EU AI Act and AI agents: logging and oversight

Regulation (EU) 2024/1689, the AI Act, defines an AI system broadly: a machine-based system that operates with some autonomy and infers from its inputs how to generate outputs, such as predictions, recommendations or decisions, that can influence physical or virtual environments. An AI agent that plans steps and calls tools fits comfortably inside that definition. The Act does not create a separate category for agents.

Instead, it sorts AI systems by risk. A small set of practices is prohibited. High-risk systems carry the heaviest duties. Certain systems carry transparency duties, such as telling people they are interacting with AI. Everything else is largely untouched. Separately, providers of general-purpose AI models have their own obligations. So the first question for any agent is not “is this an agent?” but “what is this agent used for, and does that use fall into a risk class?”

One duty reaches agents whatever their risk class. Under Article 50, which applies from 2 August 2026, providers must design systems that interact directly with people so that those people are told they are dealing with AI, unless that is obvious from the context. An agent that emails suppliers, answers customers or calls people on the phone falls within that duty. It is a small design change, but it applies now.

Under Article 6, a system is high-risk in two cases. It is a safety component of, or itself, a product covered by the EU product-safety laws listed in Annex I, such as machinery or medical devices. Or it is used in one of the areas listed in Annex III.

Article 6(3) adds an important exception: a system in an Annex III area is not high-risk if it does not pose a significant risk of harm, for example because it performs a narrow procedural task or only improves the result of a human activity already completed. An Annex III system that profiles natural persons is always high-risk. An agent that reconciles bank statements or drafts purchase orders is unlikely to be high-risk; an agent that decides which loan applicants proceed probably is. Document your assessment either way.

Article 12 requires high-risk systems to technically allow the automatic recording of events, logs, over the lifetime of the system. The logging must enable the recording of events relevant to three purposes: identifying situations that may present a risk or lead to a substantial modification, facilitating post-market monitoring by the provider, and monitoring the system's operation by the deployer.

For most systems the Act does not prescribe a field list; it prescribes what the logs must make possible. For remote biometric identification it is more specific, requiring at minimum the period of each use, the reference database, the input data that led to a match and the identity of the people who verified the result. For an agent, the practical reading is that each action needs a record of what was proposed, what was checked, who verified or approved it, and what happened. Our guide to the AI agent audit trail turns that into fields.

Providers keep the logs under their control for at least six months (Article 19), unless other EU or national law requires otherwise.

If you buy the agent rather than build it, the logging capability is the provider's job, but using it is yours. Ask the provider what events the system logs, where the logs are kept, how you export them and how long they are retained, and check the answers against its instructions for use. A deployer that cannot reach the logs cannot meet its own duties under Article 26.

Article 14 requires high-risk systems to be designed so that natural persons can oversee them effectively while they are in use. Oversight measures must be proportionate to the risks, the level of autonomy and the context. The people assigned must be enabled, as appropriate, to:

1. understand the system's relevant capacities and limitations and monitor its operation, including detecting anomalies;
2. remain aware of the tendency to rely automatically or excessively on the system's output (automation bias);
3. correctly interpret the system's output;
4. decide not to use the system in a particular situation, or to disregard, override or reverse its output;
5. intervene in its operation or interrupt it through a stop button or similar procedure.

For remote biometric identification, Article 14(5) goes further: no action is taken on an identification unless at least two competent people have separately verified it. For agents, items 4 and 5 are the design test. Can a person stop a specific change before it takes effect, and stop the agent entirely? Our guide to human approval covers how to make that real without approval fatigue.

Most businesses using an agent are deployers, not providers. Article 26 gives deployers of high-risk systems their own list of duties:

• use the system in accordance with the provider's instructions for use;
• assign human oversight to natural persons who have the necessary competence, training and authority, and the support they need;
• ensure input data under their control is relevant and sufficiently representative for the intended purpose;
• monitor operation, and inform the provider and authorities of serious incidents and risks;
• keep the logs automatically generated by the system, to the extent they are under the deployer's control, for at least six months, unless other law provides otherwise (Article 26(6));
• inform workers' representatives and affected workers before putting a high-risk system into use at the workplace.

Some deployers, including public bodies and those using systems for credit scoring or for life and health insurance pricing, must also carry out a fundamental rights impact assessment under Article 27. And under Article 86, people affected by certain decisions based on high-risk systems can ask the deployer for an explanation.

Obligations for providers of general-purpose AI models, such as technical documentation, copyright policies and, for models with systemic risk, evaluations and incident reporting, have applied since 2 August 2025. They fall on the model provider, not on every business that calls the model through an API.

The agent you build on top of a model is a separate AI system. If you put it on the market or into service under your own name, you may be its provider, with the provider's duties if its use is high-risk. Article 25 also turns a deployer or distributor into a provider if they substantially modify a high-risk system or change its intended purpose so that it becomes high-risk. Model choice does not move your obligations to the model vendor.

It can. Under Article 2, the Act applies to providers that place AI systems on the EU market or put them into service in the EU, wherever they are established, and to providers and deployers in third countries where the output produced by the system is used in the EU. Providers outside the EU of high-risk systems must appoint an authorised representative in the EU (Article 22).

In practice, an Indian software company selling an agent to EU customers is likely to be a provider in scope. An Indian business using an agent purely for its own Indian operations is not, unless the output is used in the EU, for example decisions about EU-based employees or customers. Penalties for breaching high-risk obligations can reach €15 million or 3% of worldwide annual turnover, whichever is higher (Article 99).

The Act entered into force on 1 August 2024 and applies in stages. In 2026 the EU adopted the Digital Omnibus on AI, Regulation (EU) 2026/1744, published on 24 July 2026 and in force since 27 July 2026, which postponed the high-risk dates. As of October 2026, the dates are:

Postponement is not removal. The design work for logging and oversight takes longer than the time left for most teams, and customers in regulated sectors are already asking for the evidence in procurement. The European Commission's AI Act pages and service desk track the guidance and standards still to come.

None of these controls makes a system compliant on its own. They produce the evidence a conformity assessment, an auditor or a customer will ask to see.

elan1 helps produce evidence for Articles 12, 14 and 26; it does not make a system compliant by itself. Every action an agent proposes is written to a 16-field proof record, allowed or refused, and consequential writes are held for a named approver who can refuse them. From L2 Attested, records are signed and packed into a signed evidence bundle that an auditor or customer can verify offline.

Records stay in the residency domain where they were written; today that is India, in Mumbai, and EU domains open on a signed contract (see residency). For the article-by-article mapping, read EU AI Act Articles 12 and 14 for AI agents; for risk and audit teams, see audit evidence for AI agent actions.