AI Bill of Materials (AIBOM): Volledige gids

Een AI Bill of Materials (AIBOM) is een gestructureerde inventaris van de datasets, modellen en afhankelijkheden in een AI-systeem, die transparantie brengt in de AI-toeleveringsketen.

Wat is een AI Bill of Materials (AIBOM)?

In mei 2026 bereikte een kwaadaardige Hugging Face-repository die zich voordeed als een officiële OpenAI-release de nummer-één trendingpositie van het platform voordat deze werd gemarkeerd en verwijderd. Omdat de echte modelkaart bijna regel voor regel was gekopieerd, zag de vermelding er legitiem uit, en iedereen die deze al had binnengehaald, kon dat niet weten, omdat een scan van softwareafhankelijkheden bibliotheken en pakketten inspecteert terwijl de compromittering in het model zelf zat.

Een AI bill of materials (AIBOM) geeft u wat die scan niet kon geven: een manier om te weten of een gecompromitteerd model of vergiftigde dataset zich al in uw omgeving bevindt.

Een AIBOM is een gestructureerde inventaris van de datasets, modellen, frameworks en afhankelijkheden waaruit een AI-systeem bestaat, waarbij de herkomst van elk onderdeel wordt vastgelegd. Het omvat de assets waarvan de oorsprong anders niet gedocumenteerd is: data van derden, vooraf getrainde modellen en open-sourcebibliotheken.

Hoe een AIBOM zich verhoudt tot een Software Bill of Materials

Een software bill of materials vermeldt de softwarecomponenten en afhankelijkheden in een applicatie: bibliotheken, pakketten, versie-identificaties en licenties. Een AIBOM breidt die inventarisatiepraktijk uit naar AI-specifieke assets, waaronder trainingsdata, modelgewichten, modelherkomst en prestatiebaselines. CycloneDX, de OWASP BOM-standaard, implementeert dit door SBOM en AI/ML-BOM te definiëren als interoperabele BOM-typen.

Kerncomponenten van een AIBOM

Een AIBOM registreert de volledige set componenten die de samenstelling, oorsprong en het operationele profiel van een AI-systeem bepalen. De richtlijnen van de G7 Cybersecurity Working Group van mei 2026, gepubliceerd als CISA's minimale elementen voor AI SBOM, organiseren deze componenten in zeven clusters.

Componentcluster	Wat het vastlegt	Waarom het erbij hoort
Metadata	Auteur van de AIBOM, aanmaakdatum, schemaversie, documentidentificatie	Legt de chain of custody vast voor het inventarisatie-artefact
Eigenschappen op systeemniveau	Softwareafhankelijkheden, frameworks, runtime-omgevingen, logica voor gegevensverwerking	Komt overeen met traditionele SBOM-inhoud; maakt CVE-tracking mogelijk
Modellen	Modelidentiteit, architectuur, hoe gewichten zijn geproduceerd (getraind, fine-tuned of gedistilleerd), gedocumenteerde beperkingen	Modelgewichten hebben geen equivalent in package-managers; herkomst maakt identificatie van manipulatie mogelijk
Dataseteigenschappen	Identiteit, herkomst, licenties, verzamelmethodologie en toegepaste preprocessing van trainings-, validatie- en testdatasets	Datavergiftiging is niet identificeerbaar via softwareanalyse; herkomstregistraties maken traceerbaar of trainingsdata zijn gemanipuleerd
Key Performance Indicators	Nauwkeurigheids-, fairness- en adversarial-resilience-benchmarks vastgelegd bij implementatie	Stelt gedragsbaselines vast; degradatie kan wijzen op adversarial manipulatie
Infrastructuur	Fysieke en virtuele infrastructuur, koppelingen naar Hardware BOM voor gespecialiseerde AI-hardware (GPU's, TPU's)	Documenteert de compute-omgeving die het model heeft geproduceerd en uitvoert
Documentstructuur en updatecadans	Versiebeheer van AIBOM-indeling, update-triggers, registraties van lifecycle-overgangen	Definieert wanneer en hoe de inventaris wordt bijgewerkt; koppelt elke overgang in de lifecycle aan vereiste wijzigingen in de getroffen clusters

Deze zeven clusters beschrijven wat een AIBOM bevat. Wanneer u elk cluster invult, hangt af van de modellifecycle: de registratie wordt in fasen opgebouwd, niet in één enkele stap.

Hoe een AIBOM wordt gegenereerd en onderhouden gedurende de modellifecycle

Een AIBOM-record krijgt vorm in vier lifecyclefasen, waarbij elke fase specifieke clusters vult uit de bovenstaande componenttaxonomie.

1. Datasourcing en voorbereiding. De AIBOM begint hier met Dataseteigenschappen: u legt de identiteit, herkomst, licenties en integriteit vast van elke trainings-, validatie- en testdataset voordat de modeltraining begint. Werk dit cluster bij bij de eerste verzameling en bij elke retraining- of fine-tuninggebeurtenis.
2. Modeltraining en fine-tuning. Tijdens training legt u de koppeling vast tussen inputdatasets, trainingscode, hyperparameterconfiguraties en de resulterende modelgewichten. Fine-tuninggebeurtenissen vereisen updates van zowel het modelcluster als het datasetcluster.
3. Build en implementatie. Bij implementatie vult u het cluster Eigenschappen op systeemniveau volledig met softwareafhankelijkheden, frameworks en details van de runtime-omgeving. KPI-baselinewaarden worden vastgelegd. Infrastructuurcomponenten worden gedocumenteerd of gekoppeld via een HBOM.
4. Doorlopende monitoring en onderhoud. AIBOM-onderhoud is event-driven. Wijzigingen aan een component in een van de zeven clusters activeren updates, waaronder opnieuw getrainde modellen, gepatchte afhankelijkheden, datasetversies en infrastructuurwijzigingen. Tools voor autonome detectie en machineleesbare indelingen houden het record accuraat door het bij te werken wanneer wijzigingen optreden.

Gedurende deze vier fasen blijft een AIBOM alleen betrouwbaar wanneer de indeling en updateregels vooraf zijn vastgelegd, en dat is precies wat de huidige standaarden specificeren.

AIBOM-standaarden en frameworks

Vier in elkaar grijpende standaarden vormen de huidige gezaghebbende basis voor AIBOM-implementatie. Elk behandelt een andere laag van de governance-stack.

1. NIST AI Risk Management Framework. Het NIST AI Risk Management Framework stelt traceerbaarheid en accountability vast als fundamentele eigenschappen voor betrouwbare AI. De eerste release, AI RMF 1.0, legde die baseline vast in januari 2023, en het Generative AI Profile breidde dit in juli 2024 uit naar generatieve systemen. Het NIST-rapport van april 2025 AI 100-5e2025 koppelt AI-supply chains expliciet aan SBOM-mechanismen, met verwijzingen naar model- en datakaarten naast software bills of materials als transparantie-instrumenten.
2. OWASP CycloneDX ML-BOM. De ML-BOM-capaciteit, geïntroduceerd in CycloneDX v1.5 en uitgebreid in latere versies, representeert datasets, modellen en configuraties voor AI/ML-systemen, inclusief documentatie van herkomst en ethische overwegingen voor datasets.
3. SPDX 3.0 AI- en datasetprofielen. SPDX, een ISO/IEC-standaard, voegde in versie 3.0 AI- en datasetprofielen toe. Deze profielen documenteren AI-modellen, trainingsdata, prompttemplates, AI-agents en licenties.
4. CISA en G7 minimale elementen. CISA publiceerde SBOM Minimum Elements voor AI-software in augustus 2025. In mei 2026 publiceerden cybersecurityagentschappen uit alle G7-lidstaten plus de EU gezamenlijke richtlijnen die zeven clusters van potentiële elementen voor AI SBOM's definiëren, uiteengezet in de gezamenlijke G7-richtlijnen.

De adoptie van AIBOM staat nog in de kinderschoenen en huidige implementaties zijn vaak onvolledig of onnauwkeurig. Maar de standaarden geven u een basis om op voort te bouwen.

Waarom een AIBOM belangrijk is voor beveiliging, compliance en auditability

Voor beveiliging registreert een AIBOM de herkomst van datasets en checksums van modelgewichten, zodat teams kunnen onderzoeken of modellen zijn getraind op gemanipuleerde data. Wanneer kwetsbaarheden of gecompromitteerde componenten AI-infrastructuur beïnvloeden, vertelt de AIBOM u welke systemen getroffen zijn.

Voor compliance omvat de EU AI Act transparantie- en documentatieverplichtingen voor bepaalde AI-systemen en modellen, waaronder technische documentatie en samenvattingen van trainingsinhoud. Een AIBOM ondersteunt die verplichtingen door een gestructureerd compositierecord te creëren.

Voor auditability geeft de AIBOM auditors en incident response teams een traceerbaar, geversioneerd antwoord wanneer zij vragen waaruit een specifiek AI-systeem is opgebouwd. Het record laat zien welke datasets het hebben getraind, welke modelgewichten zijn geïmplementeerd en welke frameworks en afhankelijkheden het ondersteunen. Zonder dit record is uw antwoord op elke auditvraag over AI-samenstelling op zijn best een reconstructie-inspanning.

Elk van die uitkomsten veronderstelt dat het record accuraat en actueel is. Het bereiken van die staat op enterpriseschaal stuit op structurele beperkingen die niet alleen met inspanning kunnen worden weggenomen.

Uitdagingen bij het implementeren van een AIBOM

Structurele beperkingen maken AIBOM-implementatie moeilijk, ongeacht de organisatorische volwassenheid of beschikbare middelen.

• Onvolwassen standaarden en tooling. CycloneDX ML-BOM, SPDX 3.0 AI-profielen en de G7-richtlijnen zijn allemaal recent verschenen, dus praktijken en tools zijn nog in ontwikkeling.
• Ondoorzichtige modellen van derden. Proprietary foundation models die via inference API's worden benaderd, geven weinig prijs over hun interne werking. U kunt naam, versie, endpoint, toegangscontroles en leveranciersverklaringen registreren, maar volledige samenstelling van gesloten modellen blijft buiten bereik.
• Herkomst van trainingsdata. Voor extern getrainde modellen wordt herkomst mogelijk nooit bekendgemaakt. Voor interne modellen moet u die tijdens de training vastleggen, omdat reconstructie achteraf onbetrouwbaar is.
• Snelle modelversionering. Elke retraining of parameterwijziging creëert een nieuwe effectieve versie met een eigen risicoprofiel, wat leidt tot versieverspreiding die geen enkel handmatig proces op schaal kan bijhouden.
• Heterogene omgevingen. Enterprise AI omvat cloudproviders, on-premises infrastructuur, SaaS-AI-tools, embedded AI in applicaties van derden, agentic systemen en vectordatabases.

Deze beperkingen zijn extern, dus het meeste wat u kunt doen is eromheen ontwerpen. De fouten in de volgende sectie zijn het tegenovergestelde, en het is aan u om ze te voorkomen.

Veelgemaakte fouten bij AIBOM-implementatie

Fout	Gevolg
De AIBOM behandelen als een eenmalig document dat voor een audit wordt opgesteld	Incident response neemt beslissingen op basis van een record dat de productie niet langer weerspiegelt
De inventaris handmatig onderhouden	De snelheid van wijzigingen in modellen, datasets en API's overtreft elk door mensen uitgevoerd proces, waardoor het record veroudert
Modelnamen en versies registreren zonder herkomst	Data- en modelvergiftiging blijft niet identificeerbaar, omdat identificatie afhangt van trainingslineage, checksums van gewichten en runmetadata die achteraf niet opnieuw kunnen worden opgebouwd
De AIBOM uitvoeren als een op zichzelf staand compliancebestand dat losstaat van engineeringtooling	Er ontstaan twee inventarissen die uit elkaar gaan lopen; CISA's SBOM-richtlijnen definiëren de bill of materials als een geneste inventaris voor supply chain-risico, en het uitvoeren van de AIBOM buiten de SBOM-toolchain verbreekt die koppeling
De inventaris beperken tot door IT goedgekeurde AI en shadow AI weglaten	Er blijft een systematische blinde vlek in het record bestaan

Elke bovenstaande fout is een proceskeuze, dus elke fout heeft een procesmatige oplossing. De onderstaande praktijken veranderen de inventaris van een statisch bestand in een operationele controle.

AIBOM best practices

De volgende acties brengen uw AIBOM-programma van statische documentatie naar een operationeel governance-instrument.

• Implementeer autonome detectie en generatie. Integreer dit in modelregisters, API-gateways en inventarissen van cloud-AI-services.
• Standaardiseer op een machineleesbare indeling. Lever CycloneDX ML-BOM of SPDX 3.0 AI-profielen op. Door mensen leesbare spreadsheets kunnen de workflows die de beveiligingswaarde van de inventaris operationaliseren niet voeden.
• Leg herkomst vast bij de bron. Registreer identifiers van trainings- en fine-tuningdatasets, checksums van modelgewichten, metadata van trainingsruns en version pins van inference API's. Voor interne modellen moet u tracking van herkomst in de ML-pipeline instrumenteren op het moment van training.
• Maak de AIBOM een gate in CI/CD. Genereer de AIBOM bij het aanmaken van trainingsartefacten, registry push-events en wijzigingen in implementatieconfiguraties, en behandel een ontbrekende of verouderde AIBOM als een pipelinefout die promotie naar de volgende omgeving stopt.
• Monitor continu op drift. Vergelijk hashes van geïmplementeerde modelartefacten met in de AIBOM vastgelegde hashes bij elke implementatiegebeurtenis. Een event-driven cadans is wat een governancerecord onderscheidt van een verouderd document.
• Vind shadow AI via actieve detectie. Identificeer verbindingen met bekende AI-inference-endpoints en voeg ontdekte assets toe aan de AIBOM met een expliciete classificatie van ongereguleerd risico.

Deze praktijken veranderen uw AIBOM van een auditartefact in een levend record. Uitvoering hiervan op cloudschaal vereist tooling, en daar komt SentinelOne's AI Security Posture Management in beeld.

Verbeter AIBOM-governance met SentinelOne

Een AIBOM is slechts zo goed als de detectie die het voedt. Singularity Cloud Security, SentinelOne's Cloud-Native Application Protection Platform, bouwt en onderhoudt een AIBOM in cloudomgevingen via de AI Security Posture Management (AI-SPM)-capaciteit, met geïntegreerde Data Security Posture Management (DSPM) voor de datalaag.

• Detectie die de inventaris vult. AI-SPM vindt de AI-pipelines, ML-modellen en afhankelijkheden die in uw omgeving draaien, inclusief jobs op services zoals Amazon SageMaker. Omdat het zowel goedgekeurde als shadow AI dekt, wordt elk component dat het opsomt een potentiële AIBOM-entry zonder stille blinde vlek.
• Risicocontext boven op het record. Configuratiecontroles en Verified Exploit Paths tonen welke gecatalogiseerde componenten verkeerd zijn geconfigureerd of exploiteerbaar zijn, en DSPM houdt data met hoog risico uit AI-pipelines via een safe-to-train-gate. Prompt Security inspecteert prompts en responses en beheert agentic AI, waardoor uw AIBOM-governance wordt uitgebreid naar de runtimelaag.
• Validatie over het hele platform. Het Singularity Platform verenigt endpoint-, cloud- en identity-telemetrie op één data lake, zodat u kunt bevestigen dat de geïmplementeerde omgeving nog steeds overeenkomt met uw AIBOM. Wanneer die afwijkt, Purple AI in actie, een natural language-analist die autonoom onderzoekt in diezelfde data. Volgens IDC zagen Purple AI-klanten 63% snellere dreigingsidentificatie en een vermindering van 55% in mean time to respond (MTTR). 

Boek een SentinelOne-demo om uw AI-supply chain-risico te beoordelen en een verdedigbaar AI-governanceprogramma op te bouwen in uw cloudomgevingen.

Belangrijkste conclusies

Een AIBOM inventariseert de datasets, modellen, frameworks en afhankelijkheden achter een AI-systeem en registreert waar elk component vandaan komt. Het breidt de gevestigde SBOM-praktijk uit naar AI-specifieke assets zoals trainingsdata, modelgewichten en modelherkomst. 

Standaarden van NIST, OWASP CycloneDX, SPDX en de G7 definiëren wat een AIBOM vastlegt. De inventaris is belangrijk voor beveiliging, compliance en auditability, maar vereist autonome detectie, machineleesbare indelingen, vastlegging van herkomst en CI/CD-integratie om accuraat te blijven terwijl modellen veranderen. Goed uitgevoerd houdt de AIBOM op papierwerk te zijn en wordt het een controle waarop u kunt handelen.

Veelgestelde vragen

Wat is een AI Bill of Materials?

Een AI-stuklijst, of AIBOM, is een machineleesbare inventaris van de componenten van een AI-systeem: de datasets, modellen, frameworks, softwareafhankelijkheden en metadata zoals herkomst en licenties. Het doel ervan is operationeel.

Wanneer wordt vastgesteld dat een model is gecompromitteerd of wordt aangetoond dat een dataset is vergiftigd, is de AIBOM wat u in staat stelt om, met bewijs, te beantwoorden welke van uw systemen die component bevatten en wanneer deze daarin is terechtgekomen. Zonder AIBOM wordt dat antwoord een reconstructie-inspanning onder tijdsdruk.

Kun je een AIBOM opstellen voor een gesloten model of een model van derden?

Gedeeltelijk. Voor een gesloten foundation model dat via een inference API wordt benaderd, kunt u de volledige interne samenstelling niet vastleggen, omdat de leverancier de trainingsgegevens of gewichten niet openbaar maakt. U kunt nog steeds vastleggen en verankeren wat kenbaar is: modelnaam, versie, API-eindpunt, toegangscontroles, en eventuele leveranciersverklaringen. 

Leg deze vast als een eersteklas AIBOM-item en markeer de niet-openbaar gemaakte velden expliciet, zodat de inventaris laat zien waar de transparantie eindigt en geen stilzwijgende leemtes achterlaat.

Wat moet een AIBOM bevatten?

De richtlijn van mei 2026 van de G7 organiseert AIBOM-inhoud in zeven clusters: metadata, software-eigenschappen op systeemniveau, modelidentiteit en herkomst van gewichten, dataseteigenschappen, key performance indicators, infrastructuurdocumentatie en documentstructuur met registraties van updatefrequentie. 

Samen documenteren deze clusters hoe een AI-systeem is gebouwd, waarop het draait en hoe de inventaris gedurende de levenscyclus verandert.

Welke standaarden zijn van toepassing op AIBOM's?

Vier standaarden en raamwerken vormen de basis van de huidige AIBOM-praktijk. Het NIST AI Risk Management Framework stelt verwachtingen vast voor governance en traceerbaarheid. OWASP CycloneDX ML-BOM en SPDX 3.0 AI profiles, een ISO/IEC-standaard, bieden machineleesbare formatspecificaties voor modellen en datasets. 

De minimale SBOM-elementen van CISA en de richtlijnen van de G7 met zeven clusters definiëren wat transparantie van AI-systemen moet omvatten. Samen breiden zij gevestigde SBOM-benaderingen uit naar AI-inventarismodellen.

Hoe houd je een AIBOM actueel wanneer modellen veranderen?

Behandel de AIBOM als een gebeurtenisgestuurd record dat is gekoppeld aan uw ML-pijplijn. Activeer updates bij het aanmaken van modeltrainingsartefacten, registry-pushgebeurtenissen, retraining, fine-tuning en wijzigingen in de implementatieconfiguratie. Vergelijk hashes van geïmplementeerde modellen met geregistreerde hashes en waarschuw bij nieuwe inference-endpoints of registry-vermeldingen zonder overeenkomstig AIBOM-record.

AI security posture management-tooling kan deze controles continu uitvoeren en drift signaleren zodra die optreedt. Wanneer generatie een verplichte CI/CD-stap is, stoppen verouderde inventarissen promotie voordat een model zonder governance productie bereikt.