Šta je AI rešenje arhitekta? Granice sistema, odgovornosti i kompromisi

AI Solution Architect prevodi poslovnu ili proizvodnu potrebu u arhitekturu konkretnog AI rešenja. Uloga definiše granice sistema i značajne izbore u okviru aplikacione logike, autoritativnih podataka, pretrage i konteksta, modela i provajdera, alata ili agenata, identiteta i dozvola, bezbednosti, izvršavanja i implementacije, nadzora, evaluacije, troškova i operativnog ponašanja. To nije samo izbor modela ili inženjering upita: arhitektonska odgovornost je da celo rešenje bude implementabilno, upravljivo, testabilno i operabilno.

Šta AI Solution Architect zapravo projektuje?

Predmet rada je rešenje: kompletan socio-tehnički sistem koji potrebu pretvara u korisno, kontrolisano ponašanje. Model može biti centralni za taj sistem, ali je i dalje samo jedna zavisnost. Isti model može učestvovati u bezbednom internom pretraživačkom asistentu, nebezbednom agentu sa prekomernim privilegijama, korisničkoj funkciji sa malim kašnjenjem ili skupom prototipu koji se ne može ekonomski operisati. Arhitektura određuje te razlike.

Korisna granica je stoga: poslovni ishod → zahtevi → odgovornosti sistema → arhitektonske odluke → implementacija → validacija → operacija. AI Solution Architect radi duž ovog lanca, sarađujući sa produktom, inženjeringom, podacima, bezbednošću, infrastrukturom, upravljanjem i domenskim specijalistima.

Najjednostavniji primer

Zamislite da kompanija želi internog asistenta koji odgovara na pitanja tehničara na osnovu priručnika za održavanje i operativnih procedura. Vidljiva funkcija zvuči jednostavno: ukucajte pitanje i primite odgovor sa izvorima.

Arhitektonsko pitanje je mnogo veće. Koji dokumenti su autoritativni? Kako se korisnici autentifikuju? Da li pretraga mora poštovati dozvole odeljenja ili lokacije? Da li odgovor sme koristiti samo pronađene dokaze? Koji model je prihvatljiv za klasifikaciju podataka? Može li cloud provajder primiti sadržaj? Šta se dešava kada pretraga ne pronađe ništa? Kako se proizvode citati? Kako se evaluira kvalitet odgovora? Koje kašnjenje i trošak su prihvatljivi? Ko može videti logove i šta se u njima sme čuvati?

Gde se jednostavan primer zaustavlja

Proof of concept često može preskočiti arhitekturu koju produkcija ne može. Programer može hardkodirati jednog provajdera, koristiti deljeni API ključ, smestiti sve dokumente u jedan indeks, pokretati pretragu bez filtriranja po korisničkom kontekstu, logovati upite doslovno i procenjivati kvalitet ručno. To može demonstrirati izvodljivost, ali ne uspostavlja produkcijsku arhitekturu.

Produkcija uvodi ograničenja koja interaguju: izolaciju zakupaca ili korisnika, privatnost, rezidentnost podataka, propusnost, kašnjenje, troškove, kvote provajdera, rezervno ponašanje, revizibilnost, promene verzija modela, kvalitet pretrage, dozvole alata, odgovor na incidente i životni ciklus implementacije. Posao arhitekte nije da maksimizuje svaki kvalitet odjednom; već da kompromise učini eksplicitnim i projektuje rešenje koje zadovoljava stvarni skup prioriteta.

Mapa arhitektonskih odgovornosti

Tačna podela varira od organizacije do organizacije, ali sledeća mapa obuhvata ponavljajuće odgovornosti arhitekture AI rešenja. Arhitekta možda neće lično implementirati svaki sloj; odgovornost je da slojevi funkcionišu koherentno i da kritične odluke ostanu sledljive.

1. Pretvorite potrebu proizvoda u arhitektonske zahteve

AI arhitektura počinje pre izbora modela. Arhitekta prvo utvrđuje šta se od rešenja očekuje da postigne i pod kojim ograničenjima. To uključuje funkcionalno ponašanje, ali i NFR-ove i politike koje sužavaju prostor dizajna: bezbednost, pouzdanost, latenciju, privatnost, rezidentnost, održivost, troškove i operativnu podršku.

Ovde je važna razlika iz A02: zahtev kao što je „neovlašćeni korisnici ne smeju da pronađu ograničene dokumente“ nije arhitektonska odluka. To je pokretač. Odluke o propagaciji identiteta, particionisanju indeksa, filtriranju metapodataka, granicama API-ja i sprovođenju autorizacije su arhitektonski odgovori koji kasnije moraju biti validirani.

2. Dizajnirajte autoritativne podatke, pretragu i kontekst

AI sistemi često padaju na granici između ponašanja modela i istine preduzeća. Arhitekta mora da definiše koji izvori su autoritativni, šta znače svežina i poreklo, kako kontrola pristupa stiže do pretrage i kako pronađeni dokazi postaju kontekst modela. Vektorska baza podataka, model za ugrađivanje ili RAG biblioteka nisu sami po sebi arhitektura.

Microsoft-ove trenutne smernice za AI radna opterećenja eksplicitno prave istu razliku: aplikacioni kod ne treba da zaobilazi granice pristupa podacima; kontekst korisnika ili zakupca treba da se propagira u pretragu i filtriranje; podaci za utemeljenje moraju biti dizajnirani za pretraživost, a istovremeno da zadovolje bezbednosne i regulatorne zahteve.

3. Tretirajte modele i provajdere kao zavisnosti, ne kao ceo sistem

Izbor modela je važan, ali treba da bude vođen potrebnim sposobnostima i ograničenjima. Arhitekta razmatra kvalitet rezonovanja ili generisanja, modalitet, ograničenja konteksta, latenciju, rukovanje podacima, lokaciju implementacije, dostupnost provajdera, troškove, observabilnost i rizik zamene.

Apstrakcija provajdera nije automatski „bolja arhitektura“. Dodaje inženjerske troškove i može da sakrije sposobnosti specifične za provajdera. Opravdana je kada su prenosivost, fallback, razdvajanje politika ili rutiranje ka više provajdera eksplicitni zahtevi. U suprotnom, direktna integracija može biti bolja odluka. Poenta je da kompromis bude nameran.

4. Arhitektirajte alate, radnje i granice agenata

Kada AI sistem može da poziva alate, menja podatke, šalje poruke, pokreće kod ili upravlja poslovnim sistemima, arhitektonski rizik se menja. Pristup alatima zahteva sopstveni model identiteta i autorizacije. Sposobnost modela da zatraži radnju nije isto što i dozvola da je izvrši.

Za agentna radna opterećenja, trenutne AWS smernice naglašavaju dodatne dimenzije kao što su identiteti agenata, pristup alatima, orkestracija, ljudski nadzor, praćenje, rukovanje otkazima i troškovi iterativnih petlji rezonovanja. To su pitanja rešenja čak i kada okvir sakriva neke od mehanizama implementacije.

5. Učinite granice poverenja i dozvole eksplicitnim

Produkcijsko AI rešenje ima više granica poverenja: pregledač ili klijent, aplikacioni backend, AI orkestracija, servisi za pretragu/podatke, provajderi modela, API-ji alata, lokalni runtime-ovi i eksterni sistemi. Svaka granica treba da odgovori: ko poziva, u čije ime, sa kojim akreditivom, za koji resurs, sa kojim revizorskim tragom i sa kojim ograničavanjem otkaza?

Bezbednost se ne može odložiti na „guardrail“ oko modela. Microsoft-ove smernice za AI radna opterećenja eksplicitno postavljaju bezbednost kroz sve arhitektonske slojeve i zahtevaju upravljanje identitetom/pristupom, zaštitu podataka, kontrolu sadržaja i bezbednost životnog ciklusa. NIST takođe tretira upravljanje i upravljanje rizikom kao kontinuirano kroz AI životni ciklus.

6. Odlučite gde sistem zaista radi

„Lokalni AI“, „cloud AI“ i „hibridni AI“ su arhitektonske izjave samo kada su putevi izvršavanja i podataka precizni. Lokalni desktop proces i dalje može da poziva cloud model. Aplikacija hostovana u cloudu može da pronalazi podatke iz on-premises izvora podataka. Air-gapped rešenje ima potpuno drugačija ograničenja ažuriranja, distribucije modela i observabilnosti.

Arhitekta stoga razdvaja lokaciju izvršavanja, lokaciju zaključivanja, lokaciju podataka i kontrolnu ravan. Njihovo poistovećivanje stvara lažnu sigurnost i pretpostavke o raspoređivanju.

7. Definišite evaluaciju, observabilnost i operativno prihvatanje

AI ponašanje je delimično nedeterminističko, pa definicija izdanja ne može da se osloni samo na konvencionalne unit testove. Arhitekturi su potrebni merljivi kriterijumi prihvatanja: uspeh zadatka, utemeljenost ili ispravnost citiranja gde je relevantno, ponašanje odbijanja, bezbednost alata, latencija, trošak, pouzdanost i bezbednosni testovi. Tačne metrike zavise od slučaja upotrebe.

Microsoft-ove trenutne Well-Architected AI smernice tretiraju monitoring kao kontinuiran i primenjuju ga na ponašanje modela, promptove/kompletiranja, anomalije, bezbednost i kapije kvaliteta u produkciji. AWS na sličan način tretira observabilnost, upravljanje životnim ciklusom i sledljivost modela/promptova kao pitanja operativne arhitekture.

Šta bi ova uloga trebalo da proizvede?

Arhitektura nije slajd prezentacija. Korisni izlazi su artefakti koji omogućavaju inženjeringu, bezbednosti, proizvodu i operacijama da donose konzistentne odluke i kasnije razumeju zašto sistem postoji u svom trenutnom obliku.

Rad se uglavnom sastoji od kompromisa, a ne od izbora „najbolje prakse“

Arhitektura postoji jer su poželjni kvaliteti u sukobu. Model sa nižim troškovima može smanjiti kvalitet. Sposobniji model može povećati latenciju ili ograničenja upravljanja podacima. Agresivno keširanje može poboljšati troškove i brzinu, ali otežati svežinu. Autonomniji agenti mogu smanjiti ljudski napor, ali povećati domet štete i zahteve za revizijom.

Kako se ovo razlikuje od srodnih uloga?

Titule se u velikoj meri preklapaju među kompanijama. Korisna razlika je obim arhitektonske odgovornosti, a ne HR oznaka.

U malom produktnom timu, jedna osoba može pokrivati nekoliko ovih obima. U velikom preduzeću, to mogu biti odvojene uloge sa formalnim odborima za pregled. Arhitektonska odgovornost ne nestaje kada se titula promeni.

Dokazi implementacije: kako se ove granice pojavljuju u mom radu

SenseFlow: potreba → zahtevi → arhitektura → validacija

U projektu SenseFlow Source of Truth, tehnologija je eksplicitno podređena Product Vision-u. Razvojna struktura se kreće od problema i vizije proizvoda kroz korisničke potrebe, vrednost, obim, epove, priče i kriterijume prihvatanja do arhitekture, implementacije, validacije i iteracije.

Zahtevi su dizajnirani tako da budu sledljivi od Cilja proizvoda → Sposobnosti → Epika → Korisničke priče → Kriterijuma prihvatanja → Tehničkih zadataka. Gde je praktično, uključuju funkcionalne zahteve, nefunkcionalne zahteve, zavisnosti, rizike, pretpostavke, kriterijume prihvatanja i metode validacije. Značajne odluke čuvaju odluku, razlog, alternative, kompromise, status i datum/verziju.

To je arhitektonski rad pre nego što se izabere konkretan AI okvir ili model: štiti vezu između namere proizvoda i tehničkih odluka i čini kasnije promene preglednim umesto implicitnim.

Aaasaasa AI klijent: razdvojite koncepte pre njihovog integrisanja

Aaasaasa AI klijent pruža primer na nivou implementacije. Njegov AI Hub namerno razdvaja agenta/klijenta, provajdera, model, lokaciju izvršavanja/konekcije, dozvole i veb klijenta. Lokalno izvršavanje se ne pretpostavlja da znači lokalno zaključivanje, a dozvole se tretiraju kao politika izvršavanja/alata, a ne kao svojstvo modela.

Desktop arhitektura takođe definiše granicu poverenja: Nuxt renderer nije pouzdan u odnosu na Electron main. Uzak preload i validirani IPC posreduju u pristupu AI servisima, podešavanjima, enkriptovanim tajnama, servisima radnog prostora/podataka i izvršnim okruženjima. Cloud akreditivi ostaju u privilegovanom glavnom procesu; renderer kod prima normalizovano stanje umesto sirovih tajni ili neograničenog pristupa operativnom sistemu.

Odluke o rutiranju su takođe arhitektonske. Implementacija ne prelazi tiho sa lokalne rute na plaćeno cloud zaključivanje; cloud ruta zahteva eksplicitnu potvrdu. Direktan chat nema podrazumevano alate za fajl sistem ili shell, dok izvršavanje agenta primenjuje izabrani radni prostor i profil dozvola. To su odluke na nivou rešenja o poverenju, troškovima, izvršavanju i očekivanjima korisnika—ne karakteristike modela.

Kako trenutni arhitektonski okviri podržavaju ovaj širi obim

ISO/IEC/IEEE 42010:2022 pruža opštu disciplinu za opise arhitekture kroz softver, sisteme i preduzeća. Namerno je širi od AI i ne propisuje jednu metodu arhitekture ili naziv radnog mesta. To ga čini korisnim ovde kao granicu: AI arhitektura rešenja je i dalje arhitektura, sa interesima zainteresovanih strana, više pogleda i značajnim odnosima koji moraju biti jasno izraženi.

NIST AI RMF 1.0 uokviruje upravljanje AI rizikom kroz Govern, Map, Measure i Manage i naglašava da upravljanje rizikom treba da bude kontinuirano tokom životnog ciklusa AI sistema. Generativni AI profil (NIST AI 600-1) prilagođava taj okvir GAI rizicima i organizacionim prioritetima. To pojačava da arhitektura ne može da se zaustavi na funkcionalnim performansama modela.

Microsoft-ove trenutne Azure Well-Architected AI smernice razdvajaju dizajn aplikacije, platformu aplikacije, podatke za obuku, podatke za utemeljenje i pitanja platforme podataka i više puta ih povezuju sa pouzdanošću, bezbednošću, operativnom izvrsnošću, performansama i troškovima. AWS-ova Generativna AI i Agentic AI sočiva takođe tretiraju observabilnost, bezbednost, pouzdanost, životni ciklus modela/alata, troškove i ljudski nadzor kao arhitektonske brige.

Uobičajene zablude

Načini neuspeha koje AI arhitekta rešenja treba da spreči

Praktičan redosled odlučivanja

Rubni slučajevi i granice uloge

Neki AI proizvodi su dominirani obukom modela, naučnim eksperimentisanjem ili specijalizovanim hardverom. U tim slučajevima, model/data nauka i arhitektura ML sistema mogu postati mnogo dublji od mape na nivou rešenja prikazane ovde. AI arhitekta rešenja i dalje treba integracione i operativne granice, ali specijalistička arhitektura može posedovati samu platformu za obuku.

Na drugom kraju spektra, jednostavna SaaS integracija možda ne opravdava posvećenog arhitektu. Senior inženjer ili tehnički vođa proizvoda može nositi istu arhitektonsku odgovornost. Koristan test nije titula, već da li se značajne odluke koje prelaze slojeve donose namerno i validiraju.

Regulisani, suvereni, vazdušno izolovani, bezbednosno kritični, visoko autonomni ili multi-tenant sistemi takođe pomeraju težište. Identitet, izolacija, rezidentnost, garancija, mehanizmi ažuriranja, ljudski nadzor i mogućnost revizije mogu dominirati kvalitetom modela u arhitekturi.

Šta bi promenilo ovaj odgovor?

Tačna granica odgovornosti se menja kada arhitektura pređe sa jedne aplikacije na platformu koja se može ponovo koristiti ili na ciljnu arhitekturu na nivou preduzeća. Zato AI Platform Architect i Enterprise AI Architecture zaslužuju odvojen kanonski tretman umesto da budu spojeni u ovu ulogu.

Promene tehnologije su takođe važne. Nove mogućnosti modela, protokoli, lokalna izvršna okruženja i upravljane usluge mogu ukloniti deo implementacionog rada dok istovremeno stvaraju nove granice poverenja ili operativne granice. Stabilna odgovornost je razumeti te promene kao promene sistema—a ne tretirati novi okvir kao zamenu za arhitekturu.

AI Solution Architect kontrolna lista

Zaključak

AI Solution Architect je osoba ili arhitektonska funkcija koja pretvara AI priliku u koherentan tehnički sistem. Ključna veština nije poznavanje najvećeg broja imena modela; to je povezivanje potreba proizvoda, zahteva, podataka, arhitekture aplikacije, AI mogućnosti, bezbednosti, izvršnog okruženja, isporuke i validacije bez gubljenja granica između njih.

Jaka arhitektura AI rešenja se stoga može sažeti kao: definiši cilj → uspostavi zahteve i ograničenja → projektuj granice sistema → učini značajne kompromise eksplicitnim → implementiraj kroz jasne ugovore → validiraj na osnovu dokaza → upravljaj i razvijaj namerno. Model je važan. Rešenje je proizvod.

Povezano kanonsko znanje

Ovaj članak pripada klasteru AI Architecture Foundations. Njegovi direktni temelji su Generative AI Explained: Models, Retrieval, Tools and Applications Are Not the Same Thing i ADR vs NFR: Architecture Decisions and System Quality Are Not the Same Thing. Susedni kanonski čvorovi uključuju Agentic AI Explained, Source of Truth in AI Systems, Vector Databases, Embeddings and Reranking, What Is Context Engineering?, RBAC vs Tenant Isolation, AI Platform Architect, Enterprise AI Architecture i AI Governance. URL-ovi namerno nisu izmišljeni tamo gde ti čvorovi još nisu objavljeni.

Primarni izvori i trenutne arhitektonske smernice

Spoljni izvori ispod podržavaju opšte arhitektonske tvrdnje; odeljci SenseFlow i Aaasaasa AI Client su eksplicitno originalni dokazi projekta/implementacije. Reference trenutnog stanja su proverene 8. oktobra 2026. NIST napominje da se AI RMF 1.0 revidira, tako da reference upravljanja osetljive na verziju treba ponovo proveriti kada naslednik bude objavljen.