Cine deține codul scris cu AI și ce riști cu licențele

Contractul cu clientul spune că îi cedezi toate drepturile asupra codului livrat. O parte semnificativă din acel cod a fost scrisă de un asistent AI, în editor, pe baza unor comentarii de două rânduri. Întrebarea care nu se pune aproape niciodată la semnare: ce anume cedezi, mai exact?

Nu e o discuție teoretică. Are trei consecințe practice pentru o firmă de software din România: ce poate promite prin contract, ce riscă atunci când o secvență generată seamănă cu cod public aflat sub o licență incompatibilă și ce trebuie să poată dovedi dacă cineva întreabă. Articolul acesta le tratează pe rând, cu textele legale verificate și cu termenii reali ai furnizorilor, nu cu ce se povestește pe forumuri. Despre conținutul creat cu AI în general — texte, imagini, materiale de marketing — am scris separat, în ghidul despre drepturile de autor asupra conținutului generat; aici discutăm strict codul, care are propriul regim juridic și propriile capcane.

Regula de bază: dreptul de autor cere un autor uman

Protecția programelor pentru calculator vine, în Uniunea Europeană, din Directiva 2009/24/CE. Articolul 1 alineatul (3) stabilește criteriul: un program e protejat dacă e original, în sensul că reprezintă creația intelectuală proprie a autorului. Articolul 2 alineatul (1) precizează cine poate fi autor: persoana fizică sau grupul de persoane fizice care a creat programul — iar acolo unde legislația națională permite, poate fi desemnată titulară și o persoană juridică.

În România, Legea nr. 8/1996 preia aceeași logică. Articolul 72 alineatul (1) definește obiectul protecției: „orice expresie a unui program, programele de aplicație și sistemele de operare, exprimate în orice fel de limbaj, fie în cod-sursă sau cod-obiect, materialul de concepție pregătitor, precum și manualele". Alineatul (2) exclude expres ideile, procedeele, metodele de funcționare, conceptele matematice și principiile.

Iar articolul 74 rezolvă situația angajaților, în formularea care e citată mai des decât e citită: „În lipsa unei convenții contrare, drepturile patrimoniale de autor asupra programelor pentru calculator, create de unul sau de mai mulți angajați în exercitarea atribuțiilor de serviciu sau după instrucțiunile celui care angajează, aparțin acestuia din urmă."

Puse cap la cap, aceste texte duc la o concluzie pe care mulți o găsesc inconfortabilă: protecția se leagă de un aport creativ uman. Dacă un fragment a fost produs integral de model, fără o contribuție creativă a unei persoane, nu există un „autor" în sensul legii, deci nu există nici drepturi patrimoniale de transmis mai departe. Nu există încă o hotărâre a Curții de Justiție a Uniunii Europene dedicată codului generat, deci formulările prudente sunt obligatorii; dar direcția e aceeași în toate analizele serioase, iar în Statele Unite instanțele au reconfirmat în 2025 cerința autorului uman.

Ce înseamnă „aport uman" în cazul codului

Aici e partea utilă, pentru că răspunsul nu e „scrii tu totul de mână". Contribuția umană relevantă într-un proiect software se manifestă în:

• specificația și arhitectura — decizia despre ce module există, ce responsabilități au, cum comunică;
• selecția și respingerea — care variantă propusă intră în cod și care nu, pe ce criterii;
• adaptarea substanțială — refactorizarea, integrarea în contextul aplicației, tratarea cazurilor limită;
• structura ansamblului — ordinea, compunerea, alegerile care fac dintr-un set de fragmente un program.

Un flux de lucru în care omul scrie o specificație, cere modelului o implementare, o citește, o respinge de două ori și o modifică nu e același lucru cu acceptarea automată a sugestiilor. Primul produce un aport documentabil. Al doilea nu. Diferența se vede și în calitatea produsului, nu doar în teoria juridică — motiv pentru care disciplina de plan, review și verificare din fluxul agentic e tratată pe larg în cursul de Claude Code Mastery.

Un detaliu practic: dacă vrei ca aportul uman să însemne ceva mai târziu, trebuie să lase urme. Istoricul de commituri, deciziile de arhitectură scrise, cererile de modificare din review — toate acestea sunt, în caz de dispută, singura dovadă că a existat o contribuție creativă.

Ce spun, de fapt, termenii furnizorilor

Aici se destramă cele mai multe mituri de la cafea.

GitHub Copilot. Termenii specifici produsului spun explicit: „GitHub does not own Suggestions. You retain ownership of Your Code." și „It is entirely your decision whether to use Suggestions". Documentația despre utilizarea responsabilă e la fel de directă în privința riscului: „Users assume all risks associated with generated code including security vulnerabilities, bugs, and IP infringement", iar despre similitudine: „While the probability is low, Copilot may generate code suggestions that match code in the training set."

Anthropic. Termenii comerciali prevăd că clientul deține output-urile, iar Anthropic îi cesionează „its right, title and interest (if any) in and to Outputs". Parantezele acelea două cuvinte sunt cea mai onestă frază din tot domeniul: furnizorul îți dă ce are, dar nu îți garantează că are ceva de dat.

Regula generală, valabilă la toți furnizorii mari: furnizorul nu revendică proprietatea asupra output-ului și nu îți garantează că output-ul e protejabil sau că nu încalcă drepturile nimănui. Riscul rămâne la tine, iar contractul cu clientul îl mută mai departe, la tine, încă o dată.

Riscul real nu e proprietatea. E licența.

Faptul că un fragment generat nu e protejat de drept de autor e, în cel mai rău caz, o problemă de valoare a activului. Faptul că un fragment generat reproduce cod public aflat sub o licență cu obligații stricte e o problemă de conformitate, care poate atinge produsul livrat clientului.

Modelele de cod au fost antrenate, printre altele, pe depozite publice. Când o secvență e suficient de răspândită, probabilitatea ca modelul să o reproducă aproape identic crește. Iar dacă acea secvență provine dintr-un proiect sub o licență cu efect de reciprocitate — familia GPL, în forma cea mai cunoscută — obligațiile acelei licențe se propagă asupra a ceea ce ai construit peste ea, inclusiv, în anumite condiții, obligația de a pune la dispoziție codul-sursă.

Există unelte care reduc riscul. GitHub descrie un sistem de detectare a duplicatelor, „designed to identify when suggestions match publicly available code", pe care organizațiile îl pot configura fie să blocheze sugestiile, fie să afișeze referințe cu depozitul și licența.

Și aici apare detaliul pe care aproape toată lumea îl are greșit, pentru că s-a schimbat recent. Microsoft menține un angajament contractual de apărare a clienților împotriva anumitor pretenții de proprietate intelectuală privind conținutul generat — Customer Copyright Commitment — condiționat de aplicarea unor măsuri obligatorii. Pentru produsele GitHub, pagina oficială de măsuri obligatorii spune, cu efect din 3 aprilie 2026: „Use of the Duplicate Detection filter feature is no longer required for CCC coverage. This feature remains available for optional use."

Cu alte cuvinte: recomandarea „activează filtrul, altfel pierzi acoperirea" era corectă până în aprilie 2026 și e depășită acum. Ceea ce nu s-a schimbat e regula de bază: condițiile se verifică la data la care a fost generat codul, în contractul tău, nu într-un articol. Pentru serviciile configurabile de tip Azure OpenAI, măsurile rămân stricte: la generarea de cod, modelul de detectare a materialului protejat trebuie activat în modul de anotare sau de filtrare, iar dacă alegi anotarea, ești obligat să respecți licența indicată pentru conținutul respectiv.

Merită reținut și contextul juridic mai larg: procesul colectiv privind Copilot e încă pe rol în Statele Unite, iar Curtea de Apel pentru al Nouălea Circuit a audiat pledoariile în februarie 2026 pe chestiunea dacă răspunderea pentru eliminarea informațiilor de gestionare a drepturilor cere copii identice. Nu există, deci, o soluție definitivă pe care să îți construiești politica internă. Politica se construiește pe controale, nu pe speranța unei hotărâri favorabile.

Ce ai semnat, de fapt, cu clientul

Un contract obișnuit de dezvoltare software conține trei clauze care se comportă diferit când o parte din cod e generată.

Cesiunea drepturilor. Poți cesiona doar drepturile care există. Pentru părțile cu aport creativ uman, cesiunea funcționează normal. Pentru fragmentele generate integral, obiectul cesiunii e discutabil — ceea ce, în practică, nu îl împiedică pe client să folosească livrabilul, dar poate conta enorm dacă produsul e revândut, dacă firma e cumpărată sau dacă un concurent copiază o parte din el.

Garanția de neîncălcare a drepturilor terților. Aceasta e clauza periculoasă. Prin ea garantezi că livrabilul nu încalcă drepturi ale terților. Dacă nu ai niciun control asupra provenienței codului generat, garantezi ceva ce nu poți verifica. Soluția nu e eliminarea clauzei — niciun client serios nu acceptă — ci corelarea ei cu procesul intern de verificare și cu o limitare de răspundere rezonabilă.

Personalul și colaboratorii. Pentru angajați, articolul 74 din Legea nr. 8/1996 rezolvă transferul drepturilor patrimoniale, în lipsa unei convenții contrare. Pentru colaboratori pe PFA sau contract de prestări servicii, regula nu se aplică automat: acolo trebuie clauză expresă de cesiune. Iar dacă acel colaborator lucrează cu un asistent AI, întrebarea despre ce cedează efectiv se pune la fel ca mai sus.

O clauză care apare tot mai des în contractele cu clienți mari, mai ales din sectorul public sau financiar: obligația de a declara utilizarea instrumentelor AI în procesul de dezvoltare și de a respecta anumite restricții. Dacă nu ai un răspuns pregătit, îl vei improviza sub presiune, la o achiziție. Cum se scrie o politică internă care nu blochează munca e subiectul cursului de politică de utilizare AI, iar partea de guvernanță tehnică și audit e acoperită în AI Security și Ethical Engineering.

Șase controale care se pot implementa săptămâna aceasta

Nu ai nevoie de un program de conformitate. Ai nevoie de șase lucruri, dintre care patru sunt tehnice.

1. Politică scrisă de o pagină: ce instrumente sunt permise, pe ce proiecte, ce nu se lipește niciodată într-un prompt (cod al clientului sub acord de confidențialitate, chei, date personale).
2. Analiza compoziției software în integrarea continuă: unelte de scanare a dependențelor și a licențelor, cu prag de eșec pentru licențele incompatibile cu modelul tău de livrare.
3. Inventar de componente — lista completă a bibliotecilor și versiunilor. Îți va fi cerută oricum: obligațiile de raportare din Regulamentul (UE) 2024/2847 privind reziliența cibernetică se aplică de la 11 septembrie 2026, iar restul obligațiilor, de la 11 decembrie 2027.
4. Review uman obligatoriu, cu urmă în istoric. Nicio livrare de cod generat direct în ramura principală.
5. Jurnal de proveniență pentru fragmentele sensibile: unde ai avut o sugestie lungă, atipică sau surprinzător de completă, notează de unde a venit. Cinci minute atunci, o zi câștigată la o verificare.
6. Revizuirea contractelor-cadru: garanția de neîncălcare, limitarea răspunderii și clauza de declarare a utilizării AI, corelate cu procesul real, nu cu cel dorit.

Ce automatizezi din verificarea codului în integrarea continuă și ce rămâne la om am detaliat separat în ghidul despre code review cu agenți AI.

Ce se schimbă în următoarele optsprezece luni

Trei calendare merită trecute în agenda firmei.

11 septembrie 2026 — încep obligațiile de raportare din regulamentul privind reziliența cibernetică: vulnerabilitățile exploatate activ și incidentele grave se raportează, prin platforma unică, către agenția europeană pentru securitate cibernetică și către echipa națională de răspuns.

9 decembrie 2026 — statele membre trebuie să aibă transpusă noua directivă privind răspunderea pentru produsele cu defecte, care include expres software-ul și sistemele AI în noțiunea de produs, pentru produsele introduse pe piață după această dată.

11 decembrie 2027 — se aplică integral cerințele esențiale de securitate cibernetică, evaluarea conformității și documentația tehnică din același regulament.

La acestea se adaugă un element care privește furnizorii de modele, nu firmele care le folosesc, dar care schimbă contextul: din 2 august 2025, furnizorii de modele AI de uz general au obligația, în temeiul articolului 53 alineatul (1) litera (c) din regulamentul european privind inteligența artificială, să pună în aplicare o politică de respectare a legislației Uniunii în materie de drept de autor, inclusiv identificarea rezervei drepturilor exprimate potrivit articolului 4 alineatul (3) din Directiva (UE) 2019/790, plus un rezumat suficient de detaliat despre conținutul folosit la antrenament.

Întrebări frecvente

Î: Clientul poate folosi codul generat, chiar dacă nu e protejat de drept de autor? R: Da. Lipsa protecției nu îl împiedică să ruleze, să modifice sau să livreze mai departe produsul. Problema apare la revânzare, la o operațiune de fuziune sau achiziție și în fața unui concurent care copiază: acolo, un activ neprotejat valorează altfel decât unul protejat, iar cumpărătorii serioși întreabă.

Î: Dacă am filtrul de duplicate activat, sunt acoperit? R: Filtrul reduce riscul, dar nu e o garanție și, pentru produsele GitHub, nu mai este o condiție a angajamentului de apărare începând cu 3 aprilie 2026. Acoperirea contractuală depinde de acordul tău concret cu furnizorul și de măsurile obligatorii în vigoare la data generării codului. Verifică-le acolo, nu într-un articol — inclusiv în acesta.

Î: Trebuie să spun clientului că am folosit AI la dezvoltare? R: Nu există o obligație generală de a declara utilizarea instrumentelor de asistare la scrierea codului. Există însă tot mai des o obligație contractuală, mai ales în achiziții publice și în sectoare reglementate. Verifică fiecare contract-cadru și pregătește un răspuns standard, cu procesul tău de verificare atașat.

Î: Ce fac dacă descopăr că o secvență livrată provine dintr-un proiect cu licență incompatibilă? R: Îl tratezi ca pe un incident: izolezi componenta, evaluezi dacă poate fi înlocuită cu o implementare proprie sau cu o bibliotecă licențiată permisiv, documentezi remedierea și, dacă produsul a fost deja livrat, informezi clientul. Costul unei remedieri timpurii e o fracțiune din cel al unei descoperiri făcute de altcineva.

Î: E mai sigur să interzicem asistenții de cod? R: În practică, interdicția produce utilizare neînregistrată, pe conturi personale, adică exact scenariul cel mai rău: același risc, fără niciun control și fără nicio urmă. Varianta care funcționează e utilizarea declarată, pe conturi de firmă, cu politică, scanare de licențe și review.

Concluzie

Proprietatea asupra codului generat cu AI nu e o întrebare filosofică, ci o consecință directă a două texte: criteriul creației intelectuale proprii a autorului din directiva europeană și regula angajatorului din articolul 74 al legii române. Din ele rezultă un principiu simplu de operare: valoarea juridică a livrabilului tău e proporțională cu aportul uman documentat.

Riscul mai apropiat, însă, nu vine din partea de proprietate, ci din licențe. Acolo nu te ajută nicio interpretare doctrinară, ci trei lucruri banale: scanare automată, review uman cu urmă în istoric și un contract care promite exact ce poți verifica.

Surse

• Legea nr. 8/1996 privind dreptul de autor și drepturile conexe, forma actualizată (art. 72, art. 74): https://legislatie.just.ro/Public/DetaliiDocumentAfis/7816
• Directiva 2009/24/CE privind protecția juridică a programelor pentru calculator (art. 1, art. 2): https://eur-lex.europa.eu/legal-content/RO/TXT/?uri=CELEX:32009L0024
• GitHub Copilot — termeni specifici produsului: https://github.com/customer-terms/github-copilot-product-specific-terms
• GitHub Docs — utilizarea responsabilă a completării de cod și sistemul de detectare a duplicatelor: https://docs.github.com/en/copilot/responsible-use-of-github-copilot-features/responsible-use-of-github-copilot-code-completion
• Microsoft — Customer Copyright Commitment, măsuri obligatorii (actualizat, secțiunea privind produsele GitHub, 3 aprilie 2026): https://learn.microsoft.com/en-us/legal/cognitive-services/openai/customer-copyright-commitment
• Anthropic — termeni comerciali (proprietatea asupra output-urilor): https://www.anthropic.com/legal/commercial-terms
• Regulamentul (UE) 2024/2847 privind reziliența cibernetică — obligațiile de raportare de la 11 septembrie 2026: https://digital-strategy.ec.europa.eu/en/policies/cra-reporting
• Directiva (UE) 2024/2853 privind răspunderea pentru produsele cu defecte: https://eur-lex.europa.eu/legal-content/RO/TXT/?uri=CELEX:32024L2853
• AI Act, articolul 53 — obligațiile furnizorilor de modele de uz general: https://artificialintelligenceact.eu/article/53/
• Actualizări în litigiul privind GitHub Copilot (Statele Unite): https://githubcopilotlitigation.com/case-updates.html

Articol informativ, publicat la 21 august 2026. Nu constituie consultanță juridică. Termenii furnizorilor de instrumente AI se modifică frecvent, iar condițiile contractuale relevante sunt cele în vigoare la data la care a fost generat codul.