Kontrole za AI automatizacije koje nastaju van razvoja
Zaposleni sve češće grade AI aplikacije, agente i automatizacije za rad sa poslovnim sistemima, dok Tines upozorava da takva „divlja“ rešenja mogu postati operativna zavisnost pre nego što ih bezbednosni tim uoči. Ključni rizici nisu ograničeni na propuste u generisanom kodu: obuhvataju preširoka ovlašćenja, izlaganje osetljivih podataka, neželjene radnje, napuštene pristupe i praznine u istrazi incidenata.
Primer može biti tok rada koji usmerava prodajne upite, čita evidenciju kupaca, sažima zahteve i objavljuje rezultat na zajedničkom kanalu. Takav proces štedi vreme, ali otvara pitanja o identitetu pod kojim se izvršava, obimu pristupa zapisima, publici koja vidi izlaz i mogućnosti da se rad zaustavi kada dođe do neželjenog otkrivanja podataka.
Zašto same smernice nisu dovoljne
Politike i obuke postavljaju očekivanja, ali ne mogu same da spreče nesigurnu vezu sa sistemom niti neodobrenu radnju. Zaposleni koji prave automatizaciju ne moraju prepoznati trenutak u kojem jednostavan zadatak počinje da obrađuje osetljive podatke ili poprima svojstva produkcionog softvera. Rokovi i složen odobreni postupak dodatno podstiču zaobilaženje pravila.
Izolovana okruženja korisna su za proveru upita, modela i generisanog koda, ali ne rešavaju radne uslove kada prototip dobije pristup stvarnim poslovnim sistemima. Brad Rumph, terenski CTO kompanije Tines, sažima problem tvrdnjom da sandbox rešava pitanje dizajna, dok pitanje rada u izvršavanju ostavlja otvorenim. Uspešan test ne određuje automatski koje podatke produkcioni tok sme da koristi niti koje radnje sme da obavlja.
Upravljački odbori mogu utvrditi odgovornost i proceniti visokorizične slučajeve, ali njihov ritam pregleda ne mora pratiti brzinu kojom zaposleni stvaraju i uvode nova rešenja. Problem nije nužno u kvalitetu takvog odbora, već u oslanjanju na to da će svaki novi tok rada postati vidljiv pre nego što dobije poslovnu vrednost.
Kontrole ugrađene u radno okruženje
Održiviji pristup je da bezbednosni timovi, IT i vlasnici sistema unapred utvrde granice u samom okruženju za izradu i izvršavanje. Pre povezivanja poslovnih sistema treba definisati dozvoljene izvore podataka, radnje i pristupe, a te kontrole moraju ostati aktivne i nakon puštanja automatizacije u rad. Dozvole treba da prate konkretan zadatak toka rada, a ne puna prava njegovog autora.
Za radnje sa većim posledicama potrebno je, kada je primereno, zadržati ljudsko odobrenje. Uputstvo u promptu agentu da nešto ne radi nije kontrola pristupa. Stvaranje rešenja, njegovo izvršavanje i nadzor treba povezati tako da odobrena aplikacija ne postane nevidljiva čim počne da se koristi.
Vidljivost, vlasništvo i mogućnost intervencije
Upravljano okruženje treba da omogući jasne odgovore: ko je vlasnik toka rada, pod kojim identitetom se izvršava, šta može da čita, menja ili šalje drugim sistemima i gde se sprovodi odobrenje. Korisno je da se kredencijali unose tokom izvršavanja, umesto da budu izloženi u kodu, uz dozvole ograničene na potreban obim.
Bezbednosni tim mora moći da utvrdi šta je pokrenuto, čemu je pristupano i šta je promenjeno, pri čemu evidencija ne treba nepotrebno da beleži osetljive podatke. Pre nego što tok rada postane oslonac poslovnog procesa, treba utvrditi ko može da ga pauzira, kako se opoziva pristup i kako se proverava njegov uticaj.
Poslovni zaključak je jasan: AI automatizacijama treba dati brz i upotrebljiv put do rada, ali uz imenovanog vlasnika, najmanja potrebna prava, proverljiv trag aktivnosti i unapred definisanu intervenciju. Tako bezbednost ne preuzima održavanje svakog zaposleničkog rešenja, već postavlja granice koje se mogu dosledno sprovesti.