Aperintel/regulated-ai-checklist

# 受监管 AI 部署检查清单 [](LICENSE) 这是一份供从业者使用的 AI 系统部署前检查清单，适用于在受监管环境中上线 AI 系统。涵盖了治理、模型评估、审计、安全、数据保护、监控、事件响应、供应链、文档、Agentic AI、GPAI 义务以及持续的变更管理。内容源自英国和欧盟受监管行业（FCA 监管的公司、NHS 部署、欧盟 AI 法案高风险系统、金融服务、公共部门）的实际操作实践。 **EU AI Act 执法说明：** 根据 EU AI Act 附录 III，高风险 AI 系统的义务将于 **2026 年 8 月 2 日**起全面生效。第 53 条和第 55 条规定的 GPAI 模型提供商义务已于 **2025 年 8 月 2 日**起适用。如果检查项对应了特定的 EU AI Act 条款，会在括号内标明相应的条款。标记为 `[GDPR Art. X]` 的项目适用于 UK GDPR 和 EU GDPR。 本清单旨在在任何涉及受监管业务流程的 AI 系统的设计、构建和部署前阶段**使用**。打印出来，复制并修改它，在买方的合规官审查之前通读一遍，并将完成的版本带到采购环节。 由 [Aperintel](https://github.com/aperintel) 维护。欢迎社区提交 PR。 ## 如何使用 - 将检查清单复制到你自己的代码库或 wiki 中。 - 与相关职能部门（工程、合规、安全、数据保护、运营）一起逐节核对。 - 如实勾选各项。这份清单的意义在于暴露出你尚未完成的工作；勾选了你实际上并未完成的项目就失去了它的意义。 - 任何你尚无法勾选的项目都会成为部署的关口。阅读此清单的买家期望每一个项目要么已被勾选，要么有书面理由说明其超出范围。 - 各阶段按每个标题中的生命周期里程碑大致按顺序排列，但有几个阶段（特别是阶段 0 和阶段 6）必须在整个项目中反复重温，而不是仅在指定的节点执行一次。 本清单采用 CC BY 4.0 许可；你可以对其进行分支复制、针对你的领域进行定制，并在注明出处后重新发布。 ## 阶段 0：治理基础 在编写任何代码之前。 - [ ] **用例已命名、确定范围并记录在案。** 具体包括：AI 正在参与什么决策，AI 使用了什么证据，AI 输出后会执行什么操作，以及由谁（如果有）授权该操作。`[EU AI Act Art. 9, Art. 13]` - [ ] **已明确监管类别。** 是 EU AI Act 高风险（附录 III）？有限风险（第 50 条）？属于 FCA Consumer Duty 范畴？适用 NHS DSPT？适用 PRA/FCA 模型风险管理预期？必须具体说明哪些条款适用于你的部署，而不是仅用“可能受监管”一笔带过。 - [ ] **已指派问责人。** 部署组织中有一名明确的人员对结果负责。他们的名字会出现在部署记录中。该角色不是“AI 团队”，而必须是具体的某个人。`[EU AI Act Art. 17]` - [ ] **已提交风险评估。** 记录可预见的危害、受影响的人群、严重程度以及缓解措施。在系统发生每次重大变更时都要更新。`[EU AI Act Art. 9]` - [ ] **部署决定有书面记录。** 一名有权让组织对该 AI 系统负责的人已经以书面形式签署了风险评估。该签批文件已归档。`[EU AI Act Art. 17]` - [ ] **已确定基本权利影响评估范围。** 对于高风险 AI 系统的部署者，在部署前需要进行 FRIA。涵盖对人格尊严权、数据保护、非歧视、消费者保护以及儿童权利的影响。公共部门部署者以及提供公共服务的私营机构明确在适用范围内。`[EU AI Act Art. 27]` - [ ] **已起草技术文档。** 对于高风险 AI 系统的提供商，必须在系统上市或投入使用前按照附录 IV 准备技术文档。涵盖系统描述、训练数据、验证、预期目的、风险管理和监控。`[EU AI Act Art. 11]` - [ ] **已确定合规评估途径。** 对于高风险 AI 系统的提供商，需明确并启动适用的合规评估程序（根据第 43 条进行内部控制，或根据第 44 条通过公告机构进行第三方评估），并计划签署 EU 符合性声明。`[EU AI Act Art. 43, Art. 48]` - [ ] **已更新 AI 系统清单。** 组织需维护一份正在使用中的 AI 系统登记册。在编写第一行生产代码之前，必须将此次部署连同其分类、责任人和监管类别一同添加到该登记册中。`[EU AI Act Art. 17]` ## 阶段 1：审计与溯源 在第一次生产调用之前。 - [ ] **每次 AI 调用都会写入审计条目。** 每次模型调用、每个 prompt、每次响应、每个护栏决策都会被记录。默认开启，而非可选。`[EU AI Act Art. 12]` - [ ] **审计条目具有防篡改性。** 审计日志采用哈希链、仅追加结构，并经过加密签名。当监管机构询问“你是否修改过此条目”时，可以用数学上的确定性来回答，而不是口头保证。`[EU AI Act Art. 12]` - [ ] **审计条目包含足以重建决策的信息。** 至少包括：输入指纹、模型身份及版本、prompt 模板、响应、时间戳、请求者身份、以及此次调用中作出的策略决定。`[EU AI Act Art. 12]` - [ ] **每次审计条目都会记录模型版本和发布标识符。** 部署中途发生的模型更新必须在审计日志中可被检测到。事件后审查必须能够确定哪个模型版本产生了哪个输出。`[EU AI Act Art. 12]` - [ ] **已设定审计日志保留期。** 以书面形式界定，并与相关法规保持一致（GDPR 有其自身的期限；FCA SYSC 9.1 也有自己的规定；特定行业的规则可能会延长该期限）。自动删除操作按相同的时钟运行。`[EU AI Act Art. 19]` - [ ] **审计日志可独立验证。** 第三方（审计员、监管机构、买方的内部审计团队）可以在不访问你系统的情况下验证该链条。 - [ ] **按既定时间表测试审计链完整性。** 通过程序化方式验证哈希链，而不是假定其完好无损。出现故障时会立即向运维团队发出警报。`[EU AI Act Art. 12]` - [ ] **已记录训练数据的来源。** 模型在哪里、在何时、基于什么数据以及适用什么许可进行的训练。“我们使用第三方 API”同样要求获取 API 供应商的训练数据来源。`[EU AI Act Art. 10]` - [ ] **维护 AI 系统 SBOM (Software Bill of Materials)。** 列出构成 AI 系统的所有模型权重、适配器、第三方库和数据管道，并锁定版本。在每次依赖项变更时进行更新。 ## 阶段 2：模型评估与验证 在模型提供生产流量之前。 - [ ] **准确率已在具有代表性的生产分布上进行了基准测试。** 不应仅仅参考供应商发布的基准。应使用从与生产输入相同分布中提取的保留评估集。其结果应是存档的具体数值，而非口头保证。`[EU AI Act Art. 15]` - [ ] **准确率按人口统计学子群体分别衡量。** 整体准确率数据会掩盖子群体层面的失败。针对对该用例具有实质影响的每个子群体分别测量性能，并记录结果。`[EU AI Act Art. 9, Art. 10]` - [ ] **测试集未受训练数据污染。** 已验证评估集排除了模型开发期间在训练、fine-tuning 或验证中使用过的数据。受污染的测试集会产生虚高的准确率数值。 - [ ] **评估了测试集与生产环境之间的分布偏移。** 如果评估集取自与未来生产流量不同的时间段、地理区域或人群，则应记录该差距，并明确说明其对预期准确率的影响。 - [ ] **已对失败模式进行分类。** 记录模型所犯的错误类型：假阳性、假阴性、系统性偏差、边缘情况失败以及安全关键型失败模式。此分类目录须由问责人进行审查。`[EU AI Act Art. 9]` - [ ] **对生成式系统评估了模型输出校准。** 在模型输出置信度分数或概率的情况下，需测量其校准情况：所声称的概率是否与经验准确度相符？对错误答案声称 95% 置信度的过度自信模型属于一种部署风险。`[EU AI Act Art. 15]` - [ ] **对生成式输出的幻觉率进行了量化。** 对于任何产生事实性声明的生成式模型，应测量并记录其在相关领域评估集上的虚构率。必须在部署前（而不是事后）以书面形式设定可接受的阈值。`[EU AI Act Art. 15]` - [ ] **对抗性测试套件涵盖了模型特定的攻击类别。** 除了 prompt injection 之外，还需测试：模型反转（模型是否会泄露训练数据？）、成员推理（攻击者能否确定特定记录是否在训练集中？）以及规避攻击（对抗性构造的输入是否会产生系统性错误的输出？）。`[EU AI Act Art. 15]` - [ ] **红队演练已完成。** 已针对部署的系统（而不仅仅是孤立模型）进行了由人工主导的结构化攻击模拟。调查发现已记录在案，且缓解措施已有据可查。`[EU AI Act Art. 15]` - [ ] **在任何试点之前 Model Card 已填写完毕。** 包括训练数据摘要、预期目的、已知局限性、已知失败模式、超出范围的使用情况、建议的人工监督级别。如果使用的是第三方模型，须审查其提供商的 Model Card 并记录存在的差距。`[EU AI Act Art. 13]` ## 阶段 3：安全与访问控制 在第一位用户登录之前。 - [ ] **凭证已存入 Vault。** 代码、代码库、CI 变量或 Slack 中绝无 API 密钥、签名密钥或服务账号机密。所有凭证都必须存放在托管的 Vault 中。`[EU AI Act Art. 9]` - [ ] **凭证按计划轮换。** 生产环境至少每季度轮换一次。轮换流程是自动化的；如果需要依赖人工记忆，则视为不达标。 - [ ] **实行基于角色的访问控制。** 每个角色仅拥有所需的最低权限。工程师没有常驻管理员访问权限；访问需按任务申请、授权并记录在审计日志中。 - [ ] **强制实施多因素认证 (MFA)**，适用于接触部署环境的每个账号，包括第三方 SaaS 控制台。 - [ ] **已实施网络隔离。** AI 工作负载运行在仅具有所需最低出口权限的网络段中。对模型提供商的出站调用通过有记录的代理进行。 - [ ] **已测试 prompt injection 防护栏。** 尝试绕过你的防护栏的对抗性输入应成为测试套件的一部分，而不仅仅是手工挑选的示例。`[EU AI Act Art. 15]` - [ ] **已审查数据泄露途径。** 记录所有可能从 AI 工作流中泄露敏感数据的途径（模型提供商日志、调试工具、错误报告、如果对外共享的审计日志本身）。 - [ ] **已评估模型供应链。** 如果使用了预训练权重或适配器，需记录其来源：出处、训练数据摘要、许可证，以及从原作者到你部署环节的监管链。`[EU AI Act Art. 10]` - [ ] **已实施速率限制和滥用检测。** 单个用户或自动化客户端不能以任意体积驱动 AI endpoint。异常的调用模式会向运维团队发出警报。 - [ ] **已扫描 AI 和 ML 包漏洞。** CI pipeline 包含涵盖 ML 特定包（模型服务框架、推理库、数据处理库）的依赖扫描。依赖树中已知的 CVE 会像其他软件漏洞一样被追踪，并按相同的进度进行修补。 ## 阶段 4：数据保护与合规 在第一批个人数据接触系统之前。 - [ ] **已完成数据处理影响评估 (DPIA)。** 根据英国和欧盟 GDPR，针对高风险处理必须进行此评估。AI 对个人作出决策几乎总是符合高风险条件。`[GDPR Art. 35]` - [ ] **已确定处理的合法依据。** 根据英国和欧盟 GDPR 第 6 条。需按数据类别记录依据，而不仅仅是按系统。`[GDPR Art. 6]` - [ ] **已实施数据最小化。** AI 仅能看到其所需的数据。与决策无关的个人数据在到达模型之前会被过滤掉。`[GDPR Art. 5(1)(c), EU AI Act Art. ]` - [ ] **入站数据已运行 PII 脱敏。** AI 不需要的 PII 会在边界处进行脱敏。脱敏操作会被记录在审计日志中。 - [ ] **已明确评估特殊类别数据处理。** 处理健康、生物识别、基因、种族或民族血统、或其他特殊类别数据（GDPR 第 9 条）需要超出标准第 6 条依据的明确合法依据。记录所使用的具体依据及采取的防护措施。`[GDPR Art. 9]` - [ ] **如果未成年人可能受到影响，则需纳入儿童数据保护范畴。** 如果系统可能处理与 18 岁以下个人相关的数据或作出影响他们的决策，须评估并记录 UK GDPR 第 8 条、Age Appropriate Design Code (UK) 以及 COPPA (US) 规定的额外保护措施。 - [ ] **平等与非歧视义务已映射到模型的决策范围。** 根据《2010 年英国平等法》，对拥有受保护特征（年龄、残疾、性别重置、婚姻与民事伴侣关系、怀孕与产假、种族、宗教或信仰、性别、性取向）的个人产生歧视性影响的决策具有法律风险。对于公共机构，适用公共部门平等责任（第 149 条）。记录哪些受保护特征对该用例具有实质性影响。 - [ ] **删除权可实施。** 当数据主体请求删除时，你能够识别、定位并从每个系统组件（包括审计日志）中删除其数据（受法律义务合法依据例外情况的约束）。`[GDPR Art. 17]` - [ ] **解释权可实施。** 受自动化决策影响的数据主体能够获得关于其背后逻辑的有效解释。`[GDPR Art. 22, EU AI Act Art. 13]` - [ ] **已记录国际数据传输。** 在运营商管辖区之外的每一次传输都记录了其法律机制（充分性认定、标准合同条款等）。如果你的模型提供商托管在不同的管辖区，此规定适用于每一次调用。`[GDPR Art. 44-49]` - [ ] **同意记录持久有效。** 如果同意是任何处理途径的合法依据，则同意记录必须经过签名、带有时间戳，并与审计日志一样具有防篡改性。`[GDPR Art. 7]` ## 阶段 5：运营监控 在系统交付给第一位付费客户之前。 - [ ] **漂移检测已上线。** 监控模型输出的分布偏移。出现异常时触发警报。`[EU AI Act Art. 72]` - [ ] **在监控中区分概念漂移和数据漂移。** 数据漂移（输入分布已发生变化）和概念漂移（输入与正确输出之间的关系已发生变化）需要不同的应对措施。你的监控系统能够检测并分类两者。 - [ ] **偏见监控已上线。** 跨越与用例相关的人口统计学子群体追踪输出分布。统计学上显著的发散会触发审查，而不仅仅是记录日志。`[EU AI Act Art. 9, Art. 10]` - [ ] **成本监控已上线。** 单次调用成本、单功能成本和单客户成本对运维人员近乎实时可见。失控的循环不会变成六位数的账单。 - [ ] **延迟监控已上线。** 追踪 P95 延迟并设置警报。向买家提供的 SLA 应与你系统在负载下实际提供的性能相匹配。 - [ ] **错误报告已接入审计日志。** 每个影响决策的错误情况都会被记录下来，并附带足够的事件后审查上下文。 - [ ] **输出质量已进行抽样。** 按既定频率由人工审查具有统计学意义的输出样本。样本量须经过统计学证明而非任意选择。审查结果会反馈到模型选择和 prompt 工程中。`[EU AI Act Art. 72]` - [ ] **已检测并监控反馈循环。** 当模型输出影响未来输入时（塑造用户行为的推荐、影响模型后续训练数据池的决策），需记录此循环并监控其放大效应。 - [ ] **已追踪覆盖模式。** 当人工覆盖 AI 输出时，覆盖行为会被记录、分类和审查。覆盖率上升是模型发生漂移的先期指标。`[EU AI Act Art. 14]` ## 阶段 6：事件响应 在你宣布全面可用之前。 - [ ] **已编写事件预案。** 当监管机构在周一早上 9 点打电话询问一项具体决策时会发生什么。谁会被呼叫。会产生哪些交付物。向客户传达什么内容。需以书面形式演练，最好进行实战演习。`[EU AI Act Art. 17, Art. 73]` - [ ] **存在决策回滚路径。** 当你发现模型对某一特定群体产生了错误输出时，你能够识别出受影响的决策、冻结该群体的后续 AI 处理，并在数小时（而不是数周）内向运营商提供一份名单。 - [ ] **紧急停止开关可用。** 单个控件即可禁用受影响范围内的 AI 决策。该开关每季度进行测试。该操作会被记录在审计日志中。`[EU AI Act Art. 14]` - [ ] **熟知违规通知时限。** 根据英国和欧盟 GDPR，你有 72 小时的时间通知相关监管机构。待命团队需知晓这一点，并明白在你的特定系统中什么情况被视为“违规”。`[GDPR Art. 33]` - [ ] **了解 EU AI Act 的严重事件通知。** 对于高风险 AI 系统，影响健康、安全或基本权利的严重事件必须向国家市场监督机构报告。标准通知期限为 15 天；涉及疑似死亡的事件期限为 10 天。`[EU AI Act Art. 73]` - [ ] **已明确监管机构联络流程。** 指定在事件中与 ICO、FCA、PRA 或国家市场监督机构沟通的人员。明文规定他们无需进一步签字即可授权披露的内容。明文规定哪些内容必须先交由法务处理。 - [ ] **已记录事件后审查流程。** 在每次严重事件或险发事件后，进行结构化审查，记录根本原因，并将调查结果反馈到风险评估和系统设计中。`[EU AI Act Art. 17]` - [ ] **存在险发事件报告渠道。** 运维人员和用户必须有办法报告险情（几乎造成危害的输出、差点失效的护栏、暴露出缺陷的边缘情况），而无需启动正式的事件流程。险发事件应按与正式事件相同的频率进行审查。 - [ ] **已起草通讯模板。** 针对最可能出现的事件类型预先起草对外通讯内容。经过法务审查。避免在最糟糕的时刻面临冷启动问题。 ## 阶段 7：供应商与供应链 在你与每个外部提供商签约之前。 - [ ] **每个外部提供商都登记在册。** 模型提供商、托管提供商、可观测性提供商、Vault 提供商、审计日志提供商，每一项依赖。`[EU AI Act Art. 25]` - [ ] **每个提供商都有存档的 DPA。** 根据英国和欧盟 GDPR 签署的数据处理协议。存放在审计期间可以找到的地方。`[GDPR Art. 28]` - [ ] **了解每个提供商的监管姿态。** ISO 27001？SOC 2 Type II？ISO 42001？记录你所依赖的认证和审计报告。 - [ ] **所使用的每个模型都有 Model Card 或同等的披露文件。** 训练数据摘要、已知局限性、预期用途、已知失败模式。如果提供商未发布相关内容，需记录他们已披露的信息并指出差距。`[EU AI Act Art. 13]` - [ ] **已审计开源许可证合规性。** 审查 AI 技术栈中的每个开源模型、数据集和库，确认其与商业用途的许可证兼容性。GPL、AGPL 以及特定于模型仅供研究的许可证在生产部署前需要明确批准。 - [ ] **每个模型提供商合同中都包含 AI 特定的 SLA。** 正常运行时间的 SLA 是不够的。合同应涉及：最低准确率底线、模型版本变更时的通知要求、数据保留和删除保证，以及提供商对影响你客户的模型诱发错误所承担的责任。 - [ ] **每个 AI 供应商合同中都包含审计权条款。** 你的组织可以要求供应商提供 AI Act 合规性、训练数据文档和安全姿态的证据。该条款涵盖了你自身的审计以及监管机构或第三方代表你进行的审计。 - [ ] **已审查子处理者名单。** 审查每个提供商的子处理者。关键性增加会触发重新审查。`[GDPR Art. 28]` - [ ] **已针对提供商的连续性制定计划。** 如果模型提供商被收购、弃用该模型或发生宕机，你需有一份不需要从“恐慌”开始的书面计划。 ## 阶段 8：文档与培训 在运营系统的团队开始轮班之前。 - [ ] **内部已发布 System Card。** 系统的功能、不能做的事情、已知局限性、已知失败模式、敏感场景指导。`[EU AI Act Art. 13]` - [ ] **已发布运维手册。** 日常操作、常见失败模式、升级路径、与监管机构对话的预案。 - [ ] **已交付培训。** 每位与 AI 工作流交互的运维人员都接受了关于 System Card 和运维手册的培训。已定义复习频率。`[EU AI Act Art. 26]` - [ ] **存在面向最终用户的文档。** 在适当情况下，受 AI 决策影响的人员能够找到满足 AI Act 第 13 条透明度义务的文档。`[EU AI Act Art. 13]` - [ ] **已为非技术利益相关者发布通俗语言摘要。** 提供非工程师（董事会成员、监管机构、客户）能够阅读并采取行动的 System Card 和关键风险发现版本。与专业技术文档分开。 - [ ] **聊天机器人和合成语音系统声明其 AI 属性。** 当用户通过文本、语音或视频（聊天机器人、语音助手、deepfakes）与 AI 交互时，需披露该交互的 AI 属性。不要写在不起眼的脚注中，须在交互发生时予以明确。`[EU AI Act Art. 50]` - [ ] **已定义变更管理流程。** 什么情况属于对 AI 系统的重大变更、谁有权批准变更，以及这将触发哪些重新评估，必须在上线前以书面形式确定，而不是在变更请求到来时才仓促决定。`[EU AI Act Art. 17]` - [ ] **合规团队具有利益相关者席位。** 在对系统、模型或部署范围进行重大变更时会咨询合规团队。而不是事后才要求他们签字。 ## 阶段 9：Agentic AI 系统 当 AI 系统能够规划多个步骤、调用外部工具、在外部系统中执行操作，或在极少人工干预的情况下跨多个 agent 进行协作时，适用此阶段。 - [ ] **每个 agent 操作都记录了其主体。** 每次操作都会记录发起用户、调用的工具、传递的输入以及结果。在一个 session 中调用了十个工具的 agent 会产生十个审计条目。`[EU AI Act Art. 12]` - [ ] **工具权限遵循最小权限原则。** 每个 agent 仅被授予其定义范围内所需的工具访问权限。在部署前以及对 agent 角色进行任何更改后审查权限。 - [ ] **Agent 范围有书面界定。** 文件需声明允许每个 agent 采取的操作、可以写入的系统以及它不能做的事情。边界需在工具层面强制执行，而不仅仅依靠指令。 - [ ] **针对不可逆操作存在 Human-in-the-loop 关卡。** 任何无法撤销的 agent 操作（发送电子邮件、进行支付、修改数据库记录）在执行前都必须获得明确的人工批准。该批准将作为顶级审计事件被记录。`[EU AI Act Art. 14]` - [ ] **多 Agent 移交过程已被审计。** 当一个 agent 将控制权或上下文传递给另一个 agent 时，移交过程会被记录：源 agent、目标 agent、上下文指纹和时间戳。完整的监管链可通过审计日志重建。 - [ ] **Agent 之间的通信经过身份验证。** 接收其他 agent 指令的 agent 在执行操作前会验证来源。未经验证的指令会被拒绝并记录。 - [ ] **已测试对抗条件下的 agent 行为。** 当工具返回旨在操纵 agent 下一步操作的恶意内容时会发生什么？当编排 agent 发送超出范围的指令时会发生什么？这两种场景都必须包含在测试套件中。 - [ ] **按 agent 强制执行资源消耗限制。** 每个 agent session 都设定了 Token 预算、外部 API 调用预算和实际时间预算上限。失控的 agent 循环不会消耗无限资源。 - [ ] **在 Agent、工作流和系统级别都存在紧急停止开关。** 单个控件可以停止一个 agent、一个工作流或所有的 agentic 活动。每个级别都经过测试并记录了测试结果。`[EU AI Act Art. 14]` - [ ] **已对记忆和上下文保留进行隐私评估。** 如果 agent 跨 session 保留信息（用户偏好、先前的决策、学到的事实），则需在A 下记录并评估保留期限、存储位置和擦除机制。`[GDPR Art. 35]` - [ ] **在 Agent 采取行动前已验证工具输出。** Agent 不会在没有进行完整性检查的情况下直接将工具输出传递给下一步。意外或格式错误的工具输出会被标记出来，而不是被静默处理。 - [ ] **已针对所有工具输入测试了 prompt injection。** 通过任何工具返回值（搜索结果、数据库读取、API 响应、电子邮件内容）注入的对抗性内容应成为红队测试套件的一部分。`[EU AI Act Art. 15]` ## 阶段 10：通用人工智能 (GPAI) 模型义务 当你的系统建立在通过 API 访问的基础模型或大型语言模型之上，或者你的组织是 GPAI 模型的提供商时，适用此阶段。EU AI Act 下的 GPAI 义务已于 **2025 年 8 月 2 日**起适用。 - [ ] **已确立 GPAI 模型分类。** 确定底层模型是否符合 EU AI Act 第 51 条规定的通用人工智能模型定义。系统性风险阈值是训练计算量为 10^25 FLOPs。如果模型达到此阈值，则适用第 55 条规定的额外义务。`[EU AI Act Art. 51]` - [ ] **已审查并保留提供商的技术文档和使用政策。** GPAI 模型提供商必须向下游部署者提供技术文档、训练数据摘要和使用政策。在基于该模型进行构建之前，获取并归档这些文档。`[EU AI Act Art. 53]` - [ ] **已存档来自 GPAI 提供商的版权和训练数据摘要。** GPAI 模型提供商必须发布一份所使用的训练数据摘要，包括依赖了哪些版权例外情况（如文本和数据挖掘）。保留此摘要作为供应商文档的一部分。`[EU AI Act Art. 53]` - [ ] **已记录 GPAI 提供商之外的部署者义务。** GPAI 提供商的 EU AI Act 合规性涵盖了模型层，但不涵盖你的部署层。明确记录提供商的合规性涵盖和不涵盖的内容，以及作为部署者的组织需要承担哪些额外义务。`[EU AI Act Art. 25, Art. 26]` - [ ] **监控 GPAI 提供商的模型版本变更。** 基础模型提供商可以不加事先通知地推送能力或对齐更改。需具备检测模型更新、评估其对部署合规姿态的影响、并在必要时触发重新评估的流程。 - [ ] **针对具有系统性风险的 GPAI 提供商：已审查对抗性测试结果。** 具有系统性风险的 GPAI 模型提供商必须进行对抗性测试（红队演练），并向 EU AI Office 报告严重事件。如果你的部署依赖于此类模型，需审查该提供商发布的对抗性测试计划和事件历史。`[EU AI Act Art. 55]` - [ ] **已审查服务条款和 API 合同中的 AI Act 合规义务。** 提供商的 ToS 必须与你作为部署者的 EU AI Act 义务相兼容。关键领域包括：针对你的 prompt 和输出进行训练、数据保留和删除、子处理者披露、以及针对模型诱发错误的责任分配。 ## 阶段 11：变更管理与持续合规 适用于对 AI 系统进行每一次重大变更时，以及无论是否发生变更都需按计划进行的年度审查。 - [ ] **维护变更登记册。** AI 系统的每一次重大变更（模型更新、prompt 更改、防护栏修改、数据管道更改、范围扩大、新用户群体）都会记录日期、描述以及批准人的姓名。`[EU AI Act Art. 17]` - [ ] **重大变更标准已有书面定义。** 在第一个变更请求到来之前，需记录什么情况属于需要全面重新运行相关检查清单阶段的“重大修改”。EU AI Act 第 16(d) 条要求针对重大修改更新技术文档；什么构成“重大”的标准应在内部预先设定，而不是事后争论。`[EU AI Act Art. 18]` - [ ] **模型更新触发阶段 2 的重跑。** 对底层模型的任何更改（版本升级、fine-tuning、量化更改、适配器更换）都会触发模型评估和验证阶段的重新运行。重新评估的结果将归档在变更登记册中。 - [ ] **范围变更触发阶段 0 和阶段 4 的重跑。** 将系统扩展至新用户群体、新决策类型或新司法管辖区，在治理和数据保护方面需视为一次全新部署。 - [ ] **上市后监控反馈至变更评估。** 漂移警报、偏差发散、覆盖率上升以及险发报告都应被评估为重新评估的潜在触发因素，而不仅仅是作为运营指标。`[EU AI Act Art. 72]` - [ ] **监管变更受到监控并被指派跟进。** 指定专人在相关监管出版物（ICO 指南更新、FCA 出版物、EU AI Office 指南、PRA/FCA 模型风险管理更新）发布时进行阅读和总结。将识别出的新义务映射到此检查清单中并作为项目添加进去。 - [ ] **无论是否发生触发事件，均已安排年度审查。** 即使没有任何重大变更，也应每年审查一次完整的检查清单。审查记录需标明日期，记录审查者，并将结果（无需采取行动，或行动列表）归档。 - [ ] **已记录弃用和停用计划。** AI 系统将在何时以及在何种条件下被关闭或替换。关停后审计日志、数据和模型产出物将如何处理。保留义务在停用后依然有效。`[EU AI Act Art. 19]` ## 贡献 欢迎提交 PR。仅当某项目能实质性提升受监管 AI 部署的可辩护性时才予以添加。提议的项目应指明其旨在解决的监管义务或运营风险。请参阅 [CONTRIBUTING.md](CONTRIBUTING.md)。 ## 许可 CC BY 4.0。你可以复制、定制并重新发布此列表，但需注明归属于 [Aperintel](https://github.com/aperintel) 并提供指向标准版本的链接。

标签：AI治理, ProjectDiscovery, 人工智能, 数据保护, 用户模式Hook绕过, 部署检查清单, 防御加固