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

AI Act Articles 12 and 14: What to Log, When to Stop

Your agent is asked to pay a vendor. What should it write down, and who has to sign before any money moves?

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 audit record is one saved entry per action an AI agent takes: what it saw, what it decided and who reviewed it. Article 12 asks for automatic logging over the system’s life; Article 14 asks for a design where a person can step in. In the design proposed here, a payment waits for a signature.

KEY TAKEAWAYS · 3

  • For an engineer, Article 12 is a schema: one audit record per action, with model and prompt versions, evidence, decision and any human review.
  • One record can serve as evidence for several articles; on its own, it does not meet all of those duties.
  • Article 14 can become a code path. In the design I propose, the agent abstains when evidence is thin and stops for a signature when an action moves money or changes a record.
On this page

Article 12: what to actually log

IN SHORT Article 12 reads like paperwork, but for an engineer it is a schema.

WORDS TO KNOW

Audit record
One saved entry per action the system takes: what it saw, what it decided, and who reviewed it.
Escalate
Hand a case to a person, with what the agent found and why it stopped.
Human sign-off
In the design proposed here, a named person’s approval, required before a high-stakes action, such as a payment, can run.

It asks a high-risk system to record events by itself, for its whole life, so you can rebuild an incident later. In practice, that means one Audit record One saved entry per action the system takes: what it saw, what it decided, and who reviewed it. See the glossary per action.

IN PLAIN WORDS

Keep each output next to what led to it: the model, the prompt version (the instructions given to the model), the evidence it found, the action and any human review.

The example below is made up for illustration. It is not a record taken from a client.

A WORKED EXAMPLE

Illustrative numbers

PASSRequest 1: explain a fee

INPUT

Request
Explain the 1,250.00 EUR fee on the March statement
Model, prompt
model-a, prompt v14

WHAT HAPPENS

  1. The agent retrieves the fee schedule and the March invoice.
  2. Both support the same amount, so it answers and cites them.
  3. It writes one record. A reviewer accepts the answer.

OUTPUT

decision
answer
retrievedDocIds
[fee-schedule, inv-0312]
outcome
accepted

WAITS FOR A HUMANRequest 2: pay that fee now

INPUT

Request
Pay the 1,250.00 EUR fee to the vendor

WHAT HAPPENS

  1. This action moves money, so the agent can’t run it alone.
  2. It records decision = escalate and stops.
  3. Nothing executes until a named person signs.

OUTPUT

decision
escalate
humanReviewer
empty until someone signs
outcome
pending

One record can serve as evidence for several articles. On its own, it does not meet all of those duties.

ONE RECORD, FOUR ARTICLES
interface AgentAuditRecord
runIdstring

Art. 12: ties every step of one action into one record you can rebuild.

timestampstring

Art. 12: ISO-8601, UTC, so the trail is ordered and precise.

modelIdstring

Art. 11: the exact model and version behind the output, generated, not written.

promptVersionstring

Art. 11: the prompt is config, and config is versioned.

retrievedDocIdsstring[]

Art. 15: the sources, so you can check the answer rests on them; identifiers alone do not prove accuracy.

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

Art. 14: abstain and escalate are designed outcomes, not errors.

humanReviewer?string

Art. 14: set when a person confirmed or overrode the call.

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

Art. 12: append-only, so the record closes the loop instead of being overwritten.

Illustrative starting point. Each field maps to a topic for review. The mapping is an engineering proposal, not a compliance verdict; what the record must cover and how long you keep it are judged per system.

Coming up next: So what stops the agent from paying on its own?

Article 14: human oversight as a code path

IN SHORT Human oversight is a code path you can point to, not a promise in a policy.

Article 14 is often quoted and misread: it doesn’t mean someone watches a dashboard. It means the system is designed so a person can understand it, override it and stop it, and so it doesn’t act alone where it mustn’t.

WATCH OUT

If your only oversight is “a human can read the logs afterwards”, you have monitoring, not oversight.

STEP BY STEP

Flow diagram: 4 stepsFlow diagram: 4 steps. A request arrives, then Retrieve the evidence. Retrieve the evidence, then Decide. Decide branches into 3: If evidence holds, then Answer, sources cited. If evidence is thin, then Abstain, hand to a person. If moves money or changes a record, then Stop, wait for a signature. Both paths continue to Write the audit record.EVIDENCE HOLDSEVIDENCE IS THINMOVES MONEY OR CHANGES ARECORD1A request arrives2Retrieve the evidence3DecideAnswer, sources citedAbstain, hand to apersonStop, wait for asignature4Write the audit record

Step 1. Request. A question arrives, or an action such as a payment.

Pick a step to see it move
  1. Request A question arrives, or an action such as a payment.
  2. Evidence The agent pulls the documents that could support an answer. No document, no answer.
  3. Answer The evidence supports it: the agent answers and cites its sources, so a reviewer can check them.
  4. Abstain The evidence is thin, so no guess: the agent hands the case to a person, with what it found.
  5. Human gate The action moves money or changes a record: the agent stops and waits for a person to sign. Nothing runs alone on this path.
  6. Record Whatever the path, the agent writes the audit record, so a reviewer can rebuild what happened.
One request through the agent. The decision forks three ways, and every path ends in a record, stops included.

In this design, on thin evidence the agent can Escalate Hand a case to a person, with what the agent found and why it stopped. See the glossary; on a payment it needs a Human sign-off In the design proposed here, a named person’s approval, required before a high-stakes action, such as a payment, can run. See the glossary. Oversight matters most where an action moves money.

Article 14 wants a chance to step in before the harm, not a log to read after it.

I wrote about fencing those actions in, by giving the agent only the permissions its task needs, in least privilege for agents that move money. The same control also serves as your Article 14 evidence.

ITEM GET

Stop before the money moves

In this design, strong evidence decides the answer, not who may act on it. A payment waits for a named person to sign.

STAGE CLEAR

What you now know

  • You can sketch an audit record: model and prompt versions, evidence, decision, reviewer, outcome.
  • You can tell monitoring from oversight, and say which actions must wait for a person.

Check yourself

Tap or click a question to see the answer.

Your agent has strong evidence that a customer is owed a refund, and wants to send it now. Can it act alone?

Not in this design. A refund moves money, so it takes the human-gate path: the agent records its decision and waits for a person to sign.

Next stage:How do you measure an AI agent’s accuracy under Article 15, and what should you build first?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.