According to the Bank of England and the FCA, third-party AI systems form a growing and in many cases material part of AI use, while organisations mainly rely on supplier statements and contracts. In our analysis, whoever remains responsible for the outcome should build a versioned chain record: per processing, which subprocessor, model version and route had access and, as far as reconstructable, which change influenced the output.
In their third survey of AI and machine learning in the UK financial sector, published on 26 October 2026, the Bank of England and the Financial Conduct Authority report that externally supplied AI systems now make up around four in ten of the reported systems and 53% of the reported high-materiality systems. The three largest cloud and compute providers account for almost eight in ten relationships, the three largest model and API providers slightly more than half. Around eight in ten respondents mainly rely on supplier statements and contractual arrangements for these systems; only a quarter report deep knowledge of the system itself. The survey describes participating financial institutions and is, in our estimation, not a universal market measurement; the consequences for a specific controller must be established per chain and applicable GDPR obligations.
What exactly does the Bank of England/FCA survey establish about third-party AI?
The survey shows three interconnected patterns: third-party AI systems form a larger share of the reported systems and of the high-materiality systems, the underlying suppliers are strongly concentrated among a few cloud, compute, model and API parties, and 34% of respondents cite limited transparency in third-party AI systems as a major constraint. Reliance on supplier statements is therefore not an incidental choice, but the dominant control mechanism. In our analysis, concentration is the underestimated part: a single change at a model provider could ripple through to many customers at once, without each of them seeing that change.
Why does a contract with the visible supplier not prove which subprocessor influenced the output?
Because an AI system is not a single product, but a composite chain. The National Cyber Security Centre of New Zealand describes in its guidance that the AI supply chain encompasses data, models, software, infrastructure, hardware and external services, and that each component can create risks to confidentiality, integrity and availability. Researchers at the KTH Royal Institute of Technology analyse in their analysis of the AI software supply chain that chain as a composite system in which, among other things, model inference, integration and shared infrastructure jointly determine the eventual behaviour. They describe structural shortcomings in verifiability, versioning, observability and traceability, through which dependencies are not automatically available in a single reliable manifest.
A typical multi-model chain runs from the customer 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. In our analysis, a contract that names only the visible application supplier does not make clear which subprocessor in that chain actually received personal data or which model version was involved in producing a particular outcome. Our technical analysis is that standard software SBOMs and general supplier statements are not necessarily sufficient on their own to make multi-parent lineage and runtime routing fully visible.
Which legal and operational gaps does this create in multi-model environments?
The gaps are concrete and demonstrable one by one when they are missing. For organisations subject to the GDPR, relevant control questions include the inventory of processors and further processors involved and the recording of instructions. This analysis therefore distinguishes the following possible gaps:
- No current subprocessor inventory, so it is not established which party had access.
- Unclear division of roles between controller, processor and further processor.
- No enforceable change notification, so a changed model version can ripple through unnoticed.
- No route or location evidence per processing, so the region of processing cannot be reconstructed.
- No reconstruction of model and API versions at the moment of the outcome.
- No tested exit or recovery path when an underlying provider changes or drops away.
These six points are an editorial ordering of the findings from the three sources, not a literal list from one report. Where additional obligations from the EU AI Act apply, that can bring extra requirements, which must be assessed separately on the basis of the regulation and the organisation's role.
What should directors, lawyers and CISOs do with this now?
Our analysis is that, now that third-party systems account for 53% of the reported high-materiality systems according to the survey, the customer should not base its control and evidence position solely on supplier statements. We advise the controller to have a component and subprocessor map drawn up this quarter that, per system, names the chain from application supplier to hosting party and retrieval and guardrail services. We advise the lawyer to include in the contract an enforceable change notification and a pass-through of instructions, security, incident notification, audit and deletion rights to every further processor. Because the KTH researchers describe structural shortcomings in versioning and traceability, we advise the CISO to 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. Because the provider concentration can let a single change ripple through to many customers at once, we advise the responsible owner to test, before the next audit, an exit path that demonstrates that the service can be transferred responsibly when an underlying provider drops away.
In summary, this means, as a concise translation of that analysis:
- Draw up a current component and subprocessor map per AI system.
- Record a privacy-minimal route, version and model record per request.
- Secure contractual pass-through of instructions, security, incident notification, audit and deletion rights.
- Verify supplier statements periodically rather than accepting them once.
- Test an exit path before an underlying provider changes or drops away.
The 2026 guidance from New Zealand's NCSC is not a binding Dutch or EU rule, and the KTH study is a research analysis, not a legal standard. Anyone who wants to make the audit right in AI contracts concrete with inspection evidence and understand why audit trail software may create an appearance of control without proving it will find the building blocks for this evidence model there. The broader line — chain control instead of model trust — belongs in your AI governance for the whole chain, and connects to the approach around AI components in the supply chain and to the question of whether an open-weight or closed model suits confidential work.
Sources and references
Sources: The article draws on the survey by the Bank of England and the FCA, the supply-chain guidance of New Zealand's NCSC and an analysis by researchers at the KTH Royal Institute of Technology.