The EU AI Act (Regulation 2024/1689) requires organisations deploying AI agents in high-risk domains to maintain six areas of compliance: continuous risk management (Article 9), technical documentation (Article 11), traceability and record-keeping (Article 12), transparency (Article 13), human oversight (Article 14), and incident reporting (Article 73). For organisations running agentic AI, this means every AI agent needs an explicit role definition, documented authority boundaries, a tracked governance history, and structured human oversight.
For a foundational understanding of what is needed for successful agentic AI governance, see our article: AI Agent Governance: The Organisational Readiness Gap
Key Takeaways
The EU AI Act treats AI agent governance as an organisational requirement, not just a technical one. For organisations deploying agentic AI systems, including autonomous AI agents and multi-agent systems, the Act mandates explicit governance across six compliance areas: continuous risk management (Article 9), technical documentation (Article 11), traceability and record-keeping (Article 12), transparency (Article 13), human oversight (Article 14), and incident reporting (Article 73). Each one demands explicit organisational structure — defined roles, clear authority boundaries, and tracked governance decisions — not just engineering controls.
Most organisations running AI agents today cannot answer the questions regulators will ask. Who authorised this agent to act? What is it allowed to decide? What happens when something goes wrong, and where is the evidence? Without explicit role definitions, documented authority boundaries, and a timestamped history of governance decisions, these questions have no defensible answer. The compliance gap is structural, not administrative. It cannot be closed by producing documents after the fact.
The enforcement deadline for high-risk AI systems is August 2, 2026, with a possible extension to December 2, 2027. The European Commission's Digital Omnibus proposal may push the Annex III deadline to late 2027, but that proposal is still in legislative proceedings and is not guaranteed. The requirements themselves are unchanged regardless of timeline. Organisations that delay are accumulating ungoverned agent activity with no audit trail — a gap that is impossible to fill retroactively.
Human oversight under the Act means systemic governance, not someone watching a screen. Article 14 requires that qualified people can understand an AI system's capabilities and limitations, detect anomalies, interpret its output, override its decisions, and shut it down. Oversight roles must be formally assigned to individuals with the competence, authority, and structural support to intervene effectively. The Act distinguishes between ceremonial oversight and the real thing.
Non-compliance carries fines of up to €35 million or 7% of global annual turnover. The penalty structure scales by violation type: up to €35 million or 7% of turnover for prohibited practices, up to €15 million or 3% for high-risk system violations, and up to €7.5 million or 1% for providing incorrect information to authorities. SMEs and startups are subject to proportionally lower caps, but the obligations remain the same.
Continuous, structure-based governance satisfies the Act's requirements as a natural byproduct of working. Organisations that define explicit roles, purposes, accountabilities, and authority boundaries for every agent — and evolve those definitions through tracked governance processes — generate compliant documentation, traceability, and risk management evidence automatically. Retrofitting this after deployment is expensive and, for the period before tracking began, genuinely impossible.
Platforms like Nestr.io can cover the organisational (and governance) requirements of the Act, but not all technical ones. Nestr provides the structural layer: explicit role definitions for human and AI agents, tracked governance decisions with immutable timestamped history, transparent authority boundaries queryable through MCP integration, and continuous tension-based risk surfacing. What it does not cover, and what no governance platform can, are the engineering obligations: training data quality and bias mitigation (Article 10), technical robustness and cybersecurity (Article 15), transparency labelling in product interfaces (Article 50), and formal conformity assessments and EU database registration. Organisations need both layers: the organisational foundation that makes accountability traceable, and the technical infrastructure that makes the AI system itself compliant.
The EU AI Act (Regulation (EU) 2024/1689) is the first comprehensive AI governance framework in law. It establishes binding requirements for how organisations deploy and govern AI agents, including agentic AI systems that operate with varying degrees of autonomy. It entered into force in August 2024 and is being phased in over several years. The most significant deadline for organisations running AI agents is August 2, 2026, when the rules for high-risk AI systems become enforceable. The European Commission's Digital Omnibus proposal may extend this to December 2027 at the latest, but that proposal is still in legislative proceedings and is far from certain.
Most of the conversation around the Act focuses on deadlines, fines, and risk classifications. Fines of up to €35 million or 7% of global annual turnover for prohibited practices. Up to €15 million or 3% for high-risk violations. These numbers are serious, and they should be.
But here is what strikes me: the actual requirements of the Act are not exotic. They are not some alien compliance burden dreamt up by regulators who don't understand how technology works. They are, in essence, a codification of what any well-run organisation should already have in place when it gives autonomous systems the authority to act on its behalf. Let me put it more simply: the EU AI Act doesn't ask you to do anything unreasonable. It asks you to be clear about how your AI agents operate. And the uncomfortable truth is that most organisations cannot answer that question today.
AI agents operating in domains like employment, credit decisions, education, law enforcement, or critical infrastructure are classified as high-risk under the Act. Depending on the level of risk, the Act mandates six core areas of compliance. Let's walk through them, because the language of the regulation maps remarkably well to organisational fundamentals.
1. AI Risk Management System (Article 9)
Not a one-off assessment. A continuous, iterative AI risk management process running throughout the entire lifecycle of the AI system. This aligns with broader AI risk management frameworks like NIST AI RMF that emphasise ongoing risk identification, not just initial assessment. You must identify and analyse known and foreseeable risks. You must estimate and evaluate risks under both intended use and foreseeable misuse. You must adopt targeted measures to address them. And you must test whether those measures actually work. This is not a compliance checkbox. This is an ongoing practice.
2. Technical Documentation (Article 11)
Before you put a high-risk AI system on the market or into service, you need comprehensive documentation. What the system does. Why it exists. How it was designed. What its capabilities and limitations are. What risks were identified and how they were assessed. In other words: can you describe what your agent's purpose is, what it's accountable for, and where its authority begins and ends?
3. Traceability and Record-Keeping (Article 12)
AI systems must have automatic logging capabilities that record events throughout their lifecycle. Deployers must retain these logs for at least six months. The goal is to enable risk identification, post-market monitoring, and the ability to trace what happened when something goes wrong. Here is where most organisations running agents today are completely exposed. If your agents are operating across multiple systems with no centralised record of their decisions, actions, and the governance context in which those actions were taken, you have no trail to show a regulator, nor anything to learn from yourself.
4. Transparency (Article 13)
The system must be designed so that deployers can understand its output and use it appropriately. Instructions for use must explain accuracy, robustness, known limitations, and cybersecurity properties. This is not just about disclosing that someone is talking to a bot. It is about whether the people responsible for your agents, and the people affected by their decisions, can actually understand what those agents are doing and why.
5. Human Oversight (Article 14)
This one gets misunderstood more than any other. The Act does not require that a human approves every agent action. It requires that potentially risky AI systems are designed with appropriate human-machine interface tools allowing effective oversight by natural persons. Specifically, people must be able to understand the system's capabilities and limitations, detect anomalies and unexpected performance, correctly interpret the system's output, decide not to use the system or override its decisions, and intervene or shut it down when necessary.
The key word is effective. Not ceremonial. Not a rubber stamp. Not someone who theoretically oversees an agent but has no practical ability to understand what it's doing. Effective oversight means the people in oversight roles have the competence, the authority, and the structural support to actually intervene. This is the difference between "human-in-the-loop" as a buzzword vs as a genuine governance practice.
6. Incident Reporting (Article 73)
Providers must report serious incidents to market surveillance authorities immediately upon establishing a causal link. Deployers must inform the provider and relevant authority if a system presents a risk and suspend use. The question this raises is not whether you have an incident reporting process. It is whether your governance structure makes it possible for anyone, human or agent, to surface a problem the moment it appears, and whether the decision to respond is clearly assigned.
Here is what I think most organisations are not prepared for. When something goes wrong with an agent, and with agents operating autonomously it will, the first question from a regulator, a client, or a partner will not be "what went wrong technically?"
It will be: who was responsible, and what was the governance framework?
Can you point to the role definition that gave this agent its authority? Can you show the policy that set the boundaries of that authority? Can you demonstrate the governance decision that created or modified that policy? Can you trace the history of that decision?
The EU AI Act Service Desk has already confirmed that AI agents operating in high-risk domains are subject to Chapter III obligations. The Future Society's report on governing AI agents under the Act makes the point clearly: managing agent risks effectively requires governance along the entire value chain, accounting for asymmetries between model providers, system providers, and deployers. And this is where it gets structurally interesting. As a recent European Law Blog analysis pointed out, when an agent autonomously selects a tool that takes an action with consequences, the question of who determined that action is genuinely difficult. Was it the model provider? The system provider who configured the tools? The deployer who authorised autonomous operation? Each actor has partial visibility and control, yet the Act's accountability framework assumes someone is responsible.
If you don't have explicit roles, domains, and policies that define what your agents can and cannot do, and a tracked history of how those boundaries were set, you simply cannot answer these questions. No amount of last-minute documentation will solve that.
Most compliance efforts for the EU AI Act are following a predictable pattern: hire consultants, produce documentation, create a risk register, assign a compliance officer, file it away. Check the box.
This approach fails for AI agents for a simple reason: agents are not static systems. They operate continuously. Their context changes. The organisation around them evolves. A compliance snapshot taken at a single moment in time says nothing about how the agent has been operating since then, how its role has changed, or what governance decisions shaped its current behaviour.
The Act itself recognises this. Article 9 explicitly calls for a continuous iterative process of risk management. Article 72 requires post-market monitoring that feeds back into the risk management system. This is not a one-and-done exercise. It is an ongoing practice. What's needed is not a compliance project. It's a way of working where governance is continuous, structural, and built into how agents operate day to day. Where every role, human or AI, has an explicit purpose, clear accountabilities, defined domains of authority, and living policies that evolve through a structured process. Where every change to that structure is captured, timestamped, and available for review.
Here is something I did not expect when I first read the Act in detail: the requirements it places on AI agents are the same requirements most organisations have never properly met for their human roles.
Think about it. Can you point to a document that defines the purpose, accountabilities, and authority boundaries of your social media marketing team members? One that is current, not a job description from three years ago? Can you show the governance decision that gave your operations lead the authority to approve vendor contracts up to €50,000? Can you trace when that authority was granted, who was involved in the decision, and what constraints were set?
Most organisations cannot. Not because they are negligent, but because they never had a system that required it. Human roles evolved informally. Authority was assumed, not granted through a documented process. Accountability was implicit, understood through culture and habit rather than defined in a structure anyone could inspect.
AI agents have forced the issue. Because an agent cannot operate on implicit understanding. It has no cultural memory. It cannot "just know" what it is supposed to do. You have to define its purpose, its accountabilities, its domains of authority, and its constraints explicitly, or it will do the wrong things, in the wrong places, with no way to explain why.
The EU AI Act codifies this into law for high-risk AI systems. But the deeper opportunity is this: the structural clarity the Act demands for your AI agents is exactly the same clarity your human roles have always needed. Implementing the regulation is not just a compliance exercise. It is a chance to finally build the organisational foundation you should have had all along, for everyone.
The approach that satisfies the Act's requirements most naturally is not a compliance layer bolted onto your existing organisation. It is a single, unified governance structure where every role (human or AI) is defined with the same rigour.
This means every role has an explicit purpose: a clear statement of why it exists and what it serves. Every role has defined accountabilities: the ongoing activities and outcomes the role is responsible for. Roles might have specific domains: the areas where it has full decision-making authority, and the boundaries where that authority stops. And every role is subject to policies: the constraints and guardrails that govern how it can act within the domains.
This is not a theoretical framework. Role-based governance structures have been developed and refined by practitioners over decades. What is new is that the EU AI Act is now demanding it by law for AI systems, and that platforms exist to make it operational at scale.
When you build this structure, something remarkable happens: the Act's six core compliance areas stop being separate obligations you need to manage, and start becoming natural byproducts of how your organisation works.
Article 9 requires continuous, iterative risk management throughout the AI system's lifecycle. In most organisations, this translates to a risk register that someone updates quarterly. That approach fails for AI agents because agents operate continuously in changing contexts. A risk assessment from three months ago says nothing about what an agent is doing today.
But when your organisation works within a structure where anyone (human or ai agent) can raise a tension the moment something is not working, risk management becomes embedded in daily operations. Every tension about an agent overstepping, underperforming against its accountabilities, or producing unintended consequences is a risk signal. Every governance proposal to adjust a role definition, tighten a policy, or redraw an authority boundary is a risk mitigation measure. And every one of those is captured and timestamped automatically.
In Nestr, tensions are the fundamental unit of organisational feedback. They represent the gap between how things are and how they should be. When someone notices potential harm to the organization, they raise a tension. That tension enters a structured process. If the tension requires a change in the governance structure (rule set), the team reviews it, proposes a change, tests whether the change addresses the issue without causing harm, and adopts it. The governance record shows exactly what changed, when, and why.
This is what Article 9 actually asks for. Not a document. A practice.
Article 11 requires comprehensive technical documentation before a high-risk AI system is placed into service: what the system does, why it exists, how it was designed, what its capabilities and limitations are, what risks were identified and how they were assessed.
Most organisations approach this by writing a document. That document is accurate on the day it is written, and begins decaying immediately. The agent's role shifts. Its policies get adjusted in a meeting that nobody records. Its area of impact expands because someone asked it to handle something new and nobody updated the paperwork. Three months later, the documentation describes a system that no longer exists.
When the role definition itself is the operating structure, not a separate compliance artefact, this problem disappears. In Nestr, a role's purpose, accountabilities, domains, and policies are not descriptions of what the agent does. They are the structure within which the agent operates. When a governance meeting modifies the role, the documentation updates automatically.
The same applies to human roles. When your team members' accountabilities are defined in the same system, with the same rigour, and evolve through the same governed process, you always know what any role is responsible for. Not what it was responsible for when someone last updated a job description, but what it is responsible for right now.
Article 12 requires automatic logging and record-keeping throughout the AI system's lifecycle. Deployers must retain logs for at least six months. The goal is to enable risk identification, post-market monitoring, and the ability to reconstruct what happened when something goes wrong.
This is where organisations running agents without explicit governance are most exposed. If your agents are operating across multiple systems with no centralised record of their decisions, actions, and the governance context in which those actions were taken, you have nothing to show a regulator. And you have nothing to learn from either.
When governance decisions, role changes, project updates, and operational actions all live in a single system, traceability is not something you need to construct. It accumulates as a natural byproduct of working. In Nestr, every governance decision carries a full, immutable, timestamped history. Every project update, every action, every comment is captured within the context of the role that produced it. When a regulator asks "show me what this agent did and why," you can answer. When they ask "show me how the governance structure evolved," you have the complete trail. When they ask "who decided this agent could do that," you can point to the specific governance proposal, the tensions that drove it, and the date it was adopted.
The critical word is "from day one." Traceability cannot be retrofitted. You cannot produce a governance trail for a period when no explicit governance was happening. Every month of ungoverned agent activity is a permanent gap in your compliance record.
Article 13 requires that systems are designed so deployers can understand their output and use them appropriately. This is not just about labelling a chatbot as AI. It is about whether the people responsible for your agents, and the people affected by their decisions, can actually understand what those agents are doing and why.
When your organisational structure is explicit and inspectable, transparency is structural, not performative. Every role's purpose, accountabilities, domains, and policies are visible to the entire organisation. Anyone can look up what a role is responsible for, where its authority begins and ends, and what policies constrain its behaviour.
This becomes particularly powerful when AI assistants can query that structure directly. Through Nestr's MCP integration, an AI assistant like Claude can access the full organisational context: circles, roles, accountabilities, domains, and policies. Ask "who has the accountability for customer onboarding?" and get a clear answer. Ask "what policies apply to the recruitment circle?" and see the constraints that govern how agents in that domain are allowed to operate.
This is transparency that works for both human oversight and regulatory scrutiny. It is not a report someone prepared. It is the live, queryable truth of how your organisation is structured and how authority is distributed.
Article 14 is where most organisations get it wrong, and where the opportunity for genuine improvement is greatest.
The Act does not require that a human approves every agent action. It requires that the system is designed so that qualified people can understand its capabilities and limitations, detect anomalies, interpret its output, override its decisions, and shut it down. The key word in the regulation is "effective." Not ceremonial. Not a rubber stamp.
Effective oversight is structural. It means the relevant roles have the competence, the authority, and the organisational support to actually intervene. And it means those roles are themselves explicitly defined, with clear accountabilities, so that everyone knows who is responsible for monitoring what.
This is where the single-structure approach pays off most significantly. When both AI agents and humans operate within the same governance framework with defined roles, explicit authority, and tracked decisions, oversight (or really, transparency) becomes systemic rather than personal. It does not depend on any individual's vigilance. It depends on the structure.
In practice, this means human team members stay involved at the governance level: setting and evolving the boundaries within which agents execute. When someone notices a problem, they raise a tension. That tension enters the process. The structure adapts. The agent's behaviour changes because the governance structure has changed.
This is the difference between "human-in-the-loop" as a compliance checkbox and humans maintaining genuine strategic insight in how autonomous systems operate within their organisation.
Let me be direct about what I think is the real prize here.
Most organisations are approaching the EU AI Act as a burden: a set of obligations to satisfy for their AI agents so they can avoid fines. And they are planning to satisfy those obligations through traditional compliance methods. Consultants, documentation projects, risk registers, a compliance officer…
That approach misses the point entirely. The Act's requirements are not exotic. They are a description of what a well-governed organisation looks like. And the structural work required to comply for AI agents is the same structural work that would make your entire organisation clearer, faster, and more accountable.
When you define explicit roles with clear purposes, accountabilities, and authority boundaries for your AI agents, you create a template that applies equally to every human role. When you establish a governance rhythm for evolving those definitions, you create a process that works for any organisational change. When you build traceability from day one, you create an institutional memory that serves everyone.
The organisations that will come out of this transition strongest are not the ones that treat the EU AI Act as a checkbox exercise for their AI systems. They are the ones that recognise the regulation for what it is: a forcing function to build the organisational clarity that makes everything — human and AI — work more aligned and productive.
The structure exists. The tools to implement it exist. The question is whether you start now, while you can build the foundation properly, or later, when you are trying to reconstruct what should have been tracked all along.
Whether you are a growing company of 10 people with your first few AI agents, or an enterprise with agents operating across multiple teams and systems, the implications are the same.
Organisations already running agents without explicit governance are accumulating compliance risk every day. Not because the regulation is unreasonable, but because they cannot prove what their agents are authorised to do, who set those boundaries, or what happened along the way. Retrofitting this is expensive and, for the period before tracking started, probably impossible.
Organisations about to deploy agents have a rare opportunity to get the foundation right from the start. Define the roles. Set the purposes, accountabilities, domains, and policies. Establish the governance rhythm. Start tracking from day one. The compliance evidence builds itself as a natural byproduct of working.
For organisations in regulated sectors like healthcare, financial services, education, law enforcement, or critical infrastructure, the urgency is higher still. These are the domains the Act specifically identifies as high-risk. The scrutiny will come first to you.
And if you are thinking "we'll wait for the Digital Omnibus to give us more time," consider this: the proposal, while it may push the Annex III deadline to December 2027, does not change a single requirement. It only changes when enforcement begins. Every month you wait is a month of agent activity with no governance trail.
Nestr.io is the platform where governance, work, and compliance converge. It lets you define your organisational structure through explicit roles, circles, and policies, and it applies the same structure to all roles, whether filled by AI agents or people. Every agent in Nestr fills a role with a defined purpose, clear accountabilities, bounded domains of authority, and living policies that the team sets and evolves through structured governance. That role definition is not a compliance document sitting in a folder. It is the actual operating context for the agent, which means it cannot fall out of date.
When specific mandates need to be adjusted, anyone in the team can raise a tension. That tension enters a structured governance process where the team proposes, tests, and adopts changes to roles, policies, or authority boundaries. Every governance decision is captured in a full, immutable, timestamped history. This is continuous risk management as a practice, not a register. It is documentation that stays current because it is the structure. It is traceability built from day one as a natural byproduct of working, not reconstructed after the fact.
Agents do their work within clearly defined projects, posting action-by-action updates that are visible to the team and reviewed in regular tactical meetings. The entire organisational context, every role, every policy, every domain boundary, is transparent and queryable by both humans and AI assistants through Nestr's MCP integration. Human oversight operates at the governance level, where teams set and evolve the boundaries within which agents execute, rather than depending on any single person watching a screen. And incidents surface the moment a tension is raised, not after a quarterly review.
Nestr supports role-based governance models, so you can work the way that fits your organisation while generating the compliance evidence regulators will expect. Whether you are governing your first agent or coordinating dozens across multiple teams, the structure scales with you, and the audit trail builds itself.
Nestr does not cover everything the Act requires, and it is not trying to. Some requirements are fundamentally about the technical infrastructure of your AI systems, not about how your organisation governs them.
Training data quality and bias mitigation (Article 10) depend on the tools and processes your engineering team uses to build and validate models. If your recruitment agent was trained on historically biased hiring data, that is a data pipeline problem, not a governance one.
Technical accuracy, robustness, and cybersecurity (Article 15) are about how your AI system performs under stress, resists adversarial attacks, and stays secure over time. These require engineering and security practices that live in your development and operations stack.
Transparency labelling (Article 50) is a design and UX concern: when your chatbot talks to a customer, the interface needs to make clear they are interacting with AI, and any synthetic content needs to be marked as such. That happens in the product, not in the governance platform.
Conformity assessments, CE marking, and registration in the EU database are formal regulatory procedures that every provider must complete before placing a high-risk system on the market. And while Nestr surfaces incidents internally the moment a tension is raised, the formal step of reporting serious incidents to the relevant market surveillance authority (Article 73) requires its own process and communication channel with the regulator.
These are responsibilities that every organisation deploying high-risk AI must address regardless of what platform they use. What Nestr provides is the organisational foundation that holds all of it together: the governance structure, the tracked decisions, the clear accountability chains, and the evidence that your agents have been operating within boundaries your team deliberately set. Without that foundation, even the best technical compliance efforts have no organisational home.
The EU AI Act is not the reason to build proper governance for your AI agents. It is a regulatory confirmation that proper governance was always necessary.
The organisations that will thrive in an era of agentic AI are not the ones scrambling to produce compliance documents before a deadline. They are the ones where governance is how the work happens. Where every role has an explicit purpose and clear boundaries. Where authority is distributed through structure rather than concentrated in management chains. Where every decision, every change, and every lesson is captured and available for anyone, human or AI, to learn from.
This is not new. Those of us in the self-organisation community have been building these practices (and the required software) for decades. What is new is that regulators are now codifying them into law, and that AI agents are making them more urgent than ever.
The tools exist. The governance principles are proven. The regulatory framework is demanding exactly what good organisational design has always demanded. The question is whether we step up and bring the clarity that's needed, or whether we wait for traditional command-and-control thinking to fill the void with something far less effective.
I know which option I believe in. Let's build it.
| Your situation | Risk level | What applies | What you need to do |
|---|---|---|---|
| Agent handles internal tasks like drafting emails, summarising documents, or organising files | Minimal / no risk | No specific obligations | Nothing required. Best practices encouraged. |
| Agent interacts directly with people (chatbot, customer-facing assistant) | Limited risk | Transparency obligations (Article 50) | Inform users they are interacting with an AI system. If the agent generates synthetic content, mark it as AI-generated. |
| Agent generates or manipulates images, audio, video, or text that could be mistaken for real | Limited risk | Transparency and labelling (Article 50) | Ensure outputs are marked as AI-generated in a machine-readable format. |
| Agent operates in employment or recruitment (screening CVs, ranking candidates, making hiring decisions) | High risk (Annex III) | Full Chapter III obligations | Risk management system, technical documentation, traceability, transparency, human oversight, incident reporting, conformity assessment. |
| Agent makes or informs credit and insurance decisions | High risk (Annex III) | Full Chapter III obligations | Same as above. |
| Agent operates in education (admissions, grading, exam proctoring) | High risk (Annex III) | Full Chapter III obligations | Same as above. |
| Agent is used in law enforcement, migration, or border control | High risk (Annex III) | Full Chapter III obligations | Same as above. |
| Agent operates critical infrastructure (energy, transport, water, digital) | High risk (Annex III) | Full Chapter III obligations | Same as above. |
| Agent is a safety component of a regulated product (medical device, vehicle, machinery) | High risk (Annex I) | Full Chapter III obligations + product-specific regulation | Same as above, plus conformity assessment under sector-specific EU law. Deadline: August 2027 (or August 2028 if Digital Omnibus is adopted). |
| Agent profiles individuals (automated processing of personal data to assess aspects of a person's life) | Always high risk | Full Chapter III obligations | Profiling triggers high-risk classification regardless of domain. |
| Agent manipulates behaviour through subliminal or deceptive techniques | Prohibited | Banned outright (Article 5) | Do not deploy. Has been enforceable since February 2025. Fines up to €35M or 7% of global turnover. |
| Agent performs social scoring or real-time remote biometric identification in public spaces (with limited exceptions) | Prohibited | Banned outright (Article 5) | Do not deploy. |
Note: One obligation applies to virtually every organisation using AI professionally: AI literacy (Article 4). Since February 2025, providers and deployers must ensure that staff and stakeholders involved in AI operations have sufficient understanding of AI's opportunities, risks, and potential harms.
| Article | Title | What it requires in practice |
|---|---|---|
| Article 4 | AI Literacy | Ensure staff and stakeholders have sufficient understanding of AI, its opportunities, risks, and harms. Applies to all providers and deployers. In force since February 2025. |
| Article 5 | Prohibited AI Practices | Bans manipulative, exploitative, and social scoring AI systems outright. Includes real-time remote biometric identification in public spaces (with limited law enforcement exceptions). Enforceable since February 2025. |
| Article 6 | Classification Rules for High-Risk AI Systems | Defines how AI systems are classified as high-risk: either because they are listed in Annex III (use-case based) or because they are safety components of regulated products (Annex I). Systems that profile individuals are always high-risk. |
| Article 9 | Risk Management System | Establish a continuous, iterative risk management process running throughout the AI system's lifecycle. Identify, analyse, estimate, and evaluate risks. Adopt and test mitigation measures. Review and update regularly. |
| Article 10 | Data Governance and Quality | Ensure training, validation, and testing datasets are relevant, representative, and as free of errors as possible. Take measures to detect, prevent, and mitigate biases. |
| Article 11 | Technical Documentation | Prepare and maintain comprehensive documentation before the system is placed on the market. Must cover design, purpose, capabilities, limitations, risk assessments, and testing results. |
| Article 12 | Record-Keeping (Traceability) | High-risk AI systems must automatically log events throughout their lifecycle. Logs must support risk identification, post-market monitoring, and operational oversight. Deployers must retain logs for at least six months. |
| Article 13 | Transparency and Provision of Information | Design systems so deployers can understand output and use the system appropriately. Provide instructions covering accuracy, robustness, known limitations, and cybersecurity. |
| Article 14 | Human Oversight | Design systems to allow effective oversight by natural persons. People must be able to understand the system, detect anomalies, interpret output, override decisions, and intervene or shut down the system. Oversight roles must be assigned to people with the necessary competence, training, and authority. |
| Article 15 | Accuracy, Robustness, and Cybersecurity | Maintain appropriate levels of accuracy, robustness, and cybersecurity throughout the system's lifecycle. Systems must resist errors, misuse, and adversarial attacks. |
| Article 17 | Quality Management System | Providers must establish a quality management system covering policies, procedures, and processes for design, development, testing, deployment, and post-market monitoring. |
| Article 26 | Obligations of Deployers | Deployers must use systems as per instructions, assign human oversight, ensure input data is relevant, monitor operation, keep logs, inform workers, and report risks or serious incidents to the provider and relevant authorities. |
| Article 50 | Transparency Obligations for Certain AI Systems | AI systems interacting with people must inform them they are dealing with AI (unless obvious). Emotion recognition and biometric categorisation systems require disclosure. AI-generated synthetic content must be marked as such. |
| Article 72 | Post-Market Monitoring | Providers must establish a post-market monitoring system proportionate to the AI system's nature and risk level. Feeds back into the risk management system. |
| Article 73 | Reporting of Serious Incidents | Providers must report serious incidents to market surveillance authorities immediately upon establishing a causal link. Deployers must report risks and suspend use if needed. |
| Article 99 | Penalties | Non-compliance fines: up to €35M or 7% of global turnover for prohibited practices, up to €15M or 3% for high-risk violations, up to €7.5M or 1% for providing incorrect information. SMEs and startups benefit from proportionally lower caps. |
Not automatically. The Act uses a risk-based classification. AI agents operating in domains listed in Annex III, including employment, credit scoring, education, law enforcement, and critical infrastructure, are classified as high-risk and subject to the full Chapter III obligations. Agents that interact with people must also meet transparency requirements under Article 50. Agents operating in lower-risk domains face fewer obligations but are still encouraged to follow best practices.
The original statutory deadline is August 2, 2026 for Annex III high-risk systems. The European Commission's Digital Omnibus proposal, published in November 2025, would extend this to December 2, 2027 at the latest. That proposal is still in legislative proceedings between the European Parliament and the Council. If it is not adopted before August 2026, the original deadline stands. Prudent organisations should plan for the earlier date and treat any extension as extra preparation time, not a reason to delay.
The Act assigns obligations based on your role in the value chain: provider (who develops the system), deployer (who operates it), or other operators. Within your organisation, accountability traces to whoever defined the agent's role and governance framework. This is why explicit role definitions, tracked governance decisions, and clear authority boundaries matter so much. They make accountability traceable. Without them, the answer to "who was responsible?" is effectively "nobody," which is the worst possible answer for a regulator.
Not someone watching a screen. Article 14 requires that the system is designed so that qualified people can understand its capabilities and limitations, detect problems, interpret its output, override its decisions, and shut it down. This means oversight roles must be formally assigned to people with the competence, training, and authority to intervene, along with the structural support to do so effectively. The key distinction is that oversight needs to be systemic and built into the governance structure, not dependent on one person's constant attention.
A compliance team can help you understand the requirements and coordinate the work. But the Act's requirements for continuous risk management, ongoing documentation, traceability, and effective human oversight cannot be achieved by a separate team producing reports about what the rest of the organisation does. They require governance to be built into how your agents operate. The structure itself must generate the compliance evidence, not a team that reconstructs it after the fact.
No. You need to make your existing structure explicit. Most organisations already have implicit roles and responsibilities for their AI agents. They are just not documented, not tracked, and not governed through a structured process. Start by making what exists visible: who authorised each agent, what it is responsible for, what it can decide, and what policies constrain it. Then establish a governance rhythm to evolve that structure as you learn.
One team. One or two agents. Clear role definitions with purpose, accountabilities, domains, and policies for each. A regular tactical sync to review how agents are performing and surface operational tensions. A monthly governance meeting to evolve the structure. Track everything from day one. That is enough to prove the pattern, build your compliance trail, and scale from there.
Significantly. AI agents processing personal data must comply with both the EU AI Act and GDPR. The Digital Omnibus proposal also includes amendments to clarify how GDPR applies to AI training data and processing. The governance structures required by the AI Act, including documentation, risk assessment, transparency, and human oversight, align closely with GDPR's accountability principle. Building one framework well serves both.
The EU AI Act classifies AI systems by risk level, not by technology type. Agentic AI systems — including autonomous AI agents that make decisions and take actions independently — are subject to the same rules as any AI system operating in their domain. If an autonomous AI agent operates in employment, credit decisions, education, or critical infrastructure, it is classified as high-risk and must comply with all Chapter III obligations.
Traditional IT governance for AI focuses on technical controls: model validation, data quality, access management. AI agent governance adds the organisational layer: what is this AI agent responsible for? What is it authorised to decide? Where does its authority begin and end? How does the organisation evolve those boundaries? The EU AI Act requires both layers.
Both share the principle that AI risk management must be continuous and iterative. The NIST AI RMF provides voluntary guidance; the EU AI Act creates binding legal obligations. Organisations operating in both jurisdictions benefit from a unified AI governance approach: defining roles, tracking decisions, and managing risk through structured governance satisfies the intent of both frameworks.
The EU AI Act addresses this by prohibiting manipulative and exploitative AI practices outright (Article 5) and by requiring transparency, human oversight, and accountability for all high-risk systems. For organisations deploying AI agents, the question is practical: who is responsible when an autonomous agent causes harm? The Act requires that accountability be traceable through documented governance.
EU AI Act
Regulation (EU) 2024/1689, Official Framework: digital-strategy.ec.europa.eu
EU AI Act Implementation Timeline: ai-act-service-desk.ec.europa.eu
EU AI Act Service Desk, FAQ on AI Agents: ai-act-service-desk.ec.europa.eu/faq
High-Level Summary of the AI Act: artificialintelligenceact.eu
Digital Omnibus Proposal
IAPP, EU Digital Omnibus Analysis: iapp.org
European Parliament Legislative Train: europarl.europa.eu
AI Agents and Governance
The Future Society, Governing AI Agents under the EU AI Act: thefuturesociety.org
European Law Blog, Agentic Tool Sovereignty and Compliance Gaps: europeanlawblog.eu
Mayer Brown, Governance of Agentic AI Systems (2026): mayerbrown.com
IAPP, Understanding AI Agents, Risks and Safeguards: iapp.org
Organisational Design and AI
McKinsey, The Agentic Organisation (2024): mckinsey.com
MIT Sloan Management Review, Agentic AI at Scale (2025): sloanreview.mit.edu
Deloitte, Agentic AI Strategy, 2026 Tech Trends: deloitte.com
Nestr
Nestr.io, Platform for Purpose-Driven Collaboration: nestr.io
Nestr MCP, Connect AI Assistants to Your Organisational Structure: mcp.nestr.io
Assess your commitment and context for adopting Holacracy, Sociocracy, or Teal frameworks
This assessment evaluates your organization's commitment level and context for transitioning to self-organizing structures.
Note: This is a self-assessment tool, not a scientifically validated diagnostic instrument. It provides directional guidance based on common patterns in organizational transformations.
Nestr provides tools to support self-organizing teams using Holacracy, Sociocracy, and similar frameworks.
.png){kind=logo}
