An AI-inventaris Dit is een continu bijgewerkte catalogus van alle AI-middelen die binnen uw organisatie actief zijn. modellen, AI-gestuurde eindpunten, datasets, AI-codeerassistenten, MCP-servers en AI-afhankelijkheden — samen met de relaties, risico's en eigenaren die hen met elkaar verbinden. In een beveiligingscontext heeft dit niets te maken met magazijn- of voorraadbeheer; hier, "AI-inventaris" Het betekent simpelweg dat je precies weet welke AI je gebruikt, waar deze zich bevindt en wat deze kan bereiken.
Naarmate AI zich verspreidt over elke fase van softwareontwikkeling, van codegeneratie in de IDE tot autonome agenten die intern opereren, CI/CD pipelineDe vraag is dus niet langer of AI in uw omgeving aanwezig is. Het gaat erom of je het kunt zien. Deze handleiding legt uit wat een AI-inventaris is en hoe deze zich verhoudt tot een AI-BOM en een SBOM, waarom schaduw-AI is een veiligheidsprobleem geworden, en hoe de praktijk zich verhoudt tot de EU AI-wet, NIST AI RMF en ISO / IEC 42001.
Key afhaalrestaurants
- Een AI-inventaris catalogiseert elk model, elke dataset, agent, MCP-server en AI-codeertool gedurende de gehele softwarelevenscyclus, niet alleen de tools die door IT zijn goedgekeurd.
- Schaduw-AIAI, dat zonder toezicht wordt ingevoerd, is nu de norm in plaats van de uitzondering: in een onderzoek uit 2026 onder leiders op het gebied van beveiliging bleek slechts... 19% van de organisaties gaf aan volledig inzicht te hebben in waar en hoe AI wordt gebruikt..
- An AI-BOM (AI-stuklijst) is de auditklare output van een AI-inventarisatie: de opvolger van de AI-era SBOM.
- Regelgeving komt eraan. De EU AI-wetgeving, het NIST AI RMF en ISO/IEC 42001 vereisen allemaal dat u weet met welke AI u werkt.
- Een inventarisatie is slechts het begin; de waarde schuilt in het beoordelen van risico's en het handelen met betrekking tot het kleine aantal activa dat er echt toe doet.
Wat is een AI-inventarisatie?
Een AI-inventarisatie is het proces waarbij alle AI-componenten die in uw softwareontwikkelingscyclus actief zijn, worden ontdekt, gecatalogiseerd en continu gemonitord, inclusief de risico's die aan elk component verbonden zijn. Een complete inventarisatie beantwoordt voor elk component drie vragen: wat is het, waar draait het en tot welke bronnen heeft het toegang?
Die reikwijdte is groter dan de meeste teams verwachten. Een zinvolle AI-inventarisatie moet het volgende omvatten:
- Modellen: elk groot taalmodel en basismodel dat wordt gebruikt in de ontwikkelings- en productieomgeving, met versie-, locatie- en detectiebetrouwbaarheid.
- datasets: trainingsgegevens, ophaaldatasets en vectoropslag, inclusief blootstelling aan vergiftigde context en datalekken.
- Agenten: autonome systemen die acties in uw omgeving uitvoeren, zoals het openen van deuren pull requests, het installeren van afhankelijkheden of het aanpassen van de infrastructuur.
- MCP-servers: Modelcontextprotocol Servers die AI-assistenten verbinden met externe tools, API's en gegevensbronnen.
- AI-codeertools en -assistenten: copiloten en IDE-integraties die code genereren, afhankelijkheden voorstellen en interactie met repositories.
- AI-frameworks: LangChain, LangGraph, agentservers en andere orchestratielagen die modellen koppelen aan tools en data.
- Relaties tussen activaEen relatiegrafiek toont de verbanden tussen modellen, agenten, servers, datasets en de daaraan verbonden geheimen. Een relatiegrafiek maakt risico's zichtbaar in context, niet als een platte lijst.
AI-inventarisatie versus AI-activa-inventarisatie versus AI-BOM, en hoe deze verschillen van een SBOM
Deze termen worden vaak losjes gebruikt, dus het is handig om vooraf te weten hoe ze werken.cise. "AI-inventaris" en "AI-activa-inventaris" beschrijven hetzelfde.: de levende catalogus van AI-middelen en de bijbehorende risico's. Een AI-BOM is het exporteerbare artefact dat door de inventaris wordt gegenereerd.: een machineleesbare materiaallijst die u aan een auditor of een enterprise koper.
De meest heldere manier om de AI-BOM te begrijpen is door een analogie te gebruiken met de SBOM:
Naarmate AI steeds meer ingebed raakt in de SDLCDe AI-BOM wordt net zo fundamenteel als de SBOMEn beveiligingsmanagers ontvangen steeds vaker verzoeken van auditors en enterprise inkoopteams voor precies dit artefact.
Waarom AI-voorraadbeheer nu belangrijk is
Drie factoren hebben ervoor gezorgd dat AI-inventarisatie niet langer een wenselijke optie is, maar een prioriteit.
- Ten eerste schrijft AI op grote schaal onveilige code. Onafhankelijk onderzoek toont consequent aan dat een groot deel van de door AI gegenereerde code kwetsbaarheden bevat. De oorspronkelijke NYU/Copilot-studie van Pearce et al. vond ongeveer 40% van de gegenereerde programma's bevatte beveiligingslekken.En recentere grootschalige tests wijzen in dezelfde richting: de analyse van Veracode uit 2025, uitgevoerd op meer dan 100 modellen, toonde slechts aan dat... 55% van de door AI gegenereerde code was veilig.Als u niet weet welke assistenten code genereren in uw pipelines, dat risico kunt u niet beheersen.
- Ten tweede is de softwaretoeleveringsketen een kwetsbaar punt geworden voor aanvallen door AI. In september 2025, Shai HuludDe eerste zelfverspreidende npm-worm veranderde de machines van ontwikkelaars in een distributiemechanisme en verspreidde zich over honderden pakketten. In maart 2026 compromitteerden aanvallers de systemen van ontwikkelaars. Axios, een pakket met ongeveer 100 miljoen wekelijkse downloadswaarbij vergiftigde versies werden gepubliceerd die een trojan voor toegang op afstand installeerden. Aanvallen zoals deze belanden precies in de laag tussen traditionele applicatiebeveiliging en endpoint-tools: de laag die een AI-inventarisatie juist moet blootleggen.
- Ten derde lekken geheimen en inloggegevens via AI. Het rapport State of Secrets Sprawl 2026 van GitGuardian meldde dat Het aantal gelekte geheimen over AI-diensten is met 81% gestegen ten opzichte van vorig jaar.en dat AI-ondersteund commits leak secretHet percentage ligt ongeveer twee keer zo hoog als het basistarief. Elk niet-gedocumenteerd model, agent of MCP-server is een potentiële bron voor het verkrijgen van inloggegevens.
Traditionele applicatiebeveiliging stopt bij de repository en begrijpt niet wat een model is. Endpoint-tools bewaken het besturingssysteem, maar begrijpen geen pakketten, MCP-servers of AI-assistenten. De kloof tussen deze twee is waar AI-risico's zich ophopen, en een inventarisatie is de eerste stap om die te dichten.
Waar AI zich schuilhoudt: Schaduw-AI overal SDLC
Schaduw-AI Elk AI-systeem dat zonder formele goedkeuring of governance wordt gebruikt, valt onder deze categorie: de copilot die een ontwikkelaar vorige week heeft ingeschakeld, de MCP-server die op een laptop draait, het model dat rechtstreeks van een openbare hub naar een nevenproject is gehaald. Het is geen uitzondering. In een onderzoek uit 2026 onder meer dan 400 leiders in de beveiligingssector, gaf slechts een klein percentage aan dat dit deed. 19% gaf aan volledig inzicht te hebben in waar en hoe AI wordt gebruikt. binnen hun organisatie, terwijl de overgrote meerderheid al AI-codeerassistenten gebruikte of aan het testen was.
De moeilijkst te vinden verborgen AI is de AI die zich binnen de softwarelevenscyclus bevindt, omdat deze zelden in een cloudconsole verschijnt:
- Modellen en AI-bibliotheken worden als afhankelijkheden in de repositories opgenomen.
- AI-codeerassistenten, geconfigureerd per ontwikkelaar en per IDE.
- MCP-servers en regelbestanden die lokaal draaien op ontwikkelaarsapparaten.
- Agentische workflows worden stilletjes geopend pull requests of het installeren van pakketten.
Daarom is ontdekking via de cloud alleen niet voldoende. Een echt complete AI-inventarisatie moet ook de code en de buildomgevingen omvatten (de laptop van de ontwikkelaar, de repository, de pipeline), niet alleen de productiecloud.
Wat hoort er in een AI-BOM thuis?
Een auditklare AI-BOM maakt van uw inventaris iets dat u kunt bewijzen. Het moet minimaal het volgende bevatten:
- Alle AI-componenten: modellen, datasets, agents, MCP-servers, AI-codeertools.
- Objecttype, locatie en detectiebetrouwbaarheid voor elk object.
- Herkomst en afhankelijkheden (waar het model of de component vandaan komt).
- Een risiconiveau per asset, gebaseerd op AI-specifieke aanvalsvectoren.
- Regelgeving die aansluit op de EU AI-wetgeving, het NIST AI RMF en ISO/IEC 42001.
- Een exporteerbaar, machinaal leesbaar formaat voor auditors en klanten.
Organisaties die op aanvraag een AI-BOM kunnen genereren, zullen een aanzienlijk concurrentievoordeel hebben op het gebied van compliance en vertrouwen naarmate de verplichtingen rondom AI-audits toenemen.
AI-inventarisatie en -naleving: EU AI-wetgeving, NIST AI RMF en ISO/IEC 42001
Geen van de belangrijkste frameworks noemt "AI-inventarisatie" als een apart onderdeel, maar zonder deze inventarisatie is het praktisch onmogelijk om aan al deze eisen te voldoen. Je kunt AI-systemen die je niet kunt zien, niet documenteren, classificeren of beheren.
Een opmerking over de timing: de uitrol van de EU AI-wetgeving werd herzien door de "Digital Omnibus"-overeenkomst van mei 2026, waardoor de meeste risicovolle verplichtingen werden uitgesteld tot december 2027, terwijl verschillende mijlpalen van 2 augustus 2026 wel van kracht bleven (transparantieverplichtingen, sancties van de GPAI). Beschouw de exacte data als een variabele factor en raadpleeg primaire EU-bronnen. De richting is echter duidelijk en inventarisatie is de voorwaarde voor dit alles.
Hoe bouw en onderhoud je een AI-inventaris?
Het opbouwen van een inventaris is minder een eenmalige audit en meer een continu proces, omdat AI-middelen constant veranderen: nieuwe modellen worden geïntroduceerd, nieuwe agents worden ingezet, nieuwe MCP-servers worden geconfigureerd, vaak zonder goedkeuring.
Een praktische aanpak:
- Ontdek automatisch alles in code, builds en de cloud. Handmatig uitgevoerde spreadsheets verouderen binnen enkele dagen. Discovery moet continu draaien en toegang bieden tot de gegevens. SDLC, niet alleen tijdens de uitvoering.
- Relaties classificeren en in kaart brengen. Het documenttype, de locatie, de herkomst en, cruciaal, hoe elk document verbonden is met andere documenten en met geheimen.
- Risicobeoordeling in de juiste context. Een platte lijst met honderden bevindingen helpt niemand; geef prioriteit aan wat daadwerkelijk haalbaar, bruikbaar en bedrijfskritisch is.
- Eigendom toewijzen. Elk bezit heeft een verantwoordelijke eigenaar nodig.
- Zorg dat het actueel en exporteerbaar blijft. Houd het aan als een continue voorraad die op aanvraag een AI-BOM kan genereren.
Waarop te letten bij AI-voorraadbeheersoftware
Als u tools evalueert, zijn dit de mogelijkheden die echte AI-inventarisatiesoftware onderscheiden van een statische lijst:
- Begrijpt AI-specifieke assettypen (modellen, agents, MCP-servers, datasets), niet alleen pakketten en bibliotheken.
- Reikt tot in de SDLCHet ontdekken van AI in code en op ontwikkelaarsplatformen, niet alleen in de cloud.
- KaartrelatiesHet gaat niet alleen om individuele activa, waardoor het risico in de juiste context zichtbaar wordt.
- Beoordeelt het risico op AI-specifieke aanvalsvectoren. (snelle injectie, onveilige MCP, overmatige autonomie), niet alleen de ernst van CVE.
- Loopt continuen nieuwe AI detecteren zodra die verschijnt.
- Produceert een auditklare AI-BOM. dat voldoet aan de eisen van zowel de accountants als enterprise inkoop.
- Koppelt inventaris aan handhavingzodat je kunt handelen naar wat je vindt.
Van inventarisatie naar actie: het beveiligen van wat u vindt.
Ontdekking is de eerste stap; de tweede is begrijpen welke activa een reëel risico vormen, want de meeste zullen dat niet doen. Het doel is om van duizenden ruwe bevindingen over te gaan naar de handvol die daadwerkelijk systemen, data of processen in gevaar kunnen brengen: die welke actief in gebruik zijn, onbetrouwbare input accepteren, realistisch exploiteerbaar zijn, gevoelige toegang bevatten en productie- of gereguleerde activa beïnvloeden.
Dit is waar AI-beveiligingshoudingsbeheer (AI-SPMHet proces omvat: het inventariseren van de risico's, het beoordelen van de risico's langs het AI-aanvalspad, het koppelen hiervan aan regelgeving en het produceren van de AI-BOM (Bill of Materials). Het is ook het punt waar inventarisatie en handhaving samenkomen: het blokkeren van kwaadaardige afhankelijkheden voordat ze worden geïnstalleerd, het afwijzen van niet-goedgekeurde MCP-servers en -modellen, en het isoleren van gecompromitteerde eindpunten voordat een incident zich verspreidt.
At XygeniDit is het model waar we naartoe werken: continue AI-inventarisatie en AI-BOM via AI-SPM, malwaredetectie die schadelijke pakketten onderschept voordat er een signatuur bestaat.MEW, Malware Early Warning) en het afdwingen van beleid op het ontwikkelaars-eindpunt via Xygeni Shield. De detectie is afgestemd op de OWASP Top 10 voor LLM-applicaties, de OWASP Top 10 voor agentische apps en de OWASP MCP Top 10. Maar welke aanpak u ook kiest, het principe blijft hetzelfde: Je kunt niet beveiligen wat je niet kunt zien, en een AI-inventarisatie is waar inzicht begint.
Veelgestelde vragen
Wat is het verschil tussen een AI-BOM en een SBOM?
An SBOM Een AI-BOM (Bill of Materials) catalogiseert open-source en softwareafhankelijkheden van derden, beoordeeld op de ernst van CVE's (Clinical Vein Explosives). Een AI-BOM catalogiseert AI-specifieke assets (modellen, agents, MCP-servers, datasets) met AI-specifieke risicoscores en regelgevingsmapping. Naarmate AI zich verder verspreidt over de SDLCDe AI-BOM wordt net zo fundamenteel als de SBOM.
Wat is schaduw-AI en hoe kan ik het opsporen?
Shadow AI is elke vorm van AI die zonder formele goedkeuring of governance wordt gebruikt: een ingeschakelde copiloot, een lokale MCP-server, een model dat van een openbare hub is gehaald. Je ontdekt het door middel van continue geautomatiseerde inventarisatie die de code en build analyseert. pipelineen ontwikkelaars-endpoints, niet alleen de productiecloud waar de meeste verborgen AI nooit verschijnt.
Vereist de EU-wetgeving inzake kunstmatige intelligentie een inventarisatie van kunstmatige intelligentie?
De EU-wetgeving inzake kunstmatige intelligentie (AI) noemt "AI-inventarisatie" niet expliciet, maar de documentatie-, classificatie- en registratieverplichtingen voor systemen met een hoog risico zijn zonder een dergelijke inventarisatie onmogelijk na te komen. Hetzelfde geldt voor het NIST AI RMF (kaartfunctie, Govern 1.6) en ISO/IEC 42001, die het bijhouden van een inventarisatie van AI-systemen vereisen.
Wat is AI-SPM?
AI Security Posture Management (AI-SPM) is de praktijk van het continu ontdekken van AI-assets, het beoordelen van hun risico langs het AI-aanvalspad, het koppelen ervan aan regelgeving en het opstellen van een AI-BOM (Bill of Materials). Het breidt het denken over posture management (bekend van CSPM en DSPM) uit naar AI-specifieke assets en aanvalsvectoren.
Hoe vaak moet een AI-inventaris worden bijgewerkt?
Continu. AI-assets veranderen dagelijks, omdat teams nieuwe modellen implementeren, nieuwe agents inzetten en nieuwe MCP-servers configureren, meestal zonder formele goedkeuring. Een momentopname is binnen enkele dagen alweer verouderd, dus effectieve AI-inventarisatiesoftware draait als een continu proces in plaats van een eenmalige audit.
Hoe inventariseer ik de AI die in de broncode wordt gebruikt?
Het inventariseren van AI in code betekent het detecteren van AI-modellen en -bibliotheken die als afhankelijkheden worden gebruikt, AI-codeerassistenten die per ontwikkelaar zijn geconfigureerd, en MCP-servers of regelbestanden die lokaal draaien. Dit vereist een detectieproces dat binnen de code plaatsvindt. SDLC (repositories, build pipelines en ontwikkelaars-eindpunten) in plaats van alleen in cloudconsoles.
