WEB & SAAS

Dnevnik aktivnosti AI automatizacije: što sustav mora bilježiti?

Saznajte koje radnje, ovlasti, odobrenja i pogreške treba bilježiti kako bi AI automatizacija ostala provjerljiva i pod kontrolom.

Krupni plan zaslona računala s otvorenim alatima za debugiranje i prikazom programskog koda.

Automatizirani sustav više ne mora samo prepisati podatak iz jednog polja u drugo. Može pročitati upit, povezati se s poslovnom aplikacijom, provjeriti stanje, predložiti odluku i pokrenuti sljedeći korak. Što sustav radi više, postaje važnije moći odgovoriti na jednostavno pitanje: što se točno dogodilo i zašto?

To pitanje dobiva na važnosti upravo sada. Europska komisija objavila je 14. listopada 2026. da 42 % ispitanih europskih malih, srednjih i srednje velikih tvrtki već koristi umjetnu inteligenciju ili automatizirane sustave, najčešće još u ograničenoj i eksperimentalnoj primjeni. Na hrvatskom Automation Summitu 16. listopada posebno je istaknuta potreba za ljudskim nadzorom, ograničenim pristupom i praćenjem rada AI agenata. ServiceNow je 20. listopada objavio istraživanje o nedostatku evidencije i kontrole nad agentima, a Oracle je 21. listopada predstavio poslovne automatizacije koje izvršavaju složenije zadatke unutar definiranih pravila i odobrenja.

Za hrvatsku tvrtku zaključak nije da odmah treba uvoditi najnaprednije agente. Zaključak je da prije širenja bilo koje automatizacije treba urediti njezin dnevnik aktivnosti: zapis iz kojeg se može utvrditi tko je pokrenuo proces, koje je podatke sustav koristio, što je promijenio i gdje je čovjek odobrio nastavak.

Dnevnik nije isto što i izvještaj da je zadatak završen

Mnogi alati prikazuju samo završni status: izvršeno, nije izvršeno ili dogodila se pogreška. To je dovoljno dok automatizacija šalje bezazlenu internu obavijest. Nije dovoljno kada mijenja podatke o kupcu, priprema ponudu, upisuje rok, šalje poruku ili pokreće narudžbu.

Dnevnik aktivnosti mora omogućiti rekonstrukciju pojedinačnog izvršenja. Ako kupac prijavi pogrešan iznos, zaposlenik ne bi trebao nagađati je li problem nastao u izvornom dokumentu, pravilu za izračun, prijenosu podataka ili naknadnoj ručnoj izmjeni.

Kvalitetan zapis zato povezuje najmanje pet elemenata:

  • vrijeme pokretanja i završetka procesa
  • korisnika, događaj ili sustav koji je pokrenuo automatizaciju
  • korištene izvore podataka i verziju poslovnog pravila
  • izvršene radnje, promjene i rezultate
  • pogreške, odobrenja, ručne intervencije i ponovljene pokušaje

Cilj nije pohraniti svaku tehničku sitnicu bez reda. Cilj je imati dovoljno podataka da odgovorna osoba može razumjeti poslovni tijek bez pregledavanja više nepovezanih aplikacija.

Što treba zapisati prije, tijekom i nakon izvršenja?

Dnevnik je najkorisnije planirati u tri dijela. Prvi opisuje stanje prije pokretanja, drugi bilježi radnje, a treći potvrđuje konačan ishod.

Prije pokretanja

Zapis treba sadržavati razlog pokretanja procesa i identitet pokretača. To može biti pristigli obrazac, nova e-poruka, ručni klik zaposlenika, promjena statusa u CRM-u ili zakazano vrijeme. Treba zabilježiti i koje su ovlasti vrijedile u tom trenutku.

Ako automatizacija koristi AI za tumačenje nestrukturiranog sadržaja, korisno je sačuvati ulazni dokument ili njegovu sigurnu referencu, izdvojene podatke i procjenu pouzdanosti. Osjetljive podatke ne treba nekontrolirano kopirati u više zapisa; dnevnik mora biti koristan, ali usklađen s pravilima pristupa i rokovima čuvanja.

Tijekom rada

Svaka poslovno važna radnja treba dobiti razumljiv naziv. Umjesto nejasnog zapisa „korak 7 uspješan”, bolje je navesti „provjeren status kupca”, „dohvaćena ugovorena cijena” ili „pripremljen nacrt ponude”.

Posebno treba zabilježiti vanjske pozive prema drugim sustavima, rezultat razmjene podataka, neuspjele pokušaje i naknadna ponavljanja. Bez toga se ista radnja može nenamjerno izvršiti dvaput, primjerice poslati dvije potvrde ili izraditi dva radna naloga.

Nakon izvršenja

Završni zapis treba pokazati je li proces potpuno dovršen, djelomično dovršen, zaustavljen ili predan zaposleniku. Ako je čovjek nešto odobrio, odbio ili izmijenio, mora biti jasno tko je to učinio, kada i nad kojim podacima.

Koje odluke automatizacija ne bi smjela skrivati?

Problem nije samo u tehničkoj pogrešci. Sustav može tehnički ispravno napraviti poslovno pogrešnu radnju. Primjerice, može poslati uredno oblikovanu ponudu s cijenom koja više ne vrijedi ili označiti važan upit kao nizak prioritet zbog nepotpunih podataka.

Zato dnevnik treba razlikovati tri vrste koraka:

  1. Određeni koraci slijede unaprijed postavljeno pravilo, poput izračuna PDV-a ili prijenosa šifre artikla.
  2. Procijenjeni koraci uključuju tumačenje sadržaja, razvrstavanje ili prijedlog AI sustava.
  3. Odobreni koraci zahtijevaju potvrdu odgovorne osobe prije izvršenja.

Za procijenjene korake nije dovoljno zabilježiti samo konačan odgovor. Treba znati na temelju kojih je podataka nastao, koje je pravilo primijenjeno i je li rezultat naknadno izmijenjen. Za odobrene korake važno je čuvati točnu verziju prijedloga koju je osoba vidjela. Inače se poslije ne može dokazati što je zapravo bilo odobreno.

Praktična granica može biti jednostavna: automatizacija smije samostalno izvršavati česte i reverzibilne radnje male vrijednosti, dok financijske obveze, brisanje podataka, promjene ugovornih uvjeta i komunikacija s većim posljedicama prolaze ljudsko odobrenje.

Praktičan primjer: od upita kupca do nacrta ponude

Zamislimo distributera koji upite prima e-poštom. Automatizacija čita poruku, prepoznaje kupca i artikle, provjerava podatke u CRM-u i zalihu u poslovnom sustavu te priprema nacrt odgovora.

Loše postavljen sustav zabilježit će samo da je odgovor pripremljen. Dobro postavljen dnevnik pokazat će:

  • koja je poruka pokrenula proces
  • koji su artikli i količine prepoznati
  • je li kupac pronađen jednoznačno ili je postojalo više mogućih zapisa
  • iz kojeg je sustava preuzeta cijena i kada
  • je li podatak o zalihi bio dostupan
  • koje su stavke ostale nejasne
  • tko je pregledao nacrt i što je promijenio prije slanja

Ako sustav ne može pouzdano povezati kupca ili proizvod, ne bi trebao samostalno odabrati prvi sličan rezultat. Proces se može zaustaviti i otvoriti zadatak zaposleniku. U dnevniku tada ostaje razlog predaje, pa se naknadno može prepoznati ponavljajući problem u nazivima proizvoda, šiframa ili kvaliteti podataka.

Takav zapis nije koristan samo kada nešto pođe pogrešno. Nakon nekoliko tjedana pokazuje gdje zaposlenici najčešće ispravljaju prijedlog, koji korak traje najdulje i koje bi poslovno pravilo trebalo doraditi.

Kako provjeriti spremnost prije puštanja automatizacije u rad?

Prije produkcijske uporabe provedite test s nekoliko stvarnih, ali kontroliranih scenarija: uredan slučaj, nepotpun podatak, nedostupan povezani sustav, dvostruko pokretanje i slučaj koji mora završiti kod zaposlenika. Za svaki scenarij provjerite može li osoba koja nije razvijala automatizaciju razumjeti dnevnik i rekonstruirati rezultat.

Kontrolni pregled treba odgovoriti na sljedeća pitanja:

  • Možemo li povezati svaku promjenu s konkretnim izvršenjem?
  • Vidimo li koje je ovlasti sustav imao u tom trenutku?
  • Možemo li razlikovati poslovno pravilo od AI procjene?
  • Postoji li jasno mjesto za ljudsko odobrenje?
  • Možemo li sigurno ponoviti neuspjeli korak bez dupliciranja rezultata?
  • Dobiva li odgovorna osoba upozorenje kada proces odstupi od očekivanog?
  • Jesu li pristup dnevniku i rok čuvanja zapisa unaprijed određeni?

U sklopu automatizacije poslovnih procesa povezujemo prijenos podataka, obavijesti i odobravanja s jasnim pravilima, evidencijom izvršavanja i kontrolom iznimaka. Dnevnik aktivnosti pritom nije dodatak koji se izrađuje tek nakon prve pogreške, nego dio osnovnog dizajna sustava.

Prije sljedećeg širenja automatizacije odaberite jedan stvarni proces i pokušajte iz postojećih zapisa rekonstruirati njegovo posljednje izvršenje. Ako ne možete jasno utvrditi ulaz, radnje, odobrenja i konačan ishod, sustavu još nedostaje važna kontrolna točka. Za pregled konkretnog procesa i procjenu potrebnih zapisa možete nam se javiti za nenametljiv razgovor prije tehničke izvedbe.