Back to blog
    eu-ai-actarticle-10article-11compliancedata-preparation

    欧盟《人工智能法案》第 10 条 vs 第 11 条:数据团队需要知道的事

    详细对比欧盟《人工智能法案》第 10 条与第 11 条,这是 AI 训练数据治理、文档记录与合规方面最关键的两项条款。

    Edward Xi Yang

    如果你的组织在欧盟境内构建或部署高风险 AI 系统,法案中有两条会直接决定你的数据团队怎么干活:第 10 条(数据与数据治理)和第 11 条(技术文档)。两者相关但各有分工,把它们混为一谈就会留下合规缺口。

    本文拆解每一条各自要求什么、谁来负责,以及它们在实际操作中如何咬合。

    第 10 条:数据与数据治理

    第 10 条管的是准备训练数据的过程。它规定了高风险 AI 系统的训练集、验证集和测试集必须如何管理。

    它要求什么

    数据治理实践,涵盖:

    • 数据采集与数据来源方面的设计决策
    • 数据准备操作(清洗、标注、聚合)
    • 相关性与代表性评估
    • 潜在偏见的检查
    • 数据缺口或不足之处的识别

    数据质量标准,包括:

    • 训练数据必须具备相关性、足够的代表性,并尽可能不含错误
    • 数据集必须与该 AI 系统的预期用途相匹配
    • 其统计特性必须被理解并记录在案

    偏见检查:

    • 必须检查数据集中可能导致歧视性结果的偏见
    • 一旦识别出偏见,必须采取适当措施加以处理
    • 检查过程本身也必须被记录下来

    谁来负责

    第 10 条的义务落在高风险 AI 系统的提供者身上,也就是开发或委托开发该系统并将其投放市场的主体。落到实处,指的就是数据团队、机器学习工程师,以及他们的管理层。

    实际的难点

    第 10 条要求你的数据准备过程可记录、可审计。大多数企业卡在这里,原因并不是他们没做数据清洗或偏见检查,而是这些步骤散落在各处的脚本、notebook 和临时流程里,没有一份统一的记录。

    第 11 条:技术文档

    第 11 条管的是产出,也就是你必须为每一个高风险 AI 系统编制并持续维护的文档。义务本身写在第 11 条,具体要写哪些内容则由它所援引的附件 IV 规定。

    它要求什么

    按照附件 IV,技术文档必须包含:

    • 总体描述:该 AI 系统、其预期用途,以及提供者信息
    • 系统组成部分的详细描述:算法、数据、训练过程与设计决策
    • 训练数据相关信息:数据来源、范围、主要特征、采集方法、标注流程,以及数据清洗与准备方法
    • 验证与测试流程:指标、测试结果与性能基准
    • 风险管理措施:已识别的风险及缓解步骤
    • 监控与更新计划:部署后的监控方式

    谁来负责

    与第 10 条相同,仍是提供者。但第 11 条的文档还必须在市场监管机构提出要求时可供其查阅。这意味着文档必须条理清楚、内容完整、随时可取,而不是埋在团队 wiki 里或散落在一堆 Git 提交中。

    实际的难点

    第 11 条要求你拿出一份连贯的文档(或一套文档),描述整个 AI 系统,包括训练数据的来龙去脉。如果你的数据流水线是一串彼此不通的工具,事后再把这份文档拼出来既昂贵又容易出错。

    两者如何咬合

    可以把第 10 条理解为过程要求,把第 11 条理解为报告要求。两者互补:

    维度第 10 条第 11 条
    关注点你如何准备数据你就此记录了什么
    范围数据治理实践完整的系统技术文档(附件 IV)
    时间开发过程中贯穿整个生命周期持续维护
    受众内部团队监管机构与主管部门
    核心产出受治理的数据流水线技术文档包

    第 10 条告诉你数据流水线必须做到什么,第 11 条告诉你必须能证明它确实做到了。

    大多数企业都有的那道缺口

    典型的企业 AI 流水线在第 10 条上大体是及格的:团队确实会清洗数据、检查偏见、验证质量。缺的是与第 11 条之间的那根连线,也就是能证明这些步骤发生过的文档:用了哪些数据、由谁执行、得到了什么结果。

    这道缺口之所以存在,是因为多数数据流水线由互不连通的工具拼成:

    1. 数据摄入在一个工具里完成(Docling、Unstructured.io、自研解析器)
    2. 清洗在 Python 脚本或 notebook 里完成
    3. 标注在 Label Studio 或 Prodigy 里完成
    4. 质量评分在 Cleanlab 或自研代码里完成
    5. 导出又是另一个脚本

    每跨过一个边界,审计链路就断一次。摄入工具不知道清洗脚本做了什么,标注工具不知道清洗阶段筛掉了哪些内容,质量评分工具也不知道自己正在评估的数据最初从哪里来。

    合规的流水线长什么样

    要同时满足第 10 条和第 11 条,一条数据流水线需要具备:

    1. 统一日志:所有阶段的每一次操作都记录进同一份审计日志
    2. 操作者归属:每一步由谁执行或审批,并带时间戳
    3. 数据血缘:任何一条输出记录都能穿过每一次变换,追溯回它最初的来源
    4. 质量指标:自动记录质量分数、错误率与偏见评估结果
    5. 导出能力:一键生成符合第 11 条所援引的附件 IV 内容要求的文档

    这本质上是架构问题,而不是事后加装的合规模块。像 Ertas Data Suite 这样在单一系统内处理完整流水线的平台,会把这份文档作为日常运行的副产品自然产出,因为所有阶段共享同一套日志基础设施。

    你的数据团队现在该做什么

    1. 审查现有流水线的第 10 条缺口:偏见检查有记录吗?数据治理实践写下来了吗?
    2. 评估第 11 条的准备度:如果今天就要交,你能为自己的 AI 系统拿出完整的技术文档吗?
    3. 找出血缘断点:在你目前的工具链里,审计链路是在哪里断掉的?
    4. 为 2026 年 8 月做好准备:把合规能力建进新的流水线,而不是回过头去改造旧的

    执法期限正在逼近。从一开始就把文档能力建进去,成本只是事后重建的一个零头。

    就本文向 AI 提问

    Turn unstructured data into AI-ready datasets — without it leaving the building.

    On-premise data preparation with full audit trail. No data egress. No fragmented toolchains. EU AI Act Article 30 compliance built in.

    Keep reading