2026 年 8 月，EU AI Act 相关义务进入更实际的执行窗口，开发团队不能再把它当成“欧洲法务新闻”。无论你是一家模型公司、SaaS 开发者，还是把大模型接入内部流程的企业，透明度、日志、数据来源、用户告知和供应商责任都会逐渐变成产品需求。
很多工程团队对合规的第一反应是“让法务写文档”。这当然需要，但远远不够。AI 产品的透明度不是一份 PDF 能解决的，它需要系统在运行时记录事实：哪个模型处理了哪个任务，提示模板是哪一版，是否调用了工具，用户是否知道自己在和 AI 交互，生成内容是否被标识，风险事件是否可追溯。
换句话说，AI 合规正在从政策层进入架构层。
先分清角色
EU AI Act 的影响取决于你的角色。开发团队至少要区分三类身份：
| 身份 | 典型例子 | 主要责任 |
|---|---|---|
| model provider | 训练或发布通用模型的公司 | 模型文档、风险评估、训练数据摘要 |
| deployer | 把 AI 系统提供给用户的应用方 | 用户告知、日志、人工监督、风险控制 |
| downstream integrator | 在业务流程中集成第三方 AI 的团队 | 供应商审查、场景分类、数据治理 |
很多 SaaS 团队不是模型 provider，但一定是 deployer。你调用第三方 API 并不意味着责任消失。用户看到的是你的产品，数据从你的系统流出，AI 输出影响你的业务流程。因此，工程上必须能回答：这个功能在哪里用了 AI，用的是什么模型，用户是否知情，错误时谁负责。
资产清单是第一步
不要一上来就写复杂政策。先建立 AI asset inventory：
feature: "customer-support-summary"
owner: "support-platform"
model_provider: "openai"
model_name: "gpt-5-class"
prompt_template: "support-summary-v4"
data_categories:
- customer-message
- order-status
user_visible: true
automated_decision: false
eu_users: true
risk_level: "limited"
logging:
trace: true
retention_days: 90这份清单不需要一开始完美，但必须存在。没有清单，团队甚至不知道哪些功能需要用户告知，哪些功能涉及敏感数据，哪些模型版本需要重新评估。
透明度不是弹窗
很多产品会把透明度理解成“加一句由 AI 生成”。这只是最浅的一层。真正有用的透明度包括：
- 用户是否知道自己正在与 AI 系统交互。
- AI 输出是否影响重要决策。
- 用户能否请求人工复核。
- 生成内容是否被标识或记录来源。
- 系统能否解释某次输出使用了哪个模型和版本。
对于低风险场景，比如草稿改写和客服摘要，简单告知加反馈入口可能足够。对于招聘、信贷、教育、医疗或员工管理等高影响场景，透明度必须和人工监督、日志留存、偏差评估绑定。
日志架构要重做
传统应用日志关心请求、响应、错误码和耗时。AI 系统还需要记录推理上下文。一个合理的 AI trace 至少包括：
{
"trace_id": "ai_20260805_001",
"feature": "support-summary",
"model": "provider-model-version",
"prompt_version": "support-summary-v4",
"input_hash": "sha256:...",
"output_hash": "sha256:...",
"tool_calls": ["fetch_order", "fetch_refund_policy"],
"safety_decision": "allowed",
"human_review": false,
"created_at": "2026-08-05T09:30:00+08:00"
}注意这里用 hash 而不是默认保存全文。合规和隐私之间有张力：你需要可审计，但不能把用户敏感内容无边界复制到日志系统。常见做法是分层保存：普通 trace 记录摘要和 hash，高风险或用户申诉场景通过受控权限读取原始内容。
生成内容标识
生成内容标识会影响产品体验，也会影响后续责任。对于面向外部用户的文本、图片、音频和视频，团队要明确：
- 哪些内容必须显示 AI 标识。
- 标识是在编辑器内、发布页还是元数据中。
- 用户修改后是否仍保留标识。
- 第三方导出时是否带上来源信息。
最容易被忽略的是“AI 辅助修改”。如果用户上传一段文案，系统只是帮他润色，是否需要标识？这取决于场景和法规解释，但工程上至少要能记录处理链路。否则将来出现争议，团队无法说明内容是否由模型生成或显著修改。
供应商管理进入代码路径
AI 供应商不再只是采购合同里的名字，它会出现在代码、日志和风险控制里。建议把 provider metadata 做成配置，而不是散落在业务代码中：
export const aiProviders = {
primaryChat: {
provider: "vendor-a",
model: "frontier-chat-2026-08",
dataRetention: "zero-retention",
region: "eu",
fallback: "vendor-b-safe-model",
},
};这样做有三个好处。第一，模型迁移时可追踪。第二，事故排查时能快速定位影响范围。第三，面对审计时能导出供应商和模型版本清单。
高风险功能要有人工监督
不是所有 AI 功能都需要同等强度治理。关键是识别高风险流程。只要 AI 输出会影响人的机会、权益、价格、访问权限或重要资源分配，就不能只靠自动化。
工程上可以实现三种模式：
| 模式 | 适用场景 | 机制 |
|---|---|---|
| human-in-the-loop | 高影响决策 | 人必须确认 |
| human-on-the-loop | 中风险自动化 | 人抽样监督 |
| human-after-the-loop | 低风险内容 | 用户反馈和事后纠错 |
不要把“人工监督”写成文档口号。系统必须有实际按钮、队列、权限和 SLA。比如客服 AI 建议退款，人工确认按钮、理由记录和审批日志都应该是产品功能。
对开发流程的影响
AI Act 类规则会改变开发流程。过去一个 AI 功能的上线清单可能是“能调用模型、效果不错、成本可接受”。现在至少要加上：
- 是否登记到 AI asset inventory。
- 是否有模型和 prompt 版本。
- 是否完成数据分类。
- 是否显示用户告知。
- 是否有安全和内容过滤。
- 是否记录 trace。
- 是否支持人工复核或用户申诉。
- 是否有供应商退出方案。
这听起来复杂，但可以平台化。最差的做法是每个业务团队自己写一套 AI 调用封装。更好的做法是建立统一 AI gateway，把日志、告知、安全检查、成本统计和供应商路由放在一层。
一个最小 AI gateway
AI gateway 不需要一开始很重。第一版可以只做四件事：
1. 强制传入 feature 和 owner
2. 统一记录 model、prompt_version、trace_id
3. 统一调用输入和输出 safety check
4. 统一暴露用户反馈和人工复核入口后续再加入区域路由、供应商降级、成本预算和策略版本。关键是从第一天开始让 AI 调用可见。看不见的 AI 调用，无法治理。
结论
EU AI Act 对开发者最直接的提醒是：AI 产品不能再只有“调用模型”的代码。它还需要透明度、来源、日志、风险控制和人工监督这些基础设施。法务可以解释规则，但工程系统必须保存事实。
未来优秀的 AI 产品团队，会把合规能力做成开发平台的一部分：新功能接入同一个 AI gateway，自动继承日志、告知、安全检查和供应商元数据。这样既能降低法规风险，也能提高生产可维护性。透明度不是拖慢创新的外壳，它会成为 AI 应用能否长期运行的底座。
参考来源：欧盟委员会关于 AI Act 的官方说明、欧盟 AI Office 对通用 AI 模型规则的说明，以及 2026 年 8 月产品发布检索中围绕透明度义务和企业 AI 治理的讨论。