AI Agents and the EU AI Act: From Model Compliance to Runtime Governance

Overview

The EU AI Act sorts systems by the risk they create, with obligations that escalate sharply as the risk goes up. For most enterprises the useful takeaway isn't that every AI tool gets treated the same way. It's that the organization needs a reliable way to know the risk profile of the systems it's actually running.

That gets harder with agents. An agent isn't a model behind a chat box. It's a model wired to tools, data sources, memory and an execution environment, and it can operate inside one narrow workflow or coordinate across half a dozen systems. The Act's own definition, in Article 3(1), already assumes this: an AI system is "a machine-based system that is designed to operate with varying levels of autonomy and that may exhibit adaptiveness after deployment."

Governing agents means governing operational systems rather than isolated model calls. The questions shift:

• What is this agent designed to do, and who owns it?
• Which users can invoke it, and which tools and data can it reach?
• Which actions is it allowed to perform, and which need human approval?
• How are its actions logged, and how can its access be modified or revoked?

One more thing worth settling early, because it decides which articles apply to you. Article 3(3) defines a provider as whoever develops a system and "places it on the market or puts the AI system into service under its own name or trademark". Article 3(4) defines a deployer as anyone "using an AI system under its authority except where the AI system is used in the course of a personal non-professional activity". An enterprise wiring a vendor's model into its own agent is usually a deployer, and occasionally becomes a provider without meaning to.

Risk Tiers and Timeline

Four tiers, with obligations escalating sharply moving up.

Unacceptable risk. Eight practices banned outright under Article 5(1), including social scoring, exploitation of age or disability, untargeted scraping of facial images, predictive policing based solely on profiling, biometric categorisation to infer protected characteristics, and the use of AI "to infer emotions of a natural person in the areas of workplace and education institutions" outside medical or safety purposes. Applicable since 2 February 2025. Two later additions, points (ba) and (bb) on non-consensual intimate imagery and child sexual abuse material, apply from 2 December 2026.

High risk. Systems that are safety components of regulated products under Article 6(1) and Annex I, or that fall into the Annex III use cases under Article 6(2). Annex III runs to eight areas: biometrics, critical infrastructure, education and vocational training, "employment, workers' management and access to self-employment", access to essential services and benefits, law enforcement, migration and border control, and administration of justice and democratic processes. The heaviest obligations attach here.

Limited risk. Transparency duties under Article 50, such as informing people that they are interacting with an AI system and marking synthetic content.

Minimal risk. The large remainder, not directly regulated.

An agent rarely sits in one tier. A single workflow might combine a minimal-risk summarization step, a limited-risk customer message, and an action touching an Annex III function. The text gets specific: the creditworthiness entry covers systems "intended to be used to evaluate the creditworthiness of natural persons or establish their credit score, with the exception of AI systems used for the purpose of detecting financial fraud". Classification is a property of what the agent may do at each step, and for whom.

Figure 1 — The applicable calendar after the AI Omnibus. Only the last two boxes moved; everything to the left of them is already law.

What the Omnibus Moved, and What It Didn't

Article 113 is the entry-into-application clause, and it is worth reading rather than summarising. As amended, paragraph (c) reads: "Chapter III, Sections 1, 2, and 3, with the exception of Article 6(5), shall apply from: (i) 2 December 2027 as regards AI systems classified as high-risk pursuant to Article 6(2) and Annex III; and (ii) 2 August 2028 as regards AI systems classified as high-risk pursuant to Article 6(1) and Annex I". Paragraph (d) adds that Articles 102 to 110 apply from 27 July 2026.

The Commission's own framing is that the change simplified the timeline rather than the duties: rules for "systems used in certain high-risk areas" apply from 2 December 2027, and "for systems integrated into products such as lifts or toys, the rules will apply from 2 August 2028". That change reached political agreement on 7 May 2026 and entered into force on 27 July 2026.

Nothing else on the calendar moved. And not every obligation that did move changes what an engineering team builds.

Table 1 — The deferral moved the filing rows and the engineering rows by the same eighteen months. Only the filing rows can actually be done in the last quarter before the date.

Article 99 is the reason the filings still matter. It has applied since 2 August 2025 and sets ceilings of "up to EUR 35 000 000 or, if the offender is an undertaking, up to 7 %" of total worldwide annual turnover for infringing the Article 5 prohibitions, "up to EUR 15 000 000 or ... up to 3 %" for most other obligations including the high-risk requirements, and "up to EUR 7 500 000 or ... up to 1 %" for supplying incorrect, incomplete or misleading information to authorities, whichever figure is higher in each case. The last of those three is worth noticing: a wrong answer in a technical file is its own offence, independent of whether the system was compliant.

Motivation

Early enterprise AI was mostly advisory. A user asked, the model answered, a person decided what to do next. Even a bad answer had a limited blast radius.

Once a model is wired to tools, its output becomes an instruction, and once that instruction runs through an API it touches real workflows: sending messages, updating records, querying databases. None of that makes agents unsafe. It does mean the enterprise has to govern the boundary between reasoning and action.

Take a sales agent connected to a CRM, email, Slack and call notes. Asked to follow up with prospects who raised security concerns at a recent event, it might search meeting notes, identify accounts, read CRM fields, draft emails and send some of them externally. Each step carries different risk. Searching approved event notes isn't the same as reading every customer record. Drafting an email isn't the same as sending it.

Figure 2 — One sales-agent workflow crossing three risk tiers. The classification is a property of the step, not of the agent or the model behind it.

These boundaries erode quietly. An agent scoped to draft emails picks up one new tool during a demo. A pilot connector keeps its production credentials past the pilot. A prompt-injected document talks the agent into exfiltrating data it technically had permission to read. We don't think any of that is exotic; it's the ordinary drift of a system that acts, and governing the reasoning-to-action boundary is what keeps drift from becoming an incident.

Agents also sit awkwardly across the identity categories an enterprise already has. Humans authenticate through identity providers. Applications get API credentials. SaaS tools enforce role-based permissions. Agents act on behalf of users, operate through applications, and decide using model-driven reasoning, and without a dedicated layer their access is hard to reason about.

From Model Governance to Agent Governance

Model governance is about the model: performance, data provenance, evaluation, bias, safety, vendor management. Agent governance is a separate layer covering what the system can do once that model is wired to tools and enterprise context.

The distinction matters because two agents on the same model carry very different risk. A documentation assistant answering from public help-center content is low risk. A finance agent that reads invoices, updates payment status and initiates approval workflows is not. The surrounding permissions create the requirement.

• Model governance asks: which model, who provides it, how does it perform, what are its known failure modes?
• Agent governance asks: what is this agent for, who owns it, which tools and data can it reach, which actions need approval, how is each one recorded?

This matters for compliance specifically. If a company can't say what an agent was allowed to access, what action it attempted and who approved it, it will struggle to demonstrate control. Article 12's logging requirement and Article 14's oversight requirement aren't satisfied by a strong model. They're satisfied by the operational layer built around it.

Architectural Requirements for EU AI Act Readiness

The requirements below are framework-agnostic. They apply whether agents run on an orchestration library, a hosted assistant API, or an internal platform.

1. Agent Inventory

The first requirement is visibility: which agents exist, who owns them, what they're for. An inventory should capture each agent's connected systems, user scope, data access, allowed actions, approval requirements and lifecycle state, structured enough to be queried and tied to the agent's actual runtime configuration rather than sitting in a spreadsheet:

{
  "agent_id": "sales-followup-agent",
  "owner": "revenue-ops",
  "purpose": "Draft follow-up emails for event prospects",
  "model": "provider/model-name",
  "act_role": "deployer",
  "risk_tier": "limited",
  "annex_iii_touchpoints": [],
  "allowed_tools": ["crm.read", "notes.search", "email.draft"],
  "blocked_tools": ["email.send", "crm.update"],
  "approval_required": ["email.send"],
  "data_scope": "accounts owned by invoking user",
  "lifecycle": "active"
}

Without one, a new agent ships with no security review because it looks like a productivity tool, and keeps broad access long after the experiment that justified it ended.

2. Agent Identity

Each agent needs an identity distinct from the human user, the model and the application it operates through. Without that, actions become hard to attribute: a log shows a user updating a record when an agent did it on the user's behalf, or an application calling an API with no indication of which agent initiated it.

Every action should carry both the agent's identity and the identity of the user on whose behalf it acts, so attribution never collapses into one ambiguous service account.

Agent identity is the foundation for accountability.

3. Permission Boundaries

Agents should operate under explicit boundaries defining not just which systems they can reach, but which actions they can take inside them. OAuth scopes and SaaS roles are usually too coarse: an agent may need to draft an email but not send it, read selected CRM fields but not update opportunities, search approved documents but not every file the user can see.

# Permissions for sales-followup-agent
allow:  notes.search       when source == "approved-event-notes"
allow:  crm.read           when field in ["name", "stage", "last_contact"]
allow:  email.draft        always
deny:   crm.update         always
review: email.send         when recipient.domain != "example.com"

The syntax matters less than the granularity: each rule ties an action to the conditions under which it's permitted, denied or escalated.

4. Human Approval and Oversight

Article 14 treats oversight as a design requirement, not a slogan. High-risk systems must be built so they "can be effectively overseen by natural persons during the period in which they are in use", with measures "commensurate with the risks, level of autonomy and context of use". Article 14(4) requires the assigned person be able to "decide, in any particular situation, not to use the high-risk AI system or to otherwise disregard, override or reverse the output", while staying aware of "the possible tendency of automatically relying or over-relying on the output" of one. Article 26(2) adds that deployers "shall assign human oversight to natural persons who have the necessary competence, training and authority".

Read together, those two lines rule out the cheapest implementation. A named overseer with no interface that shows the affected records, and no authority to stop the call, satisfies neither. Approval should scale with risk, which the Agent Access Control Taxonomy names aact:human-oversight/approval-for-high-risk: summarizing approved internal documentation may need no review, while external communications, customer-record changes, data exports and financial workflows usually should.

5. Runtime Permission Checks

Permissions have to be checkable while an agent is running, not only describable in documentation, the taxonomy's aact:authorization-model/per-action-policy. The same action might be allowed in one situation, blocked in another and escalated in a third. A Slack message to a private channel is low risk; the same message company-wide or to an external partner may need review.

The architectural point is that the check belongs where the agent calls a tool, not in the prompt. A model can be instructed to behave, but instructions are advisory; an authorization check at the tool boundary is dispositive.

6. Auditability

A useful audit trail captures the user request, the agent identity, the tools called, the data sources accessed, the decisions applied, any human approvals and the final action. Article 12 requires high-risk systems to "technically allow for the automatic recording of events (logs) over the lifetime of the system". Article 19 requires providers to keep those logs "for a period appropriate to the intended purpose" and "of at least six months, unless provided otherwise in the applicable Union or national law", and Article 26(6) puts the same floor on deployers for logs under their control.

Six months is a floor and a short one. The goal isn't storing unlimited sensitive content; logs should avoid exposing secrets, credentials or unnecessary personal data. But the organization needs enough to reconstruct what happened during an incident or a review.

Strategic Implications

Enterprises will increasingly be expected to prove control over what they deploy, not just document intent to control it. For agentic AI that means operational infrastructure, not model documentation and an acceptable-use policy.

That creates an opening for companies that invest early. A business team ships a new agent faster once the approval path and permission model already exist. Security stops being the function that says no by default, because it can see what it's approving. And agent behavior that's already logged and attributable is most of the evidence a compliance review would otherwise go chase down.

There's a portability argument too. The Act is the most developed regime today, not the only one taking shape. We think the controls it implies (inventory, identity, least privilege, oversight, runtime checks, audit) are close to what most emerging frameworks and internal security reviews will end up asking for.

Where Fabriq Fits

Agentic Fabriq covers one slice of the list above. It holds each user's credentials in a vault and attaches them server-side at the moment of the call, so the agent never handles the secret; it refreshes them automatically with last-used tracking; and it makes an agent's effective tool list the intersection of the user's scopes and the agent's. Every call carries two identities, the agent and the acting user, plus an audit record, which is the attribution requirement in section 2 above.

It does not reach into the provider on your behalf. Clearing a vault copy is not revoking a grant upstream, so the call to the provider's revocation endpoint stays yours.

Frequently Asked Questions

When do EU AI Act high-risk obligations actually apply? Article 113(c) sets 2 December 2027 for systems classified high-risk under Article 6(2) and Annex III, and 2 August 2028 for those classified under Article 6(1) and Annex I, meaning high-risk AI embedded in products already covered by EU product legislation.

Was the 2 August 2026 date cancelled? Only for the high-risk package. The Act still applies from 2 August 2026 in general, and Article 50's transparency duties take effect then. Articles 102 to 110 apply from 27 July 2026.

Does the AI Act regulate AI agents specifically? No. It regulates AI systems, defined in Article 3(1) as machine-based systems operating "with varying levels of autonomy". An agent is one of those, and its classification follows the use case rather than the architecture.

Are we a provider or a deployer? Article 3(4) makes you a deployer if you use a system under your own authority in a professional context. Article 3(3) makes you a provider if you place a system on the market or put it into service under your own name or trademark, which can happen when an internal agent is offered to customers.

How long do we have to keep agent logs? At least six months under Articles 19 and 26(6), measured against the intended purpose of the system, unless other Union or national law says otherwise. Sector rules and incident-response needs usually push it well beyond that.

What are the penalties? Article 99, applicable since 2 August 2025, sets ceilings of €35m or 7% of worldwide turnover for prohibited practices, €15m or 3% for most other obligations, and €7.5m or 1% for supplying incorrect information, whichever is higher.

Does a chatbot need to say it's an AI? Article 50(1) requires providers to design systems intended to interact directly with natural persons so that those persons "are informed that they are interacting with an AI system", from 2 August 2026.

Toward Production-Ready Agentic AI

Enterprise AI won't be defined only by better models. It will be defined by the systems that make models usable in real organizations: identity, permissions, connectivity, approvals and observability.

The Act reinforces that shift without being the whole reason for it. As AI systems become more capable and more embedded in business workflows, enterprises will need to show they understand what those systems are doing and that they can control them.

For AI agents the central governance question is simple: can the organization explain and enforce what each agent is allowed to do? If the answer is no, a deferred deadline doesn't make the agent production-ready. The work that was always going to matter was never on the high-risk clock to begin with.

Sources

All URLs read 2026-09-29.

• Agent Access Control Taxonomy — the nine dimensions behind the six requirements above: human oversight as a graded term rather than a slogan, and per-action authorization as distinct from a scope fixed at grant time.
• EU AI Act, Article 113 (Entry into force and application) — the amended paragraph (c) quoted above, and paragraph (d) on Articles 102 to 110 from 27 July 2026.
• European Commission, Regulatory framework for AI — the AI Omnibus timeline change, the 7 May 2026 political agreement and entry into force on 27 July 2026.
• EU AI Act, implementation timeline — the phased dates from 1 August 2024 onward, including 2 December 2026 for the newer Article 5 prohibitions.
• EU AI Act, Article 3 (Definitions) — "varying levels of autonomy" in the AI system definition, and the provider and deployer definitions in 3(3) and 3(4).
• EU AI Act, Article 5 (Prohibited AI practices) — the eight prohibitions, the emotion-recognition wording, and the 2 December 2026 date for points (ba) and (bb).
• EU AI Act, Annex III (High-risk AI systems) — the eight use-case areas and the creditworthiness item with its fraud-detection exception.
• EU AI Act, Article 12 (Record-keeping) — automatic recording of events over the lifetime of the system.
• EU AI Act, Article 14 (Human oversight) — effective oversight, measures commensurate with autonomy, automation bias, and the power to disregard, override or reverse.
• EU AI Act, Article 19 (Automatically generated logs) — the at-least-six-months retention floor for providers.
• EU AI Act, Article 26 (Obligations of deployers) — paragraph 2 on competence, training and authority; paragraph 6 on deployer log retention.
• EU AI Act, Article 50 (Transparency obligations) — the disclosure duty for systems interacting directly with people, in force 2 August 2026.
• EU AI Act, Article 99 (Penalties) — the €35m/7%, €15m/3% and €7.5m/1% ceilings, applicable since 2 August 2025.