Key Takeaways – Šta je najbitnije u ovom tekstu
Agile governance nije pokušaj da se Agile „stavi pod kontrolu“ i vrati u tradicionalni Project Management. Njegov cilj je upravo suprotan: da organizacija jasno definiše ko sme šta da odluči, pod kojim uslovima, uz koje kontrole i kakav dokaz o toj odluci mora da ostane, a zatim da timovima omogući što veću autonomiju unutar tih granica.
Ovo postaje kritično važno u trenutku kada IT organizacije istovremeno pokušavaju da rade brzo i da zadovolje zahteve GDPR-a, NIS2, DORA regulative, EU AI Act-a, internih Security Policy-ja, industrijskih standarda i sve detaljnijih zahteva klijenata.
Najgori odgovor na taj problem jeste governance zasnovan na čekanju: formulari, Excel tabele, ručna odobrenja, CAB sastanci i potpisi ljudi koji često ne poznaju samu tehničku promenu. Bolji model je Governance as Code, Policy as Code, automatizovani Audit Trail, Risk-Based Controls i Continuous Compliance – kontrole koje su ugrađene direktno u način na koji softver nastaje.
U jednoj rečenici: Agile governance nije manje kontrole, već pametnija kontrola. A možda i najvažnije: Compliance koji prvi put proveravate pred Release već ste loše organizovali.
Agile i governance nisu prirodni neprijatelji
Postoji veoma tvrdoglava zabluda da Agile znači slobodu, a governance kontrolu – te da ako povećamo jedno, drugo mora da strada. To zvuči logično samo dok ova dva pojma posmatramo površno.
Governance (upravljanje) u ozbiljnom poslovnom sistemu ne bi trebalo da znači da menadžer odobrava svaki Pull Request, niti da Compliance Officer sedi između developera i produkcije. Njegova osnovna pitanja su mnogo jednostavnija:
-
Ko je odgovoran i ko sme da donese određenu odluku?
-
Koji rizik prihvatamo, a koji ne?
-
Kako proveravamo da je pravilo poštovano i kako dokazujemo šta se dogodilo?
-
Šta radimo kada kontrola zakaže?
To su potpuno legitimna pitanja za Agile organizaciju. Problem nastaje kada odgovor na svako od njih postane: „Dodajmo još jedan Approval.“ Tada governance prestaje da upravlja rizikom i počinje da upravlja redovima čekanja.
Agile bez governance-a nije agilnost nego improvizacija
Agile tim treba da bude autonoman, ali autonomija ne znači odsustvo ograničenja. Developer u banci ne može samostalno odlučiti da će podatke o klijentima poslati na nepoznati Cloud servis samo zato što bi tako brže završio Sprint. Product Owner ne može ukinuti Audit Log jer „korisnicima ionako ne treba“. AI tim ne može promeniti svrhu sistema za ocenjivanje kandidata bez razmatranja etičkih posledica.
Agile ne ukida odgovornost. Naprotiv, što je tim autonomniji, granice odgovornosti moraju biti jasnije. Tu počinje Agile governance.
Regulativa više nije nešto čime se bavi samo Legal
Pre deset godina developer je mogao da kaže: „GDPR? To rešavaju pravnici.“ Danas je ta podela neodrživa.
GDPR princip Accountability (odgovornost) i Data Protection by Design and by Default direktno utiču na arhitekturu. Koje podatke čuvamo? Ko ima pristup? Kako ih pseudonimizujemo? Kako dokazujemo ko ih je koristio? To više nisu samo pravna pitanja, već Product, Architecture, Security i Operations pitanja. Isti obrazac danas vidimo i kod drugih propisa.
NIS2: Bezbednost kao organizaciona odgovornost
NIS2 dodatno pojačava ideju da Cybersecurity ne može biti poslednja stanica pre produkcije. Direktiva traži proporcionalne mere upravljanja sajber-rizikom koje obuhvataju Incident Handling, Business Continuity, Supply Chain Security, bezbednost razvoja, Access Control i upravljanje imovinom. To je praktično čitav IT Lifecycle.
Na ITNetwork-u smo u tekstu „Agile + DevSecOps: kako integrisati sajber-bezbednost bez usporavanja razvoja“ analizirali zašto kasni Security Review stvara najveći trošak. Najskuplja bezbednosna greška nije najteža greška – to je ona koju otkrijete najkasnije.
DORA: Kada „IT problem“ više nije samo IT problem
DORA (Digital Operational Resilience Act) jasno pokazuje smer evropske regulative. Primenjuje se od 17. januara 2025. na finansijski sektor, ali njena logika je univerzalna. Nije dovoljno da aplikacija radi. Organizacija mora da zna kako upravlja ICT rizikom, kako testira otpornost, kako upravlja dobavljačima i šta radi ako kritični vendor zakaže.
Operational Resilience postaje Governance pitanje, a Governance mora da uđe direktno u Backlog, arhitekturu, Infrastructure as Code i Incident Management.
EU AI Act pretvara governance AI sistema u inženjersku disciplinu
Od 2. avgusta 2026. veliki deo EU AI Act-a biće operativno primenljiv. AI governance se više ne svodi na: „Mi koristimo ChatGPT.“ Morate znati koji sistem, za koju svrhu, sa kojim podacima i ko proverava output. Za High-Risk sisteme predviđeni su strogi zahtevi za Traceability, Logging i Human Oversight.
Na Joombooz-u smo analizirali praktične posledice EU AI Act-a uz važan zaključak: Compliance kod AI-ja nije jednokratan projekat. Promeni se Prompt, model ili vendor, i stara procena rizika više ne opisuje sistem koji stvarno koristite.
Najveća greška: Governance kao završna kontrolna kapija
Klasična organizacija funkcioniše ovako: Business napiše zahtev → Development razvije → QA testira → Security pregleda → Legal proveri → Architecture Board i CAB odobre. Na papiru deluje kontrolisano. U realnosti ste izgradili fabriku čekanja.
Ako Compliance tek na kraju kaže: „Ove podatke ne smete ovako čuvati“, tim mora da menja Data Model. Ako Security pred Release traži novu autentifikaciju, menjate arhitekturu. To nije rigorozan Governance – to je kasno otkrivanje zahteva.
Shift Left važi i za compliance
Kao što postoji Shift Left Security, ista logika treba da važi za Shift Left Compliance. Umesto proveravanja na kraju, Compliance pitanja ulaze već u Definition of Ready. Da li funkcionalnost obrađuje lične podatke? Uvodi li novog vendora? Koristi li AI? Na osnovu toga zadatak dobija Risk Profile.
Ne treba promena fonta i Payment sistema da imaju isti governance
Ovo je fatalna greška velikih kompanija: sve promene tretiraju kao opasne. Promena boje dugmeta? CAB. Promena autentifikacije? Isti CAB. Taj proces ne upravlja rizikom, već ravnomerno distribuira birokratiju. Pametniji model:
-
Low Risk: Automatske provere, Peer Review, CI/CD, automatski Deployment.
-
Medium Risk: Automatske kontrole plus stručni Review.
-
High Risk: Threat Modeling, Architecture i Security Review, formalni Approval i kontrolisan Release.
Policy as Code: Pravilo koje računar proverava bolje od odbora
Tradicionalno: Neko napiše PDF pravilo (npr. o enkripciji baze), developer ga možda pročita, Security kasnije pronađe problem, otvara tiket, čekaju se dani. Moderno: Pravilo se prevodi u mašinski kod (Policy as Code). CI/CD Pipeline proverava kod. Ako baza nema enkripciju, Build pada odmah. Nema sastanaka i čekanja. Kontrola je pretvorena u automatizovanu infrastrukturu.
Continuous Compliance: Dokaz nastaje dok radimo, ne pred Audit
Najgori trenutak u kompaniji: „Audit je za tri nedelje. Moramo da prikupimo dokaze.“ Odjednom se traže skrinšotovi, Excel tabele i mejlovi iz februara.
Continuous Compliance menja to: dokaz nastaje kao nusproizvod rada. Git pokazuje ko je i kada menjao kod. CI/CD čuva rezultate sigurnosnih skeniranja. Cloud Audit Log beleži pristupe. Audit više nije arheološka ekspedicija – Audit Trail već postoji. Sledeći veliki korak je Evidence as Code, gde sistem u realnom vremenu potvrđuje usklađenost. (NIST SSDF je odličan primer ovog okvira zaštićenog razvoja).
Agile governance ne sme da ubije autonomiju tima
Ako developer mora da traži odobrenje da doda Cloud resurs, instalira biblioteku ili pokrene eksperiment – to nije autonoman tim, to je Ticket Processing Unit. Rešenje nisu centralizovane odluke, već Guardrails (zaštitne ograde).
Guardrail kaže: „Unutar ovih granica odlučujete sami.“ Tim može sam da koristi Open Source, ali samo ako prođe Vulnerability Scan. Može da deploy-uje, ali samo kroz sigurni Pipeline. Organizacija unapred definiše bezbedan prostor, a tim ne pita za dozvolu svaki put.
Golden Paths: Najlakši put treba da bude i najbezbedniji
Platform Engineering uvodi koncept Golden Path. Ako želite bezbednu konfiguraciju, ne dajte timu PDF od 90 strana, dajte im gotov Template. Developer klikne Create za novi mikroservis, a platforma automatski kreira CI/CD, Logging, Secrets Management, Access Control i skenere. Developer dobija brzinu, a Security standardizaciju.
Separation of Duties ne mora da znači Separation of Progress
Regulisane industrije zahtevaju da ista osoba ne piše i ne pušta kritičan kod. Umesto višednevnog čekanja potpisa, automatizujte to: Developer otvara PR, drugi inženjer radi Review, Pipeline potvrđuje identitete i beleži Audit Trail.
Dokumentacija nije neprijatelj Agile-a
Agile Manifesto kaže: Working software over comprehensive documentation. Ne kaže: Bez dokumentacije. U regulisanim sistemima morate čuvati Threat Models, arhitektonske odluke, Incident Reports. ADR (Architecture Decision Record) je odličan primer. Umesto elaborata od 80 strana, kratko beležite zašto ste izabrali rešenje i koji ste rizik prihvatili.
Takođe, pazite na Compliance Debt. Ako privremeno ugasite Audit log ili koristite stara prava pristupa, taj rizik raste u pozadini iako je „dashboard zelen“.
AI agenti će radikalno promeniti Agile governance
Sutrašnje pitanje neće biti „Šta sme developer?“, nego „Šta sme AI agent?“ Kada agent počne da generiše kod i pokreće Deployment, klasični Access Control (krojen za čoveka) pada u vodu. Ko je odgovoran za njegovu odluku? Šta ako je Prompt kompromitovan? Human Oversight postaje ključan, ali mora biti Risk-Based kako se ne bi pretvorio u Click Fatigue.
Kako bi zreo Agile governance model izgledao u praksi?
Zahtev za novu funkcionalnost se automatski klasifikuje na osnovu rizika (obrađuje li lične podatke, ima li AI, API…). Pre razvoja dodaju se obavezni koraci. Tokom razvoja aktiviraju se SAST i SCA skeneri. Pred spajanje koda radi se Quality Gate. Pred puštanje, Pipeline proverava sve dokaze. Posle puštanja, čuvaju se logovi. Nema 15 potpisa, a kontrola je mnogo jača.
Najbolji governance je nevidljiv developeru (Secure by Default). Ako je bezbedan put najkomplikovaniji, ljudi će ga zaobilaziti.
Zaključak: Najbrža kompanija nije ona bez kontrola
Postoji opasan mit da governance usporava inovacije. Loš governance to svakako radi (kroz formulare i komisije). Ali odsustvo Governance-a košta mnogo više (Data Breach, kazne regulatora).
Cilj je redizajn: od ručnog ka automatizovanom, od periodičnog ka Continuous, od univerzalnog ka Risk-Based modelu. Agile governance nije kompromis između brzine i kontrole – u zreloj organizaciji jedno omogućava drugo. Istinski agilna kompanija nije ona u kojoj svako radi šta hoće, već ona u kojoj ljudi veoma brzo mogu da urade pravu stvar, a veoma teško pogrešnu.
FAQ: Agile governance, compliance i regulativa
Šta je Agile governance? Model upravljanja kojim se definišu odgovornosti, rizici i kontrole, bez nepotrebnog ograničavanja autonomije timova. Cilj nije više ručnih odobrenja, već efikasnije i automatizovane kontrole.
Da li Agile može da funkcioniše u regulisanim industrijama? Da. Agile se masovno koristi u finansijama i zdravstvu. Ključ je integracija regulatornih zahteva u SDLC, umesto provere tek pred Release.
Šta znači Risk-Based Governance? Nivo kontrole zavisi od rizika konkretne promene. Promena teksta na sajtu ne prolazi isti proces odobrenja kao promena sistema za autentifikaciju.
Šta je Policy as Code? Pretvaranje organizacionih ili bezbednosnih pravila u mašinski proverljive politike koje se automatski izvršavaju kroz CI/CD ili Infrastructure as Code.
Šta je Continuous Compliance? Pristup gde se usklađenost proverava stalno tokom razvoja, umesto povremenim manuelnim proverama pred Audit.
Kakva je veza između DevSecOps-a i Agile governance-a? DevSecOps integriše Security kontrole u radni tok, čineći ga praktičnim mehanizmom Agile governance-a jer omogućava bezbednost bez ručnog čekanja.
Da li GDPR i NIS2 utiču na Agile razvoj? Da. GDPR utiče na Data Model i arhitekturu (Privacy by Design). NIS2 zahteva da se sajber-bezbednost, incident management i kontrola pristupa ugrade u kompletan ciklus razvoja softvera.
Šta DORA znači za Agile timove? Za kompanije iz finansijskog sektora, DORA (od januara 2025.) zahteva da ICT Risk Management, testiranje otpornosti i Third-Party Risk budu integrisani u planiranje i rad digitalnih servisa.
Kako EU AI Act menja Agile governance? Povećava zahteve za Risk Management, transparentnost, logovanje i Human Oversight. AI governance mora biti ugrađen u sam Product Development Lifecycle.
Da li automatizacija može zameniti Compliance tim? Ne. Automatizacija proverava deterministička pravila, ali ljudi moraju tumačiti zakone, procenjivati rizike i donositi etičke odluke.
Šta je Compliance Debt? Akumulacija odloženih kontrola i nedokumentovanih izuzetaka. Poput tehničkog duga, ako se ignoriše, postaje nevidljivi organizacioni rizik.
