AI agent u mom eksperimentu čita narudžbinu iz Vibera, iz nje sastavi stavke sa šiframa iz kataloga, količinama i podacima kupca, pa taj predlog pošalje čoveku na potvrdu; tek posle potvrde n8n zove API Tezga eKase i nastaje predračun ili fiskalni račun. Model nikad ne izdaje račun sam, jer greši u količinama, adresama i PIB-u dovoljno često da to ne sme.
- Postavka je bila n8n tok: Viber poruka ulazi, jezički model je pretvara u strukturisanu narudžbinu, čovek je potvrđuje jednim odgovorom, kasa izdaje dokument preko API-ja.
- Model je u tri nedelje dobro razumeo oko devet od deset poruka, ali su greške bile tačno tamo gde su najskuplje: količine, adrese i PIB kupca.
- Korak potvrde nije usko grlo nego osigurač: fiskalni račun ide Poreskoj upravi u trenutku izdavanja, a pogrešan račun znači storno i objašnjenje kupcu.
- Bezbednost je važnija od pameti: model ne vidi ključ kase, ne vidi druge kupce, ne sme da menja cene ni poreske oznake.
- Bez nadzora ne bih pustio ništa što pravi fiskalni dokument; bez nadzora bih pustio odgovaranje na pitanja, sastavljanje predloga i podsećanje na neplaćene predračune.
Zašto sam uopšte probao da pustim model na narudžbine?
Motiv je bio prizemniji nego što naslov obećava. Gledao sam kako vlasnica male radionice za kolače iz Čačka svako veče prepisuje narudžbine iz Vibera u kasu. Poruke su izgledale ovako: „Zdravo, treba mi ona torta ko prošli put ali veća, za subotu, i još 20 mafina, adresa ista”. Iz toga ona sastavi predračun sa tri stavke, pošalje link sa IPS QR kodom, i to radi dvadeset puta dnevno. Deo posla je razumevanje, deo je kucanje. Kucanje sam već rešio katalogom i naplatom linkom; ostalo je razumevanje.
Jezički modeli su danas dobri baš u tome: da neurednu ljudsku poruku pretvore u strukturu. Pitanje nije bilo da li model može da pročita „20 mafina” nego šta se dešava sa svim što ne piše: koja torta, koja veličina, koja cena, koja adresa. I još važnije pitanje: šta model sme da uradi kad misli da je razumeo. Kako uopšte gledam na AI alate u maloj firmi, pisao sam u tekstu AI za male firme u Srbiji; ovo je jedan konkretan eksperiment iz te priče.
Postavio sam sebi tri pravila pre nego što sam išta napravio. Prvo: model ne dobija ključ kase. Drugo: nijedan fiskalni dokument ne nastaje bez ljudske potvrde. Treće: eksperiment traje tri nedelje na režimu obuke, pa tek onda na stvarnim računima. Trećeg pravila sam se držao najduže, jer je režim obuke u kasi upravo za to: račun nosi napomenu da nije fiskalni i niko ne strada.
Kako izgleda tok od poruke do računa?
Tok u n8n ima šest čvorova. Namerno ga nisam pravio pametnijim; pametniji tok je teže objasniti i teže isključiti.
Model samo predlaže; provera hvata šifre i PIB; čovek odlučuje; kasa izdaje. Sve nejasno vraća se kupcu kao pitanje, ne kao dokument.
- Ulaz. Poruka iz Vibera stiže u n8n kroz webhook. Tok pamti samo tekst poruke i identifikator razgovora, ne ceo istorijat.
- Model. Jezički model dobija poruku, izvod iz kataloga (šifra, naziv, jedinica, cena) i strogo uputstvo da vrati samo JSON sa stavkama, količinama, podacima kupca i listom nejasnoća. Ne dobija ključ kase, ne dobija druge kupce, ne dobija pravo da izmisli artikal.
- Provera. Običan kod, bez modela: svaka šifra mora da postoji u katalogu, cena se uzima iz kataloga a ne iz odgovora modela, PIB mora da ima devet cifara i prolazi kontrolnu proveru, količina mora da bude pozitivan broj. Ako išta ne prođe, tok ide u granu „nejasno”.
- Čovek. Vlasnica dobije poruku sa predlogom u tri reda: stavke, iznos, kupac. Odgovara „da”, „ne” ili ispravkom („mafina 12”). n8n čeka na taj odgovor; ništa se ne dešava dok ga nema.
- Kasa. Tek posle „da” n8n zove
POST /api/integrations/ordersatipDokumenta: predracuni pozivom na broj; kupac dobije link sa IPS QR kodom, a fiskalni račun nastaje kad uplata legne na izvod. Ako je usluga već izvršena i naplaćena, ide odmah račun. - Nejasno. Ako model prijavi nejasnoću ili provera padne, agent kupcu vrati pitanje („Koja veličina torte, 12 ili 16 parčadi?”) i ne pravi ništa.
Telo poziva ka kasi sastavlja n8n iz potvrđenog predloga, nikad direktno iz odgovora modela. To je razlika koja se ne vidi na dijagramu, a najviše znači:
{
"externalId": "viber-7f3a-2026-09-11-1",
"tipDokumenta": "predracun",
"tok": "fiskalni",
"pozivNaBroj": "2026-0911-1",
"posaljiMejl": true,
"kupac": { "naziv": "Jelena M.", "email": "kupac@primer.rs" },
"nacinPlacanja": "Prenos na račun",
"stavke": [
{ "naziv": "Torta čokolada, 16 parčadi", "sifra": "T-COK-16", "kolicina": 1,
"cenaSaPdv": 4800, "poreskaStopa": "OZNAKA_IZ_KATALOGA" },
{ "naziv": "Mafin vanila", "sifra": "M-VAN", "kolicina": 20,
"cenaSaPdv": 180, "poreskaStopa": "OZNAKA_IZ_KATALOGA" }
]
}externalId je sastavljen od identifikatora razgovora i rednog broja, pa dupla potvrda („da” poslato dvaput) ne pravi dva dokumenta; kasa isti identifikator obradi tačno jednom. Kako sam istu idempotentnost učio na bankovnom izvodu, opisao sam u tekstu kako sam spojio banku, kasu i mejl u jedan tok. Ostatak API-ja je na strani API za fiskalizaciju.
Kako izgleda razgovor sa agentom iz ugla kupca i vlasnika?
Ovo je stvaran obrazac poruke, sa izmišljenim imenima. Kupac piše kao što kupci pišu; agent odgovara vlasnici, ne kupcu, dok ne bude potvrđeno.
Agent ne pogađa: torta iz prošle narudžbine je nejasna, pa pita; vlasnica ispravi količinu i potvrdi jednim odgovorom, tek tada nastaje predračun.
Obrati pažnju da je model u ovom primeru pogrešio količinu mafina (20 umesto 12, jer je kupac napisao 20 a mislio na pakovanje od 12 koje uvek uzima) i da je to uhvatila vlasnica, ne model. To nije slučajnost iz mokapa nego najčešća stvarna greška iz tri nedelje.
Gde model greši i koliko često?
Vodio sam jednostavnu evidenciju: svaka poruka, šta je model predložio, šta je vlasnica ispravila. Brojke su iz malog uzorka jedne radionice u tri nedelje, pa ih ne uzimaj kao statistiku nego kao obrazac.
| Vrsta greške | Primer | Zašto model greši | Šta je hvatalo grešku |
|---|---|---|---|
| Količina | „20 mafina” kad kupac uvek uzima kutiju od 12 | Model ne zna navike kupca, čita broj doslovno | Vlasnica pri potvrdi |
| Artikal iz istorije | „ona torta ko prošli put” | Model nema istorijat kupca, i ne treba da ga ima | Model sam prijavio nejasnoću, pa pitanje kupcu |
| Adresa | „adresa ista”, „kod tetke”, ulica bez broja | Nema izvor, pa dopuni ono što misli da je logično | Provera: adresa nije obavezna za dokument, ali kurir traži; vraća se kupcu |
| PIB kupca | Osam cifara, ili matični broj umesto PIB-a | Kupac pošalje šta ima, model prosledi | Provera u kodu: devet cifara i kontrolna cifra, inače nejasno |
| Cena | Kupac napiše „kao prošli put 4.500” | Model uzme cenu iz poruke | Provera: cena se uvek uzima iz kataloga, nikad iz poruke |
| Izmišljen artikal | „Torta jagoda” koje nema u katalogu | Model nađe najbliže i nastavi | Provera: šifra mora da postoji, inače nejasno |
| Datum isporuke | „za subotu” u nedelju uveče | Model ne zna koja subota | Vlasnica; datum ne ide na dokument, ide u napomenu |
Tri zaključka iz tabele. Prvi: model je najbolji u onome što je zaista jezik (razdvajanje stavki, prepoznavanje imena, hvatanje broja) i najgori u onome što je kontekst koji nema (navike, istorija, cene). Drugi: najskuplje greške, PIB i cena, nisu hvatane modelom nego dosadnim kodom sa pravilima, a taj kod je jeftiniji i pouzdaniji od bilo kog uputstva modelu. Treći: ni jedan jedini put model nije predložio nešto što bi prošlo proveru i potvrdu, a bilo pogrešno na fiskalnom računu. Ne zato što je model savršen, nego zato što su dva sloja iza njega.
PIB zaslužuje posebnu napomenu. Ako kupac unese PIB, račun nosi identifikaciju kupca u obliku 10:PIB i to je B2B dokument, a kod obveznika SEF-a može da ide i kao e-faktura. Pogrešan PIB na fiskalnom računu znači storno i novi račun. Zato provera PIB-a nije bila stvar modela nego koda, a za sumnjive slučajeve vlasnica je proveravala firmu u registru APR-a pre potvrde.
Šta agent sme sam, šta uz potvrdu, a šta nikad?
Ovo je dijagram koji sam nacrtao trećeg dana, kad je model prvi put pokušao da „dopuni” adresu. Od tada se nije menjao.
Zona „sme sam” je razgovor i predlog; zona „uz potvrdu” je svaki dokument koji ide Poreskoj upravi; zona „nikad” su novac unazad, cene, ključevi i tuđi podaci.
Srednja zona je ono što ljudi najčešće žele da preskoče: „pa ako je model u 95 odsto slučajeva u pravu, zašto da klikćem?” Zato što fiskalni račun nije mejl. Po Zakonu o fiskalizaciji račun ide Poreskoj upravi u trenutku izdavanja; storno je moguć, ali ostaje zabeležen, a kupac koji je dobio pogrešan račun mejlom dobiće i storno i objašnjenje. Pet odsto od dvadeset narudžbina dnevno je jedan pogrešan račun dnevno. To nije automatizacija nego proizvodnja storna. Više o tome zašto storno i refundacija nisu sitnica ima u tekstu storno i refundacija fiskalnog računa.
Desna zona je nepomična iz drugog razloga: to su radnje kod kojih greška nije pogrešan dokument nego gubitak novca ili poverenja. Model koji može da pokrene refundaciju je model koji može da bude nagovoren da pokrene refundaciju, i to od strane kupca koji zna kako se modeli nagovaraju. Zato refundaciju radi čovek, u kasi, sa vezom na originalni račun.
Kako sam postavio bezbednost oko modela?
Najveći rizik u ovom eksperimentu nije bio da model pogreši količinu, nego da neko iskoristi model kao vrata do kase. Kupac koji piše u Viber piše i modelu; ako je model povezan sa API-jem, kupac je indirektno povezan sa API-jem. Postavka je zato izgledala ovako:
- Model ne vidi ključ. Ključ kase drži n8n u credentials, a poziv ka API-ju pravi n8n čvor posle ljudske potvrde. Model dobija katalog i poruku; vraća JSON. Ništa što model kaže ne može da izazove poziv ka kasi bez čoveka između.
- Ključ vezan za IP i rotiran. Ključ je vezan za IP adresu servera sa koga n8n zove, rotira se na 90 dana, a zahtevi nose HMAC potpis. Ako ključ procuri, bez potpisa i sa pogrešne adrese ne vredi.
- Model ne vidi druge kupce. Dobija samo tekuću poruku i katalog. Nema pristup listi kupaca, istoriji narudžbina ni izvodu. Kad kupac kaže „kao prošli put”, model to prijavi kao nejasnoću, a vlasnica pogleda u kasu.
- Cene i oznake iz kataloga, uvek. Ako kupac u poruci napiše „stara cena”, ili pokuša da „naredi” modelu popust, provera ignoriše cenu iz odgovora i uzima cenu iz kataloga. Popust daje vlasnica, u katalogu.
- Uputstva iz poruka se ne izvršavaju. Poruka kupca je podatak, ne naredba. Model je dobio uputstvo da svaki pokušaj davanja instrukcija iz poruke prijavi kao nejasnoću, i pokazalo se da to i radi, mada ne bih na to oslonio ništa važno; zato je provera u kodu.
- Dnevnik. Svaka poruka, predlog, potvrda i poziv ka API-ju su zabeleženi, pa se svaki dokument može pratiti unazad do poruke i do klika.
Sve to nisu posebne funkcije za AI, nego iste stvari koje bih tražio od bilo koje integracije: ključ kao heš, ograničenje broja zahteva, HMAC, dnevnik pristupa. Kasa ih ima i za obične web shop veze; pregled je na strani sigurnost i zaštita podataka. Kako uopšte pravim softver sa AI alatima i gde im ne verujem, pisao sam u tekstu razvoj softvera sa AI: moj proces.
Šta bih pustio bez nadzora, a šta ne bih?
Posle tri nedelje eksperiment nisam ni ugasio ni pustio u potpunosti. Podelio sam ga.
Pustio bih bez nadzora: odgovaranje na pitanja o ponudi iz kataloga („imate li tortu bez glutena”), sastavljanje predloga narudžbine koji vlasnica vidi, podsećanje kupca na neplaćen predračun dan pre isteka linka, i obaveštenje vlasnici da nešto čeka. Ništa od toga ne pravi dokument ni ne pomera novac; najgore što se desi je nespretan odgovor.
Ne bih pustio bez nadzora: ništa što pravi fiskalni dokument, uključujući predračun, jer predračun sa pogrešnim iznosom vodi do pogrešne uplate, a pogrešna uplata do vraćanja novca. Ne bih pustio ni B2B dokumente, jer PIB i e-faktura preko SEF-a imaju svoje posledice, a knjigovođa ih ne voli da ispravlja. I ne bih pustio ništa u vezi sa refundacijom, ni u eksperimentu.
Za male prodavce koji rade iz poruka, ovo je zapravo dobra vest: najveći deo posla, razumevanje i kucanje, može da nestane, a ono što ostaje je jedan odgovor „da” po narudžbini. Ko uopšte mora da izda račun kad prodaje iz poruka, objasnio je Trek u tekstu prodaja preko Instagrama, Fejsbuka i Viber grupa, a gotove n8n tokove bez modela agencija je objavila u tekstu 12 n8n automatizacija za male firme. Ko hoće da isto ugradi u sopstvenu aplikaciju umesto u n8n, ima uputstvo u tekstu o fiskalizaciji iz sopstvene aplikacije preko API-ja.
Propisi u pozadini su isti kao za svaku prodaju na daljinu: Zakon o fiskalizaciji traži fiskalni račun u trenutku prometa i to ne zavisi od toga ko je sastavio narudžbinu, čovek ili model; Zakon o zaštiti potrošača (Sl. glasnik RS 35/2026) daje kupcu na daljinu pravo na odustanak u roku od 14 dana, pa i kad je naručio preko Vibera; tumačenja o elektronskoj dostavi računa su na sajtu Poreske uprave. Ovo nije pravni savet; za sopstveni slučaj proveri sa knjigovođom.
Izvori: Zakon o fiskalizaciji (Sl. glasnik RS 153/2020, 96/2021, 138/2022); Pravilnik o vrstama fiskalnih računa, tipovima transakcija, načinima plaćanja; Tehničko uputstvo za ESIR (Poreska uprava); Zakon o zaštiti potrošača (Sl. glasnik RS 35/2026); OpenAPI opis Tezga eKase i uputstvo za integratore; sopstvena evidencija eksperimenta u trajanju od tri nedelje.
Česta pitanja
Da li je AI agent uopšte legalan način da se prime narudžbine?
Jeste, jer zakon ne propisuje ko sastavlja narudžbinu nego ko i kad izdaje fiskalni račun. Račun izdaje obveznik fiskalizacije preko odobrenog ESIR-a u trenutku prometa, i to se ne menja time što je poruku pročitao model. Ono što se menja je odgovornost: račun je tvoj, pa je i greška modela tvoja; zato potvrda pre dokumenta.
Koliko košta ovakav tok?
Ne navodim brojke, jer zavise od modela, broja poruka i toga gde n8n radi. Za radionicu sa dvadeset narudžbina dnevno trošak modela je bio zanemarljiv u odnosu na vreme koje je vlasnica uštedela na kucanju. Sama kasa se plaća po paketu, a integratori po računu; sve cene su na sajtu kase i ne zavise od toga da li narudžbina dolazi od čoveka ili modela.
Zašto model ne dobija istoriju kupca ako bi mu pomogla?
Zato što bi istorija kupca u modelu bila podatak drugog lica u sistemu koji razgovara sa trećim licem. Kad kupac kaže „kao prošli put”, model prijavi nejasnoću, a vlasnica pogleda u kasu, gde istorija i treba da stoji. Manje pameti u modelu, manje rizika od curenja; razlika u brzini je jedno pitanje po narudžbini.
Može li model da izda račun ako je usluga već plaćena i izvršena?
Tehnički može, jer API to podržava, ali u mom toku i tada ide kroz potvrdu. Uz usluge se najčešće greši u tome da li je promet nastao (izvršeno ili tek zakazano), a to model ne vidi iz poruke. Kad je zakazano i plaćeno unapred, po Pravilniku ide avansni račun, ne konačni, i tu razliku mora da odluči čovek.
Šta se dešava kad kupac pokuša da „naredi” modelu popust?
Ništa. Cena se u proveri uvek uzima iz kataloga, a ne iz odgovora modela, pa je svejedno šta model misli o popustu. Model ima uputstvo da svaki pokušaj davanja instrukcija iz poruke prijavi kao nejasnoću, ali na to se ne oslanjam; oslanjam se na kod koji ignoriše cenu iz predloga. Popust daje vlasnica, promenom u katalogu, pre potvrde.
Da li kupac zna da razgovara sa agentom?
U eksperimentu agent nije odgovarao kupcu osim pitanjem za razjašnjenje, a i to je bilo označeno kao automatska poruka. Smatram da kupac treba da zna kad mu odgovara automat, i zato što je pošteno i zato što se onda manje ljuti na nespretan odgovor. Kad dođe do iznosa i računa, kupcu piše čovek ili kasa, ne model.
Bi li ovo radilo i za web shop umesto Vibera?
Za web shop model nije potreban: porudžbina već stiže strukturisana, sa šiframa i količinama, i kasa je preuzima webhookom bez ikakvog razumevanja jezika. Model ima smisla tamo gde narudžbina nastaje kao slobodan tekst: poruke, mejl, telefonski poziv prepisan u tekst. Ako imaš shop, spoji ga direktno; ako prodaješ iz poruka, ovaj tok ima smisla.
Ako prodaješ iz poruka i svako veče prepisuješ narudžbine, deo posla koji je čitanje i kucanje može da nestane, a deo koji je odluka ostaje tvoj. Probaj Tezga eKasu u režimu obuke i napravi prvi predračun iz poruke, sa modelom ili bez njega.
