EU AI Act 2026 年 8 月节点与 AI 生成代码：开发团队现在要准备的文档

2026 年 8 月 2 日，EU AI Act 的透明度条款进入可执行阶段。据 PYMNTS 的报道，随着这一步落地，合规负担从「AI 开发者」向「部署客户侧 AI 系统的银行、保险与支付公司」转移。Holland & Knight 的分析也指出，在美国运营高风险 AI 系统的企业需要留意 8 月 2 日这个节点（Article 6(1) 除外，适用 2027 年 8 月）。对开发团队来说，问题会变得非常具体：Annex III 的高风险认定标准、AI 生成内容的透明度义务、以及多 Agent 流水线如何满足审计轨迹的要求。需要强调的是：本文讨论的是工程侧的文档与记录实践，不构成法律意见；具体合规判断请以官方文本与专业法律意见为准。

一、8 月 2 日到底改变了什么

据公开分析，EU AI Act 自 2025 年 2 月起分阶段实施，多数剩余条款于 2026 年 8 月 2 日生效，其中包括 Annex III 高风险系统的相关要求、AI 生成内容的透明度义务，以及更积极的执法权力（Article 6(1) 适用 2027 年 8 月）。对开发团队而言，关键变化在于责任的落点：不再只是「模型提供方」需要说明，使用这些模型构建并部署系统的团队也需要能够说明——你用了什么、做了什么验证、谁在什么时候批准了什么。换句话说，过去很多团队「心里有数」的部分，现在需要变成「拿得出手的记录」。

// An AI bill of materials: which models and prompts produced which artifacts.
// Generate it from the repository; do not hand-write it after the fact.
type AiBom = {
  artifact: string;
  generatedWith: { vendor: string; model: string; version: string }[];
  promptHashes: string[];   // hashes, so review does not leak prompts
  humanReviewedBy: string[];
  reviewedAt: string;
};

审计问的不是你的模型多强，而是你的记录多全

二、AI 生成代码会让系统「变成高风险」吗？

这是开发者最关心、也最容易误解的一点。按目前公开的解读，高风险分类通常取决于系统的用途是否落在 Annex III 的类别中，而不是取决于「代码是不是 AI 生成的」这一事实本身。也就是说，用 AI 写代码并不自动把系统抬升为高风险；但如果这个系统的用途本身属于高风险类别，那么无论代码由谁编写，相关义务都可能适用。因此在工程上，正确的问题不是「我们用了 AI 吗」，而是「这个系统的用途落在哪个类别里，以及我们能否证明我们对它的行为有足够的控制与记录」。

# Record AI assistance where it is provable and hard to lose: the commit.
git commit -m "feat: retry policy for webhook delivery

Assisted-by: claude-code/claude-sonnet-5
Reviewed-by: [email protected]
Prompt-Hash: sha256:9f2c...c41"

# Trailers survive rebases better than a wiki page nobody updates.

三、审计真正会要的三类材料

把「合规」翻译成工程语言，其实就是要三类东西。第一类是来源与版本：每个产物由哪个厂商的哪个模型、哪个版本生成，提示词是否可以以哈希形式留痕。第二类是人审与批准：谁在什么时候看过、批准了什么；高风险的自动化动作是否有人类签核。第三类是行为轨迹：Agent 做了什么动作、基于什么输入、是否在行动前经过批准。这三类材料都不需要「重新发明工作流」——它们都可以从你已经有的东西里生成：提交记录、模型注册表、以及 Agent 的执行日志。

// Pin the model. 'Latest' is not a version you can describe to a regulator,
// and it is not a version you can debug either.
const MODEL_REGISTRY = {
  "mid-sonnet":  { vendor: "Anthropic", released: "2026-06", contextK: 1000 },
  "budget-flash": { vendor: "Google",   released: "2026-05", contextK: 1000 },
} as const;

export function resolveModel(name: keyof typeof MODEL_REGISTRY) {
  const model = MODEL_REGISTRY[name];
  if (!model) throw new Error("unpinned model: " + name);
  return model;
}

把 AI 物料清单和 SBOM 放在一起

四、多 Agent 流水线的审计轨迹怎么留

多 Agent 流水线最容易在审计时露怯，因为一次任务可能跨多个 Agent、多个模型、多次工具调用。可落地的做法是把每次「Agent 决策」记成一条结构化记录：traceId、哪个 Agent、执行了什么动作、输入哈希、是否经过人类批准、批准人是谁、用的哪个模型、发生在什么时间。有了这一层，你才能回答审计的问题——「这个改动是谁提出的、谁批准的、依据是什么」。另外要养成一个习惯：模型要「钉版本」。把「latest」当作版本，既无法向监管描述，也无法在出问题时复现。

// One span per agent decision: who acted, with what, on whose behalf, and
// whether a human signed off before the action reached production.
type AgentDecision = {
  traceId: string;
  agent: string;
  action: string;          // "open_pr" | "migrate" | "delete"
  inputsHash: string;
  humanApproved: boolean;
  approvedBy?: string;
  model: string;
  ts: string;
};

export function record(d: AgentDecision) {
  db.decisions.insert(d);
}

五、落地代码：从 AI 物料清单到发布清单

第一段定义 AI 物料清单（AI-BOM）：产物、生成它的模型与版本、提示词哈希、以及人类评审人。第二段把 AI 参与记录在提交里——用 trailer 记录模型与评审人，因为 trailer 比 Wiki 页面更抗 rebase。第三段是模型注册表，强制「钉版本」，遇到未注册的模型直接报错。第四段是 Agent 决策记录的结构，涵盖 traceId、动作、输入哈希与人类批准信息。第五段演示如何从仓库里已有的信息生成一份随版本发布的合规清单，并提醒把它和 SBOM 放在一起，而不是塞进一个叫 legal 的文件夹。

# Emit a per-release compliance manifest from artifacts you already have.
# Keep it beside the SBOM, not in a folder named legal.
{
  "release": "$(git rev-parse --short HEAD)",
  "ai_assisted_commits": $(git log --format=%B | grep -c 'Assisted-by:' || true),
  "models_referenced": $(grep -rhoE 'claude-[a-z0-9.-]+' . | sort -u | tr '\n' ',' ),
  "generated_at": "$(date -u +%FT%TZ)"
}

提交里的 trailer 比 Wiki 里的说明更可靠

六、清单：把合规当成可重复的工程流程

五个检查项。第一，你能说清每个产物是由哪个模型、哪个版本生成的吗？第二，AI 参与与人类评审是否记录在提交这类不易丢失的地方？第三，模型是否被「钉版本」，而不是写 latest？第四，每次 Agent 决策是否有结构化记录，含批准信息？第五，发布时是否生成了一份随版本归档的合规清单？这五项的共通点是「可重复」——合规不是一个季度一次的突击检查，而是一条在每次提交、每次发布时自动运行的流水线。把它做成流程，它才不会在截止日期前变成一场救火。