Regulation
EU AI Act and DORA: what agent owners should have in place by December 2027
Most enterprise agents won’t be high-risk under the AI Act, but some will — and for EU financial entities, DORA already applies. Here’s what to put in place now.
November 4, 2026 · 6 min read
AI agents are moving from pilots into workflows that touch money, personal data and decisions about people. Two pieces of EU regulation shape what their owners need to be able to show: the AI Act, whose obligations for high-risk systems apply from 2 December 2027, and the Digital Operational Resilience Act (DORA), which has applied to EU financial entities since 17 January 2025.
Governance is not keeping pace: only 21% of organizations have a mature governance model for autonomous agents, according to Deloitte.
This article is general information, not legal advice. Classification and obligations depend on your specific use cases; confirm them with counsel.
The AI Act regulates uses, not technologies
The AI Act takes a risk-based approach. A short list of practices is prohibited outright. Systems used for purposes the Act lists as high-risk carry the heaviest obligations. Some systems, such as chatbots, carry transparency duties. Everything else faces few or no specific obligations.
There is no category for “agents.” An agent is classified by what it is used for. An agent that posts supplier invoices to the ERP is not, on the face of the Act, high-risk. An agent that screens job applicants is.
Most enterprise agents won’t be high-risk. Some will.
Annex III lists the high-risk use areas. Two are directly relevant to the agents enterprises are deploying today:
- Employment and worker management: recruitment and selection, including filtering applications and evaluating candidates; decisions affecting terms of employment, promotion or termination; allocating tasks based on individual behavior or traits; and monitoring or evaluating performance.
- Access to essential private services: evaluating the creditworthiness of individuals or establishing their credit score (systems used to detect financial fraud are excluded), and risk assessment and pricing for individuals in life and health insurance.
There is a carve-out. Under Article 6(3), a system in an Annex III area is not high-risk if it doesn’t pose a significant risk of harm and doesn’t materially influence the outcome of a decision — for example, because it performs a narrow procedural or preparatory task. The carve-out never applies when the system profiles individuals. An agent that provisions accounts after HR has hired someone is unlikely to be high-risk. An agent that ranks candidates is likely to be.
Roles matter too. Providers develop a system and put it on the market or into service under their own name; deployers use it. If you build an agent in-house for a high-risk purpose, you may be both. Article 25 sets out when a deployer takes on provider obligations, for example by substantially modifying a system or changing its intended purpose.
What high-risk obligations mean for an agent
For agents that are high-risk, three articles do most of the work for the teams that operate them:
- Record-keeping (Article 12). High-risk systems must technically allow events to be logged automatically over their lifetime, so that situations presenting risk can be identified and the system’s operation monitored.
- Human oversight (Article 14). Systems must be designed so that people can understand their limits, interpret their output, decide not to use it or override it, and stop the system.
- Deployer obligations (Article 26). Deployers must use the system according to the provider’s instructions, assign oversight to people with the competence, training and authority to exercise it, monitor operation, inform the provider and authorities about risks and serious incidents, and keep the logs under their control for at least six months unless other law provides otherwise. Employers must inform workers’ representatives and affected workers before using a high-risk system at the workplace.
Financial institutions covered by EU financial-services governance rules meet the monitoring duty by complying with those rules, and keep the logs as part of the documentation those rules require. Deployers of credit-scoring or life and health insurance pricing systems must also carry out a fundamental rights impact assessment before first use (Article 27).
For agents, logging has a practical catch. An agent’s own trace records what it attempted, not what the ERP or HRIS actually did. Logs that support oversight and incident investigation need both sides — see two-sided evidence.
The dates have moved — check the ones that apply to you
These dates reflect the EU’s AI Omnibus, a simplification package proposed in November 2025 and in force since July 2026. It moved high-risk obligations for Annex III systems from August 2026 to 2 December 2027, and for AI in products covered by Annex I to 2 August 2028. Transitional rules for systems already in use are nuanced; check the current text and Commission guidance for the dates that apply to you.
DORA already applies
For EU financial entities — banks, payment and e-money institutions, investment firms, insurers and others in scope — DORA has applied since 17 January 2025. It doesn’t mention agents, and it doesn’t need to. An agent that posts payments is part of the ICT systems supporting business functions, and a vendor agent platform is an ICT service from a third-party provider. Three areas apply directly:
- ICT risk management (Articles 5–16). Identify and classify ICT assets, the business functions they support and their dependencies, and detect anomalous activity promptly. Agents and their credentials belong in that inventory.
- ICT-related incidents (Articles 17–23). Detect, classify and, where major, report incidents to the competent authority. A retry that pays a supplier twice, or ERP changes made with an agent’s credentials outside any run, may need to be assessed against your classification criteria.
- ICT third-party risk (Articles 28–30). Keep a register of information on contracts with ICT third-party providers, with required provisions such as audit, access and exit. Agent platforms and model providers that support business functions belong there.
For UK and US groups: the AI Act can apply outside the EU where an AI system’s output is used in the EU, and DORA applies to the EU-regulated financial entities in your group.
A readiness checklist for agent owners
- Inventory agents and owners. List every agent in production, its platform, the workflow it touches and a named business owner. Record whether each use falls in an Annex III area, and why.
- Define a mandate for each agent. Write down its purpose, scope (tools, systems, data), amount thresholds and autonomy level — the practical form of an intended purpose, and what its activity is checked against.
- Log what agents did, with evidence from systems of record. Keep runtime traces, but link each consequential action to the record it produced in the ERP, CRM or HRIS.
- Put human oversight where actions are consequential. Approvals above amount thresholds, bank-detail changes, hiring and credit decisions. Record who approved what, and make sure someone can stop an agent.
- Detect incidents, not just errors. Watch for duplicate payments, changes made without a required approval, and writes under agent credentials that no run explains. Route each to an owner.
- Align retention with your obligations. At least six months for deployer logs of high-risk systems, longer where financial-services or other law requires. Retain evidence from both sides, not just traces.
- Register agent platforms as third parties. Add agent platforms and model providers to your vendor register — for financial entities, the DORA register of information — with audit rights and exit plans.
How ThetaLayer helps
ThetaLayer doesn’t make anyone compliant, and it isn’t a substitute for legal analysis. It supports the evidence side: versioned mandates for each agent, checked against its full history; a ledger that reconciles what each agent claimed against what your systems of record recorded; and exceptions for duplicate payments, unapproved changes and unattributed writes, with an audit trail your internal audit, risk and compliance teams can review. Book a demo to see what that evidence looks like for one of your workflows.
Sources: Deloitte, State of AI in the Enterprise 2026. Regulation (EU) 2024/1689 (AI Act), article numbers as amended by the AI Omnibus (Regulation (EU) 2026/1744); Regulation (EU) 2022/2554 (DORA).