Infrastrukturni kod generiran umjetnom inteligencijom: jaz u upravljanju 2026.

AI agenti danas pišu sve veći udio Terraforma, Kubernetes i cloud konfiguracijskog koda u produkciji. Sintaksa je ispravna u više od 95% slučajeva. No razina sigurnosti već dvije godine zaredom stoji na otprilike 55%. Taj jaz — između “kod se prevodi” i “sigurno ga je izvoditi” — ključni je rizik infrastrukture kao koda u 2026. godini.

Veracodeovo proljetno izvješće o sigurnosti generativnog AI koda iz 2026. evaluiralo je 80 zadataka u 4 programska jezika, 4 klase ranjivosti prema Common Weakness Enumeration (CWE) standardu i više od 150 jezičnih modela. Glavni nalaz je jasan: samo 55% AI-generiranog koda proizvodi siguran kod bez dodatnih prilagodbi. Ispravnost sintakse prešla je 95%, ali sigurnost je ostala na mrtvoj točki. Modeli su izvrsni u pisanju koda koji se prevodi; nisu uspjeli u pisanju koda koji je siguran.

AI ubrzava proizvodnju IaC koda

Problem količine dodatno otežava problem kvalitete. Prema env0-ovom istraživanju iz 2026., 71% cloud timova bilježi mjerljiv porast količine infrastrukturnog koda potaknut generativnom umjetnom inteligencijom. AI agenti stvaraju pull requestove brže nego što ih većina timova stigne pregledati, stvarajući novu vrstu uskog grla u inženjerskim organizacijama.

Timovi se suočavaju s dva loša izbora: usporiti sve inzistiranjem na ručnom pregledu svake promjene ili prihvatiti nepregledani rizik u produkciji. Ranjivosti u infrastrukturi pogoršavaju taj kompromis na način na koji ranjivosti u aplikacijskom kodu to ne čine. Otvorena sigurnosna grupa ili pogrešno konfigurirana IAM uloga izlažu čitava okruženja, a ne pojedinačne usluge. Prema IBM/Ponemon izvješću o troškovima povrede podataka iz 2025., povrede koje obuhvaćaju više okruženja u prosjeku koštaju 5,05 milijuna dolara i zahtijevaju 276 dana za sanaciju.

Više o tome kako usko grlo pregleda utječe na IaC radne tokove potražite u ranijem članku o tome kako Terraform održava male infrastrukturne promjene pregledivima.

Što Veracodeovi podaci zapravo pokazuju

Veracodeova evaluacija testirala je više od 150 jezičnih modela na 80 koderskih zadataka, ciljajući četiri CWE vrste ranjivosti u Pythonu, C#, JavaScriptu i Javi. Rezultati otkrivaju gdje modeli uspijevaju, gdje dosljedno padaju i gdje zaključivanje pomaže.

Prema vrsti ranjivosti:

Ranjivost	Stopa sigurnosti	Ocjena
Nesigurna kriptografija (CWE-327)	86%	Snažno — dobro dokumentirani obrasci
SQL injekcija (CWE-89)	82%	Snažno — jasna specifikacija
Cross-Site Scripting (CWE-80)	15%	Uporni neuspjeh
Log injekcija (CWE-117)	13%	Najlošija kategorija, izravno relevantna za konfiguracije nadzora

SQL injekcije i kriptografske pogreške slijede dobro dokumentirane obrasce koje modeli dobro rješavaju. Cross-site scripting i log injekcija predstavljaju uporne neuspjehe. Log injekcija posebno je relevantna za infrastrukturni kod jer opservabilnosti cjevovodi generiraju strukturirane zapise koji se mogu iskoristiti kroz nepročišćeni unos.

Prema programskom jeziku:

Jezik	Stopa sigurnosti
Python	62%
C#	58%
JavaScript	57%
Java	29%

Java je najlošija s velikom razlikom. Najvjerojatnije objašnjenje jest da podaci za treniranje sadrže nesrazmjerno mnogo naslijeđenog poslovnog koda izgrađenog na nesigurnim okvirima, što modele uči obrascima koje ne bi trebalo reproducirati.

Prema razini modela:

Najbolji modeli — GPT-5.1, GPT-5.2, Gemini 3, Claude 4.5, Claude 4.6 — svi su grupirani na otprilike 55%, bez značajne razlike. Veličina modela prestala je biti čimbenik razlikovanja: čak i modeli s 400 milijardi parametara zadržavaju se na istoj granici od 55%. Modeli za zaključivanje (GPT-5 s produženim zaključivanjem) dosežu 70–72%, što je bolje, ali još uvijek predstavlja 28–30% stopu neuspjeha na sigurnosno kritičnim zadacima.

Obrazac je jasan: modeli su konvergirali prema sigurnosnoj granici koju ni povećanje opsega ni arhitektonske iteracije nisu pomaknuli u dvije godine. Jaz nije utrka prema većim modelima — to je problem upravljanja.

Zašto je to problem platformskog inženjerstva

Ranjivosti u aplikacijskom kodu pogađaju jednu uslugu. Ranjivosti u infrastrukturnom kodu — IAM pravila, pravila sigurnosnih grupa, mrežne ACL-ove, sigurnosne kontekste kontejnera — izlažu čitava okruženja. Jedan pogrešno konfiguriran Terraform resurs može zaobići sve sigurnosne kontrole na razini aplikacije.

Gartner predviđa da će 80% velikih organizacija za razvoj softvera imati platformske inženjerske timove do 2026., u odnosu na 45% u 2022. Platformski timovi definiraju “utrti put” — predloške, module i zaštitne mehanizme koji čine ispravnu infrastrukturu zadanim putem. Taj se mandat sada proširuje i na AI agente kao prvoklasne korisnike platforme.

DORA-ino izvješće o stanju DevOpsa iz 2023. pokazalo je da timovi s čestim odstupanjem konfiguracije imaju 2,3 puta veću stopu neuspjeha promjena. Infrastrukturne promjene generirane umjetnom inteligencijom koje se primjenjuju izvan ciklusa pregleda izravno ubrzavaju odstupanje. Kad svaka promjena prolazi kroz definirani cjevovod s automatiziranim provjerama, odstupanje se otkriva rano. Kad AI agenti zaobilaze taj cjevovod, svaka neprovjerena promjena postaje potencijalni incident u produkciji.

Za širi kontekst o tome zašto zrelost platforme određuje hoće li agencijski radni tokovi pomoći ili odmoći, pogledajte analizu Kubernetesa i platformskog inženjerstva u 2026..

Praktične zaštitne mjere — kako upravljanje izgleda u 2026.

Četiri sposobnosti razlikuju zrele platformske timove koji AI agente tretiraju kao upravljane korisnike infrastrukture, a ne kao iznimne slučajeve.

1. Politika kao kod primijenjena prije generiranja, a ne nakon njega

Provjera pravila prije planiranja — korištenjem alata poput Sentinel ili OPA pravila u fazi planiranja — smanjuje neuspjehe izgradnje uzrokovane kršenjem pravila do 45%, prema DevOps.com izvješću o StackGenovim podacima. Ključna arhitektonska odluka jest da ograničenja pripadaju uzvodno od generiranja, a ne nizvodno. Skeniranje generiranih konfiguracija naknadno je bolje nego ništa, ali otkriva kršenja koja su već potrošila vrijeme developera i računalne resurse.

2. RBAC koji tretira agente kao prvoklasne aktere

Svaki AI agent koji djeluje na infrastrukturi treba ograničena dopuštenja, kvote resursa i zapisnik revizije — iste kontrole koje biste primijenili na novog zaposlenika s produkcijskim pristupom. Mnogi developeri ne prilagođavaju zadane opsege dopuštenja u AI-generiranom kodu, tako da radijus eksplozije ranjivog Terraform plana izravno ovisi o tome do čega agentove vjerodajnice mogu doseći.

3. Kontinuirano otkrivanje odstupanja s automatskom korekcijom

Infrastruktura koja se samostalno ispravlja — koja poništava neovlaštene promjene i usklađuje stanje — više nije tek aspiracija. Praktični prag jest automatska sanacija za poznato ispravne obrasce i ljudska eskalacija za iznimke koje zahtijevaju prosudbu. Ručno upozoravanje samo dovodi do umora od upozorenja i naposljetku sljepila.

4. Provjera usklađenosti ugrađena u korak generiranja

Najnapredniji obrazac provjerava namjeru u odnosu na pravilo u trenutku generiranja, a ne naknadnim skeniranjem. Kod koji je usklađen po konstrukciji, a ne po korekciji, eliminira ciklus generiraj-skeniraj-popravi-regeneriraj koji karakterizira većinu trenutačnih AI-potpomognutih IaC radnih tokova.

Pet pitanja za vaš tim

Prilagođeno prema DevOps.com vodiču za upravljanje AI-generiranom infrastrukturom:

1. Mogu li AI agenti implementirati u produkciju? Ne bi smjeli imati širok pristup. Vjerodajnice agenata moraju biti ograničene, pregledane i rotirane kao i svaka produkcijska vjerodajnica.

2. Provjerava li se politika prije ili poslije generiranja? Naknadno skeniranje troši resurse i propušta kršenja koja provjera prije planiranja otkriva.

3. Tko pregledava AI-generirani IaC i u kojem omjeru? Postavite jasan prag za to koliko AI-generiranih pull requestova jedan recenzent može sigurno evaluirati dnevno.

4. Otkriva li se odstupanje automatski ispravlja ili samo prijavljuje? Ručna upozorenja dovode do sljepila. Automatska korekcija rješava uobičajene slučajeve.

5. Koji je poslovni trošak neupravljane AI-generirane infrastrukture? Prosječni trošak od 5,05 milijuna dolara po povredi koja obuhvaća više okruženja iz IBM/Ponemon studije polazna je točka za vašu procjenu rizika.

Kompromis između produktivnosti i sigurnosti

Dobici u produktivnosti IaC koda uz pomoć umjetne inteligencije stvarni su. Brojke o ispravnosti sintakse dokazuju da modeli mogu pouzdano generirati radne infrastrukturne konfiguracije. Ali bez promišljenog upravljanja ti dobici dolaze upakirani s rastućim sigurnosnim dugom.

Jaz između “koda koji radi” i “koda koji radi sigurno” ne samo da traje nego se i širi kako sve više timova usvaja AI-potpomognute IaC cjevovode bez odgovarajućeg ulaganja u upravljanje. Taj jaz pokretat će sljedeći val cloud incidenata.

Platformski timovi koji već sada prošire politiku kao kod, RBAC i kontinuiranu usklađenost na AI agente — umjesto da tretiraju agent-generiranu infrastrukturu kao poseban slučaj — uhvatit će dobitke u produktivnosti bez nasljeđivanja sigurnosnog duga. Revolucija produktivnosti je tu. Revolucija sigurnosti nije. Taj jaz definira izazov koji je pred nama.