Last updated: 2026-07-25· Jurisdiction: EU law (NIS 2 Directive (EU) 2022/2555, which applies through each Member State's own transposition and national supervisory authority; DORA Regulation (EU) 2022/2554; EU AI Act Regulation (EU) 2024/1689; GDPR Regulation (EU) 2016/679) and international standards (ISO/IEC 27001:2022, ISO/IEC 42001:2023)
What AI agents can and cannot be trusted to do in compliance
Almost every conversation about agentic AI in governance, risk and compliance is an argument about capability: what the models can do now, what they will do next year. That argument misses the part of the boundary that matters, because a large share of the compliance workload is not gated on capability at all. It is gated on accountability. The rules already name who has to do the deciding, and they name people.
The short version
Delegate the work that has a source of truth: evidence collection, control monitoring, drift detection, retrieval. Let an agent draft anything that a named person then adopts. Keep approval, acceptance, oversight and review with whoever the frameworks address, because NIS 2 has management bodies approve the measures and oversee them, DORA gives the management body ultimate responsibility for ICT risk, the EU AI Act requires high-risk systems to be overseen by natural persons, and ISO 27001 puts risk sign-off with risk owners and the periodic evaluation of the system with senior leadership. That last group does not move when the models improve.
Two different limits, constantly confused
When people say an AI agent cannot be trusted with something, they usually mean one of two very different things, and the difference decides whether the limit is temporary.
A capability limit
The agent is not reliable enough at the task yet. This limit is real, it is measurable, and it moves. Every model release redraws it, which is exactly why an assessment of what to automate should be revisited on a schedule rather than settled once. Anything in this category is a question of evidence: how often is it wrong, how would you know, and what does a wrong answer cost you.
An accountability limit
A rule assigns the act to someone. The management body approves. The controller carries out. Senior leadership evaluates. The risk owner signs off. Natural persons oversee high-risk AI systems. These sentences have an addressee, and that does not change as models improve. A regulator asking who approved a measure is not asking which system generated it.
One distinction inside the second category does a lot of work, and skipping it is how this argument usually gets overstated. Some rules are addressed to a natural person or a body of them: the EU AI Act asks for oversight of high-risk AI systems by natural persons, ISO 27001 puts the periodic evaluation with senior leadership and risk sign-off with risk owners, NIS 2 and DORA put approval with the management body. An agent cannot be any of those. Other rules are addressed to the organization as a legal person, most obviously the GDPR's controller. That is a weaker constraint and it is worth being precise about: it does not say software may not do the analytical work. It says the organization stays answerable for the result and has to be able to demonstrate it, which in practice means a named person owns the output and can defend how it was reached.
Confusing capability with accountability produces both failure modes. Treat every limit as a capability limit and you hand an agent decisions that were never available to delegate, then find out during an audit. Treat every limit as an accountability limit and you refuse to automate evidence collection, which no rule reserves for a human at all. Classify the task first, then argue about the tooling.
The three-question test
Run these in order against any compliance task before you delegate it. The first stop wins.
1.Does a named rule assign this act to a person or a body?
Read the requirement literally and look for the subject of the sentence. When it says the controller, the management body, top management, the risk owner, or a natural person, the act has an addressee and an agent is not it. An agent can prepare everything that goes into the act. It cannot be the party performing it.
2.Does someone become liable for the output?
If a person is answerable for the result, they have to be able to reconstruct and defend the reasoning later, in front of an auditor or a regulator who will not accept the model produced it as an explanation. That is a higher bar than the output looking right. It means the agent's work has to be reviewable, sourced and reproducible, not merely plausible.
3.Can the output be checked against a source of truth?
Evidence collection, control monitoring and retrieval all have an external referent you can diff against, so errors surface. Interpretation, risk appetite and materiality do not: a wrong answer looks exactly like a right one. When the first two answers are no and this one is yes, delegate it and spot-check.
The delegation table
The test applied across the compliance workload. Where a rule decides the verdict, the article or clause is named, so you can go and read it rather than take our word for it.
| Task | Verdict | Why |
|---|---|---|
| Collecting evidence: pulling configuration snapshots, access lists, logs and ticket exports | Agent can own it | None of the sources below reserves routine extraction of this kind to a named person. Whether a specific record has to be created, checked or retained at all depends on the requirement it serves, so read that requirement rather than this row. What makes the task delegable is that the output can be verified against the system it came from. |
| Continuous control monitoring and configuration-drift alerting | Agent can own it | Same reasoning. Detection compares a current state against an expected one, so it has an external referent and errors surface. What an alert then means, and whether it amounts to a nonconformity, is a judgement that leaves this row. |
| Answering a security questionnaire from existing, approved material | Agent drafts, a person owns | Retrieval and reassembly are agent work. The answers become representations to a customer, so a person has to own them. The failure mode is confident reuse of a control statement that was true for a different scope. |
| Drafting policies, procedures and control descriptions | Agent drafts, a person owns | ISO/IEC 27001:2022 clause 5.3 has senior leadership allocate and communicate who holds which responsibilities and decision-making powers within the management system. Drafting is not what that clause governs; adoption is. A generated policy nobody has assigned an owner to is a document, not a control. |
| Mapping controls across frameworks and building crosswalks | Agent drafts, a person owns | A crosswalk is an argument that one control satisfies another framework's requirement. That argument becomes the organization's claim, and an auditor can test it. Proposing candidate mappings is mechanical; deciding that a near-match is close enough is the part that carries the claim. |
| Determining whether a regulation applies to your organization | Agent drafts, a person owns | Scope determination is a legal position with consequences (registration, supervision, penalties) that land on the entity, not on the tool that suggested it. This is why every scope checker we publish returns a structured assessment and says so, rather than a binding determination. |
| Gathering and scoring risk-assessment inputs | Agent drafts, a person owns | Assembling asset, threat and impact data and proposing a first score is well-suited to an agent. The criteria against which risks are judged, and the judgement itself, remain the organization's. |
| Signing off the planned response to a security risk, and the exposure left afterwards | A person or body must do it | ISO/IEC 27001:2022 clause 6.1.3 puts two separate sign-offs with the people assigned to own the relevant risks: agreement to the planned response, and agreement to the exposure that will remain once that response is in place. Both are acts of an assigned owner, and an agent has no exposure of its own to agree to carry. |
| Carrying out a data protection impact assessment | A person or body must do it | GDPR Article 35(1) places the assessment on the controller, before the processing starts, and Article 35(2) has the controller seek the data protection officer's advice where one is designated. The controller is usually an organization rather than an individual, so this is not a claim that software cannot do the analytical work. It is that the organization remains answerable for the result under the Article 5(2) accountability principle, which in practice means a person has to own it and be able to defend it. |
| Approving cybersecurity risk-management measures at a NIS 2 entity | A person or body must do it | NIS 2 (Directive (EU) 2022/2555) Article 20(1) requires Member States to ensure that the management bodies of essential and important entities approve the cybersecurity risk-management measures, oversee their implementation, and can be held liable for the entity's infringements of Article 21. Article 20(2) additionally requires members of those management bodies to follow training. Because NIS 2 is a directive, the liability rules that actually bite are the ones in your Member State's transposition, and Article 20(1) is expressly without prejudice to national liability rules for public institutions and officials. What does not vary is who has to do the approving. |
| Approving the ICT risk-management framework at a financial entity | A person or body must do it | DORA (Regulation (EU) 2022/2554) Article 5(2) requires the management body to define, approve, oversee and be responsible for the implementation of all arrangements related to the ICT risk-management framework, and states that it bears the ultimate responsibility for managing the entity's ICT risk. |
| Overseeing a high-risk AI system while it is in use | A person or body must do it | EU AI Act (Regulation (EU) 2024/1689) Article 14(1) requires high-risk AI systems to be designed so they can be effectively overseen by natural persons while in use. Article 26(2) requires deployers to assign that oversight to natural persons who have the necessary competence, training and authority, as well as the necessary support. The regulation names a human on purpose. |
| Letting an agent be the sole decision-maker about an individual, where the decision has legal or similarly significant effect and no Article 22(2) exception applies | A person or body must do it | This is a constraint rather than a flat prohibition, and the qualifier in the task matters. GDPR Article 22(1) gives the data subject the right not to be subject to a decision based solely on automated processing, including profiling, that produces legal effects or similarly significantly affects them. Article 22(2) sets out where that does not apply: contractual necessity, authorisation under Union or Member State law, or explicit consent. Where the contract or consent exception applies, a solely automated decision can be permitted, but Article 22(3) still requires safeguards including at least the right to obtain human intervention, to express a point of view, and to contest the decision. Access revocation, escalation to HR and vetting outcomes can all land here. |
| Assessing your own management system through the internal assurance programme | Agent drafts, a person owns | ISO/IEC 27001:2022 clause 9.2 has the organization choose its auditors and run its audits in a way that guards against bias. It does not require a natural person to perform every step, so this is not automatically a human-only task. What it does mean is that using one system to produce material and then to evaluate that same material creates a self-review problem the organization has to be able to answer for, rather than something that is conforming by default. |
| Senior leadership's periodic evaluation of the management system | A person or body must do it | ISO/IEC 27001:2022 clause 9.3 gives senior leadership a recurring evaluation of whether the management system remains fit for purpose and is delivering what it was meant to, together with the resulting decisions about changes and improvements. An agent can assemble the entire input pack. It cannot be the senior leadership doing the evaluating. |
| Preparing the Statement of Applicability | Agent drafts, a person owns | An agent can help produce this record. ISO/IEC 27001:2022 requires the organization to have one but does not prescribe a signature, so any approval or sign-off step you run comes from your own governance rather than from the standard. The necessity decisions it records, however, come out of the risk-treatment sign-off two rows above. |
| The certification decision itself | A person or body must do it | Granting certification is the certification body's decision, made on the audit evidence under the accreditation rules it works to, not under ISO/IEC 27001:2022 itself and not by anything the audited organization or its tooling produces. The same separation applies to an attestation signed by a practitioner: the assertion belongs to whoever signs it. |
Verdicts describe where accountability sits under the sources listed at the foot of this page. They are a structured reading of those texts for planning purposes, not legal advice, and scope-specific facts can change the answer for your organization.
The failure mode nobody designs for: self-review
The structural error worth designing against has nothing to do with hallucination. It is that one system ends up drafting the policy, collecting the evidence for it, and then assessing whether the organization conforms to the requirement it drafted for. Each of those three steps is defensible in isolation. Together they remove the independence the assessment was supposed to supply.
This is not a new problem and compliance frameworks already have a way of talking about it. ISO/IEC 27001:2022 clause 9.2 has the organization choose its auditors and run its audits in a way that guards against bias, which is the same reasoning behind not letting someone check their own work. Note what that does and does not say: it does not prohibit software-assisted auditing, and it does not make every such arrangement automatically nonconforming. It puts the burden on you to show the assessment was still an objective one.
The practical response is boring: separate the producing function from the assessing function, keep the evidence trail so a person can reconstruct what was used and when, and give the assessment step an input the producing step did not control. Treat your agents the way you would treat staff on the same task.
What the market currently means by “agentic”
One dated data point is worth having in view, because it describes the category rather than any particular product. In a press release dated 25 June 2025, Gartner predicted that over 40% of agentic AI projects will be canceled by the end of 2027, citing escalating costs, unclear business value or inadequate risk controls. The same release described what it called agent washing, the rebranding of existing products such as AI assistants, robotic process automation and chatbots without substantial agentic capability, and estimated that only about 130 of the thousands of agentic AI vendors are real. It also said that current models lack the maturity and agency to autonomously achieve complex business goals or follow nuanced instructions over time. Those are Gartner's findings about the market as a whole, and we have not tested them against any specific product.
Read next to the table above, the interesting part is which words recur. Inadequate risk controls is what it looks like when the accountability question is skipped and an agent ends up where a decision-maker was required. Complex goals pursued over time is a fair description of the work in the last group of the table. None of that says agents do not work in compliance, and this page is not the evidence for whether any given implementation does. It is a reason to scope a deployment against the first two groups deliberately, and to keep a person in the third.
Five questions to ask before an agent touches a control
- When the agent is wrong, who finds out, and how? An agent with no detection path is an unmeasured control.
- Can it show its sources for every claim it makes about a requirement, at the clause or article level, or does it only produce fluent output?
- Does the same system draft the control, gather the evidence and then assess conformity? If so, ask how objectivity is preserved before your assurance process relies on any of it.
- What happens to the audit trail: can you reconstruct months later why a specific determination was made, with the inputs it used at the time?
- Which decisions does it expect a person to keep? Compare the answer against the last group of the table above, and follow up on anything in that group it offers to take off your hands.
Putting this to work
If you are governing AI rather than buying it, two of our free tools follow the same accountability logic. The EU AI Act risk checker gives you a structured read on which tier a system falls into, which is what determines whether the Article 14 oversight duties are in play at all. The AI model documentation checker scores the completeness of a model record against selected documentation topics drawn from the EU AI Act and ISO/IEC 42001:2023. Which requirements actually apply depends on the system's classification, your role and your circumstances, so the resulting record can support a demonstration of oversight without being one on its own. For the management system around all of it, the ISO 42001 readiness checker scores the AI management system clauses.
For the ISO 27001 side of the table, our guide to running a gap analysis walks the method a person still has to own, and the ISO 42001 and EU AI Act pages cover how ISMS Copilot supports each. Everything free lives in the free compliance tools directory.
Frequently asked questions
Will this boundary move as the models get better?
Parts of it will, and parts of it cannot. The tasks in the first group are limited by capability, so better models keep expanding them. The tasks in the last group are limited by who the rule is addressed to: NIS 2 Article 20(1) has management bodies approve the measures and oversee them, DORA Article 5(2) gives the management body ultimate responsibility for ICT risk, EU AI Act Articles 14 and 26(2) require oversight of high-risk systems by natural persons, and ISO/IEC 27001:2022 puts risk sign-off with risk owners and the periodic evaluation with senior leadership. No improvement in model quality changes an addressee. That boundary moves only if the rules are rewritten.
Can an AI agent do a compliance gap analysis?
It can do a great deal of the work and should not make the final call. Collecting the evidence, comparing what exists against each requirement and drafting the finding list is agent-suitable and checkable against the systems it came from. The sign-offs are different: under ISO/IEC 27001:2022 clause 6.1.3 the planned response to a risk and the exposure left afterwards are agreed by the people assigned to own those risks. Treat the agent output as a first pass that a competent person then owns.
What is the design mistake to watch for in agentic compliance setups?
Self-review. One system drafts material, collects the evidence and then evaluates that same material. ISO/IEC 27001:2022 clause 9.2 has the organization choose auditors and run audits in a way that guards against bias, so this arrangement creates an objectivity problem you have to be able to answer for. It does not automatically establish a nonconformity. A defensible design separates the producing and assessing functions, or adds something that preserves an objective evaluation.
Is agentic AI in GRC overhyped?
There is one dated figure worth knowing. Gartner predicted in a press release of 25 June 2025 that over 40% of agentic AI projects will be canceled by the end of 2027 due to escalating costs, unclear business value or inadequate risk controls, described what it called agent washing (rebranding assistants, robotic process automation and chatbots without substantial agentic capability), and estimated only about 130 of the thousands of agentic AI vendors are real. That is a statement about the market, not about any particular product. Judge a specific claim by what the system does with a wrong answer.
Does the EU AI Act apply to the compliance tools we buy?
It depends on what the tool does and how it is classified, and that is a determination for your organization rather than something we can settle in a guide. What is settled is the direction: where a high-risk AI system is in scope, Article 14 requires it to be capable of effective oversight by natural persons and Article 26(2) requires the deployer to assign that oversight to people with the competence, training, authority and support to exercise it. Our free EU AI Act risk checker gives you a structured first read on which tier applies.
So what should we actually automate first?
Start where there is a source of truth and no addressee in the rule: evidence collection, control monitoring, drift detection and retrieval across your own approved material. That is where agents are both reliable and verifiable. Then move outward into drafting, keeping a named owner on every artifact. Leave approval, acceptance, oversight and review where the frameworks put them.
Primary sources
- Directive (EU) 2022/2555 (NIS 2), Article 20 on governance: management bodies approve and oversee the cybersecurity risk-management measures and can be held liable. eur-lex.europa.eu (checked 2026-07-25).
- Regulation (EU) 2022/2554 (DORA), Article 5 on governance and organisation: the management body approves the ICT risk-management framework and bears ultimate responsibility. eur-lex.europa.eu (checked 2026-07-25).
- Regulation (EU) 2024/1689 (EU AI Act), Article 14 on human oversight of high-risk AI systems and Article 26(2) on the deployer assigning that oversight to natural persons. eur-lex.europa.eu (checked 2026-07-25).
- Regulation (EU) 2016/679 (GDPR), Article 22 on solely automated decisions including the 22(2) exceptions and the 22(3) safeguards, Article 35 on data protection impact assessments, and Article 5(2) on accountability. eur-lex.europa.eu (checked 2026-07-25).
- ISO/IEC 27001:2022 (third edition, published 2022-10, with one amendment), the information security management system requirements referenced for clauses 5.3, 6.1.3, 9.2 and 9.3. www.iso.org (checked 2026-07-25).
- ISO/IEC 42001:2023 (first edition, published 2023-12), the AI management system requirements. www.iso.org (checked 2026-07-25).
- Gartner press release, 25 June 2025: over 40% of agentic AI projects predicted to be canceled by the end of 2027, plus the agent-washing estimate. www.gartner.com (checked 2026-07-25).
Written and maintained by the ISMS Copilot team. Our compliance content is produced by certified information security professionals, including a CISM-certified ISO 27001 Lead Implementer who still runs audits. Last reviewed 2026-07-25.
The full text of ISO standards is copyrighted and available for purchase from ISO or your national standards body. This guide paraphrases requirements in original wording and does not reproduce clause titles or normative text. EU legal texts are cited by article number and summarised; read the official text at the linked source for the binding wording. This is educational content, not legal advice and not a statement of conformity. It describes categories of software generically and makes no claim about any specific vendor or product.
Ready to do compliance work faster?
Built for speed, accuracy, and audit-ready output.