3. 隐私计算合规法律法规体系

隐私计算常被误解为“技术合规的万能钥匙”：数据不出域、只交换密文或中间结果，似乎天然满足所有法律要求。但在审计视角下，隐私计算只是改变了数据处理的技术形态，并未改变“谁在处理、处理什么、为什么处理、处理结果给谁”这一法律事实链。因此，理解合规法律法规体系，关键不是背诵法条，而是把法律义务映射到隐私计算系统的具体组件、数据流和日志证据上。

一、三法一规：国内合规的底层约束

《网络安全法》《数据安全法》《个人信息保护法》构成国内数据合规的三层结构，三者关注点不同但相互叠加。

《网络安全法》侧重网络运行安全与网络运营者义务，要求落实等级保护、日志留存不少于六个月、事件应急处置。对隐私计算而言，这意味着多方计算节点、联邦学习调度服务、隐私求交服务等都应纳入等级保护定级范围，其网络边界、访问控制、审计日志属于审计必查项。

《数据安全法》建立数据分类分级、重要数据目录、数据安全风险评估与出口管制等制度。隐私计算系统往往承载跨机构数据融合，审计时需确认：参与方数据是否完成分类分级；重要数据是否被违规汇聚；是否因“密态计算”而规避了本应执行的安全评估。

《个人信息保护法》是隐私计算最直接的法律依据。其核心义务包括：告知同意、最小必要、目的限制、单独同意（敏感个人信息、对外提供、公开）、个人信息保护影响评估（PIA）、委托处理与共同处理的责任划分、跨境提供规则，以及个人权利响应（查阅、复制、更正、删除、可携带）。隐私计算常被用于“去标识化”或“匿名化”论证，但审计必须区分：去标识化信息仍属个人信息，匿名化才脱离个保法适用范围，而匿名化需达到“无法识别且不能复原”的标准，仅靠哈希或假名化通常不成立。

二、GDPR与CCPA：跨境场景的额外要求

GDPR以“数据主体权利+合法性基础+跨境传输”为主线。其第25条“通过设计和默认的数据保护”要求在产品设计阶段嵌入合规，隐私计算架构本身可作为该义务的技术证据；第35条要求高风险处理开展数据保护影响评估（DPIA）。跨境传输方面，Schrems II判决后，依赖标准合同条款（SCC）需配合传输影响评估（TIA），隐私计算若能使原始数据不出境、仅输出聚合结果，可作为降低传输风险的补充措施，但不能自动替代TIA。

CCPA/CPRA以“消费者权利+选择退出+服务提供商合同”为核心。其“出售”定义较宽，若隐私计算输出结果可用于推断个人特征并换取对价，可能触发“出售/共享”的告知与退出义务。审计需关注：隐私计算输出是否构成“去标识化”或“聚合”，服务提供商合同是否限制二次使用。

三、法律义务到审计证据的映射

合规审计的本质是“义务—控制—证据”三段式。下表给出隐私计算场景中常见映射关系，参数与示例均为教学假设，用于说明审计取证方式。

四、审计依据的层级与取证逻辑

审计依据通常分为四层：法律条文、行政法规与部门规章、国家标准（如GB/T 35273、GB/T 37964）、以及企业内控与合同条款。隐私计算审计不能只看系统日志，还要看“法律事实”是否成立。例如，某联邦学习任务日志显示“仅交换梯度”，但若梯度可被反演还原原始样本，则匿名化主张不成立，仍属个人信息处理，需有合法性基础。

取证逻辑建议按“数据流—控制点—证据链”展开：先画出参与方、数据、模型、结果的实际流向；再在每个法律义务对应的控制点设置检查项；最后验证证据是否完整、可追溯、防篡改。下面用一张关系图展示法律要求如何落到隐私计算系统的审计对象上。

五、审计实施中的关键判断

第一，区分“技术匿名化”与“法律匿名化”。审计应要求提供反演测试或重识别风险评估报告，而非仅凭算法名称。第二，关注“共同处理”与“委托处理”的责任边界：多方安全计算中，若各参与方共同决定处理目的和方式，可能构成共同处理者，需在协议中明确责任分工。第三，跨境场景下，隐私计算输出结果若仍可关联到个人，出境规则依然适用。第四，日志与密钥管理是审计取证的基石：密钥销毁记录往往决定“删除权”是否真正落实。

综上，隐私计算合规审计的核心不是判断技术是否先进，而是判断法律义务是否被真实、完整、可验证地履行。法律体系提供义务清单，隐私计算提供控制手段，审计则负责在两者之间建立可追溯的证据桥梁。