Notes on the Bank of England and FCA’s 2026 survey of AI in UK financial services
I have spent most of my career where regulation meets data, so when the Bank of England and the Financial Conduct Authority publish a survey on how firms are using AI, I read it for what it says about risk rather than adoption. The 2026 edition, the fourth in the series, covers 196 firms. Adoption is now close to universal: 86% of respondents use AI, up from 75% in 2024, and every responding UK and international bank does.
The more interesting finding is a gap. Firms are clear about where they think the risk sits. The controls they describe for the AI systems that matter most are governed largely by overly simplified black-and-white rules, or trust. That is not a criticism of the firms. It reflects what has been practical until now. This post is my attempt to explain the gap, and why I think it is starting to close.
Data protection is the top concern, and prompt leakage is its own category
Respondents rated data protection and security as the highest current risk from AI, ahead of third-party and supply-chain risk and gen AI-specific risks. UK data protection and privacy rules were also the most-cited perceived regulatory constraint, with 42% of firms saying they impose a high compliance burden.
One detail is easy to miss. The regulators list data leakage via prompts/outputs as an example of a gen AI-specific risk, separate from data protection in general – making the overall “data and model protection” category of risks by far the largest. That being said, I think that distinction is useful. Leakage through prompts and outputs happens while the data is being used, in the prompt sent to a model, in the context a retrieval system pulls in, and in what comes back. Most data protection and AI governance tools do not suffice in this context.
More of the AI that matters belongs to someone else
Third-party systems made up 39% of all reported AI systems, up from 33% in 2024. Among high-materiality systems the shift is sharper: 53%, up from 35%. Supply is also concentrated. The top three cloud and compute providers account for 79% of reported relationships.
Firms are aware of this. Information security and operational resilience were the biggest constraints on adopting third-party AI for 40% of respondents, and 34% pointed to limited transparency into third-party systems. Overseeing third-party AI was the most commonly reported governance challenge.
Assurance is not evidence
The finding that stayed with me concerns how firms understand their “high-materiality” systems. For systems they built themselves, 77% rely on deep knowledge of how those systems work. For third-party systems, that falls to 24%, and 81% rely instead on vendor assurance and contractual arrangements. Read that again – they are relying on the vendor assuring themselves, and protecting themselves only with a contract! Where have we seen this before, I wonder?
I want to be fair about what this means. For a long time, these ways of working have been the main tools available to organizations when working with data and AI vendors.. But a contract describes how a provider has agreed to handle your data. It does not show you, nor enforce for you, how the data was handled.
I made a related point in a recent session with Capgemini Invent: the world where we could rely only on paper and contracts is behind us. From the regulatory angle, several jurisdictions are moving from a risk-based approach towards something closer to “prove it to me.” From a practical angle, there are proven technologies that help enforce and prove how data and models are used, which don’t negate the need for contracts and assurance, but rather complement them. A survey in which 81% of oversight of the most important third-party systems rests on assurance suggests UK financial services is meeting that shift with the tools of the past.
What evidence looks like
There is a practical way to close part of this gap with “Confidential Computing”, which isolates processing of data and models, and evidences the entire workflow with cryptographic attestations.
The part that matters most for oversight is this attestation. Financial services organizations and their AI vendors can still work together on any infrastructure, but both sides can better control their data and models to prevent leakage, and more importantly, add a different kind of control from a contractual commitment, because it can be checked and used for prevention, rather than taken on trust and operating at a lag.
What this means is that AI generally, including Generative AI can run inside hardware-protected enclaves with attestation. In this way of working, prompts, retrieved context and model weights are decrypted only inside the attested enclave which protects the sensitive data from third party prying eyes.
What does not change
None of this replaces governance, and it would be a mistake to present it that way. Technical evidence goes hand in glove with the legal and organizational controls a firm already has. Three things remain the firm’s responsibility:
- Model behavior. Confidential computing protects data and models while they are processed. It does not stop a model from hallucinating or prevent prompt injection on its own, it does not changes whether a model is explainable or not, and it does not affect model attributes like bias. Said another way – the model remains the model – this just changes the protections around how it is run.
- Access to outputs. Who may see what a model returns is still a question of access control and policy.
- Accountability. The firm remains accountable for its use of a third-party system, however strong the technical controls around it.
What changes is the quality of the evidence behind the oversight.
Where to start
In my experience, the best starting point is a short inventory of the third-party AI systems a firm already rates as high-materiality. For each one, a few questions are worth asking:
- What data leaves our environment when this system runs, including prompts and retrieved context?
- Who could see that data while it is being processed?
- Beyond the contract, what evidence would show us how it was handled and prevent it from being mis-handled?
- Are we testing for leakage, or only reviewing before deployment?
Where the honest answer to the third question is “nothing yet,” there is a case for doing it differently.
Looking ahead
The survey shows an industry that already knows where its AI risk sits. What it does not show yet are that they are using suitable solutions to address these risks, and a way to verify these risks are being mitigated. As third-party AI continues to takes a larger share of material use, I expect the question in risk committees to shift from “do we trust this vendor?” to “prove to me that I can continue to trust this vendor.”
I would welcome hearing from risk, compliance and model risk leaders in UK financial services about where third-party AI oversight is hardest in practice. Those conversations show us where the work is.
