An AI-beholdning er en kontinuerlig oppdatert katalog over alle AI-ressurser som kjører i hele organisasjonen din — modeller, AI-drevne endepunkter, datasett, AI-kodingsassistenter, MCP-servere og AI-avhengigheter — sammen med relasjonene, risikoene og eierne som knytter dem sammen. I en sikkerhetskontekst har dette ingenting å gjøre med lager- eller lagerstyring; her, "AI-beholdning" betyr ganske enkelt å vite nøyaktig hvilken AI du kjører, hvor den befinner seg og hva den kan nå.
Etter hvert som AI sprer seg over alle stadier av programvareutvikling, fra kodegenerering i IDE-en til autonome agenter som opptrer inni CI/CD pipelines, spørsmålet er ikke lenger om AI er tilstede i miljøet ditt. Det handler om du kan se det. Denne veiledningen forklarer hva et AI-lager er, hvordan det forholder seg til en AI-BOM og en SBOM, Hvorfor skygge AI har blitt et sikkerhetsproblem, og hvordan praksisen tilpasses EUs AI-lov, NIST AI RMF og ISO / IEC 42001.
Nøkkelferier
- En AI-inventarliste katalogiserer alle modeller, datasett, agenter, MCP-servere og AI-kodingsverktøy i hele programvarens livssyklus, ikke bare de som er godkjent av IT.
- Shadow AI, AI tatt i bruk uten styring, er nå normen, ikke unntaket: i en undersøkelse av sikkerhetsledere fra 2026, bare 19 % av organisasjonene rapporterte full innsikt i hvor og hvordan AI brukes.
- An AI-BOM (AI-stykkliste) er det revisjonsklare resultatet av en AI-inventar: etterfølgeren til AI-æraen SBOM.
- Regulering er på vei. EUs KI-lov, NIST AI RMF og ISO/IEC 42001 krever i praksis at du vet hvilken KI du bruker.
- En inventarliste er bare utgangspunktet; verdien kommer fra å vurdere risiko og handle ut fra det lille antallet eiendeler som virkelig betyr noe.
Hva er en AI-inventarliste?
En AI-inventarliste er praksisen med å oppdage, katalogisere og kontinuerlig overvåke alle AI-ressurser som opererer gjennom programvareutviklingssyklusen din, og risikoene knyttet til hver enkelt. En komplett inventarliste svarer på tre spørsmål for hver ressurs: hva er det, hvor kjører det, og hva har det tilgang til?
Dette omfanget er bredere enn de fleste team forventer. En meningsfull AI-oversikt bør dekke:
- Modelleralle store språkmodeller og grunnleggende modeller som er i bruk på tvers av utvikling og produksjon, med versjons-, plasserings- og deteksjonssikkerhet.
- datasetttreningsdata, hentingsdatasett og vektorlagre, inkludert eksponering for forgiftet kontekst og datalekkasje.
- Agenterautonome systemer som utfører handlinger i miljøet ditt, for eksempel å åpne pull requests, installere avhengigheter eller berøre infrastruktur.
- MCP-servere: Model Context Protocol servere som kobler AI-assistenter til eksterne verktøy, API-er og datakilder.
- AI-kodingsverktøy og -assistenter: copiloter og IDE-integrasjoner som genererer kode, foreslå avhengigheter og samhandle med repositorier.
- AI-rammeverkLangChain, LangGraph, agentservere og andre orkestreringslag som kobler modeller til verktøy og data.
- Forholdet mellom eiendeler: forbindelsene mellom modeller, agenter, servere, datasett og hemmelighetene knyttet til dem. En relasjonsgraf gjør risiko synlig i kontekst, ikke som en flat liste.
AI-inventar vs. AI-eiendelinventar vs. AI-BOM, og hvordan de skiller seg fra en SBOM
Disse begrepene brukes løst, så det hjelper å være på forhåndcise. «AI-beholdning» og «AI-eiendellebeholdning» beskriver det samme: den levende katalogen over AI-ressurser og deres risikoer. En AI-BOM er den eksporterbare artefakten som lagerbeholdningen produsereren maskinlesbar materialliste du kan gi til en revisor eller en enterprise kjøper.
Den reneste måten å forstå AI-BOM på er ved analogi med SBOM:
Etter hvert som AI blir integrert i hele SDLC, AI-BOM blir like grunnleggende som SBOM, og sikkerhetsledere mottar i økende grad forespørsler fra revisorer og enterprise anskaffelsesteam for akkurat denne gjenstanden.
Hvorfor AI-lagerbeholdning er viktig nå
Tre krefter har gjort AI-inventar fra noe som var kjekt å ha til en prioritet.
- For det første skriver AI usikker kode i stor skala. Uavhengig forskning viser konsekvent at en stor andel av AI-generert kode kommer med sårbarheter. Den opprinnelige NYU/Copilot-studien av Pearce et al. fant omtrent 40 % av genererte programmer inneholdt sikkerhetssvakheter, og nyere storskalatester peker på samme måte: Veracodes analyse fra 2025 på tvers av over 100 modeller fant bare 55 % av AI-generert kode var sikkerHvis du ikke vet hvilke assistenter som genererer kode i din pipelines, du kan ikke kontrollere den risikoen.
- For det andre har programvareforsyningskjeden blitt en angrepsflate for AI. I september 2025, Shai Hulud, den første selvforplantende npm-ormen, gjorde utviklermaskiner om til en distribusjonsmekanisme, og spredte seg over hundrevis av pakker. I mars 2026 kompromitterte angripere Axios, en pakke med omtrent 100 millioner ukentlige nedlastinger, og publiserte forgiftede versjoner som sluppet en trojaner for ekstern tilgang. Angrep som disse havner i akkurat laget mellom tradisjonell AppSec og endepunktverktøy: laget et AI-inventar er bygget for å belyse.
- For det tredje lekker hemmeligheter og legitimasjonsinformasjon gjennom AI. GitGuardians State of Secrets Sprawl 2026 rapporterte at Lekkasjer av hemmeligheter fra AI-tjenester økte med 81 % fra år til år, og at AI-assistert commits leak secrets med omtrent dobbelt så høy rate som grunnlinjen. Enhver udokumentert modell, agent eller MCP-server er en potensiell vei til en legitimasjon.
Tradisjonell AppSec stopper ved depotet og forstår ikke hva en modell er. Endepunktverktøy overvåker operativsystemet, men forstår ikke pakker, MCP-servere eller AI-assistenter. Gapet mellom dem er der AI-risiko akkumuleres, og en inventarliste er det første skrittet for å lukke den.
Der AI gjemmer seg: Skygge-AI over hele SDLC
Shadow AI er et AI-system tatt i bruk uten formell godkjenning eller styring: kopiloten en utvikler aktiverte forrige uke, MCP-serveren som kjører på en bærbar PC, modellen trukket rett fra et offentlig knutepunkt til et sideprosjekt. Det er ikke et edge-case. I en undersøkelse fra 2026 av over 400 sikkerhetsledere, bare 19 % rapporterte full innsikt i hvor og hvordan AI brukes på tvers av organisasjonen, mens det overveldende flertallet allerede brukte eller testet AI-kodingsassistenter.
Den vanskeligste skygge-AI-en å finne er AI-en i programvarens livssyklus, fordi den sjelden dukker opp i en skykonsoll:
- Modeller og AI-biblioteker hentet inn i databaser som avhengigheter.
- AI-kodingsassistenter konfigurert per utvikler, per IDE.
- MCP-servere og regelfiler som kjører lokalt på utviklerendepunkter.
- Agentarbeidsflyter åpnes stille pull requests eller installere pakker.
Derfor er det ikke nok å bare oppdage skybasert informasjon. En fullstendig AI-inventarliste må nå inn i kode- og byggemiljøer (utviklerens bærbare datamaskin, depotet, pipeline), ikke bare produksjonsskyen.
Hva hører hjemme i en AI-BOM
En revisjonsklar AI-BOM gjør varelageret ditt om til noe du kan bevise. Som et minimum bør den inneholde:
- Alle AI-ressurser: modeller, datasett, agenter, MCP-servere, AI-kodingsverktøy.
- Aktivatype, plassering og deteksjonssikkerhet for hver.
- Proveniens og avhengigheter (hvor modellen eller komponenten kom fra).
- Et risikonivå per aktivum, basert på AI-spesifikke angrepsvektorer.
- Reguleringsmessig kartlegging til EUs KI-lov, NIST AI RMF og ISO/IEC 42001.
- Et eksporterbart, maskinlesbart format for revisorer og kunder.
Organisasjonene som kan generere en AI-BOM på forespørsel, vil ha en reell fordel innen samsvar og tillit etter hvert som forpliktelsene til AI-revisjon modnes.
AI-inventar og samsvar: EUs AI-lov, NIST AI RMF og ISO/IEC 42001
Ingen av de store rammeverkene nevner «AI-beholdning» som en varelinje, men hver enkelt er i praksis umulig å oppfylle uten den. Du kan ikke dokumentere, klassifisere eller styre AI-systemer du ikke kan se.
En merknad om tidspunktet: Utrullingen av EUs KI-lov ble revidert av «Digital Omnibus»-avtalen fra mai 2026, som utsatte de fleste høyrisikoforpliktelsene til desember 2027, samtidig som flere milepæler fra 2. august 2026 ble holdt aktive (transparenthetsplikter, GPAI-straffefullmakter). Behandle nøyaktige datoer som et bevegelig mål og bekreft mot primære EU-kilder. Men reiseretningen er klar, og inventar er forutsetningen for alt.
Hvordan bygge og vedlikeholde et AI-lager
Å bygge et inventar handler mindre om en engangsrevisjon og mer om å etablere en kontinuerlig prosess, fordi AI-ressurser endres stadig: nye modeller tas i bruk, nye agenter distribueres, nye MCP-servere konfigureres, ofte uten godkjenning.
En praktisk tilnærming:
- Oppdag automatisk på tvers av kode, bygg og sky. Manuelle regneark blir foreldet i løpet av få dager. Oppdagelsen må kjøres kontinuerlig og nå inn i SDLC, ikke bare kjøretid.
- Klassifiser og kartlegg relasjoner. Posttype, plassering, opprinnelse og, viktigst av alt, hvordan hvert aktivum er koblet til andre og til hemmeligheter.
- Poengrisiko i kontekst. En flat liste med hundrevis av funn hjelper ingen; prioriter etter hva som faktisk er tilgjengelig, utnyttbart og forretningskritisk.
- Tildel eierskap. Alle eiendeler trenger en ansvarlig eier.
- Hold den aktiv og eksporterbar. Oppretthold det som et kontinuerlig lager som kan produsere en AI-BOM på forespørsel.
Hva du skal se etter i AI-lagerprogramvare
Hvis du evaluerer verktøy, er dette funksjonene som skiller ekte AI-lagerprogramvare fra en statisk liste:
- Forstår AI-spesifikke aktivatyper (modeller, agenter, MCP-servere, datasett), ikke bare pakker og biblioteker.
- Når inn i SDLC, oppdage AI i kode og på utviklernes endepunkter, ikke bare i skyen.
- Kartrelasjoner, ikke bare individuelle eiendeler, så risiko er synlig i kontekst.
- Risikovurdering på AI-spesifikke angrepsvektorer (rask injeksjon, usikker MCP, overdreven handlefrihet), ikke bare alvorlighetsgraden av CVE.
- Kjører kontinuerlig, fanger opp ny AI slik det ser ut.
- Produserer en revisjonsklar AI-BOM som tilfredsstiller både revisorer og enterprise anskaffelse.
- Kobler inventar til håndheving, slik at du kan handle ut fra det du finner.
Fra inventar til handling: Sikre det du finner
Oppdagelse er det første trinnet; det andre er å forstå hvilke eiendeler som bærer reell risiko, fordi de fleste ikke vil det. Målet er å gå fra tusenvis av råfunn til den håndfullen som faktisk kan kompromittere systemer, data eller drift: de som er i aktiv bruk, aksepterer upålitelig inndata, er realistisk utnyttbare, har sensitiv tilgang og påvirker produksjon eller regulerte eiendeler.
Det er her AI Security Posture Management (AI-SPM) plukker opp: tar inventaret, scorer risiko langs AI-angrepsbanen, kartlegger det til forskrift og produserer AI-BOM. Det er også der inventar møter håndheving: blokkerer ondsinnede avhengigheter før de installeres, avviser ikke-godkjente MCP-servere og -modeller, og begrenser kompromitterte endepunkter før en hendelse sprer seg.
At Xygeni, dette er modellen vi bygger mot: kontinuerlig AI-inventar og AI-BOM gjennom AI-SPM, skadelig programvaredeteksjon som fanger opp ondsinnede pakker før en signatur finnes (MEW, tidlig varsling om skadelig programvare), og håndheving av retningslinjer ved utviklerens endepunkt gjennom Xygeni Shield. Deteksjon er i tråd med OWASP Topp 10 for LLM-applikasjoner, OWASP Topp 10 for Agentic-apper og OWASP MCP Topp 10. Men uansett hvilken tilnærming du velger, gjelder prinsippet: Du kan ikke sikre det du ikke kan se, og et AI-lager er der synligheten begynner.
Spørsmål og svar
Hvordan er en AI-BOM forskjellig fra en SBOM?
An SBOM katalogiserer avhengigheter av åpen kildekode og tredjepartsprogramvare, scoret etter CVE-alvorlighetsgrad. En AI-BOM katalogiserer AI-spesifikke eiendeler (modeller, agenter, MCP-servere, datasett) med AI-spesifikk risikovurdering og regulatorisk kartlegging. Etter hvert som AI sprer seg over hele SDLC, AI-BOM blir like grunnleggende som SBOM.
Hva er skygge-AI, og hvordan oppdager jeg det?
Skygge-AI er enhver AI som tas i bruk uten formell godkjenning eller styring: en aktivert copilot, en lokal MCP-server, en modell hentet fra et offentlig knutepunkt. Du oppdager den med kontinuerlig automatisert inventar som går inn i kode, bygging pipelineog utviklerendepunkter, ikke bare produksjonsskyen der mesteparten av skygge-AI aldri dukker opp.
Krever EUs KI-lov en KI-liste?
EUs KI-lov nevner ikke «KI-inventar» eksplisitt, men det er umulig å oppfylle dokumentasjons-, klassifiserings- og registreringspliktene for høyrisikosystemer uten en slik lov. Det samme gjelder NIST AI RMF (Map function, Govern 1.6) og ISO/IEC 42001, som krever at man fører et inventar over KI-systemer.
Hva er AI-SPM?
AI Security Posture Management (AI-SPM) er praksisen med kontinuerlig å oppdage AI-ressurser, vurdere risikoen deres langs AI-angrepsbanen, kartlegge dem til regulering og produsere en AI-BOM. Den utvider posture management-tenkning (kjent fra CSPM og DSPM) til AI-spesifikke ressurser og angrepsvektorer.
Hvor ofte bør en AI-inventarliste oppdateres?
Kontinuerlig. AI-ressurser endres daglig etter hvert som team tar i bruk nye modeller, distribuerer nye agenter og konfigurerer nye MCP-servere, vanligvis uten formell godkjenning. En skanning på et gitt tidspunkt er foreldet i løpet av få dager, så effektiv AI-lagerprogramvare kjører som en kontinuerlig prosess snarere enn en engangsrevisjon.
Hvordan lager jeg en oversikt over AI brukt i kildekode?
Å inventarisere AI i kode betyr å oppdage AI-modeller og biblioteker som hentes inn som avhengigheter, AI-kodingsassistenter konfigurert per utvikler, og MCP-servere eller regelfiler som kjører lokalt. Dette krever oppdagelse som opererer inne i SDLC (arkiv, bygge pipelines og utviklerendepunkter) i stedet for bare i skykonsoller.
