Šta je arhitekta AI platforme? Modeli, podaci, izvršno okruženje, bezbednost i operacije

Arhitekta AI platforme projektuje višekratno upotrebljivu AI osnovu preko koje više aplikacija, timova ili korisničkih konteksta pristupa modelima, podacima i pretraživanju, izvršnim okruženjima agenata i alata, identitetu i dozvolama, evaluaciji, nadzoru, kvotama, tajnama i mogućnostima za implementaciju. Uloga je šira od infrastrukture, ali uža od vlasništva nad svakim AI proizvodom: njena centralna odgovornost je da odluči šta treba deliti, kako se deljene mogućnosti upravljaju i izoluju, i šta mora ostati specifično za rešenje.

Šta Arhitekta AI platforme zapravo projektuje?

Predmet rada je platforma: skup zajedničkih mogućnosti koje smanjuju ponovljeni rad na integraciji uz očuvanje eksplicitnih bezbednosnih, podatkovnih i operativnih granica. Platforma može izložiti pristup modelima, adaptere dobavljača, primitive pretraživanja, izvršavanje agenata, brokere alata, sprovođenje politika, evaluaciju, telemetriju i usluge implementacije mnogim potrošačkim rešenjima.

Platforma nije vredna samo zato što su komponente centralizovane. Vredna je kada potrošači dobijaju stabilne mogućnosti sa jasnim ugovorima, vlasništvom, izolacijom, nadzorom i pravilima životnog ciklusa. Ključno arhitektonsko pitanje stoga nije „Koji model treba svi da koriste?“ već „Koje se odgovornosti mogu bezbedno standardizovati i ponovo koristiti bez brisanja zahteva svakog rešenja?“.

Najjednostavniji primer

Zamislite da organizacija ima pet AI proizvoda: internog asistenta za dokumente, kopilota za korisničku podršku, agenta za softverski inženjering, tok rada za pregled ugovora i asistenta za pretragu proizvoda. Svaki proizvod može nezavisno integrisati API-je modela, čuvati akreditive, implementirati ponovne pokušaje, prikupljati metrike tokena, kreirati kod za pretraživanje i graditi sopstvene dozvole za alate.

To dupliranje je skupo i opasno kada svaki tim izmišlja drugačiji bezbednosni i operativni model. Zajednička platforma umesto toga može ponuditi odobrene veze sa dobavljačima, otkrivanje modela, kvote, akreditive, pristup svesan korisnika, zajedničku telemetriju, višekratno upotrebljive usluge pretraživanja i ugovor o izvršnom okruženju agenata/alata.

Ali platforma mora stati na pravoj granici. Rešenje za pregled ugovora može zahtevati nadležnost nad pravnim dokumentima i pravila citiranja koja softverski agent ne zahteva. Asistent za pretragu proizvoda može zahtevati pravila svežine i autorizacije specifična za trgovinu. Višekratno upotrebljiva infrastruktura ne čini svu domensku istinu višekratno upotrebljivom.

Gde se jednostavan primer zaustavlja

Centralizacija nije automatski arhitektura. Jedna krajnja tačka ispred nekoliko API-ja modela je korisna, ali sama po sebi ne stvara AI platformu. Produkciona platforma takođe zahteva granice identiteta, ugovore o mogućnostima, upravljanje zdravljem i životnim ciklusom dobavljača, kvote, vlasništvo nad tajnama, nadzor, pravila kompatibilnosti, bezbednosne kontrole, disciplinu izdanja i jasnu operativnu odgovornost.

Suprotan neuspeh je takođe čest: stavljanje svakog upita, vektorskog indeksa, poslovnog pravila, agenta i toka rada aplikacije u jedan „AI backend“. To stvara monolit čiji je zajednički status slučajan, a ne arhitektonski. Platforma treba da standardizuje sveobuhvatne mogućnosti, a ne da preuzima domensko vlasništvo samo zato što je AI uključen.

Najvažnija odluka platforme: deljeno naspram specifičnog za rešenje

Mapa odgovornosti arhitekture

1. Pristup modelu i provajderu

Arhitekta platforme definiše kako potrošači otkrivaju i pozivaju modele bez prisiljavanja svake aplikacije da hardkodira jednog provajdera. Ovo uključuje adaptere provajdera, identifikatore modela, metapodatke o sposobnostima, autentifikaciju, provere zdravlja, konfiguraciju krajnjih tačaka, normalizaciju zahteva i ponašanje kompatibilnosti.

Apstrakcija provajdera mora ostati iskrena. Različiti provajderi izlažu različita ograničenja konteksta, semantiku alata, ponašanje strukturiranog izlaza, multimodalne sposobnosti, sigurnosne kontrole, keširanje, cene i načine otkaza. Dobra apstrakcija stvara stabilan ugovor platforme dok čuva pristup sposobnostima koje se ne mogu smisleno spljoštiti.

2. Gejtvej, rutiranje, kvote i kontrole troškova

Zajednički AI gejtvej može centralizovati autentifikaciju, rutiranje, ograničavanje, ponovne pokušaje, ograničenja tokena, atribuciju upotrebe i sprovođenje politike. Microsoft-ove trenutne smernice za AI Gateway eksplicitno tretiraju ograničenja tokena u minuti, kvote i višeprojektno zadržavanje kao pitanja platforme; AWS takođe izlaže kvote naloga i modela i centralizovane kontrole.

Gejtvej je stoga više od obrnutog proksija kada nosi AI-specifičnu politiku i operativnu semantiku. Ali ne bi trebalo tiho da donosi poslovne odluke. Politika rutiranja može preferirati zdrav lokalni model, jeftinijeg provajdera ili regionalno usklađenu krajnju tačku; da li je ta ruta prihvatljiva za određeni zadatak i dalje je ugovor između platforme i rešenja.

Rutiranje takođe zahteva semantiku otkaza. Ako preferirani model nije dostupan, platforma mora znati da li je fallback dozvoljen, da li cloud ruta zahteva eksplicitnu saglasnost, da li je model nižih sposobnosti validan i kako se odluka prikazuje u observability-ju.

3. Zajednički podaci, usluge pretrage i utemeljenja

Usluge pretrage su jaki kandidati za platformu jer su parsiranje, deljenje na delove, indeksiranje, leksička pretraga, semantička pretraga, filtriranje metapodataka, poreklo i mehanika citiranja ponovo upotrebljivi. Međutim, platforma ne sme da pobrka zajednički motor za pretragu sa zajedničkim izvorom istine.

Rešenje i dalje poseduje pitanja kao što su: Koji korpus je autoritativan? Koja verzija je validna? Može li ovaj korisnik da vidi ovaj dokument? Koliko sveži podaci moraju biti? Šta se smatra dovoljnim dokazom? Može li se odgovor generisati kada pretraga ne uspe? To su zahtevi domena i rešenja čak i kada platforma obezbeđuje mehanizam pretrage.

Ova granica je posebno važna u multi-tenant sistemima. Tehnički zajednički indeks ili vektorska usluga ne opravdava vidljivost između zakupaca. Kontekst autorizacije mora se sačuvati kroz pretragu, a ne dodavati tek nakon što su rezultati pretrage već prešli granicu.

4. Vreme izvršavanja agenata i alata

Agentni sistemi dodaju ponovo upotrebljive brige o vremenu izvršavanja: životni ciklus niti/sesije, petlje planiranja, registracija alata, pozivanje alata, otkazivanje, vremenski limiti, ljudska odobrenja, interfejsi memorije/stanja, protokoli udaljenih agenata i korelacija tragova. Platforma može da obezbedi ovu mehaniku kako svaki proizvod ne bi ponovo gradio.

Platforma takođe mora da drži dozvolu za alat odvojeno od sposobnosti modela. To što je model sposoban da generiše shell komandu ne znači da bi vreme izvršavanja trebalo da dozvoli izvršavanje shell-a. Granica dozvole pripada arhitekturi aplikacije/vremena izvršavanja i mora biti sprovodiva nezavisno od modela.

Trenutne AWS smernice za agentnu AI naglašavaju ograničene agente, eksplicitna ovlašćenja, praćenje od početka do kraja, verzionisane artefakte ponašanja i ljudski nadzor srazmeran posledicama. To su pitanja koja omogućavaju platformu, ali rešenje koje je koristi i dalje definiše koje su radnje legitimne za njegov domen.

5. Identitet, izolacija zakupaca i autorizacija

AI platforme često stoje ispred modela visoke vrednosti, vlasničkih podataka i alata sposobnih za radnje. Autentifikacija je zato samo početak. Arhitektura mora da nosi kontekst korisnika, servisa, aplikacije i zakupca kroz svaku privilegovanu operaciju kojoj je to potrebno.

RBAC i izolacija zakupaca rešavaju različite probleme. RBAC odgovara šta identitet sme da radi; izolacija zakupaca odgovara na čije resurse tog zakupca taj identitet sme da deluje. Platforma koja proverava uloge ali izgubi kontekst zakupca i dalje može da izloži pogrešne podatke.

Microsoft-ove trenutne smernice za AI radna opterećenja eksplicitno preporučuju segmentaciju identiteta i pristup sadržaju svestan autorizacije. AWS-ove smernice za višezakupničku generativnu AI platformu takođe tretiraju logičku izolaciju, centralizovane kontrole i mogućnost revizije kao pitanja platforme.

6. Tajne, akreditivi i granice poverenja

Platforma treba da definiše ko poseduje ključeve provajdera, udaljene bearer tokene, materijal za potpisivanje i akreditive alata, gde se čuvaju, koji proces im može pristupiti, kako se rotiraju i mogu li ikada stići do pregledača ili nepouzdanog renderera.

Ovo je arhitektonska granica, a ne detalj implementacije. Ako svaka aplikacija koja koristi platformu kopira akreditive provajdera u sopstvenu konfiguraciju, organizacija je duplirala i operativni teret i domet štete. Centralizacija može smanjiti taj rizik samo ako sama platforma ima uže, proverljive pristupne putanje.

7. Evaluacija, observabilnost i mogućnost revizije

Platforma koja se može ponovo koristiti može da obezbedi okvire za evaluaciju, ID-ove tragova, metapodatke modela/provajdera, metrike tokena i troškova, latenciju, stope grešaka, povezivanje verzija upita/modela, tragove agenata/alata i kontrolisano evidentiranje. I AWS i Microsoft tretiraju observabilnost i evaluaciju kao ključna produkciona pitanja za AI radna opterećenja.

Evaluacija platforme i evaluacija rešenja moraju ostati odvojene. Platforma može da potvrdi da je endpoint zdrav, da verzija modela prolazi opšti regresioni paket i da su tragovi potpuni. Ne može da odluči da su pravni odgovor, medicinski tok rada ili preporuka proizvoda prihvatljivi bez ground truth-a i kriterijuma prihvatanja specifičnih za domen.

Evidentiranje takođe stvara granicu privatnosti. Dnevnici upita i odgovora mogu sadržati osetljive ili vlasničke podatke. Arhitekta platforme zato mora da odluči šta se evidentira, rediguje, uzorkuje, zadržava i čini dostupnim, umesto da pretpostavlja da je više telemetrije uvek bezbednije.

8. Izvršno okruženje, raspoređivanje i lokalnost

Arhitekta platforme odlučuje kako se deljene AI sposobnosti raspoređuju i dohvataju: upravljani cloud servisi, samostalno hostovani endpointi, lokalna inferencija, hibridno rutiranje, kontejnerizovani servisi, desktop izvršna okruženja, privatno umrežavanje ili vazdušno izolovana okruženja. Važna razlika je između toga gde se izvršava proces kontrole/izvršnog okruženja i toga gde se inferencija i obrada podataka zaista odvijaju.

Lokalni klijent i dalje može da poziva cloud model. Cloud kontrolna ravan može da rutira ka on-premises modelu. Udaljeni agent može da izvršava alate unutar mreže korisnika. Arhitektonski dijagrami zato moraju da prikazuju granice poverenja i tokova podataka, umesto da koriste „lokalno“ i „cloud“ kao nejasne oznake.

9. Životni ciklus platforme, kompatibilnost i onboarding

Sposobnost koja se može ponovo koristiti postaje platforma tek kada korisnici mogu dugoročno da se oslone na nju. To zahteva verzionisane ugovore, pravila migracije, politiku kompatibilnosti, ukidanje, testiranje izdanja, vraćanje na prethodnu verziju, vlasništvo nad incidentima, planiranje kapaciteta, dokumentaciju i put za uvođenje novih timova ili aplikacija.

AI ekosistemi koji se brzo menjaju čine ovo posebno važnim. Imena modela, SDK-ovi, verzije protokola, API-ji provajdera i bezbednosne sposobnosti menjaju se nezavisno. Platforma mora da apsorbuje deo te volatilnosti bez skrivanja promena koje materijalno utiču na ponašanje rešenja.

Praktični model kontrolne ravni / izvršne ravni / ravni rešenja

Ovo razdvajanje pomaže u dijagnostikovanju odstupanja platforme. Ako aplikacija mora da zna svaki akreditiv i endpoint specifičan za provajdera, ugovor platforme je previše tanak. Ako platforma odlučuje koji je korisnički zapis pravno autoritativan ili da li je odgovor domena prihvatljiv, platforma je prešla u vlasništvo rešenja.

Šta bi arhitekta AI platforme trebalo da proizvede?

Posao je uglavnom kompromis, a ne maksimalna centralizacija

Kako se ovo razlikuje od srodnih uloga?

Ove granice su organizacione, a ne univerzalne. U malom timu jedna osoba može imati nekoliko odgovornosti. U regulisanom preduzeću mogu biti podeljene između grupa za arhitekturu, bezbednost, platformu, podatke i operacije. Korisna razlika je opseg arhitektonske odgovornosti, a ne naziv radnog mesta na organizacionoj šemi.

Dokaz implementacije: kako se ove granice platforme pojavljuju u mom radu

Aaasaasa AI Client: razdvajanje provajdera, izvršnog okruženja i dozvola

Aaasaasa AI Client je lokalno-prvenstveni desktop AI radni prostor izgrađen sa Nuxt 4, Electron i TypeScript. Njegov AI Hub namerno razdvaja agenta/klijenta, provajdera, model, lokaciju veze/izvršnog okruženja, dozvole i web klijenta umesto da ih tretira kao jednu konfiguracionu vrednost.

Implementacija uključuje direktne adaptere provajdera, integraciju Codex agent izvršnog okruženja, lokalne Ollama/LM Studio putanje, servise kompatibilne sa OpenAI, centralizovane dozvole radnog prostora, skladištenje akreditiva u glavnom procesu, DuckDB, Qdrant/vektorsku podršku, PDF/readability ekstrakciju i autentifikovani pristup direktorijumu zasnovan na MCP.

Dve lekcije o platformi su posebno relevantne. Prvo, lokalno izvršno okruženje nije isto kao lokalna inferencija: lokalni Codex proces i dalje može koristiti cloud model. Drugo, automatsko rutiranje ne prelazi tiho sa lokalne na plaćenu cloud inferenciju. To čini politiku rutiranja i lokalnost izvršnog okruženja eksplicitnim, a ne izvedenim iz UI oznaka.

Aaasaasa AI CMS: autorizacija ograničena na tenanta kao granica platforme

Kodna baza Aaasaasa AI CMS pruža poseban primer implementacije: RBAC ograničen na tenanta predstavljen je kroz uloge, dozvole i dodele korisničkih uloga vezane za identifikator tenanta. Sistemske dozvole su grupisane po sposobnostima, a pretraga i ažuriranje uloga ostaju ograničeni na tenanta.

Ovo samo po sebi nije dokaz kompletne AI platforme, ali je direktno relevantno za jednu od najtežih granica deljene platforme: usluga koja se može ponovo koristiti mora da očuva ko sme šta da radi i za kog tenanta. Dodavanje AI inferencije ili pretrage na vrhu aplikativne platforme ne uklanja taj zahtev.

Arhitektonska implikacija je da bi model gateway-i, servisi za pretragu i agenti trebalo da koriste uspostavljeni identitetski/tenant kontekst umesto da izmišljaju paralelni univerzum autorizacije samo za AI.

Source of Truth Research Engine: deljeni mehanizmi pretrage bez deljene istine

Source of Truth Research Engine pruža treći primer implementacije. Različiti režimi istraživanja dele zajedničko jezgro dokaza: Sources, Artifacts, provenance, Claims, Relations, Contradictions, Reference Model i revizorski trag. Sistem takođe pruža lokalnu leksičku pretragu, opcionu semantičku pretragu, ekstrakciju, snimke i provenance zasnovan na SHA-256.

Projekat eksplicitno tretira pretragu i semantičku sličnost kao signale za otkrivanje, a ne kao dokaze. Rezultat mora biti ušančen nazad do konkretnog izvora i lokatora pre nego što može da podrži tvrdnju. Upravo to je razlika koja je potrebna AI platformi: mehanizmi pretrage koji se mogu ponovo koristiti mogu biti deljeni dok autoritet dokaza ostaje vođen metodologijom koja ih koristi i domenom.

Engine takođe pokazuje zašto jedna deljena platforma ne zahteva jedno deljeno tumačenje. Istorijski, naučno-tehnički, režimi tržišne inteligencije i monitoringa mogu ponovo koristiti osnovnu infrastrukturu dokaza dok zadržavaju metodologiju specifičnu za režim.

Kako trenutne arhitektonske smernice podržavaju ovaj obim platforme

ISO/IEC/IEEE 42010:2022 pruža opštu disciplinu za opise arhitekture kroz softver, sisteme, preduzeća i povezane entitete. Ne definiše AI Platform Architect, ali pojačava potrebu da se izraze arhitektonske brige, odnosi i stanovišta umesto da se arhitektura svede na listu tehnologija.

NIST AI RMF 1.0 i Generative AI Profile uokviruju upravljanje AI rizikom kroz životni ciklus, a ne samo u trenutku izbora modela. Upravljanje, mapiranje, merenje i upravljanje su stoga kompatibilni sa arhitekturom platforme koja nosi deljene kontrole i dokaze kroz mnoge radne opterećenja koja ih koriste.

Microsoft-ove trenutne smernice za AI radna opterećenja tretiraju dizajn aplikacije, podatke, bezbednost, operacije, testiranje/evaluaciju i GenAIOps kao povezane arhitektonske oblasti. Njegove trenutne smernice za AI Gateway takođe pokazuju praktične brige platforme kao što su centralizovani pristup modelima, ograničenja tokena specifična za projekat, kvote i zadržavanje više timova.

AWS-ov trenutni Generative AI Lens i scenario platforme sa više zakupaca na sličan način razdvajaju temeljne kontrole platforme od vlasništva aplikacije koja ih koristi. AWS eksplicitno napominje da centralna platforma može da sprovodi deljene zaštitne mere i revizibilnost dok kvalitet podataka i observabilnost specifična za radno opterećenje i dalje ostaju odgovornost aplikacija koje ih koriste ili proizvođača podataka.

Proizvodi dobavljača se razlikuju, ali obrazac između izvora je stabilan: produkcijske AI platforme moraju da koordiniraju identitet, pristup podacima, modele, politiku, evaluaciju, observabilnost, kapacitet, troškove i životni ciklus. GPU klaster ili endpoint modela pokriva samo deo te odgovornosti.

Uobičajene zablude

Načini otkaza koje AI Platform Architect treba da spreči

Praktičan sled odluka o arhitekturi platforme

Rubni slučajevi i ograničenja uloge

Mala organizacija sa jednom AI aplikacijom možda neće imati potrebu za posebnom AI platformom ili platform arhitektom. Prevremeno platformisanje može stvoriti više apstrakcije nego vrednosti. Ispravna arhitektura može biti jedno dobro dizajnirano rešenje sa nekoliko modula za ponovnu upotrebu.

Air-gapped ili suvereno postavljanje značajno menja model provajdera, ažuriranja i observability. Hostovanje modela, distribucija artefakata, integracija identiteta i izvoz telemetrije mogu zahtevati lokalne ekvivalente.

Visoko regulisana ili radna opterećenja sa velikim posledicama mogu zahtevati jaču fizičku ili organizacionu izolaciju umesto logički deljene platforme. Ponovna upotreba nikada nije dovoljan razlog da se oslabi zahtevana bezbednosna granica.

Managed cloud AI servisi mogu ukloniti teret implementacije, ali ne uklanjaju arhitektonsku odgovornost. Organizacija i dalje odlučuje o identitetu, pristupu podacima, logovanju, zadržavanju, kvotama, podobnosti modela, fallback-u, evaluaciji i prihvatanju rešenja.

Granica platforme može se razlikovati i po modalitetu. Tekstualna inferencija, multimodalna generacija, govor, korišćenje računara i autonomni agenti mogu imati različite zahteve za latenciju, podatke, dozvole i observability čak i kada dele infrastrukturu provajdera i identiteta.

Šta bi promenilo ovaj odgovor?

Osnovna definicija bi se promenila ako se promeni organizacioni obim. Ako arhitekta poseduje jedno radno opterećenje, uloga postaje bliža AI Solution Architect. Ako se odgovornost proširi na strategiju sposobnosti na nivou organizacije, investicije, standarde i portfolije ciljnog stanja, pomera se ka Enterprise AI Architecture.

Smernice za implementaciju se menjaju kad god se promene provajderi, gateway proizvodi, protokoli agenata, regulatorne obaveze, mogućnosti modela ili ograničenja postavljanja. Zato arhitektura platforme treba da izražava stabilne odgovornosti i ugovore odvojeno od trenutnih mehanizama dobavljača.

Kontrolna lista AI Platform Arhitekte

Zaključak

AI Platform Arhitekta je odgovoran za arhitekturu za ponovnu upotrebu između AI mogućnosti i rešenja koja ih koriste. Uloga definiše kako modeli, provajderi, retrieval, agenti, alati, identitet, tenanti, tajne, evaluacija, observability, kvote i runtime operacije postaju pouzdani platformski servisi umesto ponovljenih jednokratnih integracija.

Težak deo nije maksimiziranje ponovne upotrebe. To je izbor ispravne granice. Jaka platforma standardizuje mehanizme, politiku i operacije tamo gde više potrošača zaista ima koristi, dok čuva autoritet nad podacima specifičan za rešenje, poslovnu logiku, bezbednosne zahteve i kriterijume prihvatanja.

Ta razlika takođe objašnjava odnos sa AI Solution Architecture: solution arhitekta čini da jedan AI-omogućen sistem odgovara svojoj svrsi; platform arhitekta čini da deljene AI mogućnosti budu bezbedne, ponovo upotrebljive, operativne i evolutivne kroz mnoge takve sisteme.

Povezano kanonsko znanje

Ovaj članak se nadovezuje na kanonske osnove o komponentama generativne AI, ADR naspram NFR i AI Solution Architecture. Ti koncepti su preduslovi jer platforma postoji da bi pružala višekratno upotrebljive sistemske mogućnosti i kodifikovala arhitekturne odluke u skladu sa eksplicitnim zahtevima kvaliteta i operativnim zahtevima.

Retrieval-Augmented Generation je jedan primer mogućnosti koja se može ponuditi kroz platformu, ali platforma ne bi trebalo da sažme infrastrukturu za pretragu, domensko znanje i validnost odgovora u jedan koncept.

Agent protokoli, izolacija zakupaca, AI upravljanje, rutiranje modela, Context Engineering i MLOps/LLMOps su nizvodni ili susedni čvorovi znanja. Oni postaju lakši za razumevanje kada je granica platforme eksplicitna.

Često postavljana pitanja

Pojmovnik

Primarni izvori i aktuelne smernice arhitekture

Izvori ispod podržavaju opšte tvrdnje o arhitekturi i produkcijskoj platformi. Sekcije Aaasaasa AI Client, Aaasaasa AI CMS i Source of Truth Research Engine su eksplicitno originalni dokazi implementacije. Eksterni izvori o trenutnom stanju provereni su 8. oktobra 2026.