欧盟《人工智能法案》EU AI Act已经过了“纸面发布”阶段进入强制落地期。从 2024 年 8 月 1 日法案生效开始很多以前只存在于草案里的义务正在分阶段变成硬性要求。对于在一线写代码、搭模型、发版本的工程师来说现在最值得做的不是重新读一遍法案原文而是把法案要求翻译成一张可以照做的工程清单系统怎么登记、文档怎么沉淀、日志怎么留、人和系统怎么闭环。这篇文章先把 EU AI Act 的关键时间点和风险分层讲清楚再给出一份可以直接拿到项目组用的工程检查清单最后用登记表、模型卡片、推理日志三个模板收尾。如果你所在团队的 AI 产品会面向欧盟市场投放或者服务对象包含欧盟用户建议收藏这份清单。说明本文是工程视角的合规落地参考不构成法律意见。具体项目的适用义务请咨询法务或合规团队。1. 核心信息速览项目内容法案全称Regulation (EU) 2024/1689欧盟《人工智能法案》生效时间2024 年 8 月 1 日管辖逻辑在欧盟市场投放、投入使用或面向欧盟用户提供服务时适用该法案适用对象模型提供方、系统提供方、部署方、进口方、分销方、授权代表等风险分层禁止风险、高风险、有限风险、最低风险禁止条款生效2025 年 2 月 2 日起通用 AI 模型义务2025 年 8 月 2 日起高风险系统义务2026 年 8 月 2 日起部分场景到 2027 年 8 月 2 日对工程团队的要求系统登记、技术文档、数据治理、日志记录、透明性与人工监督、鲁棒性与安全性不遵守的后果按风险等级和违规行为设置罚款情节严重的处罚金额较高从工程角度看这个法案最核心的变化是AI 系统从“做出来能用”变成“做出来能证明安全”。证明的过程不是写一篇报告应付过去而是要在开发、部署、运营全流程里留下可审计的证据。这和传统软件工程里的质量体系、可观测性、事故复盘其实是一套方法论只是现在被监管要求强制固化了。2. 分阶段生效时间线EU AI Act 不是一次性全部生效而是按模块分批落地。工程团队需要先知道自己处在哪个时间窗口再决定优先级。时间节点主要适用内容工程团队动作2024 年 8 月 1 日法案正式生效进入过渡期启动 AI 系统盘点建立登记模板2025 年 2 月 2 日禁止类 AI 行为开始适用AI 素养要求开始适用排查系统是否触碰禁止项对团队做 AI 法规意识培训2025 年 8 月 2 日通用 AI 模型包括大型生成式模型相关义务开始适用模型卡片补全训练数据摘要、版权政策、透明度信息2026 年 8 月 2 日大多数高风险 AI 系统的完整义务开始适用高风险系统完成技术文档、日志、人工监督、鲁棒性测试2027 年 8 月 2 日部分高风险场景的适用时间涉及就业、教育、公共服务、执法等场景的系统完成合规改造这里要特别提醒很多团队觉得“高风险义务 2026 年才生效现在不用动”这是误解。高风险系统的技术文档、数据治理、日志记录这些能力不可能一晚上建起来。如果现在不开始做数据字典、不做版本追踪、不积累评估报告到 2026 年就会变成突击补材料质量和可信度都会打折扣。3. 风险分层是合规工作的起点EU AI Act 的核心是“按风险定责任”不是一刀切。所以工程团队第一步不是盲目做全套合规而是先判断自己的系统属于哪一层。风险等级典型场景举例核心义务禁止风险社会信用评分、利用弱势群体弱点、无差别抓取人脸、基于敏感特征的预测性执法等不允许在欧盟市场投放或使用高风险AI 用于招聘、员工管理、信贷评估、教育评判、关键基础设施、司法辅助等完整的技术文档、数据治理、日志、人工监督、鲁棒性测试、上市后监测有限风险聊天机器人、深度合成内容、情感识别系统等透明度义务如告知用户正在与 AI 交互最低风险垃圾邮件过滤、游戏 AI、普通内容推荐等适用较轻的义务鼓励遵循自愿行为准则判断风险层级的实操方法是先看接入方是谁再看模型输出影响什么决策最后看错误后果是否可能导致人身伤害、经济损害或基本权利受损。例如一个简历筛选系统如果被用于企业招聘很可能被归入高风险因为它的输出直接影响到求职者的就业机会一旦存在歧视或错误拒绝后果是具体且严重的。工程团队最好用一张统一的风险初判表记录每个系统的判断依据。这样当合规团队或法务提出疑问时能够快速解释“当时为什么把它归为这一层”。4. 工程师必须关注的六个核心约束如果把 EU AI Act 对工程的要求拆开可以看到大部分不是新概念而是把“合格软件应该做到的事”变成了强制要求。4.1 系统登记与生命周期记录每个 AI 系统要有明确的身份信息系统叫什么、模型版本是什么、部署在哪个环境、数据流向哪里、谁负责运维。这一步类似传统软件里的资产清单但需要包含 AI 特有的字段比如训练数据版本、模型评估报告、偏差测试结果。4.2 技术文档法律要求系统在上市或投入使用前准备技术文档目的是让监管机构或审计方能够评估系统是否符合要求。文档不是“README 加几句话”而是覆盖系统结构、开发过程、训练数据、评估方法、预期用途、安全措施等多个维度。实践中文档最好和代码仓库、实验记录放在一起管理这样能保证文档不是事后补写的。4.3 数据治理训练、验证、测试数据必须说明来源、范围和质量。需要重点检查数据是否有偏差、是否完整、是否经过合法采集。比如一个用于招聘的模型训练数据如果只包含某一类人群的简历模型很容易产生歧视性输出。所以数据治理不是法务的事而是数据工程师和算法工程师的本职。4.4 日志与可追溯性高风险系统要能够记录运行日志支持追溯输出结果。日志至少应包含触发时间、输入数据摘要或指纹、模型输出、置信度、是否触发人工复核、复核人是谁。工程团队在设计日志系统时要考虑留存周期、访问权限和日志防篡改不能只把日志写到 stdout 就完事。4.5 透明性与人工监督使用 AI 系统的人要获得必要的信息理解系统的能力和限制。比如让 HR 使用简历筛选 AI 时系统应说明它评估了哪些维度、置信度如何、哪些结果必须人工复核。必要时要设计人工干预机制确保人可以否决或修正 AI 的输出。4.6 鲁棒性、准确性与安全性系统在正常使用和异常输入情况下都能保持稳定。需要做对抗性测试、边界输入测试、数据漂移检测和异常输出监控。对于生成式模型还要关注幻觉问题和高危内容输出。这六个约束不是孤立的它们共同构成一个闭环登记是基础文档是证据数据是原材料日志是追溯透明和人工监督是兜底鲁棒性保证了整个系统不会轻易失效。5. 工程团队检查清单下面这份清单按“成熟度”组织适合直接拿到项目周会上逐条过一遍。不需要一次性全部完成但每一项都应该有负责人、时间点和证据文件。5.1 盘点 AI 资产先回答一个问题团队里现在到底有多少个 AI 系统很多公司的答案是“不完整”。这一步要覆盖自研模型、微调模型、调用第三方 API 的模型、嵌入在供应商系统里的模型。建议建立一张系统登记表至少包含系统名称、业务部门、部署区域、数据类型、模型来源、是否涉及欧盟用户。很多团队会发现自己对 AI 资产的掌握程度远低于预期。特别是那种“从开源仓库下载模型后内部用”的小工具如果没有登记最容易成为合规盲区。5.2 风险初判针对每个系统判断风险等级并记录判断依据。这里建议由一个 AI 负责人、法务、业务方共同评审而不是工程师自己下结论。原因是“是否影响基本权利”“是否属于特定领域”这类判断需要法律专业知识。风险初判的结果要留档。如果判断为高风险要立即启动完整的文档和测试流程如果判断为最低风险也要写清楚理由。5.3 数据治理检查对每个 AI 系统的训练数据和运行数据做一次体检数据来源是否合法是否有授权记录。数据是否脱敏是否包含敏感个人信息。数据是否存在明显的群体偏差。数据集的版本是否可追溯。数据更新机制是否明确。如果系统涉及个人信息处理还要同步评估是否符合 GDPR 的要求。EU AI Act 和 GDPR 是并行的AI 合规不等于数据合规两个体系都需要覆盖。5.4 模型开发与测试在模型开发阶段建立“发布门禁”定义明确的评估指标例如准确率、召回率、AUC、置信度校准误差。按业务场景设置通过阈值不通过不允许上线。做公平性测试至少覆盖性别、年龄、地域等常见维度。做鲁棒性测试包括噪声输入、缺失字段、边界值。对生成式模型做幻觉和有害内容测试。判断标准是评估结果能够复现并且可以追溯到具体的模型版本和数据集版本。如果别人拿到你的测试报告无法复现说明评估流程还不过关。5.5 部署与透明度配置部署环节要完成三件事第一把模型卡片和技术文档部署到团队内部知识库确保运营人员能够访问。第二配置日志记录确保每次推理都有完整记录。第三在用户交互界面配置透明度提示。比如聊天机器人要先说明“你是 AI”深度合成内容要加标注。如果系统是嵌入到第三方产品里的还需要向第三方提供必要的技术说明让下游能够履行自己的透明义务。5.6 上线后监控与人工监督系统上线不代表工作结束恰恰是监控工作的开始。需要监控的指标包括推理错误率、置信度漂移、输入数据分布变化、用户投诉数量、人工复核通过率。当模型置信度下降或出现异常输入模式时系统应能自动触发告警并转人工处理。人工监督要设计成可操作的流程而不是一句空话。至少要明确什么情况下人工必须介入、人工介入的超时上限是多少、人工否决 AI 输出后如何记录原因。5.7 审计准备把所有材料组织好形成一套可审计的文档包。包括系统登记表、风险初判记录、技术文档、数据字典、评估报告、日志留存策略、人工监督流程、事故响应预案。这里的关键不是“有没有文档”而是“文档能不能在三天内找齐”。建议把文档放在固定的目录或知识库并在每次版本迭代时同步更新。6. 写进代码登记表、模型卡片与日志模板以下是三个可以直接参考的模板。它们不是官方格式而是工程团队可以起步的基座。6.1 AI 系统登记表YAML 示例# ai_system_register.yaml version: 1.0 systems: - system_id: ATS-001 system_name: 简历初筛助手 deployment_status: production risk_classification: high-risk business_domain: human-resources provider: self-developed model_reference: cv-rerank/v1.3 deployment_region: EU involved_data_types: - resume text - recruitment feedback data_retention_days: 180 human_review_required: true last_assessment: 2025-06-20 owner: ai-platform-team这个模板解决“系统清单”问题。你可以继续补充字段比如训练数据版本、评估报告链接、部署环境列表、下游系统清单。6.2 模型事实卡模板模型事实卡的目的是让非技术人员也能快速理解模型的能力和边界。## 模型事实卡 | 字段 | 内容 | | --- | --- | | 系统标识 | ATS-001 | | 模型名称 | cv-rerank-v1.3 | | 模型类型 | 文本排序模型 | | 训练数据摘要 | 20 万份匿名简历语种为英语和德语 | | 训练数据来源 | 企业招聘系统历史数据已脱敏 | | 主要评估指标 | NDCG10准确率 | | 评估结果 | NDCG100.83 | | 已知限制 | 对非传统履历格式的解析效果不稳定 | | 预期用途 | 辅助 HR 对简历进行初筛排序 | | 非预期用途 | 不建议作为唯一决策依据 | | 人工监督机制 | 置信度低于 0.7 时强制人工复核 | | 日志留存 | 180 天存储于审计日志系统 | | 责任人 | 张三算法工程师 |6.3 推理日志记录示例Python这段代码展示如何把一次推理变成一条可审计的事件记录。核心思路是记录输入指纹、模型版本、输出结果、置信度、复核状态、时间戳。import hashlib import time import uuid class InferenceAuditEvent: def __init__(self, system_id, model_version, raw_input, decision, confidence, risk_level): self.event_id uuid.uuid4().hex self.system_id system_id self.model_version model_version self.input_hash hashlib.sha256( str(raw_input).encode(utf-8) ).hexdigest() self.decision decision self.confidence confidence self.risk_level risk_level self.review_required confidence 0.7 self.reviewed_by self.timestamp time.strftime( %Y-%m-%dT%H:%M:%SZ, time.gmtime() ) def to_dict(self): return { event_id: self.event_id, system_id: self.system_id, model_version: self.model_version, input_hash: self.input_hash, decision: self.decision, confidence: self.confidence, risk_level: self.risk_level, review_required: self.review_required, reviewed_by: self.reviewed_by, timestamp: self.timestamp, } # 示例调用 event InferenceAuditEvent( system_idATS-001, model_versioncv-rerank-v1.3, raw_inputcandidate resume text ..., decisionshortlist, confidence0.65, risk_levelhigh-risk, ) print(event.to_dict())实际接入时需要把这个事件对象写入结构化日志或专门的审计存储。建议不要只写到本地文件至少要落到有权限控制的日志服务里防止被普通运维人员修改。7. 模型提供方、部署方与应用开发者的责任边界EU AI Act 不是只约束“模型训练方”它对产业链上的不同角色分配了不同义务。工程团队需要先确认自己在链条里处于什么位置。角色典型场景主要义务关键动作模型提供方开发并发布开源或商用基础模型编写模型文档、训练数据摘要、透明信息必要时配合监管建立模型卡片和版本发布流程高风险系统提供方将模型集成到产品并投放欧盟市场大部分高风险义务由这一方承担完成技术文档、风险评估、质量体系部署方在自己业务中使用 AI 系统承担运行监控、人工监督、通知义务配置日志、监控告警、人工复核流程应用开发者调用第三方 API 构建应用履行部署者或系统提供方的相关义务评估供应商提供的信息补足自身义务有一个常见场景团队只是通过 API 调用一个通用大模型做内部工具没有对外发布产品也没有部署到欧盟用户业务中。这种情况下义务相对较轻但不能认为完全不受约束。如果 API 服务的提供方位于欧盟市场或者内部处理的数据涉及欧盟用户仍然要关注数据合规和透明度要求。另一个常见争议是“开源模型是否完全免责”。实际上开源模型在 EU AI Act 下有特定规定但开源不等于零义务。模型如果被集成到高风险系统那么系统提供方仍然要履行完整义务模型自身的开发方如果发布面向欧盟市场的模型也需要满足部分配套义务。简单说开源可以减轻开发方的部分负担但不会抹掉产业链上的全部责任。8. 与 GDPR、ISO 42001 的关系EU AI Act 并不是唯一需要关注的法规。对于面向欧盟用户的系统GDPR 仍然是并行的义务来源。AI 系统处理个人信息时两项法规都要评估。维度GDPREU AI Act关注对象个人数据AI 系统核心原则合法、正当、透明、目的限制等安全、透明、可追溯、人工监督关键动作数据保护影响评估风险评估、技术文档罚款风险高按风险分层设置ISO 42001 是国际标准化组织发布的 AI 管理体系标准提供了从组织层面建立 AI 治理框架的方法。虽然不是法律强制要求但很多团队会以它作为系统化落地的参照。简单说GDPR 管“数据怎么用”EU AI Act 管“AI 系统怎么做”ISO 42001 管“组织内如何形成持续合规的机制”。三者互补不要只做其中一个。9. 常见误区与排查方法误区实际情况工程团队建议法案只针对大型科技公司任何在欧盟市场投放 AI 产品或服务的企业都可能适用先做系统盘点别按公司规模判断我们只做内部工具不适用如果内部工具涉及欧盟用户数据或服务欧盟业务需要评估将所有 AI 系统纳入登记范围开源模型可以完全免责开源不能消除下游部署者义务记录模型来源在系统层面补足文档和测试风险判断交给法务就行风险评估需要技术输入法务无法独立完成技术团队提供系统能力和数据信息文档可以上线后补高风险系统的技术文档要求在上市前完成将文档纳入发布门禁日志记录只是技术细节日志是追溯和审计的核心证据建立结构化审计日志不要只写 stdout人工监督就是加一个“确认”按钮需要明确触发条件、介入流程、记录方式定义人工复核的触发阈值和反馈闭环实际排查时如果发现某个系统没有登记、没有评估报告、没有日志留存不要急着补文档先解决“当前系统是否触碰禁止条款”这类最高优先级问题然后再按风险等级依次补齐。10. 现在就可以开始的四步第一建立 AI 系统登记表。哪怕只有十个字段先把所有模型和业务场景列出来这一步没有成本但信息价值最高。第二对系统做风险初判。把自研模型、API 调用、嵌入第三方系统的情况全部过一遍确认哪些是高风险哪些是有限风险。拿不准的交给法务判断。第三补上模型事实卡。每个在用的模型都要回答三个问题训练数据是什么、能力边界在哪、错误后果由谁承担。模型事实卡不用很长但要真实。第四把日志和人工监督流程接上生产。每次推理至少留下事件 ID、模型版本、输入指纹、输出结果、置信度、复核状态六项信息。这一步做好了后面的审计和风险排查都有据可查。EU AI Act 给工程团队带来的不是“禁止做什么”而是“做的时候留下证据”。这和 DevOps 里强调的可观测性、审计日志、发布门禁是同一种思维方式只是现在它成了进入欧盟市场的门槛。尽早把这套工程化能力沉淀下来对产品出海、客户审计和内部质量提升都有实际帮助。接下来建议按业务优先级从最有风险的系统开始逐条过这份清单。 
长河君 · 2026/8/27 7:35:42 · 阅读 1.2k EU AI Act 落地指南：工程师的 AI 系统合规检查清单
欧盟《人工智能法案》EU AI Act已经过了“纸面发布”阶段进入强制落地期。从 2024 年 8 月 1 日法案生效开始很多以前只存在于草案里的义务正在分阶段变成硬性要求。对于在一线写代码、搭模型、发版本的工程师来说现在最值得做的不是重新读一遍法案原文而是把法案要求翻译成一张可以照做的工程清单系统怎么登记、文档怎么沉淀、日志怎么留、人和系统怎么闭环。这篇文章先把 EU AI Act 的关键时间点和风险分层讲清楚再给出一份可以直接拿到项目组用的工程检查清单最后用登记表、模型卡片、推理日志三个模板收尾。如果你所在团队的 AI 产品会面向欧盟市场投放或者服务对象包含欧盟用户建议收藏这份清单。说明本文是工程视角的合规落地参考不构成法律意见。具体项目的适用义务请咨询法务或合规团队。1. 核心信息速览项目内容法案全称Regulation (EU) 2024/1689欧盟《人工智能法案》生效时间2024 年 8 月 1 日管辖逻辑在欧盟市场投放、投入使用或面向欧盟用户提供服务时适用该法案适用对象模型提供方、系统提供方、部署方、进口方、分销方、授权代表等风险分层禁止风险、高风险、有限风险、最低风险禁止条款生效2025 年 2 月 2 日起通用 AI 模型义务2025 年 8 月 2 日起高风险系统义务2026 年 8 月 2 日起部分场景到 2027 年 8 月 2 日对工程团队的要求系统登记、技术文档、数据治理、日志记录、透明性与人工监督、鲁棒性与安全性不遵守的后果按风险等级和违规行为设置罚款情节严重的处罚金额较高从工程角度看这个法案最核心的变化是AI 系统从“做出来能用”变成“做出来能证明安全”。证明的过程不是写一篇报告应付过去而是要在开发、部署、运营全流程里留下可审计的证据。这和传统软件工程里的质量体系、可观测性、事故复盘其实是一套方法论只是现在被监管要求强制固化了。2. 分阶段生效时间线EU AI Act 不是一次性全部生效而是按模块分批落地。工程团队需要先知道自己处在哪个时间窗口再决定优先级。时间节点主要适用内容工程团队动作2024 年 8 月 1 日法案正式生效进入过渡期启动 AI 系统盘点建立登记模板2025 年 2 月 2 日禁止类 AI 行为开始适用AI 素养要求开始适用排查系统是否触碰禁止项对团队做 AI 法规意识培训2025 年 8 月 2 日通用 AI 模型包括大型生成式模型相关义务开始适用模型卡片补全训练数据摘要、版权政策、透明度信息2026 年 8 月 2 日大多数高风险 AI 系统的完整义务开始适用高风险系统完成技术文档、日志、人工监督、鲁棒性测试2027 年 8 月 2 日部分高风险场景的适用时间涉及就业、教育、公共服务、执法等场景的系统完成合规改造这里要特别提醒很多团队觉得“高风险义务 2026 年才生效现在不用动”这是误解。高风险系统的技术文档、数据治理、日志记录这些能力不可能一晚上建起来。如果现在不开始做数据字典、不做版本追踪、不积累评估报告到 2026 年就会变成突击补材料质量和可信度都会打折扣。3. 风险分层是合规工作的起点EU AI Act 的核心是“按风险定责任”不是一刀切。所以工程团队第一步不是盲目做全套合规而是先判断自己的系统属于哪一层。风险等级典型场景举例核心义务禁止风险社会信用评分、利用弱势群体弱点、无差别抓取人脸、基于敏感特征的预测性执法等不允许在欧盟市场投放或使用高风险AI 用于招聘、员工管理、信贷评估、教育评判、关键基础设施、司法辅助等完整的技术文档、数据治理、日志、人工监督、鲁棒性测试、上市后监测有限风险聊天机器人、深度合成内容、情感识别系统等透明度义务如告知用户正在与 AI 交互最低风险垃圾邮件过滤、游戏 AI、普通内容推荐等适用较轻的义务鼓励遵循自愿行为准则判断风险层级的实操方法是先看接入方是谁再看模型输出影响什么决策最后看错误后果是否可能导致人身伤害、经济损害或基本权利受损。例如一个简历筛选系统如果被用于企业招聘很可能被归入高风险因为它的输出直接影响到求职者的就业机会一旦存在歧视或错误拒绝后果是具体且严重的。工程团队最好用一张统一的风险初判表记录每个系统的判断依据。这样当合规团队或法务提出疑问时能够快速解释“当时为什么把它归为这一层”。4. 工程师必须关注的六个核心约束如果把 EU AI Act 对工程的要求拆开可以看到大部分不是新概念而是把“合格软件应该做到的事”变成了强制要求。4.1 系统登记与生命周期记录每个 AI 系统要有明确的身份信息系统叫什么、模型版本是什么、部署在哪个环境、数据流向哪里、谁负责运维。这一步类似传统软件里的资产清单但需要包含 AI 特有的字段比如训练数据版本、模型评估报告、偏差测试结果。4.2 技术文档法律要求系统在上市或投入使用前准备技术文档目的是让监管机构或审计方能够评估系统是否符合要求。文档不是“README 加几句话”而是覆盖系统结构、开发过程、训练数据、评估方法、预期用途、安全措施等多个维度。实践中文档最好和代码仓库、实验记录放在一起管理这样能保证文档不是事后补写的。4.3 数据治理训练、验证、测试数据必须说明来源、范围和质量。需要重点检查数据是否有偏差、是否完整、是否经过合法采集。比如一个用于招聘的模型训练数据如果只包含某一类人群的简历模型很容易产生歧视性输出。所以数据治理不是法务的事而是数据工程师和算法工程师的本职。4.4 日志与可追溯性高风险系统要能够记录运行日志支持追溯输出结果。日志至少应包含触发时间、输入数据摘要或指纹、模型输出、置信度、是否触发人工复核、复核人是谁。工程团队在设计日志系统时要考虑留存周期、访问权限和日志防篡改不能只把日志写到 stdout 就完事。4.5 透明性与人工监督使用 AI 系统的人要获得必要的信息理解系统的能力和限制。比如让 HR 使用简历筛选 AI 时系统应说明它评估了哪些维度、置信度如何、哪些结果必须人工复核。必要时要设计人工干预机制确保人可以否决或修正 AI 的输出。4.6 鲁棒性、准确性与安全性系统在正常使用和异常输入情况下都能保持稳定。需要做对抗性测试、边界输入测试、数据漂移检测和异常输出监控。对于生成式模型还要关注幻觉问题和高危内容输出。这六个约束不是孤立的它们共同构成一个闭环登记是基础文档是证据数据是原材料日志是追溯透明和人工监督是兜底鲁棒性保证了整个系统不会轻易失效。5. 工程团队检查清单下面这份清单按“成熟度”组织适合直接拿到项目周会上逐条过一遍。不需要一次性全部完成但每一项都应该有负责人、时间点和证据文件。5.1 盘点 AI 资产先回答一个问题团队里现在到底有多少个 AI 系统很多公司的答案是“不完整”。这一步要覆盖自研模型、微调模型、调用第三方 API 的模型、嵌入在供应商系统里的模型。建议建立一张系统登记表至少包含系统名称、业务部门、部署区域、数据类型、模型来源、是否涉及欧盟用户。很多团队会发现自己对 AI 资产的掌握程度远低于预期。特别是那种“从开源仓库下载模型后内部用”的小工具如果没有登记最容易成为合规盲区。5.2 风险初判针对每个系统判断风险等级并记录判断依据。这里建议由一个 AI 负责人、法务、业务方共同评审而不是工程师自己下结论。原因是“是否影响基本权利”“是否属于特定领域”这类判断需要法律专业知识。风险初判的结果要留档。如果判断为高风险要立即启动完整的文档和测试流程如果判断为最低风险也要写清楚理由。5.3 数据治理检查对每个 AI 系统的训练数据和运行数据做一次体检数据来源是否合法是否有授权记录。数据是否脱敏是否包含敏感个人信息。数据是否存在明显的群体偏差。数据集的版本是否可追溯。数据更新机制是否明确。如果系统涉及个人信息处理还要同步评估是否符合 GDPR 的要求。EU AI Act 和 GDPR 是并行的AI 合规不等于数据合规两个体系都需要覆盖。5.4 模型开发与测试在模型开发阶段建立“发布门禁”定义明确的评估指标例如准确率、召回率、AUC、置信度校准误差。按业务场景设置通过阈值不通过不允许上线。做公平性测试至少覆盖性别、年龄、地域等常见维度。做鲁棒性测试包括噪声输入、缺失字段、边界值。对生成式模型做幻觉和有害内容测试。判断标准是评估结果能够复现并且可以追溯到具体的模型版本和数据集版本。如果别人拿到你的测试报告无法复现说明评估流程还不过关。5.5 部署与透明度配置部署环节要完成三件事第一把模型卡片和技术文档部署到团队内部知识库确保运营人员能够访问。第二配置日志记录确保每次推理都有完整记录。第三在用户交互界面配置透明度提示。比如聊天机器人要先说明“你是 AI”深度合成内容要加标注。如果系统是嵌入到第三方产品里的还需要向第三方提供必要的技术说明让下游能够履行自己的透明义务。5.6 上线后监控与人工监督系统上线不代表工作结束恰恰是监控工作的开始。需要监控的指标包括推理错误率、置信度漂移、输入数据分布变化、用户投诉数量、人工复核通过率。当模型置信度下降或出现异常输入模式时系统应能自动触发告警并转人工处理。人工监督要设计成可操作的流程而不是一句空话。至少要明确什么情况下人工必须介入、人工介入的超时上限是多少、人工否决 AI 输出后如何记录原因。5.7 审计准备把所有材料组织好形成一套可审计的文档包。包括系统登记表、风险初判记录、技术文档、数据字典、评估报告、日志留存策略、人工监督流程、事故响应预案。这里的关键不是“有没有文档”而是“文档能不能在三天内找齐”。建议把文档放在固定的目录或知识库并在每次版本迭代时同步更新。6. 写进代码登记表、模型卡片与日志模板以下是三个可以直接参考的模板。它们不是官方格式而是工程团队可以起步的基座。6.1 AI 系统登记表YAML 示例# ai_system_register.yaml version: 1.0 systems: - system_id: ATS-001 system_name: 简历初筛助手 deployment_status: production risk_classification: high-risk business_domain: human-resources provider: self-developed model_reference: cv-rerank/v1.3 deployment_region: EU involved_data_types: - resume text - recruitment feedback data_retention_days: 180 human_review_required: true last_assessment: 2025-06-20 owner: ai-platform-team这个模板解决“系统清单”问题。你可以继续补充字段比如训练数据版本、评估报告链接、部署环境列表、下游系统清单。6.2 模型事实卡模板模型事实卡的目的是让非技术人员也能快速理解模型的能力和边界。## 模型事实卡 | 字段 | 内容 | | --- | --- | | 系统标识 | ATS-001 | | 模型名称 | cv-rerank-v1.3 | | 模型类型 | 文本排序模型 | | 训练数据摘要 | 20 万份匿名简历语种为英语和德语 | | 训练数据来源 | 企业招聘系统历史数据已脱敏 | | 主要评估指标 | NDCG10准确率 | | 评估结果 | NDCG100.83 | | 已知限制 | 对非传统履历格式的解析效果不稳定 | | 预期用途 | 辅助 HR 对简历进行初筛排序 | | 非预期用途 | 不建议作为唯一决策依据 | | 人工监督机制 | 置信度低于 0.7 时强制人工复核 | | 日志留存 | 180 天存储于审计日志系统 | | 责任人 | 张三算法工程师 |6.3 推理日志记录示例Python这段代码展示如何把一次推理变成一条可审计的事件记录。核心思路是记录输入指纹、模型版本、输出结果、置信度、复核状态、时间戳。import hashlib import time import uuid class InferenceAuditEvent: def __init__(self, system_id, model_version, raw_input, decision, confidence, risk_level): self.event_id uuid.uuid4().hex self.system_id system_id self.model_version model_version self.input_hash hashlib.sha256( str(raw_input).encode(utf-8) ).hexdigest() self.decision decision self.confidence confidence self.risk_level risk_level self.review_required confidence 0.7 self.reviewed_by self.timestamp time.strftime( %Y-%m-%dT%H:%M:%SZ, time.gmtime() ) def to_dict(self): return { event_id: self.event_id, system_id: self.system_id, model_version: self.model_version, input_hash: self.input_hash, decision: self.decision, confidence: self.confidence, risk_level: self.risk_level, review_required: self.review_required, reviewed_by: self.reviewed_by, timestamp: self.timestamp, } # 示例调用 event InferenceAuditEvent( system_idATS-001, model_versioncv-rerank-v1.3, raw_inputcandidate resume text ..., decisionshortlist, confidence0.65, risk_levelhigh-risk, ) print(event.to_dict())实际接入时需要把这个事件对象写入结构化日志或专门的审计存储。建议不要只写到本地文件至少要落到有权限控制的日志服务里防止被普通运维人员修改。7. 模型提供方、部署方与应用开发者的责任边界EU AI Act 不是只约束“模型训练方”它对产业链上的不同角色分配了不同义务。工程团队需要先确认自己在链条里处于什么位置。角色典型场景主要义务关键动作模型提供方开发并发布开源或商用基础模型编写模型文档、训练数据摘要、透明信息必要时配合监管建立模型卡片和版本发布流程高风险系统提供方将模型集成到产品并投放欧盟市场大部分高风险义务由这一方承担完成技术文档、风险评估、质量体系部署方在自己业务中使用 AI 系统承担运行监控、人工监督、通知义务配置日志、监控告警、人工复核流程应用开发者调用第三方 API 构建应用履行部署者或系统提供方的相关义务评估供应商提供的信息补足自身义务有一个常见场景团队只是通过 API 调用一个通用大模型做内部工具没有对外发布产品也没有部署到欧盟用户业务中。这种情况下义务相对较轻但不能认为完全不受约束。如果 API 服务的提供方位于欧盟市场或者内部处理的数据涉及欧盟用户仍然要关注数据合规和透明度要求。另一个常见争议是“开源模型是否完全免责”。实际上开源模型在 EU AI Act 下有特定规定但开源不等于零义务。模型如果被集成到高风险系统那么系统提供方仍然要履行完整义务模型自身的开发方如果发布面向欧盟市场的模型也需要满足部分配套义务。简单说开源可以减轻开发方的部分负担但不会抹掉产业链上的全部责任。8. 与 GDPR、ISO 42001 的关系EU AI Act 并不是唯一需要关注的法规。对于面向欧盟用户的系统GDPR 仍然是并行的义务来源。AI 系统处理个人信息时两项法规都要评估。维度GDPREU AI Act关注对象个人数据AI 系统核心原则合法、正当、透明、目的限制等安全、透明、可追溯、人工监督关键动作数据保护影响评估风险评估、技术文档罚款风险高按风险分层设置ISO 42001 是国际标准化组织发布的 AI 管理体系标准提供了从组织层面建立 AI 治理框架的方法。虽然不是法律强制要求但很多团队会以它作为系统化落地的参照。简单说GDPR 管“数据怎么用”EU AI Act 管“AI 系统怎么做”ISO 42001 管“组织内如何形成持续合规的机制”。三者互补不要只做其中一个。9. 常见误区与排查方法误区实际情况工程团队建议法案只针对大型科技公司任何在欧盟市场投放 AI 产品或服务的企业都可能适用先做系统盘点别按公司规模判断我们只做内部工具不适用如果内部工具涉及欧盟用户数据或服务欧盟业务需要评估将所有 AI 系统纳入登记范围开源模型可以完全免责开源不能消除下游部署者义务记录模型来源在系统层面补足文档和测试风险判断交给法务就行风险评估需要技术输入法务无法独立完成技术团队提供系统能力和数据信息文档可以上线后补高风险系统的技术文档要求在上市前完成将文档纳入发布门禁日志记录只是技术细节日志是追溯和审计的核心证据建立结构化审计日志不要只写 stdout人工监督就是加一个“确认”按钮需要明确触发条件、介入流程、记录方式定义人工复核的触发阈值和反馈闭环实际排查时如果发现某个系统没有登记、没有评估报告、没有日志留存不要急着补文档先解决“当前系统是否触碰禁止条款”这类最高优先级问题然后再按风险等级依次补齐。10. 现在就可以开始的四步第一建立 AI 系统登记表。哪怕只有十个字段先把所有模型和业务场景列出来这一步没有成本但信息价值最高。第二对系统做风险初判。把自研模型、API 调用、嵌入第三方系统的情况全部过一遍确认哪些是高风险哪些是有限风险。拿不准的交给法务判断。第三补上模型事实卡。每个在用的模型都要回答三个问题训练数据是什么、能力边界在哪、错误后果由谁承担。模型事实卡不用很长但要真实。第四把日志和人工监督流程接上生产。每次推理至少留下事件 ID、模型版本、输入指纹、输出结果、置信度、复核状态六项信息。这一步做好了后面的审计和风险排查都有据可查。EU AI Act 给工程团队带来的不是“禁止做什么”而是“做的时候留下证据”。这和 DevOps 里强调的可观测性、审计日志、发布门禁是同一种思维方式只是现在它成了进入欧盟市场的门槛。尽早把这套工程化能力沉淀下来对产品出海、客户审计和内部质量提升都有实际帮助。接下来建议按业务优先级从最有风险的系统开始逐条过这份清单。