SKIP TO CONTENT
AI Agents10 minAgents in Production / Ep. 5

The EU AI Act as an Engineering Checklist

Adam Boudjemaa
SHARE
Pixel-art illustration of a legal scroll on the left morphing into stacked lines of code on the right, joined by a bridge of light.

KEY TAKEAWAYS

  • The AI Act itself was not delayed. Its general application date, 2 August 2026, is unchanged; Regulation (EU) 2026/1744 moved only the Chapter III high-risk requirements, to 2 December 2027 for Annex III systems and 2 August 2028 for Annex I systems.
  • This is an engineering checklist, not legal advice: each obligation maps to a concrete code change, like what to log, how to version a prompt, and where a human has to stay in the loop.
  • I have shipped machine-enforced compliance twice, ERC-3643's on-chain transfer checks and a regulated-finance RAG that abstains, so the mapping comes from building it, not reading about it.
  • Article 12 is a logging spec, Article 14 is human-in-the-loop, and Article 15 is your eval suite. They now land in 2027 or 2028, but Article 72 monitoring stayed on the original date and wants the same machinery.
2
TIMES I ENFORCED COMPLIANCE IN CODE
ERC-3643 on-chain + a regulated RAG
8
ARTICLES IN THIS CHECKLIST
AI Act, Ch. III Sect. 2 + Art. 72

The AI Act's high-risk obligations no longer land on 2 August 2026. Regulation (EU) 2026/1744 moved them to 2 December 2027 for Annex III systems and 2 August 2028 for Annex I systems. The Act itself still applies from 2 August 2026, and Article 72 monitoring came with it. None of that 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.

NOT LEGAL ADVICE

Not legal advice. This is an engineering checklist from a smart-contract and AI engineer, current as of 5 August 2026. Every Article and date below comes from the consolidated text of the EU AI Act (Regulation (EU) 2024/1689, as amended by Regulation (EU) 2026/1744) on EUR-Lex. I first published this on 2 July 2026, when the high-risk delay was still a Commission proposal. It was adopted on 8 July and entered into force on 27 July, so I have rewritten every date against the consolidated Article 113. Check EUR-Lex before you rely on any of it, and do not trust the unofficial trackers: one of the most-cited was still serving the old text when I checked.

THE TIMELINE
1

Enters into force

1 August 2024. The EU AI Act (Regulation (EU) 2024/1689) becomes law and starts the clock on every later obligation.

2

The Act starts to apply

2 August 2026. Article 113 still says so, and the omnibus did not touch that sentence. This is the date Article 50 transparency and Article 72 post-market monitoring run from.

3

High-risk, Annex III

2 December 2027. Chapter III, Sections 1 to 3, for AI systems classified as high-risk under Article 6(2) and Annex III. Sixteen months later than the Act itself.

4

High-risk, Annex I

2 August 2028. The same requirements for systems that are high-risk under Article 6(1) and Annex I, because they sit inside a product that was already regulated.

Source: consolidated Article 113 of Regulation (EU) 2024/1689 on EUR-Lex, as amended by Regulation (EU) 2026/1744 (in force 27 July 2026). The general application date did not move. Only Chapter III did.

Two times I enforced compliance in code

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

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.

Enforced on-chain: ERC-3643

A transfer checks the receiver's identity claims inside the token and reverts if they are missing. The rule cannot be skipped, because it lives on the path everyone has to use. That is machine-enforced compliance with no human in the critical path.

Enforced in a pipeline: a regulated RAG

A retrieval agent inside a fund answers only with cited evidence, abstains and escalates when the evidence is thin, and writes an audit record for every step. The AI Act calls these logging, human oversight, and accuracy. I called them the reasons it was allowed near the books.
THE SHARED SHAPE
Flow diagram: 3 stepsFlow diagram: 3 steps. Put the rule on the path everyone has to use, then Run the check before the action, not after. Run the check before the action, not after, then Make failing the check a designed outcome.1Put the rule on the patheveryone has to useERC-3643 lives inside the token'stransfer. The evidence check livesinside the agent's answer.2Run the check before the action,not afterThe token checks the identity claimsbefore the transfer settles. Theagent checks its evidence before itanswers.3Make failing the check adesigned outcomeThe transfer reverts. The agentabstains and routes the case to aperson.
Both precedents are the same three moves. Get them right and nobody has to remember the rule, because the rule sits on the only path there is.

The checklist: Article to code change

One thing to settle before the map. These obligations are not on one clock any more. Articles 9 to 15 sit in Chapter III and moved. Article 72 sits in Chapter IX and did not.

TWO CLOCKS, PLUS ONE
Decide: Which clock is the provision on?Decision tree: Which clock is the provision on? If it is Chapter III and the system is high-risk under Article 6(2) and Annex III, then Applies from 2 December 2027. If it is Chapter III and the system is high-risk under Article 6(1) and Annex I, then Applies from 2 August 2028. If it is Article 72 post-market monitoring, then Has applied since 2 August 2026.DECIDEWhich clock is the provision on?IF it is Chapter III and the systemis high-risk under Article 6(2) andAnnex IIIApplies from 2 December 2027The stand-alone high-risk case.Sixteen months after the Act itselfstarted to apply.IF it is Chapter III and the systemis high-risk under Article 6(1) andAnnex IApplies from 2 August 2028High-risk because it is embedded ina product that was alreadyregulated. Twenty-four monthsafter.IF it is Article 72 post-marketmonitoringHas applied since 2 August2026Chapter IX was never carved out, soArticle 72 runs on the Act'sgeneral date while Articles 9 to 15wait.
Which of the first two branches covers a given system is a legal classification, not an engineering call, and it is a question for a lawyer. What is not in doubt is that these provisions no longer share a date. Source: consolidated Article 113, point (c), on EUR-Lex.

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.

Article
What it requires
The code change
Art. 9, risk management
A continuous risk process across the lifecycle
A living risk register in the repo, reviewed each release, not a one-off document
Art. 10, data governance
Governed, documented training and reference data
Track dataset and index provenance and version; record what the agent can and cannot see
Art. 11, technical documentation
Docs drawn up before release, kept current (Annex IV)
Treat the model, prompt, and config as versioned artifacts; generate the doc from them
Art. 12, record-keeping
Automatic logging of events over the lifetime
Append-only audit records: one per action, model and prompt version, decision, evidence
Art. 13, transparency to deployers
Clear instructions, capabilities, and limitations
Ship a written capability and limitation sheet with the system, not just a README
Art. 14, human oversight
A person can understand, oversee, and intervene
Abstain-and-escalate paths, a stop control, and a human sign-off on money-moving actions
Art. 15, accuracy and robustness
Declared accuracy metrics and resilience
An eval suite that gates the release, with abstention scored as a first-class metric
Art. 72, post-market monitoring
Monitor the system in production
Observability on the same evals; alert when a live metric drifts from the release baseline

Source: consolidated EU AI Act (Regulation (EU) 2024/1689 as amended by Regulation (EU) 2026/1744), Articles 9 to 15 and 72. Chapter III, Sections 1 to 3 apply from 2 December 2027 (Annex III) or 2 August 2028 (Annex I), with Article 6(5) excepted; Article 72 applies from 2 August 2026. This maps obligations to engineering work; it is not a legal interpretation of whether any specific system is in scope.

EIGHT ARTICLES, FOUR ARTIFACTS
Layered stack diagram: 4 layers, top to bottomLayered stack diagram: 4 layers, top to bottom. Layer 1, DOCUMENTS YOU GENERATE: Art. 9 risk register, Art. 10 data provenance, Art. 11 technical docs, Art. 13 capability sheet. Layer 2, CODE PATHS YOU SHIP: Art. 12 audit record, Art. 14 abstain, escalate, human gate. Layer 3, TESTS THAT GATE RELEASE: Art. 15 eval suite with thresholds. Layer 4, ALERTS IN PRODUCTION: Art. 72 drift from the release baseline.DOCUMENTS YOU GENERATEArt. 9 risk registerArt. 10 data provenanceArt. 11 technical docsArt. 13 capability sheetCODE PATHS YOU SHIPArt. 12 audit recordArt. 14 abstain, escalate, human gateTESTS THAT GATE RELEASEArt. 15 eval suite with thresholdsALERTS IN PRODUCTIONArt. 72 drift from the releasebaseline
The same eight rows, grouped by what you actually build. Only the top band is paperwork; the rest is code, tests, and alerting you already know how to write. Engineering framing, not a legal taxonomy.

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 RECORD, FOUR ARTICLES
interface AgentAuditRecord
runIdstring

Article 12 logging: ties every step of one action into a single reconstructable record.

timestampstring

Article 12 logging: ISO-8601, UTC, so the lifetime trail is ordered and precise.

modelIdstring

Article 11 technical docs: the exact model and version behind the output, generated not written.

promptVersionstring

Article 11 technical docs: the prompt is config, and config is versioned.

retrievedDocIdsstring[]

Article 15 accuracy: which sources grounded the answer, proof it was not guessed.

decision'answer' | 'abstain' | 'escalate'

Article 14 human oversight: abstain and escalate are first-class outcomes, not errors.

humanReviewer?string

Article 14 human oversight: set when a person confirmed or overrode the call.

outcome'accepted' | 'overridden' | 'pending'

Article 12 logging: append-only, so the record closes the loop instead of overwriting it.

The same append-only record satisfies four obligations at once: log it well and Articles 11, 14, and 15 ride along with the logging in Article 12.

The note on each field is the clause it satisfies. 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 14 AS A CODE PATH
Decide: Can the agent act on its own here?Decision tree: Can the agent act on its own here? If the retrieved evidence supports the answer, then It answers, with its sources cited. If the evidence is thin, then It abstains and routes the case to a person. If the action moves money or changes a record, then It stops and waits for a human to sign.DECIDECan the agent act on its own here?IF the retrieved evidence supportsthe answerIt answers, with its sourcescitedThe normal path. The answer isgrounded, and the citations are theproof.IF the evidence is thinIt abstains and routes thecase to a personNo confident guess. Abstention is adesigned outcome, not an error.IF the action moves money orchanges a recordIt stops and waits for ahuman to signA hard gate. Nothing auto-executeson the high-stakes path.
Three branches, three code paths you can point a regulator at. Oversight that lives only in a policy document has no branch here.

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.

THE ACCURACY LOOP
Flow diagram: 4 stepsFlow diagram: 4 steps. Declare the metrics, on more than one axis, then Measure them before release. Measure them before release, then Gate the release on the thresholds. Gate the release on the thresholds, then Keep measuring once it is live.1Declare the metrics, on morethan one axisHow often a confident answer iscorrect. How often the agent abstainswhen it should. How it holds up undera red-team.2Measure them before releaseA fixed reference set, red-team casesincluded, scored the same way everyrun.3Gate the release on thethresholdsWritten down in advance, not afteryou saw the score.4Keep measuring once it is liveArticle 72: alert when a productionmetric drifts from the releasebaseline.
This loop is your answer to "how accurate is it?". You hand over the suite and the last run, not an adjective.

What this unlocks

Do this and the deadlines stop being a threat and become 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. Twice, now.

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.

IF YOU BUILD NOTHING ELSE
Flow diagram: 4 stepsFlow diagram: 4 steps. Ship the append-only audit record, then Add an abstain-and-escalate path, plus a human gate on high-stakes actions. Add an abstain-and-escalate path, plus a human gate on high-stakes actions, then Stand up an eval suite with thresholds. Stand up an eval suite with thresholds, then Version your model, prompt, and config.1Ship the append-only auditrecordArticle 12, and it carries Articles11, 14, and 15 with it.2Add an abstain-and-escalatepath, plus a human gate onhigh-stakes actionsArticle 14.3Stand up an eval suite withthresholdsArticle 15.4Version your model, prompt, andconfigArticle 11, so the technicaldocumentation writes itself.
The one-page version, in build order. Everything else is process around these four.

FAQ

That depends on whether your system is classified as high-risk, either on its own under Article 6(2) and Annex III, or because it is embedded in a product already regulated under Article 6(1) and Annex I. Which one, if either, is a legal question for a qualified lawyer, not something I can answer for you, and the two now carry different dates. What this post gives you is the engineering build for the case where you are in scope. Building to it is cheap insurance even before the classification is settled.

No, and the shorthand is doing damage. Article 113 still reads 'It shall apply from 2 August 2026', and that sentence was not amended. What changed sits in the carve-outs underneath it, and the one that matters here is Chapter III, Sections 1 to 3, the high-risk requirements, which now apply from 2 December 2027 or 2 August 2028 depending on how a system is classified. Anything not carved out runs from 2 August 2026, Article 72 post-market monitoring among it, though Article 72 binds providers of high-risk systems and the rules that decide what counts as high-risk are themselves in the deferred chapter, so what it asks of you in practice before 2027 is a question for your lawyer and not for me. If you read a headline saying the Act was delayed and stopped building, you were building against the headline instead of against Article 113.

Regulation (EU) 2026/1744, the Digital Omnibus on AI, was adopted on 8 July 2026, published in the Official Journal on 24 July 2026, and entered into force on 27 July 2026. It amended the third paragraph of Article 113 in three places: it replaced point (a), replaced point (c), and added a point (d). Point (c) is the one this checklist turns on, so Chapter III, Sections 1 to 3, with the exception of Article 6(5), now apply from 2 December 2027 for AI systems classified as high-risk under Article 6(2) and Annex III, and from 2 August 2028 for those classified as high-risk under Article 6(1) and Annex I. The other two matter less to this post but are real: point (a) pushes parts of Article 5 to 2 December 2026, and the new point (d) applies Articles 102 to 110 from 27 July 2026. There is also a new Article 111(4) giving providers of synthetic-content systems placed on the market before 2 August 2026 until 2 December 2026 to meet Article 50(2). Article 72 sits in Chapter IX, which was not carved out, so it runs from 2 August 2026. Read the consolidated Article 113 on EUR-Lex rather than a tracker site: a popular unofficial tracker was still serving the pre-omnibus text when I checked on 5 August 2026.

No. This is an engineering checklist. It maps obligations to code so you know what to build; it does not tell you whether the law applies to you or how a court would read it. Get the classification and the interpretation from a lawyer, then use this to build.

The append-only audit record from Article 12. One record per agent action, capturing the model and prompt version, the evidence retrieved, the decision, and any human review. It satisfies the logging requirement directly and also carries your Article 11, 14, and 15 evidence, so it is the single structure that does the most work.

Closer than most. Verified citations are Article 15 accuracy evidence, evidence-based abstention is an Article 14 oversight trigger, and an eval suite with thresholds is your accuracy declaration. The gap is usually two things: the append-only logging from Article 12, and the written technical documentation from Article 11 that most teams never generate.

Agents in Production

Episode 5 · 10 published

PreviousNext
Adam Boudjemaa

Adam Boudjemaa

Former CTO of Integra. Named author (1 of 5) of ERC-3643, first author of ERC-6960, co-author of ERC-7410, and co-author of ERC-8203, which is still a draft. Building production AI and regulated Web3 systems.

LinkedInTwitterGitHub

Enjoyed this post?

Get more like it in your inbox every Tuesday.