Who owns AI risk? A UK view for security and audit leaders

For most of the last decade, AI inside a business acted as an adviser. It produced a score, a forecast or a first draft, and a person decided what to do with it. That is changing. AI agents now approve, route, order, reply and reconfigure on their own, often with access to systems that used to be reserved for named employees.

Governance has not kept up. Deloitte's 2026 research found that 80% of automation leaders plan to speed up their investment in AI agents, while only 21% of organisations say their governance of them is mature. Just 11% of the technology leaders surveyed named legal, compliance and risk as critical to their objectives.

That gap is a governance problem before it is a technology one. In the UK it also has some particular sharp edges.

Why the UK sharpens the question

There is no single AI law to lean on. The government has asked existing regulators to apply shared principles (safety and security, transparency, fairness, accountability and contestability) within their own remits. In financial services, the FCA has signalled that it expects firms to apply the rules they already have, including the Consumer Duty and the Senior Managers and Certification Regime, rather than wait for AI-specific ones. For banks in scope, the PRA's model risk principles in SS1/23 already reach machine learning models. The practical effect is that each firm has to work out which obligations apply to which use of AI, and be able to show its working.

Accountability is personal. Under SM&CR, a senior manager has a duty to take reasonable steps to prevent regulatory breaches in their area. "The agent did it" is not a defence anyone should plan to rely on. Someone with a name has to answer for each outcome.

Boards are about to sign for controls. For financial years starting on or after 1 January 2026, boards of companies that follow the UK Corporate Governance Code are expected to declare whether their material internal controls were effective (Provision 29). Where AI now runs a process that matters to the accounts or to customers, the controls around it sit inside that declaration.

Suppliers do not carry the risk for you. Much of the AI in use arrives inside supplier products. The operational resilience rules leave firms responsible for their important business services however those services are delivered, and data protection law, which the ICO applies to AI that touches personal data, does not stop at the contract.

What the CISO should and should not carry

It is tempting to hand AI risk to the CISO, because some of it looks like cyber risk: prompt injection, data leakage, tampered models. But a biased outcome, an unlawful decision or a supplier failure is not a security incident, and a CISO left holding all of it will be answerable for results they do not control.

A better brief is narrower and firmer:

• Treat agents as identities. Each one has credentials and permissions. Give it an owner, review its access on a schedule, and make withdrawing that access a matter of minutes rather than days.
• Build the sight lines. Keep logs that show what an agent did, on whose authority and using which data, in a form that someone independent can review.
• Own containment. When an agent misbehaves or a model is compromised, security should be able to isolate it and start recovery at the speed the agent operates.
• Be in the room at design and purchase, not after go-live. The NCSC's guidelines for secure AI system development, and the government's code of practice for the cyber security of AI, give a UK baseline to hold both suppliers and internal builders to.

Five questions worth putting to the board

1. What AI is running, and who put it there? Include AI embedded in supplier software. If it is not on a list with a named business owner, it is ungoverned by definition.
2. Who answers for each outcome? One accountable person for each use case. In a regulated firm, map that person to the relevant senior management function. Where the answer is unclear, that is your first finding.
3. What can each agent touch, and how fast can we stop it? Least privilege, a tested way to switch it off, and a clear list of actions that always need a human sign-off.
4. Would we notice it going wrong? Agree thresholds for unusual behaviour, and choose two or three measures the board will actually see, such as how much of the inventory has an owner and how long it takes to withdraw access.
5. Could we prove all of this to an auditor or a regulator? Documented controls, evidence that they operate, and records kept for long enough. It is the same discipline that SOX and Provision 29 already ask of financial controls.

Where internal audit fits

AI governance needs independent challenge, and that is the job of the third line. The people who build and run agents should not be the only ones judging whether the controls work.

Internal audit can test the framework against realistic scenarios: a supplier changes a model overnight, an agent acts on corrupted data, a key platform goes down. The question for each is the same. Does the important business service stay within its impact tolerance, and can we show who decided what?

Many teams will not have the capacity to add this to a full audit plan. A co-sourced specialist working alongside the in-house team is one way to do it without a permanent hire.

A sensible place to start

You do not need a large programme to begin. Build the inventory. Give every use case an owner. Pick one high-impact scenario and run it as a tabletop exercise. For most organisations, those three steps show quickly where the real gaps are.

This article is general commentary and is not legal or regulatory advice.

Sources

• Deloitte, State of AI in the enterprise: The untapped edge (January 2026) and 2026 Global Technology Leadership Study (April 2026).
• Financial Reporting Council, UK Corporate Governance Code 2024, Provision 29.
• Prudential Regulation Authority, Supervisory Statement SS1/23: Model risk management principles for banks.
• National Cyber Security Centre, Guidelines for secure AI system development; Department for Science, Innovation and Technology, Code of practice for the cyber security of AI.