AI scrie cod tot mai repede. Dar cine îl verifică? Ce se schimbă pentru securitate când construim software cu AI

AI-ul a schimbat felul în care scriem cod și producem software. Un developer poate porni de la o idee, o poate descrie în limbaj natural și poate ajunge în câteva minute la o funcție, un endpoint sau chiar la un prototip de aplicație. Iar odată cu instrumentele de vibe coding și agenții AI, vorbim despre sisteme care pot scrie, modifica și rula cod fiind necesară tot mai puțină intervenție umană.

Viteza asta ridică o întrebare pe care e ușor să o pierdem din vedere: cât de sigur este codul pe care îl construim atât de repede?

Un cod poate să ruleze, să treacă testele și să facă exact ceea ce i-am cerut și, în același timp, să lase în urmă vulnerabilități pe care nu le vedem imediat. Iar când AI-ul începe să aibă acces la repository-uri, terminale, baze de date sau alte sisteme, miza crește: este vorba despre ce poate face un sistem autonom cu acces la infrastructura noastră.

De aceea, discuția despre AI și programare trebuie să includă securitatea, responsabilitatea și competențele de care avem nevoie ca să folosim aceste instrumente fără să transformăm viteza într-o nouă sursă de risc.

1. Cod care funcționează ≠ cod sigur

Una dintre cele mai mari schimbări aduse de AI în dezvoltarea software-ului este viteza cu care poți ajunge de la o idee la ceva concret și funcțional. Îi ceri unui model să scrie o funcție, să construiască un endpoint sau chiar o aplicație și, în câteva minute, ai un cod pe care îl poți rula. Iar cu cât modelele devin mai bune la programare, cu atât este mai ușor să te uiți la rezultat și să spui: „cred că este în regulă”.

Dar un cod care funcționează nu este neapărat și un cod sigur. Un program poate să facă exact ceea ce i-ai cerut, să treacă testele de bază, dar să aibă în continuare probleme pe care acele teste nu le verifică. Asta poate însemna o vulnerabilitate care permite accesul la date, o configurare greșită sau o bibliotecă folosită în aplicație care are propriile probleme de securitate.

Un studiu Veracode publicat în 2025 arată cât de importantă este diferența dintre cele două. Compania a testat peste 100 de modele AI cu 80 de taskuri de programare, în patru limbaje și patru tipuri de vulnerabilități, iar doar 55% dintre rezultatele generate au trecut verificările de securitate. Asta nu înseamnă că 45% din tot codul generat de AI este vulnerabil. Studiul arată cum s-au descurcat modelele în condițiile respective, nu cât cod generat de AI este vulnerabil în viața reală.

O imagine similară apare și în benchmark-uri mai recente. În SusVibes, un studiu prezentat la ICML 2026 și revizuit în august 2026, cel mai bun setup de agent AI a produs cod corect funcțional în 57% dintre task-uri, dar doar 11,8% dintre soluții au fost considerate securizate. Datele astea nu contrazic studiul Veracode, ci completează tabloul: cu cât task-urile sunt mai apropiate de situații reale, cu atât decalajul dintre „funcțional” și „sigur” devine mai vizibil.

Rezultatele au fost diferite și în funcție de tipul de vulnerabilitate testat. Unele probleme au fost mai ușor de evitat, în timp ce la altele modelele au avut rezultate mult mai slabe. Asta ne arată că, deși AI-ul a devenit foarte bun la a produce cod care funcționează, securitatea nu vine automat la pachet cu funcționalitatea. Și aici apare una dintre cele mai importante schimbări aduse de AI în dezvoltare: dacă putem produce cod mult mai repede, trebuie să fim capabili să îl verificăm.

2. De ce AI-ul poate scrie cod perfect funcțional și totuși vulnerabil

Să luăm un formular de autentificare. Îi poți cere unui model AI să-l construiască, iar rezultatul poate funcționa foarte bine: utilizatorul își introduce emailul și parola, aplicația verifică datele și îi permite să intre. Dar, pentru ca formularul să fie și sigur, mai sunt câteva întrebări la care codul trebuie să răspundă corect: cum sunt stocate parolele? Câte încercări de conectare sunt permise? Sunt protejate sesiunile? Poate un utilizator să schimbe un ID din URL și să ajungă la datele altcuiva?

Aici apare ceea ce cercetătorii de la University at Buffalo numesc „knowledge-actuation gap”: modelul „știe” regulile de securitate, dar nu le aplică acolo unde ar conta, adică la linia de cod care ar bloca un atac. În task-uri simple, gap-ul e vizibil, dar în aplicații reale, unde securitatea trebuie să stea în middleware-ul potrivit, ruta potrivită și fișierul potrivit, diferența dintre ce știe modelul și ce livrează devine și mai mare. De aceea poți ajunge ușor la un formular care „merge”, dar nu are rate limiting, nu validează input-urile cum trebuie sau nu verifică cine are voie să vadă ce date.

AI-ul lucrează cu informația pe care i-o dai și pornește de la cerința pe care o formulezi. Dacă îi ceri „construiește un sistem de autentificare”, îți va livra asta. Dar dacă nu îi ceri explicit să ia în calcul rate limiting, gestionarea sesiunilor, controlul accesului, protejarea secretelor și alte măsuri de securitate, unele dintre ele pot lipsi sau pot fi implementate într-un mod nepotrivit.

Aici intervine și importanța contextului. Până la urmă, siguranța unei aplicații ține și de felul în care toate aceste lucruri funcționează împreună. De aceea, omul trebuie să înțeleagă unde este folosit codul, ce date poate accesa, ce permisiuni are și ce s-ar putea întâmpla dacă cineva încearcă să-l folosească altfel decât a fost gândit. Cu atât mai mult când vorbim despre aplicații care lucrează cu date personale, bani sau sisteme importante.

3. Vibe coding schimbă și cine poate construi software

Până nu demult, ca să construiești un instrument digital aveai nevoie de o bază în programare. Astăzi, poți descrie în limbaj obișnuit ce vrei să facă o aplicație, iar un instrument AI îți poate genera interfața, baza de date, funcțiile și pașii necesari pentru a o rula. Asta schimbă atât viteza dezvoltării, cât și cine poate începe să construiască software.

Un antreprenor poate face prototipul unui instrument intern pentru echipă. Un specialist în marketing își poate face un dashboard. Un jurnalist poate construi un instrument pentru organizarea documentelor. Un profesor poate crea o aplicație simplă pentru cursurile sale. Problema apare atunci când un prototip este confundat cu un produs pregătit pentru utilizare reală.

Un instrument care „merge pe laptopul meu” nu este același lucru cu o aplicație care poate folosi în siguranță datele a 10.000 de clienți. O pagină care arată bine nu este automat pregătită să proceseze plăți. Un formular care salvează date într-o bază de date nu este pregătit să stocheze informații medicale, financiare sau personale.

Între aceste două niveluri există o mulțime de elemente: autentificarea, autorizarea, backupurile, logurile, dependențele, protecția împotriva atacurilor automate, controlul accesului și modul în care aplicația reacționează atunci când ceva nu merge conform planului. Aici este una dintre cele mai importante competențe pe care le aduce vibe coding-ul: să știi când ai depășit nivelul la care poți valida singur ceea ce ai construit.

Nu trebuie să devii programator senior înainte să folosești AI pentru codare. Dar trebuie să recunoști momentul în care proiectul nu mai este doar un experiment și să răspunzi la câteva întrebări importante:

• Ce date intră în aplicație și unde ajung?
• Cine are voie să le vadă sau să le modifice?
• Ce se întâmplă dacă un utilizator încearcă să forțeze sistemul?
• Ce biblioteci și servicii externe sunt folosite?
• Cum sunt gestionate parolele, cheile și tokenurile?
• Cine poate verifica aplicația înainte să ajungă la utilizatori?
• Ce se întâmplă dacă ceva este șters, trimis greșit sau expus?

Center for Security and Emerging Technology (CSET) subliniază că riscurile codului generat cu AI nu ar trebui puse doar în responsabilitatea utilizatorului individual. Sunt implicați dezvoltatorii modelelor, organizațiile care folosesc aceste instrumente, echipele care produc software la scară largă și cei care stabilesc standarde sau reguli pentru securitate.

4. Agenții AI cresc miza

Un instrument care îți dă niște sugestii și un agent AI care poate modifica singur mai multe fișiere nu implică aceleași riscuri. Primul îți oferă o propunere. Tu o citești, o accepți sau o modifici și iei decizia finală. Al doilea poate primi un obiectiv, poate analiza, poate împărți problema în pași, poate rula comenzi, poate instala pachete, poate modifica fișiere și poate încerca din nou dacă primul rezultat nu funcționează.

IBM descrie diferența dintre un asistent și un agent prin această combinație de autonomie, conectivitate și acțiune. Iar cu cât agentul poate face mai multe lucruri, cu atât este mai mare și suprafața de atac. Dacă agentul primește acces la repository și la terminal, o instrucțiune greșită sau o manipulare a contextului poate avea efecte mai serioase decât o sugestie de cod care nu a fost acceptată.

Asta nu înseamnă că agenții AI sunt inutili sau că orice acces trebuie blocat. Înseamnă că accesul trebuie proiectat cu mai multă atenție. Primul principiu este least privilege, adică accesul minim necesar. Un agent care trebuie doar să citească fișierele unui proiect nu ar trebui să poată șterge repository-ul. Un agent care rulează teste nu are nevoie automat de permisiunea de a face deploy în producție. Un agent care analizează o bază de date poate avea nevoie de acces read-only, nu de dreptul de a modifica sau elimina tabele.

Al doilea principiu este izolarea. Un agent ar trebui, pe cât posibil, să lucreze într-un sandbox (un mediu izolat și controlat în care pot fi rulate programe, cod sau experimente fără a afecta sistemul principal) sau într-un mediu separat, unde acțiunile sale pot fi observate și oprite fără să afecteze direct sistemele reale.

Al treilea principiu este autentificarea și identitatea. Trebuie să știm ce agent AI a acționat, pentru cine, cu ce permisiuni și în baza cărei aprobări. PwC recomandă ca fiecare agent să aibă o identitate verificată, un rol definit, permisiuni legate de o anumită sarcină și un istoric al acțiunilor care poate fi verificat ulterior.

Nu uita că pe măsură ce cresc autonomia agentului și consecințele acțiunilor sale, trebuie să crească și nivelul de supraveghere umană. Trebuie să știm la ce are acces, ce poate modifica, ce poate face fără aprobare și cum îi putem opri accesul dacă ceva merge prost. Autonomia nu ar trebui acordată dintr-o dată și fără limite, ci construită treptat, în funcție de cât de bine putem controla și verifica ceea ce face.

Aici mai e o capcană ușoară: să te bazezi pe faptul că „îl punem pe AI să-și verifice singur codul”. În practică, același model care a scris codul are aceleași puncte oarbe și când îl rogi să-l facă acest audit: nu cunoaște modelul tău de autorizare, nu are tot contextul și e la fel de încrezător în varianta nesecurizată ca în cea securizată. Benchmark-urile arată că simpla adăugare de indicii de vulnerabilitate în prompt nu elimină problemele. De aceea verificarea de încredere are nevoie de semnal extern: scanning automat, reguli clare de securitate și, mai ales, review uman pe zonele sensibile.

5. Un nou atacant, dar și o nouă suprafață de atac

În ultimele săptămâni au apărut câteva exemple care ne arată cum poate fi folosit AI-ul în atacuri și de ce discuția despre securitate devine tot mai complicată. La începutul lui octombrie, compania de cercetare Transluce a relatat că agenți AI au încercat să acceseze un site al guvernului canadian. Autoritățile canadiene au confirmat că știau despre activitate, dar au spus că nu există indicii că sistemele guvernului ar fi fost compromise.

Pe 6 octombrie, președintele Coreei de Sud a spus că există indicii că AI-ul ar fi fost folosit în unele atacuri recente asupra unor bănci, în timp ce investigația este încă în desfășurare. Nu știm cu exactitate toate detaliile și nici cât de mult a fost implicat AI-ul în aceste atacuri, dar cert este faptul că AI-ul poate deveni, în anumite situații, parte din procesul de atac.

Asta nu înseamnă că AI-ul reinventează toate metodele de atac. Multe breșe apar în continuare din motive foarte bine cunoscute. Pe 6 octombrie, Reuters relata despre o breșă care a compromis date sensibile ale FBI, după ce un patch critic pentru Oracle PeopleSoft nu fusese instalat.

Contrastul este important. Pe de o parte, vorbim despre agenți AI care pot căuta vulnerabilități și pot testa foarte rapid mai multe metode de acces. Pe de altă parte, realitatea ne arată că o vulnerabilitate cunoscută și un patch care nu a fost instalat la timp pot fi suficiente pentru a produce o breșă serioasă. Nu avem nevoie întotdeauna de un atacator care folosește AI ca să avem o problemă de securitate. Uneori este suficient să lăsăm nerezolvată o vulnerabilitate pe care o cunoaștem.

De aici reiese o lecție importantă pentru companii: AI-ul poate crește viteza și amploarea atacurilor, dar nu schimbă regulile de bază ale securității. Dacă ai sisteme neactualizate, parole neprotejate sau vulnerabilități lăsate „pentru mai târziu”, o soluție sofisticată de securitate bazată pe AI nu va repara automat problema. Înainte să ne gândim cum ne apărăm de atacatori care folosesc AI, trebuie să verificăm dacă nu le lăsăm deja ușa întredeschisă.

6. Ce trebuie să știe acum un developer care folosește AI

Am văzut ce riscuri poate aduce codul generat de AI și cum agenții schimbă atât procesul de dezvoltare, cât și provocările de securitate. Dar cum se traduc toate acestea în practica de zi cu zi? Ce ar trebui să verifice un developer înainte să dea deploy unui cod scris sau modificat cu ajutorul AI?

L-am întrebat pe George Flurche, inginer software și mentor în programele Digital Stack, care este greșeala pe care o vede cel mai des când oamenii folosesc AI pentru a scrie cod:

„Un agent AI trebuie văzut ca o unealtă care are ca scop eficientizarea efortului depus de un programator/inginer R&D - nu ca pe o persoană propriu-zisă care poate înlocui programatorul. Cel mai des observ oameni care nu înțeleg concepte de programare sau fără un background tehnic încercând să rezolve probleme reale prin prompturi vagi, mult prea generice. Vulnerabilitatea principală este că AI-ul promite prea mult, deoarece obține rezultate convingătoare într-un timp extrem de scurt, iar inginerii tratează superficial validarea codului generat.”

Viteza cu care AI-ul generează cod nu ar trebui să scurteze procesul de verificare. Developerul rămâne responsabil pentru ceea ce ajunge în producție, indiferent cine sau ce a scris codul.

Ce ar trebui să verifice obligatoriu un developer înainte să dea deploy unui cod generat cu AI

„Un developer trebuie să trateze codul generat ca pe un cod scris de un angajat aflat sub supravegherea lui, de ale cărui acțiuni este responsabil 100%. Deci, într-un scenariu ideal, ar trebui verificat comportamentul codului, tratate cazurile de risc, analizat stilul și eliminat conținutul redundant.”

7. Python și agenții: contează mai mult cum îl folosești decât limbajul în sine

Python este folosit pe scară largă în dezvoltarea aplicațiilor bazate pe AI și a agenților software. Pentru developerii care intră în acest domeniu, este unul dintre limbajele cu care se vor întâlni frecvent.

Totuși, folosirea Python nu reprezintă în sine un risc de securitate. Contează cum este construită aplicația, ce biblioteci folosește, la ce date are acces și ce permisiuni primesc agenții integrați în ea.

Tot George ne-a explicat ce competențe de securitate merită dezvoltate de programatorii care lucrează cu Python și AI:

„Deși securitatea este critică pentru companii mari și medii și pentru toate entitățile care sunt stricte în manipularea datelor sau au restricții de confidențialitate, există o nevoie uriașă de automatizare și robotizare a fiecărui proces din viața de zi cu zi. Implementarea unor măsuri de siguranță atunci când ele nu sunt utile sau necesare în niciun fel este o formă de overengineering, iar programatorul trebuie să poată decide în avans nivelul de securitate de care aplicația are cu adevărat nevoie.

Dacă ar fi totuși să aleg o competență care va deveni din ce în ce mai importantă, aceea ar fi capacitatea de a identifica și proteja datele sensibile, precum date personale, credențiale, tokenuri, chei de acces sau informații confidențiale care nu trebuie expuse către servicii externe sau agenți AI.”

Dincolo de alegerea măsurilor potrivite pentru fiecare aplicație, rămâne întrebarea practică: ce ar trebui să învețe un developer de la început, astfel încât securitatea să facă parte din procesul de dezvoltare, nu să devină o problemă de rezolvat ulterior?

„Toate datele cu caracter sensibil (PII - Personally Identifiable Information) trebuie să rămână, indiferent de moment, în sistemele aprobate. Niciun agent AI nu trebuie să primească acces la astfel de informații, deoarece reprezintă un factor de risc. Parolele, cheile de autentificare, variabilele importante de mediu, IP-urile, etc - toate trebuie să rămână într-un mediu controlat și nu în cod, deoarece codul poate ajunge într-un agent, poate ajunge în git, în cloud sau în alte locuri de unde pot fi recuperate versiuni anterioare.

E o discuție foarte amplă, deoarece fiecare scenariu are particularitățile lui, dar în esență, putem presupune că orice informație care ajunge într-un mediu extern poate fi păstrată, prelucrată sau folosită de alte entități, deci este critic să înțelegem diferența dintre date sensibile și date care pot fi expuse fără nicio problemă.

Un exemplu simplu este generarea unui script Python care citește un fișier CSV și trimite automat datele către un serviciu extern. Un developer junior ar putea rula direct codul generat de AI pentru că pare corect și produce rezultatul dorit. Problema este că AI-ul poate introduce fără intenție detalii precum logarea întregului conținut al fișierului, afișarea unor informații sensibile în consolă sau transmiterea unor date care nu ar trebui să părăsească organizația. Funcțional, aplicația merge perfect.

Problema apare doar atunci când ne uităm la impactul asupra securității și confidențialității datelor. Acesta este motivul pentru care codul generat de AI trebuie tratat ca orice alt cod: revizuit, testat și înțeles înainte de a fi utilizat în producție.”

***

George Flurche lucrează în principal în zona automatizării, dezvoltării de aplicații și integrării soluțiilor bazate pe AI în procese tehnice reale. În cadrul programelor Digital Stack, a susținut sesiuni practice de Python și Inteligență Artificială, în care participanții au construit pas cu pas aplicații complete, de la integrarea modelelor AI și agenților software până la embeddings, semantic search și chatbot-uri. Abordează tehnologia dintr-o perspectivă pragmatică, concentrată pe înțelegerea principiilor de bază și pe construirea unor soluții care rezolvă probleme reale.

8. Ce se schimbă pentru companii

Pentru o companie, miza nu este doar că un developer poate scrie cod mai repede cu ajutorul AI. Miza este că întregul mod de lucru începe să se schimbe: cine ia decizii, cine verifică rezultatul, cât de repede intră modificările în aplicație și cum știe organizația că viteza obținută nu vine cu un risc pe care nu îl mai poate controla.

Un instrument AI poate reduce timpul necesar pentru o anumită sarcină. Dar beneficiul real nu se măsoară doar în minutele economisite la scrierea codului. Trebuie să iei în calcul și timpul necesar pentru înțelegerea rezultatului, verificarea lui, integrarea, testarea și eventualele reparații.

Dacă o echipă produce cu AI de două ori mai mult cod, dar restul procesului rămâne neschimbat, compania nu obține automat de două ori mai multă valoare. Veracode descrie acest risc prin „security debt”: vulnerabilități și probleme de securitate care rămân nerezolvate și se adună în timp.

Asta poate crea un paradox. Pe hârtie, echipa pare mai productivă pentru că livrează mai multe funcționalități. În realitate, o parte din această viteză poate fi transferată în etapele ulterioare: securitate, mentenanță, depanare și gestionarea incidentelor.

Productivitatea nu înseamnă doar viteză

Un sondaj citat de Dark Reading arată că 96% dintre dezvoltatorii chestionați nu au încredere că un cod generat de AI este corect fără verificare. În același timp, doar 48% spun că verifică întotdeauna codul generat de AI înainte să îl trimită mai departe în procesul de dezvoltare.

Tensiunea asta se vede și la nivel de adopție. În raportul DORA din 2025, 90% dintre respondenți spuneau că folosesc AI la muncă, dar 30% aveau încredere mică sau nulă în codul generat, iar adopția AI corela cu o stabilitate mai scăzută a livrării de software. Altfel spus, echipele livrează mai repede, dar nu neapărat mai sigur, iar o parte din viteza câștigată se mută în etapele de securitate, mentenanță și reparat incidente.

Diferența dintre cele două răspunsuri spune ceva important despre organizații. Oamenii pot ști foarte bine că un rezultat trebuie verificat și, totuși, să nu aibă timpul, resursele, instrumentele sau regulile necesare pentru a face asta de fiecare dată.

De aceea, companiile nu ar trebui să măsoare succesul adoptării AI doar prin numărul de linii de cod, funcții sau taskuri închise. Ar trebui să se uite și la:

• cât de des ajung problemele de securitate în etape târzii;
• cât timp durează remedierea lor;
• câte modificări sunt refăcute după review;
• câte dependențe sau componente sunt introduse fără o evaluare clară;
• cât de mult înțeleg oamenii codul pe care îl livrează;
• dacă viteza de dezvoltare crește fără să crească și numărul incidentelor sau al problemelor de mentenanță.

AI trebuie integrat în proces, nu doar adăugat peste el

Dacă AI-ul preia o parte din munca de implementare, învățarea se schimbă și ea la rândul ei. Trebuie să înveți cum să înțelegi un cod pe care nu l-ai scris integral, cum să pui întrebările potrivite, cum să recunoști o soluție fragilă și cum să știi când un proiect a depășit nivelul la care poate fi verificat informal.

Un junior care începe să lucreze în Python are nevoie să înțeleagă bazele: cum circulă datele printr-o aplicație, ce înseamnă autentificarea, de ce există diferența dintre autentificare și autorizare și de ce un cod care rulează nu este automat un cod sigur.

Un backend developer are nevoie de o înțelegere mai aprofundată a API-urilor, bazelor de date, dependențelor, gestionării secretelor și controlului accesului. Un developer care lucrează cu agenți AI trebuie să înțeleagă și ce poate face agentul în numele lui, ce date poate accesa și unde este necesară aprobarea umană.

Cineva care construiește aplicații cu low-code și AI nu trebuie să învețe neapărat arhitectură software la nivel avansat. Dar trebuie să știe unde ajung datele, cine poate accesa aplicația, ce permisiuni sunt activate automat și când are nevoie de o verificare tehnică.

Un engineering manager sau un fondator are un alt tip de responsabilitate. Nu trebuie să știe fiecare detaliu de implementare, dar trebuie să poată pune întrebări corecte despre risc, să creeze timp pentru verificare și să nu evalueze productivitatea exclusiv prin viteza cu care sunt închise taskurile.

Aici intervine și rolul programelor de formare care combină partea tehnică cu aplicarea ei în proiecte reale. Digital Stack poate construi această zonă de învățare în funcție de nivelul și rolul participantului, de la bazele programării și lucrul cu Python până la competențe de securitate relevante pentru aplicațiile și instrumentele pe care oamenii le folosesc deja.

9. Învață cum să identifici și să previi amenințările cibernetice

Dacă vrei să înțelegi mai bine cum se schimbă securitatea digitală odată cu apariția AI-ului și cum îți poți proteja datele și sistemele, îți recomandăm cursul Stăpânește viitorul Cybersecurity: Folosește AI pentru o apărare digitală impenetrabilă, din cadrul Digital Stack.

Pe parcursul celor patru săptămâni, vei învăța să recunoști tipurile comune de atacuri cibernetice, să înțelegi cum poate fi folosit AI-ul generativ pentru a facilita atacuri și să aplici bune practici pentru protejarea datelor personale și a infrastructurii digitale.

Ce vei învăța la curs:

• Să recunoști atacurile cibernetice: vei explora exemple practice și vei înțelege cum să identifici amenințările și să previi riscurile.
• Să înțelegi rolul AI-ului în securitatea digitală: vei descoperi cum poate facilita atacurile cibernetice și ce riscuri noi apar odată cu utilizarea lui.
• Să aplici măsuri concrete de protecție: vei învăța cum să-ți protejezi datele personale și infrastructura digitală.
• Să-ți dezvolți competențele de securitate: vei înțelege mai bine cum poate fi folosit AI-ul atât în atacuri, cât și în protejarea datelor și sistemelor.

Cine te ghidează?

Alex Gâtu, lider tech cu peste 15 ani de experiență în domeniu, care lucrează în testarea software și ajută profesioniștii să-și dezvolte carierele încă din 2015.