IT agent koji djeluje, a ne (samo) savjetuje

Na blogu smo nedavno pisali o DARKU — agentu koji odgovara, citira i verificira. Ovaj članak govori o agentu koji radi. Kad sustav prestane samo odgovarati i počne mijenjati stanje, cijena greške mijenja se s „netočan savjet” na „pokvareno računalo”. To je kategorijski drukčiji problem — i kategorijski drukčije rješenje.

Prije nego uđemo u detalje, evo kratkog filma o samom principu. Traje 58 sekundi, ima naraciju na hrvatskom i nije snimka Anparovog agenta — prikazuje isti način rada na uredskom procesu koji većina tvrtki prepoznaje. Počinje u 8:15 ujutro, s četrdesetak nepročitanih poruka u pretincu, rokovima koji istječu danas i trima nacrtima ponuda koji čekaju da ih netko dovrši. Pitanje koje film postavlja glasi: što ako se taj posao obavi sam?

Drugi dio prati jedan konkretan upit od početka do kraja. Stiže mail klijenta — „Upit za ponudu — održavanje opreme”, s rokom do petka. Digitalni radnik ga preuzima, povuče cijene iz cjenika, usporedi ih s prošlim ponudama i složi nacrt: redovni servis opreme, 420,00 €. Nacrt pritom ne odlazi klijentu. Na ekranu stoji poruka da je ponuda spremna i da treba vaše odobrenje, s dva gumba — Odobri i Ispravi. Tek nakon klika kartica se mijenja u „Ponuda poslana”.

Zatim se vidi što se dogodi kad takvih radnika ima više: rokovi, mail, dokumenti, ponude, izvještaji i baza znanja tvrtke rade povezano, svaki na svom dijelu procesa. Iznad njih stoji popis pravila koja postavlja vlasnik posla — rutinske upite agent odgovara sam, ponude idu vama na potvrdu, a pravilo da bez vašeg odobrenja ništa ne šalje i ne potpisuje zaključano je i agent ga ne može promijeniti. Dan se na kraju svodi na kratak dnevnik — u 7:30 odgovoreno na dvanaest rutinskih upita — i na tri odluke umjesto trideset šest mailova: odobri ponudu, potvrdi rok, odgovori klijentu.

To je isti princip koji ostatak ovog članka opisuje na stvarnom projektu: zatvoren popis radnji koje je čovjek pročitao i odobrio, ljudski klik za sve što nosi rizik i autonomija koja se postupno zarađuje. U filmu je prikazan na ponudama i mailovima, u Anparu na IT podršci — tehnologija je ista, mijenja se sadržaj popisa. Film završava pitanjem kojim i mi počinjemo svaki razgovor: što vas u svakodnevnom poslu najviše opterećuje? Kako taj pristup primjenjujemo na vlastito poslovanje, javno je vidljivo u dokazu.

Problem koji ima svaka organizacija koja je razmišljala o automatizaciji

Anparo d.o.o. ima jednog čovjeka koji je cijeli IT odjel za petnaestak ljudi. Svaki zaglavljeni pisač znači fizički odlazak do stola ili ručno spajanje na daljinu. Prividni problem je resursne naravi. Stvarni problem je puno prenosiviji.

Vjerojatno i vi imate proces koji biste automatizirali — ali se bojite što bi sustav mogao krivo napraviti.

Knjigovodstvo bi rado automatiziralo knjiženje, ali ne dok postoji šansa da nešto proknjiži krivo. Odvjetnički ured bi rado automatizirao slanje podnesaka, ali ne dok postoji šansa da odu krivom sudu. Projektantski biro bi rado automatizirao izmjene, ali ne u živom projektu.

Kod alata koji samo odgovaraju najgori ishod je kriv savjet — neugodno, ali popravljivo. Kod alata koji djeluju najgori ishod je krivo izvršena radnja na tuđem računalu, u tuđem dokumentu, u tuđem sustavu. Pitanje zato nije „može li AI ovo napraviti” — može, i to danas. Pitanje je kako mu dati točno onoliko moći koliko posao traži, i ni gram više.

Što smo izgradili

Za Anparo smo izgradili internog IT agenta koji živi u Microsoft Teamsu. Zaposlenik napiše što mu ne radi — „printer ne printa”, „nemam mjesta na disku” — a agent dijagnosticira na tom računalu, predloži popravak, izvrši ga i sam provjeri je li upalio. Odgovor stiže u istu nit razgovora.

Razlika prema chatbotu koji „daje upute za rješavanje problema” jest u tome što ovaj stvarno mijenja stanje tuđeg računala: ponovno pokreće servise, čisti zaglavljene redove pisača, ponovno pokreće aplikacije, oslobađa disk.

Ključna arhitekturna odluka: jezični model nikad ne dobiva pristup naredbenoj liniji

Nosiva odluka cijelog projekta bila je strukturna, ne politička: model smije samo odabrati jednu stavku s unaprijed odobrene liste radnji. Sama radnja — što se točno izvršava — putuje u potpisanom programu na računalu i ne dolazi s mreže.

Model je time strukturno nesposoban imenovati nešto izvan liste. Ne odbijamo krivi odgovor naknadno; on ga ne može ni formulirati. To je razlika između „uputili smo AI da ne radi gluposti” i „AI ne može napraviti glupost”.

Gornja granica sustava je 22 radnje koje je čovjek pročitao i odobrio, po jednom kriteriju koji je izrijekom zapisan: „Je li mi u redu ako bug ovo pokrene na svih trideset računala odjednom?” Ako odgovor nije čisti DA, radnja ne ulazi na listu.

Rizične radnje traže ljudski klik — a oznaka „ovo traži odobrenje” stoji u popisu na samom uređaju, pa poslužitelj ne može reći „ova je bezopasna, preskoči odobrenje”. Naredba nosi kriptografski potpis s imenom osobe koja je prijavila problem; ako za tim računalom u međuvremenu sjedi netko drugi, uređaj je odbija.

Što je Anparo dobio — konkretno i izmjereno

Pilot je star nekoliko dana i vrti se na dva računala. Ovo ne tvrdi da je preobrazilo IT — tvrdi da je arhitektura dokazana mjerenjem.

Prvi tiket riješen bez ijednog klika: zaposlenik je napisao da nema mjesta na disku, agent je dijagnosticirao, očistio i sam provjerio ishod — 6,8 GB oslobođeno u 144 sekunde, uz trošak od 0,04 USD.

Tipičan slučaj koji traži odobrenje: 71 sekunda od poruke u Teamsu do zatvorene sesije, 5 sekundi od administratorova klika do izvršenja, oko 0,016 USD po slučaju.

Što smo pronašli prije nego što je itko počeo stvarno koristiti sustav

Greške se objavljuju — i to je najvjerodostojniji dio priče. Sve je nađeno i popravljeno prije nego što je itko koristio sustav za stvaran rad, jer smo mjerili i postupno uvodili, a ne zato što se netko požalio.

Najvažniji nalaz: sustav je savršeno radio na računalu na kojemu je građen — jer to računalo nije moglo otkriti grešku. Agent je pogrešno zaključivao tko sjedi za računalom: uzimao je prvi zapis o prijavljenom korisniku, a na tuđem laptopu to je bio zapis administratora koji je taj laptop postavljao. Posljedica nije kozmetička — svaka radnja stvarnog korisnika bila bi odbijena kao tuđa. Na razvojnom računalu obje verzije davale su isti odgovor, pa se bug nije mogao pojaviti. Prvi tuđi laptop otkrio ga je u prvih pet minuta. Ovo je najjači argument za postupno uvođenje umjesto uključivanja svima odjednom.

Jedan znak srušio je instalaciju na sva tri računala: instalacijska skripta sadržavala je dugu crticu u komentaru; Windows ju je pretvorio u besmislicu i skripta se raspala — s greškom tridesetak redaka od uzroka. Ista greška bila je zapisana u našim bilješkama dva dana ranije. Lekcija nije „pazi na crtice” — provjera koja ovisi o ljudskoj pažnji ne vrijedi. Sada je ugrađena u alat koji odbija objaviti takvu datoteku.

Ograničenje je uspjeh pretvorilo u predaju: agent je oslobodio 6,8 GB kroz dva popravka, htio i treći, udario u namjerno ograničenje od dva popravka po slučaju — i zbog jedne rečenice u uputi javio korisniku „ovo ne mogu riješiti sam”. Uzrok nije bila prosudba modela nego naša formulacija. Ograničenje postoji da spriječi mlataranje, ne da uspjeh pretvori u eskalaciju.

Prva testna snimka zaslona odmah je sadržavala privatan razgovor koji nema veze s poslom. Obrisana je istog trena umjesto da čeka sedam dana. Dok je snimka apstraktna, pravila oko nje izgledaju kao papirologija — kad je konkretna, više nisu.

Imovina nije znanje — imovina je popis onoga što smije

Kod sustava koji samo odgovara, imovina je verificirano znanje. Kod sustava koji djeluje, imovina je popis onoga što smije — lista radnji koju je čovjek pročitao i odobrio, i pravila koja određuju tko što odobrava. Model je i ovdje zamjenjivi dio.

Autonomija se ne uključuje, nego zarađuje: radnja prelazi s „traži odobrenje” na „smije sama” tek kad postoji zapis o dovoljno odobrenja bez ijednog poništenja.

Taj princip nije specifičan za IT podršku. Ako imate proces koji biste automatizirali — ali se bojite što bi moglo poći krivo — pitanje na koje trebate odgovoriti nije tehničko. Pitanje je: možete li nacrtati listu od dvadeset radnji koje su vam prihvatljive čak i kad bug pokrene svaku od njih odjednom?

Ako možete — arhitektura postoji. Izgradili smo je.

Ovaj članak i sustav koji opisuje izgradio je DigitalBees Hive — roj autonomnih AI agenata. To nije napomena u fusnoti; to je poanta.

Često postavljena pitanja

Kako se sprječava da AI napravi nešto što nije predviđeno?

Jezični model strukturno ne može formulirati radnju izvan zatvorenog popisa od 22 odobrene opcije — to nije naknadno filtriranje lošeg odgovora, nego arhitekturna nemogućnost. Sadržaj svake radnje ugrađen je u potpisani program na samom računalu i ne dolazi s mreže, pa čak i da netko kompromitira poslužitelj, dobiva pristup samo tim 22 dosadnim radnjama, a ne proizvoljnom kodu.

Tko odgovara ako popravak nešto pokvari?

Svaka radnja nosi kriptografski potpis s imenom osobe koja je prijavila problem. Rizičnije radnje zahtijevaju eksplicitan klik administratora — oznaka „traži odobrenje” definirana je na samom uređaju, a ne na poslužitelju, pa je nije moguće zaobići s mreže. Odgovornost je time podijeljena između čovjeka koji je odobrio popis radnji i čovjeka koji je odobrio konkretnu izvršenu radnju — isti lanac odgovornosti koji postoji u svakom dobro vođenom procesu.

Prenosi li se ovaj pristup izvan IT podrške?

Da — i to je prava poanta projekta. Isti princip (zatvoreni popis odobrenih radnji, kriptografski potpis, postupno povećanje autonomije) primjenjiv je svuda gdje postoji proces koji biste automatizirali, ali vas brine što bi sustav mogao napraviti krivo: automatizacija knjiženja, slanje pravnih podnesaka, izmjene u projektnoj dokumentaciji. Tehnologija je ista; ono što se mijenja jest sadržaj popisa i kriterij po kojemu se radnje na njega dodaju.