Bank of England and FCA report growing third-party AI

You must now document which third-party AI system, model version and subprocessor touched each piece of personal data or influenced each material decision, and maintain that record through the lifetime of the processing. Supplier statements and contracts alone do not satisfy this obligation.

The prompt is an analysis of 26 October 2026 of the subprocessor chain, model routes and versions in third-party AI systems, which argues that financial institutions increasingly rely on externally supplied AI systems without maintaining visibility of which component in the supply chain handled which data or produced which output. The survey by the Bank of England and the Financial Conduct Authority found that externally supplied systems now account for 53 per cent of reported high-materiality systems, whilst the three largest model and API providers account for more than half of all relationships. In our assessment, this concentration means a single change at one provider could affect many customers simultaneously, and the dominant reliance on supplier statements creates a control gap that you must close through your own documentation and audit capability.

What does the survey actually show about third-party AI in the financial sector?

The Bank of England and FCA's third survey of AI and machine learning in the UK financial sector, published in October 2026, identifies three interconnected patterns. Externally supplied AI systems now represent around four in ten of all reported systems. Among high-materiality systems—those carrying significant operational or financial risk—the share rises to 53 per cent. The underlying suppliers are highly concentrated: the three largest cloud and compute providers account for almost eight in ten relationships, whilst the three largest model and API providers account for slightly more than half. Around eight in ten respondents rely primarily on supplier statements and contractual arrangements to understand these systems; only a quarter report deep knowledge of the system itself. The survey is based on participating financial institutions and should not be read as a universal market measurement; the consequences for your specific processing chain must be established separately under GDPR obligations.

Why is concentration a governance problem rather than just a scale problem?

Concentration creates a single point of failure that can propagate across many customers without each of them observing the change. When a model provider updates a model version, changes an inference route, or shifts data handling practices, that change ripples through to every customer using that provider—often without explicit notification to the downstream customer or their own audit systems. A contract naming only the visible application supplier does not make clear which subprocessor in the chain actually received personal data or which model version produced a particular output. The National Cyber Security Centre of New Zealand describes in its supply-chain guidance that the AI supply chain encompasses data, models, software, infrastructure, hardware and external services, each of which can create risks to confidentiality, integrity and availability. Researchers at the KTH Royal Institute of Technology analyse the AI software supply chain as a composite system in which model inference, integration and shared infrastructure jointly determine eventual behaviour, and they identify structural shortcomings in verifiability, versioning, observability and traceability through which dependencies are not automatically available in a single reliable manifest.

What gaps emerge when you map a typical multi-model chain?

A typical multi-model chain runs from your organisation via an application supplier to a router or API gateway, then to one or more model providers, a hosting or cloud party, and additional retrieval, embedding, guardrail and logging services. Standard software SBOMs and general supplier statements are not necessarily sufficient on their own to make multi-parent lineage and runtime routing fully visible. The gaps are concrete and demonstrable one by one when they are missing:

• Absence of a processor and subprocessor inventory — you cannot identify which parties in the chain received personal data or held instructions from you.
• Undocumented model versions and routing decisions — you cannot reconstruct which model version or inference route was active when a particular output was produced.
• No change notification or versioning mechanism — you cannot detect when a provider has updated a model, changed data handling, or shifted infrastructure without independent monitoring.
• Lack of pass-through rights in contracts — your contractual rights to audit, delete data, or receive incident notification do not extend to subprocessors beyond the immediate supplier.
• Absence of runtime observability — you cannot capture which region, which infrastructure, or which guardrail service was active during a particular inference.
• No exit or transfer capability — you cannot demonstrate that the service can be transferred responsibly if an underlying provider becomes unavailable or unsuitable.

What must you be able to demonstrate in an audit?

You should establish the following controls before your next audit cycle:

1. Maintain a versioned component and subprocessor map — document per system the chain from application supplier through to hosting party, retrieval services and guardrail services, with each party's role and data access clearly identified.
2. Record model version, inference route and region per request — capture which model version, which routing decision and which infrastructure were active for each material processing, with reliable version and change evidence.
3. Enforce change notification and instruction pass-through in contracts — require your immediate supplier to notify you of material changes to models, versions, data handling or infrastructure, and to pass through your audit, deletion and incident notification rights to every further processor.
4. Establish a privacy-minimal audit trail — implement logging that captures routing and versioning decisions without storing unnecessary personal data, so you can reconstruct what happened without creating additional retention obligations.
5. Test an exit path before dependency deepens — demonstrate that the service can be transferred to an alternative provider or brought in-house if an underlying provider drops away or becomes unsuitable.

How should you translate this into governance action?

Now that third-party systems account for 53 per cent of reported high-materiality systems, you should not base your control and evidence position solely on supplier statements. Have a component and subprocessor map drawn up this quarter that names the chain from application supplier to hosting party and retrieval and guardrail services. Include in your contracts an enforceable change notification mechanism and a pass-through of instructions, security, incident notification, audit and deletion rights to every further processor. Set up a privacy-minimal route and model record per request that captures which model version, which route and which region were active, with reliable version and change evidence. Test an exit path that demonstrates the service can be transferred responsibly when an underlying provider drops away.

Tooling can help you capture and organise this information, but the governance decision—which model is suitable for which data, which provider concentration you will tolerate, which changes trigger a review—remains yours. The KTH researchers describe structural shortcomings in versioning and traceability that no single vendor tool can fully overcome; you must build the control framework first, then select tooling that fits it rather than accepting the control framework that a tool imposes.