Upravljanje veštačkom inteligencijom: Modeli, podaci, dozvole, rizik i mogućnost revizije

Upravljanje veštačkom inteligencijom je sistem prava odlučivanja, odgovornosti, kontrola i dokaza koji se koriste za odlučivanje o tome kako organizacija može da razvija, nabavlja, uvodi, upravlja, menja i ukida AI sisteme. Ono je šire od dokumenta politike i uže od cele enterprise arhitekture. Efikasno upravljanje AI povezuje vlasništvo nad poslom, izbor modela i provajdera, nadležnost nad podacima, dozvole, klasifikaciju rizika, evaluaciju, monitoring, rukovanje incidentima, proverljivost i odluke o životnom ciklusu, tako da neko može da odgovori ne samo na pitanje „da li AI radi?“ već i na pitanje „ko ga je odobrio, pod kojim uslovima, uz koje dokaze i kada ta odluka mora ponovo da se razmotri?“

Šta upravljanje AI zaista znači

Upravljanje AI odgovara na organizaciona pitanja na koja model, SDK ili dijagram arhitekture ne mogu sami da odgovore. Ko je vlasnik poslovnog ishoda? Ko može da odobri novog provajdera? Koje klase podataka je zabranjeno obrađivati eksterno? Koji dokazi su potrebni pre uvođenja? Koje dozvole agent može da dobije? Ko može da prihvati preostali rizik? Šta se dešava kada model promeni ponašanje nakon nadogradnje?

Cilj nije da se spreči promena. Dobro upravljanje čini promenu čitljivom: odluke imaju vlasnike, dokaze, uslove, izuzetke, datume revizije i puteve vraćanja ili eskalacije.

Zato NIST postavlja GOVERN kroz ceo životni ciklus upravljanja rizikom AI, umesto da upravljanje tretira kao jedan završni korak odobravanja. Upravljanje uspostavlja kulturu, politike, odgovornost i organizacione strukture koje omogućavaju mapiranje, merenje i upravljanje rizikom AI.

Najjednostavniji primer

Produktni tim želi da doda eksternog provajdera generativne AI za sumiranje internih tiketa korisničke podrške. Tehnički, integracija može da zahteva samo API poziv.

Upravljanje postavlja drugi skup pitanja: Da li je sadržaj tiketa dozvoljeno izneti iz okruženja organizacije? Koji provajder i verzija modela su odobreni? Da li je zadržavanje onemogućeno? Koji korisnici mogu da pozovu tu funkciju? Kako se evaluira izlaz? Da li je potrebna ljudska provera? Šta se beleži? Ko je vlasnik incidenata? Šta se dešava ako provajder promeni uslove ili ponašanje modela?

Rezultat upravljanja i dalje može biti „uvesti to“. Razlika je u tome što je uvođenje sada odluka koja se može pratiti, sa izričitim uslovima, umesto nezabeleženog inženjerskog izbora.

Gde se jednostavan primer zaustavlja

Velike organizacije retko upravljaju jednim AI sistemom izolovano. Isti model može da podrži desetine proizvoda; jedan provajder može da obrađuje nekoliko klasa podataka; agentska platforma može da izloži deljene alate mnogim timovima.

Zato su upravljanju potrebne strukture na nivou portfolija, kao i kontrole na nivou sistema: inventar AI, odobreni provajderi, katalozi modela, zajedničke osnove evaluacije, bezbednosni obrasci, pragovi rizika, registri izuzetaka i mapiranja vlasništva.

Upravljanje takođe ne može biti identično za svaku upotrebu AI. Sumarizator javnog sadržaja, interni asistent za kodiranje, sistem za podršku zapošljavanju i agent koji može da inicira plaćanja imaju bitno različite profile posledica i kontrola.

Šta upravljanje veštačkom inteligencijom jeste — a šta nije

Upravljanje je šire od usklađenosti

Usklađenost je jedan od inputa za upravljanje, a ne ceo sistem upravljanja. Slučaj upotrebe veštačke inteligencije može biti pravno dozvoljen, a da i dalje krši apetit za rizik kompanije, bezbednosnu politiku, ugovorne obaveze ili zahteve kvaliteta proizvoda.

I obrnuto je važno: interno odobrenje ne nadjačava zakon. Upravljanje treba da učini primenljive pravne obaveze vidljivim unutar istog puta odlučivanja koji se koristi za arhitekturu, bezbednost i poslovni rizik.

ISO/IEC 42001 eksplicitno definiše sistem upravljanja veštačkom inteligencijom kao strukturisan način za uspostavljanje politika, ciljeva i procesa za odgovornu veštačku inteligenciju. ISO takođe navodi da standard ne zamenjuje zakone ili propise; on pruža okvir upravljanja koji može da podrži usklađenost.

NIST AI RMF i ISO/IEC 42001 rešavaju različite potrebe upravljanja

Ovi izvori ne treba da se spoje u jednu kontrolnu listu. NIST AI RMF su smernice za upravljanje rizikom. ISO/IEC 42001 je standard za sistem upravljanja. EU AI Act je zakon. Organizacija može da ih koristi zajedno, ali njihov autoritet, obim i svrha implementacije su različiti.

Trenutni vremenski okvir EU AI Act je važan

Od 8. oktobra 2026, Evropska komisija navodi da je AI Act postao opšte primenljiv 2. avgusta 2026. Odredbe o zabranjenim praksama i AI pismenosti primenjivale su se od 2. februara 2025, dok su se pravila upravljanja i obaveze za modele veštačke inteligencije opšte namene primenjivale od 2. avgusta 2025.

Trenutne smernice Komisije takođe odražavaju kasnije datume primene za određene zahteve visokog rizika. Tačni datumi i pravila tranzicije su promenljiv input za usklađenost i treba ih proveriti u odnosu na aktuelne materijale Komisije pre odluke o uvođenju.

Upravljanje veštačkom inteligencijom počinje popisom

Organizacija ne može da upravlja sistemima veštačke inteligencije koje ne može da identifikuje. Popis treba da obuhvati više od prilagođeno obučenih modela. Može da uključi eksterne API-je modela, ugrađene kopilote, lokalne modele, AI funkcije u SaaS-u, runtime agenata, sisteme za pretragu i komponente automatizovanog odlučivanja.

Koristan popis povezuje AI sposobnost sa njenim poslovnim vlasnikom, tehničkim vlasnikom, slučajem upotrebe, korisnicima, klasama podataka, modelom/pružaocem, okruženjem za uvođenje, dozvolama, klasifikacijom rizika, statusom evaluacije, primenljivim obavezama i stanjem životnog ciklusa.

Popis nije samo tabela za revizore. To je indeks koji omogućava organizaciji da zna šta mora da se pregleda kada se pružalac promeni, pojavi ranjivost, regulativa postane primenljiva ili model bude povučen.

Upravljanje zahteva imenovano vlasništvo

Neuspesi AI cesto prelaze organizacione granice. Problem kvaliteta modela moze postati neuspeh proizvoda, bezbednosni problem, incident privatnosti ili ugovorni prekrsaj. Upravljanje zahteva imenovane vlasnike pre nego sto se incident dogodi.

Vlasnistvo ne znaci da je jedna osoba odgovorna za sve. Snazan model razdvaja prava odlucivanja: poslovni vlasnik, vlasnik proizvoda, tehnicki vlasnik, vlasnik podataka, strucnjaci za bezbednost/privatnost, pravni/uskladenost akteri i operativna podrska.

Kriticno svojstvo je da svaka potrebna odluka ima vlasnika i da svaki vlasnik zna koje dokaze treba da pregleda.

Prava odlucivanja treba da budu eksplicitna

Upravljanje modelom je vise od izbora modela

Upravljanje modelom prati koji se model koristi, u koju svrhu, pod kojom konfiguracijom i dokazima. Ovo se primenjuje na eksterne API-je, lokalno hostovane modele, fino podesene modele i modele ugradjene u softver trecih strana.

Odluka o modelu treba da uzme u obzir sposobnost, rezultate evaluacije, trosak, latenciju, rukovanje podacima, uslove provajdera, podrsku zivotnog ciklusa, geografska/ hosting ogranicenja, bezbednost, ponasanje pri fallback-u i posledice promene verzije.

Aliasi modela kao sto je „latest“ mogu biti operativno zgodni ali slabe reproduktivnost ako se ponasanje menja bez upravljanog procesa izdanja. Sistemi sa posledicama imaju koristi od eksplicitnog pracenja verzija i evaluacije regresije.

Upravljanje provajderom je odvojen sloj zavisnosti

Dva sistema koja koriste istu familiju modela mogu imati razlicit rizik upravljanja ako jedan radi lokalno a drugi salje podatke eksternom provajderu. Upravljanje provajderom pokriva ugovorne uslove, lokaciju obrade, zadrzavanje, logovanje, podprocesore, dostupnost, ukidanje i strategiju izlaska.

Apstrakcija provajdera moze smanjiti tehnicko zakljucavanje, ali ne uklanja posao upravljanja. Zamena provajdera moze promeniti tokove podataka, ponasanje modela, bezbednosne pretpostavke, trosak i obaveze uskladenosti.

Lista odobrenih provajdera se stoga ne sme tumaciti kao „svaki model i svaka klasa podataka od ovog provajdera je automatski odobrena.“ Odobrenje zahteva obim.

Upravljanje podacima ostaje sloj izvora istine

AI upravljanje ne cini model autoritetom za organizacione cinjenice. Upravljanje podacima i dalje odredjuje vlasnistvo, klasifikaciju, zadrzavanje, kvalitet i dozvoljenu upotrebu izvornih podataka.

Za RAG i agente, upravljanje treba da identifikuje koji izvori su autoritativni, koji su savetodavni, kako se cuva provenijencija, koji podaci mogu uci u kontekst modela i koje granice zakupca/korisnika moraju biti primenjene.

Generisani izlazi takodje stvaraju nova pitanja upravljanja podacima: da li se promptovi i odgovori zadrzavaju, ko moze pristupiti tragovima, da li generisani rezimei postaju zapisi i kako se izvedeni embedding-ovi ili indeksi brisu kada se izvorni podaci uklone.

Dozvole su upravljačke odluke sa primenom u vreme izvršavanja

Agentna AI čini dozvole upravljačkim objektom prvog reda. Organizacija treba da odluči kojim alatima, datotekama, API-jima, bazama podataka i sporednim efektima svaki agent ili korisnik može da pristupi.

Upravljanje definiše politiku i logiku odobravanja; pouzdano izvršno okruženje ih sprovodi. Uputstva na prirodnom jeziku kao što je „ne briši datoteke“ nisu zamena za autorizaciju na nivou datotečnog sistema, API-ja ili servisa.

Isti princip važi i za izolaciju zakupaca: uloga može da autorizuje operaciju, dok opseg zakupca ograničava čijim resursima kupaca ta operacija može da pristupi.

Klasifikacija rizika treba da menja skup kontrola

Nije svakom AI sistemu potrebna ista dubina pregleda. Upravljanje postaje skalabilno kada klasifikacija rizika menja zahteve za dokazima, odobravanjem i nadzorom.

Metod klasifikacije može biti jednostavan ili sofisticiran, ali treba da se preslika u konkretne posledice: više testiranja, uža ovlašćenja, obavezan ljudski nadzor, bezbednosni pregled, prihvatanje rizika od strane rukovodstva ili zabranu uvođenja.

Upravljanje mora da očuva kontekst slučaja upotrebe

NIST-ova funkcija MAP naglašava predviđenu svrhu, korisnike, kontekst uvođenja, pretpostavke, uticaje i primenljive zakone ili norme. To je važno jer isti model može biti niskog rizika u jednom slučaju upotrebe, a sa visokim posledicama u drugom.

Zapisi o upravljanju bi stoga trebalo da klasifikuju aplikaciju, a ne samo model. „Koristimo model X“ nije dovoljno da se odredi rizik.

Relevantni upravljački objekat je sistem/slučaj upotrebe: model + podaci + kontekst + alati + korisnici + okruženje za uvođenje + poslovni proces.

Evaluacija je dokaz za upravljanje

Proces upravljanja AI-jem ne bi trebalo da odobri uvođenje samo na osnovu prodavčevih referentnih vrednosti ili uspešne demonstracije. Sistemu su potrebni dokazi povezani sa njegovom stvarnom predviđenom upotrebom.

Korisni dokazi mogu uključivati evaluaciju uspešnosti zadatka, kvalitet pronalaženja, činjeničnu utemeljenost, bezbednosne testove, testove dozvola, adversarne scenarije, studije ljudskog pregleda, latenciju/troškove, robusnost i poređenja regresija.

NIST-ova funkcija MEASURE to eksplicitno naglašava: organizacije treba da identifikuju i primene odgovarajuće metode i metrike za rizike identifikovane tokom mapiranja, uz dokumentovanje rizika koji ne mogu ili neće biti mereni.

Kapije upravljanja treba da postoje tokom celog životnog ciklusa

Upravljanje promenama je centralno za AI upravljanje

AI sistemi se menjaju čak i kada se kod aplikacije ne menja. Provajderi ažuriraju modele, sigurnosne filtere, ograničenja konteksta, cene, politike i infrastrukturu. Korpusi za pretragu se menjaju. Alati agenata dobijaju dozvole. Propisi i ugovori se razvijaju.

Upravljanje bi stoga trebalo da definiše okidače materijalnih promena. Manje prilagođavanje formulacije upita može zahtevati obične regresione testove; zamena modela, omogućavanje alata za pisanje ili uvođenje osetljivih podataka može zahtevati novu kapiju odobrenja.

Zapis o upravljanju treba da sačuva koja je verzija odobrena i koji uslovi su učinili odobrenje važećim.

Izuzeci zahtevaju vlasnike, rok trajanja i kompenzujuće kontrole

Stvarne organizacije zahtevaju izuzetke. Timu može biti potreban neodobreni model za vremenski ograničen eksperiment, ili nasleđeni sistem možda još ne ispunjava novi zahtev za evidentiranje.

Opasan obrazac je trajni nedokumentovani izuzetak. Izuzeci kojima se može upravljati preciziraju vlasnika, obrazloženje, obim, preostali rizik, kompenzujuću kontrolu, datum isteka i uslov pregleda.

Rukovanje izuzecima treba da bude deo normalnog sistema upravljanja, a ne neformalni sporedni kanal.

Revizibilnost je sposobnost rekonstrukcije odluke i izvršenja

AI revizibilnost nije samo čuvanje upita modela. To znači biti u mogućnosti da se rekonstruiše koja je verzija sistema korišćena, koji podaci i dozvole su primenjeni, ko je odobrio konfiguraciju, koje evaluacije su podržale implementaciju i šta se dogodilo tokom relevantnog izvršenja.

Za agenta, to može zahtevati identitet principala, pozive alata, odobrenja, ciljne resurse, promene stanja i ishode. Za RAG, to može zahtevati verziju korpusa/indeksa, upit za pretragu, izabrane dokaze i poreklo. Za promenu modela, to može zahtevati prethodne i nove rezultate evaluacije.

Revizijski dokazi treba da budu proporcionalni. Evidentiranje svakog mogućeg tokena može stvoriti sopstveni rizik za privatnost i bezbednost. Upravljanje treba da definiše koji dokazi su neophodni, koliko dugo se čuvaju i ko može da im pristupi.

Nadzor zatvara petlju upravljanja

Odobrenje je snimak stanja. Nadzor u produkciji govori upravljanju da li pretpostavke iza odobrenja još uvek važe.

Korisni signali zavise od slučaja upotrebe: regresija kvaliteta, nesigurni izlazi, kvarovi alata, odbijanja politike, neuobičajeni troškovi, latencija, pritužbe korisnika, drift, svežina pretrage, incidenti provajdera, bezbednosna upozorenja ili nove regulatorne klasifikacije.

Upravljanje treba da definiše pragove koji izazivaju akciju: istražiti, ograničiti, zahtevati ljudski pregled, vratiti unazad, promeniti provajdera, suspendovati ili ukinuti.

AI incidenti zahtevaju definisan operativni put

AI-specifični incidenti mogu uključivati štetni sadržaj, curenje podataka, neovlašćene radnje, trajni činjenični neuspeh, prekid rada modela/pružaoca usluga, prompt injection, cross-tenant pretragu ili neočekivano ponašanje nakon ažuriranja modela.

Proces za incidente treba da poveže tehnički odgovor sa upravljačkim vlasništvom. Neko mora biti ovlašćen da onemogući model, ukloni alat, opozove akreditive, ograniči korisnike, obavesti pogođene funkcije i odluči da li sistem može da se vrati u upotrebu.

Naučene lekcije iz incidenata treba da ažuriraju politike, testove, klasifikaciju rizika i kontrole platforme koje se mogu ponovo koristiti, umesto da ostanu izolovane u jednom timu.

Nabavka je deo AI upravljanja

Organizacije mogu steći značajne AI sposobnosti kroz običnu SaaS nabavku. Upravljanje stoga treba da pokriva i kupljene AI funkcije i interne inženjerske sisteme.

Procena dobavljača može uključivati korišćenje podataka, zadržavanje, politiku obuke modela, podprocesore, bezbednost, obaveštavanje o incidentima, izvoz/brisanje, geografsku obradu, promenu verzije, kontinuitet usluge i ugovorni izlaz.

Pregled tehničke arhitekture i pregled nabavke treba da dele isti inventar sistema kako komercijalno odobrenje ne bi odstupilo od stvarnog toka podataka u upotrebi.

Ljudski nadzor treba da bude dizajniran, a ne samo deklarisan

„Čovek u petlji“ ima smisla samo ako čovek ima ovlašćenje, vreme, informacije i upotrebljiv mehanizam intervencije.

Recenzent koji vidi samo AI preporuku, ali ne i njene dokaze, neizvesnost ili stanje izvora, može jednostavno automatski odobriti izlaz. Upravljanje treba da precizira šta recenzent može da pregleda i koje su radnje dostupne: odobri, odbije, izmeni, eskalira ili zaustavi.

Ljudski nadzor takođe treba da se zasniva na riziku. Sistemi sa malim posledicama mogu koristiti uzorkovanje ili naknadni pregled, dok efekti sa velikim posledicama mogu zahtevati odobrenje pre izvršenja.

Upravljanje platformom i upravljanje slučajevima upotrebe su različiti

Odobrenje platforme stoga treba da smanji ponavljanje posla, a ne da eliminiše odgovornost za slučaj upotrebe. „Model je odobren“ je različito od „ova primena modela je odobrena.“

AI upravljanje i Enterprise AI arhitektura

Enterprise AI arhitektura opisuje kako se AI sistemi, platforme, podaci, identiteti, pružaoci usluga, operacije i organizacioni sistemi uklapaju zajedno. AI upravljanje opisuje sistem odlučivanja i kontrole koji određuje kako se te arhitekture mogu kreirati i menjati.

Njih dvoje su tesno povezani. Upravljanje bez arhitekture može postati apstraktna politika. Arhitektura bez upravljanja može proizvesti tehnički elegantne sisteme sa nejasnim vlasništvom, nekontrolisanim usvajanjem pružalaca usluga ili nepregledanim rizikom.

Najjači dizajn je dvosmeran: zahtevi upravljanja postaju arhitektonske kontrole, dok arhitektura otkriva stvarne odluke koje upravljanje mora da preuzme.

Dokazi iz originalnog projekta

Enterprise Aaasaasa 0.1: upravljanje kao struktura isporuke

Enterprise Aaasaasa 0.1 koristi definisane prekretnice za zahteve, arhitekturu, prototip, validaciju i zatvaranje projekta. Ta struktura ilustruje osnovni princip upravljanja: tranzicije životnog ciklusa treba da imaju eksplicitne izlaze i tačke odlučivanja umesto neformalnog procesa „prvo izgradi, pa pregledaj kasnije“.

Projekat takođe prati rizike kao što su širenje obima, kašnjenje arhitekture i zabrinutosti vezane za AI/GDPR i identifikuje grupe zainteresovanih strana uključujući sponzorstvo, upravni odbor, arhitekturu, bezbednost, marketing, eksterne API-je i hosting.

Ovo ne predstavlja ISO/IEC 42001 sistem upravljanja. To su uži projektni dokazi koji pokazuju kako se vlasništvo, rizik, prekretnice i validacija mogu integrisati u tehničku isporuku.

SenseFlow: sledljivost zahteva i odluka

SenseFlow koristi strukturisan put od cilja proizvoda i korisničke potrebe kroz epove, korisničke priče, kriterijume prihvatanja, arhitekturu, implementaciju i validaciju. Zapisi o odlukama čuvaju odluku, obrazloženje, alternative, kompromise, status i datum/verziju.

Taj obrazac sledljivosti je direktno relevantan za upravljanje jer AI kontrola treba da se poveže sa zahtevom ili rizikom koji ju je opravdao. Sistem upravljanja postaje jači kada se lanac od poslovne potrebe do arhitektonske odluke do dokaza validacije može rekonstruisati.

Aaasaasa AI Client: dozvole i vreme izvršavanja kao upravljana konfiguracija

Aaasaasa AI Client razdvaja provajdera, model, lokaciju izvršavanja i dozvole umesto da ih tretira kao jedno „AI podešavanje“. Centralni profili dozvola radnog prostora upravljaju pristupom alatima, Direct Chat nema alate za fajl sistem/šel, a okruženja sposobna za agente rade pod eksplicitnim profilima dozvola.

To razdvajanje pokazuje važan obrazac upravljanja: izbor modela i autoritet za delovanje treba da budu nezavisni konfiguracijski objekti. Jači model automatski ne dobija šire dozvole za fajl sistem, šel ili poslovanje.

Dokazi implementacije su arhitektonski, a ne tvrdnja da aplikacija predstavlja sertifikovani organizacioni sistem upravljanja AI-jem.

Uobičajeni načini neuspeha upravljanja AI-jem

Centralno upravljanje ne znači centralizaciju svake odluke

Zrela organizacija može centralizovati politiku, kontrolne obrasce i eskalaciju, dok istovremeno delegira odluke niskog rizika produktnim ili platformskim timovima.

Ovaj federativni model skalira se bolje od zahteva da centralni komitet odobrava svaku izmenu prompta. Centralna funkcija definiše nivoe rizika, obavezne kontrole, politiku provajdera, ovlašćenja za izuzetke i zahteve za reviziju; timovi deluju autonomno unutar tih granica.

Cilj dizajna je dosledna odgovornost, a ne maksimalna centralizacija.

Upravljajte samim sistemom upravljanja

Upravljanje zahteva povratne informacije. U suprotnom, kontrole mogu postati skupi rituali koji ne smanjuju rizik.

Metrike upravljanja ne bi trebalo da nagrađuju obim papirologije. Korisna mera je da li se kvalitet odlučivanja, sledljivost, detekcija rizika i bezbedna isporuka poboljšavaju.

Praktičan redosled implementacije AI upravljanja

Kontrolna lista za AI upravljanje

Uobičajene zablude

Granični slučajevi i ograničenja

Vrlo male organizacije možda ne zahtevaju namensku funkciju AI upravljanja. Isti principi mogu se primeniti kroz lagane arhitekturne odluke, registre rizika, mapiranja vlasnika i kapije izdanja.

Visoko regulisane organizacije mogu zahtevati mnogo formalnije upravljanje, nezavisno uveravanje, dokumentovane procese usklađenosti i pravno tumačenje nego što ovaj članak na arhitektonskom nivou opisuje.

Open-source i samostalno hostovani modeli smanjuju neke zavisnosti od provajdera, ali stvaraju druge: zakrpe, poreklo modela, evaluaciju, bezbednost infrastrukture, licenciranje i operativno vlasništvo.

AI modeli opšte namene mogu se koristiti u mnogim kontekstima. Upravljanje treba da izbegne pretpostavku da kontrole modela na nivou provajdera u potpunosti određuju rizik aplikacije nizvodno.

Nijedan okvir upravljanja ne garantuje da je AI sistem bezbedan ili ispravan. Upravljanje poboljšava odgovornost i kvalitet odluka; tehnička validacija, praćenje i ljudska procena ostaju neophodni.

Šta bi promenilo ovaj odgovor?

Tačan skup kontrola menja se u zavisnosti od zakona, industrije, veličine organizacije, osetljivosti podataka, autonomije, modela uvođenja i poslovnih posledica.

NIST trenutno revidira AI RMF 1.0, tako da se buduća NIST terminologija ili preporučene prakse mogu promeniti. ISO standardi takođe mogu biti revidirani, a smernice i detalji tranzicije EU AI Act-a nastavljaju da se razvijaju.

Stabilan arhitektonski princip je da AI odluke zahtevaju eksplicitne vlasnike, dokaze, dozvole, tretman rizika i pregled životnog ciklusa, umesto da budu skrivene unutar konfiguracije modela ili aplikacije.

Povezano kanonsko znanje

AI upravljanje zavisi od koncepata koji su već razdvojeni na drugim mestima u ovom grafu znanja: Izvor istine određuje autoritet, RBAC i izolacija zakupaca ograničavaju pristup, inženjering konteksta kontroliše informacije vidljive modelu, a agentna arhitektura definiše kako alati i akcije ulaze u izvršnu petlju.

Enterprise AI Architecture je nadređeni koncept organizacione arhitekture. Upravljanje je operativni kontrolni sloj koji određuje kako se ti enterprise AI komponenti mogu uvesti, menjati i ukinuti.

Agentni sistemi povećavaju zahteve upravljanja jer odluke modela mogu postati stvarne posledice. Kontrole dozvola, odobrenja i revizije stoga moraju postojati izvan samog modela.

Često postavljana pitanja

Pojmovnik

Zaključak

AI upravljanje je organizaciona kontrolna ravan oko AI. Ono daje imena i dokaze odlukama koje bi inače ostale skrivene unutar koda, podešavanja provajdera, upita ili neformalne procene tima.

Snažno upravljanje povezuje kompletan sistem: poslovnu svrhu, modele, pružaoce usluga, autoritet nad podacima, identitet, dozvole, evaluaciju, rizik, usklađenost, nadzor, incidente, promene i ukidanje.

Praktični cilj nije maksimalan proces. To je minimalna struktura upravljanja koja omogućava da važne AI odluke budu vlasnički definisane, zasnovane na dokazima, sprovodive, pregledne i revizorske tokom celog životnog ciklusa.

Primarni izvori i aktuelne reference

Izvori navedeni u nastavku pružaju aktuelno eksterno utemeljenje za upravljanje AI, rizik i regulativu. Sekcije projekta predstavljaju originalne dokaze o implementaciji/projektu i eksplicitno se razlikuju od formalnih standarda ili sertifikovanih sistema upravljanja.