An AI-stokregistro estas kontinue ĝisdatigita katalogo de ĉiu artefarita inteligenteco funkcianta tra via organizo — modeloj, finpunktoj funkciigitaj per AI, datumaroj, AI-kodaj asistantoj, MCP-serviloj kaj AI-dependecoj — kune kun la rilatoj, riskoj kaj posedantoj, kiuj ilin ligas. En sekureca kunteksto, tio tute ne rilatas al stokejo- aŭ stokregistro-administrado; ĉi tie, "Arkivo de artefarita inteligenteco" simple signifas scii precize kian artefaritan inteligentecon vi uzas, kie ĝi loĝas, kaj kion ĝi povas atingi.
Ĉar AI disvastiĝas tra ĉiu etapo de programara disvolviĝo, de kodgenerado en la IDE ĝis aŭtonomaj agentoj agantaj interne CI/CD pipelines, la demando jam ne estas ĉu AI ĉeestas en via ĉirkaŭaĵo. Temas pri ĉu vi povas vidi ĝin. Ĉi tiu gvidilo klarigas kio estas AI-stokregistro, kiel ĝi rilatas al AI-BOM kaj SBOM, kial ombro AI fariĝis sekureca problemo, kaj kiel la praktiko rilatas al la EU AI-Leĝo, NIST AI RMF kaj ISO / IEC 42001.
Ŝlosilaj sendaĵoj
- AI-stokregistro katalogas ĉiun modelon, datumaron, agenton, MCP-servilon kaj AI-kodilon tra via programara vivciklo, ne nur tiujn, kiujn IT-aprobis.
- Ombro AI, AI adoptita sen regado, nun estas la normo, ne la escepto: en unu enketo de sekurecaj gvidantoj en 2026, nur 19% de organizoj raportis plenan videblecon pri kie kaj kiel AI estas uzata.
- An AI-BOM (AI-Listo de Materialoj) estas la revizio-preta rezulto de AI-stokregistro: la AI-epoka posteulo de la SBOM.
- Reguligo alvenas. La EU-leĝo pri artefarita inteligenteco, NIST-regularo pri artefarita inteligenteco kaj ISO/IEC 42001 ĉiuj efektive postulas, ke vi sciu, kiun artefaritan inteligentecon vi funkciigas.
- Stokregistro estas nur la deirpunkto; la valoro venas de la taksado de risko kaj agado rilate al la malgranda nombro da aktivaĵoj, kiuj vere gravas.
Kio estas AI-stokregistro?
AI-stokregistro estas la praktiko malkovri, katalogi kaj kontinue monitori ĉiun AI-aktivaĵon funkciantan dum via programara disvolva vivciklo, kaj la riskojn ligitajn al ĉiu. Kompleta stokregistro respondas tri demandojn por ĉiu aktivaĵo: kio ĝi estas, kie ĝi funkcias, kaj kion ĝi povas aliri?
Tiu amplekso estas pli vasta ol plej multaj teamoj atendas. Signifa AI-stokregistro devus kovri:
- modeloj: ĉiu granda lingvomodelo kaj fundamenta modelo uzata dum disvolviĝo kaj produktado, kun versio, loko kaj detektofido.
- Datasets: trejnaj datumoj, retrovaj datumaroj kaj vektorstokejoj, inkluzive de eksponiĝo al venenigita kunteksto kaj datenelfluado.
- agentoj: aŭtonomaj sistemoj kiuj agas en via ĉirkaŭaĵo, kiel ekzemple malfermi pull requests, instalante dependecojn, aŭ tuŝante infrastrukturon.
- MCP-serviloj: Modela Kunteksta Protokolo serviloj kiuj konektas AI-asistantojn al eksteraj iloj, API-oj kaj datenfontoj.
- AI-kodaj iloj kaj asistantoj: kunpilotoj kaj IDE-integriĝoj kiuj generas kodon, sugesti dependecojn kaj interagi kun deponejoj.
- AI-kadrojLangChain, LangGraph, agento-serviloj kaj aliaj orkestradaj tavoloj, kiuj konektas modelojn al iloj kaj datumoj.
- Rilatoj inter aktivaĵoj: la ligoj inter modeloj, agentoj, serviloj, datumaroj kaj la sekretoj ligitaj al ili. Rilata grafeo videbligas riskon en kunteksto, ne kiel ebenan liston.
AI-stokregistro kontraŭ AI-aktivaĵa stokregistro kontraŭ AI-BOM, kaj kiel ili diferencas de SBOM
Ĉi tiuj terminoj estas uzataj loze, do helpas esti antaŭcise. "Artiklo-inventaro" kaj "Artiklo-aktivaĵa inventaro" priskribas la saman aferon: la vivanta katalogo de artefarita inteligenteco kaj iliaj riskoj. AI-BOM estas la eksportebla artefakto, kiun stokregistro produktas.maŝinlegebla listo de materialoj, kiun vi povas transdoni al revizoro aŭ enterprise aĉetanto.
La plej klara maniero kompreni la AI-BOM estas per analogeco al la SBOM:
Dum AI enradikiĝas tra la SDLC, la AI-BOM fariĝas tiel fundamenta kiel la SBOM, kaj sekurecaj gvidantoj pli kaj pli ricevas petojn de revizoroj kaj enterprise aĉetteamoj por ĝuste ĉi tiu artefakto.
Kial AI-stokregistro gravas nun
Tri fortoj transformis la inventaron de AI de dezirindaĵo al prioritato.
- Unue, AI skribas nesekuran kodon je granda skalo. Sendependa esplorado konstante trovas, ke granda parto de kodo generita per artefarita inteligenteco havas vundeblecojn. La originala studo de NYU/Copilot de Pearce kaj aliaj trovis proksimume 40% de generitaj programoj enhavis sekurecajn malfortojn, kaj pli lastatempaj grandskalaj testoj montras la saman vojon: la analizo de Veracode en 2025 trans pli ol 100 modeloj trovis nur 55% de la per artefarita inteligenteco generita kodo estis sekuraSe vi ne scias, kiuj asistantoj generas kodon en via pipelines, vi ne povas regi tiun riskon.
- Due, la provizoĉeno de programaro fariĝis ataksurfaco de AI. En septembro 2025, Shai-Hulud, la unua mem-disvastiĝanta npm-vermo, transformis programistajn maŝinojn en distribuan mekanismon, disvastiĝante tra centoj da pakaĵoj. En marto 2026, atakantoj kompromitis aksioj, pakaĵo kun proksimume 100 milionoj da semajnaj elŝutoj, publikigante venenigitajn versiojn kiuj faligis trojanon por fora aliro. Atakoj kiel ĉi tiuj alteriĝas ĝuste en la tavolo inter tradicia AppSec kaj finpunktaj iloj: la tavolo, kiun AI-stokregistro estas konstruita por lumigi.
- Trie, sekretoj kaj akreditaĵoj likas tra AI. La raporto "State of Secrets Sprawl 2026" de GitGuardian raportis, ke likoj de sekretoj de artefarita inteligenteco pliiĝis je 81% jare post jaro, kaj ke AI-helpata commits leak secrets je proksimume duoble la baza rapideco. Ĉiu nedokumentita modelo, agento aŭ MCP-servilo estas ebla vojo al akreditaĵo.
Tradicia AppSec haltas ĉe la deponejo kaj ne komprenas, kio estas modelo. Finpunktaj iloj observas la operaciumon sed ne komprenas pakaĵojn, MCP-servilojn aŭ AI-asistantojn. La breĉo inter ili estas kie AI-risko akumuliĝas, kaj inventaro estas la unua paŝo por fermi ĝin.
Kie AI kaŝiĝas: Ombra AI tra la SDLC
Ombro AI ĉu iu ajn AI-sistemo estas adoptita sen formala aprobo aŭ administrado: la kunpiloto, kiun programisto ebligis lastan semajnon, la MCP-servilo funkcianta sur tekokomputilo, la modelo prenita rekte de publika nabo en flankan projekton. Ĝi ne estas randa kazo. En enketo de 2026 de pli ol 400 sekurecaj gvidantoj, nur 19% raportis plenan videblecon pri kie kaj kiel AI estas uzata tra sia organizo, dum la superforta plimulto jam uzis aŭ pilotis AI-kodajn asistantojn.
La plej malfacile trovebla ombra artefarita inteligenteco estas la artefarita inteligenteco ene de la programara vivciklo, ĉar ĝi malofte aperas en nuba konzolo:
- Modeloj kaj AI-bibliotekoj enmetitaj en deponejojn kiel dependecoj.
- AI-kodadaj asistantoj agorditaj laŭ programisto, laŭ IDE.
- MCP-serviloj kaj reguldosieroj funkciantaj loke sur programistaj finpunktoj.
- Agentaj laborfluoj kviete malfermiĝas pull requests aŭ instalante pakaĵojn.
Tial nuba malkovro ne sufiĉas. Vere kompleta artefarita inteligenteco-inventaro devas atingi kodon kaj konstrui mediojn (la tekokomputilo de la programisto, la deponejo, la pipeline), ne nur la produktada nubo.
Kio apartenas al AI-BOM
Kontrol-preta AI-BOM transformas vian inventaron en ion, kion vi povas pruvi. Minimume, ĝi devus inkluzivi:
- Ĉiu AI-aktivaĵo: modeloj, datumaroj, agentoj, MCP-serviloj, AI-kodigaj iloj.
- Tipo de aktivaĵo, loko kaj detektofido por ĉiu.
- Deveno kaj dependecoj (de kie venis la modelo aŭ komponanto).
- Riskonivelo por ĉiu aktivaĵo, bazita sur AI-specifaj atakvektoroj.
- Reguliga mapado al la EU AI Act, NIST AI RMF kaj ISO/IEC 42001.
- Eksportebla, maŝinlegebla formato por revizoroj kaj klientoj.
La organizoj, kiuj povas generi AI-BOM laŭpete, havos veran avantaĝon pri konformeco kaj fido kiam la devoj pri AI-audito maturiĝos.
AI-inventaro kaj konformeco: EU AI-Leĝo, NIST AI RMF kaj ISO/IEC 42001
Neniu el la ĉefaj kadroj nomas "AI-stokregistron" kiel linion, sed ĉiu estas efektive nekontentebla sen ĝi. Vi ne povas dokumenti, klasifiki aŭ regi AI-sistemojn, kiujn vi ne povas vidi.
Noto pri tempigo: la efektivigo de la EU AI-Leĝo estis reviziita per la interkonsento "Cifereca Omnibuso" de majo 2026, kiu prokrastis la plej multajn altriskajn devojn ĝis decembro 2027, samtempe konservante plurajn mejloŝtonojn de la 2a de aŭgusto 2026 aktivaj (travideblecaj devoj, punaj povoj rilate al GPAI). Traktu la precizajn datojn kiel moviĝantan celon kaj konfirmu kontraŭ primaraj EU-fontoj. Sed la direkto de la vojaĝo estas klara, kaj inventaro estas la antaŭkondiĉo por ĉio.
Kiel konstrui kaj konservi AI-stokregistron
Krei stokregistron malpli temas pri unufoja revizio kaj pli pri establado de kontinua procezo, ĉar AI-aktivaĵoj konstante ŝanĝiĝas: novaj modeloj adoptitaj, novaj agentoj deplojitaj, novaj MCP-serviloj agorditaj, ofte sen aprobo.
Praktika aliro:
- Malkovru aŭtomate tra kodo, konstruo kaj nubo. Manaj kalkultabeloj malfreŝiĝas post kelkaj tagoj. Malkovro devas funkcii kontinue kaj atingi la SDLC, ne nur rultempo.
- Klasifiki kaj mapi rilatojn. Rekordtipo, loko, deveno kaj, grave, kiel ĉiu aktivaĵo konektas al aliaj kaj al sekretoj.
- Poentara risko en kunteksto. Plata listo de centoj da trovoj helpas neniun; prioritatigu laŭ tio, kio estas efektive atingebla, ekspluatebla kaj komerce kritika.
- Asigni proprieton. Ĉiu havaĵo bezonas respondecan posedanton.
- Konservu ĝin aktiva kaj eksportebla. Konservu ĝin kiel kontinuan inventaron, kiu povas produkti AI-BOM laŭpete.
Kion serĉi en AI-stokregistro-programaro
Se vi taksas ilojn, jen la kapabloj, kiuj distingas aŭtentan AI-stokprogramaron de statika listo:
- Komprenas AI-specifajn aktivaĵtipojn (modeloj, agentoj, MCP-serviloj, datumaroj), ne nur pakaĵoj kaj bibliotekoj.
- Atingas en la SDLC, malkovrante AI-on en kodo kaj sur finpunktoj de programistoj, ne nur en la nubo.
- Mapoj rilatoj, ne nur individuaj aktivaĵoj, do risko estas videbla en kunteksto.
- Poentaroj riskas je AI-specifaj atakvektoroj (tuja injekto, nesekura MCP, troa agado), ne nur la severeco de CVE.
- Kuras senĉese, kaptante novan AI-on kiam ĝi aperas.
- Produktas revizio-pretan AI-BOM kiu kontentigas kaj revizorojn kaj enterprise akiro.
- Ligas inventaron al devigo, por ke vi povu agi laŭ tio, kion vi trovas.
De stokregistro al ago: sekurigante tion, kion vi trovas
Malkovro estas la unua paŝo; la dua estas kompreni, kiuj aktivaĵoj portas realan riskon, ĉar la plej multaj ne portas. La celo estas transiri de miloj da krudaj trovoj al la manpleno, kiuj efektive povas kompromiti sistemojn, datumojn aŭ operaciojn: tiuj, kiuj estas aktive uzataj, akceptas nefidindan enigaĵon, estas realisme ekspluateblaj, havas sentemajn alirojn, kaj influas produktadon aŭ reguligitajn aktivaĵojn.
Jen kie AI Sekureca Pozo-Administrado (AI-SPM) kolektas: prenas la inventaron, taksas riskon laŭ la vojo de la AI-atako, mapas ĝin al reguligo, kaj produktas la AI-BOM. Ĝi ankaŭ estas kie la inventaro renkontas devigon: blokas malicajn dependecojn antaŭ ol ili instaliĝas, malakceptas neaprobitajn MCP-servilojn kaj modelojn, kaj enhavas kompromititajn finpunktojn antaŭ ol okazaĵo disvastiĝas.
At Ksgeni, jen la modelo, al kiu ni konstruas: kontinua AI-stokregistro kaj AI-BOM per AI-SPM, detekto de malica programaro, kiu kaptas malicajn pakaĵojn antaŭ ol subskribo ekzistas (MEW, Frua Averto pri Malica Programaro), kaj devigo de politikoj ĉe la finpunkto de programistoj per Xygeni Shield. Detekto estas akordigita kun la OWASP Supraj 10 por LLM Aplikaĵoj, la OWASP Supraj 10 por Agentaj Aplikaĵoj kaj la OWASP MCP Supraj 10. Sed kian ajn aliron vi elektas, la principo validas: vi ne povas sekurigi tion, kion vi ne povas vidi, kaj AI-stokregistro estas kie komeniĝas videbleco.
FAQs
Kiel AI-BOM diferencas de SBOM?
An SBOM katalogas malfermfontajn kaj triapartajn programarajn dependecojn, poentitajn laŭ la severeco de CVE. AI-BOM katalogas AI-specifajn aktivaĵojn (modelojn, agentojn, MCP-servilojn, datumarojn) kun AI-specifa riskopoentado kaj reguliga mapado. Dum AI disvastiĝas tra la SDLC, la AI-BOM fariĝas tiel fundamenta kiel la SBOM.
Kio estas ombra AI kaj kiel mi malkovras ĝin?
Ombra AI estas ajna AI adoptita sen formala aprobo aŭ regado: ebligita kunpiloto, loka MCP-servilo, modelo prenita de publika nabo. Vi malkovras ĝin per kontinua aŭtomatigita inventaro kiu atingas kodon, konstruon pipelineoj kaj programistaj finpunktoj, ne nur la produktada nubo kie plej multe da ombra AI neniam aperas.
Ĉu la EU-Leĝo pri AI postulas AI-inventaron?
La EU-Leĝo pri AI ne eksplicite nomas "AI-inventaron", sed ĝiaj dokumentaj, klasifikaj kaj registraj devoj por altriskaj sistemoj estas neeble plenumi sen ĝi. La samo validas por la NIST AI RMF (Map-funkcio, Govern 1.6) kaj ISO/IEC 42001, kiu postulas konservi inventaron de AI-sistemoj.
Kio estas AI-SPM?
Administrado de Sekureca Pozo de AI (AI-SPM) estas la praktiko de kontinua malkovro de AI-aktivaĵoj, poentado de ilia risko laŭlonge de la AI-atakvojo, mapado de ili al reguligo, kaj produktado de AI-BOM. Ĝi etendas pensadon pri administrado de pozo (konatan de CSPM kaj DSPM) al AI-specifaj aktivaĵoj kaj atakvektoroj.
Kiom ofte oni devus ĝisdatigi AI-stokregistron?
Kontinue. AI-aktivaĵoj ŝanĝiĝas ĉiutage dum teamoj adoptas novajn modelojn, deplojas novajn agentojn kaj agordas novajn MCP-servilojn, kutime sen formala aprobo. Skanado de specifa tempo malaktualiĝas post kelkaj tagoj, do efika AI-stokregistro-programaro funkcias kiel daŭra procezo anstataŭ unufoja revizio.
Kiel mi inventaras artefaritan inteligentecon uzatan en fontkodo?
Inventari AI en kodo signifas detekti AI-modelojn kaj bibliotekojn enigitajn kiel dependecojn, AI-kodajn asistantojn agorditajn laŭ programisto, kaj MCP-servilojn aŭ reguldosierojn funkciantajn loke. Tio postulas malkovron, kiu funkcias ene de la SDLC (deponejoj, konstruo pipelines kaj programistaj finpunktoj) anstataŭ nur en nubaj konzoloj.
