ONE WORLD AI Discuss a pilot

Rules, execution
and evidence.

OWAI INSIGHTS · EUROPEAN UNION / AI ACT

EU AI Act and AI agents: logging and human oversight at the point of action

When an AI agent moves from suggesting an action to taking it, two AI Act themes become operational questions: can you reconstruct what happened, and could a competent person with the right authority have stopped it? This note summarises the relevant obligations for high-risk systems, the revised timetable, and what they imply for an agent architecture.

LAST REVIEWED / 28 SEPTEMBER 2026Discuss your workflow
01

The timetable after the Digital Omnibus

Regulation (EU) 2026/1744, the Digital Omnibus on AI, amended the AI Act and entered into force in July 2026. It moved the application of the high-risk obligations: for stand-alone high-risk systems listed in Annex III (for example employment, credit scoring, education, access to essential services and critical infrastructure) to 2 December 2027, and for AI that is part of products covered by the legislation in Annex I to 2 August 2028.

The delay changes the deadline, not the substance. Organisations deploying agents in areas that may fall within Annex III have roughly a year to design logging, oversight and evidence into their systems — which is easier to do before agents are connected to production systems than after.

02

Article 12: record-keeping

High-risk AI systems must technically allow the automatic recording of events (logs) over their lifetime, to a degree appropriate to their intended purpose. The aim is traceability: identifying situations that may create risk or lead to a substantial modification, and supporting post-market monitoring and the deployer’s own monitoring. Deployers must keep the logs under their control for a period appropriate to the purpose, and at least six months unless other law provides otherwise (Article 26(6)).

For an agent that can act, a log of model inputs and outputs is not the whole picture. The events that matter for traceability include which action was proposed, which rule and policy version applied, who approved or refused it, and what the connected system actually did.

03

Article 14: human oversight

High-risk systems must be designed so that natural persons can oversee them effectively while in use. Among other things, the people assigned must be able to understand the system’s capacities and limitations, remain aware of automation bias, correctly interpret its output, decide not to use it or override its output, and intervene or interrupt the system through a “stop” button or a similar procedure that brings it to a halt in a safe state.

Article 26(2) adds that deployers must assign oversight to natural persons who have the necessary competence, training and authority, as well as the necessary support.

04

What this means for an agent architecture

Read together, these provisions describe three properties that an agent architecture should be able to evidence for each consequential action:

  • A place to intervene: a defined point between the agent’s proposal and execution where the action can be allowed, escalated or stopped — not a dashboard that shows what has already happened.
  • Authority at that place: the person or role who decides is named, competent and entitled to decide for that class of action, and that entitlement can be traced to its source.
  • Records that tie it together: the proposal, the rule and policy version applied, the decision and who took it, and the execution result, kept for the retention period and in a form reviewers can verify.
05

Practical steps now

Start with an inventory of agent actions that change something — payments, records, code, customer communications — and decide which ones need a human decision, under which conditions. Then check that the stop is real: that the connected system cannot act without an approved decision, and that there is no alternative route, retry or service account that bypasses it. Finally, test the records: can a reviewer reconstruct, for one action, what was proposed, what rule applied, who decided and what happened?

06

How OWAI OS relates

OWAI OS is designed around exactly this point of action: it evaluates each AI-proposed action against versioned policy, routes the actions that need approval to the role your policy names, lets the connected system act only on an approved decision and records verifiable evidence of each step. It helps you prepare for assessment; whether a system is high-risk and which obligations apply remain determinations for your organisation and its advisers.