Kada kompanija uvede AI sistem, često se govori o „modelu“ kao da je on čitav proizvod. U stvarnosti, savremena AI aplikacija može da se sastoji od modela jedne kompanije, embedding modela druge, baze podataka treće, nekoliko API-ja, biblioteka otvorenog koda, skupa dokumenata za RAG, dodatnih bezbednosnih filtera i alata kojima agent pristupa spoljnim sistemima. Promena ili kompromitovanje samo jedne od tih komponenti može da utiče na ponašanje čitavog sistema.
Zbog toga se iz sveta klasične softverske bezbednosti u AI prenosi koncept Bill of Materials, odnosno popisa komponenti od kojih je sistem napravljen. Kod softvera već postoji SBOM – Software Bill of Materials, strukturisana evidencija biblioteka, paketa i drugih softverskih komponenti koje ulaze u proizvod. Njegova vrednost postaje očigledna kada se otkrije nova ranjivost: kompanija može da proveri gde koristi problematičnu komponentu umesto da ručno istražuje svaki sistem.
Kod veštačke inteligencije problem je širi. Nije dovoljno znati koje se softverske biblioteke koriste. Potrebno je znati koji model donosi odluke, odakle potiču podaci, koja verzija modela je aktivna, koje alate agent može da pozove i koji spoljni servisi učestvuju u izvršavanju zadatka. Odatle nastaje koncept AI Bill of Materials – AIBOM.
AI sistem nije samo model
Zamislimo kompanijskog asistenta koji odgovara zaposlenima na pitanja o internim procedurama. Na prvi pogled može izgledati da sistem koristi jedan veliki jezički model i nekoliko dokumenata. Iza korisničkog interfejsa, međutim, može postojati znatno složeniji lanac.
Pitanje se prvo obrađuje jednim modelom, zatim se pomoću embedding modela pretražuje vektorska baza, pronalaze se dokumenti iz internog skladišta i njihovi delovi ulaze u prompt. Glavni model generiše odgovor, dok drugi sistem proverava njegov sadržaj. Ako je u pitanju agent, može dodatno da pozove interni API, preuzme podatke iz CRM-a ili pokrene neku poslovnu operaciju.
Svaka od tih komponenti ima sopstvene rizike. Model može promeniti ponašanje nakon ažuriranja. Biblioteka može dobiti bezbednosnu ranjivost. Dokument u RAG bazi može biti zaražen zlonamernom prompt injection instrukcijom. API može promeniti način autentifikacije, a spoljni servis može prestati da bude dostupan.
Ako kompanija ne zna tačno od čega je njen AI sistem sastavljen, teško može brzo da utvrdi da li je pogođena kada se pojavi novi problem.
Šta bi AIBOM trebalo da sadrži?
Klasični SBOM uglavnom beleži naziv softverske komponente, verziju, proizvođača i međuzavisnosti. Kod AI sistema potrebno je više informacija.
Prvi sloj čine sami modeli. Potrebno je znati koji model se koristi, ko ga je napravio, koja verzija je aktivna i da li se izvršava lokalno ili preko spoljnog API-ja. Ako sistem koristi više modela – na primer jedan za generisanje, drugi za embeddings i treći za moderaciju – svaki od njih predstavlja zasebnu komponentu.
Drugi sloj čine podaci. To mogu biti skupovi korišćeni za dodatno treniranje ili fine-tuning, interni dokumenti dostupni kroz RAG, baze podataka iz kojih agent povlači informacije ili drugi izvori koji ulaze u kontekst modela. Poreklo i verzija tih podataka mogu biti jednako važni kao verzija softvera.
Treći sloj čine alati i servisi. Agent može imati pristup pretraživaču, terminalu, cloud platformi, imejlu, CRM-u ili sopstvenim poslovnim API-jima kompanije. AIBOM zato ne bi trebalo samo da kaže koji model postoji, već i sa čim taj model može da komunicira.
Na kraju dolaze klasične softverske komponente: biblioteke, framework-i, kontejneri, baze podataka i infrastruktura na kojoj se sve izvršava. Zbog toga AIBOM ne zamenjuje SBOM. On ga proširuje na elemente specifične za AI.
Šta se događa kada se promeni model?
Jedna od najvećih razlika između klasičnog softvera i AI servisa jeste to što kompanija ponekad ne kontroliše verziju ključne komponente.
Ako koristi model preko API-ja, proizvođač može da objavi novu verziju, povuče staru ili promeni određene karakteristike servisa. Sistem kompanije formalno ostaje isti – isti kod, isti interfejs i isti poslovni proces – ali njegovi rezultati mogu da se promene zato što se promenila komponenta koju ne kontroliše.
AIBOM bi u takvoj situaciji trebalo da omogući odgovor na jednostavno pitanje: koji naši sistemi zavise od ovog modela?
Bez centralne evidencije odgovor može zahtevati pretragu velikog broja aplikacija i razgovor sa različitim timovima. Sa dobro vođenim popisom moguće je odmah videti gde se određeni model koristi i proceniti koje sisteme treba ponovo testirati.
Isti problem postoji sa API-jima. Ako agent zavisi od spoljnog servisa koji promeni autentifikaciju, ograničenja ili format odgovora, posledice se mogu pojaviti u više poslovnih procesa istovremeno.
Podaci postaju deo supply chain-a
Kod AI sistema postoji još jedna komponenta koja u klasičnom softverskom supply chain-u nije imala istu ulogu: podaci.
Ako se u RAG sistem ubaci dokument sa netačnim informacijama, model može početi da ih koristi u odgovorima. Ako se u dokumentu nalazi indirect prompt injection, posledica može biti promena ponašanja agenta. Ako je skup podataka za fine-tuning kompromitovan, problem može biti ugrađen u sam model.
Zbog toga poreklo podataka postaje pitanje bezbednosti, a ne samo kvaliteta. Potrebno je znati ko je podatke uneo, odakle su došli, kada su promenjeni i koji sistemi ih koriste.
Ovaj problem je posebno izražen kada kompanije preuzimaju javne modele i skupove podataka sa platformi kao što je Hugging Face. Otvoreni ekosistem omogućava brzo eksperimentisanje, ali istovremeno uvodi zavisnost od velikog broja komponenti koje organizacija nije sama napravila.
AIBOM zato postaje i mapa poverenja: pokazuje koji delovi sistema potiču iz sopstvene infrastrukture, a koji dolaze od spoljnih dobavljača ili iz open-source zajednice.
Kada se otkrije ranjivost
Najjasnija praktična vrednost ovakvog popisa vidi se kada nešto pođe pogrešno.
Pretpostavimo da je otkrivena ozbiljna ranjivost u framework-u koji se koristi za povezivanje AI agenata sa spoljnim alatima. Bez evidencije kompanija prvo mora da utvrdi da li ga uopšte koristi, zatim u kojim aplikacijama, koja verzija je instalirana i kojim resursima ti sistemi imaju pristup.
Ako postoji AIBOM, taj proces može biti znatno brži. Pretragom se identifikuju svi sistemi koji sadrže problematičnu komponentu, njihovi vlasnici i povezani resursi. Bezbednosni tim tada može da odredi prioritete prema stvarnom riziku.
Isto važi ako problem nije klasična softverska ranjivost. Može se otkriti da određeni model ima ozbiljnu slabost na novu vrstu prompt injection napada, da je kompromitovan skup podataka ili da spoljni AI servis menja politiku čuvanja podataka. U svakom slučaju prvo pitanje ostaje isto: gde ga koristimo?
Popis nije dovoljan ako nije živ
Najveća opasnost AIBOM-a jeste da postane još jedan dokument koji se napravi prilikom pokretanja projekta i više nikada ne ažurira.
AI sistemi se menjaju veoma brzo. Tim može da zameni model, doda novi alat, poveže agent sa još jednim API-jem ili ubaci novu bazu dokumenata. Ako se te promene ne evidentiraju automatski ili kroz jasno definisan proces, popis vrlo brzo prestaje da odgovara stvarnom stanju.
Zato AIBOM ima smisla samo ako prati životni ciklus sistema. Promena modela, dodavanje datasource-a ili nove integracije trebalo bi da automatski ažurira evidenciju ili pokrene zahtev da se ona dopuni.
Poseban problem predstavljaju eksperimentalni AI alati koje timovi uvode bez centralne kontrole. Kompanija može imati dobro dokumentovane zvanične AI sisteme, dok zaposleni paralelno povezuju druge modele i agente sa poslovnim podacima. Takve komponente neće postojati ni u jednom popisu ako organizacija prvo nema način da ih otkrije.
Od liste komponenti do mape rizika
AIBOM sam po sebi ne čini AI sistem bezbednim. Činjenica da kompanija zna koji model ili biblioteku koristi ne sprečava ranjivost, prompt injection ili curenje podataka. Njegova vrednost je u tome što omogućava da se posledice problema brzo pronađu i ograniče.
To postaje sve važnije kako AI aplikacije prerastaju jednostavan odnos korisnika i jednog modela. Savremeni agent može da koristi više modela, desetine alata i veliki broj izvora podataka, dok se deo sistema nalazi kod različitih dobavljača.
U takvom okruženju pitanje „koji AI koristimo?“ više nema jednostavan odgovor. Mnogo korisnije pitanje glasi: od čega je naš AI sistem napravljen, od koga zavisi i šta će sve biti pogođeno ako jedna od tih komponenti zakaže?
AIBOM je pokušaj da odgovor na to pitanje postoji pre nego što se pojavi incident.
