Governing Agentic AI in GRC: Accountability, Audit Trails

Agentic AI changes the accountability model because the system is no longer only advising — it is acting. When AI updates risk registers, escalates vendors, closes findings, or routes compliance tasks autonomously, regulators will expect firms to prove who authorised the system, what it was allowed to do, and how every action can be reconstructed after the fact.

ISO 42001:2023, the EU AI Act, the FCA's October 2026 AI good practice guidance, and UK GDPR Article 22 all converge on the same principle: AI-assisted compliance must remain explainable, reviewable, and attributable to named humans.

Key principle: The firms that succeed with agentic AI in GRC will not be the ones with the most automation, but the ones with the clearest governance architecture around it.

This article sets out what that architecture looks like, updated to reflect the regulatory position as of November 2026 — including the EU AI Act timeline changes introduced by the Digital Omnibus on AI, and the FCA's first dedicated guidance on agentic AI governance.

What this article covers:

1. Why agentic AI breaks the accountability assumptions built for advisory AI
2. The EU AI Act timeline as it now stands after the Digital Omnibus
3. ISO 42001:2023 requirements for AI management and impact assessment
4. The FCA's October 2026 good practice guidance on agentic systems
5. Human-in-the-loop design principles for regulated compliance contexts
6. Audit trail requirements for autonomous actions
7. A practical five-component accountability framework

Traditional AI in compliance is advisory: a model surfaces an anomaly, a human decides what to do. Agentic AI works on a different structure. An agent receives a goal — "monitor third-party control evidence and flag overdue items" — and autonomously determines which tools to use, which systems to query, and what action to take. By default, the human sits outside the decision loop and only enters it when the system is explicitly designed to require their review.

This shift matters because the accountability frameworks built for advisory AI do not map cleanly onto agentic systems. When a compliance professional reviews an AI recommendation and acts on it, the human decision is on record. When an agentic system sends a supplier a formal notification, updates a risk register, or closes a control as tested without human sign-off, the decision trail becomes an automated log.

Accountability then depends entirely on whether that log is complete, tamper-evident, and attributed to a named individual within the firm.

The regulatory context has sharpened alongside the technology. The EU AI Act (Regulation (EU) 2024/1689) came into force on 1 August 2024. Enforcement for general-purpose AI models, prohibitions, and transparency rules started on 2 August 2026. High-risk AI obligations under Annex III now apply from 2 December 2027, following revisions introduced by the Digital Omnibus on AI (signed 8 July 2026, published in the Official Journal 24 July 2026).

GRC systems operating in financial services may fall within the high-risk classification depending on their function and the decisions they influence. Separately, the FCA has made clear in multiple publications — and most recently in its October 2026 AI good practice guidance — that firms cannot delegate regulatory accountability to technology vendors. The accountability sits with the regulated firm and stays there.

Get a fuller picture of what agentic AI means inside a GRC workflow.

The Three Questions Regulators Will Ask

Most GRC teams deploying agentic tools have yet to answer three questions that regulators will ask:

1. Which named individual within the firm is accountable for the agentic system's compliance decisions?
2. Which decisions is the system authorised to make without human review, and which require it?
3. Where is the complete, auditable record of every autonomous action the system has taken?

The failure mode is rarely that firms have no answers. The answers exist, but they are scattered across a vendor contract, an implementation document, and an informal assumption held by the compliance team. When something goes wrong, accountability is contested, with no documented record to reconstruct who authorised what.

Vendor Contracts Do Not Transfer Regulatory Accountability

A common assumption is that liability can be managed through vendor contracts — so that if an AI system produces a wrong output, the vendor bears the risk. Financial services regulation works differently. The FCA's Principles for Businesses, particularly Principle 3, places accountability for compliance outcomes on the regulated firm.

Outsourcing a function to an AI system, or to a vendor who provides one, leaves that accountability where it is. The FCA's outsourcing and operational resilience guidance explicitly requires firms to retain management oversight of material outsourced activities, and an agentic AI performing compliance activities meets that threshold.

The EU AI Act's timeline has changed materially since mid-2026. GRC teams working from earlier summaries need to update their classification assessments accordingly.

What Is Already in Force

From 2 August 2026, the following are enforceable:

1. Transparency obligations (Article 50): AI systems must disclose when users are interacting with AI, with limited exceptions.
2. Prohibitions: Banned AI practices are now enforceable, including social scoring and certain biometric categorisation systems.
3. General-purpose AI (GPAI) model obligations: Providers of the most capable GPAI models must comply with systemic risk assessment and mitigation requirements.
4. AI literacy obligations: Firms must ensure staff have sufficient AI literacy appropriate to their role.

The High-Risk Deadline Has Moved

The Digital Omnibus on AI, agreed by EU co-legislators on 7 May 2026, signed on 8 July 2026, and published in the Official Journal on 24 July 2026, revised the application dates for high-risk AI obligations. The change was driven by delays in establishing technical standards and designating national competent authorities.

The revised timeline, confirmed by the EU AI Act Service Desk, is:

1. 2 December 2027: Rules for high-risk AI systems designated under Annex III (stand-alone systems, including those used in critical infrastructure management and employment-related decisions).
2. 2 August 2028: Rules for high-risk AI systems embedded in regulated products covered by Annex I.

For GRC teams, this means the Article 9 risk management system, Article 11 technical documentation, Article 12 automatic logging, Article 14 human oversight, and Article 15 accuracy and cybersecurity requirements for high-risk systems now have a December 2027 deadline rather than August 2026.

What this does not mean: The deadline extension is not permission to defer preparation. Classification assessments take time. Technical documentation and logging architectures need to be designed in from the start, not retrofitted. Firms that begin now will be positioned well ahead of the December 2027 deadline.

Does Your GRC System Qualify as High-Risk?

The classification question is not straightforward. Under Annex III, AI systems used in the management and operation of critical infrastructure, and systems that materially influence decisions about individuals in employment or essential services, fall into the high-risk category. For GRC systems in financial services that influence risk scoring, compliance decisions, or operational resilience assessments, the threshold may be met.

The practical test is whether the system's outputs materially influence a decision that affects individuals or critical operations. Where the answer is yes, the December 2027 obligations apply and classification work should begin now.

ISO 42001:2023 is the international standard for AI management systems. It follows the high-level structure familiar from ISO 27001 and ISO 9001, which means it integrates cleanly into existing management system frameworks. For GRC teams, it provides a structured basis for governing agentic AI that maps to regulatory expectations.

Core Requirements Relevant to Agentic GRC

Clause 5.3 — Roles, responsibilities, and authorities. Top management must assign and communicate responsibility for AI system management. This is the ISO equivalent of the FCA's named-SMF requirement: accountability must be assigned to a specific person, not to a team, a department, or the technology itself.

Clause 6.1 — AI risk assessment. Organisations must establish a process for identifying AI-related risks and opportunities, including those arising from the AI system's intended use and potential misuse. For agentic systems, this requires assessing the consequences of incorrect autonomous actions, not just incorrect outputs.

Clause 8.4 — AI system impact assessment. Before deployment, organisations must assess the potential impacts of the AI system on individuals, groups, and society. In a GRC context, this means documenting what happens if the agentic system makes an error in a risk rating, a vendor escalation, or a control closure.

Clause 9.1 — Monitoring, measurement, analysis, and evaluation. Organisations must monitor AI system performance against defined objectives. For agentic systems, this includes monitoring whether the system is staying within its authorised decision scope, not just whether its outputs are accurate.

The ISO 42001 Annex A controls include specific guidance on AI incident management (A.6.2) and AI system documentation (A.6.1). Both are directly relevant to the audit trail requirements that regulators will expect from firms running agentic compliance systems.

ISO 42001 certification is increasingly appearing in vendor due diligence frameworks. GRC teams evaluating AI vendors should ask whether the vendor operates an ISO 42001-certified management system and what that certification covers.

On 19 October 2026, the FCA published its first substantive guidance on AI good practice and areas for improvement, drawing on supervisory engagement with regulated firms. The guidance does not introduce new rules. It does, however, set out clearly how the FCA assesses firms' existing AI governance against the SM&CR, Consumer Duty, and operational resilience frameworks.

For agentic AI specifically, the guidance marks a significant step. The FCA's 2024 AI update did not address agentic AI at all. The October 2026 guidance addresses it directly and signals that supervisory scrutiny of agentic deployments will increase.

What the FCA Expects from Firms Deploying Agentic AI

Named accountability from the design stage. The FCA expects firms to assign each material AI use case to a named Senior Management Function (SMF) holder from the point of design, not at deployment. Firms that assigned accountability retrospectively, or that could not identify a named accountable individual, were cited as poor practice.

An agent inventory. The guidance specifically identifies the maintenance of a central agent inventory as good practice. Firms developing agentic use cases should register agents in a central inventory that records which agents are live, who owns them, what systems and data they can access, and what controls apply. This supports accountability, monitoring, and change management.

Continuous, conditional assurance. The FCA's guidance states explicitly that agentic systems require a different assurance model. A system that is safe at deployment may behave differently at scale, under stress, or as the underlying models change. The FCA describes this as "continuous, conditional assurance" — assurance is not a one-time gate before go-live but an ongoing monitoring obligation.

Human oversight that is genuinely capable of challenge. The FCA found that in some firms, human oversight had become a box-ticking exercise, with reviewers lacking the authority, information, or capability to challenge or override AI outputs. The guidance makes clear that oversight is only effective where the human can genuinely intervene. For agentic systems, this means designing escalation triggers and override mechanisms before deployment, not as an afterthought.

Near-miss reporting. The FCA stated that its incident reporting requirements must extend to significant AI failures and near-misses. The FCA's Chief Digital Information Officer described near-miss reporting for agentic AI as "becoming a national security priority." Firms should build near-miss reporting into their AI incident management processes now.

The SM&CR Framing

The FCA does not expect Senior Managers to be AI specialists. It does expect them to take reasonable steps to understand the risks arising from AI use within their area of responsibility, obtain appropriate expertise where needed, and provide effective oversight and challenge.

The practical implication: a Senior Manager cannot discharge their SM&CR obligations by pointing to a vendor contract or a technology team. They need documented evidence that they understood the risk, set appropriate governance, and received regular reporting on AI system performance.

The full guidance is available on the FCA's website.

Human-in-the-loop is not a binary setting. It is a design decision that must be calibrated to the consequence of the action the AI is performing. Getting this calibration wrong in either direction creates problems: too much human review and the efficiency case for agentic AI collapses; too little and accountability gaps open up.

A Risk-Based Framework for Oversight Thresholds

The right approach is to classify AI actions by their consequence and set oversight requirements accordingly:

This tiered model aligns with the FCA's guidance that human oversight controls should be designed around the specific use case, the level of AI autonomy, and the potential impact of the decision.

Escalation Triggers Must Be Defined in Advance

One of the FCA's consistent findings was that firms had not defined escalation triggers before deployment. Good practice requires specifying, in advance:

1. What confidence threshold below which the agent must escalate to a human
2. What action types require human approval regardless of confidence
3. What constitutes an AI near-miss and how it should be reported
4. Who receives escalations and within what timeframe

These triggers should be documented in the AI system's governance record, reviewed periodically, and tested as part of ongoing monitoring.

Override Must Be Technically Possible

The FCA's guidance and the EU AI Act's Article 14 requirements both require that humans can effectively intervene in, stop, or override an AI system's actions. This is not just a policy statement; it is a technical requirement. GRC teams should confirm with their AI vendors that:

1. Any action taken by an agentic system can be rolled back
2. The system can be paused or restricted without disrupting the wider platform
3. Override actions are themselves logged and attributed

The architecture test: if you cannot demonstrate that a human could stop the agent and reverse its last three actions with an auditable record of doing so, the oversight model is not sufficient.

Audit trails for agentic AI are not the same as standard system logs. A log records that something happened. An audit trail for an agentic system must record what happened, why the system decided to do it, who authorised the system to have that capability, and what the state of the data was before and after the action.

The Four Layers of an Adequate Audit Trail

1. Action log. Every action taken by the agentic system, with timestamp, action type, affected record, and outcome. This is table stakes and most platforms provide it.

2. Reasoning record. The basis on which the system decided to take the action: which inputs it considered, what logic it applied, and what alternatives it evaluated. For AI systems using large language models, this means capturing the reasoning chain, not just the output.

3. Authorisation record. The documented scope of what the system is authorised to do, who approved that scope, when it was approved, and whether it has been reviewed since deployment. This is the record that connects a specific action to a named human who accepted responsibility for the system's authority.

4. Change and rollback log. A record of any changes to the system's configuration, scope, or underlying model, with attribution and the ability to roll back to a prior state. Where a vendor updates the underlying model, this change should be recorded and assessed.

DORA's Logging Requirements

For firms in scope of the Digital Operational Resilience Act (DORA), Article 10 requires ICT systems to be equipped with logging mechanisms that produce tamper-resistant logs. Article 17 requires firms to report major ICT-related incidents to competent authorities. Where an agentic AI system constitutes part of the ICT infrastructure supporting critical or important functions, its logging must meet DORA's standards.

The practical implication for GRC teams is that AI audit logs should be stored in a system that cannot be modified after the fact, with access controls that prevent the AI system itself from altering its own record. Event-sourced architectures, where each action is recorded as an immutable event rather than an overwrite of a prior state, satisfy this requirement more cleanly than traditional database logging.

As Verdantix noted in its 2026 assessment of SureCloud: "SureCloud's event-based architecture converts every user action into a discrete, traceable event. As regulatory scrutiny intensifies, this architecture will be particularly valuable for firms handling sensitive data in highly regulated sectors."

UK GDPR Article 22 and Automated Decision-Making

Where an agentic GRC system's outputs contribute to decisions about individuals — for example, a vendor risk rating that affects a supplier relationship, or a compliance assessment that affects an employee — UK GDPR Article 22 may apply. Article 22 restricts solely automated decisions that produce legal or similarly significant effects, requiring either explicit consent, contractual necessity, or a legal basis, plus the right to human review.

GRC teams should audit whether any of their agentic workflows produce outputs that feed into decisions affecting individuals, and document the legal basis for any such automated processing.

Pulling the regulatory requirements together, a governance-ready agentic AI deployment in GRC needs five components to be in place before the system goes live.

1. Named Accountability

Every agentic AI use case must be assigned to a named individual who accepts accountability for the system's compliance decisions within their area of responsibility. This person does not need to be a technical specialist, but they must be able to demonstrate informed oversight: they understand what the system is authorised to do, they receive regular reporting on its performance, and they have documented the steps they have taken to assess and manage the risk.

In financial services, this maps to a named SMF holder. In other regulated sectors, it maps to whoever holds the equivalent accountability for the business area the system operates in.

2. Defined Scope and Decision Authority

The system's authorised decision scope must be documented: which actions it can take autonomously, which require human approval, and which are out of scope entirely. This document should be reviewed whenever the underlying model changes, the use case expands, or the system is deployed in a new context.

3. Immutable Audit Logs

Every action taken by the agentic system must be captured in an immutable log that records the action, the reasoning, the authorisation basis, and the state of the data before and after. The log must be stored in a system that the AI cannot modify, with access controls that prevent post-hoc alteration.

4. Human Override Capability

The system must be designed so that a human can stop it, redirect it, and roll back its actions at any point. This capability must be tested before deployment and retested whenever the system's scope or underlying model changes. The FCA's guidance and the EU AI Act's Article 14 both require this.

5. Ongoing Monitoring and Near-Miss Reporting

Governance does not end at deployment. Firms must monitor AI system performance against defined objectives, review whether escalation triggers remain appropriate, and report significant failures and near-misses through their incident management process. The FCA has signalled that supervisory scrutiny of agentic AI will increase, and firms that cannot evidence ongoing monitoring will face questions.

The governance test: if your agentic AI vendor cannot demonstrate all five of these components through their platform architecture, the governance burden falls entirely on your team to build around it. That is a significant risk to carry.

These five components should be documented in an AI governance record for each use case and reviewed at least annually, or whenever a material change occurs to the system or the regulatory environment.

The governance requirements described in this article are not optional extras that can be bolted onto an agentic AI deployment after the fact. They need to be built into the platform architecture from the start. When evaluating agentic AI for GRC, the governance question should come before the capability question.

The right questions to ask a vendor are not "what can your agents do?" They are:

1. How does the platform assign and enforce the scope of each agent's authority?
2. Where are the immutable reasoning logs stored, and who controls access to them?
3. Can any action taken by an agent be rolled back, and is that rollback itself logged?
4. Does the platform's permission model prevent agents from exceeding their assigned role?
5. How does the platform handle model updates, and are those changes recorded?

The distinction that matters: a platform where governance is a feature layer added to an AI tool is fundamentally different from one where governance is the architecture. The former requires the firm to build and maintain the governance controls. The latter has those controls as native properties of the system.

SureCloud's Gracie AI Agents with Personas and Skills is built on an event-sourced architecture where every action is captured as an immutable, discrete event. Agents operate within Personas that inherit the platform's existing permissions model, so they cannot exceed their assigned role. Every action can be rolled back. Customer data is never used to train models and never leaves the tenant environment. Human-in-the-loop controls require confirmation before agents make significant changes to data or decisions.

This architecture is not a governance add-on. It is how the platform works.

To see how Gracie AI Agents with Personas and Skills handles accountability in practice, explore the SureCloud platform.

Agentic AI in GRC is not a future scenario. It is deployed and operating in regulated firms today. The regulatory frameworks that govern it are active, evolving, and becoming more specific.

The EU AI Act's high-risk obligations have been pushed to December 2027, but the transparency requirements, prohibitions, and GPAI model obligations are in force now. The FCA has published good practice guidance that directly addresses agentic AI and makes clear that supervisory scrutiny will increase. ISO 42001 provides the management system structure to bring it together.

The firms that will be well-positioned are not those that waited for the regulation to settle. They are those that built governance into their AI deployments from the start: named accountability, defined scope, immutable logs, real override capability, and continuous monitoring.

Accountability for AI in GRC does not belong to the vendor. It belongs to the firm, and it is exercised through the governance architecture around the system.

If you are evaluating agentic AI for your GRC programme, start with the governance questions. The capability will follow. The accountability cannot be retrofitted.