An AI-inventar er et løbende opdateret katalog over alle AI-aktiver, der kører på tværs af din organisation — modeller, AI-drevne slutpunkter, datasæt, AI-kodningsassistenter, MCP-servere og AI-afhængigheder — sammen med de relationer, risici og ejere, der forbinder dem. I en sikkerhedsmæssig sammenhæng har dette intet at gøre med lager- eller lagerstyring; her, "AI-lager" betyder ganske enkelt at vide præcis, hvilken AI du kører, hvor den befinder sig, og hvad den kan nå.
Efterhånden som AI spreder sig på tværs af alle faser af softwareudvikling, fra kodegenerering i IDE'en til autonome agenter, der agerer indeni CI/CD pipelines, spørgsmålet er ikke længere, om AI er til stede i dit miljø. Det handler om, hvorvidt du kan se det. Denne guide forklarer, hvad en AI-opgørelse er, og hvordan den relaterer sig til en AI-BOM og en SBOM, hvorfor skygge AI er blevet et sikkerhedsproblem, og hvordan praksissen tilpasser sig EU's AI-lov, NIST AI RMF og ISO / IEC 42001.
Vigtige takeaways
- En AI-opgørelse katalogiserer alle modeller, datasæt, agenter, MCP-servere og AI-kodningsværktøjer på tværs af din softwarelivscyklus, ikke kun dem, der er IT-godkendte.
- Shadow AI, AI indført uden styring, er nu normen, ikke undtagelsen: i en undersøgelse fra 2026 af sikkerhedsledere, kun 19 % af organisationerne rapporterede fuldt indblik i, hvor og hvordan AI bruges.
- An AI-BOM (AI-materialeliste) er det revisionsklare output af en AI-opgørelse: efterfølgeren fra AI-æraen til SBOM.
- Regulering er på vej. EU's AI-lovgivning, NIST AI RMF og ISO/IEC 42001 kræver alle i praksis, at du ved, hvilken AI du bruger.
- En opgørelse er kun udgangspunktet; værdien kommer fra risikovurdering og handling på det lille antal aktiver, der virkelig betyder noget.
Hvad er en AI-opgørelse?
En AI-opgørelse er praksissen med at opdage, katalogisere og løbende overvåge alle AI-aktiver, der opererer i hele din softwareudviklingslivscyklus, og de risici, der er forbundet med hver enkelt. En komplet opgørelse besvarer tre spørgsmål for hvert aktiv: hvad er det, hvor kører det, og hvad kan det få adgang til?
Det omfang er bredere, end de fleste teams forventer. En meningsfuld AI-opgørelse bør dække:
- Modelleralle store sprogmodeller og fundamentsmodeller, der bruges på tværs af udvikling og produktion, med versions-, placerings- og detektionssikkerhed.
- datasætTræningsdata, hentningsdatasæt og vektorlagre, herunder eksponering for forgiftet kontekst og datalækage.
- Agenter: autonome systemer, der udfører handlinger i dit miljø, såsom at åbne pull requests, installation af afhængigheder eller berøring af infrastruktur.
- MCP-servere: Modelkontekstprotokol servere, der forbinder AI-assistenter til eksterne værktøjer, API'er og datakilder.
- AI-kodningsværktøjer og -assistenter: copiloter og IDE-integrationer, der genererer kode, foreslå afhængigheder og interagere med arkiver.
- AI rammerLangChain, LangGraph, agentservere og andre orkestreringslag, der forbinder modeller til værktøjer og data.
- Forholdet mellem aktiver: forbindelserne mellem modeller, agenter, servere, datasæt og de hemmeligheder, der er knyttet til dem. En relationsgraf gør risiko synlig i kontekst, ikke som en flad liste.
AI-lager vs. AI-aktiverlager vs. AI-BOM, og hvordan de adskiller sig fra en SBOM
Disse udtryk bruges løst, så det er nyttigt at være forberedtcise. "AI-beholdning" og "AI-aktiverbeholdning" beskriver det samme: det levende katalog over AI-aktiver og deres risici. En AI-BOM er den eksporterbare artefakt, som lagerbeholdningen producereren maskinlæsbar stykliste, du kan give til en revisor eller en enterprise køber.
Den reneste måde at forstå AI-BOM på er ved analogi med SBOM:
Efterhånden som AI bliver integreret på tværs af SDLC, AI-BOM bliver lige så grundlæggende som SBOM, og sikkerhedsledere modtager i stigende grad anmodninger fra revisorer og enterprise indkøbsteams til præcis denne artefakt.
Hvorfor AI-lagerbeholdning er vigtig nu
Tre kræfter har forvandlet AI-lagerbeholdning fra at være en rar ting til en prioritet.
- For det første skriver AI usikker kode i stor skala. Uafhængig forskning viser konsekvent, at en stor andel af AI-genereret kode indeholder sårbarheder. Det oprindelige NYU/Copilot-studie af Pearce et al. fandt omtrent 40% af de genererede programmer indeholdt sikkerhedssvagheder, og nyere storstilede tests peger på samme måde: Veracodes 2025-analyse på tværs af 100+ modeller fandt kun 55% af AI-genereret kode var sikkerHvis du ikke ved, hvilke assistenter der genererer kode i din pipelines, du kan ikke styre den risiko.
- For det andet er softwareforsyningskæden blevet en AI-angrebsflade. I september 2025, Shai Hulud, den første selvudbredende npm-orm, forvandlede udviklermaskiner til en distributionsmekanisme, der spredte sig på tværs af hundredvis af pakker. I marts 2026 kompromitterede angribere Axios, en pakke med omtrent 100 millioner ugentlige downloads, der udgiver forgiftede versioner, der droppede en fjernadgangstrojaner. Angreb som disse lander i præcis laget mellem traditionel AppSec og endpoint-værktøjer: det lag, et AI-lager er bygget til at belyse.
- For det tredje lækker hemmeligheder og legitimationsoplysninger gennem AI. GitGuardians State of Secrets Sprawl 2026 rapporterede det Lækager af hemmeligheder fra AI-tjenester steg med 81 % år over år, og at AI-assisteret commits leak secrets med omtrent dobbelt så høj hastighed som basislinjen. Enhver udokumenteret model, agent eller MCP-server er en potentiel vej til en legitimationsoplysninger.
Traditionel AppSec stopper ved repository'et og forstår ikke, hvad en model er. Endpoint-værktøjer overvåger operativsystemet, men forstår ikke pakker, MCP-servere eller AI-assistenter. Kløften mellem dem er der, hvor AI-risikoen akkumuleres, og en opgørelse er det første skridt til at lukke den.
Hvor AI gemmer sig: Skygge-AI på tværs af SDLC
Shadow AI Er et AI-system implementeret uden formel godkendelse eller styring: copiloten, som en udvikler aktiverede i sidste uge, MCP-serveren, der kører på en bærbar computer, modellen, der trækkes direkte fra en offentlig hub til et sideprojekt. Det er ikke et edge-case. I en undersøgelse fra 2026 af over 400 sikkerhedsledere var det kun 19 % rapporterede fuld indsigt i, hvor og hvordan AI bruges på tværs af deres organisation, mens det overvældende flertal allerede brugte eller afprøvede AI-kodningsassistenter.
Den sværeste skygge-AI at finde er AI'en inde i softwarens livscyklus, fordi den sjældent optræder i en cloud-konsol:
- Modeller og AI-biblioteker trækkes ind i lagre som afhængigheder.
- AI-kodningsassistenter konfigureret pr. udvikler, pr. IDE.
- MCP-servere og regelfiler, der kører lokalt på udviklerslutpunkter.
- Agentworkflows åbner stille og roligt pull requests eller installation af pakker.
Derfor er det ikke nok at opdage data udelukkende i skyen. En fuldstændig AI-opgørelse skal nå ind i kode- og byggemiljøer (udviklerens bærbare computer, repository'et, pipeline), ikke kun produktionsskyen.
Hvad hører hjemme i en AI-BOM
En revisionsklar AI-BOM forvandler din lagerbeholdning til noget, du kan bevise. Som minimum bør den indeholde:
- Alle AI-aktiver: modeller, datasæt, agenter, MCP-servere, AI-kodningsværktøjer.
- Aktivtype, placering og detektionssikkerhed for hver.
- Proveniens og afhængigheder (hvor modellen eller komponenten stammer fra).
- Et risikoniveau pr. aktiv, baseret på AI-specifikke angrebsvektorer.
- Reguleringskortlægning til EU's AI-lovgivning, NIST AI RMF og ISO/IEC 42001.
- Et eksporterbart, maskinlæsbart format for revisorer og kunder.
De organisationer, der kan generere en AI-BOM on-demand, vil have en reel fordel i forhold til overholdelse af regler og tillid, efterhånden som AI-revisionsforpligtelserne modnes.
AI-opgørelse og overholdelse af regler: EU's AI-lov, NIST AI RMF og ISO/IEC 42001
Ingen af de store frameworks nævner "AI-inventar" som en post, men hver enkelt er reelt umulig at opfylde uden. Du kan ikke dokumentere, klassificere eller styre AI-systemer, du ikke kan se.
En bemærkning om timingen: Udrulningen af EU's AI-lov blev revideret med "Digital Omnibus"-aftalen fra maj 2026, som udskød de fleste højrisikoforpligtelser til december 2027, samtidig med at flere milepæle fra den 2. august 2026 blev bevaret (gennemsigtighedspligter, GPAI-sanktionsbeføjelser). Betragt nøjagtige datoer som et bevægeligt mål, og bekræft dem i forhold til primære EU-kilder. Men retningen er klar, og opgørelse er forudsætningen for det hele.
Sådan opbygger og vedligeholder du et AI-lager
Opbygning af en inventarliste handler mindre om en engangsrevision og mere om at etablere en kontinuerlig proces, fordi AI-aktiver ændrer sig konstant: nye modeller tages i brug, nye agenter implementeres, nye MCP-servere konfigureres, ofte uden godkendelse.
En praktisk tilgang:
- Opdag automatisk på tværs af kode, build og cloud. Manuelle regneark bliver forældede inden for få dage. Discovery skal køre kontinuerligt og nå ind i SDLC, ikke kun kørselstid.
- Klassificer og kortlæg relationer. Registreringstype, placering, oprindelse og, afgørende, hvordan hvert aktiv er forbundet med andre og med hemmeligheder.
- Score risiko i kontekst. En flad liste med hundredvis af fund hjælper ingen; prioritér efter, hvad der rent faktisk er tilgængeligt, udnytteligt og forretningskritisk.
- Tildel ejerskab. Ethvert aktiv har brug for en ansvarlig ejer.
- Hold det aktivt og eksporterbart. Vedligehold det som et kontinuerligt lager, der kan producere en AI-BOM efter behov.
Hvad skal man kigge efter i AI-lagersoftware
Hvis du evaluerer værktøjer, er disse de funktioner, der adskiller ægte AI-lagersoftware fra en statisk liste:
- Forstår AI-specifikke aktivtyper (modeller, agenter, MCP-servere, datasæt), ikke kun pakker og biblioteker.
- Når ind i SDLC, opdage AI i kode og på udviklernes endpoints, ikke kun i skyen.
- Kortrelationer, ikke kun individuelle aktiver, så risiko er synlig i kontekst.
- Scorer risiko på AI-specifikke angrebsvektorer (hurtig injektion, usikker MCP, overdreven handlekraft), ikke kun CVE-sværhedsgraden.
- Kører kontinuerligt, fanger ny AI, som det ser ud til.
- Producerer en revisionsklar AI-BOM der tilfredsstiller både revisorer og enterprise indkøb.
- Forbinder lagerbeholdning med håndhævelse, så du kan handle ud fra det, du finder.
Fra opgørelse til handling: Sikring af det, du finder
Opdagelse er det første skridt; det andet er at forstå, hvilke aktiver der indebærer en reel risiko, for det vil de fleste ikke. Målet er at gå fra tusindvis af rå fund til den håndfuld, der rent faktisk kan kompromittere systemer, data eller operationer: dem, der er i aktiv brug, accepterer upålidelig input, realistisk set kan udnyttes, har følsom adgang og påvirker produktion eller regulerede aktiver.
Det er her, AI Security Posture Management (AI-SPM) opfanger: opgørelse af inventaret, risikovurdering langs AI-angrebsstien, kortlægning af det til regulering og produktion af AI-BOM. Det er også her, inventar møder håndhævelse: blokering af ondsindede afhængigheder, før de installeres, afvisning af ikke-godkendte MCP-servere og -modeller og inddæmning af kompromitterede slutpunkter, før en hændelse spreder sig.
At Xygeni, dette er den model, vi bygger hen imod: kontinuerlig AI-opgørelse og AI-BOM gennem AI-SPM, malwaredetektion, der fanger ondsindede pakker, før en signatur findes (MEW, tidlig advarsel om malware), og håndhævelse af politikker ved udviklerens slutpunkt via Xygeni Shield. Detektion er i overensstemmelse med OWASP Top 10 for LLM-applikationer, OWASP Top 10 for Agentic-apps og OWASP MCP Top 10. Men uanset hvilken tilgang du vælger, gælder princippet: Du kan ikke sikre det, du ikke kan se, og en AI-opgørelse er der, hvor synligheden begynder.
Ofte Stillede Spørgsmål
Hvordan adskiller en AI-BOM sig fra en SBOM?
An SBOM katalogiserer open source- og tredjepartssoftwareafhængigheder, scoret efter CVE-alvorlighed. En AI-BOM katalogiserer AI-specifikke aktiver (modeller, agenter, MCP-servere, datasæt) med AI-specifik risikoscoring og regulatorisk kortlægning. Efterhånden som AI spredes på tværs af SDLC, AI-BOM bliver lige så grundlæggende som SBOM.
Hvad er skygge-AI, og hvordan opdager jeg det?
Skygge-AI er enhver AI, der anvendes uden formel godkendelse eller styring: en aktiveret copilot, en lokal MCP-server, en model hentet fra en offentlig hub. Du opdager den med kontinuerlig automatiseret inventar, der rækker ind i kode, build pipelines og udvikler-slutpunkter, ikke kun produktionsskyen, hvor det meste skygge-AI aldrig optræder.
Kræver EU's AI-lovgivning en AI-opgørelse?
EU's AI-lovgivning nævner ikke eksplicit "AI-opgørelse", men dens dokumentations-, klassificerings- og registreringsforpligtelser for højrisikosystemer er umulige at opfylde uden en sådan. Det samme gælder for NIST AI RMF (Map function, Govern 1.6) og ISO/IEC 42001, som kræver vedligeholdelse af en opgørelse over AI-systemer.
Hvad er AI-SPM?
AI Security Posture Management (AI-SPM) er praksissen med løbende at opdage AI-aktiver, score deres risiko langs AI-angrebsstien, kortlægge dem til regulering og producere en AI-BOM. Det udvider posture management-tænkningen (kendt fra CSPM og DSPM) til AI-specifikke aktiver og angrebsvektorer.
Hvor ofte skal en AI-opgørelse opdateres?
Kontinuerligt. AI-aktiver ændrer sig dagligt, efterhånden som teams implementerer nye modeller, implementerer nye agenter og konfigurerer nye MCP-servere, normalt uden formel godkendelse. En point-in-time-scanning er forældet inden for få dage, så effektiv AI-lagersoftware kører som en løbende proces snarere end en engangsrevision.
Hvordan laver jeg en oversigt over AI, der bruges i kildekode?
At opføre AI i kode betyder at detektere AI-modeller og biblioteker, der hentes som afhængigheder, AI-kodningsassistenter, der er konfigureret pr. udvikler, og MCP-servere eller regelfiler, der kører lokalt. Dette kræver registrering, der opererer inde i SDLC (lagre, build pipelines og udvikler-slutpunkter) i stedet for kun i cloud-konsoller.
