← Nazad na blog

Kada AI agenti prestanu samo da razgovaraju i počnu da deluju

AI asistent koji ume da odgovara na pitanja može biti vrlo koristan. AI agent koji može da proveri nalog klijenta, pronađe fakturu, pošalje upit internoj bazi, izmeni zapis u CRM-u, otvori zahtev korisničkoj podršci ili pokrene poslovni proces može doneti daleko veću vrednost.

Ali sa tom mogućnošću nastaje i sasvim druga vrsta rizika.

Kako kompanije prelaze sa eksperimenata sa generativnom veštačkom inteligencijom na AI agente koji rade u produkciji, glavno pitanje više nije samo da li model ume da pruži dobar odgovor. Mnogo je važnije kako mu omogućiti kontrolisan pristup sistemima koji su mu potrebni da bi zaista obavio posao.

Zamislimo agenta zaduženog za korisničke operacije. Da bi rešio samo jedan slučaj, možda mora da pronađe klijenta u Salesforce-u, proveri porudžbinu u internoj bazi, preuzme podatke o isporuci sa logističke platforme, pregleda istoriju komunikacije sa podrškom i pripremi povraćaj novca ili zamensku pošiljku. Svaki od tih sistema ima sopstveni API, način autentifikacije, nivoe pristupa, strukturu podataka i poslovna pravila. Kada isti problem proširite na više agenata i desetine sistema, složenost integracija vrlo brzo raste.

Model Context Protocol, odnosno MCP, rešava deo tog problema tako što uvodi standardizovan način na koji AI aplikacije mogu da otkriju spoljne alate, resurse i servise i da sa njima komuniciraju. I sam MCP projekat poslednjih meseci sve više pažnje posvećuje pitanjima koja postaju važna tek kada se takve veze uvedu u stvarne organizacije: skaliranju, autorizaciji na nivou kompanije, identitetu agenata, upravljanju i bezbednosti. (MCP razvojni plan)

Takva standardizacija ima jasnu vrednost. Kompanija koja razvija nekoliko AI aplikacija ne bi trebalo za svakog novog agenta iznova da pravi iste integracije sa CRM-om, bazama podataka, razvojnim alatima ili internom pretragom.

Međutim, standardizacija otvara još važnije pitanje:

Šta AI agent zapravo sme da uradi kada se jednom poveže sa tim sistemima?

Agent može da izabere koji će alat pozvati na osnovu zahteva korisnika, podataka preuzetih iz drugog sistema, sadržaja dokumenta ili instrukcija koje se nalaze u informacijama koje je upravo obradio. Može i da spoji ovlašćenja iz više sistema na način koji nijedna pojedinačna integracija nije predvidela. Put od korisničkog zahteva do konkretne akcije zato može biti manje determinističan nego kod klasične aplikacije.

Jedno je kada agent korisničke podrške može samo da pročita status porudžbine. Sasvim je drugo kada može da pristupi podacima klijenata, odobri povraćaj novca, šalje spoljne poruke, menja naloge i izvršava akcije u produkcionim sistemima.

Zbog toga se povezivanje AI agenata sa poslovnim sistemima ne može posmatrati samo kao problem integracije. To je istovremeno pitanje identiteta, autorizacije, upravljanja, praćenja rada sistema i granica autonomije.

MCP specifikacija 2026-07-28 napravila je važan korak ka ozbiljnoj primeni u produkciji: uvedeno je jezgro protokola bez stanja sesije, usmeravanje preko zaglavlja pogodno za gateway infrastrukturu, ojačani su mehanizmi autorizacije i formalizovan je sistem proširenja. Ipak, nijedan protokol ne može umesto organizacije da definiše njenu bezbednosnu politiku. MCP može da standardizuje način na koji AI aplikacija dolazi do određenog alata, ali sam po sebi ne odlučuje da li agent taj alat sme da koristi, koje granice važe, kada je potrebna ljudska saglasnost niti koliku štetu kompromitovan ili pogrešno usmeren agent uopšte može da napravi. (MCP specifikacija 2026-07-28)

Te odluke pripadaju arhitekturi koja okružuje MCP.

U ovom vodiču objašnjavamo kako takvu arhitekturu treba postaviti, gde nastaju najvažniji bezbednosni rizici, zašto autorizacija nije isto što i dozvola da se konkretna akcija izvrši i kako kompanije mogu agentima da daju dovoljno pristupa da budu korisni, ali ne i više ovlašćenja nego što njihov zadatak zaista zahteva.

Šta MCP menja u arhitekturi poslovnih AI sistema

U najjednostavnijem obliku, MCP je standardizovan način na koji AI aplikacije komuniciraju sa spoljnim sistemima.

To mogu biti baze podataka, interni API-ji, razvojni alati, sistemi za upravljanje dokumentima, SaaS aplikacije, servisi za pretragu ili gotovo bilo koji drugi sistem kome AI aplikacija mora da pristupi da bi obavila koristan posao.

Pojednostavljeno, arhitektura izgleda ovako:

AI aplikacija / agent
          │
          ▼
      MCP klijent
          │
          ▼
      MCP server
          │
          ▼
     Spoljni sistem

Aplikacija u kojoj model radi najčešće se naziva host. U okviru hosta nalazi se MCP klijent koji komunicira sa jednim ili više MCP servera. Ti serveri izlažu mogućnosti koje aplikacija može da otkrije i koristi.

MCP server ne zamenjuje CRM, bazu podataka, GitHub repozitorijum, ERP API ili interni servis. Njegova uloga je da prema AI aplikaciji obezbedi standardizovan interfejs ka tim sistemima.

Posebno su važna tri osnovna elementa:

• Alati (tools) izlažu operacije koje je moguće pokrenuti, na primer pretragu klijenta, otvaranje zahteva podršci, proveru porudžbine ili poziv internog API-ja.
• Resursi (resources) izlažu informacije koje aplikacija može da pročita i koristi kao kontekst, poput dokumentacije, zapisa, datoteka ili sadržaja iz repozitorijuma.
• Promptovi (prompts) predstavljaju ponovo upotrebljive obrasce ili instrukcije za rad sa modelom.

Ta razlika je važna zato što čitanje informacije i izvršavanje akcije ne nose isti nivo rizika. Izložiti pravilnik za zaposlene kao resurs nije isto što i izložiti alat kojim je moguće promeniti podatke za obračun zarada.

Od pojedinačnih integracija do infrastrukture koja se ponovo koristi

Bez zajedničkog sloja, različiti timovi često iznova grade veoma slične integracije. Prodajni agent može imati jedan Salesforce konektor, agent korisničke podrške drugi, dok treća aplikacija razvija sopstveni način pristupa bazi podataka. Autentifikacija, šeme, nadzor i obrada dozvola tada počinju da se razlikuju čak i kada svi rade sa istim poslovnim sistemom.

MCP omogućava da se takve veze tretiraju kao infrastruktura koja se može ponovo koristiti:

                     ┌── CRM MCP server
                     ├── MCP server za podršku
AI aplikacije ────────┼── ERP MCP server
                     ├── MCP server za razvojne alate
                     └── MCP server za interne podatke

Dobro projektovan CRM MCP server može da izloži kontrolisan skup mogućnosti za više ovlašćenih aplikacija. Kada se promeni API CRM sistema, izmena se tada rešava na toj integracionoj granici, umesto da se isti posao ponavlja u svakom agentu zasebno.

MCP, dakle, ne uklanja posao oko integracije. Menja mesto na kome se taj posao obavlja.

Može da smanji i vezanost za konkretnu aplikaciju ili dobavljača. Ako je neka mogućnost dostupna kroz standardan interfejs, a ne ugrađena isključivo u rešenje jednog proizvođača AI platforme, kasnije je može koristiti i drugi kompatibilni host. To ne znači potpunu nezavisnost od dobavljača, ali sprečava da svaka poslovna integracija zauvek ostane vezana za prvu AI aplikaciju za koju je napravljena. Zvanični MCP SDK upravo je zasnovan na toj podeli između servera koji izlažu mogućnosti i hostova koji ih koriste. (MCP SDK)

MCP postaje prirodna tačka kontrole

Na nivou veće organizacije, infrastruktura koja se ponovo koristi donosi još jednu važnu prednost: stvara mesto na kome zajedničke kontrole mogu dosledno da se primene.

Umesto da svaki tim koji razvija agenta posebno implementira autentifikaciju, autorizaciju, logovanje, ograničenja poziva, mrežne politike, upravljanje pristupnim podacima i bezbednosne provere, deo tih odgovornosti može da se premesti u zajedničku infrastrukturu.

Pojednostavljeno:

AI aplikacije
       │
       ▼
Identitet i okruženje agenta
       │
       ▼
Politike / autorizacija
       │
       ▼
MCP pristupni sloj
       │
       ▼
Poslovni sistemi

Međutim, ista standardizacija koja smanjuje dupliranje posla istovremeno može da koncentriše rizik. Ako se veliki broj aplikacija oslanja na isti MCP server ili isti pristupni sloj, slabost na tom mestu može da pogodi sve njih. Pogrešno postavljena pravila pristupa mogu da se standardizuju jednako efikasno kao i dobra integracija.

Zato pravo pitanje za kompaniju nije samo:

Koje sisteme možemo da povežemo preko MCP-a?

Mnogo korisnije pitanje glasi:

Koje poslovne mogućnosti treba učiniti dostupnim kojim agentima i pod kojim uslovima?

CRM, na primer, ne mora agentu da bude izložen kao jedan neograničen administrativni interfejs. MCP server može da ponudi usko definisane operacije kao što su search_customer, read_order_history, add_internal_note ili request_account_update, dok sve druge administrativne funkcije ostaju nedostupne.

Dobra MCP arhitektura zato polazi od konkretnog toka rada, a ne od svega što pozadinski sistem tehnički ume da uradi.

Bezbednosni problem MCP-a u poslovnom okruženju

Klasična API bezbednost i dalje je neophodna u MCP okruženju, ali sama po sebi nije dovoljna. Upravo se ovde MCP neposredno ukršta sa širom arhitekturom sajber-bezbednosti.

Klasična aplikacija najčešće dolazi do API-ja kroz unapred napisanu logiku. Programeri definišu koja se krajnja tačka poziva, pod kojim uslovima, koji parametri se prihvataju i šta se dešava sa rezultatom.

Agent uvodi drugačiji model poverenja. Model može da izabere alat tek nakon što protumači zahtev korisnika, preuzme podatke, pročita e-mail, obradi dokument ili analizira rezultat koji je vratio neki drugi alat. Na odluku zato može direktno da utiče spoljni sadržaj.

Korisnik
  │
  ▼
Agent / model
  ▲
  │
Spoljni kontekst
E-mailovi, datoteke, veb stranice,
zapisi, rezultati drugih alata
  │
  ▼
Izbor alata
  │
  ▼
MCP
  │
  ▼
Poslovni sistem

Tako nastaju rizici koji spajaju klasične bezbednosne propuste sa ponašanjem modela koji samostalno bira naredne korake.

Preširoka ovlašćenja

Najjednostavnija greška jeste da agent dobije više mogućnosti nego što mu je zaista potrebno.

Agent korisničke podrške možda treba da pronađe klijenta, pregleda porudžbinu, proveri status isporuke i otvori slučaj. Međutim, servisni nalog koji se nalazi iza integracije možda istovremeno može da menja podatke za naplatu, izvozi evidenciju klijenata, deaktivira naloge ili briše podatke.

Takav nalog je praktičan za razvoj, ali značajno povećava posledice greške modela, zlonamerne instrukcije ili kompromitovanog servera.

Bezbedniji pristup je da se izlože samo poslovne mogućnosti koje su potrebne konkretnom toku rada i da se, gde god je praktično, odvoje operacije čitanja od operacija upisa. Aktuelne OWASP smernice za AI agente i MCP okruženja upravo preporučuju minimalna ovlašćenja na nivou alata i izričitu autorizaciju osetljivih operacija. (OWASP AI Agent Security Cheat Sheet)

Prompt injection može prerasti u zloupotrebu alata

Prompt injection postaje znatno ozbiljniji problem kada model može nešto i da izvrši.

Napadaču nije potreban direktan pristup interfejsu agenta ako zlonamernu instrukciju može da smesti u sadržaj koji će agent kasnije obrađivati. E-mail, dokument, veb stranica, tiket podrške, polje u bazi, datoteka iz repozitorijuma ili odgovor drugog alata mogu postati izvor indirektnog prompt injection napada.

Kod chatbota takav napad može dovesti do pogrešnog odgovora. Kod agenta koji ima pristup poslovnim alatima može da utiče na to koji će podaci biti pročitani, koji će alat biti izabran ili koja će akcija biti pokušana.

OWASP preporučuje da se spoljni podaci, kao što su korisničke poruke, preuzeti dokumenti, API odgovori i e-mailovi, tretiraju kao nepouzdani ulazi. Njihove MCP smernice takođe preporučuju proveru i filtriranje rezultata alata pre nego što se vrate u kontekst modela. Praktična posledica je jasna: zaštita od prompt injection napada ne sme biti jedina bezbednosna granica. Čak i kada model zatraži neprimerenu akciju, nezavisna pravila autorizacije i izvršavanja moraju biti u stanju da je zaustave. (OWASP AI Agent Security Cheat Sheet) (OWASP MCP Security Cheat Sheet)

MCP serveri i opisi alata postaju deo softverskog lanca poverenja

Povezivanje sa MCP serverom znači da kompanija ne veruje samo protokolu. Veruje i kodu servera, njegovim zavisnostima, opisima alata, izdavaču, načinu ažuriranja, okruženju u kome radi i servisima kojima dalje pristupa.

Opisi alata zaslužuju posebnu pažnju zato što ih model vidi i oni mogu da utiču na njegov izbor. Kompromitovan ili zlonameran server zato može istovremeno da utiče i na klasično izvršavanje koda i na kontekst na osnovu kog model donosi odluku.

OWASP MCP smernice izdvajaju rizike kao što su trovanje alata (tool poisoning), prikrivanje ili zasenjivanje alata (tool shadowing), kompromitovani serveri trećih strana i izmene ranije odobrenih alata nakon što su već stekli poverenje. (OWASP MCP Security Cheat Sheet)

Zato produkcioni server mora imati jasno poreklo, vlasnika, kontrolisane verzije, proces provere i način da se značajne promene u njegovom ponašanju otkriju.

Pristupni podaci i problem „confused deputy“

MCP serveru je često potrebno ovlašćenje za pristup sistemu koji se nalazi iza njega. Ako koristi jedan široko privilegovan zajednički nalog, agenti mogu posredno dobiti veća ovlašćenja od korisnika koji je pokrenuo zahtev.

To je varijanta poznatog problema „confused deputy“: servis legitimno ima određena prava, ali ih koristi u ime nekoga ko ta ista prava ne bi smeo da ima.

Na primer, MCP server za bazu podataka može da koristi nalog koji čita sve zapise o klijentima. Ako se autorizacija proverava samo na ulazu u MCP server, prodavac bi preko agenta mogao da dođe do podataka kojima kroz uobičajenu poslovnu aplikaciju nema pristup.

Kod operacija upisa posledice su još ozbiljnije.

Kad god je moguće, identitet korisnika i njegov kontekst autorizacije treba da ostanu relevantni sve do zaštićenog resursa. Zajednički servisni nalozi treba da imaju što uži opseg, a OAuth scope ili ekvivalentne dozvole moraju da odgovaraju tačno onim mogućnostima koje tok rada zahteva. OWASP i preširoke tokene i confused deputy scenarije prepoznaje kao važne MCP rizike. (OWASP MCP Security Cheat Sheet)

Spajanje više sistema može stvoriti mogućnosti koje niko nije izričito odobrio

Neki od najvažnijih rizika ne postoje unutar jednog alata.

Agent može sasvim legitimno imati dozvolu da čita CRM, pretražuje interne dokumente i šalje e-mail. Kada se ta tri ovlašćenja spoje, može nastati put kojim podaci iz zaštićenog sistema odlaze ka spoljnom primaocu, iako nijedan administrator nikada nije odobrio nešto što bi se zvalo „izvezi poverljive informacije“.

Takva mogućnost nastaje tek kombinovanjem više dozvola.

Isti obrazac javlja se u finansijskim tokovima, razvojnim okruženjima i automatizaciji infrastrukture. Pojedinačno razumna ovlašćenja mogu zajedno da formiraju veoma moćan tok rada.

Zrelo bezbednosno rešenje zato ne proverava samo da li je svaki poziv alata pojedinačno dozvoljen, već i šta agent može da postigne kada više alata koristi u kombinaciji.

Autonomne akcije povećavaju razmeru mogućih posledica

Poslednji problem nije konkretna ranjivost već veličina posledica jedne pogrešne odluke.

Agent koji pretražuje internu dokumentaciju ima ograničen operativni rizik. Agent koji može da menja produkcionu infrastrukturu, odobrava povraćaj novca, menja naloge klijenata, šalje poruke van kompanije ili izvršava finansijske transakcije nema.

Zato pitanje nije samo da li je model dovoljno pouzdan da koristi određeni alat. Važno je i šta se dešava kada model pogreši, bude izmanipulisan ili dobije nejasan zahtev.

Kontrole moraju da budu strože što su posledice akcije veće, teže za poništavanje, finansijski značajnije ili vidljivije van same organizacije.

Autentifikacija jeste neophodna, ali politika izvršavanja je nešto drugo

Autentifikacija utvrđuje identitet. Autorizacija određuje čemu taj identitet sme da pristupi.

Kod sistema sa agentima potreban je i treći odgovor:

Da li ovu konkretnu akciju treba izvršiti u ovom konkretnom kontekstu?

Zamislimo zaposlenog koji je uredno prijavljen preko identitetskog sistema kompanije i ima pravo pristupa podacima o klijentima. Agent koji radi u njegovo ime možda je takođe ovlašćen da koristi alat kojim se ti podaci mogu menjati.

Obe provere mogu proći, a da konkretna akcija i dalje nije primerena. Korisnik je možda tražio samo da se problem ispita. Model je sam mogao da zaključi da treba izvršiti izmenu, ili je na njegovu odluku mogao da utiče spoljni sadržaj.

Zato je korisno razdvojiti tri pitanja:

Identitet
Ko pokreće zahtev?

        ↓

Autorizacija
Kojim resursima i alatima sme da pristupi?

        ↓

Politika izvršavanja
Da li ovu konkretnu akciju sada treba dozvoliti?

Politika izvršavanja može uzimati u obzir korisnika koji je pokrenuo proces, samog agenta, alat, osetljivost podataka, vrednost transakcije, mogućnost poništavanja akcije, okruženje, ograničenja učestalosti i potrebu za ljudskim odobrenjem.

Povraćaj novca je dobar primer. Kompanija može dozvoliti agentu da pripremi svaki opravdan zahtev, da samostalno izvrši povraćaj do 100 dolara, da za iznose od 100 do 1.000 dolara traži odobrenje nadređenog, a da iznad toga uopšte nema pravo samostalnog izvršenja.

Alat ostaje isti. Menja se politika pod kojom sme da bude pokrenut.

Specifikacija 2026-07-28 dodatno je ojačala mehanizme autorizacije, dok stabilno proširenje Enterprise-Managed Authorization omogućava organizacijama da pristup MCP serverima centralno dodeljuju preko postojećeg identitetskog sistema. To su važni temelji, ali oni ne zamenjuju poslovna pravila o tome kada konkretna akcija sme da bude izvršena. (MCP specifikacija 2026-07-28) (Enterprise-Managed Authorization)

Kako izgleda bezbedna MCP arhitektura za poslovne sisteme

Produkcioni sistem ne bi trebalo da postavi model neposredno ispred moćnih poslovnih sistema i da se osloni na prompt instrukcije kao glavnu zaštitu. Isto načelo bezbednosti ugrađene u sam dizajn važi i za razvoj prilagođenog softvera i API integracija uopšte.

Odbranjiviji pristup izgleda ovako:

Nije svakoj organizaciji potreban proizvod koji se doslovno zove „MCP gateway“. Ulogu pristupnog sloja mogu imati API gateway, service mesh, namenski MCP sloj ili kombinacija postojećih bezbednosnih komponenti.

Važna je jasna podela odgovornosti.

Identitet mora ostati vezan za čitav tok rada

Sistem treba da zna koji je korisnik ili servis pokrenuo zahtev i, gde je to relevantno, koji agent postupa u njegovo ime. Taj kontekst ne bi smeo da se izgubi u trenutku kada zahtev prođe kroz MCP server.

Ako prodavac traži od agenta podatke o određenom klijentu, zahtev u pozadini ne bi smeo da se pretvori u anonimni poziv nekog globalno privilegovanog AI servisa.

Centralizovan identitet daje pouzdanu osnovu za odluke o pristupu, ali ne znači da svaki autentifikovani agent automatski dobija isto ovlašćenje.

Pravila izvršavanja treba da budu izvan modela

Okruženje agenta može da tumači zahtev, održava kontekst i odluči koja bi mogućnost mogla da pomogne da se zadatak završi. Ne bi, međutim, smelo da ima poslednju reč kada je u pitanju osetljiva akcija.

Ako model predloži update_customer_account, deterministički sloj politike treba da proveri zahtev pre nego što on stigne do poslovnog sistema.

Takva podela olakšava i kontrolu i izmene. Kompanija može da smanji prag za automatski povraćaj sa 100 na 50 dolara kroz pravilo u sistemu, umesto da menja sistemski prompt i zatim se nada da će model novo pravilo primenjivati dosledno.

Izlažite uske poslovne mogućnosti, a ne ceo pozadinski sistem

MCP server treba da izloži najmanji koristan skup operacija, umesto da praktično preslika čitav API sistema iza sebe.

Umesto:

execute_order_operation

server za korisničku podršku može da izloži:

find_order
read_order_status
read_shipping_status
prepare_replacement
request_refund

Tako se smanjuje i mogućnost slučajne zloupotrebe i broj operacija koje bi napadač mogao da pokuša da iskoristi.

Pristupni podaci ne treba da ulaze u kontekst modela

Modelu uglavnom nisu potrebni pristupni podaci kojima se njegove akcije zaista izvršavaju.

API ključevi, lozinke za baze, OAuth refresh tokeni i cloud kredencijali treba da ostanu unutar pouzdane infrastrukture. Model zahteva odobrenu mogućnost, a sistem oko njega obezbeđuje pristupne podatke neophodne da se ona izvrši.

Klasične prakse upravljanja tajnama, kratkotrajni kredencijali gde god su mogući i usko definisani scope-ovi ostaju obavezni.

I mrežni pristup je dozvola

Agent koji može da pročita osetljive podatke i istovremeno ima neograničen izlazni pristup mreži može imati put za iznošenje podataka čak i kada je svaki pojedinačni MCP alat dobro projektovan.

Server kome je potreban samo interni CRM nema nužno razlog da pristupa celom internetu. Lokalni MCP proces takođe ne bi trebalo automatski da nasledi širok pristup datotečnom sistemu, shell-u, mreži i kredencijalima računara na kome radi.

Arhitekturu treba projektovati pod pretpostavkom da će neki sloj zakazati

Filter protiv prompt injection napada može nešto propustiti. Model može pogrešno razumeti zahtev. Server može imati ranjivost. Kredencijal može biti pogrešno podešen.

Odbrana u dubinu znači da loša odluka modela i dalje nailazi na druge granice: pravila izvršavanja, validaciju na strani servera, ograničene kredencijale, obavezna odobrenja, mrežna ograničenja i nadzor.

MCP je interfejs. Arhitektura oko njega određuje koliko ovlašćenja zaista može da prođe kroz taj interfejs.

Načelo minimalne autonomije

Načelo minimalnih privilegija kaže da korisnik, servis ili aplikacija treba da dobije samo ona ovlašćenja koja su mu potrebna da obavi svoj zadatak.

Kod AI agenata potrebno je postaviti još jedno pitanje.

Agent može legitimno da ima pristup nekom alatu, a da i dalje ima previše slobode u tome kada i kako će ga koristiti. Zato je koristan srodan princip: načelo minimalne autonomije (least agency). OWASP-ov Top 10 za Agentic Applications 2026 takođe koristi least agency zajedno sa least privilege kada govori o kontrolama protiv zloupotrebe alata. (OWASP Top 10 for Agentic Applications 2026)

Agent treba da dobije ne samo najmanji neophodan nivo pristupa već i najmanji nivo samostalnosti potreban da bi zadatak imao smisla.

Načelo minimalnih privilegija pita:

Čemu agent sme da pristupi?

Načelo minimalne autonomije pita:

O čemu agent sme sam da odluči i šta sme da izvrši bez dodatnog odobrenja?

Agent korisničke podrške možda mora da pristupi istoriji porudžbina, podacima o isporuci, informacijama o nalogu i alatima za povraćaj novca. Minimalne privilegije ograničavaju ga na te sisteme. Minimalna autonomija određuje da li sme samostalno da izvrši svaki povraćaj koji je tehnički sposoban da zatraži.

Praktično pravilo može izgledati ovako:

Čitanje podataka o klijentu i porudžbini
        → autonomno

Provera uslova za povraćaj
        → autonomno

Priprema povraćaja
        → autonomno

Izvršenje povraćaja do 100 USD
        → autonomno

Izvršenje povraćaja od 100 do 1.000 USD
        → odobrenje nadređenog

Povraćaj iznad 1.000 USD
        → agent nema pravo izvršenja

Takav model omogućava da se autonomija širi postepeno, umesto da kompanija odmah bira između potpunog ručnog nadzora i praktično neograničene automatizacije.

Novi agent može prvo samo da posmatra, preporučuje i priprema akcije. Niskorizične i lako poništive operacije mogu zatim postati automatske. Akcije sa većim posledicama mogu ostati vezane za odobrenje čak i kada ostatak procesa postane veoma autonoman.

Ljudsko odobrenje treba da prati nivo rizika

Ljudska potvrda ima smisla samo tamo gde zaista smanjuje rizik.

Ako čovek mora da odobri svaki poziv alata, gubi se veliki deo vrednosti automatizacije. Ako se ništa ne odobrava, agent može dobiti više samostalnosti nego što posledice eventualne greške opravdavaju.

Jedan jednostavan model može izgledati ovako:

Odobrenje pritom mora biti vezano za tačno definisanu akciju. Dijalog koji samo kaže „Dozvoliti agentu da nastavi?“ pruža vrlo malo zaštite.

Kvalitetan zahtev za odobrenje treba da navede operaciju, cilj, iznos ili druge važne parametre, razlog, agenta koji je pokreće i vreme važenja odobrenja. Ako se važan parametar promeni, mora se tražiti nova potvrda. OWASP preporučuje da se odobrenja za rizične akcije vezuju za konkretnog aktera, alat, ciljni resurs, parametre, vremensku oznaku i rok važenja. (OWASP AI Agent Security Cheat Sheet)

Cilj nije da čovek ostane uključen u svaki korak. Cilj je da ostane uključen baš tamo gde bi greška najviše koštala.

Upravljanje MCP-om i praćenje rada sistema

Kako se MCP širi kroz organizaciju, problem prestaje da bude samo tehnički i postaje i organizacioni.

Mali tim može neformalno da vodi nekoliko eksperimentalnih servera. Takav pristup ne funkcioniše kada više odeljenja počne da povezuje agente sa podacima klijenata, finansijskim sistemima, cloud infrastrukturom, razvojnim alatima i servisima trećih strana.

Svaki produkcioni server mora imati odgovornog vlasnika

Svaki MCP server u produkciji treba da ima jasno određenog vlasnika koji odgovara za njegovu namenu, izložene mogućnosti, model kredencijala, dozvole, izmene, ranjivosti i eventualno gašenje.

Koristan je i interni katalog odobrenih servera koji beleži osnovne informacije: vlasnika, klasifikaciju podataka, dostupne alate, potrebna ovlašćenja, verziju, status bezbednosne provere i okruženja u kojima server sme da radi.

Time se jasno razdvajaju eksperiment i produkcija, a smanjuje se i verovatnoća da različiti timovi prave više nekontrolisanih verzija iste integracije.

Promena alata je i bezbednosno relevantna promena

Server koji je u početku izlagao tri alata samo za čitanje kasnije može da dobije operaciju upisa. Može se promeniti opis alata, proširiti OAuth scope ili pojaviti nova zavisnost ili spoljni servis.

Sve to može promeniti stvarni nivo ovlašćenja koji je dostupan svakom povezanom agentu.

Zato značajne promene u definiciji alata, dozvolama, autentifikaciji, zavisnostima i mrežnom pristupu moraju biti vidljive i podložne novoj proveri. U okruženjima visokog rizika može biti opravdano i zaključavanje na određenu verziju ili drugi ekvivalentni mehanizam koji sprečava da udaljeni server neprimetno promeni ponašanje.

Upravljanje mora da obuhvati i gašenje servera. Organizacija treba da zna koji agenti od njega zavise, da može da opozove kredencijale, ukloni server iz odobrenog kataloga i potvrdi da više nije dostupan.

MCP serveri trećih strana deo su lanca poverenja

Udaljeni server kojim upravlja treća strana treba procenjivati u skladu sa osetljivošću toka rada.

Važna pitanja su: koji podaci se šalju dobavljaču, kako radi autentifikacija, koliko dugo se podaci čuvaju, gde se obrađuju, kako se saopštavaju promene, koje dozvole server traži i da li dalje zavisi od drugih spoljnih servisa.

Konektor ka javno dostupnim informacijama i server koji pristupa poverljivim podacima o klijentima ne mogu prolaziti isti nivo provere.

Praćenje mora da obuhvati čitav put do akcije

Upravljanje definiše šta bi u sistemu trebalo da postoji. Praćenje pokazuje šta se zaista dogodilo.

Klasičan API log može potvrditi da je krajnja tačka vratila 200 OK, ali ne objašnjava zašto ju je agent pozvao, koji korisnik je pokrenuo proces, kakvu je odluku donela politika izvršavanja niti koja akcija je usledila.

Za važne operacije koristan trag treba da poveže:

Zahtev korisnika
      ↓
Agent / sesija
      ↓
Izbor alata
      ↓
Odluka politike
      ↓
MCP poziv
      ↓
Odobrenje, ako je potrebno
      ↓
Akcija u spoljnom sistemu
      ↓
Rezultat

OpenTelemetry-jeve GenAI semantičke konvencije, koje su još u razvoju, nude model za povezivanje poziva agenta, poziva modela i izvršavanja alata unutar istog traga. Relevantne operacije invoke_agent i execute_tool još nose status Development, pa su korisne za projektovanje sistema nadzora, ali ih ne treba predstavljati kao potpuno stabilizovan standard. (OpenTelemetry GenAI semantic conventions) (OpenTelemetry GenAI observability)

Više logova nije automatski i bolje. Promptovi, argumenti alata, rezultati, dokumenti i odgovori modela mogu sadržati podatke o klijentima, izvorni kod, kredencijale ili regulisane informacije. Zato praćenje mora da uskladi mogućnost rekonstrukcije događaja sa minimizacijom podataka, pravilima čuvanja, kontrolom pristupa, redakcijom osetljivih vrednosti i enkripcijom.

Nadzor takođe treba da posmatra više od pojedinačnih poziva. Ponavljani neuspesi autorizacije, neuobičajeni nizovi alata, nagli rast količine preuzetih podataka ili neočekivane izlazne akcije mogu otkriti obrazac koji se ne vidi iz jednog događaja.

Cilj nije beleženje skrivenog procesa rezonovanja modela. Cilj je da odluke i posledice koje sistem spolja može da posmatra budu proverljive i povezane sa odgovornim akterima.

Praktičan primer: korisnička podrška uz MCP

Zamislimo kompaniju koja želi da automatizuje deo procesa korisničke podrške.

Klijent prijavljuje da porudžbina nije stigla. Kompanija želi da AI agent istraži slučaj, utvrdi odgovarajuće rešenje i samostalno završi akcije niskog rizika tamo gde je to opravdano.

Agentu je potreban pristup više sistema:

CRM
Sistem za upravljanje porudžbinama
Logistički sistem
Platforma korisničke podrške
Sistem za povraćaj novca

Arhitektura može izgledati ovako:

Korisnik iz podrške
     │
     ▼
Agent za korisničke operacije
     │
     ▼
Politike / autorizacija
     │
     ▼
MCP pristupni sloj
     │
 ┌───┼──────┬──────────┬─────────┐
 ▼   ▼      ▼          ▼         ▼
CRM Porudžbine Logistika Podrška Povraćaji

Agent najpre poziva alate samo za čitanje, kao što su find_customer, get_order i get_tracking_status. Sloj politike proverava da li zaposleni sme da pristupi nalogu tog klijenta i da li opseg agenta obuhvata odgovarajuće zapise.

Logistički sistem pokazuje da je pošiljka izgubljena. Agent proverava politiku povraćaja, potvrđuje da povraćaj ili zamena nisu već izvršeni i predlaže:

Akcija: Povraćaj novca
Porudžbina: ORD-91832
Iznos: 72 USD
Razlog: Gubitak pošiljke potvrđen od strane prevoznika

Zaključak modela sam po sebi nije autorizacija.

Sloj politike nezavisno proverava iznos, uslove, ciljnu porudžbinu, prethodne transakcije i ostala deterministička pravila. Pošto je iznos ispod praga za autonomno izvršenje, sistem dozvoljava poziv issue_refund.

MCP server ne izlaže kompletno upravljanje platnim sistemom. Alat za povraćaj proverava porudžbinu i dozvoljeni iznos pre nego što pozove sistem za plaćanja. Model nikada ne vidi platne kredencijale i ne može da izabere proizvoljan račun na koji će novac biti poslat.

Nakon uspešnog izvršenja, agent može da doda internu belešku i pripremi odgovor klijentu.

Sada promenimo samo jednu činjenicu: iznos povraćaja je 840 dolara.

Istraga ostaje ista. Sloj politike, međutim, prosleđuje predlog nadređenom na odobrenje. Odobrenje sadrži tačnu porudžbinu, iznos, razlog i cilj transakcije. Ako nadređeni potvrdi akciju, ta dozvola važi samo za tu konkretnu transakciju, a ne kao opšte ovlašćenje agenta.

To je minimalna autonomija u praksi. AI obavlja gotovo ceo tok rada, dok se čovek uključuje tek na mestu na kome finansijska posledica opravdava dodatnu kontrolu.

Ista arhitektura ograničava i posledice prompt injection napada. Ako e-mail klijenta sadrži instrukciju da se izvezu nepovezani podaci o drugim klijentima, model i dalje može biti pod uticajem tog sadržaja, ali agent nema alat za masovni izvoz, pristup podacima je ograničen, izlazne akcije su kontrolisane, a izvršavanje između različitih sistema prolazi kroz sloj politike.

Bezbednost zato ne zavisi od toga da li ćemo savršeno prepoznati svaku zlonamernu instrukciju. Zavisi od toga da i loša odluka modela i dalje nailazi na stvarne granice.

Iste MCP integracije pritom mogu ponovo da se koriste. Prodajni agent može koristiti CRM server bez pristupa povraćajima. Operativni agent može koristiti logističke podatke bez pristupa komunikaciji sa klijentima. Finansijski agent može koristiti platne alate pod potpuno drugačijim pravilima.

Veza sa sistemima može biti ponovo upotrebljiva.

Ovlašćenje ne mora da bude.

Najčešće greške pri uvođenju MCP-a

Problemi u produkciji često ne nastaju zbog egzotičnih propusta samog protokola, već zbog prečica koje su u demonstracionoj fazi delovale bezazleno, a ostale su u sistemu i nakon što je agent dobio pristup važnim poslovnim sistemima.

Izlaganje celog pozadinskog sistema

Najlakše je obmotati veliki administrativni API tankim MCP slojem i izložiti gotovo sve što sistem već ume da radi. Time se, međutim, puna moć pozadinskog sistema prenosi pravo u okruženje agenta.

Počnite od poslovnog procesa i izložite samo mogućnosti koje su agentu potrebne.

Korišćenje široko privilegovanih zajedničkih naloga

Jedan moćan servisni nalog za sve korisnike i agente slabi autorizaciju u pozadini i povećava posledice eventualnog kompromitovanja.

Kada je praktično, zadržite kontekst korisnika i suzite ovlašćenja servisnih kredencijala.

Posmatranje OAuth-a kao čitave bezbednosne arhitekture

Važeći identitet i token potvrđuju pristup. Ne potvrđuju da je svaki naredni poziv alata primeren konkretnom kontekstu.

Osetljive akcije i dalje zahtevaju zasebna pravila izvršavanja.

Povezivanje svega sa jednim opštim agentom

Agent koji istovremeno ima pristup CRM-u, e-mailu, shell-u, cloud infrastrukturi, bazama podataka, finansijskim alatima i repozitorijumima ima ogroman skup mogućnosti čak i kada je svaka pojedinačna integracija legitimna.

Uži agenti ili jasno odvojeni profili mogućnosti često su lakši za razumevanje, testiranje i zaštitu.

Isto tretiranje čitanja i upisa

Pretraga i brisanje nisu isto. Priprema poruke i njeno slanje nisu isto. Upit nad bazom i izmena podataka nisu isto.

Odvojite operacije čitanja i upisa i primenite različite kontrole.

Pretpostavka da je jednom odobren server zauvek bezbedan

Zavisnosti, opisi alata, dozvole i udaljene implementacije menjaju se tokom vremena. Odobravanje servera zato mora biti proces kroz čitav njegov životni ciklus.

Prelazak iz uspešne demonstracije pravo u autonomnu produkciju

Uspešan demo dokazuje da agent može da obavi tok rada u povoljnim uslovima. Ne dokazuje da je isti proces spreman za rad bez nadzora u produkciji.

Produkcija donosi nejasne zahteve, zastarele podatke, ponovljene pokušaje, delimične kvarove, zlonamerni sadržaj, različita ovlašćenja korisnika, promene modela i međuzavisnosti između sistema.

Autonomiju širite postepeno i odvojeno od samog povezivanja.

MCP, API i pozivanje funkcija: Da li vam je MCP uopšte potreban?

MCP ne bi trebalo da postane podrazumevani odgovor na svaki problem integracije veštačke inteligencije.

Direktni API-ji, pozivanje alata ili funkcija i MCP rešavaju srodne, ali različite probleme. U mnogim produkcionim sistemima koristiće se zajedno.

Direktan API je ponekad jednostavnije rešenje

Ako jedna AI aplikacija izvršava uzak i stabilan proces nad dva interna servisa, MCP možda neće doneti dovoljno koristi da opravda dodatni sloj.

AI aplikacija
      │
      ├── Interni API dobavljača
      └── Računovodstveni API

Programeri već znaju sa kojim sistemima rade, koje su operacije dostupne i kako autentifikacija funkcioniše. Možda uopšte ne postoji ozbiljan problem ponovne upotrebe ili interoperabilnosti koji treba rešavati.

Svaka apstrakcija nosi operativni trošak. MCP uvodi upravljanje serverima, autorizaciju, otkrivanje mogućnosti, praćenje i dodatna pravila upravljanja. Ako je okruženje jednostavno, novi sloj može biti suvišan.

Pozivanje funkcija rešava drugi nivo problema

Function calling ili tool calling omogućava modelu da od aplikacije zatraži strukturisanu akciju, na primer lookup_customer ili create_ticket.

To odgovara na pitanje na nivou modela i izvršnog okruženja:

Kako model može da zatraži da moja aplikacija upotrebi određeni alat?

MCP rešava šire integraciono pitanje:

Kako AI aplikacije mogu da koriste spolja dostupne alate i resurse kroz zajednički protokol?

Ta dva pristupa zato nisu konkurenti već se dopunjuju.

Model može izabrati alat kroz svoj mehanizam tool calling-a. Aplikacija je taj alat možda dobila od MCP servera. MCP server zatim može pozvati sasvim običan REST, GraphQL ili gRPC API, bazu podataka ili vlasnički interfejs.

Model
   │  izbor alata
   ▼
AI aplikacija
   │  MCP
   ▼
MCP server
   │  postojeći API
   ▼
Poslovni sistem

MCP postaje vredniji kako mreža integracija raste

Argument u korist MCP-a postaje jači kada više aplikacija treba da pristupa istim sistemima.

Ako kompanija ima agente za podršku, prodaju, finansije, razvoj i internu bazu znanja, različiti timovi bi bez zajedničkog sloja mogli iznova da prave iste CRM, database, dokumentacione, Jira, GitHub ili reporting integracije.

Ponovo upotrebljiv MCP sloj može da smanji to dupliranje i da stvori zajedničku granicu na kojoj se primenjuju pravila upravljanja.

Direktna integracija je i dalje često bolji izbor kada:

• postoji samo jedna AI aplikacija;
• uključeno je malo spoljnih sistema;
• tok rada je fiksan;
• integracija je veoma specifična za jednu aplikaciju;
• brzina i operativna jednostavnost važnije su od interoperabilnosti;
• nema realne potrebe da se integracija ponovo koristi.

MCP postaje znatno privlačniji kada:

• više AI aplikacija pristupa istim sistemima;
• iste mogućnosti treba deliti između više modela ili agent platformi;
• broj dostupnih alata raste;
• kompanija želi kontrolisan zajednički sloj za AI integracije;
• interne mogućnosti treba održavati kao platformsku infrastrukturu koju više timova koristi;
• očekuje se da će se AI aplikacioni sloj vremenom menjati.

Poređenje može izgledati ovako:

Najjači razlog za uvođenje MCP-a nije to što je nov ili popularan. Razlog postoji kada je integraciono okruženje postalo dovoljno složeno da standardizacija rešava stvaran problem.

Ako te složenosti nema, jednostavnija arhitektura i dalje može biti bolji izbor.

Da li kompanije treba da uvedu MCP u 2026?

Do septembra 2026. MCP je odavno prerastao ideju desktop asistenta koji se povezuje sa nekoliko lokalnih alata. Na dan 25. septembra 2026, 2026-07-28 i dalje je najnovija završena revizija MCP specifikacije, dok je sledeća planirana verzija 2026-12-15 u javnoj matrici projekta još označena kao nespremna. (MCP matrica planiranih specifikacija)

Specifikacija 2026-07-28 približila je MCP klasičnoj produkcionoj infrastrukturi kroz jezgro bez stanja sesije, ojačanu autorizaciju, formalni sistem proširenja, usmeravanje preko zaglavlja pogodno za gateway-e i politiku zastarevanja. Enterprise-Managed Authorization omogućava i povezivanje MCP pristupa sa postojećom identitetskom infrastrukturom kompanije. (MCP specifikacija 2026-07-28) (Enterprise-Managed Authorization)

To MCP čini ozbiljnom opcijom za produkciju.

Ali ne čini svaku MCP implementaciju automatski spremnom za produkciju.

Praktična odluka nije da li kompanija „veruje MCP-u“ kao protokolu. Pitanje je da li se konkretna kombinacija agenata, servera, dozvola, podataka i poslovnih akcija može bezbedno koristiti u realnom okruženju.

MCP je posebno privlačan tamo gde ponovna upotreba integracija donosi jasnu korist, a ovlašćenja mogu dobro da se ograniče: interni sistemi znanja, analitika, procesi koji pretežno čitaju podatke, razvojni alati u odgovarajuće izolovanom okruženju i zajedničke poslovne mogućnosti koje koristi više AI aplikacija.

Tokovi većeg rizika, poput finansijskih operacija, izmena naloga klijenata, produkcione infrastrukture, upravljanja identitetima ili regulisanih podataka, takođe mogu koristiti MCP, ali zahtevaju proporcionalno strože kontrole identiteta, politike izvršavanja, kredencijala, mrežnog pristupa, odobravanja, porekla servera i praćenja.

Razuman proces uvođenja počinje od poslovnog toka, a ne od protokola.

Prvo definišite šta agent zaista treba da radi. Izložite samo te mogućnosti. Povežite ih preko MCP-a tamo gde standardizacija donosi stvarnu vrednost. Autonomiju zatim širite odvojeno od same povezanosti.

Kompanija može da standardizuje pristup poslovnim sistemima, a da u početku većinu akcija zadrži u režimu preporuke ili pripreme. Operacije niskog rizika mogu postepeno postati automatske. Akcije sa velikim posledicama mogu trajno ostati vezane za ljudsko odobrenje.

Kontrolna lista za MCP u produkciji

Pre nego što agent zasnovan na MCP-u dobije pristup produkcionim sistemima, organizacija treba da može jasno da odgovori na sledeća pitanja.

Arhitektura i obim

• Postoji li jasan razlog da se koristi MCP umesto jednostavnije direktne integracije?
• Da li su mogućnosti definisane prema poslovnom toku, umesto prema punom skupu funkcija pozadinskog API-ja?
• Da li su operacije čitanja i upisa razdvojene tamo gde to ima smisla?
• Da li agent ima samo alate koji su mu potrebni za njegovu ulogu?
• Da li su proverene kombinacije mogućnosti između više sistema?

Identitet i autorizacija

• Da li se važne akcije mogu povezati sa konkretnim korisnikom, servisom i agentom?
• Da li su kredencijali uskog opsega i izdvojeni iz konteksta modela?
• Da li se autorizacija proverava pri relevantnim zahtevima, a ne samo prilikom prijave?
• Da li pristup u pozadini i dalje poštuje ovlašćenja korisnika tamo gde je to potrebno?
• Da li su osetljive akcije pod dodatnim pravilima izvršavanja, a ne samo pod kontrolom pristupa alatu?

Bezbednost servera i softverskog lanca

• Da li svaki produkcioni MCP server ima odgovornog vlasnika?
• Da li se serveri trećih strana proveravaju kao deo softverskog lanca poverenja?
• Da li se važne promene alata, dozvola, opisa i zavisnosti mogu otkriti?
• Da li se zastareo ili kompromitovan server može brzo opozvati?

Autonomija

• Da li svaki alat sa ozbiljnim posledicama ima definisan nivo rizika?
• Da li se poništive i nepovratne akcije tretiraju različito?
• Da li su autonomne akcije ograničene determinističkim pravilima?
• Da li visokorizične akcije zahtevaju nezavisno odobrenje?
• Da li je ljudska potvrda vezana za tačnu akciju i njene parametre?

Podaci, mreža i operacije

• Da li se osetljivi podaci izlažu samo kada su zaista potrebni?
• Da li se proveravaju ulazni i izlazni podaci alata?
• Da li je izlazni mrežni pristup ograničen tamo gde je potrebno?
• Da li su poznati realni putevi kojima bi podaci mogli biti izneti iz sistema?
• Da li organizacija može da isprati korisnički zahtev kroz politiku, MCP i konačnu akciju u spoljnom sistemu?
• Da li su osetljivi promptovi i rezultati alata zaštićeni od prekomernog logovanja?
• Da li se agenti, alati, kredencijali i serveri mogu brzo isključiti tokom incidenta?

Testiranje

• Da li je sistem testiran na direktan i indirektan prompt injection?
• Da li su razmotreni zlonamerni dokumenti, e-mailovi, veb stranice i odgovori drugih alata?
• Da li su testirani ponovljeni pokušaji, duplirane akcije, delimični kvarovi i nedostupni servisi?
• Da li su granice autorizacije testirane sa korisnicima različitih uloga?
• Da li je provereno šta se dešava kada model donese uverljivu, ali pogrešnu odluku?

Agent koji samo čita interne informacije i agent koji može da prebaci novac ne zahtevaju iste kontrole. Važno je da arhitektura odgovara posledicama potencijalne greške.

Za organizacije koje imaju jedan uzak tok rada, MCP možda i dalje nije potreban. Za one koje razvijaju više agenata, dele iste mogućnosti između više aplikacija ili grade kontrolisanu internu AI platformu, argument u njegovu korist je mnogo snažniji.

MCP može da standardizuje povezivanje. Spremnost za produkciju zavisi od toga šta ćete povezati, koliko ovlašćenja ćete propustiti kroz te veze i gde ćete postaviti granicu.

Povezani tekstovi Orcas Group-a

• Razlika između AI demonstracije i sistema spremnog za produkciju
• Cena razvoja AI agenta u 2026: Kompletan vodič
• Vibe Coding za startape u 2026: Možete li uz AI napraviti MVP spreman za produkciju?

Zaključak: MCP je infrastruktura, a ne bezbednosna granica

MCP rešava stvaran problem poslovnih AI sistema.

Kako agentima postaju potrebni pristup bazama podataka, SaaS platformama, internim API-jima, dokumentima, razvojnim sistemima i operativnim procesima, postaje sve teže održavati svaku vezu kao zasebnu integraciju. Zajednički protokol može da omogući ponovnu upotrebu tih mogućnosti i smanji vezanost AI aplikacije za sisteme na koje se oslanja.

Greška bi bila poistovetiti lakše povezivanje sa bezbednijim povezivanjem.

MCP server može da izloži alat ili resurs kroz standardizovan interfejs. Ne odlučuje da li određeni agent treba da ima tu mogućnost, da li korisnik iza zahteva ima pravo da je koristi, da li je konkretna akcija primerena datom kontekstu niti da li njene posledice opravdavaju autonomno izvršenje.

Te odluke ostaju deo arhitekture koja okružuje MCP.

Zato za kompanije ključno pitanje nije koliko sistema agent može da dosegne. Važnije je koliko precizno organizacija može da kontroliše šta agent sme da uradi kada su te veze jednom uspostavljene.

Za to su i dalje potrebne dobro poznate discipline: upravljanje identitetima, minimalne privilegije, izdvajanje kredencijala, mrežne kontrole, logovanje i provera softverskog lanca. Sistemi sa agentima dodaju još jednu dimenziju: količinu samostalnog ovlašćenja koje prepuštamo modelu.

Načelo minimalne autonomije dobro opisuje tu razliku. Agentu treba dati dovoljno samostalnosti da tok rada zaista postane efikasniji, ali ne više nego što konkretan zadatak i njegove moguće posledice opravdavaju.

MCP olakšava povezivanje veštačke inteligencije sa stvarnim poslovnim mogućnostima. Kvalitet implementacije zavisiće od toga koliko pažljivo oblikujete i ograničite taj pristup.

Gradite AI agente kojima je potreban pristup stvarnim poslovnim sistemima?

U Orcas Group-u projektujemo i razvijamo AI sisteme spremne za produkciju koji se povezuju sa postojećom poslovnom infrastrukturom, uključujući interne API-je, baze podataka, SaaS platforme i operativne tokove rada.

Takav posao ne svodi se na povezivanje modela sa alatom. Produkcioni sistemi zahtevaju i odgovarajuću arhitekturu identiteta, dozvola, pravila izvršavanja, praćenja i bezbednosti. Naš rad na AI sistemima oslanja se i na specijalizovane usluge sajber-bezbednosti i IT infrastrukture, što postaje posebno važno kada agenti pređu sa pronalaženja informacija na izvršavanje akcija unutar poslovnih sistema.

Ako vaš AI projekat prelazi iz eksperimentalne faze u produkciju, Orcas Group može da pomogne u projektovanju integracione i bezbednosne arhitekture potrebne za taj prelazak.

Razgovarajte sa nama o AI arhitekturi →

O autoru

Ivan Janković je osnivač i CEO kompanije Orcas Group. Njegova profesionalna i akademska pozadina povezuje međunarodni menadžment, pravo i informacione tehnologije, uz više od decenije iskustva na preseku regulisanih industrija i savremenog softvera. Studirao je u Ženevi, diplomirao menadžment na Univerzitetu Webster u Beču, a potom završio master studije prava i informacionih tehnologija na Pravnom fakultetu Univerziteta u Nišu.

Pre osnivanja Orcas Group-a, Ivan je radio kao konsultant za privatnu banku sa sedištem u Švajcarskoj na inicijativama vezanim za blokčejn tehnologiju, uključujući arhitekturu, usklađenost i strategiju proizvoda. Pod njegovim vođstvom, Orcas Group je izrastao u tim od više od 20 stručnjaka i realizovao više od 100 projekata u oblastima kao što su fintech, SaaS, zdravstvene tehnologije, LegalTech, e-trgovina, proizvodnja i javni sektor.

Njegov današnji rad nalazi se na preseku AI strategije, poslovnog softvera, sajber-bezbednosti, usklađenosti i tehnološke realizacije. Ta kombinacija je naročito važna kod AI sistema u produkciji, gde mogućnosti modela, softverska arhitektura, bezbednost i upravljanje sve češće moraju da se projektuju zajedno.

Više o Ivanu Jankoviću i Orcas Group-u →