An AI-inventering är en kontinuerligt uppdaterad katalog över alla AI-tillgångar som körs i din organisation — modeller, AI-drivna slutpunkter, datamängder, AI-kodningsassistenter, MCP-servrar och AI-beroenden — tillsammans med de relationer, risker och ägare som kopplar samman dem. I ett säkerhetssammanhang har detta ingenting att göra med lager- eller lagerhantering; här, "AI-inventering" betyder helt enkelt att veta exakt vilken AI du kör, var den finns och vad den kan nå.
Allt eftersom AI sprider sig över alla steg av mjukvaruutveckling, från kodgenerering i IDE:n till autonoma agenter som agerar inuti CI/CD pipelines, frågan är inte längre om AI finns i din miljö. Det är huruvida du kan se det. Den här guiden förklarar vad ett AI-inventeringssystem är, hur det relaterar till en AI-BOM och en SBOM, varför skugga AI har blivit ett säkerhetsproblem, och hur praxisen anpassas till EU:s AI-lag, NIST AI RMF och ISO / IEC 42001.
Viktiga takeaways
- En AI-inventering katalogiserar varje modell, dataset, agent, MCP-server och AI-kodningsverktyg under hela din programvarulivscykel, inte bara de som IT-godkänt.
- Shadow AI, AI som antas utan styrning, är nu normen, inte undantaget: i en undersökning av säkerhetsledare från 2026, endast 19 % av organisationerna rapporterade fullständig insyn i var och hur AI används.
- An AI-BOM (AI-materiallista) är den revisionsklara utdata från en AI-inventering: AI-erans efterföljare till SBOM.
- Reglering är på väg. EU:s AI-lag, NIST AI RMF och ISO/IEC 42001 kräver i praktiken att du vet vilken AI du använder.
- En inventering är bara utgångspunkten; värdet kommer från att bedöma risker och agera utifrån det lilla antal tillgångar som verkligen spelar roll.
Vad är ett AI-inventering?
En AI-inventering är praxisen att upptäcka, katalogisera och kontinuerligt övervaka varje AI-tillgång som är aktiv under hela programvaruutvecklingens livscykel, och de risker som är förknippade med var och en. En komplett inventering besvarar tre frågor för varje tillgång: vad är den, var körs den och vad kan den komma åt?
Det omfånget är bredare än vad de flesta team förväntar sig. En meningsfull AI-inventering bör omfatta:
- Modelleralla stora språkmodeller och grundmodeller som används inom utveckling och produktion, med versions-, plats- och detekteringssäkerhet.
- datasetträningsdata, hämtningsdatamängder och vektorlager, inklusive exponering för förgiftat kontext och dataläckage.
- Agenterautonoma system som vidtar åtgärder i din omgivning, till exempel att öppna pull requests, installera beroenden eller vidrör infrastruktur.
- MCP-servrar: Modell Context Protocol servrar som kopplar AI-assistenter till externa verktyg, API:er och datakällor.
- AI-kodningsverktyg och assistenter: copiloter och IDE-integrationer som genererar kod, föreslå beroenden och interagera med arkiv.
- AI ramverkLangChain, LangGraph, agentservrar och andra orkestreringslager som kopplar modeller till verktyg och data.
- Relationer mellan tillgångar: kopplingarna mellan modeller, agenter, servrar, datamängder och de hemligheter som är kopplade till dem. Ett relationsdiagram synliggör risk i sitt sammanhang, inte som en platt lista.
AI-lager kontra AI-tillgångslager kontra AI-BOM, och hur de skiljer sig från en SBOM
Dessa termer används löst, så det är bra att vara förbereddcise. ”AI-inventering” och ”AI-tillgångsinventering” beskriver samma sak: den levande katalogen över AI-tillgångar och deras risker. En AI-BOM är den exporterbara artefakt som lagret produceraren maskinläsbar materialförteckning som du kan lämna till en revisor eller en enterprise köpare.
Det renaste sättet att förstå AI-BOM är genom analogi med SBOM:
I takt med att AI blir integrerat över hela SDLC, AI-BOM blir lika grundläggande som SBOM, och säkerhetschefer får alltmer förfrågningar från revisorer och enterprise upphandlingsteam för just denna artefakt.
Varför AI-inventering är viktigt nu
Tre krafter har förvandlat AI-inventering från något bra att ha till en prioritet.
- För det första skriver AI osäker kod i stor skala. Oberoende forskning visar konsekvent att en stor andel AI-genererad kod innehåller sårbarheter. Den ursprungliga NYU/Copilot-studien av Pearce et al. fann ungefär 40 % av de genererade programmen innehöll säkerhetsbrister, och mer nyligen genomförda storskaliga tester pekar på samma sätt: Veracodes analys från 2025 över 100+ modeller fann endast 55 % av AI-genererad kod var säkerOm du inte vet vilka assistenter som genererar kod i din pipelines, du kan inte kontrollera den risken.
- För det andra har mjukvaruleveranskedjan blivit en AI-attackyta. I september 2025, Shai Hulud, den första självförökande npm-masken, förvandlade utvecklarmaskiner till en distributionsmekanism och spred sig över hundratals paket. I mars 2026 komprometterade angripare Axios, ett paket med ungefär 100 miljoner nedladdningar per vecka, publicerade förgiftade versioner som släppte en fjärråtkomsttrojan. Attacker som dessa hamnar i exakt lagret mellan traditionell AppSec och endpoint-verktyg: lagret som ett AI-inventarium är byggt för att belysa.
- För det tredje läcker hemligheter och inloggningsuppgifter genom AI. GitGuardians State of Secrets Sprawl 2026 rapporterade att Läckorna av AI-tjänsthemligheter ökade med 81 % jämfört med föregående år, och att AI-assisterad commits leak secrets till ungefär dubbelt så höga som baslinjen. Varje odokumenterad modell, agent eller MCP-server är en potentiell väg till en autentiseringsuppgift.
Traditionell AppSec stannar vid repositoriet och förstår inte vad en modell är. Endpoint-verktyg övervakar operativsystemet men förstår inte paket, MCP-servrar eller AI-assistenter. Gapet mellan dem är där AI-risken ackumuleras, och en inventering är det första steget för att täppa till den.
Där AI gömmer sig: Skugga AI över hela SDLC
Shadow AI är något AI-system implementerat utan formellt godkännande eller styrning: copiloten som en utvecklare aktiverade förra veckan, MCP-servern som körs på en bärbar dator, modellen hämtad direkt från en offentlig hubb till ett sidoprojekt. Det är inte ett edge-fall. I en undersökning från 2026 med över 400 säkerhetsledare, endast 19 % rapporterade fullständig insyn i var och hur AI används i hela sin organisation, medan den överväldigande majoriteten redan använde eller testade AI-kodningsassistenter.
Den svåraste skugg-AI:n att hitta är AI:n inuti mjukvarulivscykeln, eftersom den sällan dyker upp i en molnkonsol:
- Modeller och AI-bibliotek hämtas till databaser som beroenden.
- AI-kodningsassistenter konfigurerade per utvecklare, per IDE.
- MCP-servrar och regelfiler som körs lokalt på utvecklarslutpunkter.
- Agentarbetsflöden öppnas tyst pull requests eller installera paket.
Det är därför molnbaserad identifiering inte räcker. En verkligt komplett AI-inventering måste nå in i kod- och byggmiljöer (utvecklarens bärbara dator, arkivet, pipeline), inte bara produktionsmolnet.
Vad som hör hemma i en AI-BOM
En revisionsklar AI-BOM förvandlar ditt lager till något du kan bevisa. Som ett minimum bör den innehålla:
- Varje AI-tillgång: modeller, datamängder, agenter, MCP-servrar, AI-kodningsverktyg.
- Tillgångstyp, plats och detekteringssäkerhet för varje.
- Proveniens och beroenden (var modellen eller komponenten kommer ifrån).
- En risknivå per tillgång, baserad på AI-specifika attackvektorer.
- Regulatorisk mappning till EU:s AI-lag, NIST AI RMF och ISO/IEC 42001.
- Ett exporterbart, maskinläsbart format för revisorer och kunder.
De organisationer som kan generera en AI-BOM på begäran kommer att ha en verklig fördel med efterlevnad och förtroende i takt med att skyldigheterna för AI-revision mognar.
AI-inventering och efterlevnad: EU:s AI-lag, NIST AI RMF och ISO/IEC 42001
Inget av de större ramverken nämner "AI-inventering" som en radpost, men vart och ett av dem är i praktiken omöjligt att uppfylla utan det. Du kan inte dokumentera, klassificera eller styra AI-system som du inte kan se.
En anmärkning om tidpunkten: Utrullningen av EU:s AI-lag reviderades genom avtalet om "Digital Omnibus" från maj 2026, som sköt upp de flesta högriskskyldigheter till december 2027, samtidigt som flera milstolpar från den 2 augusti 2026 bibehölls (transparensskyldigheter, straffbefogenheter för GPAI). Behandla exakta datum som ett rörligt mål och bekräfta mot primära EU-källor. Men färdriktningen är tydlig, och inventering är en förutsättning för allt detta.
Hur man bygger och underhåller ett AI-lager
Att bygga ett inventarium handlar mindre om en engångsrevision och mer om att etablera en kontinuerlig process, eftersom AI-tillgångar ständigt förändras: nya modeller antas, nya agenter driftsätts, nya MCP-servrar konfigureras, ofta utan godkännande.
Ett praktiskt tillvägagångssätt:
- Upptäck automatiskt i kod, build och moln. Manuella kalkylblad blir inaktuella inom några dagar. Discovery måste köras kontinuerligt och nå in i SDLC, inte bara körtid.
- Klassificera och kartlägga relationer. Registreringstyp, plats, ursprung och, avgörande, hur varje tillgång kopplas till andra och till hemligheter.
- Poängrisk i kontext. En platt lista med hundratals fynd hjälper ingen; prioritera efter vad som faktiskt är tillgängligt, exploaterbart och affärskritiskt.
- Tilldela ägarskap. Varje tillgång behöver en ansvarig ägare.
- Håll det aktivt och exporterbart. Underhåll det som ett kontinuerligt lager som kan producera en AI-BOM på begäran.
Vad man ska leta efter i AI-inventeringsprogramvara
Om du utvärderar verktyg är det här de funktioner som skiljer äkta AI-inventeringsprogramvara från en statisk lista:
- Förstår AI-specifika tillgångstyper (modeller, agenter, MCP-servrar, dataset), inte bara paket och bibliotek.
- Når in i SDLC, upptäcka AI i kod och på utvecklarnas slutpunkter, inte bara i molnet.
- Kartrelationer, inte bara enskilda tillgångar, så risken syns i sitt sammanhang.
- Riskpoäng för AI-specifika attackvektorer (snabb injektion, osäker MCP, överdriven agentskap), inte bara CVE-svårighetsgrad.
- Körs kontinuerligt, fångar ny AI som det verkar.
- Producerar en revisionsklar AI-BOM som tillfredsställer både revisorer och enterprise anskaffning.
- Kopplar inventering till verkställighet, så att du kan agera utifrån det du hittar.
Från inventering till handling: säkra det du hittar
Upptäckt är det första steget; det andra är att förstå vilka tillgångar som medför verklig risk, eftersom de flesta inte gör det. Målet är att gå från tusentals råa fynd till den handfull som faktiskt kan kompromettera system, data eller verksamheter: de som används aktivt, accepterar otillförlitlig input, är realistiskt utnyttjade, har känslig åtkomst och påverkar produktion eller reglerade tillgångar.
Det är här AI-säkerhetshantering (AI-SPM) tar upp: inventering, riskbedömning längs AI-attackvägen, mappning till reglering och framtagning av AI-BOM. Det är också där inventering möter verkställighet: blockering av skadliga beroenden innan de installeras, avvisning av icke-godkända MCP-servrar och modeller, och inneslutning av komprometterade slutpunkter innan en incident sprider sig.
At Xygeni, detta är modellen vi bygger mot: kontinuerlig AI-inventering och AI-BOM genom AI-SPM, detektering av skadlig kod som fångar skadliga paket innan en signatur finns (MEW, tidig varning om skadlig kod), och policytillämpning vid utvecklarens slutpunkt via Xygeni Shield. Detekteringen är i linje med OWASP Top 10 för LLM-applikationer, OWASP Top 10 för Agentic-appar och OWASP MCP Top 10. Men oavsett vilken metod du väljer gäller principen: Du kan inte säkra det du inte kan se, och en AI-inventering är där synligheten börjar.
Vanliga frågor
Hur skiljer sig en AI-BOM från en SBOM?
An SBOM katalogiserar beroenden av öppen källkod och programvara från tredje part, poängsatta utifrån CVE-allvarlighetsgrad. En AI-BOM katalogiserar AI-specifika tillgångar (modeller, agenter, MCP-servrar, dataset) med AI-specifik riskpoängsättning och regulatorisk kartläggning. Allt eftersom AI sprids över SDLC, AI-BOM blir lika grundläggande som SBOM.
Vad är skugg-AI och hur upptäcker jag det?
Skugg-AI är all AI som används utan formellt godkännande eller styrning: en aktiverad copilot, en lokal MCP-server, en modell som hämtas från en offentlig hubb. Du upptäcker den med kontinuerlig automatiserad inventering som når in i kod, byggnation pipelineoch utvecklarslutpunkter, inte bara produktionsmolnet där det mesta av skugg-AI aldrig dyker upp.
Kräver EU:s AI-lag en AI-inventering?
EU:s AI-lag nämner inte uttryckligen "AI-inventering", men dess dokumentations-, klassificerings- och registreringsskyldigheter för högrisksystem är omöjliga att uppfylla utan en sådan. Detsamma gäller för NIST AI RMF (Map function, Govern 1.6) och ISO/IEC 42001, som kräver att man för en inventering av AI-system.
Vad är AI-SPM?
AI Security Posture Management (AI-SPM) är en metod där man kontinuerligt upptäcker AI-tillgångar, poängsätter deras risk längs AI-attackvägen, mappar dem till reglering och producerar en AI-BOM. Det utvidgar posture management-tänkandet (bekant från CSPM och DSPM) till AI-specifika tillgångar och attackvektorer.
Hur ofta bör ett AI-inventarium uppdateras?
Kontinuerligt. AI-tillgångar förändras dagligen när team antar nya modeller, driftsätter nya agenter och konfigurerar nya MCP-servrar, vanligtvis utan formellt godkännande. En tidsbestämd skanning är inaktuell inom några dagar, så effektiv AI-inventeringsprogramvara körs som en kontinuerlig process snarare än en engångsrevision.
Hur inventerar jag AI som används i källkod?
Att inventera AI i kod innebär att detektera AI-modeller och bibliotek som hämtas som beroenden, AI-kodningsassistenter som konfigurerats per utvecklare och MCP-servrar eller regelfiler som körs lokalt. Detta kräver identifiering som fungerar inuti SDLC (förråd, bygg pipelines och utvecklarslutpunkter) snarare än bara i molnkonsoler.
