Galdetu segurtasun-buru bati zenbat IA tresna ari diren enpresako datuak ukitzen une honetan, eta zenbaki fidagarria lortuko duzu. Okerra izango da, eta ez inork ezer ezkutatzen duelako. Itzaleko IA gehienek ez dute ezer aurkitzen uzten: ez instalaziorik, ez lizentziarik, ez lerro-elementurik. Arakatzailearen fitxa bat eta pertsonala... login nahikoa dira. Zure politikak estaltzen duen IAren eta zure erakundeak benetan erabiltzen duen IAren arteko aldea da itzaleko IAren arriskua bultzatzen duena, eta IT oin-ohar batetik AppSec-eko kategoria azkarrenetako bat bihurtu da. Gida honek itzaleko IA praktikan nola detektatu eta ezabatu azaltzen du, auditoria amaitutakoan irauten duten detekzio-seinaleekin eta gobernantza-urratsekin.
Itzaleko IA arriskua paragrafo batean
Itzal-AIa zure erakundearen barruan segurtasun edo IT berrikuspenik gabe funtzionatzen duen edozein AI tresna, eredu, agente edo API dei da. IT itzalaren ondorengo zuzena da, baina zailagoa da harrapatzen: IT itzalak normalean erosketa-erregistro bat edo sare-sinadura bat uzten zuen CASB batek alderatu zezakeen. AI itzalak askotan ez bata ez bestea uzten. Langile batek kontratu bat itsasten du kontu pertsonal batekin saioa hasitako chatbot batean, edo garatzaile batek modelo-hornitzaile batetik API gako bat zuzenean script batera transferitzen du, eta horrek ez du saltzaileen inbentariorik ukitzen. Bi zifra independentek erakusten dute zenbat pilatu den AI itzalaren arrisku: langileen % 80k erabiltzen dituzte beren erakundeak onartu ez dituen AI tresnak, Unseen Security-ren 2026ko AI itzalaren egoeraren txostenaren arabera, eta erakundeen % 86k diote ez dutela ikusgarritasunik datuak nola isurtzen diren erabiltzen ari diren AI tresnetara eta horietatik.
Zergatik itzaleko AI arriskua itzaleko ITa gainditu zuen
Hiru aldaketa azaltzen dute zergatik itzaleko IAren arriskua itzaleko IT harrapatzeko eraikitako gobernantza baino azkarrago mugitu zen, eta horietako bat ere ez da itzulgarria.
- IA-k instalazio behar izateari utzi zion. IT itzala (SaaS baimenik gabekoa, arakatzaile-luzapen gaiztoak) definitu zuten tresnek frogak utzi zituzten aktiboen inbentario batean. Arakatzailearen fitxa batean irekitako IA laguntzaile batek edo txartel pertsonal batekin deitutako modelo API batek ez dute ezer uzten amaierako puntuen monitorizaziorako edo erosketarako markatu ahal izateko.
- Adimen artifiziala dagoeneko onartu dituzun tresnen barruan mugitu da. Copilot estiloko funtzioak orain baimendutako zerrendan dauden plataformetan txertatuta datoz. Plataforma berrikusi egin da. IA gaitasuna isilean piztu da barruan, baina normalean ez da horrela egiten.
- Bolumena gizakiak eragindako eskalatik makinaren eskalara igaro zen. Zscalerren ThreatLabz taldeak 536.5 milioi adimen artifizial eta ikaskuntza automatikoko transakzio aztertu ditu. bere hodeian zehar eta urte arteko % 3,464.6ko igoera erregistratu zuen enterprise AI/ML trafikoa. Aldaketa-eskala horixe da, hain zuzen ere, duela urtebete egindako itzaleko AI arriskuen ebaluazioa zaharkituta egotearen arrazoia, eta uneko auditoriak hilero okerrera egiten duen arazo baten ondorioz galtzen jarraitzearen arrazoia.
Non ezkutatzen den itzal-IA
IT tresnekin itzaleko IA arriskua bilatzen duten segurtasun taldeek normalean zerrenda osatugabea izaten dute, ezkutalekuak desberdinak direlako:
- Amaierako punturik gabeko arakatzailean oinarritutako tresnak. Adimen artifiziala fitxa batean exekutatzen da erabat. Ez dago detektatu beharreko agenterik, ez dago instalatu beharreko ezer.
- Baimendutako plataformetan txertatutako IA ezaugarriak. Plataforma berrikusi zen. Geroago bertan zetorren IA funtzioa, normalean, ez zen berrikusi.
- APIaren erabilera pertsonalki gastua. Garatzaile batek API eredu bat txartel pertsonal batean jartzen du eta zuzenean kodetik deitzen du. Ez da inoiz erosketa-gunera iristen, beraz, ez da inoiz inbentariora iristen.
- Berrikusi gabeko agenteen argibideak eta trebetasun fitxategiak. Agentzien kodeketa tresnek gero eta gehiago jarraitzen dituzte biltegi batean zuzenean idatzitako argibideak (trebetasun fitxategiak, agenteen arauak), eta fitxategi horiek agente bat inork saioa hasi ez duen modelo, datu-multzo edo MCP zerbitzari batera konekta dezakete.
Nola detektatu eta ezabatu itzal-IA
Itzal-AI nola detektatu eta ezabatu jakiteak esan nahi du elkarrekin exekutatu behar diren bi arazo bereizi gisa tratatzea: dagoeneko hor dagoena aurkitzea eta kudeatu gabe itzultzen ez dela ziurtatzea.
Detektatu: elkarrekin lan egiten duten hiru seinale
Eskaneatze bakar batek ez du IAren itzal-arrisku guztia aurkitzen, gaineko ezkutaleku bakoitzak arrasto desberdina uzten duelako.
- Sarearen eta proxyaren erregistroak. Zure suebakiak, proxyak eta DNS erregistroek dagoeneko IA hornitzaileen amaiera-puntuetara egindako deiak erregistratzen dituzte, tresna onartu den ala ez. Ostalari bakar batetik maiztasun handiko API deiak, irteerako karga handiak edo ordutegietatik kanpoko amaiera-puntu batera egindako trafiko automatizatua dira aztertzeko moduko ereduak.
- Identitate eta sarbide seinaleak. Sareko erregistroek tresna bat erabiltzen ari dela esaten dizute; zure identitate-hornitzaileak nor dagoen atzean eta zenbat sarbide eman duen esaten dizu. Adi egon berrikusi gabeko IA aplikazioei OAuth baimenak, IA tresnetan saioa hasteko kontu pertsonalak (enpresa kontuak baino) eta inork azaldu ezin duen zerbitzu-kontuaren API jarduera.
- Aktiboen eta kode mailako aurkikuntza. Hau da geruza. standard itzal-IT tresnek huts egiten dute, eta IA softwarean nola agertzen den zehatza da: modeloak, datu-multzoak, inferentzia-amaiera-puntuak, agenteak, MCP zerbitzariak eta biltegietan zuzenean erreferentziatutako IA kodetze-tresnak, pipelines eta trebetasun fitxategiak, ez bakarrik arakatzailearen trafikoan. Geruza hau gabe, ikus dezakezu duen API eredu bat deitu da; ezin duzu ikusi zein agenteak deitu zion, hemendik zein pipeline, edo zeri lotuta dagoen, hau da, zehazki non itzaleko IA arriskua hornidura-kateko gertakari bihurtzen da politika-urraketa baten ordez.
Ezabatu: itsatsita mantentzeko lau urrats
Detekzioak dagoeneko martxan dagoena esaten dizu. Hori iraunkor bihurtzeak lau urrats behar ditu, begizta gisa exekutatu beharrean auditoria bakar baten ordez, itzaleko IA arriskua urteko edozein berrikuspenek jarrai dezakeena baino azkarrago aldatzen baita.
- Egin inbentario bat, ez hiru. Aktibo tradizionalak (berreskuratzeak, pipelines, edukiontziak) eta IA aktiboek (ereduak, datu-multzoak, agenteak, MCP zerbitzariak, kodeketa tresnak) ikuspegi berean bizi behar dute, haien arteko harremanak mapatuta. Bere kabuz kaltegabea dirudien IA tresna bat benetako arriskua izan daiteke, zein datu-multzok elikatzen duen eta zein amaiera-punturekin komunikatzen den ikusten duzunean.
- Sailkatu politika idatzi aurretik. "IA tresnetan datu sentikorrak" debekatzen dituen arau batek ez du ezer esan nahi inork ezin badu zein datu garrantzitsuak esan. Jakin non dauden datu arautuak eta konfidentzialak, eta utzi sailkapen horrek erabakitzen zein IA erabilera kasu diren onak eta zeinek ez duten inoiz eraikinetik irteten.
- Eman taldeei bide onartu azkarrago bat, ez debeku-zerrenda luzeago bat. Jendeak itzaleko AIra jotzen du, onartutako aukera aurrean duten fitxa baino motelagoa delako. Onartutako modelo eta agenteen katalogo gobernatu batek, garatzaileengandik bereizitako kredentzialak dituenak, politika saihesteko arrazoia kentzen du.
- Arriskua benetan gertatzen den lekuan betearazi: instalazioan eta deian. Dokumentu batean modelo bat blokeatzeak ez dio agenteari hura instalatzea eragozten. Betearazpena pakete bat instalatzen den edo API bat deitzen den puntuan egon behar da, blokeatutako ekintza batek automatikoki huts egiten badu, norbaitek araua gogoratzearen mende egon beharrean.
Zer esan nahi du itzaleko IA arriskuak AppSec-entzat, ez bakarrik ITrentzat
Itzal-IAren gidalerro gehienek datu-galera prebenitzeko arazo gisa soilik tratatzen dute hau, eta DLP arazo horren zati legitimo bat da. Baina itzal-IAren arriskuaren zati gero eta handiagoa ez da arakatzaile batean agertzen: agente batek instalatzen saiatu den pakete haluzinatu gisa, inork egiaztatu ez duen MCP zerbitzari gisa edo inoiz ukitzeko baimenik ez duen biltegi baterako sarbide iraunkorra duen kodetze-laguntzaile gisa agertzen da. Hori ez da IA etiketa duen itzal-IT. Softwarearen hornikuntza-katearen arriskuaren kategoria berri bat da, eta AppSec-ek beste edozein mendekotasuni aplikatzen dion diziplina bera behar du: jakin zer dagoen, egiaztatu eta egiaztapena automatizatu, garatzaile guztiek egiaztatzea gogoratzea espero beharrean.
Utzi kalkulu-orri batetik IA gobernatzeari
Hutsune hori ez da ahalegina; ikusgarritasuna baizik: talde gehienek ez dute toki bakar bat non IA aktiboak, kodea eta pipelines elkarrekin agertzen dira, eta horixe da, hain zuzen ere, "itzaleko IA politika bat dugu" eta "benetan betearazi dezakegula" arteko distantzia.
Hori da arazoa. Xigenoa AI Segurtasuna honen inguruan eraikitzen da. AI Inventory-k etengabe eta automatikoki aurkitzen ditu zure biltegietako AI aktibo guztiak, pipelines eta garatzaile inguruneak: modeloak, esparruak, datu-multzoak, inferentzia-amaiera-puntuak, agenteak, MCP zerbitzariak eta Copilot, Cursor edo Claude Code bezalako AI kodetze tresnak, eskaneatze bakoitzean sortutako AI-BOM batekin erlazio-grafo gisa mapatuta. DevAI ingurune berdinetan babes-hesi aktibo gisa exekutatzen da, trebetasun-fitxategiak eta agenteen argibideak balioztatuz eta agente batek jardun aurretik instalazio gaiztoak blokeatuz, ez da beharrezkoa abisurik ematea. Eta zeren eta CoreAI Xygeniren beraren eskanerren aurkikuntzei IA bidezko korrelazio eta gobernantza bera aplikatzen die, itzaleko IA arriskua ez da beste tresna deskonektatu batean desagertzen: zure gainerako guztiaren arrisku-ikuspegi berean erortzen da. SDLC.
Doan hasi. Sign up with GitHub, GitLab edo Google-rekin harremanetan jar zaitezke eta hilean 25 biltegi eta 50 IA eskaneatu arteko ikusgarritasuna lortu doan eta kreditu txartelik gabe.
ohiko galderak
Zer da itzaleko IAren arriskua, hitz arruntetan esanda?
IA itzalaren arriskua erakunde baten barruan segurtasun-berrikuspenik gabe exekutatzen diren IA tresnek, ereduek, agenteek edo API deiek sortutako esposizioa da. Gehienetan ez da instalaziorik edo erosketa-erregistrorik uzten, beraz, arriskua isilik areagotzen da norbaitek nahita bilatzen duen arte.
Nola detektatu eta ezabatzen duzu itzaleko IA praktikan?
Detekzioa elkarrekin lan egiten duten hiru seinaletan oinarritzen da (sare eta proxy erregistroak, identitate eta sarbide seinaleak eta kodea/pipelinemailako aktiboen aurkikuntza), eta ezabatzea lau urratseko begizta bat da: inbentario bateratu bat eraiki, datuak sailkatu politika idatzi aurretik, taldeei bide onartu azkarrago bat eman eta instalazio puntuan edo API deian betearazi, dokumentu batean baino.
Itzaleko AI eta itzaleko IT berdinak al dira?
Erlazionatuta, ez berdinak. Shadow IT-k normalean arrasto bat uzten zuen (instalazio bat, lizentzia bat, sareko sinadura bat). Shadow AI-k askotan ez du horrelakorik uzten: arakatzailearen fitxa bat eta pertsonal bat. login nahikoak dira, eta AI funtzioak orain dagoeneko onartutako plataformetan txertatuta datoz.
CASB edo DLP tresna batek bere kabuz detekta al dezake itzaleko AI arriskua?
Partzialki bakarrik. Tresna horiek aztarna duen baimenik gabeko softwarea harrapatzeko eraiki ziren. Kodetik zuzenean deitutako eredu batek edo plataforma onartu baten barruan aktibatutako IA funtzio batek ez du CASB batek markatzeko sintonizatuta dagoen seinalerik sortzen. Itzal IAren arriskua guztiz kudeatzeko identitatea, sarea eta kodea/pipeline-ikusgarritasun mailakatua elkarrekin.
Non agertzen da itzaleko AI gehien software garapenean, zehazki?
Nabigatzailean oinarritutako txatbot-ez gain, iturburu-kodean gogor kodetutako API gako gisa, segurtasun-eskaneatu gabe proiektu batera sartutako kode irekiko eredu gisa eta berrikuspenik gabe biltegi batera gehitutako agenteen trebetasun-fitxategi edo MCP zerbitzari-konexio gisa agertzen da, hain zuzen ere itzal-IT tresna generikoek ikuskatzen ez duten geruza gisa.
