Srpski
Aleksandar Basara
Zakažite razgovor

AI agenti u produkciji: Zašto je observability važniji od samog modela

Kako pouzdano koristiti AI agente u produkciji: tracing, evaluacija, tool pozivi, bezbednost, troškovi i OpenTelemetry, uz tehničke primere.

9. novembar 2026.

  • Kvalitet modela nije dovoljan za pouzdanog produkcionog agenta.
  • Traces objašnjavaju izvršavanje, a evaluacija potvrđuje poslovni rezultat.
  • Pratite uspešno završene zadatke, tool greške, P95 latenciju i trošak.
  • Observability mora štititi podatke i ne zamenjuje autorizaciju.
  • Bezbedan deployment zahteva odobrenja, regression testove i fallback.

Dobar model nije isto što i pouzdan AI agent

AI agent odlično rešava testni zahtev. Nekoliko sati kasnije isti workflow nailazi na nestabilan API, zastarele podatke ili nedovoljna prava pristupa. Odgovor i dalje zvuči uverljivo, ali zadatak zapravo nije završen. Problem ne mora da bude u jezičkom modelu. Često nastaje u sistemima sa kojima on radi.

U produkciji nije dovoljno meriti kvalitet pojedinačnog odgovora. Tim mora da zna koje podatke je agent koristio, koje alate je pozvao, šta se dogodilo u povezanim sistemima i da li je poslovni rezultat ispravan. Tu počinje observability.

Traces povezuju korake jednog izvršavanja, metrike pokazuju obrasce kroz veliki broj zahteva, a logovi beleže relevantne tehničke događaje. Uz to su potrebni evaluacija, verzionisanje i provera stvarno završenih zadataka. Observability olakšava otkrivanje uzroka problema; ne zamenjuje kontrole koje probleme sprečavaju.

Zašto je observability AI agenata posebno važan u 2026.

Google je u novembru 2026. objavio general availability observability funkcija za BigQuery Data Agents, uključujući execution traces, latenciju, potrošnju i troškove. Ovo je jasan signal da razvoj agenta nije kraj posla: jednako je važno razumeti kako se ponaša u stvarnom procesu.

Sam tracing ne garantuje dobar governance niti tačan rezultat. Uspešan HTTP odgovor može da sadrži pogrešnu preporuku. U potpunosti zabeležen workflow može ipak da izvrši nedozvoljenu akciju. Zato su potrebni evaluacija, jasne granice pristupa i odgovornost za produkcioni sistem.

Primer iz prakse: AI agent za servisne zahteve u industriji

Zamislimo proizvođača industrijske opreme koji želi bržu obradu servisnih tiketa. Agent čita opis problema, proverava podatke o proizvodu i ugovoru u ERP-u, pretražuje tehničku dokumentaciju i predlaže odgovor servisnom timu. Nejasne slučajeve prosleđuje zaposlenom. Slanje odgovora klijentu ili upis u operativni sistem zahtevaju posebna odobrenja.

Pilot radi dobro. U produkciji jednom tiketu nedostaje serijski broj, za drugi agent pronađe zastarelo uputstvo, a kod trećeg API poziv završi timeout-om. Model može da napiše ubedljiv tekst i kada nema dovoljno osnova za tačnu odluku.

Zato trace treba da pokaže verziju dokumenta, svaki poziv alata, trajanje, retry pokušaje i ishod provere dozvola. Tek stručna provera potvrđuje da li je servisni zahtev zaista rešen. Ovo je ilustrativan arhitektonski primer, a ne tvrdnja o konkretnom Valanor projektu.

Arhitektura: odvojiti model, podatke i dozvole za akcije

Workflow API prima zahtev i dodeljuje mu jedinstveni ID. Orkestracija povezuje pretragu podataka, pozive modela i alate. Policy layer na serveru proverava identitet, tenant, dozvole i ciljne resurse. Osetljive akcije zahtevaju odobrenje, a idempotency key sprečava slučajno ponavljanje upisa.

Svaki bitan korak dobija span: workflow, pretraga dokumenata, inference i izvršavanje alata. Zajednički trace ID povezuje ih u jednu celinu. Poseban audit log beleži koju je izmenu ciljni sistem zaista potvrdio. Trace objašnjava izvršavanje; poslovna validacija ocenjuje rezultat.

Za ovakvu kontrolu nisu automatski potrebni microservices. Jedna dobro instrumentirana aplikacija sa jasnim ugovorima za alate često je razumniji izbor. Ključno je razdvojiti predlog modela od akcije koju je sistem stvarno autorizovao.

Koje signale mora da pruža AI agent u produkciji

SlojSignal ili metrikaŠta time proveravamo
WorkflowUdeo uspešno završenih zadataka i eskalacijaDa li je agent zaista završio poslovni zadatak?
ModelVerzija modela, tokeni, latencija inferencijeKako model i prompt utiču na kvalitet, vreme i trošak?
Pretraga i podaciVerzija izvora, kvalitet pretrage, prazni rezultatiDa li je uzrok greške u podacima koji nedostaju ili su zastareli?
Tool poziviNaziv alata, status, timeout, retry, dozvoleDa li je integracija otkazala ili je nedozvoljeni poziv blokiran?
AkcijeStatus odobrenja, idempotency key, rezultatDa li je upis odobren i izvršen bez dupliranja?
KvalitetUtemeljenost u izvorima, potvrđeni rezultati, ljudske ispravkeDa li je rezultat tačan i proverljiv?
OperacijeP95 latencija, stopa grešaka, kapacitetGde nastaju uska grla i kada tim mora da reaguje?
TroškoviTrošak po uspešno završenom zadatkuKoliko košta stvarno upotrebljiv rezultat, uključujući ponavljanja?

Tracing objašnjava tok; evaluacija proverava rezultat

Trace može da objasni zašto je workflow postao spor: pretraga nije vratila podatke, API je istekao ili je model pokušao novi poziv. To ne dokazuje da je odgovor tačan. Tehnički uspešno izvršavanje i uspešno završen poslovni zadatak nisu ista stvar.

Za evaluaciju su potrebni reprezentativni slučajevi i proverljivi rezultati. Kod servisnog agenta to znači ispravnu identifikaciju proizvoda, relevantno uputstvo, dozvoljene pozive alata, pravilnu eskalaciju i tačnu preporuku. Automatsko ocenjivanje je korisno, ali kod važnih odluka ne zamenjuje determinističke provere i stručni review.

Ponekad potvrda stiže tek kasnije, na primer kada serviser posle nekoliko dana potvrdi dijagnozu. Takvu ground truth informaciju treba odvojiti od brzih, približnih pokazatelja dostupnih odmah po završetku workflow-a.

Tracing poziva alata pomoću OpenTelemetry

Ovaj TypeScript primer instrumentira poziv alata koji je već autorizovan. Ne implementira autentifikaciju niti sam proces odobrenja. Server mora da sprovede te provere nezavisno od modela. Produkciona implementacija zahteva i context propagation, sampling, exporter, idempotentnost i kontrolisano rukovanje greškama. Osetljivi podaci se namerno ne upisuju u trace.

TypeScript
import {trace, SpanStatusCode} from '@opentelemetry/api'
const tracer = trace.getTracer('service-agent')

export async function callTool<T>(
  name: string,
  requestId: string,
  executeAuthorizedAction: () => Promise<T>
): Promise<T> {
  return tracer.startActiveSpan('agent.tool', async (span) => {
    span.setAttribute('agent.tool.name', name)
    span.setAttribute('agent.request_id', requestId)

    try {
      // Server mora da proveri prava i odobrenja
      // pre nego sto se pozove autorizovana akcija.
      const result = await executeAuthorizedAction()
      span.setAttribute('agent.tool.status', 'success')
      return result
    } catch (error) {
      span.setStatus({code: SpanStatusCode.ERROR})
      span.setAttribute('agent.tool.status', 'error')
      throw error
    } finally {
      // Ne upisivati promptove, lozinke i podatke klijenata.
      span.end()
    }
  })
}

Pet metrika koje treba pratiti od početka

Task Completion Rate pokazuje koliko je zadataka stvarno i proverljivo završeno, a ne koliko je odgovora generisano. Odvojeno pratite autonomno završene zadatke, eskalacije i naknadne ispravke. Veliki broj odgovora uz mnogo ručnog rada ne znači bolju automatizaciju.

Tool Failure Rate razdvaja timeout, greške u dozvolama, neuspešnu validaciju i prazne rezultate pretrage. Tako se vidi da li problem nastaje u modelu, podacima ili integraciji.

P95 Workflow Latency meri vreme do upotrebljivog rezultata, a ne samo vreme inference-a. Pretraga, API pozivi, retry i odobrenja utiču na ukupno trajanje.

Cost per Successful Task uključuje upotrebu modela, infrastrukturu, spoljne servise, ponovljene pozive i ljudske ispravke. Jeftin model ne mora da znači jeftin poslovni proces.

Escalation Rate i Correction Rate pokazuju kada agent pravilno prepoznaje neizvesnost i koliko često ljudi moraju da popravljaju njegov rezultat. To su važni signali za određivanje realnih granica automatizacije.

Evaluacija pre i posle deployment-a

Offline testovi treba da obuhvate uobičajene zahteve, nedostajuće podatke, kontradiktorne izvore, zastarele dokumente, padove alata, duple zahteve i zlonamerna uputstva. Rezultati moraju da se povežu sa konkretnom verzijom modela, prompta, alata i testnih podataka. Dobar prosečan score ne sme da prikrije kritične greške.

U produkciji se menjaju podaci, dokumentacija i način rada korisnika. Reprezentativni slučajevi iz stvarnog rada, pripremljeni u skladu sa pravilima zaštite podataka, postaju novi regression testovi. Release gates, rollback i povratak na ručnu obradu omogućavaju kontrolu kada kvalitet opadne.

Primer kriterijuma za odobravanje release-a

Ovaj YAML predstavlja primer arhitektonskih pravila, ne gotovu konfiguraciju za konkretan CI alat. Navedeni pragovi su ilustrativni. Stvarne vrednosti zavise od rizika i izmerene početne osnove. Kritični upisi i dalje zahtevaju tehničke kontrole i odgovarajuća ljudska odobrenja.

YAML
# Ilustrativni pragovi; nisu univerzalni produkcioni ciljevi
workflow: service-ticket-agent
dataset: service-tickets-v3
checks:
  - metric: required_field_accuracy
    minimum: 0.98
  - metric: unauthorized_write_actions
    maximum: 0
  - metric: p95_workflow_latency_ms
    maximum: 10000
  - metric: escalation_on_uncertainty
    required: true
release:
  human_approval: true
  rollback_enabled: true

Zaštita podataka: telemetrija ne sme da postane druga baza klijenata

AI agenti često obrađuju CRM zapise, email poruke, ugovore, tehničku dokumentaciju i podatke o ličnosti. Slanje kompletnih promptova i rezultata alata u eksternu observability platformu otvara dodatni tok osetljivih podataka i nova pravila pristupa.

Podrazumevano beležite tehničke metapodatke: trace ID, verziju komponente, naziv alata, status, trajanje i agregiranu potrošnju. Za čuvanje sadržaja potreban je jasan cilj, odgovarajući pravni osnov i mere zaštite. Pseudonimizovani podaci i dalje mogu biti podaci o ličnosti.

Redaction pre slanja telemetrije, pristup po ulogama, enkripcija, ograničen retention i kontrolisani debug pristup deo su arhitekture. Čak i exception poruke ili parametri alata mogu otkriti poverljive informacije. Proverite šta konkretna verzija SDK-a automatski beleži.

Security: praćenje napada nije isto što i njegova prevencija

Prompt injection može da stigne kroz dokument, web stranicu ili odgovor alata. Zlonamerno uputstvo u prilogu može pokušati da navede agenta da izveze podatke o klijentima. Trace pomaže da se incident rekonstruiše, ali ne sprečava neovlašćeni pristup.

Spoljni sadržaj treba tretirati kao podatke, ne kao pouzdana uputstva. Least privilege, server-side authorization, allowlist za alate, provera resursa i odobrenja za kritične akcije ograničavaju posledice. Model ne sme sam da odlučuje koje upise sme da izvrši.

Retry zahteva istu pažnju. Posle timeout-a aplikacija možda ne zna da li je ciljni sistem već izvršio akciju. Bez idempotentnosti nastaju dupli tiketi, porudžbine ili drugi neželjeni efekti. To nije problem koji rešava bolji prompt.

OpenTelemetry, Langfuse ili ugrađeni alati platforme?

OpenTelemetry je vendor-neutral osnova za traces i metrike. Posebno odgovara organizacijama koje već imaju observability za backend i API sisteme. GenAI Semantic Conventions opisuju zajedničke atribute modela i alata; nivo podrške zavisi od konkretnih verzija i instrumentacije.

Langfuse dodaje funkcije specifične za LLM, poput tracing-a, evaluacije i verzionisanja promptova. Pomaže developerima i stručnim timovima da zajedno analiziraju izvršavanja. Hosting, prenos podataka i dozvole moraju da budu posebno rešeni.

OpenAI Agents SDK i Google Cloud imaju i sopstvene tracing funkcije. One mogu ubrzati integraciju, ali uvode zavisnost od konkretnog ekosistema. Izbor treba prilagoditi postojećoj infrastrukturi, zahtevima za podatke i načinu rada sistema.

Od pilota do kontrolisanog produkcionog workflow-a

Počnite od jednog jasno ograničenog zadatka i definišite šta znači proverljiv uspeh. Zatim navedite izvore podataka, ugovore za alate, dozvole, telemetriju i vrste grešaka. Testirajte prazne rezultate, timeout, duple pozive, neispravne podatke i zabranjene akcije.

U osetljivim procesima krenite od read-only funkcija ili upisa koji zahtevaju ljudsko odobrenje. Nivo autonomije povećavajte tek kada stvarni rezultati i evaluacija opravdavaju takvu odluku. Kontrolisani rollout, alarmi, regression testovi i fallback štite poslovni proces.

U okviru našeg Data & AI Engineering rada povezujemo tokove podataka, agent arhitekturu i softver sa operativnim procesima.

Za širi tehnički kontekst pogledajte i razvoj AI i Machine Learning sistema.

Zaključak: pouzdanost zavisi od celog sistema

Napredniji model može poboljšati pojedinačne odgovore. Ne može sam da popravi nestabilan API, nedovoljna prava ili nejasna pravila odobravanja. Poslovna vrednost nastaje kada agent zadatke završava pouzdano, proverljivo i uz prihvatljiv trošak.

Observability daje timu informacije potrebne da razume ponašanje sistema. Uz evaluaciju, security i jasnu odgovornost, dobar demo postaje kontrolisana produkciona funkcija. Nije svakom agentu potrebna velika monitoring platforma, ali svakom produkcionom agentu treba pregledno izvršavanje i definisan način postupanja pri greškama.

Česta pitanja o AI agentima u produkciji

Koja je razlika između monitoring-a i observability-ja?

Monitoring prati unapred definisane signale i odstupanja. Observability omogućava istraživanje neočekivanih problema kroz traces, metrike i događaje. Kod AI agenata važne su i verzije modela, prompta, podataka i alata.

Šta treba beležiti u trace-u AI agenta?

Pre svega tehničke metapodatke kao što su naziv alata, status, trajanje, verzija i agregirani trošak. Promptovi, dokumenti i podaci o ličnosti ne smeju se beležiti bez posebne provere.

Da li je Langfuse dovoljan za produkcioni monitoring?

Langfuse pokriva važne LLM traces i evaluaciju. Zavisno od arhitekture, potrebni su i monitoring infrastrukture i API-ja, server-side dozvole, alarmi i stručne provere rezultata.

Kako meriti kvalitet AI agenta?

Proveravajte stvarno završene zadatke, ispravne akcije, eskalacije, ljudske ispravke, vreme izvršavanja i trošak po uspešnom zadatku. Offline testovi i realni produkcioni slučajevi dopunjuju se.

Može li observability sprečiti prompt injection?

Ne. Observability pomaže u analizi. Prevencija zahteva ograničena prava, server-side authorization, sigurne tool ugovore i odobrenja za osetljive akcije.

Kada treba uvesti napredni observability stack?

Potreba raste kada agenti koriste više spoljnih sistema, izvršavaju upise ili učestvuju u kritičnim procesima. Manji pilot može početi jednostavnom instrumentacijom ako je uzrok grešaka i dalje proverljiv.

Tehnička dokumentacija i izvori

OpenTelemetry: GenAI Semantic Conventions

OpenAI Agents SDK: Tracing

Langfuse: Observability i evaluacija

OWASP: LLM Top 10

Google Cloud: novosti iz Data Analytics oblasti

AI agenti u produkciji

Od prototipa do kontrolisanog produkcionog sistema

Razvijamo AI agente sa jasnim granicama pristupa, proverljivim tokovima podataka, evaluacijom i observability pristupom. Definišemo arhitekturu, odobrenja i operativne kontrole za integraciju u poslovne procese.

Razgovarajmo o AI projektu

Aleksandar Basara

Managing Director

aleks@valanor.co

Bulevar Milutina Milankovića 7Đ, 11070 Beograd, Srbija

Aleksandar Basara