Bank of England en FCA melden groei van third-party AI en sterke providerconcentratie

Third-party AI-systemen vormen volgens de Bank of England en de FCA een groeiend en in veel gevallen materieel deel van het AI-gebruik, terwijl organisaties vooral op leveranciersverklaringen en contracten vertrouwen. Naar onze analyse zou wie verantwoordelijk blijft voor de uitkomst een versieerbare ketenregistratie moeten aanleggen: per verwerking welke subverwerker, modelversie en route toegang had en, voor zover reconstrueerbaar, welke wijziging de output beïnvloedde.

In hun vierde enquête naar AI en machine learning in de Britse financiële sector, gepubliceerd op 26 oktober 2026, rapporteren de Bank of England en de Financial Conduct Authority dat extern geleverde AI-systemen inmiddels ongeveer vier op de tien van de gemelde systemen vormen en ruim de helft van de systemen met de hoogste impact. De drie grootste cloud- en computeproviders vertegenwoordigen bijna acht op de tien relaties, de drie grootste model- en API-providers iets meer dan de helft. Ongeveer acht op de tien respondenten leunt bij deze systemen vooral op leveranciersverklaringen en contractuele afspraken; slechts een kwart meldt diepe kennis van het systeem zelf. De enquête beschrijft deelnemende financiële instellingen en is naar onze inschatting geen universele marktmeting; de gevolgen voor een specifieke verwerkingsverantwoordelijke moeten per keten en toepasselijke AVG-verplichtingen worden vastgesteld.

Wat stelt de Bank of England/FCA-enquête precies vast over third-party AI?

De enquête laat drie samenhangende patronen zien: third-party AI-systemen vormen een groter aandeel van de gemelde systemen en van de high-materiality-systemen, de onderliggende leveranciers zijn sterk geconcentreerd bij enkele cloud-, compute-, model- en API-partijen, en 34% van de respondenten noemt beperkte transparantie in third-party AI-systemen een grote beperking. De afhankelijkheid van leveranciersverklaringen is daarmee geen incidentele keuze, maar het dominante beheersingsmechanisme.

Naar onze inschatting is de concentratie het onderschatte deel. Dit wijst erop dat, als een handvol providers de keten domineert, het risico verschuift van individuele leveranciers naar systeemafhankelijkheid: één wijziging bij een modelprovider kan dan bij veel afnemers tegelijk doorwerken, zonder dat ieder van hen die wijziging ziet.

Waarom bewijst een contract met de zichtbare leverancier niet welke subverwerker de output beïnvloedde?

Omdat een AI-systeem geen enkel product is, maar een samengestelde keten. Het National Cyber Security Centre van Nieuw-Zeeland beschrijft in zijn guidance dat de AI-toeleveringsketen data, modellen, software, infrastructuur, hardware en externe diensten omvat, en dat elk onderdeel risico's voor vertrouwelijkheid, integriteit en beschikbaarheid kan veroorzaken. Onderzoekers van het KTH Royal Institute of Technology analyseren in hun analyse van de AI-softwaretoeleveringsketen die keten als een samengesteld systeem waarin onder meer modelinference, integratie en gedeelde infrastructuur het uiteindelijke gedrag mede bepalen. Zij beschrijven structurele tekortkomingen in verifieerbaarheid, versionering, observability en traceability, waardoor afhankelijkheden niet vanzelf in één betrouwbaar manifest beschikbaar zijn.

Een typische multi-modelketen loopt van de afnemer via een applicatieleverancier naar een router of API-gateway, dan naar een of meer modelproviders, een hosting- of cloudpartij en aanvullende retrieval-, embedding-, guardrail- en loggingdiensten. Naar onze analyse maakt een contract dat alleen de zichtbare applicatieleverancier aanwijst niet duidelijk welke subverwerker in die keten feitelijk persoonsgegevens ontving of welke modelversie een bepaalde uitkomst produceerde. Onze technische analyse is dat standaard software-SBOM's en algemene leveranciersverklaringen op zichzelf niet noodzakelijk voldoende zijn om multi-parent lineage en runtime-routing volledig zichtbaar te maken.

Welke juridische en operationele gaten ontstaan hierdoor in multi-model omgevingen?

De gaten zijn concreet en per stuk aantoonbaar als zij ontbreken. Voor organisaties die onder de AVG vallen, zijn onder meer de inventarisatie van betrokken verwerkers en verdere verwerkers en het vastleggen van instructies relevante beheersingsvragen. In deze analyse worden daarom de volgende mogelijke gaten onderscheiden:

• Geen actuele subverwerkersinventaris, waardoor niet vaststaat welke partij toegang had.
• Onduidelijke rolverdeling tussen verwerkingsverantwoordelijke, verwerker en verdere verwerker.
• Geen afdwingbare wijzigingsmelding, zodat een gewijzigde modelversie onopgemerkt kan doorwerken.
• Geen route- of locatiebewijs per verwerking, waardoor de regio van verwerking niet is te reconstrueren.
• Geen reconstructie van model- en API-versies op het moment van de uitkomst.
• Geen getest exit- of herstelpad wanneer een onderliggende provider wijzigt of wegvalt.

Deze zes punten zijn een redactionele ordening van de bevindingen uit de drie bronnen, niet een letterlijke opsomming uit één rapport. Waar aanvullende verplichtingen uit de EU AI Act van toepassing zijn, kan dat extra eisen meebrengen. De precieze toepasselijkheid en inhoud moeten afzonderlijk aan de hand van de verordening en de rol van de organisatie worden beoordeeld.

Wat moeten bestuurders, juristen en CISO's hier nu mee?

Onze analyse is dat, nu third-party systemen volgens de enquête 53% van de gemelde high-materiality-systemen vormen, de afnemer zijn beheersing en bewijspositie niet uitsluitend op leveranciersverklaringen zou moeten baseren. Wij adviseren de verwerkingsverantwoordelijke om binnen dit kwartaal een componenten- en subverwerkerskaart te laten opstellen die per systeem de keten van applicatieleverancier tot hostingpartij en retrieval- en guardraildiensten benoemt. Omdat ongeveer acht op de tien respondenten vooral op leveranciersverklaringen leunt en slechts een kwart diepe systeemkennis heeft, adviseren wij de jurist om in het contract een afdwingbare wijzigingsmelding en een doorlegging van instructies, beveiliging, incidentmelding, audit- en verwijderingsrechten naar iedere verdere verwerker op te nemen. Omdat de KTH-onderzoekers structurele tekortkomingen in versionering en traceability beschrijven, adviseren wij de CISO om per verzoek een privacy-minimaal route- en modelrecord in te richten dat vastlegt welke modelversie, welke route en welke regio actief waren, met betrouwbaar versie- en wijzigingsbewijs. Omdat de providerconcentratie één wijziging bij een modelprovider bij veel afnemers tegelijk kan laten doorwerken, adviseren wij de verantwoordelijke eigenaar om vóór de volgende audit een exitpad te testen dat aantoont dat de dienst bij het wegvallen van een onderliggende provider verantwoord kan worden overgezet.

Samengevat betekent dit, als bondige vertaling van die analyse:

1. Stel een actuele componenten- en subverwerkerskaart op per AI-systeem.
2. Leg per verzoek een privacy-minimaal route-, versie- en modelrecord vast.
3. Borg contractuele doorlegging van instructies, beveiliging, incidentmelding, audit- en verwijderingsrechten.
4. Verifieer leveranciersverklaringen periodiek in plaats van ze eenmalig te aanvaarden.
5. Test een exitpad voordat een onderliggende provider wijzigt of wegvalt.

De guidance van het Nieuw-Zeelandse NCSC uit 2026 is geen bindende Nederlandse of EU-regel, en de KTH-studie is een onderzoeksanalyse, geen wettelijke standaard. Wie het auditrecht in AI-contracten concreet wil maken met inspectiebewijs en wil begrijpen waarom audit trail-software controle kan suggereren zonder die te bewijzen, vindt daar de bouwstenen voor dit bewijsmodel. De bredere lijn — ketenbeheersing in plaats van modelvertrouwen — hoort thuis in uw AI-governance, en sluit aan op de aanpak rond AI-componenten in de leveranciersketen en op de vraag of een open-weight of gesloten model past bij vertrouwelijk werk.

Bronnen: Het artikel steunt op de enquête van de Bank of England en de FCA, de supply-chainguidance van het Nieuw-Zeelandse NCSC en een analyse van onderzoekers van het KTH Royal Institute of Technology.