1. 隐私计算审计与合规工程导论

隐私计算解决的是“数据可用不可见”的问题，但一个隐私计算系统能否真正上线、能否通过监管检查、能否在多方之间持续运行，取决于另一条常被忽视的工程主线：审计与合规。本课程讨论的正是这条主线——如何让隐私计算从“技术可行”走向“可证明、可追溯、可监管”。

课程定位：技术之外的“可信证据链”

隐私计算涉及多方安全计算（MPC）、联邦学习（FL）、可信执行环境（TEE）、差分隐私（DP）等技术。这些技术回答“计算是否安全”，而审计与合规回答的是另外三个问题：谁在什么授权下、对哪些数据、做了什么计算、结果是否合规。前者是密码学与系统问题，后者是证据、流程与责任问题。

因此本课程的定位不是再讲一遍密码学协议，而是把隐私计算系统当作一个需要被审计对象化的工程系统：它的每一次数据使用、每一次模型训练、每一次跨域查询，都应留下可验证的记录，并能对照法规与合同条款给出合规判断。课程面向三类读者：隐私计算平台的研发与运维人员、数据合规与法务人员、以及需要设计审计方案的安全架构师。

核心概念：审计、合规与工程化

审计（Audit）是对系统行为的事后或实时核查，关注“实际发生了什么”。在隐私计算中，审计对象包括：数据接入记录、授权凭证、计算任务描述、参与方身份、算法版本、中间结果访问日志、输出结果的披露范围等。审计的核心产物是证据——能够被独立验证、不可抵赖、可追溯来源的记录。

合规（Compliance）是对照规则判断“是否允许这样做”。规则来源包括法律法规（如《个人信息保护法》《数据安全法》）、行业标准、监管细则以及多方之间的数据合作协议。合规关注的是判断依据：某次计算是否超出授权目的、是否满足最小必要、是否完成了告知同意、跨境传输是否具备合法路径。

两者关系可以概括为：审计提供事实，合规提供标准，事实与标准比对后产生合规结论。没有审计，合规判断只能依赖自述；没有合规，审计记录再完整也无法回答“是否越界”。

工程化思维：把合规要求变成可执行的控制点

合规条款通常是自然语言，例如“数据处理应遵循最小必要原则”。工程化思维要求把它翻译成系统里可检查的控制点。以一次联邦学习任务为例：

• “最小必要” → 参与方只能读取约定特征列，任务配置中显式声明特征白名单；
• “目的限制” → 任务必须绑定授权凭证中的 purpose 字段，运行时校验；
• “可追溯” → 每次梯度聚合写入带签名的审计日志，记录任务 ID、参与方、时间戳、算法版本；
• “可验证” → 输出模型附带计算证明或哈希链，供第三方复核。

这些控制点不是事后补文档，而是嵌入任务提交、调度、执行、输出四个阶段的强制检查。工程化的标志是：合规判断可以由系统自动给出，而不是依赖人工回忆。

学习路径与工具链概览

本课程按“概念—规则—证据—工程—案例”推进。前期建立审计与合规的基本模型，中期进入具体技术：日志与证据链设计、授权与策略引擎、隐私预算核算、TEE 远程证明、MPC 审计追踪、差分隐私参数审计。后期以真实场景（金融联合风控、医疗多中心研究、跨企业数据协作）串联，完成从需求到审计报告的闭环。

工具链方面，读者会接触到几类典型组件：策略引擎（如 OPA/Rego 风格的策略描述）、审计日志与哈希链、TEE 证明验证工具、差分隐私预算跟踪器、以及合规检查清单与报告模板。课程不绑定某一厂商，而是强调可替换的接口与可验证的证据格式。

上图给出本课程的整体心智模型：左侧规则层提供判断标准，中间控制层把标准翻译为系统检查，执行层产生运行事实，证据层把事实固化为可验证记录，最终在合规判断环节完成“事实与标准”的比对，输出结论并触发整改，整改结果又反馈回控制层形成闭环。底部工具链是支撑这条链的常见组件，具体选型可替换，但证据的可验证性不可妥协。

一个最小示例：判断一次联合统计是否合规

假设 A、B 两家机构要联合统计某地区用户活跃度，约定只输出聚合结果，不暴露个体。审计系统需要记录并检查以下要点：

若 ε 实际使用值为 1.2，而协议约定上限为 1.0，则合规判断为“不通过”，需调整噪声参数或重新申请预算。这个例子说明：审计与合规工程的关键不是写文档，而是让系统在运行时就能自动比对参数与规则，并留下不可篡改的证据。