Senior Manager AI Regime Obligations: A Compliance Checklist

Senior managers are already accountable for AI-driven decisions under existing SMCR duties, whether or not the FCA issues an AI-specific prescribed responsibility. That is the position both the FCA and PRA have signaled: SMCR applies to AI use now, and firms are expected to allocate ownership and demonstrate reasonable steps without waiting for new rules. The duty is not novel. It is the same "take reasonable steps" standard that has applied since the Senior Managers Regime began, now extended to systems that make or influence decisions at machine speed.

What changes with AI is the evidence bar. Supervisors increasingly want to see provenance-tracked records, not verbal assurances or a slide deck from last year's board meeting, when they assess whether a firm's AI oversight holds up. If you cannot produce a log showing who approved a model, when it was tested, and who monitors it today, you have a governance gap. Delegation to a data science team or a third-party vendor does not remove your accountability as the senior manager attached to that area.

Here is what to prioritize immediately:

• Build an AI inventory. List every AI system touching customer outcomes, regulatory reporting, or financial decisions, including agent-based automations that run without a human in the loop.
• Assign a named owner to each material system. Every item on that inventory needs a senior manager attached to it in your Statement of Responsibilities, not a shared or implied ownership.
• Risk-rate each system. Prioritize based on customer harm potential, financial exposure, and decision autonomy.
• Start logging now. Testing dates, approval sign-offs, monitoring alerts, and escalation records all count as evidence, and gaps are easier to explain if logging started before an incident, not after.

Anchor this against three things: the FCA's SMCR framework, the PRA's parallel accountability expectations for regulated firms, and the growing body of supervisory commentary treating AI oversight as a subset of existing conduct duties rather than a separate regime.

Key Takeaways

Senior managers who assign named ownership and maintain provenance-tracked evidence face materially lower enforcement risk than those relying on informal or verbal oversight assurances.

Table of Contents

• What Senior Managers' Accountability Covers for AI
• Core Elements of a Senior Managers Regime That Matter for AI
• Regulatory Expectations and AI Principles You Must Translate Into Controls
• A Practical Compliance Checklist You Can Act on This Week
• Evidence and Audit Readiness: What to Keep and How
• Liability, Enforcement Risk, and How Regulators Assess Senior Managers
• A RACI Exercise to Embed SMCR Concepts Into Your Organization
• How Aetherpulse Produces Audit-Ready Evidence Without Touching Customer Data
• Guidance on Integrating AI Ethics Frameworks With Legal Obligations
• Methods for Maintaining Explainability in Complex AI Systems
• Handling Data Privacy Within AI Governance Under SMCR
• Continuous Monitoring Strategies to Maintain Compliance
• Precedent and Enforcement Patterns Under the Senior Managers Regime
• Communication Protocols for AI Incidents Under SMCR
• An Editorial Take on What Actually Matters This Quarter
• Get Audit-Ready Evidence Before Your Next Supervisory Review
• Frequently Asked Questions
• Sources

What Senior Managers' Accountability Covers for AI

Accountability under SMCR runs through three mechanisms: senior manager functions (SMFs), Statements of Responsibility, and prescribed responsibilities. For AI, this means the person holding an SMF for a business area, whether that is retail lending, trading operations, or customer service, retains responsibility for AI systems deployed within that area, even when a separate technology function built and maintains the tool.

The scope question that trips up most firms is where accountability sits when AI cuts across business lines. A fraud detection model used by both retail banking and payments operations, for instance, needs a clear owner, not two senior managers each assuming the other has it covered. SureCloud's analysis of FCA and PRA governance expectations makes the point directly: every material AI system needs a named owner, and board-level oversight applies where exposure is significant enough to matter at that level.

Third-party AI services complicate this further. If your firm licenses a large language model from an external provider or runs risk scoring through a vendor platform, you remain accountable for how that system is used inside your firm, even though you do not control its underlying code. The FCA and PRA's position on AI accountability treats deployer responsibility as separate from provider responsibility. You cannot outsource the duty to monitor outcomes just because you outsourced the model.

Boards and senior managers need genuine AI literacy and clear governance procedures for approving and implementing AI systems, and where AI cuts across departments, multiple senior managers can legitimately share responsibility, provided that sharing is documented rather than assumed.

Common boundary cases include:

• Shared ownership across business lines, where a system serves two SMF-holders and neither has formally claimed it.
• Agent-driven automations that execute decisions (a claims-triage bot, an automated credit adjustment) without a human checkpoint, which typically require tighter named ownership than advisory tools.
• Legacy systems retrofitted with AI features, where the original system owner may not realize their remit expanded when a vendor pushed a machine-learning update.

Core Elements of a Senior Managers Regime That Matter for AI

SMCR rests on three pillars, and each one carries a distinct implication for how you govern AI.

The Senior Managers Regime itself requires named individuals to hold formal responsibility for specific business functions, documented in a Statement of Responsibilities. For AI, this means every material system needs to trace back to a named SMF holder, not a committee or a department. The Certification Regime requires firms to assess and certify staff in roles that could cause significant harm, which increasingly includes data scientists, model risk officers, and anyone building or tuning production AI systems. The Conduct Rules set baseline standards of individual behavior, including acting with due skill, care, and diligence, a standard that applies just as much to approving an AI model rollout as it does to approving a lending decision.

In practice, responsibility typically splits this way across functions:

• Compliance owns regulatory mapping and ensures AI use aligns with FCA SYSC requirements and Consumer Duty obligations.
• Risk owns model risk assessment, testing standards, and the risk-rating methodology applied to each AI system.
• Operations owns day-to-day monitoring, escalation triggers, and incident response when a model behaves unexpectedly.
• Technology owns technical documentation, change control, and the audit trail generated by the system itself.

The gap most firms fall into is assuming technology automatically owns "AI governance" because it built the system. That is a governance failure waiting to surface, because technology teams rarely have visibility into customer harm thresholds or regulatory reporting obligations.

Pro Tip: When two functions could plausibly own an AI system, write the ownership question into your next Statement of Responsibilities review rather than leaving it as an informal understanding. A regulator asking "who owns this" during a supervisory visit is not the moment to discover the answer is unclear.

Regulatory Expectations and AI Principles You Must Translate Into Controls

Regulators have been consistent about the principles that matter, even without a finalized AI-specific rulebook. Five priorities show up repeatedly across FCA and PRA commentary: safety, security and robustness; transparency and explainability; human oversight; testing and validation; and third-party risk management.

Each principle needs a concrete control attached to it, or it stays a slogan on a governance slide:

• Safety, security and robustness translates into penetration testing schedules, model performance thresholds, and defined failure modes for each system.
• Transparency and explainability translates into model documentation that a non-technical reviewer can read, plus decision logs that show what inputs drove a specific output.
• Human oversight translates into defined escalation triggers, a named reviewer for edge cases, and a documented threshold for when a human must intervene before an automated decision executes.
• Testing and validation translates into a testing calendar, retained test results, and a sign-off record for every model version deployed to production.
• Third-party risk translates into vendor contracts that specify audit rights, data handling terms, and a documented assessment of what happens if the vendor's model changes without notice.

Industry pressure for clarity is building. Commentary tracked by Law360 shows growing calls for the FCA to clarify AI-specific rules for senior managers, reflecting real uncertainty about how existing duties apply when a model, not a person, makes the call that goes wrong. Until that clarity arrives, the safest position is to over-document rather than wait.

Regulatory signal: Supervisors increasingly expect audit-ready, provenance-tracked evidence, meaning logs of when models were tested, approved, and monitored, rather than high-level status reports or verbal assurance during a supervisory review.

A Practical Compliance Checklist You Can Act on This Week

You do not need a multi-quarter program to make meaningful progress. Here is a sequence that produces defensible evidence within weeks, not months.

1. Build the AI inventory first. List every system, including shadow AI tools business units adopted without formal sign-off. Minimum evidence: an exportable spreadsheet or dashboard with system name, function, and business owner.
2. Assign a named owner to every material system. Update the relevant Statement of Responsibilities to reflect the assignment explicitly. Minimum evidence: a signed and dated document.
3. Risk-rate each system using a consistent methodology. Rate on customer harm potential, decision autonomy, and financial exposure. Minimum evidence: a risk register with a rating and rationale per system.
4. Run or commission baseline model testing. For any system rated medium risk or above, document test scope, method, and results. Minimum evidence: test logs with dates and reviewer sign-off.
5. Stand up basic monitoring and escalation triggers. Define what counts as anomalous output and who gets notified. Minimum evidence: an MI dashboard or alert log showing the trigger fired and was reviewed.
6. Review third-party contracts for AI-relevant terms. Confirm audit rights and change-notification clauses exist. Minimum evidence: a contract addendum or clause reference.
7. Train staff who interact with or oversee AI outputs. Even a short session establishes a documented baseline of AI literacy. Minimum evidence: attendance records and training material.

A useful phrasing template for updating a Statement of Responsibilities: "[Named SMF holder] is responsible for the oversight, risk management, and ongoing monitoring of [system name], including escalation of material performance deviations to [committee/function]." Keep it specific enough that a regulator reading it knows exactly what was assigned and to whom.

Pro Tip: The single fastest exposure reduction most firms can achieve is naming an owner for every system currently sitting in an ownership gray zone. It costs nothing, takes a day, and closes the most commonly cited governance failure before it becomes a finding.

• Escalation triggers should specify a threshold, not a vague instruction to "flag if something looks wrong."
• Quick wins compound: logging started this month is still evidence a supervisor can review next year.

Evidence and Audit Readiness: What to Keep and How

Regulators do not accept intent as evidence. They want artefacts, and the artefacts need provenance, meaning a clear, tamper-evident record of who created them and when.

The core evidence set most firms need to assemble includes AI inventory exports, model test logs, decision provenance records, approval sign-offs, vendor contracts with audit clauses, and a change history for every production model. The EU AI Act's technical documentation requirements offer a useful comparator here, since they specify documentation, testing records, and retained logs for high-risk systems in enough detail to model a UK evidence standard against, even for firms with no direct EU AI Act obligation.

Build these records so a reviewer with no prior context can reconstruct the decision chain in minutes, not days spent chasing emails. That standard, often called an audit-ready evidence checklist by supervisors, is what separates a firm that passes a review smoothly from one that spends weeks assembling documents under pressure.

Pro Tip: Cryptographic signing of evidence exports, using a standard like HMAC-SHA256, gives you a tamper-evident record that a supervisor can trust without having to verify your internal audit process from scratch. It is a small technical step that removes an entire category of credibility questions.

Liability, Enforcement Risk, and How Regulators Assess Senior Managers

Enforcement action under SMCR has never required a finding that a senior manager personally caused harm. The duty is about reasonable steps, and Addleshaw Goddard's analysis of senior manager liability for AI decisions confirms that current SMCR duties already give regulators enough basis to assess culpability when AI causes customer harm, without a new prescribed responsibility.

Four factors tend to drive enforcement outcomes: documentation gaps, poor oversight of delegated tasks, failure to monitor ongoing model performance, and absent or unclear escalation paths. A firm that can show consistent testing records, a named owner, and a documented escalation trail faces a materially different conversation with a supervisor than one that cannot produce any of it, even if both firms experienced the same underlying AI failure.

Lower enforcement risk generally correlates with visible governance discipline: risk registers that get updated, monitoring dashboards that actually get reviewed, and named owners who can speak knowledgeably about their systems when asked. Higher risk correlates with governance that exists on paper but was never operationalized, meaning policies were written but never followed, or ownership was assigned but never actually exercised.

Where the current SMCR regime lacks an AI-specific prescribed responsibility, regulators can still assess senior managers under existing duties, and firms that document governance, testing, monitoring, and escalation now materially reduce their enforcement exposure later.

Consider a scenario: an automated credit decisioning tool systematically under-approves applications from a specific demographic segment due to a training data flaw. If the senior manager overseeing that lending function can produce testing records showing fairness checks were run, an escalation log showing the anomaly was flagged and investigated within a reasonable window, and a remediation record, the regulatory conversation focuses on remediation speed. Without those records, the conversation shifts toward whether reasonable steps were taken at all, a much harder position to defend.

A RACI Exercise to Embed SMCR Concepts Into Your Organization

Mapping AI systems to accountable individuals does not require a consulting engagement. A structured half-day session, run properly, produces a defensible management responsibility map.

Invite the senior manager for each affected business line, a risk representative, compliance, and one technology lead per system under review. Keep the group small enough to make real decisions in the room rather than deferring everything to follow-up.

1. List every AI system from your inventory and confirm no additions have surfaced since the last review.
2. Assign Responsible, Accountable, Consulted, and Informed roles for each system, insisting on exactly one Accountable party per system.
3. Flag disputed or shared systems for a follow-up decision within one week, not left open indefinitely.
4. Update Statements of Responsibility for every SMF holder whose remit changed as a result of the session.
5. Circulate the finalized management responsibility map to all participants and file it as a dated governance record.

The most common mapping mistake is over-relying on IT to self-report ownership, since technology teams often describe systems in terms of what they built rather than what business outcome the system drives. The second most common mistake is under-involving risk early, which leads to risk ratings applied retroactively rather than shaping the ownership discussion from the start. A governance maturity framework can help calibrate how rigorous your mapping exercise needs to be relative to your firm's actual AI footprint.

Validate the finished map by checking three things: does every material system have exactly one named Accountable senior manager, does the Statement of Responsibilities language match the RACI outcome, and can a reviewer trace from any given AI system back to a specific accountable individual in under a minute.

How Aetherpulse Produces Audit-Ready Evidence Without Touching Customer Data

Most governance tooling asks you to choose between visibility and intrusion, either you deploy agents inside production systems, or you accept limited oversight. Aetherpulse takes a different route: it connects through metadata only, via OAuth, and never touches customer data directly, which matters when the goal is oversight evidence, not another system with production access to manage.

The platform builds an inventory and identity graph of your organization's AI agents automatically, rather than relying on manual spreadsheet updates that go stale within a quarter. It surfaces risk concentration, including financial blast-radius exposure, so a senior manager can see at a glance which systems carry the most consequence if something goes wrong. When a supervisor or internal audit function requests evidence, Aetherpulse generates tamper-evident, cryptographically signed evidence packs using HMAC-SHA256, giving you a defensible export rather than a hastily assembled folder of screenshots.

Feature highlights that map directly to regulator expectations:

• Automated AI agent inventory built from metadata, updated continuously rather than manually.
• Cryptographically signed evidence packs that prove provenance without requiring a supervisor to trust your internal process on faith.
• Read-only, non-invasive connections that never require production access or customer data exposure.
• Retention and export functionality aligned to the EU AI Act Article 26, FCA SYSC, and Consumer Duty documentation expectations.

Two situations show the value clearly. First, a regulator request: rather than scrambling to reconstruct which systems exist and who owns them, a compliance lead exports a current inventory snapshot and a signed evidence pack showing testing and monitoring history in minutes. Second, a post-incident review: after an anomaly in an automated decisioning tool, the firm pulls decision provenance and change history to confirm exactly when the model was last updated and who approved it, closing the investigation faster and with a documented answer.

Pro Tip: If you are weighing whether to build this capability internally, hire a consultancy, or adopt a platform, the tradeoffs are worth working through deliberately rather than defaulting to whichever option a vendor pitches hardest. A platform-versus-consultancy comparison is a useful starting point before committing budget.

Guidance on Integrating AI Ethics Frameworks With Legal Obligations

Ethics frameworks and legal obligations under SMCR are not competing priorities, they overlap substantially, and treating them separately creates duplicate work. A firm's AI ethics principles, typically covering fairness, accountability, and harm avoidance, map almost directly onto the FCA's transparency, human oversight, and safety expectations.

The practical move is to fold ethics review into your existing risk-rating process rather than running it as a parallel exercise owned by a different committee. If your risk assessment already asks whether a model could produce disparate outcomes across customer segments, you have effectively answered the core fairness question an ethics framework would raise separately. Document that overlap explicitly in your governance policy so a supervisor sees one coherent process, not two frameworks that were never reconciled.

Methods for Maintaining Explainability in Complex AI Systems

Explainability gets harder as systems become more autonomous, particularly with agent-based automations that chain multiple decisions together without a single human checkpoint. The practical answer is not full technical transparency into model internals, which is often impossible for complex models anyway, but decision-level documentation that a non-technical reviewer can follow.

Maintain a decision log that records the inputs to each material decision, the output produced, and a plain-language summary of the logic path, even for models where the underlying architecture is genuinely opaque. Pair this with model documentation standards that specify version history, training data provenance, and known limitations. For agent-driven systems specifically, log each step in a decision chain separately, not just the final output, since regulators reviewing a harmful outcome will want to see where in the chain things diverged from expected behavior.

Handling Data Privacy Within AI Governance Under SMCR

AI governance and data privacy obligations intersect constantly, particularly where models process personal data to generate customer-facing decisions. Senior managers overseeing AI systems remain accountable for data protection compliance in that area, meaning a data privacy failure inside an AI system is still, first and foremost, an SMCR governance failure attached to a named individual.

The practical control is ensuring your AI inventory captures what personal data each system processes, not just what business function it serves. This lets you cross-reference data protection impact assessments against your risk register rather than maintaining two disconnected compliance processes. Metadata-only governance approaches, which assess system behavior and configuration without accessing the underlying customer data itself, offer one way to build oversight visibility without expanding your own data exposure footprint in the process.

Continuous Monitoring Strategies to Maintain Compliance

A model approved six months ago is not necessarily the model running today, particularly if it retrains on new data or a vendor pushes an update. Continuous monitoring, not periodic review, is what keeps your evidence current and your risk ratings accurate.

Set monitoring cadences based on risk rating rather than applying one schedule across every system: high-risk systems warrant weekly or even daily automated checks against performance thresholds, while lower-risk tools might need only monthly review. Define drift indicators in advance, meaning specific, measurable signs that a model's behavior has shifted from its tested baseline, so monitoring produces an objective trigger rather than a subjective judgment call made after the fact. Revisit your risk ratings on a fixed schedule, not just when something goes wrong, since a system's risk profile can change as its usage scales even without any technical modification.

Precedent and Enforcement Patterns Under the Senior Managers Regime

There is no widely publicized enforcement case built specifically around AI-caused harm under SMCR yet, and that absence is itself informative. It means the regulatory test currently being applied is the existing reasonable-steps standard, interpreted by supervisors against whatever evidence a firm can produce, rather than a bespoke AI liability framework with its own established case law.

That makes historical SMCR enforcement patterns, built around delegation failures, documentation gaps, and inadequate monitoring in non-AI contexts, a genuinely relevant guide. Firms that faced enforcement for conduct failures outside AI were consistently criticized for the same gaps now showing up in AI governance commentary: unclear ownership, absent escalation records, and reliance on assurance rather than evidence. The lesson transfers directly. Why regulators audit AI agents at all traces back to this same pattern of expecting proof, not process descriptions.

Communication Protocols for AI Incidents Under SMCR

When an AI system causes or risks causing customer harm, the communication clock starts immediately, and how a firm handles that early window often shapes the entire supervisory relationship going forward. Notify your regulator through established channels as soon as a material incident is identified, providing a factual summary rather than waiting until root cause analysis is complete.

Internally, the escalation path should route directly to the named senior manager accountable for that system, not through a general IT incident queue where AI-specific context can get lost. Prepare a standard incident summary template in advance, covering what happened, when it was detected, immediate containment steps, and a remediation timeline, so you are not drafting that structure for the first time under pressure. Follow up with the regulator once remediation is complete and document that follow-up as part of your evidence trail, since a demonstrated close-out is itself a governance signal worth having on record.

An Editorial Take on What Actually Matters This Quarter

The gap between firms that handle AI oversight well and firms that struggle is rarely about sophistication. It is about sequencing. Too many governance programs start with policy documents and ethics statements before anyone has actually listed which AI systems exist inside the firm. That order is backward. Inventory first, named ownership second, everything else follows from those two decisions.

If you take one thing from this guide into your next leadership meeting, make it this: assign owners to every AI system that currently lacks one, and start logging decisions and tests today, even imperfectly. A partial evidence trail that started three months ago beats a comprehensive policy framework with zero supporting records behind it. Lead this from the senior management team directly, not by delegating the RACI mapping exercise to a junior analyst and reviewing it later. Regulators can tell the difference between governance that was designed by leadership and governance that was assigned as homework.

Get Audit-Ready Evidence Before Your Next Supervisory Review

Building an internal evidence pipeline from scratch, spreadsheets, manual logs, and ad hoc exports, takes months most compliance teams do not have, especially with an inventory that changes every time a business unit adopts a new AI tool. Aetherpulse gives you that pipeline already built: a live agent inventory, risk concentration mapping, and cryptographically signed evidence packs generated on demand, all through a read-only metadata connection that never touches customer data.

A demo walks through exactly what a supervisor would see: a sample inventory pulled from your own environment, a risk concentration view highlighting your highest-exposure systems, and an exportable, tamper-evident evidence pack you can hand to an auditor without reformatting anything. Pricing scales with firm size and deployment scope, detailed on the Aetherpulse pricing page, so you can see what tier fits before committing to anything. Request a demo and ask specifically to see the evidence export in action, that single feature tends to answer most of the questions a compliance team has before the call even ends.

Frequently Asked Questions

Does a firm need a specific AI policy separate from its existing SMCR framework? Not necessarily as a standalone document. The FCA has signaled that existing SMCR duties already apply to AI, so the priority is mapping AI systems into your current Statement of Responsibilities structure rather than building a parallel policy framework from scratch.

What counts as "reasonable steps" for AI oversight specifically? It generally means demonstrable governance: a named owner, a documented risk rating, evidence of testing before deployment, and ongoing monitoring with defined escalation triggers. The exact bar depends on the system's risk level and potential customer impact.

Can a senior manager delegate AI oversight to a technology team entirely? Delegation of tasks is fine, but accountability under SMCR does not transfer. The senior manager remains responsible for ensuring oversight happens, even when day-to-day monitoring sits with a technical team.

How long should AI testing and monitoring records be retained? There is no single fixed period specified for all firms, but retaining records for the operational life of the model plus a reasonable period afterward gives you coverage for most supervisory review windows and incident investigations.

Is metadata-only governance tooling sufficient for regulatory evidence requirements? It depends on what a supervisor asks for, but inventory, provenance, and testing logs are exactly the categories regulators have indicated they want to see, and metadata-only approaches can capture all of that without requiring access to underlying customer data.

This article is general information, not a substitute for advice from a qualified lawyer. Consult a qualified legal professional about your own circumstances before acting on anything here.

Sources

• Senior Managers Regime | FCA
• From principles to practice: the FCA’s evolving expectations on AI governance | Ropes & Gray
• Consolidated TEXT: 32024R1689 — EN — 27.07.2026

Recommended

• AI Compliance Gap Assessment Guide for Regulated Firms - AETHER Pulse
• AI Explainability Requirements for Compliance Officers - AETHER Pulse
• AI Regulatory Disclosure Obligations Explained for Finance - AETHER Pulse
• AI Governance Evidence Library - AETHER Pulse