AI 治理：负责任 AI 所需的政策、控制与证据

SEYA Group 帮助企业为已经上线或即将上线的 AI 系统编写政策、控制措施和证据。工作成果对应 NIST AI 风险管理框架；若您需要建立管理体系，则同时对应 ISO/IEC 42001。SEYA 不对该体系进行认证，也不会声称一份政策文件就能让模型变得安全。项目由我们温哥华办公室的资深工程师主导，技术评审也由同一批人完成。

适用对象

被要求拿出一份 AI 政策、又不想要一本工程团队不会照做的厚文件的风险、安全和技术负责人。需要向董事会、客户或监管机构说明系统支持什么决策、使用什么数据、谁有权关停它的团队。已经在进行 AI 安全评审、需要配套治理文档与技术控制相匹配的公司。

您将获得

• 系统清单。纳入范围的 AI 系统：用途、用户、数据来源、模型或 API 提供方，以及业务负责人。没有负责人的系统会被记为缺口，而不是在纸面上随便指定一个。
• 指向具体控制的政策。可接受使用、人工审核、数据处理和供应商审查，每一项都指向一个有人能够执行的控制措施。结构遵循 NIST AI 风险管理框架 （治理、映射、度量、管理）。如果您要将管理体系对标 ISO/IEC 42001，我们会把同一套控制映射到该标准的条款。映射不等于证书。如果您寻求 ISO 认证，证书由经认可的认证机构颁发。
• 证据。能证明政策已被执行的记录：一次审批、一份来自 LLM 安全评估的测试报告、一份工具白名单变更人的日志。我们不会为没有召开过的会议编造纪要。
• 加拿大背景说明。该说明记录系统在加拿大联邦私营部门隐私法（PIPEDA）下的位置，以及是否有任何 AI 专门法规已对该系统实际生效。拟议中的立法，包括随 Bill C-27 提出的《人工智能与数据法案》（Artificial Intelligence and Data Act），均标注为“拟议”。我们不会把一项法案当作现行法律义务。这份说明是供您的法律顾问参考的工程背景，不是法律意见。

项目如何开展

• 确定系统。一个产品，或一份简短的清单。试图在第一天就治理所有实验的项目，是做不完的。
• 写下决策。系统可以做什么、不得做什么、谁来承担剩余风险。安全测试中发现的技术限制会直接写入控制措施，而不是放进附录。
• 附上证据。每项控制都注明产生记录的系统。 DevSecOps 流水线中已有的检查会直接复用。
• 交给负责人。政策集和证据索引归您的公司所有。SEYA 不会继续担任审批方。

您需要具备的条件

纳入范围的每个系统都要有业务负责人；如果需要法律结论，要有法律顾问；并能访问系统架构。如果还没有人测试过提示词和工具，请先完成该评估，再让政策声称某项您尚未见过生效的控制。

不在范围内：法律意见、ISO/IEC 42001 证书、关于模型无偏见或安全的声明，以及构建 AI 产品本身。我们可以引用的已公开客户工作，仍是 Boeing GoldCare Azure 迁移中的安全评审模式：客户的 InfoSec 团队在上线前审查了基础设施。那不是一个 AI 治理项目，而是本服务所依据的评审习惯。

常见问题

你们会为我们做 ISO/IEC 42001 或 NIST 认证吗？

不会。NIST AI RMF 是一个框架，不是认证体系。ISO/IEC 42001 是经认可的机构可以据以认证的标准。SEYA 把您的控制映射到这些文件并写明缺口。证书不由我们颁发。

这能替代隐私审查吗？

不能。我们会说明系统能触及哪些数据，以及哪些隐私问题需要您的法律顾问介入。PIPEDA 义务由您承担。治理文件包为法律顾问提供了具体的阅读材料，但它不是隐私法律备忘录。

政策可以比框架更短吗？

可以。文件包只覆盖范围内的系统，而非框架中的每一项功能。不适用的控制会标注“不适用”并注明原因，而不是作为空白文本照搬进来。

如果董事会或客户已经向您索要 AI 政策，而您希望这份政策与实际运行的系统挂钩，请预约云安全评估。