BLOG
18. kolovoza 2026.ai-agentsblockchainauditabilita2 min čitanjaITENHR

Dva smjera na sjecištu AI-ja i blockchaina, pod istom etiketom

Jedna arhitektura koristi lanac kao izvor podataka, druga kao javnog bilježnika. Rješavaju suprotne probleme, a većina ponuda na tržištu ih miješa.

Pod etiketom "AI plus blockchain" prodaju se dvije suprotne stvari. Dijele iste sastojke, pojavljuju se na istim slajdovima, ali rješavaju probleme koji nemaju veze jedan s drugim. Tko procjenjuje projekt na ovom sjecištu, prvo bi trebao razumjeti koji mu se od dva smjera zapravo nudi — razlika nije u nijansi, nego u arhitekturi.

Prvi smjer: agent čita lanac

U prvom smjeru blockchain je izvor podataka, a agent je potrošač. Agent prati novčanike, transakcije i događaje protokola, označava obrasce vrijedne provjere, sastavlja compliance izvještaj koji nitko ne želi pisati u petak popodne, pregledava smart contract prije deploya i kaže što mu izgleda sumnjivo.

To je koristan posao i u mnogim je situacijama upravo ono što treba. Ali treba ga zvati pravim imenom: to je integracija. Lanac je uzvodno, agent nizvodno, a onome što agent proizvede i dalje se vjeruje na riječ. Ako model pogriješi, pogrešan izvještaj stiže na stol jednako uredno formatiran kao i točan.

Drugi smjer: lanac dokazuje agenta

U drugom smjeru uloge se okreću. Agent kod svakog poziva piše strukturirani zapis u decision ledger: hash ulaza, pozvani alati, verzija modela, izlaz. Zapisi se skupljaju u serije, nad serijom se gradi Merkle korijen i samo taj korijen ide on-chain. Nijedan osjetljivi podatak ne izlazi iz infrastrukture klijenta — na lanac putuje otisak, ne sadržaj.

Ovdje lanac nije baza podataka. On je javni bilježnik. Njegov je posao učiniti dokazivim, i to prema trećoj strani koja vam ne vjeruje, da zapis odluka agenta nije naknadno prepravljen. Obična log tablica u bazi aplikacije to ne može: svatko s odgovarajućim ovlastima može je izmijeniti, a nitko ne može dokazati da nije.

Što to znači za firme u regiji

Za tvrtke u regiji koje sada digitaliziraju postojeće sustave razlika je vrlo praktična. Prvi smjer je integracijski projekt: rezultat se vidi brzo i lako se pokazuje upravi. Drugi smjer dira način na koji aplikacija bilježi što je napravila — a to je odluka koju treba donijeti prije pisanja prvog agenta, jer naknadno ugrađivanje decision ledgera u sustav koji ga ne predviđa košta znatno više nego da je projektiran od početka.

Upravo je drugi smjer ono što traže revizor, banka ili strani partner koji vas ne poznaje. Audit trail koji vlasnik sustava može sam mijenjati za njih nije dokaz; audit trail čiji je otisak usidren on-chain jest nešto što mogu provjeriti bez povjerenja u vas.

I načini na koje dva smjera padaju su suprotni. Prvi pada tiho: model pogriješi i nitko ne primijeti. Drugi pada na mjestu upisa: ako zapis u decision ledger piše komponenta koju nitko nije pregledao, sidrenje lošeg zapisa dokazuje samo da je loš zapis star. Nepromjenjivost nije točnost.

Većina ponuda na tržištu trenutno je prvi smjer obučen u odjeću drugoga. Riječ "auditability" prodaje se na arhitekturi obične integracije podataka, a kupac to otkrije u najgorem trenutku — kad revizor prvi put zatraži dokaz.

Koji od dva smjera zapravo rješava vaš problem?

Ovaj je članak nastao kao objava na LinkedInu, gdje se o njemu raspravljalo.Pogledaj raspravu