Arhitektura suverenog AI-ja: kako izgraditi sustav koji tvrtka doista kontrolira

Microsoft i Mistral objavili su 21. srpnja 2026. višemilijardsko proširenje svojeg partnerstva. Sporazum uključuje dodatne GPU kapacitete u Europi, integraciju većeg broja Mistralovih modela u Microsoft Foundry i Copilot Studio te podršku za različite načine implementacije, od javnog oblaka do potpuno izoliranih okruženja.

Za europske tvrtke, osobito one koje posluju u zdravstvu, proizvodnji, financijama i kritičnoj infrastrukturi, ovo je odgovor na vrlo praktično pitanje: kako koristiti napredne AI modele, a pritom zadržati kontrolu nad osjetljivim podacima i ključnim poslovnim operacijama.

Objava Microsofta i Mistrala dolazi u trenutku kada Europska unija nastavlja ulagati u AI Factories i AI Gigafactories. Europa želi povećati vlastite računalne kapacitete, potaknuti razvoj regionalnih modela i smanjiti ovisnost o infrastrukturi koja se kontrolira izvan Europske unije.

To je važno.

No u toj se raspravi često izgubi jedna neugodna činjenica: model koji radi u Europi ne znači automatski da tvrtka kontrolira proizvod izgrađen oko njega.

Lokacija poslužitelja odgovara samo na jedno pitanje. Na sva ostala odgovara softverska arhitektura.

Može li tvrtka zamijeniti model bez ponovne izgradnje aplikacije? Može li premještati radna opterećenja između oblaka, privatnog okruženja i lokalne infrastrukture? Kontrolira li upute modelu, poslovna pravila, logiku dohvaćanja podataka i podatke za evaluaciju? Što se događa ako vanjski API promijeni cijene, ograničenja ili uvjete korištenja?

Sve se te odluke donose unutar kodne baze.

Arhitektura suverenog AI-ja nadilazi lokaciju podataka

Mjesto pohrane i obrade podataka obično je prvo pitanje u projektima suverenog AI-ja. Ono određuje gdje se informacije čuvaju i obrađuju, koji se pravni okviri mogu primjenjivati te smiju li radna opterećenja napustiti određenu jurisdikciju.

Za neke je sustave to dovoljno. Interni pomoćnik za pisanje s niskom razinom rizika može sasvim dobro raditi putem upravljanog API-ja smještenog u prethodno odobrenoj regiji.

Situacija se mijenja kada AI obrađuje medicinsku dokumentaciju, operativnu infrastrukturu, zaštićene proizvodne podatke, financijske odluke ili procese usmjerene prema korisnicima.

U takvim slučajevima kontrola ima nekoliko razina:

• Kontrola nad podacima: gdje se pohranjuju izvorni podaci, upute modelu, zapisnici i vektorski prikazi.
• Kontrola nad modelima: koji se modeli mogu koristiti, prilagođavati, zamjenjivati ili implementirati u privatnom okruženju.
• Kontrola nad aplikacijom: tko posjeduje radne tijekove, pristupna prava, sučelja i poslovnu logiku.
• Operativna kontrola: može li sustav nastaviti raditi tijekom problema s mrežom, prekida rada pružatelja usluge ili ograničenja servisa.
• Komercijalna kontrola: ostaje li ekonomika proizvoda održiva kada se promijene opseg korištenja, cijene tokena ili licencni uvjeti.

Tvrtka može u potpunosti riješiti prvi sloj i istodobno ostati izložena rizicima na preostala četiri.

Primjerice, AI aplikacija može raditi u europskoj cloud regiji, ali i dalje ovisiti o agentnom okviru određenog pružatelja, zatvorenoj vektorskoj pohrani, vlasničkim alatima za evaluaciju i uputama modelu raspoređenima po cijeloj aplikaciji. Kasnija migracija tada zahtijeva ozbiljno prepisivanje sustava.

Infrastruktura je regionalna. Ovisnost je i dalje duboka.

Gdje se zapravo skriva ovisnost o AI pružatelju

Većina timova ne stvara ovisnost o jednom pružatelju namjerno. Ona nastaje postupno.

Dokaz koncepta počinje jednim API pozivom. Test uspije. Tim zatim dodaje dohvaćanje podataka, obradu dokumenata, alate, memoriju, korisničke ovlasti i administrativno sučelje. Šest mjeseci poslije AI pružatelj već je ugrađen u gotovo svaki sloj proizvoda.

Ovisnost se najčešće pojavljuje na četiri mjesta.

1. Aplikacijska logika vezana uz određeni model

Različiti modeli različito rade s uputama, pozivima alata, strukturiranim izlazima, multimodalnim ulazima i kontekstnim prozorima.

Kada se upute specifične za pojedini model izravno ugrađuju u pozadinske servise, promjena pružatelja postaje softverska migracija, a ne promjena konfiguracije.

Čak i mala razlika u strukturi odgovora može narušiti naknadnu validaciju, izvještavanje ili rad korisničkog sučelja.

2. Vlasnička infrastruktura za dohvaćanje podataka

Generiranje prošireno dohvaćanjem podataka, poznato kao retrieval-augmented generation, obično uključuje unos dokumenata, njihovo dijeljenje na segmente, izradu vektorskih prikaza, vektorsku pohranu, filtre metapodataka i rangiranje rezultata.

Ako je svaka komponenta vezana uz formate i API-je jednog pružatelja, tvrtka može formalno posjedovati svoje dokumente, ali u praksi ne kontrolirati sustav koji ih čini upotrebljivima.

Problem postaje osobito ozbiljan nakon obrade milijuna zapisa.

3. Radni tijekovi unutar vanjskih platformi

Low-code platforme za AI agente korisne su za testiranje ideja. Poteškoće počinju kada pravila odobravanja, obrada iznimki, integracije i operativno znanje ostanu unutar platforme koju nije moguće reproducirati u drugom okruženju.

Model se može zamijeniti. Radni tijek više ne može.

4. Zapisnici i podaci za evaluaciju

AI u produkciji zahtijeva više od uobičajenih aplikacijskih zapisnika.

Tim mora znati koja je uputa korištena, koji je kontekst dohvaćen, koji je model odgovorio, koji su alati pozvani, koliko je zahtjev koštao i je li čovjek naknadno ispravio rezultat.

S vremenom ta povijest postaje jedan od najvrjednijih resursa sustava. Pomaže poboljšati upute, uspoređivati modele, istraživati pogreške i dokazati kako je određena odluka nastala.

Ako se svi ti podaci nalaze samo na nadzornoj ploči vanjskog pružatelja, tvrtka gubi dio vlastitog operativnog znanja.

Softverski sloj dio je sustava koji tvrtka može stvarno posjedovati

Modeli će se mijenjati. Cijene će se pomicati. Pojavljivat će se novi i snažniji pružatelji.

Trajnu vrijednost ima softverski sloj oko modela.

On uključuje podatkovne strukture tvrtke, integracije, pravila pristupa, radne tijekove, sučelja, postupke provjere i operativnu povijest. Upravo se u tom sloju nalazi znanje o tome kako poslovanje doista funkcionira.

Takav je pristup oblikovao arhitekturu nekoliko Allmaticsovih projekata.

U jednom projektu obrade sadržaja klijent je želio uvesti AI u postojeću platformu bez ponovne izgradnje glavnog proizvoda. Allmaticsov tim razvio je zaseban AI mikroservis, smjestio ga u cloud okruženje i povezao s klijentovim sustavom putem API-ja.

Prema studiji slučaja o optimizaciji sadržaja uz pomoć AI-ja, novi je radni tijek smanjio operativne troškove više od tri puta i ubrzao proizvodnju sadržaja.

Ključna arhitekturna odluka bila je razdvajanje komponenti.

Glavna platforma ostala je odgovorna za poslovni proces. AI funkcionalnost radila je kroz jasno definiran servisni sloj. Upute, logika obrade i buduće promjene modela mogli su se kontrolirano mijenjati unutar tog servisa bez ponovne izgradnje glavne aplikacije.

Takav obrazac nije koristan samo za generiranje sadržaja.

Zaseban AI sloj može podržavati:

• više pružatelja modela;
• privatne modele i modele u oblaku;
• odabir modela prema vrsti zadatka ili osjetljivosti podataka;
• centralizirana pravila pristupa;
• upravljanje verzijama uputa;
• predmemoriranje i ograničavanje troškova;
• rezervne scenarije;
• objedinjeni nadzor.

Pružatelj se može promijeniti, dok poslovni proces ostaje stabilan.

Model je samo jedna komponenta AI proizvoda

Obrada dokumenata dobro pokazuje tu razliku.

Organizacija može svoju potrebu opisati kao „korištenje AI-ja za obradu dokumenata”. U stvarnosti model obavlja samo dio posla.

Cjelovit sustav mora primiti datoteku, odrediti njezinu vrstu, izdvojiti tekst, prepoznati tablice, provjeriti obvezna polja, strukturirati podatke, označiti nepouzdane rezultate, proslijediti iznimke čovjeku i izvesti završni rezultat u drugi sustav.

Allmatics je upravo takav produktni pristup primijenio pri razvoju DocStreamsa, AI platforme za obradu životopisa.

Platforma pretvara nestrukturirane životopise u PDF formatu u standardizirane i strukturirane dokumente. Njezina vrijednost proizlazi iz cijelog radnog tijeka: obrade datoteka, izdvajanja podataka, pravila oblikovanja, validacije i izvoza.

Noviji OCR model može poboljšati kvalitetu prepoznavanja. Ne može zamijeniti cijeli proizvod.

Zato je vlasništvo nad radnim tijekom ključno. Kada poslovna organizacija posjeduje aplikacijsku logiku, pojedine se AI komponente mogu testirati i mijenjati kako se tržište razvija.

Kada radni tijek pripada vanjskom pružatelju, svaka odluka o modelu istodobno postaje odluka o platformi.

Regulirane industrije trebaju kontrolu na razini radnog tijeka

Zdravstvo tu razliku pokazuje posebno jasno.

Klinički AI asistent može koristiti snažan medicinski model, ali model sam ne upravlja pristupom podacima pacijenata, privolama, ulogama medicinskog osoblja, revizijskim tragom, rokovima čuvanja dokumenata, integracijama ili ljudskim odobravanjem.

Sve to mora biti ugrađeno u softverski sloj oko modela.

U jednom od Allmaticsovih HealthTech projekata tim je izradio AI asistenta temeljenog na modelu Google Med-PaLM 2 za privatne pružatelje zdravstvenih usluga. Projekt je obuhvaćao šire medicinsko radno okruženje, a ne samo zasebno chat sučelje.

Platforma je trebala strukturirati podatke o pacijentima, podržati kliničke radne tijekove i uklopiti se u način na koji zdravstveni djelatnici već rade.

Drugi Allmaticsov zdravstveni projekt pokazuje koliki učinak može imati dobro osmišljen softverski radni tijek čak i bez generativnog AI-ja. Pružatelj zdravstvenih usluga u velikoj se mjeri oslanjao na prijavu pacijenata i razmjenu nalaza putem faksa. Allmatics je dovršio i proširio web portal, automatizirao ključne operacije i izradio prilagođene online obrasce.

Prema potvrđenoj recenziji klijenta na Clutchu, udio narudžbi poslanih faksom smanjen je s gotovo 90% na 20%, dok je online prijava porasla na 80%.

Rezultat je donijelo redizajniranje procesa oko softvera. Sam model to ne bi mogao postići.

Isto načelo vrijedi i nakon uvođenja AI-ja. Organizacija mora kontrolirati kretanje podataka, pravila pristupa, provjeru rezultata i ponašanje sustava kada model nije dostupan ili nije dovoljno siguran u odgovor.

Zbog toga je arhitektura suverenog AI-ja posebno važna u zdravstvu, zrakoplovstvu, industrijskim sustavima, logistici i drugim okruženjima u kojima su kontinuitet rada i sljedivost odluka presudni.

Kako izgleda arhitektura bez čvrste vezanosti uz jednog pružatelja

Ne postoji univerzalna arhitektura za svaki AI proizvod. Razuman dizajn počinje od konkretnog radnog opterećenja, vrste podataka i razine rizika.

Ipak, nekoliko obrazaca može znatno pojednostavniti buduće promjene.

Postavite modele iza internog AI pristupnika

Aplikacija bi se trebala povezivati sa servisom koji kontrolira sama tvrtka, umjesto da izravno komunicira s više pružatelja modela.

Takav servis može standardizirati zahtjeve i odgovore, primjenjivati pravila pristupa, odabrati odgovarajući model i bilježiti korištenje.

Zahtjev korisničkoj podršci može se poslati brzom upravljanom modelu. Osjetljiv dokument može obraditi privatni model. Odgovor s niskom razinom pouzdanosti može se proslijediti drugom modelu ili osobi na provjeru.

Aplikacija ne mora poznavati sve tehničke detalje implementacije.

Poslovnu logiku držite izvan uputa modelu

Upute modelu korisne su, ali ne bi trebale biti jedino mjesto na kojem se čuvaju procesna pravila.

Zahtjevi validacije, pristupna prava, pragovi odobravanja i obrada iznimki trebaju ostati jasno definirani u aplikacijskom sloju. Takav sustav lakše je testirati, revidirati i održavati.

Uputa može od modela tražiti strukturirani odgovor. Pozadinski sustav i dalje mora provjeriti odgovara li rezultat zadanoj shemi i poslovnim pravilima.

Zadržite kontrolu nad podatkovnim tokom

Unos dokumenata, prethodnu obradu, metapodatke te pravila čuvanja i brisanja treba projektirati kao punopravne dijelove proizvoda.

Tako organizacija dobiva jasnu kartu kretanja informacija: odakle ulaze u sustav, kako se mijenjaju i gdje se pohranjuju.

Time migracija postaje realnija. Tvrtka može ponovno izraditi vektorske prikaze, zamijeniti vektorsku bazu ili uvesti drukčiji način dohvaćanja bez gubitka izvornih podataka i metapodataka potrebnih za obnovu indeksa.

Ugradite nadzor i sljedivost u proizvod

Produkcijski timovi moraju imati vlastitu operativnu evidenciju.

Najmanje bi trebali moći pratiti:

• korisnika ili sustav koji je pokrenuo zahtjev;
• korišteni model i njegovu verziju;
• uputu ili verziju upute;
• dohvaćeni kontekst;
• pozive alata i vanjske radnje;
• vrijeme odaziva i trošak;
• rezultate validacije;
• ljudske ispravke.

Ti podaci pomažu inženjerskim timovima uspoređivati modele i istraživati kvarove. Vlasnicima proizvoda daju i realniju sliku o tome gdje AI stvara vrijednost, a gdje proizvodi dodatni ručni rad.

Projektirajte sustav za više načina implementacije

Microsoft i Mistral izričito podržavaju cloud, cloud-connected i potpuno izolirane implementacije. Taj raspon pokazuje koliko su se poslovna radna opterećenja međusobno udaljila.

Nekim je zadacima potrebna skalabilnost oblaka. Drugi zahtijevaju lokalnu obradu zbog vremena odaziva, povjerljivosti ili zahtjeva za neprekidnim radom.

Prenosiv aplikacijski sloj omogućuje kombiniranje oba pristupa.

Primjerice, sustav može osjetljive izvorne podatke obrađivati lokalno, anonimizirani sadržaj slati vanjskom modelu, a konačni operativni zapis pohraniti u vlastitom okruženju tvrtke.

Prava granica ovisi o konkretnom procesu. Treba je odrediti prije nego što produkcijska upotreba učini postojeću arhitekturu skupom za promjenu.

Suvereni AI ne znači da sve mora raditi lokalno

Privatna infrastruktura pruža više kontrole, ali donosi i dodatne troškove i odgovornosti.

Organizacija mora osigurati računalne kapacitete, postupke implementacije, sigurnosna ažuriranja, nadzor, održavanje modela i zaposlenike koji mogu upravljati takvim okruženjem.

Za brojna uobičajena radna opterećenja upravljani cloud model i dalje je praktičan izbor.

Dobra arhitektura ostavlja taj izbor otvorenim.

Ona omogućuje da zadaci niskog rizika i velikog opsega ostanu u upravljanom okruženju, dok se odabrani radni tijekovi premještaju u privatni oblak, lokalnu infrastrukturu ili na rubne uređaje.

Allmatics pruža sigurnu lokalnu obradu podataka, razvoj privatnog AI-ja i prilagođenih AI/ML sustava. Polazište ipak trebaju biti poslovna ograničenja, a ne unaprijed donesena odluka u korist jednog modela implementacije.

Vrijedi postaviti nekoliko pitanja:

• Koji podaci ne smiju napustiti organizaciju?
• Koji radni tijekovi moraju nastaviti raditi tijekom prekida internetske veze ili nedostupnosti vanjskog pružatelja?
• Gdje je potrebno predvidljivo vrijeme odaziva?
• Kolika je razina prilagodbe modela potrebna?
• Koliko se brzo model mora poboljšavati?
• Kojim operativnim kapacitetima tvrtka već raspolaže?

Za jednu tvrtku suverena arhitektura može značiti potpuno izoliran sustav. Za drugu može značiti aplikaciju neovisnu o pružatelju koja istodobno koristi nekoliko upravljanih usluga.

Oba pristupa mogu biti opravdana.

Može li vaša tvrtka doista premjestiti svoj AI?

Jednostavna provjera arhitekture može pokazati je li AI proizvod prenosiv ili samo ostavlja takav dojam.

Postavite pet pitanja:

1. Možemo li zamijeniti glavni model bez prepisivanja ključnog poslovnog radnog tijeka?
2. Znamo li gdje se pohranjuju upute, zapisnici, vektorski prikazi i podaci za evaluaciju?
3. Ima li AI funkcionalnost jasno definiranu servisnu granicu i interni API?
4. Možemo li odabrana radna opterećenja premjestiti u privatno ili lokalno okruženje?
5. Mogu li ključni dijelovi proizvoda nastaviti raditi ako vanjska AI usluga postane nedostupna?

Tri ili više negativnih odgovora obično upućuju na strukturnu ovisnost.

Takva ovisnost može biti prihvatljiva za prototip. Teže ju je opravdati nakon što AI počne obrađivati podatke korisnika, utjecati na poslovne odluke ili podržavati svakodnevne operacije.

Gdje se uklapa Allmatics

Suvereni AI stvara potražnju za infrastrukturom, modelima, pravnim okvirima i sigurnosnim kontrolama. Istodobno stvara i velik softversko-inženjerski zadatak.

Netko i dalje mora izgraditi aplikaciju koja povezuje podatke tvrtke, AI modele i operativne radne tijekove.

Allmatics razvija prilagođene AI i softverske proizvode za zdravstvo, HRTech, maloprodaju, logistiku, zrakoplovstvo i druge industrije koje rade s velikim količinama podataka. Opseg rada može uključivati:

• arhitekturu AI sustava i product discovery;
• integraciju i orkestraciju modela;
• prilagođene web i mobilne aplikacije;
• privatnu i hibridnu implementaciju AI-ja;
• sustave za obradu dokumenata;
• integracije s ERP, CRM, EHR i ATS sustavima;
• pristup temeljen na ulogama i tijekove odobravanja;
• nadzor, revizijske zapise i ljudsku provjeru;
• modernizaciju postojećih platformi.

Cilj je jasan: ključni poslovni proces ostaje pod kontrolom klijenta, dok se pojedinačni modeli i infrastrukturne komponente mogu mijenjati s razvojem tržišta.

Za timove koji AI funkcionalnost premještaju iz pilot-faze u produkciju, pregled arhitekture često je najkorisniji prvi korak. On otkriva ovisnosti o modelima, tokove podataka, integracijske rizike i komponente koje bi trebale ostati prenosive ili privatne.

Razgovarajte s Allmaticsovim AI/ML razvojnim timom o softverskom sloju na kojem počiva vaš AI proizvod.

Često postavljana pitanja

Što je arhitektura suverenog AI-ja?

Arhitektura suverenog AI-ja način je projektiranja sustava koji organizaciji daje jasno definiranu kontrolu nad AI podacima, modelima, aplikacijskom logikom, okruženjem implementacije i operativnim procesima. Potrebna razina kontrole ovisi o vrsti radnog opterećenja i regulatornom kontekstu.

Zahtijeva li suvereni AI lokalnu implementaciju?

Ne. Suverena arhitektura može koristiti javni oblak, privatni oblak, lokalnu infrastrukturu ili hibridni model. Ključno je razumije li i kontrolira organizacija gdje se podaci obrađuju, kako sustav radi i koliko se lako njegove komponente mogu zamijeniti.

Kako prilagođeni softver smanjuje ovisnost o AI pružatelju?

Prilagođeni softver može postaviti modele iza internog API-ja, zadržati radne tijekove izvan vanjskih platformi, čuvati zapisnike i podatke za evaluaciju pod kontrolom tvrtke te podržavati više modela i okruženja implementacije. Time buduća migracija postaje znatno izvedivija.