欧盟AI法案进入下一阶段：企业AI应用需要补齐哪些治理能力？

文章摘要

随着欧盟AI法案进入新的实施阶段，企业AI项目不能再把合规理解为“在页面上加一句AI生成提示”。OpenAI于2026年7月31日公开说明其对通用人工智能模型行为准则和AI生成内容透明度行为准则的支持，并再次强调安全评测、风险治理、来源标识、事件响应和持续更新。对于使用第三方大模型构建客服、知识库、Agent和内容生成系统的企业而言，模型提供商承担一部分责任，但应用部署方仍需建立风险分级、数据治理、人工监督、日志审计、内容来源和供应链管理。本文从工程视角给出一套可落地的治理清单。

一、企业最容易产生的误解

很多团队认为：

模型来自大型云厂商
→ 模型提供商已经合规
→ 自己的AI应用自然合规

这个推理并不成立。

企业在模型之上仍然决定：

• 用什么业务数据；
• 向哪些用户开放；
• 是否自动作出决策；
• 是否调用高风险工具；
• 是否保留用户输入；
• 如何处理错误答案；
• 是否标识AI生成内容；
• 出现事故后如何响应。

因此，模型治理和应用治理必须拆开：

模型提供商治理
＋应用部署方治理
＋业务流程治理

二、先建立AI用例清单

企业无法治理自己都不知道存在的AI应用。

建议建立统一登记表：

application_id
application_name
business_owner
technical_owner
model_provider
model_name
business_purpose
input_data_type
output_destination
user_group
automation_level
risk_level
human_review
retention_policy
launch_status

重点盘点以下“影子AI”：

• 员工自行购买的AI工具；
• 浏览器插件；
• 嵌入IDE的代码助手；
• 部门自行搭建的RAG；
• 通过API接入的内容生成服务；
• 没有登记的自动化Agent；
• 使用个人账号处理企业资料的工具。

如果企业只治理正式立项系统，而忽略员工和部门级工具，真实风险面仍然不可见。

三、按业务影响进行风险分级

可以先采用四级分类。

L1：辅助型

例如：

• 文案润色；
• 会议摘要；
• 代码解释；
• 内部搜索；
• 图片草图。

特点：

AI只提供建议
人类决定是否采用
错误影响有限

L2：业务支持型

例如：

• 客服答复建议；
• 售前方案草稿；
• 合同条款提取；
• 报告分析；
• 营销内容生成。

需要：

• 来源引用；
• 人工复核；
• 输出审核；
• 数据权限；
• 版本追踪。

L3：业务执行型

例如：

• 自动创建工单；
• 自动发送邮件；
• 修改客户信息；
• 自动审批建议；
• 自动调用内部系统。

需要增加：

• 工具白名单；
• 参数校验；
• 幂等控制；
• 操作审批；
• 完整审计；
• 回滚能力。

L4：高影响型

例如涉及：

• 招聘筛选；
• 信贷判断；
• 医疗建议；
• 员工绩效；
• 公共服务资格；
• 生物识别；
• 安全关键控制。

这类应用不能套用普通聊天机器人的治理方式，应由法务、合规、安全、业务和技术共同评估。

四、建立数据输入边界

企业AI系统经常同时处理：

公开信息
内部信息
商业秘密
个人信息
敏感个人信息
客户数据
第三方授权数据

建议对输入数据分级：

在调用模型前增加数据策略：

输入识别
→ 数据分类
→ 敏感字段脱敏
→ Provider策略选择
→ 是否允许发送

不要把所有模型Provider视为同一数据处理环境。

五、对输出建立透明度和来源机制

企业AI输出至少需要回答三个问题：

这是AI生成的吗？
依据是什么？
谁对最终结果负责？

1. AI标识

面向外部用户的自动生成内容，可根据场景增加：

• “由AI辅助生成”；
• “请核对关键信息”；
• “最终决定由人工完成”；
• 生成时间和模型版本。

2. 来源引用

RAG和研究类应用应保留：

document_id
version
section
retrieved_at
citation_id

3. 内容来源证明

图片、音频和视频场景需要考虑：

• Content Credentials；
• C2PA元数据；
• 水印信号；
• 编辑历史；
• 原始文件保留。

需要认识到：

单一水印或元数据
≠ 永久可靠证明

元数据可能丢失，水印也可能受转码影响，因此更适合采用多层来源证明。

六、人工监督不能只写在制度里

“重要结果需要人工审核”是一句常见制度条款，但很多系统没有真正实现。

有效的人工监督必须提供：

• AI建议与原始证据；
• 风险提示；
• 不确定项；
• 可编辑结果；
• 批准、拒绝和退回按钮；
• 审核人身份；
• 审核时间；
• 修改前后差异；
• 最终责任归属。

错误设计：

AI自动执行
→ 事后让人工查看日志

正确设计：

AI提出建议
→ 风险分级
→ 高风险进入审批
→ 审批通过后执行

七、建立模型和供应商台账

每个AI应用应记录：

provider
model
model_version
region
retention_policy
training_policy
data_residency
security_certification
subprocessors
contract_version
fallback_provider

模型升级不能自动等同于普通依赖升级。

因为模型版本变化可能影响：

• 内容安全；
• 输出风格；
• 工具选择；
• 拒答行为；
• 结构化输出；
• 成本；
• 延迟；
• 已有评测基线。

建议采用：

新模型影子测试
→ 回归评测
→ 小流量灰度
→ 业务确认
→ 全量切换

八、上线前需要什么评测

至少覆盖五类评测。

1. 任务质量

• 正确率；
• 完整性；
• 任务成功率；
• 引用准确率。

2. 安全性

• Prompt Injection；
• 越权访问；
• 敏感数据泄露；
• 有害内容；
• 工具滥用。

3. 稳定性

• 超时；
• 429；
• 结构化输出失败；
• 工具重复调用；
• 流式中断。

4. 公平性和偏差

针对可能影响个人权益的用例，检查不同群体之间的结果差异。

5. 人工可控性

• 是否可以拒绝AI建议；
• 是否可以转人工；
• 是否可以撤销操作；
• 是否可以追踪责任。

九、日志审计应该记录什么

建议形成统一AI审计事件：

{
  "requestId": "R1001",
  "applicationId": "APP-CRM-01",
  "tenantId": "T001",
  "userIdHash": "...",
  "model": "model-name",
  "promptVersion": "v12",
  "policyVersion": "v5",
  "inputClassification": "INTERNAL",
  "tools": ["query-order"],
  "humanReview": true,
  "resultStatus": "APPROVED",
  "createdAt": "2026-08-02T06:30:00Z"
}

不要默认记录完整Prompt和完整个人信息。

审计需要满足：

可追踪
＋最小化
＋访问受控
＋保留期明确

十、建立AI事件响应流程

需要定义哪些情况属于AI事件：

• 敏感数据泄露；
• 跨租户访问；
• 高风险工具误执行；
• 大规模错误答案；
• 不当内容生成；
• 模型供应商安全事件；
• 来源标识失效；
• 费用异常增长。

响应流程：

发现
→ 分级
→ 限流或停用
→ 保留证据
→ 影响分析
→ 通知责任人
→ 修复
→ 复盘
→ 更新评测集

AI系统必须支持快速关闭：

• 某个模型；
• 某个工具；
• 某个租户；
• 某类输入；
• 某个Prompt版本；
• 自动执行能力。

十一、企业可以立即执行的治理清单

□ 建立AI应用登记表
□ 划分风险等级
□ 明确业务负责人和技术负责人
□ 建立数据输入分类
□ 核对模型供应商数据条款
□ 对外输出增加AI标识
□ RAG结果保留来源版本
□ 高风险动作增加人工审批
□ 建立红队和回归测试集
□ 记录模型、Prompt和策略版本
□ 建立AI事件响应流程
□ 提供模型和工具紧急停用开关

十二、技术团队的实际落地顺序

推荐先做六件事：

统一AI网关
→ 身份与租户上下文
→ 数据分类和脱敏
→ 输出来源与审核
→ 评测与灰度
→ 审计和事件响应

不要一开始就试图完成一份非常长的“AI合规平台”，却没有控制真实调用链。

总结

欧盟AI治理进入下一阶段，对企业最大的提醒不是增加更多法律术语，而是把治理要求转化为可执行系统能力：

知道哪些AI在运行
知道处理了什么数据
知道模型输出依据什么
知道谁批准了结果
知道出了问题如何停用和追踪

模型供应商提供安全和透明度基础，企业仍需对自己的业务数据、自动化动作、用户影响和最终决策负责。

延伸阅读

如果你正在关注企业级AI应用、RAG、Agent、MCP与安全治理，欢迎访问 智元界：

https://www.zyentor.com/

智元界将持续分享可运行的技术实战、架构设计、问题排查与企业应用案例。