MCP priključak treba tretirati kao poslovnu granicu: organizacija mora unaprijed odrediti koje AI radnje smiju dosegnuti poslovne sustave, tko im dodjeljuje ovlast, kada je potrebna potvrda čovjeka i kako pregledati posljedicu svake radnje. Tehničko povezivanje bez tih odluka širi pristup bez jasnog vlasnika. Poslovne ovlasti MCP priključka zato počinju katalogom, a ne samim spajanjem.
MCP priključak može povezati AI aplikaciju s alatima, podacima ili procesima. U poslovnom okruženju ta mogućnost odmah otvara operativna pitanja: može li radnja samo pronaći podatak, smije li pripremiti prijedlog, može li poslati dokument ili promijeniti službeni zapis u ERP-u?
Razlika nije semantička. Čitanje raspoloživosti materijala, izrada nacrta narudžbenice i knjiženje dokumenta imaju različit učinak, vlasnika odluke i potrebu za kontrolom. ERP službene transakcije pripadaju poslovnom procesu, ne samo integracijskom sloju.
Izvorna bilješka o MCP-u opisuje promjenu protokola i migraciju. Takva promjena jest povod za provjeru ugovora, tehničkog opsega, odgovornosti i načina upravljanja pristupom. Ne govori sama po sebi ništa o podršci, kompatibilnosti ili raspoloživosti postojećeg priključka kod pojedinog klijenta. Prije nastavka potrebno je provjeriti konkretan ugovor, dokumentaciju i okruženje. MCP specification notes, July 28 2026 služe kao polazište za tu provjeru.
Katalog dopuštenih AI radnji je poslovni popis onoga što priključak smije učiniti. Ne bi smio biti samo popis tehničkih funkcija poput search ili update . Svaka stavka mora opisati poslovnu namjenu, granice i odgovornost.
Za svaku radnju evidentirati:
Takav katalog odvaja pitanje "može li alat" od pitanja "smije li proces". Tehnički moguća radnja bez poslovne ovlasti ne pripada produkcijskom opsegu.
Korisno je radnje svrstati prema učinku. Radnje samo za čitanje mogu imati uži rizik, ali i dalje trebaju pravilo o opsegu podataka. Radnje koje stvaraju prijedlog trebaju jasno označiti nacrt i osobu koja odlučuje. Radnje koje mijenjaju službeni zapis ili šalju obvezujuću komunikaciju traže izričitu ovlast, potvrdu i pregledan trag posljedice.
Prijavljeni korisnik ne daje automatski priključku pravo na svaku radnju. Poslovna ovlast treba povezati tri razine: identitet korisnika ili sustava, poslovnu ulogu i konkretnu radnju iz kataloga.
Kod promjene službenog zapisa potvrda treba prikazati barem:
Potvrda ima smisla samo ako osoba može razumjeti posljedicu i odbiti radnju. Klik bez jasnog sažetka pretvara kontrolu u formalnost. S druge strane, potvrda za svaku bezopasnu radnju može usporiti rad bez stvarne koristi. Granicu odrediti prema učinku, osjetljivosti podatka, mogućnosti povrata i poslovnoj odgovornosti.
Odgovorna ovlast ne završava potvrdom. Proces mora ostaviti mogućnost odgovora na jednostavna pitanja: što je AI zatražio, koje je ulaze koristio, koja je ovlast provjerena, što je sustav izvršio i kakvo je stanje ostalo nakon izvršenja.
Ovaj pregled nije nužno potpuna rekonstrukcija svakog internog koraka modela. Za poslovni proces važniji je provjerljiv operativni trag. On može uključiti identifikator zahtjeva, korištenu radnju, opseg zahvaćenih zapisa, rezultat, status izvršenja, odbijenu iznimku i poveznicu na službenu transakciju kada ona postoji.
Vlasnik procesa treba odrediti tko pregledava neuspjele radnje, djelomične izvršene promjene i odstupanja između prijedloga i stvarnog rezultata. Bez tog vlasnika iznimka ostaje tehnički događaj umjesto poslovnog zadatka.
Hipotetski scenarij: nabava želi AI pomoćnika koji pronalazi otvorene potrebe materijala i priprema nacrt zahtjeva za nabavu. Prvo pitanje nije može li pomoćnik dohvatiti podatke iz ERP-a. Prvo pitanje glasi tko posjeduje podatke o potrebama, tko odlučuje o nastanku zahtjeva i smije li pomoćnik ikada poslati zahtjev bez potvrde.
Razuman početni opseg mogao bi ograničiti priključak na čitanje relevantnih potreba i pripremu nacrta. Katalog bi zabranio promjenu količine, dobavljača, cijene i statusa bez ovlaštene potvrde. Vlasnik nabavnog procesa odobrava pravila rada. Vlasnik podatka potvrđuje dopušteni opseg zapisa. Odgovorna osoba za iznimke prima slučajeve s nepotpunim ili proturječnim ulazima.
Kriterij prihvata ne mora sadržavati izmišljenu ciljnu metriku. Može biti provjerljiv: testni scenariji moraju pokazati da priključak odbija radnju izvan kataloga, traži potvrdu za svaku označenu promjenu, bilježi vlasnika odluke i vraća iznimku u dogovoreni radni red. Takav kriterij provjerava ponašanje procesa, ne obećava poslovni ishod.
Migracija protokola može promijeniti način povezivanja, identitet, dozvole, format razmjene ili nadzor. Opseg promjene utvrditi iz aktualne tehničke dokumentacije i ugovornih obveza relevantnih strana. Nije opravdano pretpostaviti kompatibilnost postojećeg priključka samo na temelju naziva protokola ili prethodne implementacije.
Prije migracije provjeriti:
Ova provjera nije samo zaštita od tehničke greške. Ona vraća vlasništvo nad priključkom poslovnom procesu.
Prije odobrenja MCP priključka okupiti vlasnika procesa, vlasnika ulaznih podataka, osobu ovlaštenu za odluke, tehničkog vlasnika priključka i odgovornu osobu za iznimke. Zatim dovršiti sljedeći popis:
Za organizacije koje tek oblikuju te uloge, Screening poslovnog procesa može poslužiti za mapiranje odluka, ulaza i iznimaka prije tehničkog opsega. Sljedeći praktični korak je pregledati postojeći katalog radnji i ugovorni opseg priključka prije bilo kakve migracije ili proširenja ovlasti.