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

AI Act Article 15: How to Measure an Agent’s Accuracy

Can one percentage prove your agent is accurate? For an agent allowed to say “I don’t know”, accuracy is several numbers.

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

An eval suite is a fixed set of test cases, scored the same way before every release. For Article 15, I’d use one to measure several accuracy numbers and gate the release on thresholds set in advance. This stage ends with the build order: the audit record first.

KEY TAKEAWAYS · 3

  • For an agent allowed to say “I don’t know”, accuracy is several numbers: right when sure, holds back when it should, holds up under attack.
  • Measure them on a fixed set before release, against thresholds written in advance, then in production (Article 72, for providers of high-risk systems).
  • Tests are evidence for Article 15, not all of it. Build the audit record first; logs, oversight and evals still need named owners and a risk assessment.
On this page

Article 15: how to measure accuracy

IN SHORT For an agent allowed to say “I don’t know”, accuracy is several numbers, not one percentage.

WORDS TO KNOW

Eval suite
A fixed set of test cases, scored the same way before every release, so you can compare one release with the last.
Red team
People who attack a system on purpose, to make it fail or lie before real users meet it.
Post-market monitoring
Watching a system once it is in use, and acting on what you find. Article 72 covers it.

Article 15 covers accuracy, robustness and cybersecurity. It asks you to declare your accuracy metrics. I’d declare three: how often a sure answer is right, how often the agent holds back when it should, and how well it holds up against a Red team People who attack a system on purpose, to make it fail or lie before real users meet it. See the glossary.

Measure them with an Eval suite A fixed set of test cases, scored the same way before every release, so you can compare one release with the last. See the glossary on a fixed test set before release. Set the pass marks first; if one is missed, the release waits.

STEP BY STEP

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, onmore than one axis2Measure them beforerelease3Gate the release on thethresholds4Keep measuring once it islive

Step 1. Declare. Declare more than one axis, not a single number.

Pick a step to see it move
  1. Declare Declare more than one axis, not a single number.
  2. Measure A fixed reference set, red-team cases included, scored the same way every run.
  3. Gate The thresholds were set before the run. A score below one holds the release back.
  4. Keep measuring Once live, alert when a metric drifts from its release baseline.
The accuracy loop. A release under a threshold doesn’t pass the gate.

Then keep measuring in production: that is part of Post-market monitoring Watching a system once it is in use, and acting on what you find. Article 72 covers it. See the glossary, under Article 72, which binds providers of high-risk systems. What it asks of you before 2027 is a question for your lawyer.

Write the pass marks down before you see the score.

IN PLAIN WORDS

You hand reviewers the suite and its last run, not an adjective like “accurate”.

WATCH OUT

Tests and their pass marks give you evidence for Article 15. They don’t cover it all: accuracy, robustness and cybersecurity still need a wider look at the whole system.

Two earlier posts go further. How it works: verified citations and abstention in RAG. The numbers: the eval suite that gates a release.

Coming up next: So with all of this on the list, what do you build first?

Four things to build first

IN SHORT Start with the audit record, because three other articles lean on it.

IF YOU BUILD NOTHING ELSE
Flow diagram: 4 stepsFlow diagram: 4 steps. Ship the append-only audit record, then Add abstain-and-escalate, plus a human gate on high-stakes actions. Add abstain-and-escalate, 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-onlyaudit recordArticle 12; it also feedsevidence for Articles 11, 14and 15.2Add abstain-and-escalate,plus a human gate onhigh-stakes actionsArticle 14.3Stand up an eval suitewith thresholdsArticle 15.4Version your model,prompt and configArticle 11, so much of thetechnical documentation canbe generated.
The one-page version, in build order. Most of the rest is process around these four, and none of them establishes compliance on its own.

Logs, oversight and evals still need owners written down and a risk assessment. They also need a check against the rules that apply.

I’d build these with the legal, compliance and operations teams. You need code you can maintain and a correct reading of the rules. This checklist is one page of a larger map: how I build AI for regulated finance.

ITEM GET

Record first

Ship it before anything else: oversight, accuracy and documentation all draw on it.

FAQ

For this checklist, it depends on whether your system is high-risk. It can be through a use listed in Annex III (Article 6(2), with exceptions), or as a product, or safety part of one, that Annex I law sends for a third-party check (Article 6(1)). Which one, if either, is for a qualified lawyer.

Other parts of the Act, like the Article 50 transparency duties, can apply anyway. The two high-risk routes carry different dates. Building early is cheap insurance.

A record for each action. It links the model and prompt versions, the evidence found, the decision and any human review. It can support logging and documentation work.

What it must cover, how long you keep it and the other controls still have to be judged for each system.

Those are useful building blocks. With the reviewers in charge, still check the system’s intended purpose, risk assessment, data governance, oversight, security, documentation and how it is run.

This article is not a full conformity assessment.

STAGE CLEAR

What you now know

  • You can list the accuracy numbers worth declaring for an agent that may abstain, and why one percentage hides them.
  • You can give the build order: audit record, abstention and a human gate, gated evals, versioning.

Check yourself

Tap or click a question to see the answer.

Your agent’s report shows one number: the share of correct answers. It never abstains. What is missing from that report?

The other axes: how often it holds back when it should, and how it holds up against a red team. One percentage can hide confident wrong answers.

Next episode:What tests should an AI agent pass before it goes live, and who decides go, wait or block?5 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.