8.0
热点
AI SCORE
技术实践2026-08-08 05:28
如何构建 AI 合规证据包：清单与结构
dev.to · AI#AI合规#EU AI Act#GDPR
Editor brief · 编辑速览
合规证据包是一套工件集合而非单一文档，欧盟 AI Act、GDPR、ISO/IEC 42001 要求不同，企业需按八个核心问题组织材料。
合规章证包不是一份文件。它是一套工件集合，其中的每一项都是系统或个人在正常工作时产生的副产物，组装在一起的目的是让任何人在一天之内就能找到某个问题的答案。本文列出了这些工件，说明每一项的来源，以及它们的组织结构。
信息，不构成法律建议。审核日期：2026 年 8 月 4 日。工件清单源自《欧盟 AI 法》、《通用数据保护条例》（GDPR）、ISO/IEC 42001 以及常规审计实务；你的义务取决于你的角色、风险分类和管辖范围，下面的每一项并不一定都适用于你。凡是 AI 法要求的内容，均标注了相应条款；标注为"良好实践"而非义务的内容则非强制要求。
实际会被问到的问题
收到的请求很少是"把你们的合规文档发过来"。通常是八个左右的具体问题，围绕这些问题来构建证包，比围绕某个标准的条款清单来构建有用得多。
你们使用了哪些 AI 系统，每个系统的用途是什么？
其中哪些系统在做影响人员的决策，或为决策提供参考？
谁决定这个系统不属于高风险，依据是什么？
给我看你们部署前做的评估。
谁在审查输出，他们有什么权限？
给我看一个今年 3 月的决策，以及它是如何做出的。
你们发送给模型的个人数据后续怎么处理？
出问题时你们做了什么？
这些问题每一项都有对应的工件可以作答。如果只能靠人的记忆来回答，那就不算证据。
四个层级。一个是组织级的，一个是系统级的，一个是运营持续级的，还有一个是向供应商收集的。
compliance/
00-inventory/
ai-system-inventory.csv # every system, owner, status
role-determinations/ # one memo per system
literacy/ # materials, attendance, rationale
policies/ # AI policy, acceptable use, incident
systems/
cv-shortlister/
01-classification.md # Annex III analysis, Art 6(3) if used
02-impact-assessment.md # FRIA / DPIA / state assessment
03-technical-file/ # provider role only: Annex IV set
04-instructions-for-use.pdf # from vendor, or written by you
05-evaluation/ # eval set, results per model version
06-oversight.md # who reviews, authority, competence
07-transparency/ # notices shown to affected people
08-changes.md # model, prompt, threshold change log
support-triage/
...
operations/
decision-logs/ # or a pointer to where they live
incidents/ # register plus per-incident records
monitoring/ # metric definitions, alerts, reviews
access/ # who can call what, reviewed quarterly
vendors/
<vendor>/
dpa.pdf subprocessors-2026-08-04.pdf certifications/
model-documentation-2026-08-04.pdf
training-content-summary-2026-08-04.pdf
acceptable-use-2026-08-04.pdf change-log-notes.md
供应商文件名中的日期是关键。一个悄然更新的供应商页面无法证明你当时依赖的是什么；而一份标注日期、从已知日期检索到的 PDF 可以。
第一层：清单与角色
从数据推导清单，而不是通过调查来编制。问一百个人他们用了什么 AI，你会得到六十个答案，提到的工具加起来也就四个；但看看哪些凭证调用了哪些端点，你得到的是真实清单，包括那两个没人愿意提的系统。
如果模型调用已经通过一个网关、每个应用对应一个 key，那么清单、每个系统的模型版本列表以及第三层需要的逐请求记录都可以从同一个地方导出，而季度更新就是一条查询而非一个项目。这是从合规角度而非工程角度通过一个接口路由的主要原因。
第二层：系统级证据
第三层：运营证据
第一层和第二层是书面文件。第三层是积累起来的，而且这一层无法事后补齐——这也是为什么一份在你开始收集之前就到来的审计，无法靠加班来通过。
日志。高风险系统的提供商必须设计自动日志记录功能（第 12 条）并保留日志（第 19 条）；部署者必须在与目的相适应的期限内保留其控制下的日志，且不少于六个月，除非其他法律另有规定（第 26 条）。实际操作中需要记录：请求、模型版本、输入（或输入的哈希值）、输出、延迟、成本、调用方，以及所采取的任何人工操作。在采集时就去除个人数据，而不是事后处理，因为满是个人数据的日志是随保留时间增长而扩大的责任。
决策记录。当系统影响到一个人时：决策内容、输入数据、模型版本、阈值、是否经过人工审查及审查人、以及告知该个人的理由。这就是"给我看一个今年 3 月的决策"这一问题的答案。
监控。指标、阈值、告警，以及定期审查的记录。具名的指标及阈值是证据；"我们有在监控"不是。
事件登记簿。每个事件及其分类、已采取的措施、以及是否符合上报阈值。AI 法第 73 条要求高风险系统提供商在意识到严重事件后迅速向市场监管部门报告，且无论如何不迟于十五天，最严重的类别有更短的期限——具体期限请查阅条款原文。部署者必须通知提供商和主管部门。AI 特异性故障的预案手册是独立于登记簿的一项工作。
访问审查。谁可以用哪个 key 调用哪个模型，按一定周期审查。常规的访问控制，而且往往能发现清单中遗漏的系统。
第四层：从供应商处收集的内容
模型文档。Annex XII 下游信息，或提供商签署《实践守则》时的模型文档表，或模型卡。标注检索日期。
训练内容摘要与版权政策，适用于通用模型提供商。同样标注日期。
数据处理协议，包含注明日期的分处理商名单、传输机制和保留条款。
认证与报告。ISO 27001、SOC 2、ISO 42001（如有），以及各认证的范围声明——范围才是关键，也是没人看的那部分。
可接受使用政策。因为这份文档告诉你提供商排除了哪些用途，而被排除的用途恰恰是让你变成提供商的方式。
变更通知。收到的每个停用公告和重大变更公告，按其影响的系统归档。
一周内完成组装
对于一个什么都没有的组织，五天集中工作可以产出一份站得住脚的证包。它不会完整；但它是诚实的，这比一份假装完整的残缺证包要好得多。
第一天——清单。拉取 API key、网关日志、云账单行项目和 AI 工具报销记录。编制清单。为每一行指定一名具名负责人。预计清单长度会在所有人预测的数字两到五倍之间。
第二天——分类与角色。对每个系统：它是否涉及个人数据，是否影响对人的决策，是否面向客户。这三个问题的答案将清单分为需要进一步工作的系统和只需要一行记录的系统。为需要工作的系统撰写角色认定备忘录。
第三天——分类与评估。对每个影响人的系统进行 Annex III 分析，并在依赖第 6(3) 条推理的地方写下推理过程。为任何高风险系统启动影响评估。建立文件夹结构，把现有内容放进去。
第四天——供应商。检索并标注第四层每个供应商工件日期。这项工作是机械性的，可以委托。同时也能发现你必须向供应商索取的内容缺口，而索取和等待回复需要数周，所以必须尽早启动。
第五天——缺口与计划。写一份缺口登记簿：缺什么、谁负责关闭、截止时间。然后为不会打开文件夹的人写一份整本证包的单页摘要。这份摘要是高管或审计人员最先看到的内容。
一周后你仍不会有的内容：运营证据，因为它需要积累。在第一天就启动日志记录和事件登记簿，这样六个月后你就有六个月的记录。
防止过期
一次性组装完成后再也不动的证包比什么都没有更糟，因为它记录的状态此后已经改变，而上面有你的签名。四种周期机制保持证包的活力：
清单中价值最高的习惯是对比带日期的供应商工件。提供商会在没有任何通知的情况下更改可接受使用政策、分处理商名单和保留条款，而这些变更往往会影响你自身文档第三层的一个假设，使其失效。
你是提供商还是部署者？
ISO 42001 和 NIST AI 风险管理框架