AI-toeleveringsketen en AI bill of materials (AIBOM)
Wat is de AI-toeleveringsketen en een AIBOM?
De AI-toeleveringsketen is alles wat moest bestaan voor jouw AI-functie haar eerste vraag kon beantwoorden, en je hebt er zelf bijna niets van gemaakt. Een AI bill of materials, meestal afgekort tot AIBOM, is de lijst van die onderdelen: welke modellen, welke datasets, welke libraries, welke tools, en wie elk stuk levert.
Denk aan het allergenenblad achter de toog bij de bakker. Dat maakt het brood niet veiliger. Het maakt de vraag beantwoordbaar in de tien seconden dat de klant er staat.
Wie AI koopt in plaats van bouwt, en dat is zowat elk bedrijf, heeft een keten van ongeveer acht schakels.
Een basismodel dat je niet zelf getraind hebt, van Anthropic, OpenAI, Google of een open-weight familie.
Ofwel weights op je eigen hardware, ofwel een API waarbij het model nooit van de machines van de leverancier komt. Het tweede komt veel vaker voor en geeft je veel minder om na te kijken.
Trainingsdata die je niet kan zien, en die het grootste deel van het gedrag van het model bepaalt.
Een fine-tune die je softwareleverancier op eigen materiaal heeft gedaan, en die zelden op de factuur staat.
Libraries en frameworks, het enige stuk van de keten dat een klassieke SBOM al degelijk dekt.
Een vector store met jouw geïndexeerde documenten, plus het embedding model dat er vectoren van maakte.
Tools en MCP-servers: je CRM, een mailbox, een betaal-endpoint, een zoek-API.
De hosting van de leverancier: welke cloud, welke regio, wiens datavoorwaarden.
De meeste bedrijven kunnen de eerste en de laatste schakel benoemen. De zes daartussen zijn waar de verrassingen zitten.
SBOM tegenover AIBOM: wat kan je echt openmaken?
Een SBOM zegt wat er in een programma zit. Een AIBOM is diezelfde lijst voor een AI-systeem, en die had een eigen naam nodig omdat twee onderdelen zich niet gedragen zoals software.
Bij een SBOM kan je het onderdeel openmaken. Een regel zegt openssl 3.0.11, dus je leest de broncode, je hasht de binary en je zoekt de versie op in een vulnerability database. Dat versienummer is een belofte: net die bytes, voor altijd.
Bij een model kan dat niet. In het beste geval heb je de weights, en die vertellen je de architectuur en de grootte, en niets over wat het model geleerd heeft of waaruit. Meestal is het slechter: het model is een endpoint en je hebt helemaal niets in handen. Trainingsdata bepaalt hoe het ding zich gedraagt, en geen enkele bill of materials geeft je daar toegang toe.
Het tweede verschil is timing. Een library vastgezet op 2.4.1 is volgend jaar dezelfde code. Een gehost model achter een gewone naam of een latest alias wordt vervangen op de kalender van de leverancier, terwijl jouw prompts en jouw parsers bovenop de versie zitten die je getest hebt. Anthropic verwittigt minstens 60 dagen op voorhand voor een publiek uitgebracht model uit dienst gaat, en zegt erbij dat aanvragen naar een teruggetrokken model gewoon falen. Duidelijk beleid, en toch een onderdeel van jouw product met een vervaldatum die iemand anders zet.
Een SBOM lijst dingen op die je kan openen en verifiëren. Een AIBOM lijst dingen op die je enkel kan benoemen, dateren en aan een leverancier toewijzen.
Hoe ver staan de standaarden in september 2026?
Er is echt standaardisatiewerk, met veel marketing bovenop. Dat onderscheid telt, want een leverancier die zegt dat zijn AIBOM standaard-conform is, beweert iets dat je kan nakijken.
CycloneDX is gepubliceerd en is het formaat dat je het vaakst zal krijgen. Versie 1.5 voegde machine-learning-model en data toe als componenttypes naast de softwaretypes, plus een modelCard object voor modelparameters, datasets, technische beperkingen en ethische afwegingen, de machineleesbare tegenhanger van de model card die een aanbieder in gewone tekst publiceert. Versie 1.7 verscheen in oktober 2025 en werd in december van dat jaar door de ECMA General Assembly bekrachtigd als de tweede editie van ECMA-424.
SPDX is ook gepubliceerd. Het AI-profiel is een normatief deel van specificatie 3.0.1, met een klasse AIPackage en eigenschappen als typeOfModel, safetyRiskAssessment en useSensitivePersonalInformation, naast een apart Dataset-profiel.
CISA en de G7 publiceerden richtlijnen, en die zijn uitdrukkelijk vrijwillig. Software Bill of Materials for AI: Minimum Elements verscheen in mei 2026, van CISA samen met Duitsland, Canada, Frankrijk, Italië, Japan, het Verenigd Koninkrijk en de Europese Unie. Het sorteert de inhoud in zeven blokken: metadata over het document zelf, eigenschappen op systeemniveau, modellen, datasets, infrastructuur, beveiliging en prestatie-indicatoren. De tekst noemt die elementen aanvullend op de gewone SBOM-minimumelementen, en zegt er uitdrukkelijk bij dat ze niet volledig en niet verplicht zijn.
Wat niet bestaat, is een wet die je verplicht om een document met de naam AIBOM te publiceren. Het woord staat in geen enkel artikel van eender welke Europese verordening. De regelgeving vraagt wel de inhoud, en enkel van bepaalde partijen.
Wat vraagt de AI Act, en aan wie?
De AI Act deelt per systeem een rol uit, en de documentatieplicht valt bijna volledig bij de aanbieder. Een bedrijf dat AI-software koopt is gebruiksverantwoordelijke, en een gebruiksverantwoordelijke is geen bill of materials verschuldigd.
Een aanbieder van een hoogrisicosysteem moet de technische documentatie van bijlage IV leveren, en twee punten daarvan lezen als een AIBOM in zinnen. Punt 2(a) vraagt hoe het systeem ontwikkeld is, met inbegrip van het gebruik van voorgetrainde systemen of tools van derden en hoe die gebruikt, geïntegreerd of aangepast zijn. Punt 2(d) vraagt datasheets over de trainingsdata: herkomst, omvang en voornaamste kenmerken, hoe de data verkregen en geselecteerd is, de labelingprocedures en de opschoningsmethodes.
Een aanbieder van een AI-model voor algemene doeleinden heeft een smallere en publieke plicht. Artikel 53(1)(d) vraagt een samenvatting van de inhoud waarmee het model getraind is, op een verplicht sjabloon dat de Commissie in juli 2025 publiceerde. Dat sjabloon toont hoeveel transparantie de wet echt gekocht heeft: de grote publiek beschikbare datasets die gebruikt zijn, en de top 10 procent van de domeinen die ze gescrapet hebben, voor kmo's teruggebracht tot 5 procent of 1000 domeinen, wat het laagst uitvalt. De verplichting geldt sinds 2 augustus 2025, en modellen die al voordien op de markt waren hebben tijd tot 2 augustus 2027.
Een gebruiksverantwoordelijke valt onder artikel 26, en dat gaat over gebruik en niet over samenstelling: volg de gebruiksaanwijzing, zet bekwaam menselijk toezicht in, hou de inputdata relevant, bewaar de logs, licht de betrokkenen in. Nergens staat de vraag waarop het model getraind is. De deadline voor die hoogrisicoplichten schoof naar 2 december 2027 met de Digital Omnibus over AI, verordening (EU) 2026/1744.
De ene pagina die een KMO bijhoudt
Een bedrijf van veertig mensen gaat nooit een CycloneDX-document maken en hoeft dat ook niet. Het heeft een tabel nodig die iemand tijdens een vergadering kan openen, met vijf kolommen: welk model, via welke leverancier, op welk contract, met welke data erin, en met welke terugvaloptie.
Schrijf de exacte identifier die je systeem aanroept, dus claude-sonnet-4-5-20250929 en niet "Claude", want het merk is niet wat stopt met werken. Noteer of je rechtstreeks bij de modelleverancier koopt of via een stuk software, want dat bepaalt wie je belt. Zet erbij wat de datavoorwaarden zeggen over trainen op jouw input, wat er aan data binnengaat, en waar je naartoe zou schakelen als dit volgende maand verdwijnt.
Twee regels per systeem maken het af: wie eigenaar is, en welke tools het systeem mag aanroepen. Die tweede is de regel die zowat niemand invult.
Een uitgewerkt voorbeeld: welke systemen gebruiken model X?
Neem een Belgisch studiebureau van vijfenvijftig mensen. Op 14 april 2026 kondigde Anthropic aan dat claude-sonnet-4-20250514 op 15 juni uit dienst ging. Iemand stuurt die mail intern door met de vraag of dit hen raakt.
Zonder lijst. Niemand kan dat antwoorden, dus het antwoord wordt bij elkaar gezocht. De IT-verantwoordelijke doorzoekt de code-repositories en vindt twee treffers. Boekhouding vraagt het aan hun leverancier voor factuurverwerking, die na negen dagen laat weten dat ze op Azure OpenAI draaien, wat er niets mee te maken heeft. Een marketingtool die iemand met zijn eigen kaart betaalde, shadow AI onder een andere naam, valt pas in week drie een collega te binnen, en een Power Automate flow van iemand die het bedrijf intussen verlaten heeft, wordt op 10 juni bij toeval gevonden, vijf dagen voor de afsluiting. Niemand weet ooit zeker of de zoektocht volledig was, en bij de volgende aankondiging begint de oefening van nul.
Met de lijst. Iemand opent het blad, filtert op de modelkolom en heeft binnen de minuut vier regels, elk met een eigenaar: twee interne scripts, de offerte-assistent die een klant ziet, en een product van een leverancier waarbij in de regel al staat dat die leverancier de versie beheert. De klantgerichte assistent wordt eerst tegen het vervangmodel getest, de scripts schakelen dezelfde namiddag om, en de leverancier krijgt een mail met de vraag naar zijn migratiedatum.
Beide bedrijven kregen dezelfde zestig dagen. Eén ervan kon een aankondiging van een leverancier op de dag zelf omzetten in een lijst met namen.
Waar moet je op letten bij een AIBOM?
Een lijst maakt niets veilig. Ze maakt vragen beantwoordbaar. Als een library in je stack een bekend lek blijkt te hebben, als een leverancier zijn datavoorwaarden wijzigt, of als een klant vraagt waarop een systeem gebouwd is, dan is de lijst het verschil tussen een antwoord in een minuut en veertien dagen rondvragen.
Ze veroudert sneller dan een SBOM. Een softwarelijst verandert wanneer iemand deployt. Een AI-lijst verandert wanneer een leverancier een model achter een alias vernieuwt, zonder dat er bij jou iets uitgerold wordt. Zet een datum en een eigenaar op het blad en herlees het elk kwartaal.
Het document van de leverancier dekt het product van de leverancier. Een AIBOM van een leverancier zegt wat er in hun eigen product zit, en niets over de vector store die jij aangesloten hebt of de mailbox waartoe jij toegang gaf.
De tools zijn de ontbrekende kolom. Modellen komen in de inventaris omdat er namen en facturen aan hangen. Wat een agent mag aanroepen komt bij niemand in de inventaris, en daar zit net de schade die een aanvaller kan bereiken.
Koop hier geen software voor zolang je geen spreadsheet hebt. Er bestaan generatoren en die werken, vooral op modellen die je zelf host. Zit jouw AI in SaaS-producten, dan vindt geen enkele scanner ze. Iemand moet het aan de leveranciers vragen, en die persoon is het eigenlijke project.