An Imbentaryo ng AI ay isang patuloy na ina-update na katalogo ng bawat asset ng AI na tumatakbo sa iyong organisasyon — mga modelo, mga endpoint na pinapagana ng AI, mga dataset, mga AI coding assistant, mga MCP server at mga AI dependency — kasama ang mga ugnayan, panganib at mga may-ari na nag-uugnay sa kanila. Sa konteksto ng seguridad, wala itong kinalaman sa pamamahala ng imbentaryo ng bodega o stock; dito, "Imbentaryo ng AI" nangangahulugan lamang ito ng eksaktong pag-alam kung anong AI ang iyong pinapatakbo, kung saan ito umiiral, at kung ano ang maaari nitong maabot.
Habang kumakalat ang AI sa bawat yugto ng pagbuo ng software, mula sa pagbuo ng code sa IDE hanggang sa mga autonomous agent na kumikilos sa loob CI/CD pipelines, ang tanong ay hindi na kung mayroon nang AI sa iyong kapaligiran. Nasa kung makikita mo ba ito. Ipinapaliwanag ng gabay na ito kung ano ang isang imbentaryo ng AI, kung paano ito nauugnay sa isang AI-BOM at isang SBOM, bakit anino AI ay naging isang problema sa seguridad, at kung paano nauugnay ang kasanayan sa EU AI Act, NIST AI RMF at ISO / IEC 42001.
Key takeaways
- Inililista ng isang imbentaryo ng AI ang bawat modelo, dataset, ahente, MCP server at AI coding tool sa buong lifecycle ng iyong software, hindi lamang ang mga inaprubahan ng IT.
- Shadow AI, ang AI na pinagtibay nang walang pamamahala, ay karaniwan na ngayon, hindi ang eksepsiyon: sa isang survey noong 2026 sa mga pinuno ng seguridad, tanging 19% ng mga organisasyon ang nag-ulat ng ganap na kakayahang makita kung saan at paano ginagamit ang AI.
- An AI-BOM (Kathang-isip ng mga Materyales ng AI) ay ang output na handa nang i-audit ng isang imbentaryo ng AI: ang kahalili ng panahon ng AI sa SBOM.
- Paparating na ang regulasyon. Ang EU AI Act, NIST AI RMF at ISO/IEC 42001 ay epektibong nag-aatas sa iyo na malaman kung anong AI ang iyong pinapatakbo.
- Ang imbentaryo ay panimulang punto lamang; ang halaga ay nagmumula sa pagmamarka ng panganib at pagkilos batay sa maliit na bilang ng mga asset na tunay na mahalaga.
Ano ang imbentaryo ng AI?
Ang imbentaryo ng AI ay ang kasanayan sa pagtuklas, pag-katalogo, at patuloy na pagsubaybay sa bawat asset ng AI na tumatakbo sa buong lifecycle ng iyong software development, at ang mga panganib na kaakibat ng bawat isa. Ang kumpletong imbentaryo ay sumasagot sa tatlong tanong para sa bawat asset: ano ito, saan ito tumatakbo, at ano ang maaari nitong ma-access?
Mas malawak ang saklaw na iyan kaysa sa inaasahan ng karamihan sa mga koponan. Dapat saklawin ng isang makabuluhang imbentaryo ng AI ang:
- Modellen: bawat malaking modelo ng wika at modelo ng pundasyon na ginagamit sa pag-develop at produksyon, na may kumpiyansa sa bersyon, lokasyon, at pagtuklas.
- Mga Dataset: datos ng pagsasanay, mga dataset ng pagkuha at mga imbakan ng vector, kabilang ang pagkakalantad sa nakalalasong konteksto at pagtagas ng datos.
- Ahente: mga autonomous system na nagsasagawa ng mga aksyon sa iyong kapaligiran, tulad ng pagbubukas pull requests, pag-install ng mga dependency, o paghawak sa imprastraktura.
- Mga MCP server: Model Context Protocol mga server na nagkokonekta sa mga AI assistant sa mga panlabas na tool, API, at mga mapagkukunan ng data.
- Mga tool at katulong sa AI coding: mga copilot at IDE integration na bumubuo ng code, magmungkahi ng mga dependency at makipag-ugnayan sa mga repository.
- AI frameworks: LangChain, LangGraph, mga agent server at iba pang mga orchestration layer na nagkokonekta ng mga modelo sa mga tool at data.
- Mga ugnayan sa pagitan ng mga asset: ang mga koneksyon sa pagitan ng mga modelo, ahente, server, dataset at mga sikretong nakatali sa mga ito. Ang isang graph ng relasyon ay nagpapakita ng panganib sa konteksto, hindi bilang isang patag na listahan.
Imbentaryo ng AI vs Imbentaryo ng asset ng AI vs AI-BOM, at paano sila naiiba sa isang SBOM
Ang mga terminong ito ay ginagamit nang maluwag, kaya nakakatulong na maging handacise. Ang "AI inventory" at "AI asset inventory" ay naglalarawan ng parehong bagay: ang buhay na katalogo ng mga asset ng AI at ang kanilang mga panganib. Isang Ang AI-BOM ay ang artifact na maaaring i-export na nalilikha ng imbentaryo.: isang mababasa ng makinang talaan ng mga materyales na maaari mong ibigay sa isang auditor o isang enterprise mamimili.
Ang pinakamalinis na paraan upang maunawaan ang AI-BOM ay sa pamamagitan ng pagkakatulad sa SBOM:
Habang ang AI ay nakakabit sa buong SDLC, ang AI-BOM ay nagiging kasing-pundamental ng SBOM, at ang mga pinuno ng seguridad ay parami nang parami ang natatanggap na mga kahilingan mula sa mga auditor at enterprise mga pangkat ng pagkuha para mismo sa artifact na ito.
Bakit mahalaga ang imbentaryo ng AI ngayon
Tatlong puwersa ang nagpabago sa imbentaryo ng AI mula sa isang bagay na "maganda" tungo sa isang prayoridad.
- Una, ang AI ay nagsusulat ng mga hindi secure na code sa malawakang saklaw. Patuloy na natutuklasan ng independiyenteng pananaliksik na ang malaking bahagi ng AI-generated code ay may mga kahinaan. Ang orihinal na pag-aaral ng NYU/Copilot nina Pearce et al. ay natagpuan ang humigit-kumulang 40% ng mga nabuong programa ay naglalaman ng mga kahinaan sa seguridad, at mas kamakailang malawakang mga punto ng pagsubok sa parehong paraan: Ang pagsusuri ng Veracode noong 2025 sa mahigit 100 modelo ay natagpuan lamang 55% ng code na nabuo ng AI ay ligtasKung hindi mo alam kung aling mga assistant ang bumubuo ng code sa iyong pipelines, hindi mo maaaring pamahalaan ang panganib na iyan.
- Pangalawa, ang supply chain ng software ay naging isang larangan ng pag-atake ng AI. Noong Setyembre 2025, Shai Hulud, ang unang self-propagating npm worm, ay ginawang mekanismo ng pamamahagi ang mga developer machine, na kumakalat sa daan-daang pakete. Noong Marso 2026, nakompromiso ng mga attacker mga axios, isang pakete na may humigit-kumulang 100 milyong lingguhang pag-download, naglalathala ng mga bersyong may poisoning na naghulog ng isang remote-access trojan. Ang mga pag-atakeng tulad nito ay napupunta sa eksaktong layer sa pagitan ng tradisyonal na AppSec at endpoint tooling: ang layer na kung saan ginawa ang isang AI inventory para magbigay-liwanag.
- Pangatlo, ang mga sikreto at kredensyal ay tumutulo sa pamamagitan ng AI. Iniulat ng GitGuardian's State of Secrets Sprawl 2026 na Ang mga paglabas ng mga sikreto ng serbisyo ng AI ay tumaas ng 81% taon-taon, at ang tinutulungan ng AI commits leak secrets sa halos doble ng baseline rate. Ang bawat undocumented na modelo, ahente o MCP server ay isang potensyal na landas patungo sa isang kredensyal.
Ang tradisyunal na AppSec ay humihinto sa repository at hindi nauunawaan kung ano ang isang modelo. Binabantayan ng mga endpoint tool ang operating system ngunit hindi nauunawaan ang mga package, MCP server o AI assistant. Ang puwang sa pagitan ng mga ito ang siyang naiipon na panganib ng AI, at ang imbentaryo ang unang hakbang upang maisara ito.
Kung saan nagtatago ang AI: Anino ng AI sa kabila ng SDLC
Shadow AI may anumang sistema ng AI na pinagtibay nang walang pormal na pag-apruba o pamamahala: ang copilot na pinagana ng isang developer noong nakaraang linggo, ang MCP server na tumatakbo sa isang laptop, ang modelo ay direktang hinila mula sa isang pampublikong hub patungo sa isang side project. Hindi ito isang edge case. Sa isang survey noong 2026 sa mahigit 400 na pinuno ng seguridad, tanging 19% ang nag-ulat ng ganap na kakayahang makita kung saan at paano ginagamit ang AI sa kanilang organisasyon, habang ang nakararaming bilang ay gumagamit na o sumusubok na sa paggamit ng mga AI coding assistant.
Ang pinakamahirap hanapin na shadow AI ay ang AI sa loob ng software lifecycle, dahil bihira itong lumitaw sa isang cloud console:
- Ang mga modelo at AI library ay kinuha sa mga repository bilang mga dependency.
- Mga AI coding assistant na naka-configure kada developer, kada IDE.
- Mga MCP server at rule file na lokal na tumatakbo sa mga developer endpoint.
- Tahimik na nagbubukas ang mga daloy ng trabaho ng ahente pull requests o pag-install ng mga pakete.
Kaya naman hindi sapat ang cloud-only discovery. Ang isang tunay na kumpletong imbentaryo ng AI ay kailangang umabot sa mga code at build environment (ang laptop ng developer, ang repository, ang pipeline), hindi lang ang production cloud.
Ano ang kabilang sa isang AI-BOM
Ang isang AI-BOM na handa sa pag-audit ay ginagawang isang bagay na mapapatunayan mo ang iyong imbentaryo. Dapat kasama rito ang:
- Bawat asset ng AI: mga modelo, dataset, ahente, MCP server, mga tool sa AI coding.
- Uri ng asset, lokasyon at kumpiyansa sa pagtuklas para sa bawat isa.
- Pinagmulan at mga dependency (kung saan nagmula ang modelo o component).
- Antas ng panganib bawat asset, batay sa mga vector ng pag-atake na partikular sa AI.
- Pagmamapa ng regulasyon sa EU AI Act, NIST AI RMF at ISO/IEC 42001.
- Isang format na nae-export at nababasa ng makina para sa mga auditor at customer.
Ang mga organisasyong maaaring bumuo ng AI-BOM on demand ay magkakaroon ng tunay na kalamangan sa pagsunod at tiwala habang tumatagal ang mga obligasyon sa AI audit.
Imbentaryo at pagsunod sa AI: EU AI Act, NIST AI RMF at ISO/IEC 42001
Wala sa mga pangunahing balangkas ang nagpapangalan sa "AI inventory" bilang isang line item, ngunit ang bawat isa ay epektibong imposibleng matugunan kung wala ito. Hindi mo maaaring idokumento, uriin, o pamahalaan ang mga sistemang AI na hindi mo nakikita.
Isang tala tungkol sa tiyempo: ang paglulunsad ng EU AI Act ay binago ng kasunduang "Digital Omnibus" noong Mayo 2026, na ipinagpaliban ang karamihan sa mga obligasyong may mataas na panganib sa Disyembre 2027, habang pinapanatiling buhay ang ilang mahahalagang pangyayari noong Agosto 2, 2026 (mga tungkulin sa transparency, mga kapangyarihan sa parusa ng GPAI). Ituring ang mga eksaktong petsa bilang isang target na gumagalaw at kumpirmahin laban sa mga pangunahing mapagkukunan ng EU. Ngunit malinaw ang direksyon ng paglalakbay, at ang imbentaryo ang kinakailangan para sa lahat ng ito.
Paano bumuo at magpanatili ng imbentaryo ng AI
Ang pagbuo ng imbentaryo ay hindi gaanong tungkol sa minsanang pag-audit kundi tungkol sa pagtatatag ng isang patuloy na proseso, dahil ang mga asset ng AI ay patuloy na nagbabago: mga bagong modelo na ginagamit, mga bagong ahente na inilalagay, mga bagong MCP server na na-configure, kadalasan nang walang pag-apruba.
Isang praktikal na diskarte:
- Awtomatikong tumuklas sa code, build, at cloud. Ang mga manu-manong spreadsheet ay nagiging lipas na sa loob ng ilang araw. Ang Discovery ay kailangang patuloy na tumakbo at maabot ang SDLC, hindi lang runtime.
- Pag-uri-uriin at imapa ang mga ugnayan. Uri ng rekord, lokasyon, pinagmulan at, mahalaga, kung paano nauugnay ang bawat asset sa iba at sa mga sikreto.
- Markahan ang panganib ayon sa konteksto. Ang isang patag na listahan ng daan-daang natuklasan ay hindi nakakatulong kaninuman; unahin ang mga bagay ayon sa kung ano ang talagang maabot, mapapakinabangan, at mahalaga sa negosyo.
- Magtalaga ng pagmamay-ari. Ang bawat asset ay nangangailangan ng isang may-ari na may pananagutan.
- Panatilihin itong buhay at maaaring i-export. Panatilihin ito bilang isang patuloy na imbentaryo na maaaring makagawa ng isang AI-BOM kapag hiniling.
Ano ang dapat hanapin sa software ng imbentaryo ng AI
Kung sinusuri mo ang mga kagamitan, narito ang mga kakayahan na naghihiwalay sa tunay na software ng imbentaryo ng AI mula sa isang static na listahan:
- Nauunawaan ang mga uri ng asset na partikular sa AI (mga modelo, ahente, mga MCP server, mga dataset), hindi lamang mga pakete at mga library.
- Umaabot sa SDLC, pagtuklas ng AI sa code at sa mga developer endpoint, hindi lamang sa cloud.
- Mga ugnayan sa mapa, hindi lamang mga indibidwal na asset, kaya ang panganib ay nakikita sa konteksto.
- Nag-iiskor ng panganib sa mga vector ng pag-atake na partikular sa AI (mabilis na iniksyon, hindi ligtas na MCP, labis na ahensya), hindi lamang ang kalubhaan ng CVE.
- Tuloy-tuloy na tumatakbo, nakakahuli ng bagong AI sa hitsura nito.
- Gumagawa ng isang AI-BOM na handa nang i-audit na nakakatugon sa parehong mga auditor at enterprise pagkuha.
- Nag-uugnay ng imbentaryo sa pagpapatupad, para makakilos ka batay sa iyong natuklasan.
Mula sa imbentaryo hanggang sa aksyon: pagsiguro sa iyong matutuklasan
Ang pagtuklas ang unang hakbang; ang pangalawa ay ang pag-unawa kung aling mga asset ang may tunay na panganib, dahil karamihan ay hindi. Ang layunin ay lumipat mula sa libu-libong hilaw na natuklasan patungo sa iilang maaaring aktwal na makompromiso ang mga sistema, datos o operasyon: iyong mga aktibong ginagamit, tumatanggap ng hindi mapagkakatiwalaang input, makatotohanang maaaring pagsamantalahan, may sensitibong access, at nakakaapekto sa produksyon o mga regulated na asset.
Dito matatagpuan ang Pamamahala ng Posture ng Seguridad ng AI (AI-SPM) kumukuha ng impormasyon: pagkuha ng imbentaryo, pagmamarka ng panganib sa landas ng pag-atake ng AI, pagmamapa nito sa regulasyon, at paggawa ng AI-BOM. Dito rin nagtatagpo ang imbentaryo at pagpapatupad ng batas: pagharang sa mga malisyosong dependency bago ang mga ito i-install, pagtanggi sa mga hindi aprubadong MCP server at modelo, at pagpigil sa mga nakompromisong endpoint bago kumalat ang isang insidente.
At Xygeni, ito ang modelong aming binubuo patungo sa: patuloy na imbentaryo ng AI at AI-BOM sa pamamagitan ng AI-SPM, pagtuklas ng malware na nakakahuli ng mga malisyosong pakete bago pa man magkaroon ng lagda (MEW, Maagang Babala sa Malware), at pagpapatupad ng patakaran sa endpoint ng developer sa pamamagitan ng Xygeni Shield. Ang pagtukoy ay nakahanay sa OWASP Top 10 para sa mga Aplikasyon ng LLM, ang OWASP Top 10 para sa mga Agentic Apps at ang OWASP MCP Top 10. Ngunit alinmang pamamaraan ang iyong piliin, ang prinsipyo ay nananatili: Hindi mo maaaring protektahan ang hindi mo nakikita, at ang imbentaryo ng AI ay kung saan nagsisimula ang kakayahang makita.
Mga Madalas Itanong
Paano naiiba ang isang AI-BOM sa isang SBOM?
An SBOM mga katalogo ng mga open-source at third-party na dependency ng software, na may marka batay sa kalubhaan ng CVE. Ang isang AI-BOM ay nag-catalog ng mga asset na partikular sa AI (mga modelo, ahente, MCP server, dataset) na may AI-specific risk scoring at regulatory mapping. Habang kumakalat ang AI sa buong SDLC, ang AI-BOM ay nagiging kasing-pundamental ng SBOM.
Ano ang shadow AI at paano ko ito matutuklasan?
Ang Shadow AI ay anumang AI na pinagtibay nang walang pormal na pag-apruba o pamamahala: isang pinaganang copilot, isang lokal na MCP server, isang modelo na kinuha mula sa isang pampublikong hub. Natutuklasan mo ito gamit ang patuloy na awtomatikong imbentaryo na umaabot sa code, build pipelinemga endpoint ng s at developer, hindi lang ang production cloud kung saan hindi lumalabas ang karamihan sa shadow AI.
Kinakailangan ba ng EU AI Act ang isang imbentaryo ng AI?
Hindi tahasang tinutukoy ng EU AI Act ang "AI inventory", ngunit ang mga tungkulin nito sa dokumentasyon, klasipikasyon, at pagpaparehistro para sa mga sistemang may mataas na panganib ay imposibleng matugunan kung wala ito. Totoo rin ito sa NIST AI RMF (Map function, Govern 1.6) at ISO/IEC 42001, na nangangailangan ng pagpapanatili ng imbentaryo ng mga sistema ng AI.
Ano ang AI-SPM?
Ang AI Security Posture Management (AI-SPM) ay ang kasanayan ng patuloy na pagtuklas ng mga asset ng AI, pagmamarka ng kanilang panganib sa landas ng pag-atake ng AI, pagmamapa ng mga ito sa regulasyon, at paggawa ng isang AI-BOM. Pinalalawak nito ang pag-iisip sa pamamahala ng postura (pamilyar sa CSPM at DSPM) sa mga asset at vector ng pag-atake na partikular sa AI.
Gaano kadalas dapat i-update ang imbentaryo ng AI?
Patuloy. Ang mga asset ng AI ay nagbabago araw-araw habang ang mga koponan ay gumagamit ng mga bagong modelo, nagde-deploy ng mga bagong ahente at nagko-configure ng mga bagong MCP server, kadalasan nang walang pormal na pag-apruba. Ang isang point-in-time scan ay nalulusaw sa loob ng ilang araw, kaya ang epektibong AI inventory software ay tumatakbo bilang isang patuloy na proseso sa halip na isang minsanang pag-audit.
Paano ko iimbentaryo ang AI na ginamit sa source code?
Ang pag-imbentaryo ng AI sa code ay nangangahulugan ng pag-detect ng mga modelo at library ng AI na nakuha bilang mga dependency, mga AI coding assistant na naka-configure bawat developer, at mga MCP server o rule file na tumatakbo nang lokal. Nangangailangan ito ng pagtuklas na gumagana sa loob ng SDLC (mga imbakan, bumuo pipelines at mga developer endpoint) sa halip na sa mga cloud console lamang.
