Directiva 2024/2853: răspunderea pentru software și AI defecte

De la 9 decembrie 2026, software-ul intră explicit în regimul european al răspunderii pentru produse defecte. Directiva (UE) 2024/2853 spune că „produs” înseamnă și software, deci o aplicație, un firmware sau un sistem AI care vatămă o persoană ori îi distruge datele poate angaja răspunderea producătorului fără să se dovedească vreo culpă. Mai jos: regulile, articol cu articol, ce se schimbă pentru cine scrie, integrează sau vinde software și AI și ce pregătești în cele opt săptămâni rămase.

Informare generală, nu consultanță juridică. Articolul rezumă textul directivei publicat în Jurnalul Oficial și stadiul public al transpunerii la 14 octombrie 2026. Încadrarea unui produs anume o face un avocat care cunoaște faptele și, când va exista, legea română de transpunere.

Directiva 2024/2853: de la ce dată și pentru ce produse

Directiva (UE) 2024/2853 privind răspunderea pentru produsele cu defecte a fost adoptată la 23 octombrie 2024, publicată în Jurnalul Oficial, seria L, la 18 noiembrie 2024 și a intrat în vigoare în a douăzecea zi de la publicare, la 8 decembrie 2024 (art. 23). Textul în limba română e pe EUR-Lex; trimiterile de mai jos sunt la articolele și considerentele lui.

• Transpunerea: statele membre pun în vigoare actele naționale până la 9 decembrie 2026 (art. 22 alin. (1)).
• Aplicarea în timp: directiva se aplică produselor introduse pe piață sau puse în funcțiune după 9 decembrie 2026 (art. 2 alin. (1)).
• Abrogarea: Directiva 85/374/CEE se abrogă de la 9 decembrie 2026, dar se aplică în continuare produselor introduse pe piață sau puse în funcțiune înainte de această dată (art. 21).

Câțiva ani vor funcționa deci două regimuri. În România, regimul vechi e Legea nr. 240/2004 privind răspunderea producătorilor pentru pagubele generate de produsele cu defecte, republicată, care a transpus Directiva 85/374/CEE. Excepția de urmărit sunt modificările substanțiale: când o modificare substanțială se face printr-o actualizare de software sau prin învățarea continuă a unui sistem AI, produsul modificat se consideră pus la dispoziție pe piață sau în funcțiune în momentul modificării (considerentul 40). Cum se aplică asta unui produs lansat înainte de 9 decembrie 2026 și modificat după e o întrebare pentru juristul care cunoaște produsul.

Directiva e de armonizare maximă: în lipsa unei prevederi contrare, statele nu pot păstra sau introduce reguli diferite, nici mai stricte, nici mai permisive (art. 3). Conținutul viitoarei legi românești e, așadar, previzibil.

Software-ul și sistemele AI devin „produse”

„Produs” înseamnă orice bun mobil, chiar integrat într-un alt bun sau interconectat cu acesta, și include expres software-ul (art. 4 pct. 1). Considerentul 13 dă exemplele, sistemele de operare, firmware-ul, programele, aplicațiile și sistemele de IA, și închide discuția despre livrare: software-ul e produs indiferent dacă e stocat pe un dispozitiv, accesat prin rețea ori prin cloud sau furnizat ca software ca serviciu. Tot acolo scrie că dezvoltatorii de software, inclusiv furnizorii de sisteme de IA în sensul AI Act, sunt producători.

Excepția pentru open-source are margini clare. Dezvoltarea, contribuția și publicarea în depozite deschise nu înseamnă introducere pe piață, în afara unei activități comerciale, dar software-ul furnizat contra cost sau în schimbul datelor personale folosite altfel decât exclusiv pentru securitate, compatibilitate ori interoperabilitate intră sub directivă (considerentul 14). Practic, fiecare dependință open-source din produsul tău devine, la capitolul răspundere, problema ta. Licențele și proprietatea asupra codului sunt alt subiect, tratat în ghidul despre codul generat cu AI.

Pentru dezvoltarea la comandă contează cine lansează produsul și sub ce nume. Cine dezvoltă software-ul intră în definiția producătorului (art. 4 pct. 10 lit. a)), la fel clientul care îl comandă și îl lansează sub marca lui (lit. b)). Un producător se exonerează însă dacă dovedește că nu a introdus produsul pe piață și nu l-a pus în funcțiune (art. 11 alin. (1) lit. a)). Diferența dintre a vinde servicii și a vinde produse, privită din ofertă, e discutată în ghidul despre serviciile AI ale firmelor de software.

Când e defect un software: factorii din articolul 7

Un produs e defect când nu oferă siguranța la care o persoană are dreptul să se aștepte sau care e prevăzută de dreptul Uniunii ori de dreptul intern (art. 7 alin. (1)). Noutatea e lista circumstanțelor de care ține seama instanța (art. 7 alin. (2)). Pentru software și AI contează mai ales cinci:

Considerentul 32 e explicit: producătorul unui produs capabil să dezvolte un comportament neașteptat răspunde în continuare pentru comportamentul care cauzează prejudicii, iar un produs poate fi defect din cauza unei vulnerabilități de securitate cibernetică. Contrapunctul e art. 7 alin. (3): un produs nu e defect doar pentru că ulterior a apărut unul mai bun, inclusiv o actualizare a lui.

Securitatea intră deci direct în aprecierea defectului, nu doar în conformitate. Ce înseamnă concret pentru un sistem AI, de la modelarea amenințărilor la atacurile pe lanțul de aprovizionare și testarea prin red teaming, e lucrat pas cu pas în cursul AI Security și Ethical Engineering.

Legătura cu AI Act și cu Cyber Resilience Act

Directiva nu numește regulamentul privind reziliența cibernetică și pomenește AI Act doar ca să spună că furnizorii de sisteme de IA sunt producători. Legătura trece prin art. 7 alin. (2) lit. (f), care face din cerințele de securitate cibernetică un factor de apreciere, și prin art. 10 alin. (2) lit. (b), care prezumă defectul când produsul nu respectă cerințele obligatorii de siguranță din dreptul Uniunii sau din dreptul intern.

• AI Act (Regulamentul (UE) 2024/1689). Art. 15 cere sistemelor cu grad ridicat de risc acuratețe, robustețe și securitate cibernetică pe tot ciclul de viață, iar celor care continuă să învețe după lansare, măsuri împotriva buclelor de feedback (alin. (4)), exact comportamentul vizat de art. 7 alin. (2) lit. (c) din directivă. Obligațiile pentru sistemele cu grad ridicat de risc au fost amânate prin Regulamentul (UE) 2026/1744, până la 2 decembrie 2027 (anexa III) și 2 august 2028 (anexa I).
• Cyber Resilience Act (Regulamentul (UE) 2024/2847). Impune cerințe esențiale de securitate cibernetică (art. 13 alin. (1), anexa I) și o perioadă de asistență de cel puțin cinci ani, mai scurtă doar pentru produsele folosite, previzibil, mai puțin timp (art. 13 alin. (8)). Se aplică de la 11 decembrie 2027, iar raportarea vulnerabilităților exploatate activ, de la 11 septembrie 2026 (art. 71). Considerentul 31 al CRA spune că directiva privind produsele cu defecte îi este complementară și că lipsa actualizărilor de securitate care provoacă un prejudiciu poate angaja răspunderea producătorului. Raportarea e detaliată în ghidul despre Cyber Resilience Act.

Dacă o cerință anume din aceste regulamente declanșează prezumția de la art. 10 alin. (2) lit. (b) vor tranșa instanțele, caz cu caz. Direcția e însă clară: documentația de conformitate de azi e apărarea de mâine.

Controlul producătorului: actualizările te țin în răspundere

„Controlul producătorului” e un concept nou (art. 4 pct. 5). Produsul e sub controlul tău când efectuezi, autorizezi sau aprobi integrarea unei componente, inclusiv actualizări de software, ori modificarea produsului (lit. a)) sau când ai capacitatea de a furniza actualizări, direct sau printr-un terț (lit. b)). Cât timp păstrezi această capacitate, produsul rămâne sub controlul tău (considerentul 19). Simpla posibilitate tehnică de integrare sau recomandarea unor mărci nu înseamnă însă acord (considerentul 18).

Consecința e la art. 11. În mod obișnuit, un operator se exonerează dacă dovedește că defectul probabil nu exista la lansare (alin. (1) lit. (c)). Pentru software, apărarea e blocată dacă defectul vine, sub controlul producătorului, dintr-un serviciu conex, din software, inclusiv actualizări, din neefectuarea actualizărilor necesare menținerii siguranței sau dintr-o modificare substanțială (alin. (2)).

Două limite, din considerentul 51: răspunderea pentru lipsa actualizărilor nu se aplică dacă instalarea nu poate fi controlată de producător, de exemplu când proprietarul nu instalează actualizarea, iar directiva nu impune, ea însăși, obligația de a livra actualizări. Răspunderea poate fi și limitată sau exclusă când prejudiciul e cauzat și din vina persoanei prejudiciate (art. 13 alin. (2)), inclusiv când aceasta, din neglijență, nu instalează actualizarea primită (considerentul 55).

Apărarea bazată pe stadiul cunoștințelor științifice și tehnice rămâne (art. 11 alin. (1) lit. (e)), dar se judecă la lansare „sau în perioada în care produsul s-a aflat sub controlul producătorului”. La software, fereastra se întinde pe toată perioada în care livrezi actualizări. Statele pot deroga de la această apărare, în condițiile art. 18.

Modificarea substanțială: când integratorul devine producător

Pentru integratori, textul-cheie e art. 8 alin. (2): cine modifică substanțial un produs în afara controlului producătorului și apoi îl pune la dispoziție pe piață sau în funcțiune e considerat producător.

Dacă normele de siguranță aplicabile nu fixează un prag, modificarea e substanțială când, cumulativ, schimbă performanța, scopul sau tipul inițial al produsului fără ca schimbarea să fi fost prevăzută în evaluarea inițială a riscurilor și schimbă natura pericolului, creează un pericol nou sau crește riscul (art. 4 pct. 18).

Întrebări de pus la fiecare lansare (scenariu ilustrativ, nu încadrare juridică): ajustezi un model pe date noi și îl folosești într-un context neevaluat de furnizorul inițial? Treci un sistem de la recomandare la decizie automată? Elimini o protecție a produsului original? Fiecare „da” cere o analiză documentată.

Consecințele: cel care modifică se exonerează dacă defectul ține de o parte neafectată de modificare (art. 11 alin. (1) lit. (g)); termenul de 10 ani curge din nou de la punerea la dispoziție după modificare (art. 17 alin. (1) lit. (b)); iar producătorul inițial care face el modificarea nu se poate apăra spunând că defectul a apărut după lansare (art. 11 alin. (2) lit. (d), considerentul 39). AI Act are propriul test pentru momentul în care un distribuitor, importator, implementator sau alt terț devine furnizor al unui sistem cu grad ridicat de risc (art. 25); cele două teste nu coincid automat.

Cine răspunde: lanțul operatorilor economici

Art. 8 numește operatorii răspunzători:

• producătorul produsului, care răspunde și pentru componentele defecte integrate sub controlul său (alin. (1) lit. (a));
• producătorul componentei defecte, integrate sub controlul producătorului, care a cauzat defectul produsului (lit. (b));
• pentru producătorii din afara Uniunii: importatorul, reprezentantul autorizat și, dacă niciunul nu e stabilit în Uniune, furnizorul de servicii de logistică (lit. (c));
• subsidiar, distribuitorul care nu indică, în termen de o lună de la cerere, un operator din Uniune sau pe cel care i-a furnizat produsul (alin. (3)) și, în aceleași condiții, platforma online care intermediază contracte la distanță cu consumatorii, sub rezerva art. 6 alin. (3) din Regulamentul (UE) 2022/2065 (alin. (4)).

Versiunea română folosește „furnizor de servicii de logistică” pentru cine oferă cel puțin două dintre depozitare, ambalare, adresare și expediere, fără să fie proprietarul produsului (art. 4 pct. 13); în unele comentarii apare ca „prestator de servicii de executare a comenzilor”.

Operatorii răspunzători pentru același prejudiciu pot răspunde solidar (art. 12 alin. (1)), iar cel care plătește are acțiune în regres după dreptul intern (art. 14). Răspunderea nu scade pentru că a contribuit și un terț (art. 13 alin. (1)); considerentul 55 dă exemplul terțului care exploatează o vulnerabilitate a produsului. Atacatorul nu te scoate din răspundere. Excepția negociabilă: integratorul poate renunța prin contract la regresul împotriva unei microîntreprinderi sau întreprinderi mici care i-a furnizat componenta software (art. 12 alin. (2)), fără ca asta să limiteze răspunderea față de victimă (considerentul 54).

Cine poate cere despăgubiri și pentru ce

Directiva protejează persoanele fizice (art. 1, art. 5 alin. (1)); cererea o pot introduce și cei subrogați în drepturile lor sau cei care acționează în numele lor (art. 5 alin. (2)). O firmă nu cere în temeiul directivei despăgubiri pentru propriul prejudiciu; căile contractuale și extracontractuale din dreptul intern rămân (art. 2 alin. (4) lit. (b)).

Prejudiciile acoperite (art. 6 alin. (1)):

• decesul sau vătămarea corporală, inclusiv vătămarea psihologică recunoscută medical;
• deteriorarea sau distrugerea bunurilor, cu excepția produsului defect însuși, a produsului deteriorat de o componentă integrată de producătorul lui sau sub controlul său și a bunurilor folosite exclusiv în scopuri profesionale;
• distrugerea sau coruperea datelor care nu sunt utilizate în scopuri profesionale.

Se despăgubesc toate pierderile materiale rezultate și, în măsura în care dreptul intern o permite, cele nemateriale (art. 6 alin. (2)). Pentru software, a treia categorie e cea nouă: considerentul 20 include costul recuperării datelor, precizează că nu există automat pierdere când datele se recuperează fără cost, de exemplu dintr-o copie de rezervă, și separă situația de scurgerile de date, care rămân sub GDPR. Datele folosite profesional, chiar neexclusiv, sunt excluse (considerentul 22).

Pentru un produs B2B, expunerea nu dispare, se mută: un sistem vândut unei firme poate vătăma fizic un angajat sau un client al ei, iar o aplicație de consum care corupe fișierele personale ale unui utilizator intră direct la art. 6 alin. (1) lit. (c).

Probele și prezumțiile: documentația devine probă

Reclamantul dovedește defectul, prejudiciul și cauzalitatea (art. 10 alin. (1)), dar are două pârghii noi.

Divulgarea probelor (art. 9). Dacă cererea e plauzibilă, pârâtul poate fi obligat să divulge probele relevante de care dispune (alin. (1)), în limita a ce e necesar și proporțional (alin. (3)), cu protecția secretelor comerciale (alin. (4) și (5)) și, la cererea instanței, într-o formă ușor accesibilă și ușor de înțeles (alin. (6)). Considerentul 42 include documentele pe care pârâtul trebuie să le creeze compilând sau clasificând probele existente.

Prezumțiile (art. 10). Defectul se prezumă dacă pârâtul nu divulgă probele cerute, dacă produsul încalcă cerințe obligatorii de siguranță menite să protejeze de riscul respectiv sau dacă prejudiciul vine dintr-o funcționare defectuoasă evidentă, în utilizare previzibilă (alin. (2)). Cauzalitatea se prezumă când prejudiciul e de natura celor corelate obișnuit cu defectul (alin. (3)). Pentru AI contează alin. (4): la dificultăți excesive, de exemplu din cauza complexității tehnice, instanța prezumă defectul sau cauzalitatea dacă reclamantul arată că sunt probabile. Considerentul 48 dă exemplul învățării automate și spune că reclamantul nu trebuie să explice caracteristicile sistemului de IA. Toate prezumțiile pot fi răsturnate (alin. (5)).

Concluzia tehnică: jurnalele, rezultatele testelor, evaluările de risc și istoricul versiunilor sunt probele tale. Dacă refuzi să le divulgi, defectul se prezumă; dacă nu le ai, nu ai cu ce răsturna prezumțiile.

Termenele: 3, 10 și 25 de ani

Pentru o echipă de produs, acesta e orizontul de păstrare a dovezilor; fiecare modificare substanțială pornește un ceas nou.

Contractul nu te scoate din răspundere

Răspunderea în temeiul directivei nu poate fi limitată sau exclusă, față de persoana prejudiciată, prin contract sau prin dreptul intern (art. 15); considerentul 56 exclude și plafoanele financiare stabilite prin lege. Plafonul din termenii și condițiile tale nu se opune, deci, unei persoane fizice care cere despăgubiri. Contractele dintre operatori rămân utile pentru altceva: împart costul final prin regres (art. 14), despăgubiri reciproce și obligații de cooperare, iar răspunderea contractuală obișnuită față de clientul tău rămâne neatinsă (art. 2 alin. (4) lit. (b)). Negocierea plafoanelor și a garanțiilor privind folosirea AI e tratată în ghidul despre clauzele AI din contractele software.

Ce s-a întâmplat cu directiva privind răspunderea pentru AI

Propunerea de directivă privind adaptarea normelor de răspundere civilă extracontractuală la inteligența artificială, COM(2022)496, procedura 2022/0303(COD), a fost retrasă. Retragerea a fost aprobată în reuniunea Comisiei din 16 iulie 2025 și publicată în Jurnalul Oficial, seria C, la 6 octombrie 2025 (C/2025/5423), cu trimitere la motivele din anexa IV a programului de lucru COM(2025)45 din 11 februarie 2025. La nivelul Uniunii nu există, deci, un regim separat de răspundere pentru AI: rămân directiva privind produsele cu defecte, cu răspundere obiectivă, și regulile naționale de răspundere civilă.

Stadiul transpunerii în România la 14 octombrie 2026

Nu am găsit un proiect de act normativ publicat oficial. Documentele publice arată:

• Planul anual de transpunere pentru 2026 al Ministerului Afacerilor Externe (anexă din 23 septembrie 2025): instituția competentă era încă în curs de stabilire între ANPC, Ministerul Justiției, Ministerul Economiei și ADR; ANPC și Ministerul Justiției declinaseră competența, iar la actul și calendarul de transpunere scria „Evaluare în curs. Nu au fost comunicate informații.”
• Raportul MAE din februarie 2026 trece directiva la „Proces de transpunere în curs”.
• La 14 octombrie 2026, căutările noastre pe site-urile Guvernului, Ministerului Economiei, ANPC, Ministerului Justiției, Camerei Deputaților și Senatului nu au găsit un proiect de lege sau de ordonanță de transpunere.

Ce înseamnă, formulat prudent:

• Până la transpunere se aplică Legea nr. 240/2004, care transpune Directiva 85/374/CEE (art. 16 din lege) și nu menționează software-ul.
• Directiva se adresează statelor membre (art. 24). Potrivit jurisprudenței constante a Curții de Justiție a UE, o directivă netranspusă nu creează, prin ea însăși, obligații în sarcina particularilor, deci nu poate fi invocată ca atare împotriva unei firme într-un litigiu între particulari.
• Instanțele sunt însă obligate să interpreteze dreptul intern, în măsura posibilului, în lumina textului și a scopului directivei, fără a ajunge la o interpretare contrară legii.
• Pentru produsele lansate după 9 decembrie 2026 fără lege de transpunere, situația e incertă; un caz concret îl analizează avocatul.

Ipoteza prudentă de planificare: regulile vor ajunge în legea română foarte aproape de text, pentru că directiva e de armonizare maximă (art. 3), iar produsele software se vând de regulă și în alte state membre, care o transpun după propriul calendar.

Lista de pregătire înainte de 9 decembrie 2026

Pregătirea tehnică

1. Inventarul lansărilor. Pentru fiecare produs, data verificabilă a introducerii pe piață, înainte sau după 9 decembrie 2026 (art. 2 alin. (1), art. 21).
2. Harta controlului. Canalele de actualizare (OTA, actualizare automată, implementare SaaS), componentele terțe aprobate și serviciile conexe (art. 4 pct. 5).
3. Politica scrisă de actualizări de securitate. Durata suportului, prioritizarea, dovada livrării și anunțarea utilizatorilor; perioada de asistență din CRA e un reper firesc (art. 11 alin. (2) lit. (c); art. 13 alin. (8) din CRA).
4. Procedura pentru modificări substanțiale. O verificare la fiecare lansare majoră, reantrenare sau ajustare de model, cu concluzia arhivată lângă versiune (art. 4 pct. 18).
5. Monitorizarea comportamentului de după lansare. Pentru sistemele care învață: ce urmărești și ce praguri declanșează revenirea la versiunea anterioară (art. 7 alin. (2) lit. (c)). Tehnicile de testare și monitorizare pentru sisteme AI sunt în AI Security și Ethical Engineering.
6. Inventarul componentelor (SBOM). Inclusiv open-source și modele terțe (considerentul 15); CRA cere deja diligență la integrarea componentelor terțe (art. 13 alin. (5) din CRA).
7. Jurnalizarea și păstrarea probelor. Loguri, teste, evaluări de risc și versiuni, păstrate pe orizontul de la art. 17 și exportabile într-o formă ușor de înțeles (art. 9 alin. (6)).
8. Prezentarea și instrucțiunile. Documentația și mesajele din interfață fixează așteptarea legitimă de siguranță (art. 7 alin. (2) lit. (a)); marketingul nu promite mai mult decât face produsul.
9. Rechemarea sau dezactivarea. Cum oprești o funcție periculoasă și cum anunți utilizatorii (art. 7 alin. (2) lit. (g)).
10. Copiile de rezervă pentru datele utilizatorilor. Ele limitează prejudiciul prin coruperea datelor (art. 6 alin. (1) lit. (c), considerentul 20).

Pregătirea contractuală

1. Termenii și condițiile, recitiți cu art. 15 în față: clauzele de excludere nu operează față de persoana prejudiciată.
2. Furnizorii de componente, inclusiv de modele AI: regres și despăgubiri (art. 14), cooperare la divulgarea probelor, acces la documentația tehnică, notificarea vulnerabilităților.
3. Clienții care integrează sau modifică produsul: cine autorizează actualizările și componentele (art. 4 pct. 5), ce modificări sunt permise și cine devine producător dacă le face (art. 8 alin. (2)).
4. Renunțarea la regres, pentru firmele mici: o microîntreprindere sau întreprindere mică ce furnizează o componentă software o poate negocia (art. 12 alin. (2)); fără clauză expresă, regresul rămâne.
5. Producătorii din afara UE: cine e importatorul sau reprezentantul autorizat în Uniune (art. 8 alin. (1) lit. (c)).
6. Asigurarea: verifică cu brokerul dacă polița de răspundere pentru produse acoperă software-ul și sistemele AI și prejudiciile prin coruperea datelor.
7. Lansările din preajma datei de 9 decembrie 2026: stabilește cu juristul cum le tratezi și cum documentezi momentul introducerii pe piață.

Pentru juriștii interni care inventariază contractele, analiza asistată de AI, cu identificarea riscurilor și a clauzelor problematice, e tratată în cursul AI pentru Avocați și Juriști; verificarea finală rămâne a juristului.

Întrebări frecvente

Directiva 2024/2853 se aplică și aplicațiilor SaaS? Da. Considerentul 13 spune că software-ul e produs indiferent de modul de furnizare, inclusiv prin cloud sau ca software ca serviciu. Serviciile ca atare nu intră, dar serviciile digitale conexe fără de care produsul nu funcționează sunt tratate drept componente (art. 4 pct. 3 și 4).

Răspund pentru o bibliotecă open-source inclusă în produsul meu? Directiva nu se aplică software-ului liber și open-source furnizat în afara unei activități comerciale (art. 2 alin. (2)). Dacă îl integrezi într-un produs pe care îl vinzi, poți răspunde tu, ca producător, pentru defectul lui, nu autorul bibliotecii (considerentul 15).

Pot limita răspunderea prin termeni și condiții? Nu față de persoana prejudiciată (art. 15). Între operatori poți negocia regresul și despăgubirile, iar firmele mici care furnizează componente software pot obține renunțarea la regres (art. 12 alin. (2)).

O firmă client poate cere despăgubiri în temeiul directivei? Nu pentru propriul prejudiciu: dreptul aparține persoanelor fizice (art. 5), iar bunurile folosite exclusiv profesional și datele folosite profesional sunt excluse (art. 6 alin. (1)). Firma păstrează căile din dreptul intern (art. 2 alin. (4)).

Ce se întâmplă dacă România nu transpune directiva până la 9 decembrie 2026? Legea nr. 240/2004 rămâne în vigoare, iar o directivă netranspusă nu creează, prin ea însăși, obligații pentru firme în litigiile dintre particulari. Instanțele trebuie însă să interpreteze legea română, în măsura posibilului, în lumina directivei.

Concluzie

Directiva 2024/2853 mută software-ul și sistemele AI în regimul răspunderii obiective pentru produsele introduse pe piață după 9 decembrie 2026. Software-ul e produs, oricum ar fi livrat. Cât timp controlezi actualizările, defectele apărute după lansare rămân în contul tău. Cine modifică substanțial un produs devine producător. Documentația tehnică devine probă, iar contractul nu limitează răspunderea față de victimă, ci doar împarte costul între parteneri. În România, proiectul de transpunere nu era public la 14 octombrie 2026, dar armonizarea maximă face conținutul previzibil, iar pregătirea tehnică și contractuală nu depinde de data la care apare legea.

Surse și resurse oficiale

• EUR-Lex: Directiva (UE) 2024/2853 privind răspunderea pentru produsele cu defecte (text în limba română)
• EUR-Lex: Retragerea unor propuneri ale Comisiei, JO C/2025/5423 din 6.10.2025
• EUR-Lex: Regulamentul (UE) 2024/1689 privind inteligența artificială
• EUR-Lex: Regulamentul (UE) 2024/2847 privind reziliența cibernetică
• MAE: Planul anual de transpunere a directivelor UE pentru 2026 (anexă, 23.09.2025)
• MAE: Directive cu termen de transpunere în 2026 și 2027 (raport, februarie 2026)

Articol redactat la 14 octombrie 2026. Textul directivei, al regulamentelor privind reziliența cibernetică și inteligența artificială și anunțul de retragere au fost citite în aceeași zi, în versiunea în limba română din Jurnalul Oficial; stadiul transpunerii provine din documentele MAE citate și din căutări publice făcute în aceeași zi. Informare generală, nu consultanță juridică. Cursuri-AI.ro este furnizor de cursuri plătite, deci parte interesată.