Compliance Briefing · 9 min read
SM&CR and AI: Who's Accountable When an Agent Goes Wrong?
A working answer to the question every Senior Manager at a UK regulated firm is now asking — how Senior Manager Function holders attest to AI systems they did not build, write, or fully understand.
Published 30 April 2026 · By Sunny Patel, Founder, Agentic AI Associates
Informational only, not legal advice. Confirm interpretations with your firm's legal and compliance teams.
The thesis
SM&CR is not technology-neutral. It was written before agentic AI existed, and the answer to "who is accountable when an agent goes wrong?" is the same answer SM&CR gave in 2016 to the question "who is accountable when an outsourced provider goes wrong?" — the regulated firm, through a named Senior Manager Function holder, with a Statement of Responsibility that covers the relevant area. AI changes the operational mechanics of accountability, not its location.
This page maps the question through six common scenarios, names the SMF role that ends up accountable in each, and lists the evidence that holder needs to be holding when supervision asks. It draws on the engagements we run with regulated firms in 2025–2026 — wealth, savings, payments, and insurance — and on the FCA's AI Approach as published.
The accountability map (six scenarios)
Each scenario names the SMF role most often accountable, and the evidence that holder must be able to produce on demand. The mapping is not law. It is the operational pattern we have seen survive supervisory scrutiny.
| Scenario | Accountable | Evidence required |
|---|---|---|
| AI system makes a wrong call on a regulated decision (e.g. suitability, fraud, vulnerable-customer support) | SMF holder for the business area where the decision was made (typically SMF24, SMF18, or the relevant business head with a Statement of Responsibility covering AI) | Boundary document, decision log with agent rationale, sample-review records, and the Senior Manager's most recent attestation |
| Vendor model used by an AI system is deprecated or behaves differently after an update | SMF holder for the system + SMF4 (Chief Risk) for the model-risk dimension | Version pin in the AI Risk Register entry, model change-control log, regression-test results |
| AI system breaches a customer-data class it should not have accessed | SMF24 (Chief Operations) plus SMF17 (MLRO) if AML/KYC, plus the DPO operating under SMF16 (Compliance) | Boundary document, IAM scope, audit log of the breach, incident report |
| Engineering team uses AI coding assistant and ships a regulatory-affecting bug | SMF24 (or whoever holds the Statement of Responsibility for engineering) for the bug; the AI assistant is a tool, not the accountable party | Code review record, test coverage at point of release, whether the AI assistant was logged as the source of the change |
| AI-driven communication produces misleading information to a customer | SMF16 (Compliance Oversight) for the perimeter breach; SMF for the business area for the customer outcome | Communication log, AI rationale, plain-English testing record, vulnerable-customer review |
| Third-party AI vendor has an outage that breaches an Important Business Service impact tolerance | SMF24 + SMF for Operational Resilience (often SMF1 in smaller firms) | Outsourcing register, IBS mapping, scenario-tested fallback, outage timeline |
Three rules for SMF holders inheriting AI
Rule 1 — Boundary before output
An SMF holder should never attest to "the AI works." They should attest to the AI operated within its boundary. The boundary is the document — the Agentic Capability Boundary in our playbook — that names every system the AI is allowed to read or act on, every data class it can touch, and every action it cannot take. If the boundary is correctly enforced and the audit trail confirms it, the SMF holder can attest with confidence even on systems they did not build and would not understand at code level.
Rule 2 — Audit trail before model
The SMF holder does not need a deep grasp of model architecture. They do need a tamper-evident, decision-grade audit trail they can interrogate retrospectively. Hashed, append-only storage with 7-year retention, capturing every agent decision, every tool call, every retrieval, with the agent\'s articulated rationale. If the audit trail is solid, the SMF holder has the same defensive posture as a Senior Manager attesting to a manual process performed by named humans.
Rule 3 — Kill switch before launch
Before any AI system reaches production for regulated workloads, the kill switch is documented, the on-call rota is named, the time-to-disable is measured (target: under 60 minutes), and the procedure is rehearsed. Most kill switches we audit have never been tested. Test them quarterly. The SMF holder cannot defend an attestation if the only kill switch evidence is "we wrote a runbook."
Drafting AI into Statements of Responsibility
The Statement of Responsibility is the SM&CR document that lists what an SMF holder is accountable for. AI accountability lives here, not in some separate AI policy. The drafting pattern we use:
- Name the system class explicitly. "All deployed AI systems within Operations, including agentic systems used in customer support and engineering automation." Not "operational technology," which is too broad.
- Reference the AI Risk Register by name. "Accountable for the operation of all systems recorded in the AI Risk Register at Material or Significant tier." This binds the SoR to a live operational artefact.
- Tie to attestation cadence. "Quarterly attestation that systems operated within boundary, with monthly Model Risk Committee participation."
- Cross-reference cross-cutting SMFs. "Cross-cutting model-risk responsibility held by SMF4 (Chief Risk); cross-cutting compliance perimeter held by SMF16."
For Material-tier consumer-facing AI — for example an AI driving suitability decisions, lending decisions, or high-volume Consumer Duty touchpoints — the responsibility may need explicit mention in two SoRs (the business-line SMF and SMF4), with the boundary between them documented.
Frequently asked questions
Can a Senior Manager delegate AI accountability to a vendor?
No. SM&CR accountability is non-delegable. The vendor can be contractually responsible for service levels, indemnities, and warranties, but the regulated person — the SMF holder — remains the accountable party. The most common drafting error is treating an outsourcing agreement as a transfer of accountability rather than a transfer of execution.
Who at a typical UK fintech ends up accountable for AI?
In firms with a Chief Operating Officer who holds SMF24, that role is the most common landing spot for operational AI. Where SMF24 does not exist, the responsibility usually falls to the CTO holding SMF18 (Other Overall Responsibility) or to the CEO under SMF1. For Material-tier consumer-facing AI, the firm should consider whether the responsibility sits naturally with the SMF for the business line affected, with SMF4 (Chief Risk) responsible for the cross-cutting model risk.
What does an SMF holder actually need to know about an AI system to attest?
They do not need to understand the model architecture. They need to: (1) know what the system does, what data it touches, what decisions it influences; (2) know the boundary — what it cannot do; (3) trust the audit trail to give them retrospective visibility; (4) know who the operational owner is and how decisions reach review; (5) have a credible kill-switch they could invoke. If any of these is missing, the attestation is unsafe.
Is "agentic" AI different in accountability terms from non-agentic AI?
Yes, materially. Non-agentic AI (e.g. a classifier producing a probability) is a static decision-support tool with predictable inputs and outputs. Agentic AI takes actions over time, choosing among options, calling tools, and producing a state graph of decisions. Accountability for agentic AI requires accountability for the decision graph, not just the output — which is why the audit-trail design we describe in our SDLC playbook records every decision point, every tool call, and every retrieval, not just the final answer.
When should a firm appoint a dedicated SMF for AI?
There is no FCA requirement for a dedicated AI SMF, and we do not recommend creating one until the firm operates at a scale where AI is a strategic business line in its own right. For most firms, AI accountability sits within existing SMF duties via amended Statements of Responsibility. Creating a new SMF role for AI before the operating model warrants it tends to dilute accountability rather than concentrate it.
Does the FCA expect personal liability for SMF holders on AI?
Yes. SM&CR is built on personal liability of approved persons. The duty of responsibility means an SMF holder can be held personally accountable for failures within their area. The FCA has not, as of 2026, taken enforcement action against an SMF holder specifically for an AI failure, but the supervisory expectation that they could is explicit in the FCA's public communications since 2024.
How do you write a Statement of Responsibility that covers AI properly?
Three rules: (1) name the AI within the SMF holder's prescribed responsibilities — do not leave it implicit; (2) tie it to the operating model — say what they oversee, not what they technically own; (3) align it to the AI Risk Register — every Material-tier system should be reflected in at least one Statement of Responsibility. We have observed firms attempt to bury AI inside catch-all "operational technology" clauses; supervisors do not regard this as adequate.
Make this real for your firm
A Phase-Gate Diagnostic produces the AI Risk Register, the Statements of Responsibility text, and the kill-switch playbook your Senior Managers can sign. Two weeks, £6,500.
Book a Fit Call →