Shipping AI Agents Under the EU AI Act: A Developer Checklist for Risk Tiers and Audit Trails

AI Usage (80%)

Introduction — "No New Law" Is the Signal. The Work Is Still Yours.

Start with the consequence: agentic features shipped into the EU still have to clear the EU AI Act — Regulation (EU) 2024/1689 — because the people who could have replaced it say they won't. This developer checklist takes that at face value and maps the Act's risk tiers onto the engineering artifacts you have to produce anyway: model documentation, audit trails, human-in-the-loop gates, and incident reporting.

That's the practical takeaway from mid-October 2026 statements by EU officials and the EU tech chief: no emergency framework is coming for agents that misbehave. Whatever text you're building against today is the text you'll be building against at your next release.

My technical position: risk tiers are a design input, not a legal review you schedule two weeks before launch. The tier you sit in decides what you log, what you gate behind a human, what docs you generate, and what you report. Decide it at design time and those artifacts fall out of your pipeline. Decide it at the end and you're rebuilding telemetry under deadline pressure.

Scope: agentic features, tool-calling, and autonomous actions in software you ship into the EU. Out of scope: procurement law, market surveillance procedure, politics. This is an engineering mapping of a regulation, not legal advice.

What the EU Actually Said, and What It Leaves Unresolved

The two reported claims and their dates

디지털투데이 reported on 12 October 2026 that EU officials said existing law can handle out-of-control AI model risks. PYMNTS reported on 11 October 2026 that the EU tech chief said the AI Act can contain rogue agents. Both are reports of a stated position, not text from a legal instrument. Only publisher snippets were available to me, so I'm not quoting either verbatim, and neither names a speaker beyond the role. Read the framing as "the Commission's public posture," not an official communication.

Confirmed versus unconfirmed: what the reporting does and doesn't establish

What the reporting establishes: officials are signalling no new emergency AI legislation is planned for agentic systems. That's it. What it doesn't establish: whether any guidance, delegated act, or enforcement priority changes as a result. The reporting doesn't say, and I haven't seen it.

What would confirm a concrete change rather than a posture: a published Commission communication, an AI Office guidance document on agentic systems, or a template update for the Article 73 serious-incident report. Until one exists, plan against the consolidated regulation text.

Why "existing law covers it" doesn't shrink your obligations

A sufficiency claim is about legislation. It says nothing about your backlog, and it defers exactly zero duties. The Act's obligations on providers and deployers are already phased in and already enforceable, and the high-risk cliff for Annex III lands on 2 August 2026. The honest reading of "nothing new is coming" is: no, and that's the problem — the deadline you already had is the deadline you have.

Step 1 — Classify the Feature, Not the Model: Prohibited, High-Risk, Limited, and Minimal Tiers

Classify at the feature level, at design time. The same base model sits inside a low-risk summariser and a high-risk decision engine; what changes the tier is what the feature does on a user's behalf. Agent autonomy is the variable that pushes a feature up a tier, so "which model did we pick" is the wrong first question.

💡

This post maps the regulation to engineering artifacts. It is not legal advice, and the tier decision for a specific product should be reviewed by counsel.

Prohibited practices and their date

The prohibitions applied from 2 February 2025. The ones engineering teams actually trip over: manipulative or deceptive techniques that materially distort behaviour, social scoring, exploitation of vulnerabilities of people or groups, and untargeted scraping of facial images to build recognition databases. Treat this as a fast stop-the-design check. If a feature matches, the release is over and no amount of logging fixes it.

High-risk: Annex III and Annex I, with application dates

Annex III names the categories — employment and worker management, education, essential services such as credit and insurance, law enforcement, migration and border control, administration of justice. Annex I is the embedded-product route, where an AI system is a safety component of a product already governed by harmonised legislation.

Dates as established by the regulation: 2 August 2026 for Annex III high-risk, 2 August 2027 for Annex I embedded high-risk. I treat those as fixed. Any proposal to amend them after 2026 is unconfirmed and would need a published amending act before I'd rewrite a roadmap around it.

Limited-risk transparency and minimal-risk

Article 50 sets the transparency duties: telling users they're interacting with an AI system, labelling synthetic and manipulated content, machine-readable marking of generated output. Minimal-risk features carry no new duties beyond existing product law. Say it plainly, though — once an agent acts on a user's behalf, "minimal-risk" is usually the wrong label. A system that takes actions has a trust boundary to disclose.

The Art. 6(3) filter, and how agent autonomy pushes a feature upward

Article 6(3) is the exit from Annex III. A narrow procedural task, improving a previous human result, detecting deviations without replacing human assessment, or a preparatory task can keep an Annex III system out of high-risk — but the provider must document that assessment and register it. The filter is not self-executing.

Here's the technical part that matters. An agent that picks its own tools, retrieves its own context, and executes irreversible actions is not a narrow procedural task. The moment the loop can choose what to call next, the "narrow" argument collapses and the filter usually won't save you. Design for high-risk and be wrong, rather than argue the filter in an audit.

Table: tier to obligation to artifact

Tier	Core obligation	Artifact it forces
Prohibited	No release	Design-stop review
High-risk	Conformity assessment, risk management, logging	Annex IV doc set, audit events, oversight gates
Limited	Transparency (Art. 50)	User disclosure strings, output marking
Minimal	Existing product law	Nothing new

Step 2 — Documentation You Can Generate: Articles 9, 10, 11, and 13 as Build Outputs

Most of Annex IV is metadata you already have if you instrument for it, and expensive manual archaeology if you don't. The builder's move is to make the docs a build output.

Art. 11 and Annex IV mapped to repo files

A mapping that works:

system description and intended purpose — a versioned doc, reviewed under the same PR template as code
model and provider inventory — generated from config, not typed by hand
training and fine-tuning data provenance — recorded where the data pipeline runs
validation and test results — CI artifacts tied to the release SHA
known limitations and foreseeable misuse — a maintained section, not a one-time paragraph
change history tied to releases — your git history, surfaced into the doc set

The two fields teams consistently under-specify for agents are intended purpose and foreseeable misuse. "The agent can do anything in the workspace" is not an intended purpose, and it's the sentence that turns a review hostile.

Art. 9 risk management as a living file

The Article 9 risk management system is iterative across the lifecycle, not a document you sign once. Every new agent capability — a new tool, a new memory, a new autonomy level — should produce a new risk entry and a test that demonstrates the mitigation. Ship the capability without the risk entry and the file is stale, and it will read that way.

Art. 10 data governance and Art. 13 instructions for use

Article 10 asks for dataset relevance, representativeness, and bias examination at a practical level: do you know what your fine-tuning set contains, and can you show the check? Article 13 asks for instructions for use — user-facing documentation of limits, accuracy, intended purpose. Ship those as product docs users can find, not a PDF linked once in an onboarding email.

Step 3 — Audit Trails That Survive Articles 12 and 26(6) Logging Rules

What an agent event record needs

Fields that make a record defensible: timestamp, trace and span ID, model identifier and exact version, prompt template hash, tool invoked with an arguments hash, retrieved document IDs and versions, policy decision, human approval or denial, outcome. Recording prompts and tool arguments verbatim collides with PII minimisation, so the pattern is hashed or redacted fields plus a separate, access-controlled store for any raw content you must keep.

CodeBlock — structured agent run log

agent-audit-log.js

// Append-only run evidence. Lab example, no real endpoints or secrets.
const logPath = process.env.AGENT_AUDIT_LOG ?? "./agent-runs.jsonl";
const hash = (v) => createHash("sha256").update(String(v)).digest("hex").slice(0, 16);

export async function emitAuditEvent({
traceId,
spanId,
modelId,
modelVersion,
promptTemplate,
toolCall = null,
policyDecision,
approval = "none",
outcome,
}) {
const record = {
  ts: new Date().toISOString(),
  trace_id: traceId,
  span_id: spanId,
  model_id: modelId,
  model_version: modelVersion,
  prompt_hash: hash(promptTemplate),
  tool_call: toolCall
    ? { name: toolCall.name, args_hash: hash(JSON.stringify(toolCall.args)) }
    : null,
  policy_decision: policyDecision, // "allow" | "deny" | "escalate"
  approval,                        // "none" | "granted" | "denied"
  outcome,
};
await appendFile(logPath, JSON.stringify(record) + "\n", "utf8");
}

The hash proves which template and which arguments were used without dumping a user's raw content into a log line.

Retention, access, and the six-month floor

Article 12 requires automatic recording of events over the system lifetime at the provider level. Deployer log retention is at least six months under Article 26(6) — verify that against the current consolidated text before writing it into a retention policy, because retention is the kind of clause that gets amended. Practical notes: store logs where you can actually query them, make them tamper-evident (append-only or a write-once bucket), and define who can read them before someone asks.

Step 4 — Human-in-the-Loop Gates That Aren't Theatre

Oversight by design versus rubber-stamp approval

An approval dialog that appears 200 times a day isn't oversight — it's automation bias with a timestamp. Article 14 requires oversight that is effective, which means the interface surfaces the decision-relevant context and the reviewer has the authority and the time to stop the action. If the reviewer can't say no without breaking the workflow, you have a modal, not a control.

Gate patterns worth implementing

tool allowlists scoped per task, not per agent
mandatory approval on irreversible or external-effect actions — payments, emails, deletes, infrastructure changes
confidence and policy thresholds that escalate to a human instead of guessing
a global kill switch that stops in-flight runs
an override path that works mid-run, not only at start

CodeBlock — a policy gate wrapper

policy-gate.js

// Wrap a tool dispatcher so side effects cannot run without approval.
const ALLOWLIST = new Map([
["search_docs", { sideEffect: false }],
["send_email", { sideEffect: true }],
["delete_record", { sideEffect: true }],
]);

export function createGatedDispatcher({ dispatch, audit }) {
return async function gated(toolName, args, ctx) {
  const policy = ALLOWLIST.get(toolName);
  if (!policy) {
    await audit({ toolName, policy_decision: "deny", outcome: "unlisted_tool" });
    throw new Error(`tool not allowed: ${toolName}`);
  }
  if (policy.sideEffect && !ctx.approvalToken) {
    await audit({ toolName, policy_decision: "escalate", outcome: "approval_required" });
    throw new Error(`approval required for: ${toolName}`);
  }
  return dispatch(toolName, args, ctx);
};
}

The gate refuses and logs by default, which is what you want when the allowlist and the agent disagree.

Step 5 — Incident Reporting and Post-Market Monitoring Under Articles 72 and 73

Art. 72 post-market monitoring as a tracked backlog

Article 72's monitoring plan is an engineering input, not a compliance binder. Instrument refusals, escalations, tool failures, and unintended actions, and route them into a reviewed backlog with an owner. A dashboard nobody opens is not monitoring.

Art. 73 timelines and thresholds

Article 73 sets the serious-incident reporting duty. As written: report after establishing a causal link, no later than 15 days in the general case, with shorter windows for critical-infrastructure incidents and for death, plus the option of an initial incomplete report followed by a complete one. Treat those exact numbers as something to confirm against the current consolidated text and any Commission guidance before baking them into a runbook. I won't quote a deadline the source material doesn't support.

Wiring the report into on-call

Add a "regulatory reportable" flag to the incident template, name an owner, and keep a prepared evidence bundle — logs, model version, decision path — so the 15-day window isn't spent assembling data. It's a small change to an existing process, and it's the one that saves the most time when it matters.

Where Liability Lands for Rogue Agents

Value-chain duties and reclassification

The Act allocates duties along the chain, and a deployer can take on provider obligations when it puts its name on the system or substantially modifies it — exactly the situation for a team wrapping a third-party model in its own agent loop. Article 25 is the mechanism. That reading is my inference from how the article is structured; it's the interpretation I'd check with counsel before relying on it.

What the Act does not decide

Be honest about the limit. "The AI Act can contain rogue agents" is a containment claim about a legal framework, not a technical guarantee about your agent. It doesn't replace contracts, insurance, or the general product-liability regime. What would change the picture: harmonised standards published by CEN-CENELEC, or official guidance on agentic systems specifically. Until then, "covered by the Act" and "covered by our engineering" are different sentences.

A Shipping Checklist for Risk Tiers, Documentation, and Audit Trails

Pre-merge	Release	Production
Tier classification recorded	Annex IV doc set generated in the pipeline	Audit event schema versioned
Art. 6(3) assessment documented, if claimed	Disclosure strings present in UI	Log retention and access policy defined
Risk entry filed for each new capability	Approval gates tested with an irreversible action	Monitoring alerts routed to a named owner
		Incident template updated with the reportable flag

What to Watch: Dates, Guidance, and Harmonised Standards

Confirmed: the application dates in the regulation as published — 2 February 2025 for prohibitions, 2 August 2026 for Annex III high-risk, 2 August 2027 for Annex I. Open: any amending proposal to those dates, Commission guidance and AI Office templates, the status of harmonised standards, and enforcement actions under the prohibitions. I'm not forecasting any of them. I'm watching for one of them to produce a document, because that's what changes a plan.