Wie een AI-dienst gebruikt, ziet doorgaans alleen de voorkant: een chatinterface, een agent, een knop die een document verwerkt. Wat er onder de motorkap draait, blijft onzichtbaar. Nieuwe richtsnoeren van de NSA en aanvullend onderzoek van de Cloud Security Alliance maken duidelijk dat die onzichtbaarheid een probleem is. Achter één AI-dienst schuilt vaak een keten van leveranciers, datasets, modellen, infrastructuur en third-party diensten — en risico's als backdoors, datapoisoning en misconfiguraties worden in die keten als relevante bedreigingen gezien.
De AI-keten als expliciet aandachtsgebied
Op 4 maart 2026 publiceerde de NSA het document Artificial intelligence and machine learning: Supply chain risks and mitigations. De Cloud Security Alliance vatte deze guidance samen in een research note en vertaalde ze naar een praktisch raamwerk. Daarin wordt de AI/ML-supply chain uiteengelegd in zes onderdelen: trainingdata, modellen, software, infrastructuur, hardware en third-party services.
Aan die keten koppelt de CSA-analyse concrete maatregelen: een AI Bill of Materials (AI BOM) die alle componenten inventariseert, cryptografische integriteitsvalidatie en threat-modelleren over de volledige pipeline. De kern is dat organisaties de volledige keten moeten meenemen en niet alleen het hoofdmodel beoordelen. Elke schakel — subverwerkers in de keten — hoort systematisch in kaart gebracht en gecontroleerd te worden.
Deze insteek staat niet op zichzelf. Het Artificial Intelligence Risk Management Framework van NIST beschrijft supply-chainrisico's voor AI-systemen al langer en adviseert organisaties om alle leveranciers, subcontractors en componenten te identificeren, AI-BOM's en SBOM's te eisen en third-party providers expliciet te beoordelen op hun eigen ketenbeveiliging. De richting is consistent: ketencontrole is in deze bronnen nadrukkelijk een governance- en risicomanagementvraagstuk, niet alleen een technisch detail.
Hoe ketencontrole er technisch uitziet
Wat betekent dit in de praktijk? Een academisch artikel op arXiv, A Framework for AI Software Bill of Materials, werkt dit uit. De auteurs stellen voor om modellen, datasets, libraries en diensten als afzonderlijke artefacten vast te leggen, met continue model lineage-tracking en cryptografische provenance-validatie door de MLOps-pipeline heen. Zo wordt herleidbaar waar een model vandaan komt, welke data het heeft gezien en welke onderliggende componenten meedraaien.
Het artikel koppelt dit expliciet aan bestaande standaarden zoals NIST SSDF en het AI RMF, en aan zero-trustprincipes. De boodschap is dat subverwerkers in deze benadering niet langer als onzichtbare componenten achter een API zouden moeten fungeren. Ketenbeheersing is een ontwerpvraagstuk, waarbij zichtbaarheid per component het uitgangspunt is.
Governance, contracten en auditrechten
Ketencontrole is niet alleen techniek. Een analyse van Mitratech, NIST AI RMF and Third-Party Risk, laat zien dat meerdere functies in het NIST-raamwerk — GOVERN, MAP en MANAGE — expliciet gericht zijn op externe software, data en diensten. Third-party risico is daarmee formeel onderdeel van AI-risk management.
Foley & Lardner LLP vertaalt dit in Five Steps Every Manufacturer and Supply Chain Manager Should Take naar concrete stappen: leveranciers contractueel verplichten transparant te zijn over hun modellen, dataprovenance, testprotocollen en logging, en terugkerende assessments en auditrechten inbouwen. Voor organisaties met gevoelige informatie komen daarmee vaste vragen op tafel: wie zijn onze AI-subverwerkers, welke datasets en diensten gebruiken zij, hoe vaak toetsen we hun beveiliging, en welke fallback-scenario's zijn geborgd?
Waar een verificatielaag kan helpen
Een praktische uitdaging is de kloof tussen de front-end die een professional ziet en de keten die daarachter draait. Precies daar kan een verificatielaag extra zichtbaarheid bieden. IamVera.ai is geen chatbot en geen eigen taalmodel, maar een privacygerichte verificatielaag voor professionals die met vertrouwelijke of hoog-trust informatie werken.
Vera kan een taak door geselecteerde, onafhankelijke AI-modellen routeren en daarbij verificatiestappen, correcties, onderlinge verschillen en bronnen zichtbaar maken voor inspectie. Dat ondersteunt controle en review; het is geen garantie voor correctheid of waarheid en het maakt hallucinaties niet onmogelijk. Wat het wél doet, is verificatiestappen, correcties, onderlinge verschillen en bronnen zichtbaar maken voor inspectie — een benadering die aansluit bij het bredere idee van zichtbaarheid en review.
Voor de datascope is het Semantic Privacy Shield relevant. Deze kan gevoelige documentwaarden vervangen door synthetische, sessie-gebonden equivalenten op EU-infrastructuur, vóórdat AI-verwerking plaatsvindt. De AI-keten analyseert de synthetische versie; de oorspronkelijke waarden kunnen lokaal worden hersteld na de workflow. De architectuur is ontworpen om alleen geanonimiseerde inhoud door te sturen naar de geselecteerde modellen. De workflow is fail-closed: mislukt de privacycontrole, dan wordt het document niet doorgestuurd. Dit is een architectuurbeschrijving, geen belofte van foutloze anonimisering of volledige AVG-compliance.
Geüploade PDF's worden tijdelijk verwerkt voor de actieve run en niet permanent opgeslagen; PDF-metadata kan bewaard blijven voor sessiegeschiedenis. Binnen die beschermde workflow kunnen gebruikers documenten bekijken en bewerken via Vera Office, dat gebruikmaakt van Collabora Online. Vera Office bewerkt niets autonoom en is geen Microsoft Office-plug-in; de gebruiker houdt de regie.
Zichtbaarheid als vertrekpunt
De richtsnoeren van de NSA, het NIST-raamwerk en de aanvullende analyses wijzen in dezelfde richting: subverwerkers en onderliggende componenten mogen geen black box meer zijn. Een verifieerbare inventaris van de keten, met inzicht in welke partijen bij welke gegevens konden en onder welke voorwaarden, wordt onderdeel van serieus AI-gebruik. Een verificatielaag kan dat zicht ondersteunen, maar in mijn beoordeling blijft het professionele eindoordeel — welke keten aanvaardbaar is en welke niet — bij de gebruiker.