Američki medij Axios 22. listopada 2026. izvijestio je da pojedine banke otkrivaju neodobrene AI agente koji ulaze u korisničke račune, ponekad uz vjerodajnice koje im je dao sam korisnik. Dan poslije Microsoft je u pregledu novih poslovnih mogućnosti istaknuo zasebne račune za agente, s upravljanjem ovlastima, okidačima i pravilima poslovnog procesa.

To ne znači da se opisani bankovni slučajevi odnose na Hrvatsku niti da je Microsoftova funkcija već općenito dostupna hrvatskim malim i srednjim tvrtkama. Agent Accounts tada je bio naveden kao privatni pregled. Ipak, obje vijesti pokazuju isti problem: automatizacija može dobiti više ovlasti nego što joj je potrebno samo zato što radi kroz račun zaposlenika.

Pravo pitanje zato nije samo može li AI obaviti zadatak, nego pod čijim identitetom djeluje, što smije učiniti i kako joj se pristup može odmah ukinuti.

Zašto račun zaposlenika nije bezazlen tehnički detalj

Kada zaposlenik poveže automatizaciju sa svojim e-mailom, CRM-om, dokumentima ili financijskim alatom, sustav često nasljeđuje dio njegovih ovlasti. Ako je zaposlenik administrator, automatizacija može dobiti pristup podacima i radnjama koje joj za konkretan zadatak uopće nisu potrebne.

Primjerice, sustav koji treba pročitati nove upite i pripremiti nacrt odgovora ne mora nužno imati mogućnost:

slanja poruke bez odobrenja,
brisanja kontakata i prethodne komunikacije,
izvoza cijele baze klijenata,
promjene korisničkih ovlasti,
povezivanja dodatnih aplikacija,
pristupa privatnim mapama zaposlenika.

Problem se dodatno povećava kada više automatizacija koristi isti račun ili isti API ključ. U zapisima aktivnosti tada se može vidjeti ime zaposlenika ili zajedničkog tehničkog korisnika, ali ne i koja je automatizacija donijela odluku. Ako se pojavi pogreška, teško je odvojeno zaustaviti samo problematičan proces.

Račun zaposlenika može biti opravdan kada automatizacija obavlja jednu kratku radnju u njegovu prisutnost i koristi samo njegove postojeće ovlasti. Međutim, za procese koji rade u pozadini, ponavljaju se po rasporedu ili djeluju bez neposredne potvrde sigurniji je zaseban, jasno označen identitet.

Kada automatizacija treba zaseban račun

Zaseban račun ili upravljani tehnički identitet posebno je važan kada sustav samostalno obrađuje podatke, radi izvan radnog vremena ili pokreće radnje u više aplikacija. Cilj nije otvoriti još jedan običan korisnički račun i dati mu administratorske ovlasti, nego odvojiti automatizaciju od osobnog identiteta zaposlenika.

Takav račun treba imati naziv koji jasno opisuje svrhu, primjerice „obrada web-upita” ili „sinkronizacija narudžbi”. Treba imati i imenovanog poslovnog vlasnika: osobu koja razumije čemu proces služi i može odlučiti treba li ga promijeniti, privremeno zaustaviti ili ugasiti.

Zaseban identitet ima nekoliko praktičnih prednosti:

automatizaciji se dodjeljuju samo potrebne ovlasti,
njezine se radnje lakše razlikuju od rada zaposlenika,
pristup joj se može ukinuti bez zaključavanja ljudskog korisnika,
promjena radnog mjesta ili odlazak zaposlenika ne prekida proces,
lakše je odvojiti čitanje podataka od njihova mijenjanja,
svaka kritična radnja može dobiti zasebno pravilo odobravanja.

To nije pravilo samo za AI agente. Ista logika vrijedi za klasične integracije, sinkronizacije, automatizirane e-mail poruke, prijenos narudžbi i druge procese koji povezuju poslovne alate.

Čitanje, priprema i izvršenje nisu ista ovlast

Česta je pogreška promatrati pristup nekom alatu kao jednu odluku: automatizacija je ili povezana ili nije. U stvarnosti treba odvojiti najmanje tri razine rada.

1. Čitanje podataka

Sustav može pregledati novi upit, stanje narudžbe ili podatke potrebne za izračun. Već i ovdje treba ograničiti koje zapise i polja smije vidjeti. Automatizaciji za raspoređivanje servisnih naloga možda trebaju ime, lokacija i vrsta kvara, ali ne i kompletna povijest naplate.

2. Priprema prijedloga

AI može sastaviti odgovor, predložiti kategoriju upita ili pripremiti nacrt ponude. Rezultat se sprema kao prijedlog, a zaposlenik ga pregledava prije slanja. To je dobar početni model za procese u kojima pogreška može zbuniti klijenta ili stvoriti financijsku obvezu.

3. Izvršenje radnje

Slanje poruke, promjena cijene, odobravanje povrata, izdavanje dokumenta ili brisanje zapisa imaju veći poslovni učinak. Takve radnje trebaju užu ovlast, jasne granice i, prema razini rizika, dodatno ljudsko odobrenje.

Praktično pravilo glasi: ako se pogreška može lako vratiti i nema većih posljedica, automatizacija može dobiti više samostalnosti. Ako radnja šalje novac, mijenja ugovorene podatke, objavljuje sadržaj ili trajno briše zapis, treba uvesti kontrolnu točku prije izvršenja.

Što provjeriti prije povezivanja poslovnih računa

Prije puštanja automatizacije u stvarni rad nije dovoljno provjeriti samo može li uspješno izvršiti zamišljeni zadatak. Potrebno je testirati i što se događa kada primi nepotpun podatak, neočekivanu uputu ili zahtjev izvan dopuštenog opsega.

Koristan pregled može se provesti kroz sedam pitanja:

Identitet: djeluje li sustav kao zaposlenik, zaseban agent ili tehnički servis?
Vlasništvo: koja je osoba odgovorna za svrhu i životni ciklus automatizacije?
Opseg: kojim aplikacijama, mapama, zapisima i funkcijama sustav stvarno treba pristup?
Trajanje: treba li ovlast biti trajna ili samo aktivna tijekom određenog zadatka?
Odobrenje: koje radnje zahtijevaju potvrdu zaposlenika prije izvršenja?
Praćenje: može li se iz zapisa utvrditi što je automatizacija pročitala, predložila i promijenila?
Zaustavljanje: može li se pristup brzo opozvati bez prekida rada ostalih korisnika i procesa?

Posebno treba izbjegavati slanje korisničkih lozinki kroz poruke, tablice ili tekstualne upute za AI alat. Kada aplikacije podržavaju službene integracije, sigurnije je koristiti kontrolirani pristup putem API-ja, ograničene tokene i postupak za njihovu zamjenu ili ukidanje. Naša usluga API integracija obuhvaća mapiranje podataka, autentifikaciju, sinkronizaciju i obradu neuspjelih prijenosa.

Primjer odluke: obrada upita sa stranice

Zamislimo servisnu tvrtku koja želi automatizirati obradu upita s web-stranice. Novi sustav treba pročitati obrazac, prepoznati vrstu usluge, otvoriti zapis u poslovnoj aplikaciji i poslati potvrdu korisniku.

Najbrže rješenje bilo bi povezati automatizaciju s računom voditelja prodaje. Time bi sustav možda dobio pristup njegovoj cijeloj e-pošti, svim kontaktima, izvještajima i postavkama aplikacije. To je više nego što zadatak zahtijeva.

Kontroliraniji model bio bi zaseban identitet koji smije čitati samo nove obrasce, izraditi novi zapis i koristiti odobreni predložak potvrde. Ako upit sadrži nejasne podatke ili zahtjev izvan standardne ponude, dodjeljuje se zaposleniku umjesto da sustav samostalno obeća cijenu ili rok.

U evidenciji tada ostaje jasno tko je poslao obrazac, što je automatizacija zaključila, koji je zapis otvorila i je li zaposlenik morao intervenirati. Ako se pojavi problem, može se ugasiti samo ta integracija, bez promjene lozinke voditelja prodaje i prekida njegova rada.

Dobro postavljena automatizacija poslovnih procesa zato ne počinje pitanjem koji AI alat odabrati. Počinje popisom zadataka, podataka, ovlasti, iznimki i odluka koje moraju ostati pod ljudskom kontrolom.

Kontrolna točka prije pokretanja glasi: ako automatizaciju ne možete neovisno prepoznati, ograničiti i zaustaviti, još nije spremna za trajni pristup poslovnim računima. Ako želite pregledati postojeću integraciju ili planirati novi proces s jasnim ovlastima i odobrenjima, možete nam se javiti za razgovor bez obveze uvođenja sustava prije nego što se utvrde stvarne potrebe.