AI 治理与合规

具体法规因司法辖区而异，变化之快，任何一篇文章都追不上。稳定的是底下那一套义务，无论套用哪个框架，最终都收敛到差不多的要求上。

本文讲的就是这些义务。涉及任何有约束力的情形，请找你所处辖区内具备资质的人咨询——本文不构成法律意见。

风险随后果升级

各个框架的共同点：义务的轻重，随系统出错会造成什么后果而定。

**后果轻微。**起草文案、做摘要、内部检索。输出错了只是浪费时间。几乎没有正式的合规义务。

**后果值得一提。**用户会依赖的推荐、面向客户的沟通、内容排序。要求披露，并对质量有期望。

**后果重大。**实质影响某个人的决定——就业、信贷、住房、教育、医疗、法律。义务不轻，在若干辖区内还有专门的法律要求。

**禁止。**有些应用在某些地方根本就不允许做。

先给你的系统在这把尺子上定个位置，再决定它需要什么流程。大多数内部工具都在最底下；而任何会影响某个人能否获得重要资源的系统，都不是。

通常会被要求什么

**披露 AI 的参与。**这越来越成为底线要求，而且无论如何都合理。

**重大决定要有人工复核。**关于个人的自动化决定，通常要求有一个实质意义上的人工角色——关键就在「实质」二字。一个人一小时点一百次通过，那不叫复核，盖章式走过场也满足不了它看起来满足的那条要求。

**可解释性。**多少要能说出输出为什么是这样。注意，模型自己讲出来的推理并不是可靠的审计线索——对 RAG 系统来说，检索到的来源比生成的解释是强得多的证据。

偏见评估，针对会影响人的系统。要在相关群体上实测出来，而不是嘴上声称。

**数据处理。**合法依据、最小化、留存期限、应请求删除——范围要覆盖记忆、日志和索引，不只是你的主数据库。

**记录留档。**这个系统做什么、用了什么数据、怎么测的、有哪些局限。

该写下什么

如果你在开发过程中顺手写，而不是事后回头补，文档负担比听起来小得多。

**用途与范围。**它做什么、不做什么、谁来用。

**数据。**进去什么、从哪来、到哪去、留存多久、是否由第三方服务商处理。

**模型与配置。**服务商、模型、版本，以及一个事实：托管模型会在名字不变的情况下悄悄变化。

**测试。**你的评测集、结果，以及已知的失效模式。写下来的局限是一种资产——它证明你确实查过。

**人工监督。**哪些操作设了闸、由谁复核，以及实测的通过率。

**事故记录。**出过什么问题，之后改了什么。

这些大多是你本来就该有的工程文档。合规视角主要多了一条要求：让它保持最新。

反复出现的难题

**供应商条款会变。**服务商的数据处理方式会变。谁在跟进你的依赖更新，就该把这件事一起跟进。

**模型的静默更新。**行为变了，版本号却没变，这意味着你文档里写的测试描述的是一个已经不存在的东西。唯一的办法是定期重新评测。

**跨派生存储的删除。**一条删除请求必须触及 embedding、存储的记忆和日志。事后补这套东西是真的痛苦——在你需要它之前就先设计好。

偏见测量需要分群体数据，而你可能没有收集，也可能不被允许收集。这事没有干净的解法；把你采取的做法写下来。

**跨境传输。**模型跑在哪里，可能直接决定你能不能用它。

相称原则

一个内部摘要工具不需要正式的风险评估。决定贷款申请的系统需要。

对低风险工作过度走流程是有代价的：它占用了本该投给重要系统的注意力，还会让人把治理当成走形式。流程要和后果相匹配。

要点回顾

• 义务的轻重随后果而定，与系统有多先进无关。
• 常见要求：披露、实质性的人工复核、可解释性、偏见评估、数据处理、记录留档。
• 记录用途、数据流向、模型版本、测试、监督和事故——这些大多是你本来就需要的工程文档。
• 检索到的来源，比生成的解释更有说服力。
• 反复出现的难题：供应商条款变动、模型静默更新、跨派生存储的删除，以及你收集不到的偏见数据。
• 流程要与后果匹配；对低风险系统过度走流程，会浪费高风险系统真正需要的注意力。

下一篇： LLM 系统的可观测性