Bank of England en FCA: groei third-party AI
Bank of England en FCA tonen groeiende third-party AI en providerconcentratie. Leg de subverwerkersketen, modelroutes en versies vast om verantwoordelijkheid
U moet per AI-systeem dat via derden wordt geleverd vastleggen welke subverwerkersroute actief is, welke modelversie wordt gebruikt en welke wijzigingen aan die keten zijn doorgevoerd — niet alleen vertrouwen op leveranciersverklaringen.
De aanleiding is een analyse van 26 oktober 2026 van de groei van third-party AI en providerconcentratie in de Britse financiële sector, die aantoont dat extern geleverde AI-systemen inmiddels ruim de helft van de systemen met de hoogste impact vormen, terwijl drie grote cloudproviders bijna acht op de tien relaties controleren. De analyse gebruikt de enquête van de Bank of England en de Financial Conduct Authority naar AI en machine learning in de financiële sector als uitgangspunt. In onze beoordeling betekent dit dat u als verwerkingsverantwoordelijke niet langer kunt volstaan met contractuele afspraken met de zichtbare applicatieleverancier — u moet de volledige keten van model tot hosting tot aanvullende diensten kunnen reconstrueren en bewijzen welke versies en routes op welk moment actief waren.
Waarom concentratie bij enkele providers het risico verschuift
De drie grootste model- en API-providers vertegenwoordigen iets meer dan de helft van alle relaties. Dit betekent niet alleen dat u afhankelijk bent van enkele leveranciers, maar dat een wijziging bij één modelprovider tegelijk bij veel afnemers doorwerkt — zonder dat ieder van hen die wijziging ziet aankomen. Acht op de tien respondenten verlaat zich vooral op leveranciersverklaringen; slechts een kwart heeft diepgaande kennis van het systeem zelf. Dit patroon maakt u kwetsbaar voor systeemafhankelijkheid in plaats van individuele leveranciersrisico's.
Welke gaten in zichtbaarheid en beheer ontstaan in een multi-modelketen
Een typische keten loopt van u 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. Een contract dat alleen de zichtbare applicatieleverancier aanwijst, maakt niet duidelijk welke subverwerker feitelijk persoonsgegevens ontving of welke modelversie een bepaalde uitkomst produceerde. Standaard software-SBOM's en algemene leveranciersverklaringen maken multi-parent lineage en runtime-routing niet noodzakelijk volledig zichtbaar.
De volgende gaten zijn concreet aantoonbaar als zij ontbreken:
- Onbekende subverwerkersroute — u weet niet welke verdere verwerkers in de keten persoonsgegevens ontvangen of verwerken.
- Geen modelversieregistratie — u kunt niet reconstrueren welke modelversie een bepaalde uitkomst heeft gegenereerd.
- Afwezige wijzigingsmelding — u wordt niet op de hoogte gesteld van wijzigingen aan modellen, routes of hosting.
- Geen audit trail per verzoek — u kunt niet bewijzen welke versie, route en regio op welk moment actief waren.
- Onvoldoende instructiedoorlegging — uw instructies bereiken niet alle verdere verwerkers in de keten.
- Geen exitpad — u kunt niet aantonen dat u de dienst verantwoord kunt overzetten als een onderliggende provider wegvalt.
Welke concrete controles u moet kunnen aantonen
Om uw beheersing en bewijspositie te versterken, moet u per systeem kunnen aantonen:
- Componenten- en subverwerkerskaart — u hebt een actuele kaart opgesteld die per systeem de volledige keten van applicatieleverancier tot hostingpartij en retrieval- en guardraildiensten benoemt.
- Afdwingbare wijzigingsmelding in contracten — uw contracten bevatten een verplichting tot onverwijlde melding van wijzigingen aan modellen, routes, versies en hosting, met doorlegging van instructies naar iedere verdere verwerker.
- Privacy-minimaal route- en modelrecord — u kunt per verzoek vastleggen welke modelversie, welke route en welke regio actief waren, met betrouwbaar versie- en wijzigingsbewijs.
- Auditrecht met inspectiebewijs — uw contracten geven u het recht op audit en inspectie bij iedere verdere verwerker, niet alleen bij de zichtbare applicatieleverancier.
- Getest exitpad — u hebt aangetoond dat u de dienst verantwoord kunt overzetten als een onderliggende provider wegvalt.
Hoe u dit in uw AI-governance inbouwt
Dit hoort niet thuis in incidentele contractonderhandelingen, maar in uw AI-governance als structureel onderdeel van ketenbeheersing. Omdat ruim de helft van de gemelde high-materiality-systemen via derden wordt geleverd, moet u dit kwartaal een componenten- en subverwerkerskaart laten opstellen. Uw juridische team moet contracten herzien op afdwingbare wijzigingsmeldingen en doorlegging van instructies naar alle verdere verwerkers. Uw CISO moet per verzoek een privacy-minimaal route- en modelrecord kunnen inrichten. Uw eigenaar van de dienst moet een exitpad hebben getest.
De guidance van het Nieuw-Zeelandse NCSC is geen bindende Nederlandse of EU-regel, en onderzoeksanalyses zijn geen wettelijke standaarden. Maar de bouwstenen voor een bewijsmodel — ketenbeheersing in plaats van modelvertrouwen — horen thuis in uw AI-governance en sluiten aan op de vraag of een open-weight of gesloten model past bij vertrouwelijk werk. Wat tooling kan dragen en wat uw eigen professionele oordeel blijft, hangt af van de specifieke keten en uw rol daarin.
Bronnen: Dit artikel is gebaseerd op berichtgeving en richtlijnen van Bank of England and Financial Conduct Authority, New Zealand National Cyber Security Centre en KTH Royal Institute of Technology.
Geschreven door
Marit Halversen
Schrijft over AI-governance en regelgeving, met de nadruk op hoe verplichtingen neerslaan in architectuur in plaats van in papierwerk.