Budućnost AI u ERP sistemima

Skoro svaki ERP danas „ima AI“. To je tačno onoliko koliko je i beskorisno: rečenica ne kaže gde AI stoji, a to je jedina stvar koja se kasnije ne može promeniti. AI može da bude deo jezgra — još jedan pozivalac istog API-ja koji koristi i ekran, bez ijedne sopstvene dozvole — ili može da bude zalepljen sa strane: zaseban servis sa sopstvenim ključem, koji čita kopiju baze i vidi sve. Obe varijante na demou izgledaju isto. U radu se razlikuju u svemu.

Ovaj tekst je o toj arhitektonskoj liniji, ne o kvalitetu modela. Slabiji model u jezgru je bezbedniji od jačeg modela sa strane, jer pitanje koje odlučuje finansijski softver nikada nije „koliko je pametan“ nego „šta sme da uradi, u čije ime, i da li se to posle može dokazati“. Zalepljeni AI po pravilu ne može da odgovori ni na jedno od tri — a upravo se ta tri pitanja postave kada stigne kontrola ili kada neko pita kako je podatak izašao iz firme.

Zalepljeni AI ima prepoznatljiv oblik

Zalepljeni AI se prepozna po tome što zaobilazi model dozvola koji je ERP godinama gradio za ljude. Najčešće to nije zla namera nego prečica: da bi „chat u ćošku“ brzo proradio, neko mu da servisni nalog koji vidi sve, ili ga zakači na read-replicu, ili na integraciju koja čita ekrane. Svaka od tih odluka je razumljiva pojedinačno, a zajedno prave sistem u kome AI ima svoj put do podataka — put koji ne prolazi kroz RLS, kroz podelu dužnosti, kroz limite odobravanja ni kroz dnevnik.

• Servisni nalog koji vidi sve — jedan tehnički korisnik iznad celog autorizacionog modela.
• Kopija podataka — read-replica ili poseban indeks koji se puni mimo dozvola, pa curi nezavisno od njih.
• Sopstveni model podataka — „AI verzija“ dokumenta sa svojim ekranom, koja počne da zaostaje za pravom.
• Čitanje ekrana — integracija koja glumi korisnika kroz UI, pa je neproverljiva i puca na svaku izmenu izgleda.
• Odgovori bez porekla — tvrdnja koju ne možete da rasklopite do zapisa, jer AI ne zna odakle mu je podatak.

Agent koristi ista vrata kao i ekran

AI-native jezgro okreće tu grešku naopako. Agent nema svoju vezu sa bazom i nema svoje dozvole; dobija sesiju korisnika koji ga je pozvao i zove tačno one operacije koje bi taj korisnik i sam mogao da pokrene na ekranu. Tehnički, to se danas najčistije izvodi kroz MCP — protokol koji postojeće operacije aplikacije izloži agentu kao imenovane alate. Ključna reč je postojeće: alat iza MCP-a je isti onaj API poziv koji radi i dugme u interfejsu, sa istom autorizacijom, istim RLS-om, istim guard-ovima i istim workflow-om.

Zato agent ne može da uradi ništa što korisnik u čije ime radi ne bi smeo. Ako knjigovođa ne vidi kupce druge poslovne jedinice, ne vidi ih ni agent koji odgovara tom knjigovođi. Ako čovek ne sme da odobri iznad svog limita, ne sme ni automatika u njegovo ime. To nije „AI bezbednost“ kao poseban sloj — to je autorizacioni model koji ozbiljan ERP ionako mora da ima, samo sada pritisnut jače nego ijednim korisnikom pre agenta.

Jedna kapija za modele

Native sloj ne zove model direktno sa sto mesta u kodu. Ide kroz jednu kapiju — model gateway — kroz koju prolazi svaki zahtev ka bilo kom modelu. Na jednom mestu žive stvari koje sa strane obično nedostaju: koji model sme da dodirne koju klasu podataka, gde podatak fizički ide, koja je verzija modela zaključana, koliko po tenantu, i pun zapis ulaza i izlaza. Sto razbacanih API ključeva ne može ništa od toga da garantuje; jedna kapija može.

Zašto lokalni model nije luksuz

U domaćem kontekstu izbor modela nije samo pitanje cene i kvaliteta nego i toga gde podatak sme da otputuje. Ugovori, obračun zarada, spiskovi kupaca sa PIB-om — to su podaci koje mnoge firme ne žele da pošalju spoljnom provajderu, a neke ni ne smeju. Kapija to rešava rutiranjem po klasi podatka: osetljivo ide na lokalni ili on-prem model koji ne napušta infrastrukturu firme, a samo neosetljivo i bezlično na hostovani model — ili se ceo sloj vrti offline. Bez kapije taj izbor ne postoji: podatak ide tamo gde je zalepljen prvi ključ.

Zašto se native sloj može dokazati

Kod zalepljenog AI-ja tragovi njegovih radnji žive u aplikacionom logu — tekst koji se rotira, teško se pretražuje i odvojen je od poslovnog dnevnika. Kod native sloja je obrnuto: pošto je agent prošao kroz isti API, njegove radnje su već događaji u istom nepromenljivom dnevniku kao i ručni rad — svaki predlog i svaka akcija nose ulaz, model i njegovu verziju, verziju prompta, pozvane alate, izlaz, i ko je i kada potvrdio. Zašto to nije birokratija vidi se dve godine kasnije, kada kontrola pita ko je odlučio da faktura za građevinske radove ide u deo 8b POPDV-a. „AI je predložio“ nije odgovor; odgovor je zapis koji pokazuje model i verziju, izvorni dokument i čoveka koji je potvrdio — isti standard koji važi za svako knjiženje.

Isti taj put kroz API čini sloj testabilnim. Fiksni skup dokumenata i pitanja može da se pusti kroz agenta u CI-ju i da se proveri šta je predložio, koje je alate pozvao i šta je odbio da popuni. Zalepljena integracija koja čita ekrane to ne može: njena površina za test je sam interfejs, pa se regresija otkrije tek kad klijent pozove. Promena verzije modela je promena ponašanja celog sloja i dolazi spolja, bez vašeg commit-a — golden setovi u CI-ju su jedini način da takva promena obori build pre produkcije, a ne posle nje.

Gde AI ne sme da odlučuje

Native arhitektura čini AI dovoljno bezbednim da se koristi široko — ali „može bezbedno“ nije „sme“. Neke odluke ostaju ljudske bez obzira na sigurnost modela, jer im je posledica spoljna, pravna i na vašoj strani nepovratna. Za njih agent sme da pripremi sve do poslednjeg polja, ali čin koji stvara tu posledicu ostaje ljudska potvrda:

• Predaja zakonske prijave — PP PDV, PPP-PD i POPDV idu poreskoj sa potpisom i rokom firme, ne modela.
• Puštanje plaćanja — novac koji je izašao iz banke nema undo u vašem sistemu.
• Slanje eFakture na SEF — poslata eFaktura je pravni dokument, ne nacrt.
• Zaključavanje perioda — zatvaranje dnevnika je odluka sa posledicom po sve što sledi.
• Odobravanje iznad limita — cena, rabat ili kredit preko granice čoveka koji potvrđuje.
• Radnja čiji undo nije u vašem sistemu — svaki spoljni, treći, nepovratni efekat.

Zajednički imenilac te liste nije slabost današnjih modela koju jači model uklanja. To je pitanje ko odgovara poreskoj i sudu — a odgovornost nikada ne pređe na softver. Zato ove granice ne stoje u promptu (koji se može nadglasati tekstom u prilogu) nego u workflow-u: operacije koje predaju prijavu ili puštaju plaćanje jednostavno nisu među alatima koje agent sme da pozove.

Kako NG One pristupa ovome

NG One je građen AI-native u ovom tačnom smislu. Agent je pozivalac istog API-ja koji koristi i interfejs, preko MCP-a, bez ijedne sopstvene dozvole; nasleđuje šestoslojnu autorizaciju, RLS izolaciju tenanta na nivou baze, workflow guard-ove i maker–checker. Model gateway rutira po klasi podatka, podržava lokalne i on-prem modele za osetljive klase i može da radi offline. Svaki predlog i svaka akcija su prvorazredni događaji u istom nepromenljivom dnevniku. Evaluacije — ponovljeni golden dokumenti, testovi tenant izolacije i prompt-injection-a, i skup koji nagrađuje odbijanje — uslov su da AI izmena uđe u granu. A granice iz prethodne sekcije su workflow, ne prompt: operacije koje predaju prijavu ili puštaju plaćanje nisu na spisku agentovih alata.

Izbor između native i zalepljenog AI-ja pravi se jednom, rano, i ne može se naknadno ugraditi. Zalepljeni copilot se za demo može doterati da izgleda kao deo jezgra, ali se rupe u dozvolama i tragu vide na prvoj kontroli i na prvom pitanju kako je podatak izašao. Kupcu ostaje jedan pošten test: neka dobavljač pokaže agenta koji radi iz naloga sa užim dozvolama, i neka pokaže zapis u dnevniku za ono što je agent uradio. Ako oba postoje, AI je u jezgru. Ako ne, zalepljen je — koliko god lepo pričao.