The EU AI Act as an Engineering Checklist

The EU AI Act's high-risk obligations were set to apply on 2 August 2026, and a European Commission proposal could push parts of that timeline to as late as December 2027. Either way, none of it tells an engineer what to change in the code, so this post does.

Law firms will hand you the obligation. I have not found one that hands you the diff. This is the translation: here is the Article, here is the thing you build.

I can write it because I have shipped machine-enforced compliance twice. Once on-chain, where ERC-3643 checks transfer eligibility inside the token. Once in a regulated fund, where a retrieval agent cites its sources, abstains when the evidence is thin, and logs every step. The Articles below map onto that work almost one to one.

Two times I enforced compliance in code

Before any Article, one idea does most of the work: compliance you can enforce in code beats compliance you promise in a document. I have built it that way twice, and both are the mental model for the checklist.

The first time I made a rule impossible to skip, it was on-chain: ERC-3643 enforces transfer eligibility inside the token, which is the same instinct this checklist applies to an AI system.

The checklist: Article to code change

Here is the map. The left column is the obligation, taken from the EU AI Act's high-risk requirements (Regulation (EU) 2024/1689, Chapter III, Section 2, plus Article 72 on monitoring). The right column is what it means in a repository.

I am not telling you whether your system is high-risk. That classification depends on Annex III and is a legal question for a qualified lawyer. What I can do is show you the build once someone tells you that you are in scope.

Source: EU AI Act (Regulation (EU) 2024/1689), Articles 9 to 15 and 72. This maps obligations to engineering work; it is not a legal interpretation of whether any specific system is in scope.

Article 12: what to actually log

Article 12 is the one engineers underestimate, because it reads like paperwork and is actually a schema. It asks that a high-risk system automatically records events across its lifetime, so an incident can be reconstructed later.

The trap is logging the output. The output is the least useful thing to keep. Log the decision: what the model was, what prompt version ran, what evidence it saw, what it chose to do, and whether a human touched it. Here is the record I keep per action.

// One immutable record per agent action. Article 12 wants events
// reconstructable over the system's lifetime, so log the decision,
// not just the output.
interface AgentAuditRecord {
  runId: string             // ties every step of one task together
  timestamp: string         // ISO-8601, UTC
  actor: 'agent' | 'human'  // Article 14: who made this call
  modelId: string           // exact model + version behind the output
  promptVersion: string     // Article 11: the prompt is config, and it is versioned
  inputHash: string         // what the agent saw, without storing raw PII
  retrievedDocIds: string[] // Article 15 evidence: which sources grounded the answer
  decision: 'answer' | 'abstain' | 'escalate'
  citations: Citation[]     // the evidence behind an 'answer'
  humanReviewer?: string    // set when a person confirmed or overrode
  outcome: 'accepted' | 'overridden' | 'pending'
}

Read that record against the Articles and it stops being one obligation. The promptVersion and modelId fields are your Article 11 technical documentation, generated instead of written. The decision field, with abstain and escalate as first-class values, plus humanReviewer, is your Article 14 human-oversight trail.

The retrievedDocIds and citations are your Article 15 accuracy evidence: proof the answer was grounded, not guessed. And because the record is append-only, one per action, the whole log is the Article 12 requirement satisfied by construction. One data structure, four Articles.

Article 14: human oversight in a retrieval pipeline

Human oversight is the Article people quote and misread. Article 14 does not mean a person watches a dashboard. It means the system is designed so a person can understand it, override it, and stop it, and so it does not act on its own where it must not.

In a retrieval pipeline that is a concrete design, not a policy. The agent answers only from retrieved evidence. When the evidence is thin, it does not produce a confident guess, it abstains and routes the case to a person. A money-moving action never auto-executes; it waits for a human to sign.

A money-moving action is exactly where oversight has to bind. I wrote about the containment side of this in least privilege for agents that move money; the same control doubles as your Article 14 evidence.

Article 15: how to evidence accuracy

Article 15 asks for accuracy, robustness, and cybersecurity, and it asks you to declare the accuracy metrics. Engineers hear 'accuracy' and reach for a single percentage. That is the wrong shape for an agent that is allowed to say 'I do not know.'

The honest metric set has more than one axis. How often a confident answer is correct. How often the agent abstains when it should. How it holds up under a red-team trying to make it lie. You declare those, you measure them before release, and you keep measuring them in production.

Article 15 asks you to declare accuracy and back it up. Two things I have already written do that work: verified citations and abstention in RAG for the mechanism, and the eval suite that gates a release for the numbers that gate a deployment.

What this unlocks

Do this and the deadline stops being a threat and becomes a checklist you already know how to clear. Logging is a schema. Human oversight is a few code paths. Accuracy is an eval suite. None of it is new to a team that ships carefully; the Act just names it and dates it.

The teams that struggle are the ones treating the AI Act as a legal document to be summarized. The teams that clear it treat it as a spec. I read it as a spec because I had implemented the same ideas before the law asked me to.

This checklist is one page of a larger map: how I build AI for regulated finance.

FAQ