Kome se obratiti za AI agenta ili chatbota u Srbiji

Pišem sisteme koji rade bez nadzora čoveka i godinama ih sam držim u produkciji. Zovem se Lazar Milićević, inženjer sam, i gradim BizFlowAI (bizflowai.io), autonomne AI sisteme za male firme. Ovaj tekst je za vlasnike koji traže izvođača za chatbota ili AI agenta, a nisu sigurni šta tačno traže. Napisao sam ga onako kako bih ja želeo da mi neko objasni da sam sa druge strane stola.

Prvo pojmovi: šta vam zapravo treba

Najčešće greške u ovom poslu počinju pogrešno izabranom vrstom rešenja. Evo moje podele, a to je moje tumačenje, ne standardna terminologija:

Veliki deo posla koji firme nazovu "AI" zapravo je običnim pravilima rešiv. To je dobra vest: jeftinije je, predvidljivije, i nema modela koji može da pogreši. Dobar izvođač će vam to reći pre nego što vam ponudi agenta. Ako izvođač na svaki opis procesa odgovori "to rešavamo AI agentom", to je crvena zastavica.

Praktično pravilo koje koristim: ako se proces može opisati sa "ako je X, uradi Y" za sve slučajeve, to je automatizacija. Ako ulaz dolazi kao slobodan tekst (mejl, poruka, dokument) pa treba razumeti šta piše, tu model ima smisla. Ako sistem treba i da deluje (upiše, pošalje, odobri), to je agent, i tu počinje ozbiljan deo posla.

Šta posao stvarno obuhvata

Isporuka koda je najmanji deo. Cela usluga, kako je ja shvatam, ima šest delova:

1. Razgovor o procesu. Ko šta radi danas, gde se gubi vreme, šta se dešava kad nešto pođe naopako.
2. Povezivanje sa vašim alatima. CRM, mejl, fakturisanje, SEF. Većina rada je ovde, ne u modelu.
3. Izbor modela. Ne po reputaciji, nego po zadatku, jeziku i tome šta se dešava kad model nije dostupan.
4. Testiranje. Na vašim stvarnim primerima, ne na izmišljenim.
5. Puštanje u rad. Postepeno, ne jednim klikom.
6. Nadzor posle puštanja.

Šesta stavka je ta koju firme najčešće tretiraju kao dodatak. Nije dodatak. Sistem koji ne nadzire niko je sistem koji će tiho prestati da radi, i to ćete saznati od kupca, ne od alarma. Ako ponuda ne pominje nadzor, ponuda je nepotpuna.

SEF zaslužuje poseban pasus jer ga mnogi srpski vlasnici imaju u procesu. Fakture se tamo šalju u XML formatu, ne mejlom u PDF-u, a automatsko slanje je moguće kad je vaš računovodstveni softver integrisan preko API-ja (izvor: Paragraf). Javni API ima metode za uvoz izlaznih faktura, prijem ulaznih (uključujući prihvatanje ili odbijanje) i praćenje promena statusa (prezentacija Ministarstva finansija). To su tačke gde agent može da pomogne, ali i tačke gde sistem mora da se prati: portal SEF-a beleži česta ažuriranja (kratko uputstvo za API), pa integracija koja je radila prošlog meseca ne mora da radi sledećeg. Ko vam kaže da je SEF integracija "završen posao", nije je držao u produkciji. Obaveze i rokove po zakonu proverite u aktuelnom tekstu na portalu efaktura.gov.rs, tamo su i najnovije izmene.

Kako izgleda saradnja korak po korak

Ovako ja to radim, i ovako bih očekivao da radi svako ko je ozbiljan:

1. Prvi razgovor. Opisujete proces koji vas košta vremena. Ja pitam koliko se često dešava, ko ga radi, šta se desi kad se pogreši. Cilj je da oboje saznamo da li AI tu ima smisla. Ponekad odgovor je "ne".
2. Mapiranje procesa. Crtam stvarni tok, ne idealni. Stvarni tok ima izuzetke koje niko nije zapisao: "kad je kupac iz Crne Gore, Marija to šalje ručno".
3. Pilot na jednom slučaju. Jedan tip mejla, jedna vrsta fakture, jedan kanal. Ne pokušavam da pokrijem sve odjednom.
4. Produkcija. Pilot postaje stalni sistem, sa praćenjem i jasnim vlasnikom.
5. Merenje. Šta je sistem uradio, šta je ljudi morali da isprave, šta je pao.

Pilot je tu da se nešto izgubi jeftino. Ako se u pilotu ispostavi da podaci nisu dovoljno uredni ili da proces nije ono što ste mislili, bolje je da to saznate posle nekoliko nedelja nego posle punog projekta.

Od čega zavise rok i cena

Nemam namere da ovde navodim iznose ni rokove, jer bi bili izmišljeni bez poznavanja vašeg procesa. Navodim faktore koji ih zapravo pokreću:

• Broj integracija. Svaki spoljni sistem je zaseban izvor grešaka: autentifikacija, promene API-ja, ograničenja. Dva alata nisu duplo teža od jednog, ali nisu ni ista stvar.
• Kvalitet podataka. Ako su podaci u CRM-u nedosledni, agent će biti nedosledan. Čišćenje podataka je često veći posao od samog agenta.
• Ko odobrava izlaz. Ako agent samo priprema nacrt a čovek šalje, rizik je mali i sistem se pušta brzo. Ako agent sam šalje kupcu ili sam upisuje u knjigovodstvo, treba više testiranja, pravila i mehanizama za zaustavljanje.
• Jezik i dijakritika. Srpski sa dijakritikom, bez dijakritike, ćirilica i latinica, mešavina sa engleskim nazivima proizvoda: sve to utiče na ponašanje modela i na pretragu u bazi. Ovo se na demo primerima na engleskom nikad ne vidi.
• Obim nadzora. Alarmi, dnevnik odluka, izveštaji, ko reaguje noću. Što sistem više sme da radi samostalno, to nadzor mora biti ozbiljniji.

Kad vam neko da cenu posle jednog razgovora od pola sata, a nije pitao ništa od ovoga, cena je pogađanje.

Pitanja koja postavite izvođaču pre ugovora

Ko drži sistem posle isporuke? Ako je odgovor "vi", pitajte ko u vašoj firmi to može. Ako je odgovor "mi", pitajte kako tačno i ko reaguje.

Šta se dešava kad model padne ili API vrati grešku? Ovo je pitanje koje razdvaja ljude. Greška 429 kod Anthropic API-ja može da znači privremeni rate limit, ali i dostignut mesečni limit potrošnje, a tada nema retry-after zaglavlja i automatski retry ne pomaže (Claude API errors, rate limits). Kod Z.ai (GLM) isti HTTP 429 pokriva više nepovezanih stanja: rate limit, preopterećen servis, nedovoljan saldo (Z.ai kodovi grešaka). Zato failover ne sme da bude "ako je 429, probaj drugi model", nego mora da razlikuje uzrok. Šta god da izaberete, izbor rezervnog modela je inženjerska odluka, ne propisana procedura, i svaki takav izbor ima sopstvene zamke o kojima treba voditi računa.

Kako znate da radi? Ne "nema grešaka u logu", nego: koja brojka bi pala da sistem prestane da radi, i ko je gleda. O tome je ostatak teksta.

Ko ima pristup podacima? Zakon o zaštiti podataka o ličnosti (tekst zakona) propisuje evidenciju obrade i za rukovaoca i za obrađivača (vodič SHARE Fondacije). Ako izvođač obrađuje podatke vaših kupaca, on će u tom odnosu najčešće biti obrađivač, a uloga zavisi od konkretnog odnosa, pa to proverite u definicijama iz zakona. Izvođač bi trebalo da može da vam kaže gde se podaci čuvaju, ko ih vidi i koji model ih prima. Pravne detalje proverite sa pravnikom, ja nisam pravnik.

Da li imate živ sistem koji sami koristite? Ovo je moje omiljeno pitanje. Izvođač koji svoj sistem drži u produkciji zna kako se ti sistemi kvare. Ja držim autonomni sistem za sadržaj i SEO koji sam objavljuje na više sajtova, sa zakazanim poslovima i bazom. Ne navodim to kao hvalu, nego kao dokaz da sistem radi stalno, a ono što radi stalno se i kvari, i tu se uči.

Greška koja je danima ostala neprimećena

Ovo je priča o nadzoru, ne o tome koliko sam dobar. Registracija mejlom na jednom mom proizvodu danima nije uspevala ni u jednom pokušaju. Nisam je primetio dok mi to nije pokazala analiza po kanalima.

Uzrok je bio banalan. Verifikacija JWT-a kod mog Supabase Auth Hook-a bila je pogrešno podešena. Auth Hook ne šalje JWT, nego poziv potpisan po Standard Webhooks specifikaciji (zaglavlja webhook-id, webhook-timestamp, webhook-signature). Kad je verifikacija JWT-a uključena, platforma pre izvršenja funkcije proverava Authorization zaglavlje, i ako ga nema, vraća 401 a kod funkcije se nikad ne izvrši (Supabase: Authorization headers). Dokumentacija za hookove kaže da se JWT verifikacija isključuje, a autentičnost poruke štiti potpis (Supabase Auth Hooks). Ja sam to propustio, pa je gateway svakom pokušaju registracije mejlom vraćao 401.

Zašto niko nije primetio? Prijava preko Google-a je radila. Ukupan broj korisnika je rastao. Metrika koju sam gledao izgledala je zdravo, a jedan ceo ulaz u proizvod bio je mrtav. Gora stvar: događaj "Registration Failed" nije bio među događajima koje sync povlači, pa pad nije ostavljao trag tamo gde sam gledao.

Detektor koji je nastao posle toga meri registracije po provajderu direktno iz baze i diže alarm kad ima pokušaja bez ijednog kreiranog naloga. Suština nije u konkretnom alatu nego u principu: agregatna metrika krije mrtav deo toka. Zdrav zbir ne znači da je zdrava svaka grana.

Zato kad vas izvođač pita "koje metrike pratimo", dobar odgovor ima razbijanje po kanalu, tipu ulaza ili provajderu, ne samo ukupan broj.

Česte greške pri izboru izvođača

• Demo nije produkcija. Demo radi na tri pažljivo izabrana primera. Produkcija dobija mejl od kupca koji piše pola rečenice, sa prilogom koji je slika. Tražite da vidite sistem koji je radio mesecima, ne snimak ekrana.
• Nema merenja. Ako se "uspeh" ne može izraziti brojem koji se računa iz stvarnih podataka, nije se ni znalo da li radi. "Korisnici su zadovoljni" nije merenje.
• Metrika koja izgleda zdravo dok je deo toka mrtav. Vidi gore.
• Nema vlasnika. Sistem koji je "svačiji" je ničiji. Neko mora da dobije poruku kad nešto padne.
• Nema načina da se sistem zaustavi. Agent koji piše u vaše sisteme mora imati prekidač i mogućnost vraćanja izmena.

Šta bih ja uradio na vašem mestu

Ne bih krenuo od izbora izvođača, nego od jednog procesa. Izaberite onaj koji vas najviše košta vremena i koji se ponavlja, i zapišite ga kako se stvarno odvija, sa izuzecima. Zatim tražite od svakog izvođača odgovor na tri pitanja: šta se dešava kad model padne, kako se vidi da neki deo toka ne radi, i ko to gleda posle isporuke. Ko na ta tri pitanja odgovori konkretno, i priča iz prakse, taj je verovatno držao nešto u produkciji.

Počnite pilotom na jednom slučaju gde agent priprema, a čovek odobrava. Pustite ga da radi nekoliko nedelja pre nego što mu date pravo da sam deluje. I tražite pregled po kanalima, ne samo zbir.

Kako izgleda prvi razgovor

Opišete mi proces koji vas košta vremena: ko ga radi, koliko puta nedeljno, gde se greši. Ja vam kažem iskreno da li AI tu ima smisla, ili je dovoljna obična automatizacija, ili ne treba ništa uvoditi. Odgovor "ne" je potpuno legitiman ishod i bolji je od projekta koji nikome ne treba.

Ako želite da to probamo, javite se preko lazar-milicevic.com/#contact ili pogledajte šta gradim na bizflowai.io.