En AI-materialförteckning är bara användbar om den kan besvara två frågor: vad deklarerades före driftsättning, och vad kördes faktiskt när ett beslut, en incident eller en granskning inträffade. En giltig JSON-fil som inte kan besvara båda frågorna är inventeringsteater.
Den praktiska utformningen är en parad inventering. Generera en standardbaserad post under byggtid eller upphandling, observera det aktiva systemet under körning, bevara bevis för varje fält och jämför de två. Blockera en release när en kritisk modell, ett dataset, en runtime, ett API, ett agentverktyg eller en licens är olöst.
Läsarnivå: Avancerad. Den här guiden är för ingenjörer, säkerhetsteam, plattformsägare och tekniska styrningsansvariga som driver modellbaserade system.
Innehåll
Vilka frågor en AI-materialförteckning bör besvara
En AI-materialförteckning, vanligtvis förkortad till AIBOM eller AI BOM, är en maskinläsbar inventering av komponenterna och bevisen bakom ett AI-system. Den utökar en konventionell SBOM bortom paket och bibliotek.
Inventeringen bör låta en granskare besvara:
CycloneDX beskriver sin AI/ML-BOM-funktion som ett sätt att representera modeller, dataset, konfigurationer, proveniens och beroenden. SPDX 3.0.1 definierar också en AI-profil för AI-specifika metadata. Det här är interoperabla datamodeller, inte ersättningar för själva de saknade bevisen.
Ett model card besvarar en snävare fråga: vad är den här modellen avsedd att göra, hur utvärderades den och var kan den misslyckas? Den ursprungliga artikeln om Model Cards föreslog dokumentation som täcker avsedd användning, utvärderingsvillkor och prestanda för relevanta grupper. Ett data card dokumenterar ett datasets ursprung, insamling och annotering, avsedda användning samt beslut som formar efterföljande prestanda; artikeln om Data Cards redovisar lärdomar från mer än 20 driftsättningar.
Behåll båda. Ett model card eller data card ger mänsklig kontext. En AIBOM kopplar dessa dokument till en versionshanterad systeminventering.
Varför giltiga AIBOM-filer fortfarande kan innehålla svaga bevis
En studie från juli 2026 testade denna skillnad i stor skala. Författarna samlade in en ögonblicksbild av 2 942 466 offentliga Hugging Face-modellposter, behöll 97 940 modeller med fler än 100 nedladdningar och genererade CycloneDX AIBOM:er med OWASP AIBOM Generator. De kontrollerade ett urval på 100 artefakter mot generatorns rapporter och mätte sedan fältnärvaro i hela mängden.
Det rapporterade genomsnittliga fullständighetspoänget var 54,31 av 100. Obligatoriska strukturfält fanns i 100 % av de genererade artefakterna. Dokumentation i model cards hade ett genomsnitt på 19,51 %.
Det gapet är det viktiga resultatet. Filen kan vara strukturellt giltig samtidigt som informationen som behövs för ett beslut saknas.
Resultaten på fältnivå var ännu tydligare:
| Fält i den genererade AIBOM:en | Närvarande |
|---|---|
| --- | ---: |
| Licens | 73,14 % |
| Dataset | 39,35 % |
| Hyperparametrar | 25,40 % |
| Tekniska begränsningar | 16,74 % |
| Bedömning av säkerhetsrisk | 9,76 % |
| Meningsfull beskrivning | 0,22 % |
| Energiförbrukning | 0,02 % |
Beskrivningsfältet fanns i nästan varje artefakt, men endast 211 av 97 940 beskrivningar innehöll information utöver platshållartext. En kontroll av om schemat innehåller fältet skulle räkna de övriga beskrivningarna som kompletta.
Vad författarna mätte: täckning av fält och kategorier i AIBOM:er som genererats från en filtrerad offentlig Hugging Face-ögonblicksbild.
Vad de härledde: dokumentation i model cards och externa referenser driver en stor del av skillnaden mellan svaga och starkare artefakter.
Vad de inte fastställde: om någon modell var säker, rättvis, presterande, juridiskt användbar eller lämplig för en viss driftsättning.
Författarna varnar också för att resultaten beror på Hugging Face API, generatorns extraktionslogik och en ögonblicksbild som utesluter modeller med 100 eller färre nedladdningar. Privata register, gated-modeller, andra värdplattformar och senare ändringar i repositorier kan se annorlunda ut. Resultatet stöder semantisk validering. Det fastställer inte ett universellt tröskelvärde.
Inventering vid byggtid och inventering under körning löser olika problem
En AIBOM vid byggtid registrerar avsikt. En runtime-inventering registrerar observation.
| Fråga | Bevis vid byggtid | Bevis under körning |
|---|---|---|
| --- | --- | --- |
| Vilken modell ska levereras? | Lockfil, manifest, upphandlingspost, modelldigest | Laddat modell-ID, endpoint, image digest, serveringskonfiguration |
| Vilka data ska vara tillgängliga? | Deklarationer för träning och utvärdering, godkända retrieval-källor | Anslutna vektorlagringar, monterade dataset, aktiva datatjänster |
| Vilka verktyg får en agent anropa? | Verktygsregister, policy, deklarerade MCP-servrar och API:er | Upptäckta endpoints, aktiva integrationer, observerad konfiguration |
| Vilken mjukvara stöder inferens? | Paket- och container-SBOM | Körande image, runtime, drivrutiner, acceleratorer |
| Vilka begränsningar gäller? | Licens, model card, data card, kontraktsreferens | Aktuell leverantör, region, route, policyversion |
| Har det godkända systemet drivit? | Baslinje för jämförelse | Bevis att jämföra med baslinjen |
Bevis från byggtid ensamt missar nödändringar, skuggdriftsättningar, föränderliga taggar, omdirigering hos leverantören och konfigurationsdrift. Runtime-observation kan ensamt se ett processnamn eller en endpoint utan att veta dess godkända syfte, licens, träningsproveniens eller utvärderingsgräns.
Google open-sourcade k8s-aibom den 14 juli 2026 för att utforska runtime-sidan. Controllern bevakar Kubernetes-workload- och podstatus, tillämpar detekteringsregler och genererar CycloneDX 1.6 ML-BOM-dokument. Den dokumenterade täckningen omfattar inferens-runtimes, agentramverk, vektordatabaser, träningsjobb och utvärderingsharnesser. Den körs utan en privilegierad DaemonSet eller kernelåtkomst.
Projektet visar en användbar arkitektonisk poäng: AIBOM:er vid byggtid och under körning kompletterar varandra. Det är också tidig mjukvara. Repositoriet märker v1.0 som alpha och lämplig för observationsanvändningsfall som inte är kritiska. Det levererar ingen hostad image eller Helm-repository, och dess nuvarande `NoopVerifier` kan inte markera en identitet som kryptografiskt verifierad.
En underhållare av NVIDIA AICR föreslog en integration mellan k8s-aibom och AICR som skulle koppla k8s-aiboms runtime-observationer till AICR:s driftsättningsavsikt och signerade attesteringar. Författaren beskriver målet som bevis för att det ett team driftsatte är det systemet kör. Ärendet har ingen länkad implementation, ansvarig eller milstolpe. Behandla det som ett förslag från praktiker, inte som en officiell roadmap eller färdig design.
Gör inte en ny controller till en universell produktrekommendation. Använd mönstret: para ihop deklarerat tillstånd med observerat tillstånd, bevara bevis och gör osäkerhet synlig.
_En användbar AI-materialförteckning kopplar byggavsikt till runtime-bevis, semantiska kontroller och ett versionshanterat beslut._
De sju lager som är värda att registrera
Det exakta schemat beror på din standard och driftsättning. Följande lager utgör ett praktiskt minimum för en produktionsinventering.
1. Modellidentitet
Registrera leverantör, modellfamilj, oföränderlig revision eller digest, format, basmodell, adaptrar, kvantisering, tokenizer och serveringsroute. Ett lättbegripligt alias som `support-model` är användbart för människor men otillräckligt för spårbarhet.
För ett externt API ska du registrera leverantörens stabila modellidentifierare och gateway-routen som valde den. Om leverantören i tysthet kan uppdatera modellen bakom ett alias ska revisionen märkas som olöst i stället för att du hittar på precision.
2. Data- och retrieval-beroenden
Registrera deklarerade tränings-, finjusterings-, utvärderings- och kalibreringsdataset när den informationen finns. För ett RAG-system ska du lägga till källsamlingar, embedding-modell, chunking-version, vektorlagringstjänst, åtkomstpolicy och färskhetsgräns.
Lagra datasetidentifierare, versioner, hashvärden, kontrakt eller kontrollerade katalogreferenser. Kopiera inte råa kundposter eller privata träningsexempel till AIBOM:en.
När ett team bygger anpassade datasystem med Next.js och AI-agenter→ hör schemaversionen, migrationsgränsen och anslutna tjänster till systemkontexten även när de inte är modellartefakter.
3. Runtime och mjukvara
Koppla AI-inventeringen till den vanliga SBOM:en. Registrera container-digest, inferensmotor, ramverk, relevanta bibliotek, drivrutins- och accelerator-klass samt konfiguration som kan ändra modellens beteende.
Detta spelar roll eftersom samma vikter kan bete sig annorlunda efter en ändring av tokenizer, attention-backend, kvantiseringsväg eller serveringsmotor. Analysen av varför fler AI-tokens ändrar compute-kostnaden→ visar varför en driftsättningspost behöver runtime-budget och konfiguration, inte bara ett modellnamn.
4. Verktyg, API:er och agentbehörigheter
Lista verktyg som en agent kan nå, inte alla verktyg som är installerade någonstans i företaget. Inkludera model gateways, MCP-servrar, webbläsar- eller kodexekveringsverktyg, externa API:er och policyreferensen som styr varje åtgärd.
Inventering verkställer inte auktorisering. Kombinera den med deterministiska kontroller. Artikeln om AI-agentbehörigheter→ förklarar varför en modells självbehärskning inte är en åtkomstkontrollgräns.
5. Utvärdering och driftbegränsningar
Referera till det exakta utvärderingsdatasetet, evaluatorversionen, tröskelvärdena, datumet och villkoren som användes för godkännande. Registrera kända fellägen, avsedda och uteslutna användningar, fallback-beteende, övervakningsansvarig och utgångsdatum för beslutet.
Skriv inte “klarade utvärderingen” utan testidentiteten. En ändrad modell med en oförändrad resultatsträng är svaga bevis.
6. Rättigheter, policy och proveniens
Registrera modell- och datasetlicenser, användningsbegränsningar, villkor för vidare distribution, källrepositorier, model cards, data cards, artiklar, godkännanden och attesteringar. Lagra referenser och hashvärden när källan är åtkomstskyddad.
Detta lager stöder granskning. Det avgör inte en juridisk fråga. Saknad eller motstridig information om rättigheter ska skickas till den person som ansvarar för beslutet.
7. Ägarskap och livscykel
Varje post behöver en ägare, ett systemsyfte, en miljö, skapandetid, observationstid, ersatt version och bevaranderegel. Utan ägarskap blir en inventering ett arkiv över övergivna fakta.
Inkludera ett stabilt system-ID som överlever nya driftsättningar. En versionshanterad AIBOM bör visa historiken över vad som ändrades, vem som accepterade det och vilka bevis som stödde beslutet.
Märk varje fakta som deklarerad, härledd, verifierad eller olöst
En AIBOM bör bära evidensstatus på fältnivå. En enda etikett för hela dokumentet döljer för mycket.
De tre första etiketterna beskriver olika styrkor hos bevisen. “Deklarerad” är inte en svagare stavning av “verifierad”. En leverantörsdeklaration kan vara den enda tillgängliga källan för träningsdata, medan en image digest kan verifieras mekaniskt.
Projektet k8s-aibom implementerar för närvarande `declared`, `inferred` och `unresolved`, med evidenslokatorer för attribut. README-filen placerar kryptografisk status som `verified` på roadmapen i stället för att hävda att den finns nu. Bevara samma ärlighet i ditt eget system.
En konceptuell post kan se ut så här:
{ "system_id": "customer-support-prod", "component": { "type": "machine-learning-model", "name": "provider/model-family", "version": "immutable-revision", "hashes": ["sha256:..."] }, "evidence": { "status": "verified", "source": "signed-build-attestation", "observed_at": "2026-07-29T08:00:00Z" }, "depends_on": [ "runtime:inference-engine@version", "dataset:retrieval-corpus@revision", "api:model-gateway@policy-version" ] }
Detta är en designskiss, inte ett dokument som följer CycloneDX eller SPDX. Använd den valda standardens schema och validator för den riktiga artefakten.
Ett reproducerbart AIBOM-arbetsflöde
Steg 1: definiera systemgränsen
Namnge applikationen, miljöerna, ägarna och de användarvända beslut som ingår. Bestäm om inventeringen täcker en modell-endpoint, ett agentarbetsflöde eller en komplett produkt.
En gräns som “all AI” kan inte testas. “Produktionssupportagenten och varje tjänst som kan ändra dess svar eller åtgärder” kan.
Steg 2: samla in bygg- och upphandlingsbevis
Generera den vanliga SBOM:en, lös modell- och datasetidentifierare, fånga oföränderliga digest-värden och länka model cards, data cards, licenser, utvärderingar och godkännanden.
OWASP AIBOM Generator kan extrahera Hugging Face-metadata till CycloneDX 1.6 och rapportera saknade fält. Behandla dess resultat som en startinventering. Studien i stor skala visar varför ett automatiskt ifyllt fält fortfarande behöver en innehållskontroll.
Steg 3: generera ett standarddokument
Välj ett format som dina konsumenter kan tolka. CycloneDX tillhandahåller en AI/ML-BOM-funktion och en implementeringsguide. SPDX 3 tillhandahåller profiler för AI och dataset.
Formatvalet bör följa de mottagande systemen, policy-motorn, attestationspipen och kundkraven. Undvik att underhålla två format om inte en verklig konsument behöver båda.
Steg 4: berika det som automation inte kan veta
Tilldela ägare som fyller i avsedd användning, begränsningar, datasetproveniens, utvärderingsvillkor, rättigheter och riskbeslut. Avvisa platshållare som “N/A”, “standardmodell” eller kopierad marknadsföringstext när fältet är beslutskritiskt.
Kräv en uttrycklig anledning till okända värden. “Leverantören offentliggör inte träningsdata” är bättre bevis än en tom array eftersom det skiljer mellan uteblivet arbete och otillgänglig information.
Steg 5: observera den aktiva driftsättningen
Samla in runtime-modell-ID:n, image digests, endpoints, anslutna lagringar, agentverktyg och konfiguration genom den minst privilegierade mekanism som är tillgänglig. I Kubernetes kan det vara en controller som bevakar API:et. I en hanterad API-stack kan det vara gateway-konfiguration, driftsättningsmanifest, leverantörssvar och granskningsloggar.
Hävda inte runtime-verifiering när scannern bara matchade en sträng. Märk den som härledd och bevara matchningsbeviset.
Steg 6: validera syntax, semantik och drift
Kör tre separata kontroller:
Den första kontrollen är automatiserad. Den andra behöver domänregler och, för vissa fält, mänsklig granskning. Den tredje behöver versionshanterade poster och en stabil jämförelsegräns.
Steg 7: signera, lagra, jämför och låt upphöra
Hasha artefakten, bind den till builden eller driftsättningen, lagra den i ett append-only- eller kontrollerat bevissystem och skapa en läsbar diff. AIBoMGen är en forskningsprototyp som kombinerar fångst av modell och miljö med hashvärden, signaturer och in-toto-attesteringar under träning.
Signaturer skyddar integriteten efter skapandet. De gör inte en ofullständig eller falsk deklaration sann.
Sätt ett utgångs- eller granskningsdatum. En perfekt inventering från förra kvartalet beskriver inte ett föränderligt produktionssystem i dag.
Gör inventeringen till en releasegrind
En inventering blir användbar när den ändrar ett beslut. Definiera policyn före releasefönstret.
| Villkor | Standardåtgärd | Orsak |
|---|---|---|
| --- | --- | --- |
| Identiteten för en kritisk modell eller runtime är olöst | Blockera | Den driftsatta komponenten kan inte spåras |
| Runtime innehåller en odeklarerad modell, ett API, ett verktyg eller en datalagring | Blockera och utred | Den godkända gränsen har drivit |
| Modellrevisionen ändrades men utvärderingsreferensen gjorde det inte | Blockera | Godkännandebevisen täcker inte kandidaten |
| Obligatorisk licens eller användningsbegränsning saknas | Skicka till ansvarig granskning; blockera där policyn kräver det | Rättigheter kan inte härledas från tillgänglighet |
| Heuristisk härledning strider mot en deklaration | Blockera eller isolera beviset | Minst en källa är felaktig eller inaktuell |
| En icke-kritisk beskrivning saknar detaljer | Skapa en tidsbegränsad åtgärdspunkt | Bristen kanske inte motiverar att tjänsten stoppas |
| AIBOM ändrades endast eftersom observationstiden ändrades | Tillåt | Ingen materiell systemdrift inträffade |
Anpassa allvaret efter systemet. En skrivassistent och ett medicinskt beslutsverktyg bör inte dela samma universella tröskelvärde.
Följ fyra operativa mått:
Optimera inte för antalet ifyllda fält. Det återskapar exakt det misslyckande som fullständighetsstudien visade.
Samma systemprincip syns i analysen av kodagenters aktivitet och infrastruktur→: modellkapacitet är bara en del av det driftsatta systemet. Runtime, verktyg, routing och operativa kontroller avgör vad användarna faktiskt får.
Håll hemligheter och personuppgifter utanför
En AIBOM kommer sannolikt att cirkulera bland teknik, säkerhet, revisorer, kunder och automatiserade system. Behandla den som en inventering, inte som ett hemlighetslager.
Inkludera inte:
Referera till hemligheter med en sökväg i secret manager eller en logisk identifierare utan att inkludera värdet. Referera till känsliga dataset genom ett styrt katalog-ID, version, klassificering, ägare och integritetshash. Tillämpa åtkomstkontroll på hela artefakten när även dess metadata är känsliga.
Vad en AIBOM inte kan bevisa
En AI-materialförteckning förbättrar spårbarheten. Den bevisar inte:
Fullständighetsstudien från juli mäter dokumentationstäckning, inte modellkvalitet. Repositoriet k8s-aibom säger uttryckligen att dess output inte certifierar efterlevnad. Båda begränsningarna spelar roll.
Använd AIBOM:en som en karta från ett beslut till inspekterbara bevis. Kombinera den med utvärdering, auktorisering, övervakning, incidenthantering, integritetskontroller och ansvarig granskning. Kartan gör dessa processer snabbare eftersom den visar varje granskare vilket system de bedömer.
Vanliga frågor
Vad är en AI-materialförteckning?
En AI-materialförteckning är en maskinläsbar inventering av modeller, dataset, mjukvara, runtimes, verktyg, proveniens, begränsningar och bevis bakom ett AI-system. En användbar AIBOM identifierar oföränderliga versioner, ägare, olösta fakta och ändringar mellan godkänt och aktivt tillstånd.
Är en AI BOM samma sak som en SBOM?
Nej. En SBOM inventerar mjukvarukomponenter och beroenden. En AI BOM kopplar den mjukvaruinventeringen till AI-specifika komponenter som modeller, dataset, adaptrar, utvärderingar, avsedda användningar, begränsningar och runtime-routes. Ett AI-system i produktion behöver vanligtvis båda.
Bör jag använda CycloneDX eller SPDX för en AIBOM?
Använd det format som dina nedströmsverktyg och beviskonsumenter stöder. CycloneDX har en dokumenterad AI/ML-BOM-funktion; SPDX 3 har AI- och datasetprofiler. Validera först ett kanoniskt format. Lägg bara till ett andra när en policy, kund eller integration kräver det.