一家联网摄像头企业准备上线人脸名单比对功能。研发团队已经完成测试，隐私人员对人脸数据的保存期限提出了疑问，安全人员也发现名单访问权限需要收紧。会上每个团队都给了意见，但会后仍有几个问题：谁负责补测？谁确认问题已经解决？谁有权决定上线？上线之后，又由谁检查这些控制措施是否真的在运行？
人脸名单比对同时涉及识别效果、个人数据保护和系统安全，需要产品、研发、隐私和安全人员开展跨职能协作（Cross-functional collaboration）。三道防线模型（Three Lines Model）帮助企业分清风险管理、监督和独立审计的职责。RACI 职责矩阵（RACI Matrix）则把测试、整改和上线决定等具体工作分配到人。
跨职能协作：让产品、研发、隐私和安全一起参与决策
研发团队认为，多保留一些现场图像有助于分析误判。隐私人员需要判断，排查问题是否真的需要保留这些可识别的图像。安全人员则要考虑，谁能查看或导出这些资料，一旦账户被盗会造成什么影响。这些问题彼此相关。如果等研发确定了数据采集和保存方案，再请其他团队评审，企业可能已经错过了更容易调整设计的时机。
跨职能协作就是让承担不同职责的人，在还能改变方案时，共同判断风险、比较可选做法，并把结论落实到产品设计和上线条件中。NIST《人工智能风险管理框架》在 MAP 1.2 中强调，应让具备不同领域知识和用户经验的人参与界定使用场景，并记录他们的参与。GOVERN 2.1 则强调，要明确记录风险管理的职责和沟通渠道。NIST 的隐私框架也鼓励管理层、法务和安全等职能协作，网络安全框架 CSF 2.0 则强调明确并落实安全风险管理中的职责和权限。
每个团队要带来什么信息？
| 参与职能 | 要回答的问题 | 摄像头案例中的具体贡献 |
|---|---|---|
| 产品与业务 | AI 比对结果可以触发什么行动？ | 确定名单比对结果只提示值班人员复核，还是可以触发放行。与研发和运营一起明确：如果匹配结果不确定，系统应转人工核验，还是提供其他通行方式？ |
| 研发与测试 | 模型容易在哪里出错？调整阈值会有什么代价？ | 比较夜间、逆光和遮挡条件下的误匹配（False match）与漏匹配（False non-match）。提高匹配阈值可能减少认错人的情况，也可能让更多已登记人员无法通过。用测试结果支持产品决定阈值和人工复核条件。 |
| 隐私与法务 | 用人脸识别身份是否可行？复核误判需要保留什么？ | 先核查拟议用途能否合法开展。对误判排查，和研发一起判断能否先用事件编号、比对结果和人工复核记录定位问题，明确哪些情况下才需要调取现场原图。 |
| 信息安全 | 有人能否欺骗模型，或操纵它用来比对的名单？ | 与研发一起测试系统是否会把照片或手机屏幕上的人脸当成现场人员，并验证名单被未经授权修改后能否及时发现和撤销。前者是呈现攻击（Presentation attack），后者可能直接改变模型比对所依据的名单。 |
| 运营与客服 | 怎样判断一次误判是个案，还是模型在某个场景中反复出错？ | 记录人工核验结果和现场条件。若某个入口在逆光时反复误判，将记录交给研发复测，并与产品团队判断是否暂时改用人工核验。 |
把协作放在三个决策时点
- 设计前确认预期用途（Intended purpose）。 在选定技术方案前，记录功能适用的场景、可能受影响的人、需要人工核验的条件，以及明确排除的用途。后续的测试范围和上线条件，以这份记录为依据。
- 上线前一起审查证据（Evidence review）。 当研发希望多留图像以便排错时，可以一起比较方案。日常排查能否使用事件编号、时间和错误类型？哪些问题确实需要原图？如果确需保留原图，就把适用条件、访问权限、保存期限和删除方式写清楚。评审最后应留下未解决的问题、整改负责人、完成标准和上线决定。有分歧时，按事先约定的路径升级给有权限的人。
- 上线后共享反馈（Post-deployment feedback）。 同一次误识别投诉，客服可能看到用户无法通行，研发可能发现模型在逆光下表现不佳，隐私人员则需要判断排查时可以调取哪些资料。用同一条事件记录串起这些信息，团队才能判断是处理个案、调整阈值，还是暂停某个场景并重新测试。
三道防线划分三类治理职责
国际内部审计师协会（IIA）提出的三道防线模型，适用于组织的治理、风险管理和内部控制。第一道承担并管理风险，第二道提供专业建议、监测并提出质疑，第三道由内部审计提供独立、客观的保证，也可以提出改进建议。整改和上线决定由管理层按授权负责。 董事会或其他治理机构负责整体监督。
| 治理角色 | AI 治理 | 隐私治理 | 信息安全治理 |
|---|---|---|---|
| 第一道 · 承担并管理风险（Own and manage risk） | 产品、研发和运营团队明确 AI 的用途，验证系统表现，处理误判和运行异常。 | 业务和产品团队明确为什么需要个人数据，并执行收集、访问、保留和删除规则。 | IT、研发和运维团队配置权限、修复漏洞，并处置安全事件。 |
| 第二道 · 提供建议、监测并提出质疑（Advise, monitor and challenge） | AI 风险或合规人员审查风险评估，追问测试证据能否支持预定的上线范围。 | 隐私或合规人员审查数据处理方案，提出风险意见，并跟踪整改。 | 安全治理人员制定控制要求，监督整改进度，并审查放宽安全要求的理由。 |
| 第三道 · 提供独立审计保证（Independent internal audit assurance） | 内审抽查上线审批和运行监测，评价它们能否发现并处理问题。 | 内审检查数据删除、权限管理等控制是否按规定执行。 | 内审评价漏洞管理、事件响应等流程是否有效，并跟踪审计发现。 |
判断属于哪一道，要看实际承担的职责。 例如，安全人员亲自配置摄像头后台权限时，承担第一道职责。安全治理人员检查各业务团队是否遵守权限规则、对例外提出质疑时，承担第二道职责。即使两项工作由同一部门承担，企业也要明确谁执行、谁复核，以及出现分歧时向谁报告。
职责矩阵RACI 把职责落实到具体任务
职责矩阵RACI 的四个字母分别对应 R（Responsible）负责执行、A（Accountable）对该项工作最终负责、C（Consulted）在决定前征询意见、I（Informed）接收进展或结果。一项工作可以有多位执行者，通常应明确一个 A。遇到争议或任务未完成时，团队就知道谁需要作出决定并推动解决。
以摄像头人脸名单比对功能为例，企业可以把“上线”拆成几项可分工的任务。下面是一种示例，具体岗位应按企业的实际授权调整。
| 具体任务 | R · 谁执行 | A · 谁最终负责 | C · 决策前问谁 | I · 通知谁 |
|---|---|---|---|---|
| 验证人脸比对效果，记录误匹配和漏匹配 | AI 测试团队 | 研发负责人 | 产品、AI 风险人员 | 上线批准人 |
| 确定名单数据的收集范围、访问权限和保存期限 | 产品团队 | 业务负责人 | 隐私、法务和安全人员 | 研发、运维 |
| 修复名单访问控制缺陷并复测 | 研发、运维团队 | 技术负责人 | 安全治理人员 | 产品负责人 |
| 组织上线评审并形成发布决定 | 产品团队汇总测试和整改证据、组织评审并记录决定 | 经授权的上线批准人作出决定并对其负责 | AI 风险、隐私和安全人员 | 客服、运维和销售 |
| 独立评价上线审批和控制措施是否有效 | 内部审计人员 | 内部审计负责人 | 相关团队提供记录并说明实际做法 | 审计委员会或其他治理机构、相关管理层 |
在上线评审中，C（Consulted）负责在决策前提供专业意见，A（Accountable）对这项决定最终负责。如果隐私或安全人员提出的异议尚未解决，应记录异议和处理进度，并按事先约定的路径升级。流程中还应明确，哪些问题必须整改并复核后才能上线，以及谁有权暂缓发布。同一角色在不同任务中的分工可以变化。例如，隐私人员在上线评审中可以是 C，在跟踪隐私整改的任务中则可以是 R。
对小团队，可以先从一张上线评审表开始。列出必须完成的 AI 测试、隐私检查和安全整改，逐项写明执行人、批准人、征询对象和通知对象。再约定哪些问题需要升级、谁能暂停发布，以及日后如何安排独立评价。这样，团队在真正遇到误判、数据争议或安全缺陷时，就知道谁来处理、谁来决定，以及用什么证据判断问题已经解决。
参考文献
NIST AI RMF 核心功能 · NIST 隐私框架 · NIST 网络安全框架 2.0，GV.RR
有具体的合规问题吗？欢迎咨询！
若贵公司在拓展或运营欧洲业务时，遇到隐私与数据保护、客户合规审查、认证准备或产品准入等合规问题，欢迎联系我们。我们将结合贵公司的业务与产品情况，协助梳理相关要求，明确准备事项，为后续合规工作提供支持。
联系 BEPSUN实际完成任务的人或团队，一项任务可以有多个 R。
对任务结果负责，并有权推动决策和解决问题的角色；通常应明确一个 A。
在决策前提供专业意见或必要信息的角色。
需要了解工作进展或结果的角色。