Agile i EU AI Act: izazovi razvoja AI sistema u regulisanom okruženju

Key Takeaways – šta je najbitnije u ovom tekstu

EU AI Act više nije propis o kome kompanije mogu da govore u budućem vremenu. Veći deo uredbe počeo je da se primenjuje 2. avgusta 2026., dok se različite kategorije obaveza uvode fazno. Pravila o zabranjenim praksama i AI literacy (AI pismenosti) primenjuju se od 2025, obaveze za General-Purpose AI – GPAI (AI opšte namene) takođe su već aktivne, a pravila za određene high-risk AI systems (visokorizične AI sisteme) počinju da se primenjuju od 2. decembra 2027, odnosno od 2. avgusta 2028. za određene AI sisteme integrisane u regulisane proizvode.

To menja način na koji razvijamo AI proizvode. Klasična formula „napravimo MVP, pustimo korisnicima, pa ćemo kasnije srediti dokumentaciju“ može postati veoma skupa greška.

Ali postoji i druga strana priče. EU AI Act ne znači kraj Agile-a. Naprotiv: kvalitetno primenjen Agile može biti jedan od najboljih načina da se zahtevi regulative kontinuirano ugrađuju u proizvod. Problem nastaje kada Agile koristimo kao izgovor za nedostatak dokumentacije, nejasnu odgovornost, nekontrolisane promene modela, nepoznato poreklo podataka i kulturu u kojoj je jedina važna metrika koliko brzo je nova funkcija stigla u produkciju.

U ovom tekstu analiziraćemo šta se događa kada se Agile, DevOps, MLOps, AI governance i EU AI Act sudare u realnom projektu, koje će razvojne navike morati da se promene i zašto će regulatory compliance (usklađenost sa propisima) sve više postajati deo samog Software Development Life Cycle – SDLC-a (životnog ciklusa razvoja softvera), a ne posao pravnika nekoliko dana pre lansiranja proizvoda.

Najpre jedna neprijatna istina: „Agile“ nikada nije značio „bez dokumentacije“

U tehnološkoj industriji postoji dugogodišnja karikatura Agile-a: Kodiramo brzo. Dokumentovaćemo kasnije. Ako nešto nije jasno – popravićemo u sledećem sprintu. Ako specifikacija zastari – nema veze, kod je prava dokumentacija. Ako se pojavi problem – imamo retrospektivu.

To nije Agile. To je improvizacija.

Jedan od principa Agile Manifesto-a kaže da se više vrednuje working software over comprehensive documentation – funkcionalan softver više od obimne dokumentacije. Ali „više vrednujemo“ nikada nije značilo „drugu stvar ne radimo“.

Kod razvoja AI sistema ova razlika postaje presudna. Ako AI sistem učestvuje u odlučivanju o zapošljavanju, kreditiranju, obrazovanju, pristupu javnoj usluzi ili nekoj drugoj oblasti koja može imati ozbiljan uticaj na čoveka, nije dovoljno demonstrirati da model „uglavnom dobro radi“. Moraćete da znate mnogo više:

• Koji podaci su korišćeni?

• Koliko su reprezentativni?

• Koje greške model pravi?

• Postoje li diskriminatorni obrasci?

• Koja verzija modela je donela konkretnu odluku?

• Ko je odobrio deployment?

• Ko nadzire sistem?

• Šta se događa kada rezultat izgleda sumnjivo?

• Kako se incident prijavljuje?

• Kako se sistem zaustavlja?

EU AI Act upravo oko takvih pitanja gradi režim za high-risk AI sisteme: risk management (upravljanje rizikom), kvalitet podataka, logging (beleženje događaja), tehnička dokumentacija, informacije za korisnika sistema, human oversight (ljudski nadzor), accuracy (tačnost), robustness (robustnost) i cybersecurity (sajber bezbednost).

Odjednom rečenica „nemamo dokumentaciju jer smo agilni“ više ne zvuči moderno. Zvuči neodgovorno.

EU AI Act nije jedan rok

Ovo je naročito važno jer je internet prepun zastarelih članaka sa starom vremenskom linijom. EU AI Act stupio je na snagu 1. avgusta 2024, ali se primenjuje fazno:

• Od 2. februara 2025. primenjuju se, između ostalog, odredbe o AI literacy i većini zabranjenih AI praksi.

• Od 2. avgusta 2025. počele su da se primenjuju obaveze vezane za governance i pružaoce General-Purpose AI modela.

• Od 2. avgusta 2026. počela je šira primena Uredbe, uključujući važna transparency (transparentnost) pravila i aktiviranje većeg dela enforcement (sprovođenje propisa) sistema.

• Nakon izmena usvojenih kroz takozvani AI Omnibus, pravila za određene visokorizične sisteme iz Annex III – oblasti poput biometrije, obrazovanja, zapošljavanja, kritične infrastrukture, migracija i sličnih osetljivih primena – primenjuju se od 2. decembra 2027.

• Za određene high-risk AI sisteme povezane sa regulisanim proizvodima rok je 2. avgust 2028.

To je dobra vest za kompanije koje još nisu spremne. Ali bila bi ozbiljna greška protumačiti dodatno vreme kao dozvolu da se posao odloži do 2027. Jer ono što će biti potrebno tada uglavnom mora da bude projektovano mnogo ranije.

Najskuplja rečenica u AI projektu: „Dodaćemo compliance kasnije“

Zamislimo SaaS kompaniju koja razvija sistem za automatsko rangiranje kandidata za posao. Tim radi Agile. Sprint traje dve nedelje. Prva verzija koristi nekoliko atributa kandidata. Rezultati izgledaju dobro. Product Owner traži novu funkciju. Developer povezuje još jedan model. Data Scientist menja trening skup. Nakon dva sprinta menja se prompt. Mesec dana kasnije koristi se novi foundation model. Tri meseca kasnije uvodi se automatsko odbacivanje određenog procenta kandidata.

Proizvod radi sve bolje. Komercijalno – odlična priča. Regulatorno? Možda katastrofa.

Posle godinu dana neko postavi nekoliko jednostavnih pitanja: Na osnovu koje verzije modela je kandidat odbijen? Koji dataset je tada korišćen? Da li je urađena bias analiza? Zašto je promenjen threshold? Ko je odobrio promenu? Koji je bio poznati false-negative rate? Možete li rekonstruisati odluku?

Ako tim odgovori: „Pa… verovatno možemo nešto da pronađemo u Git-u“, problem nije regulativa. Problem je arhitektura procesa.

Compliance mora da uđe u backlog

Najvažnija promena koju EU AI Act donosi Agile timovima zapravo je konceptualno jednostavna. Compliance više nije projekat posle projekta. Postaje deo Product Backlog-a.

Ako razvojna priča glasi: Sistem treba da rangira prijavljene kandidate prema relevantnosti za poziciju, onda acceptance criteria (kriterijumi prihvatanja) više ne mogu biti samo:

• rangiranje radi;

• API vraća odgovor;

• performanse su zadovoljavajuće;

• UI prikazuje rezultat.

Kod regulisanog AI sistema kriterijumi će možda uključivati i:

• verzija modela mora biti evidentirana;

• izvor podataka mora biti poznat;

• relevantne metrike kvaliteta moraju biti sačuvane;

• rezultat mora biti logovan;

• ljudski operater mora moći da interveniše;

• poznata ograničenja modela moraju biti dokumentovana;

• promena mora proći odgovarajući risk review.

Drugim rečima: regulatorni zahtev postaje tehnički zahtev. To je možda najvažnija promena koju menadžment treba da razume.

Definition of Done više ne može da znači samo „radi u produkciji“

Agile timovi koriste Definition of Done – DoD (definiciju završenog) kako bi znali kada je posao stvarno završen. Kod obične web funkcije to može značiti: kodiran, testiran, review-ovan, deployovan.

Kod regulisanog AI proizvoda lista postaje duža:

• Da li je promena dokumentovana?

• Da li je izvršena procena rizika?

• Da li postoji test na poznate failure modes (načine otkaza)?

• Da li su metrike modela zabeležene?

• Da li je promena uticala na podatke?

• Da li je human oversight i dalje funkcionalan?

• Da li je model dovoljno robustan?

• Da li su izvršeni security testovi?

• Da li su logovi dovoljni za kasniju rekonstrukciju događaja?

EU AI Act eksplicitno zahteva od pružalaca high-risk sistema lifecycle pristup – odgovornost se ne završava trenutkom kada je proizvod stavljen na tržište. Potrebni su monitoring, korektivne mere i reagovanje na ozbiljne incidente tokom korišćenja sistema. To savršeno odgovara jednoj od osnovnih ideja Agile-a: proizvod nikada nije stvarno „završen“.

Paradoks: regulativa možda više odgovara Agile-u nego Waterfall-u

Na prvi pogled moglo bi se pomisliti da je regulatorno okruženje idealno za Waterfall: Napišemo specifikaciju. Napravimo dokumentaciju. Odobrimo je. Izgradimo sistem. Testiramo. Sertifikujemo. Završeno.

Problem je što AI sistemi nisu statični. Podaci se menjaju. Distribucija korisnika se menja. Modeli se menjaju. Prompts se menjaju. Foundation model koji koristite preko API-ja može biti ažuriran. Pojavljuje se model drift (odstupanje ponašanja modela). Menjaju se poslovni procesi. Pojavljuju se novi napadi. Otkrivaju se novi bias problemi.

U takvom okruženju dokumentacija izrađena jednom godišnje veoma brzo postaje istorijski dokument. Zato je bolje pitanje: Kako napraviti Agile koji kontinuirano proizvodi dokaz o usklađenosti? Tu dolazimo do koncepta Continuous Compliance (kontinuirana usklađenost).

Continuous Compliance: verovatno jedan od ključnih obrazaca AI razvoja narednih godina

Ideja je jednostavna. Kao što Continuous Integration – CI automatski proverava kod, a Continuous Delivery – CD automatizuje isporuku, deo regulatory compliance-a može postati automatski deo pipeline-a.

Na primer:

• svaka verzija modela dobija jedinstveni identifikator;

• dataset ima versioning;

• promena modela automatski pokreće određene evaluacije;

• rezultati testova čuvaju se kao artifact;

• beleže se security rezultati;

• kreira se audit trail;

• sistem proverava da li je model card ažuriran;

• deployment je blokiran ako kritični testovi nisu prošli.

Time regulatorna dokumentacija prestaje da bude Word dokument koji neko naknadno piše. Postaje nusproizvod razvoja. To je ogromna razlika.

Od DevOps-a ka MLOps-u, a od MLOps-a ka RegOps-u?

Već smo govorili o tome da AI više nije dodatak programeru već može da bude ugrađen kroz gotovo čitav SDLC – od analize zahteva do testiranja, Code Review-a, deploymenta i observability-ja. To ubrzava razvoj.

Ali brzina ima cenu. Što više procesa automatizujemo, potrebno je više kontrole nad tim ko je šta uradio, kojim alatom, sa kojim modelom i sa kojim rezultatom. Zato će se pored DevOps-a i MLOps-a verovatno sve češće pojavljivati nešto što možemo nazvati RegOps – Regulatory Operations, odnosno tehnička operacionalizacija regulatornih zahteva. Ne kao još jedan birokratski sloj, već kao code-level compliance. Policy as Code. Automatska validacija. Audit trail. Machine-readable governance. U ozbiljno regulisanom AI sistemima to će verovatno postati jednako normalno kao CI/CD danas.

AI Act menja i Product Owner-a

Product Owner više neće moći da posmatra funkciju samo kroz poslovnu vrednost. Recimo da kompanija želi novu funkciju: „AI treba automatski da proceni produktivnost zaposlenog.“ Poslovna strana vidi uštedu vremena, bolju analitiku i automatizaciju HR-a. Ali Agile tim pre nego što dodeli story points mora da postavi drugo pitanje: Šta ova funkcija znači regulatorno?

AI Act koristi risk-based approach (pristup zasnovan na riziku). Nisu svi AI sistemi jednako regulisani. Velika većina običnih AI aplikacija spada u minimal ili no-risk kategoriju i ne podleže dodatnim zahtevima visokorizičnog režima. Ali kontekst upotrebe može potpuno promeniti situaciju. AI filter za spam je jedna stvar. AI koji utiče na zapošljavanje potpuno druga.

Zato backlog grooming budućnosti neće uključivati samo developera, dizajnera i Product Owner-a. Kod ozbiljnih projekata povremeno će za stolom morati da budu security, data governance, privacy, risk, compliance i pravnik ili regulatorni stručnjak. Ne na svakom Daily Scrum-u. Ali mnogo ranije nego danas.

„Shift left“ više nije samo bezbednosni izraz

U cybersecurity svetu dugo postoji ideja shift left – bezbednost treba pomeriti što ranije u razvojni proces. EU AI Act praktično tera AI industriju da isto uradi sa governance-om. Ne čekajte završetak proizvoda da biste pitali:

• Da li imamo pravo da koristimo ove podatke?

• Da li je dataset reprezentativan?

• Kako ćemo obezbediti ljudski nadzor?

• Kako ćemo objasniti ograničenja?

• Kako ćemo voditi evidenciju?

• Kako će sistem biti zaustavljen?

• Kako ćemo otkriti incident?

Ta pitanja treba postaviti tokom Product Discovery faze. Ponekad čak pre prve linije koda.

Data governance postaje razvojni problem

Mnogi AI timovi vole da pričaju o modelima: GPT, Gemini, Claude, Llama, Mistral, Fine-tuning, RAG, Agents. Ali u regulatornom okruženju često će mnogo nezgodnije pitanje biti: Odakle vam podaci?

Za visokorizične sisteme EU zahteva odgovarajuće data governance prakse i visok kvalitet datasetova kako bi se smanjio rizik diskriminatornih ishoda. To znači da organizacija mora znati:

• poreklo podataka;

• način prikupljanja;

• relevantnost i kvalitet;

• poznate nedostatke i reprezentativnost;

• način čišćenja i transformacije.

U Agile terminologiji, dataset više nije samo input. Postaje versioned dependency – verzionisana zavisnost proizvoda. Promena dataseta može biti jednako značajna kao promena koda. Ponekad i značajnija.

Model versioning mora postati ozbiljan kao Git

Kod klasičnog softvera lako možemo reći: problem je nastao u verziji 4.8.2. Kod AI sistema odgovor može biti mnogo komplikovaniji. Aplikacija je ista, ali model je promenjen. Prompt je promenjen. RAG baza je dopunjena. Embedding model je zamenjen. System prompt je ažuriran. Temperature je promenjena. Safety layer je drugačiji. External tool je dobio novi API.

Odjednom imamo drugačije ponašanje bez promene tradicionalnog „programa“. Zato ozbiljan AI governance zahteva mnogo širi change management. Potrebno je pratiti ne samo code version, nego i:

• model version;

• prompt version;

• dataset version;

• knowledge-base version;

• configuration version;

• evaluation results.

Ako to ne radimo, pitanje „koja verzija sistema je ovo uradila?“ može postati iznenađujuće teško.

Human oversight nije dugme „Approve“

EU AI Act veliku pažnju poklanja human oversight-u (ljudskom nadzoru). Ali postoji opasnost da kompanije ovo pretvore u regulatorni teatar. AI donese odluku, a čovek dobije dugme: APPROVE.

Ako zaposleni dnevno dobija 1.500 AI preporuka, realno on nije nadzornik – on je deo automatizacije. Ako ne razume kako sistem funkcioniše, nema dovoljno informacija da proceni rezultat ili je pod pritiskom da odobri 99,8 odsto preporuka, formalno postoji čovek u petlji, ali praktično ga nema.

Komisija zahteva da osobe kojima je poveren ljudski nadzor budu adekvatno osposobljene i da zaista mogu da intervenišu u rad high-risk sistema. To znači da UX AI sistema postaje regulatorno pitanje:

• Koliko informacija prikazujemo operateru?

• Da li vidi uncertainty (nesigurnost modela)?

• Može li da odbije preporuku ili zaustavi automatizaciju?

• Razume li posledice?

To više nije samo dizajn interfejsa. To je safety architecture.

Transparentnost više nije opciona „lepa praksa“

Od 2. avgusta 2026. primenjuju se važni zahtevi iz člana 50 EU AI Act-a. Korisnik u određenim situacijama mora biti obavešten da razgovara sa AI sistemom. Generativni sistemi imaju obaveze vezane za mašinski čitljivo označavanje sintetičkog sadržaja, a posebna pravila postoje i za deepfake sadržaje i određeni AI-generisani tekst od javnog interesa.

Za razvojni tim to znači vrlo praktične stvari. Transparentnost nije tekst koji pravnik ubaci u Terms & Conditions. Može zahtevati promenu: UI-a, API-ja, metadata strukture, content pipeline-a, CMS-a, video pipeline-a ili watermarking sistema. Drugim rečima – opet dolazi u backlog.

Šta ako koristimo tuđi AI model?

To će biti najčešći scenario. Većina evropskih kompanija neće trenirati sopstveni foundation model. Koristiće API – OpenAI, Google, Anthropic, Microsoft, Mistral, Meta modele, ili neku kombinaciju.

Da li time regulatory problem nestaje? Ne. Samo se menja raspodela odgovornosti. GPAI provider ima svoje obaveze, a kompanija koja taj model ugradi u proizvod i dalje može imati sopstvene obaveze. Najjednostavnije rečeno: „Koristimo API velike kompanije“ nije compliance strategija.

A šta ako OpenAI sutra promeni model?

Napravili ste aplikaciju. Testirali ste je sa modelom X, izmerili accuracy, proverili bias, uradili security testove i dokumentovali rezultate. Dobavljač zatim promeni model. Isti API endpoint, sličan naziv, ali ponašanje nije identično.

U običnom SaaS proizvodu možda ne morate ništa da uradite. U regulisanom AI sistemu možda morate ponoviti deo evaluacije. Tu vendor management postaje deo AI governance-a. Tim mora znati:

• koji dependency je promenjen;

• kada se to desilo;

• koliko je promena značajna;

• koji testovi moraju ponovo da se izvrše.

Ovo je razlog zbog kog će ozbiljni AI sistemi imati mnogo strože regression suites nego današnji chatbot prototipi.

Kazne jesu velike, ali kazna možda nije najveći problem

EU AI Act predviđa veoma ozbiljne finansijske sankcije. U zavisnosti od vrste povrede, maksimalni pragovi mogu dostići desetine miliona evra i procenat globalnog godišnjeg prometa kompanije. Ali za tehnološku kompaniju možda je još opasnija druga posledica:

• Proizvod koji mora hitno da se povuče.

• Enterprise klijent koji raskine ugovor.

• Tender koji izgubite.

• Investitor koji otkrije da ne možete dokumentovati trening podataka.

• Partner koji zahteva compliance dokaz koji nemate.

• Reputaciona šteta.

Drugim rečima: regulatorni dug može postati isto što i technical debt (tehnički dug). Samo mnogo skuplji.

Regulatory debt – novi oblik tehničkog duga

Technical debt nastaje kada danas izaberemo brže rešenje, svesni da ćemo kasnije morati da platimo cenu. Regulatory debt funkcioniše slično. Nemamo AI inventory? Sredićemo kasnije. Nemamo data lineage? Kasnije. Nemamo model cards? Kasnije. Nismo evidentirali prompt promene? Kasnije. Nemamo formalizovan human oversight? Kasnije.

Problem je što posle dve godine možda više ne možete rekonstruisati ono što je trebalo zabeležiti danas. Dokumentacija se može napisati retroaktivno. Istorija sistema ne može uvek da se rekonstruiše.

Agile governance nije oksimoron

Brzina bez governance-a više nije dovoljna. Ali ni governance koji blokira svaku promenu nije dobar odgovor. Pravi cilj bi mogao biti Agile Governance:

• minimalni, ali dovoljan nivo kontrole;

• automatizovani dokazi;

• jasna odgovornost;

• kontinuirano testiranje;

• risk-based procedure;

• kontrola proporcionalna posledicama.

Spam classifier ne treba isti proces kao AI koji procenjuje kreditnu sposobnost. Video igra ne treba isti governance kao medicinski uređaj. To je i osnovna logika EU AI Act-a: regulacija treba da prati rizik.

Srbija nije van ove priče

Srbija nije članica EU, ali zaključak „EU AI Act se zato ne odnosi na nas“ može biti veoma pogrešan. Evropska komisija jasno navodi da okvir može da obuhvati i javne i privatne aktere izvan EU kada AI sistem ili GPAI model stavljaju na tržište Unije, koriste ga u EU ili kada se output sistema koristi u EU. To je posebno relevantno za srpske software kompanije, outsourcing timove, SaaS startape, HR platforme, fintech kompanije, e-commerce sisteme i B2B proizvode koji imaju klijente u EU.

Počnite od najjednostavnije stvari – popisa AI alata koje zaista koristite. Pokušajte u firmi od 200 zaposlenih da odgovorite na pitanje: Koje sve AI servise trenutno koristimo? Odgovor će često biti neprijatan.

Shadow AI može postati Shadow Compliance problem

Zaposleni koristi ChatGPT. Drugi koristi Claude. Marketing testira Gemini. Programeri koriste Copilot. Dizajner koristi Midjourney. Prodaja je povezala neki AI transcription servis. HR je kupio mali AI alat za analizu CV-ja. Niko nije napravio centralni pregled. To je Shadow AI.

Sa poslovne strane može izgledati kao spontan rast produktivnosti, ali sa governance strane izgleda drugačije. Koji podaci odlaze tim servisima? Da li su među njima lični podaci, poslovne tajne, izvorni kod, podaci korisnika? Zbog toga će AI inventory verovatno postati standardni deo IT Asset Management-a.

AI literacy je mnogo važnija nego što zvuči

Jedna od prvih obaveza EU AI Act-a koja je počela da se primenjuje bila je AI literacy. Najbolja tehnička zaštita ne pomaže mnogo ako zaposleni veruje da je svaki odgovor velikog jezičkog modela činjenica. AI literacy ne znači da svi zaposleni moraju znati kako Transformer radi, već da razumeju:

• šta AI može, a šta ne može;

• šta je hallucination;

• koje podatke ne smeju unositi;

• kada rezultat mora proveriti čovek;

• kada AI ne sme imati poslednju reč.

U Agile organizaciji ovo znači da trening više nije jednokratni PowerPoint. Mora pratiti promenu alata, novi model, nova pravila, novi workflow i novi rizik.

Da li EU AI Act usporava inovacije?

Da. U nekim slučajevima – apsolutno. Biće više testiranja, više dokumentacije, više review procesa i više razgovora sa pravnicima. Neke funkcije će kasnije stići na tržište. Neke ideje će biti odbačene jer je odnos rizika i poslovne vrednosti loš.

Ali drugo pitanje je važnije: Da li je svako usporavanje loše? Ako AI bira koju osobu ćemo zaposliti, kome ćemo dati kredit, koji pacijent ima prioritet ili ko dobija pristup određenoj usluzi, možda „Move fast and break things“ nije idealna filozofija. Naročito kada je „thing“ koji smo slomili nečiji život.

Najbolji AI timovi neće biti oni koji najbrže kodiraju

Za nekoliko godina razlika između prosečnog i vrhunskog razvojnog tima možda više neće biti u tome ko može da proizvede više koda. Kod će postajati jeftiniji. Prava vrednost biće u tome ko zna šta treba napraviti, ko upravlja rizikom, ko ume da proveri rezultat, ko može da dokaže kako sistem radi, ko ima pouzdane podatke i ko može bezbedno da menja proizvod. To je mnogo zahtevniji problem.

Harmonizovani standardi mogu postati nova „dokumentacija za developere“

EU paralelno razvija harmonised standards (harmonizovane standarde) za oblasti kao što su risk management, dataset governance, logging i cybersecurity. Primena harmonizovanog standarda ostaje dobrovoljna, ali standard koji je odgovarajuće objavljen može kompaniji dati presumption of conformity – pretpostavku usklađenosti. Kao što danas kažemo „koristimo OAuth 2.0“, sutra ćemo možda mnogo češće govoriti: „ovaj deo AI lifecycle-a implementiran je prema tom-i-tom harmonizovanom standardu“.

Budućnost: compliance as code

Zamislimo AI development platformu 2030. godine. Developer otvori Pull Request. Automatski se izvršava unit testing, security scanning, model evaluation, bias evaluation, prompt regression, data-quality validation i AI Act policy check. Sistem automatski ustanovi: „Ova promena utiče na model koji se koristi u high-risk workflow-u.“ Zatim zahteva dodatni review. Rezultati evaluacije postaju deo Pull Request-a, model card se automatski ažurira, a risk register dobija novu stavku. Deployment se odobrava tek kada su ispunjeni svi uslovi.

To je Compliance as Code. I verovatno je mnogo bolja budućnost od armije ljudi koja ručno popunjava Excel tabele nakon svakog release-a. (A paradoksalno, ista ta AI tehnologija može postati agent koji analizira tehničku dokumentaciju i prati promene modela kao compliance proverivač).

Najbolji model možda neće pobediti

AI industrija trenutno je opsednuta benchmark rezultatima. Ali enterprise kupci će sve češće pitati: Možete li dokazati poreklo modela? Imate li dokumentaciju? Kako rešavate incidente? Možemo li dobiti audit log? Odjednom model koji je dva procenta slabiji na benchmark-u, ali je mnogo lakši za governance, može biti komercijalno bolji izbor.

Agilnost ne znači maksimalnu brzinu

Agile nije Formula 1. Cilj nije voziti najbrže moguće bez obzira na pravac. Agilnost znači sposobnost brzog prilagođavanja promeni. A regulativa je promena. Novi rizik je promena. Novi model je promena. Incident je promena. Promena dataseta je promena. Ako kompanija mora da zaustavi razvoj šest meseci kako bi retroaktivno dokumentovala dve godine AI sistema, ona nije agilna. Ako može da promeni model, automatski ponovi evaluacije, ažurira dokumentaciju i za nekoliko dana pouzdano potvrdi da je sistem i dalje bezbedan i usklađen – to jeste agilnost.

Praktičan Agile AI Act okvir

Za većinu organizacija dobar početak mogao bi da izgleda ovako:

• napraviti kompletan AI inventory;

• za svaki sistem odrediti provider/deployer ulogu;

• izvršiti početnu klasifikaciju rizika;

• mapirati relevantne regulatorne zahteve;

• pretvoriti zahteve u backlog stavke;

• proširiti Definition of Done;

• uvesti model, prompt i dataset versioning;

• automatizovati evaluacije gde je moguće;

• dokumentovati human oversight;

• uvesti continuous monitoring;

• napraviti incident procedure;

• periodično preispitivati klasifikaciju rizika.

Sledeća faza Agile-a nije manje discipline, već pametnija disciplina

Agile je pre više od dve decenije nastao kao odgovor na spore, krute i previše birokratizovane procese razvoja softvera. Danas postoji opasnost od obrnutog ekstrema. AI može da proizvede softver toliko brzo da governance, testiranje i ljudska sposobnost provere više ne mogu da prate tempo.

EU AI Act tu uvodi ograničenje. Ne uvek elegantno. Ne uvek jednostavno. Ali suštinsko pitanje koje postavlja je legitimno: Ako AI sistem može ozbiljno uticati na čoveka, možete li dokazati da znate šta ste napravili?

Možda zato prava poruka EU AI Act-a Agile zajednici nije „Usporite“, već: „Ako želite da se krećete brzo, morate konačno znati šta radite dok se krećete.“ I upravo će tu nastati nova generacija najboljih AI kompanija. Ne one koje uspeju da naprave najviše funkcija u jednom sprintu, već one koje mogu brzo da eksperimentišu, uče i menjaju sistem – a da pritom u svakom trenutku mogu da dokažu šta su promenile, zašto su to uradile i kakve posledice ta promena može imati.

FAQ

Da li EU AI Act znači da Agile razvoj AI sistema više nije moguć? Ne. EU AI Act ne propisuje Waterfall niti određenu razvojnu metodologiju. Agile može veoma dobro funkcionisati, ali regulatorni zahtevi moraju biti ugrađeni u backlog, Definition of Done, testiranje, dokumentaciju i release proces.

Da li se EU AI Act već primenjuje? Da. Veći deo Uredbe primenjuje se od 2. avgusta 2026, dok su pojedine obaveze počele ranije. Određena pravila za visokorizične sisteme počinju 2. decembra 2027, a određeni sistemi povezani sa regulisanim proizvodima od 2. avgusta 2028.

Da li svaki AI proizvod predstavlja high-risk sistem? Ne. Evropska komisija navodi da velika većina AI sistema spada u minimal ili no-risk kategoriju. Klasifikacija prvenstveno zavisi od namene i konteksta sistema.

Da li ChatGPT u firmi automatski znači da smo high-risk AI kompanija? Ne. Obična upotreba generativnog AI alata ne čini kompaniju automatski pružaocem high-risk sistema. Međutim, firma mora utvrditi svoju ulogu, način korišćenja alata, podatke koji se obrađuju i eventualne transparency ili druge relevantne obaveze.

Da li se EU AI Act može odnositi na kompaniju iz Srbije? Da. EU pravila mogu se odnositi i na subjekte van EU kada stavljaju AI sisteme ili GPAI modele na evropsko tržište, koriste ih u EU ili kada se rezultat određenog AI sistema koristi u Uniji.

Šta znači Continuous Compliance? Continuous Compliance je pristup u kome se provera regulatornih i internih zahteva ugrađuje direktno u razvojni i deployment pipeline, umesto da se usklađenost proverava samo neposredno pre lansiranja ili tokom audita.

Da li se promena AI modela mora tretirati kao promena proizvoda? U ozbiljnim i posebno regulisanim sistemima svakako bi trebalo proceniti uticaj promene. EU AI Act predviđa ponovnu conformity assessment proceduru kada high-risk sistem pretrpi relevantne substantial modifications (značajne izmene).

Šta je human oversight? Human oversight predstavlja stvarnu mogućnost kompetentne osobe da razume, prati i po potrebi interveniše u rad AI sistema. Formalno postavljanje dugmeta „Approve“ nije dovoljno ako čovek praktično nema sposobnost da ospori ili zaustavi odluku.

Da li korišćenje velikog foundation modela rešava compliance problem? Ne. Provider modela ima svoje obaveze, ali kompanija koja taj model integriše ili koristi u sopstvenom AI sistemu može imati dodatne obaveze koje zavise od njene uloge i namene proizvoda.

Da li harmonizovani standardi postaju obavezni? Ne automatski. Njihova primena je dobrovoljna, ali relevantni harmonizovani standardi mogu omogućiti presumption of conformity, odnosno pretpostavku da su odgovarajući regulatorni zahtevi ispunjeni.

Hoće li EU AI Act usporiti razvoj AI proizvoda? Kod određenih projekata hoće. Posebno kod visokorizičnih primena biće potrebno više evaluacije, dokumentovanja i kontrole. Međutim, kompanije koje automatizuju compliance i uvedu ga rano u razvoj mogu znatno smanjiti taj teret.

Šta bi kompanija trebalo prvo da uradi? Najpraktičniji prvi korak je AI inventory: popisati sve AI modele, SaaS alate, API-je, chatbotove, coding assistants i interne AI sisteme koji se koriste, zatim odrediti njihovu namenu, vlasnika, podatke koje obrađuju i regulatornu ulogu kompanije.