SKIP TO CONTENT
AI AGENTS6 minAgents in Production / Ep. 5 · Stage 5-2

AI Act High-Risk Rules: Which Articles Become Code?

Your policy says a person approves every payment; does your code agree? Read as an engineer, each high-risk AI Act article maps to a change you can build and show.

XIN
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.

IN 30 SECONDS

A compliance control in code is a check that runs on the path every ordinary action takes, instead of a promise in a document. This stage maps each high-risk article, 9 to 15 plus 72, to such a change. It assumes a lawyer has settled whether your system is high-risk.

KEY TAKEAWAYS · 3

  • In an engineering reading, each high-risk article (9 to 15, plus 72) maps to something you can build: about half are documents you can generate, the rest code paths, tests and alerts.
  • Put the rule on the path every ordinary action takes, check before the action, and make failing the check a designed outcome.
  • Those controls can support compliance work; they do not establish legal compliance by themselves.
On this page

The checklist: article to code change

IN SHORT I’d map each high-risk article to something you can build and show in a repository.

WORDS TO KNOW

Intended purpose
The use the provider intends the system for. Reviewers start from it.
Deployer
A person or organisation that uses an AI system under its own authority.
Abstain
When an agent declines to answer because its evidence is thin, instead of guessing.

First, a qualified reviewer must look at what the system is meant to do, its Intended purpose The use the provider intends the system for. Reviewers start from it. See the glossary, and check the Article 6 conditions, both the Annex I and the Annex III routes. The ideas here assume that question is settled.

IN PLAIN WORDS

The rows come from the high-risk requirements (Chapter III, Section 2), plus Article 72. About half are documents you can generate from the repo; the rest are code paths, tests and alerts. That grouping is an engineering framing, not a legal taxonomy.

ARTICLE TO CODE
Art. 9, risk management
A continuous risk process across the lifecycle
A living risk register in the repo, reviewed each release
Art. 10, data governance
Governed, documented training, validation and testing data
Track dataset and index provenance and versions; record what the agent can and cannot see
Art. 11, technical documentation
Docs drawn up before market or service, kept current (Annex IV)
Version the model, prompt and config; generate the doc from them
Art. 12, record-keeping
Automatic logging of events over the lifetime
Audit records you only add to: one per action, with versions, decision and evidence
Art. 13, transparency to deployers
Clear instructions for Deployer A person or organisation that uses an AI system under its own authority. See the glossary, with capabilities and limits
A written capability and limitation sheet, not just a README
Art. 14, human oversight
Designed so a person can understand, oversee and intervene
Abstain-and-escalate paths, a stop control, a human sign-off on money moves
Art. 15, accuracy, robustness and cybersecurity
Declared accuracy metrics, resilience and security
An eval suite that gates the release, abstention scored as a metric
Art. 72, post-market monitoring
A documented monitoring system and plan for the system in use
The same evals in production; alert when a metric drifts from the release baseline
Source: consolidated AI Act (Regulation 2024/1689, amended by 2026/1744), Articles 9 to 15 and 72. Chapter III, Sections 1 to 3 (only part of them for some Annex I laws): from 2 December 2027 (Annex III) or 2 August 2028 (Annex I), Article 6(5) excepted. Article 72: from 2 August 2026, for providers of high-risk systems. Check EUR-Lex before you rely on these dates. Each change is evidence toward its article, never the whole duty, and not a legal reading of whether a system is in scope.

ADAM says: Think of the Act as a fire code, and your controls as the doors, alarms and drills. Where it breaks: whether the Act covers your system at all is a legal classification you settle with a lawyer.

And having the controls in place doesn’t, on its own, make a system compliant.

Coming up next: So why put the rule in the code rather than in a policy?

Two times I enforced compliance in code

IN SHORT Compliance you enforce in code beats compliance you promise in a document.

I’ve built it that way twice. First on-chain, directly on the blockchain: ERC-3643 enforces transfer eligibility inside the token. On an ordinary transfer, identity and compliance checks run before it goes through, so the token reaches only a verified holder.

WATCH OUT

That doesn’t cover everything. Privileged paths, meaning actions reserved for authorised roles such as a forced transfer, the admins themselves and whether off-chain identity decisions are valid still need their own review.

The second was a retrieval agent inside a fund, built to answer only with cited evidence. When the evidence is thin, it is designed to Abstain When an agent declines to answer because its evidence is thin, instead of guessing. See the glossary rather than guess.

STEP BY STEP

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 use2Run the check before theaction, not after3Make failing the check adesigned outcome

Step 1. On the path. ERC-3643 checks inside the token’s transfer. The agent checks inside its answer.

Pick a step to see it move
  1. On the path ERC-3643 checks inside the token’s transfer. The agent checks inside its answer.
  2. The check fails The token checks identity claims before the transfer settles; the agent checks its evidence before it answers. Here the check says no.
  3. A designed outcome The transfer reverts: it fails and its effects are undone. The agent abstains instead of guessing.
Both precedents make the same three moves.

The AI Act would file these under human oversight and accuracy. I called them the reasons the agent was allowed near the books. Like the token, they support compliance work; they don’t establish it.

Built right, a rule on the ordinary path is a rule nobody has to remember.

ITEM GET

Rule on the path

Rule on the ordinary path, check before acting, refusal planned.

FAQ

No. It’s an engineering checklist that maps obligations to code, so you know what to build. It doesn’t tell you whether the law applies to you, or how a court would read it.

Ask a lawyer how your system is classified and how the rules read. Then use this to build.

STAGE CLEAR

What you now know

  • You can name the code change I’d map to each high-risk article, and to Article 72.
  • You can say why a rule on the code path beats a rule in a document.

Check yourself

Tap or click a question to see the answer.

A colleague adds a policy PDF: “the agent never pays without approval”. The payment code still runs alone. What would you change?

Put the rule on the path: the payment code itself waits for a signature. A promise in a document stops nothing.

Next stage:What should an AI agent log under Article 12, and what does human oversight look like in code?6 min
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.

Have a project to ship or a role to fill?

Discuss your project or role
LinkedInTwitterGitHub
Follow the engineering notes

Get new articles on production AI and smart contracts by email.