Softver po meri i AI integracije u Srbiji: kako izabrati

Softver po meri i AI integracije u Srbiji: kako izabrati izvođača

Ja sam Lazar Milićević, osnivač BizFlowAI, i držim u produkciji AI automatizacije i integracije za male i srednje firme. Ovaj tekst pišem zato što svake nedelje dobijem barem jedan poziv od vlasnika firme u Srbiji koji je već potrošio budžet na "AI rešenje" koje nikada nije stiglo do produkcije, ili jeste, ali niko ne zna da li stvarno radi. Cilj mi je da vam dam okvir po kome ćete umeti da razlikujete izvođača koji je nešto stvarno gradio od onoga koji je gledao demo na YouTube-u.

Šta "softver po meri i AI integracije" konkretno znači

Ova fraza se koristi za previše različitih stvari, pa da razgraničim odmah. Softver po meri i AI integracije nisu isto što i:

• Gotova SaaS pretplata (Monday, HubSpot, Pipedrive). Tu birate iz menija, ne gradite.
• Chatbot na sajtu. To je jedan endpoint prema OpenAI ili sličnom, obično dvonedeljni projekat, i skoro nikad ne dodiruje vaše interne sisteme.
• SEF/e-fakture konektor. To je regulatorna integracija, uzak posao sa jasnom specifikacijom.

Kad neko ozbiljno kaže "treba nam softver po meri i AI integracije", u praksi to skoro uvek znači orkestraciju. Više sistema koji moraju da rade zajedno, po rasporedu, sa AI slojem koji radi konkretan posao (klasifikacija, ekstrakcija, generisanje sadržaja, odgovor korisniku) i sa merenjem koje potvrđuje da sistem stvarno radi ono što treba.

Da bude konkretno, evo kako izgleda jedan realan stack koji držim u produkciji:

• Baza: PostgreSQL 16 u Dockeru, sa pgvector ekstenzijom za semantičku pretragu.
• Aplikativni sloj: Python workeri za ETL i AI pozive, Next.js dashboard za operatera.
• Raspored poslova: Task Scheduler sa oko 30 imenovanih poslova, svaki sa svojim intervalom, retry politikom i alarmom.
• LLM sloj: Claude preko OAuth kao primarni, GLM kao failover kad Anthropic vrati 429 ili 529.
• Lokalni GPU: RTX 3060 za TTS i deo generisanja slika, da tokeni ne odu u nebo.
• Merenje: posebna tabela sa metrikama po poslu, plus dashboard koji pokazuje šta je izvršeno, šta je otkazano, i šta je "prošlo" ali sumnjivo.

To je jedan primer. Vaš stack može biti drugačiji, ali princip je isti: baza, raspored, AI sloj sa failoverom, i merenje. Ako izvođač ne priča o sve četiri stvari, verovatno gradi demo, ne sistem.

Kako izgleda ozbiljan proces saradnje

Ovde ljudi obično gube novac. Ne zato što je tehnologija skupa, nego zato što se skoči na kodiranje pre nego što se razume tok podataka.

Proces koji ja vodim ima pet faza, i redosled je važan:

1. Discovery (1 do 2 sedmice). Sednem sa osobom koja zaista radi taj posao, ne sa menadžerom. Snimim korak po korak šta rade, gde kliknu, gde kopiraju iz jednog sistema u drugi, gde greše. Pišem to na papiru pre nego što otvorim editor.
2. Mapiranje toka podataka. Nacrtam gde podatak ulazi, gde stoji, ko ga menja, gde izlazi. Ovde se skoro uvek otkrije da ne postoji "izvor istine", nego tri Excel-a i jedan mejl folder. To se rešava pre AI dela.
3. Pilot na jednom uskom procesu. Biram najbolniji, ali ograničen proces. Ne "digitalizujmo prodaju", nego "automatizujmo klasifikaciju dolaznih upita iz mejla u tri kategorije, sa procenom uspešnosti". Pilot traje 4 do 8 nedelja.
4. Merenje u produkciji. Pustimo pilot da radi barem mesec dana i gledamo brojke. Ne "izgleda dobro", nego: koliko poruka je klasifikovano, koliko je bilo tačno, koliko je AI odbio da odgovori, koliko je operater morao da interveniše.
5. Širenje. Tek posle ovoga se priča o drugom, trećem procesu.

Ako vam neko na prvom sastanku ponudi "kompletno AI rešenje za celu firmu za tri meseca", to je crvena zastavica. Ozbiljan tim počinje malo, meri, pa širi.

Od čega zavise rok i cena

Neću vam dati cifre jer bi bile lažne bez konteksta. Ali evo faktora koji stvarno pomeraju procenu, po redu značaja:

• Broj i kvalitet integracija. Da li vaš ERP ima API, ili moramo da čitamo iz baze pozadi? Da li CRM ima webhook-ove ili moramo da polujemo? Svaka integracija bez API-ja produžava rok za nedelje.
• Broj procesa koji se orkestriraju. Jedan proces sa AI slojem je jedno. Petnaest povezanih poslova koji zavise jedan od drugog je red veličine više posla, ne linearno više.
• Gde ide sistem. Na vašoj infrastrukturi (on-premise, VPS, vaš AWS nalog) ili kod izvođača? Ako ide kod vas, treba više vremena za setup, monitoring, backup, ali ste vlasnik.
• Volumen i cena tokena. Ako sistem šalje 100 hiljada LLM poziva mesečno, cena tokena nije zanemarljiva. Treba dizajn koji smanjuje pozive (caching, batching, mali modeli za jeftine korake).
• Koliko dugo se drži u produkciji. Ovo se najčešće ignoriše. Izgradnja je 30 do 50 posto posla. Ostatak je održavanje, monitoring, reakcija kad se nešto pokvari. Ako izvođač ne planira održavanje, planirajte ga sami.

Sve ostalo (dizajn dashboarda, "AI magija") je šum. Ovih pet stvari određuju budžet.

Sedam pitanja koja treba postaviti izvođaču

Ovo je deo koji preporučujem da odštampate i ponesete na sastanak. Ako izvođač ne ume da odgovori direktno, sa primerom, imate odgovor.

1. Da li vi lično držite nešto u produkciji što traje duže od 6 meseci?
Ne "smo radili za klijenta X", nego "trenutno radi, ovo je dashboard, evo šta je otkazalo prošle nedelje". Ljudi koji su samo gradili demo ne umeju da vam pokažu ovo.

2. Kako merite da sistem stvarno radi, ne samo da "ne pada"?
Ovo je najvažnije pitanje u celom tekstu i zaslužuje ratni izveštaj.

Imao sam sistem sa registracionim levkom koji je 17 dana bio mrtav, a metrika nije pokazivala ništa loše. Sve zeleno. Zašto? Zato što je moja sync lista poruka koje pratim uključivala "Registration Success", "Payment Failed", "Email Bounced", ali ne i "Registration Failed". Kad se registracija rušila zbog validacije, poruka je odlazila u log, ali je moj monitoring nije video. Sa strane operatera je izgledalo kao da nema novih registracija (što je, statistički, izgledalo kao normalno slabija sedmica). 17 dana. Otkrio sam slučajno, gledajući raw log jer mi je frontend timing izgledao čudno.

Pouka: monitoring koji gleda samo "da li poslovi prolaze" je nedovoljan. Treba detekcija tihih otkaza - anomalija u volumenu, provera da očekivane poruke stižu, alarm kad neki tok bude tiši nego obično. Ako vam izvođač na ovo pitanje odgovori "imamo Uptime Robot", to nije dovoljno. Uptime Robot vam kaže da server živi, ne da vaš biznis proces radi.

3. Šta se dešava kad LLM API vrati 429 ili 529?
Odgovor koji hoćete da čujete: "imamo failover na drugi model, sa retry-jem i exponential backoff-om, i alarmom ako failover traje duže od X minuta". Odgovor koji ne želite: "pa, obično ne vraća".

4. Ko plaća tokene, i kako pratimo potrošnju?
Ovo mora da bude eksplicitno u ugovoru. Da li izvođač prosleđuje trošak, ili je fiksno mesečno? Da li postoji dashboard sa dnevnom potrošnjom? Da li postoji alarm ako potrošnja skoči 3x preko proseka? (Da, dešava se, obično zbog loop-a u kodu.)

5. Ko je vlasnik koda, kredencijala i podataka?
Ako sutra prekinete saradnju, da li dobijate git repo, pristup bazi, dokumentaciju? Ovo pišete u ugovor, ne dogovarate na reč.

6. Kako izgleda deployment i rollback?
"Puštamo u petak popodne pa vidimo" nije odgovor. Hoćete da čujete o staging okruženju, o mogućnosti da se vrati prethodna verzija za par minuta, i o tome kako se testira promena pre nego što udari na produkciju.

7. Šta radite kad korisnik prijavi da nešto ne radi?
Ovde vidite da li postoji proces. Ko prima poziv, koliko brzo je odgovor, kako se prati da je problem stvarno rešen a ne samo "restartovali smo servis pa je proradilo". Ako je odgovor "javite mi na WhatsApp", to je fer za mikro projekat, ali ne za sistem od koga vam zavisi biznis.

Šta bih ja uradio na vašem mestu

Ako birate izvođača, uradio bih ovo, ovim redom:

• Pitao bih za jedan konkretan sistem u produkciji i tražio da vidim dashboard uživo. Ne slajdove. Uživo. Ako izvođač ne može to da pokaže (zbog NDA ili nema šta da pokaže), pitajte ga da vam objasni arhitekturu jednog realnog sistema koji je radio, sa brojevima. Ko ne ume da priča o brojevima, nije bio blizu produkcije.
• Počeo bih sa pilotom fiksne cene, ne sa velikim ugovorom. 4 do 8 nedelja, jedan proces, jasan kriterijum uspeha. Ako pilot ne uspe, znate to za dva meseca, ne za godinu.
• Insistirao bih na tome da kod ide u vaš git repo od prvog dana. Ne "predaćemo vam na kraju". Od prvog commit-a.
• Tražio bih pisani plan monitoringa pre nego što se piše kod. Šta se meri, kako se detektuje tihi otkaz, ko dobija alarm, ko reaguje. Ako izvođač ovo dopisuje na kraju, meriće samo "da server živi".
• Ne bih platio nikome ko obećava "AI koji uči sam" bez konkretnog opisa šta to znači. Ta fraza je marketing. Model se ne "doučava" kod vas u produkciji bez ozbiljne infrastrukture i troška, i skoro nikad vam ne treba.

Ako izvođač prođe kroz ovih pet stvari bez frke, verovatno znate šta radi.

Kako izgleda prvi razgovor sa mnom

Ako vas ovo pogodilo i mislite da bi imalo smisla da porazgovaramo, prvi poziv je oko 30 minuta, bez obaveze. Interesuje me šta pokušavate da rešite i koji je najbolniji proces, ne prezentacija vaše firme. Na kraju tog razgovora vam kažem ili "mislim da ovo možemo, evo kako", ili "ovo nije za mene, evo kome bih preporučio da se javite". Nema srednjeg.

Više o tome kako radim je na bizflowai.io, a direktan kontakt je na lazar-milicevic.com/#contact. Ako ništa drugo, iskoristite listu od sedam pitanja iznad na sledećem sastanku sa bilo kojim izvođačem. Uštedeće vam više nego što mislite.