AI Act după 2 august 2026: ghid tehnic pentru funcția de conformitate

Ce este aplicabil după 2 august 2026

AI Act nu a început la 2 august 2026. Regulamentul a intrat în vigoare la 1 august 2024, iar obligațiile au fost activate în etape. Interdicțiile și măsurile privind pregătirea persoanelor care folosesc AI se aplică din 2 februarie 2025. Regimul furnizorilor de modele AI de uz general, numite în regulament GPAI, se aplică din 2 august 2025. De la 2 august 2026 se aplică cea mai mare parte a regulamentului, inclusiv articolul 50 privind transparența și regimul sancționator.

Digital Omnibus a mutat termenele pentru cerințele high-risk. Sistemele din anexa III, cum sunt anumite utilizări în recrutare, creditare sau asigurări, intră în regimul special la 2 decembrie 2027. Pentru sistemele integrate în produsele reglementate de anexa I, termenul este 2 august 2028.

Aceste termene trebuie ținute separat în registrul de conformitate. O obligație viitoare nu trebuie prezentată conducerii ca și cum ar fi deja scadentă. Nici nu este prudent ca o achiziție făcută astăzi să blocheze accesul la instrucțiuni, loguri sau informații pe care deployerul va trebui să le aibă la termen.

Mai întâi: este un sistem AI în sensul articolului 3?

Regulamentul definește sistemul AI printr-un ansamblu de elemente: este bazat pe mașină, funcționează cu niveluri variabile de autonomie, poate fi adaptiv după introducerea în utilizare și deduce din datele de intrare cum să genereze predicții, conținut, recomandări sau decizii care pot influența medii fizice ori virtuale. Adaptivitatea este posibilă, nu obligatorie. Elementul distinctiv este capacitatea de inferență.

Nu orice automatizare este AI Act. O formulă fixă într-un tabel, o regulă de validare sau un flux determinist nu intră automat în definiție doar fiindcă furnizorul îi spune AI. Invers, integrarea discretă a unei funcții de clasificare sau recomandare într-o aplicație obișnuită nu o scoate din regulament.

Fișa de inventar trebuie să descrie ce deduce sistemul, ce ieșire produce și unde este folosită acea ieșire. Dacă echipa nu poate răspunde fără prezentarea comercială a furnizorului, calificarea juridică nu este încă matură.

Rolul organizației se stabilește înaintea riscului

AI Act distribuie obligațiile între furnizor, deployer, importator, distribuitor și producătorul unui produs. Într-o achiziție SaaS obișnuită, clientul care folosește sistemul sub propria autoritate este, de regulă, deployer. Furnizorul este entitatea care dezvoltă sau comandă dezvoltarea și introduce sistemul pe piață ori îl pune în funcțiune sub numele său.

Articolul 25 poate schimba însă rolul. Un deployer sau alt terț poate ajunge furnizor al unui sistem high-risk dacă îi aplică propriul nume sau marcă, îi face o modificare substanțială ori îi schimbă scopul prevăzut astfel încât sistemul devine high-risk. Un produs cumpărat pentru sortare administrativă, dar adaptat să decidă cine este exclus din recrutare, nu mai trebuie analizat doar după documentația inițială.

Dosarul de achiziție ar trebui să fixeze versiunea, scopul declarat de furnizor, configurația clientului, datele de intrare, ieșirile și locul rezultatului în proces. Aceste elemente permit identificarea unei modificări substanțiale și arată dacă utilizarea rămâne în limitele instrucțiunilor.

Clasificarea potrivit articolului 6

Există două căi principale către categoria high-risk. Articolul 6 alineatul (1) privește sistemele care sunt produse sau componente de siguranță ale produselor reglementate prin actele din anexa I și supuse evaluării conformității de către un terț. Articolul 6 alineatul (2) trimite la utilizările enumerate în anexa III.

Pentru companii, anexa III apare frecvent în recrutare, selecție, promovare și încetarea raportului de muncă, alocarea sarcinilor pe baza comportamentului, monitorizarea performanței, evaluarea bonității persoanelor și stabilirea riscului sau prețului în asigurările de viață și sănătate.

Articolul 6 alineatul (3) conține un filtru. Un sistem din anexa III poate să nu fie high-risk dacă nu prezintă un risc semnificativ și nu influențează material rezultatul deciziei, de exemplu când execută o sarcină procedurală îngustă sau una pregătitoare. Derogarea nu se aplică sistemelor care realizează profilarea persoanelor. Furnizorul care o invocă trebuie să își documenteze evaluarea.

Deployerul nu ar trebui să reconstituie această concluzie dintr-un răspuns informal al echipei de vânzări. Trebuie să obțină poziția documentată a furnizorului și să verifice dacă utilizarea concretă nu a depășit scopul pe baza căruia a fost făcută evaluarea.

Articolul 5: filtrul care precedă orice matrice de risc

Practicile interzise trebuie verificate înaintea clasificării high-risk. Lista include, în condițiile precise ale articolului 5, tehnici manipulative sau înșelătoare care produc ori pot produce prejudicii semnificative, exploatarea vulnerabilităților legate de vârstă, dizabilitate sau situație socială, social scoring și anumite evaluări ale riscului de comitere a unei infracțiuni bazate exclusiv pe profilare.

Sunt interzise și colectarea nedirecționată de imagini pentru baze de recunoaștere facială, anumite forme de categorizare biometrică și inferarea emoțiilor la locul de muncă sau în educație, cu excepțiile limitate prevăzute pentru motive medicale sau de siguranță. Pentru un angajator, o funcție care pretinde că deduce sinceritatea ori entuziasmul candidatului din voce sau expresia feței este un semnal de oprire.

O practică interzisă nu poate fi remediată printr-o evaluare favorabilă, o clauză contractuală sau acordul persoanei. Procedura internă are nevoie de un test scurt de articol 5 și de autoritatea clară de a opri proiectul.

Articolul 50: transparența care se aplică acum

Articolul 50 nu cere etichetarea fiecărui text la care a contribuit un instrument AI. Obligațiile depind de sistem, conținut și rol. Furnizorii sistemelor destinate interacțiunii directe trebuie să le proiecteze astfel încât persoana să afle că discută cu AI, cu excepția cazului în care acest lucru este evident în context.

Furnizorii sistemelor care generează conținut sintetic trebuie să asigure marcarea într-un format prelucrabil automat și detectabil, în limitele tehnice prevăzute de regulament. Deployerii trebuie să divulge folosirea AI pentru deepfake-uri și pentru anumite texte publicate în scopul informării publicului despre chestiuni de interes public. Pentru text există o excepție atunci când a existat control editorial uman și o persoană fizică sau juridică își asumă răspunderea editorială.

Implementarea se face la nivelul produsului și al fluxului de publicare. Echipa trebuie să știe cine activează mesajul pentru chatbot, cine verifică marcajele tehnice, cine aprobă divulgarea și cum este păstrată dovada. Un paragraf generic în politica AI nu îndeplinește singur aceste obligații.

GPAI nu este sinonim cu orice sistem care folosește un model mare

Capitolul V reglementează furnizorii de modele AI de uz general. Articolul 53 le cere, între altele, documentație tehnică actualizată, informații pentru furnizorii sistemelor care integrează modelul, o politică de respectare a drepturilor de autor și un rezumat public al conținutului folosit la antrenare. Modelele cu risc sistemic au obligații suplimentare.

Un IMM care cumpără acces la un model ori la un asistent construit pe acel model nu devine, doar din acest motiv, furnizor de GPAI. Compania trebuie să distingă trei niveluri: furnizorul modelului, furnizorul aplicației și organizația care folosește aplicația. Fiecare nivel are informații și obligații diferite.

Poziția se poate schimba dacă organizația introduce un model pe piață sub nume propriu, dezvoltă un sistem pe baza lui sau transformă substanțial o soluție high-risk. Contractul cu furnizorul din amonte trebuie să asigure informațiile necesare pentru obligațiile asumate în aval.

Dosarul furnizorului pentru un sistem high-risk

Cerințele din articolele 9 până la 15 privesc gestionarea riscului, guvernanța datelor, documentația tehnică, logurile, transparența față de deployer, supravegherea umană, acuratețea, robustețea și securitatea cibernetică. Articolul 16 le leagă de sistemul de management al calității, evaluarea conformității, declarația UE, marcajul CE, înregistrare și acțiuni corective.

Acesta este dosarul furnizorului. Clientul care rămâne deployer nu trebuie să recreeze proiectarea sistemului și evaluarea de conformitate. Trebuie însă să primească documentația relevantă, să verifice identitatea și rolul furnizorului, scopul prevăzut, declarația și instrucțiunile, apoi să controleze propria utilizare.

În achiziții, întrebarea utilă nu este dacă furnizorul declară produsul conform. Întrebarea este ce document poate transmite, pentru ce versiune, care este clasificarea, ce limitări a testat și cum va notifica o modificare care afectează performanța ori conformitatea.

Obligațiile deployerului potrivit articolului 26

Deployerul unui sistem high-risk trebuie să folosească sistemul potrivit instrucțiunilor și să adopte măsuri tehnice și organizatorice adecvate. Supravegherea se atribuie unor persoane cu competența, instruirea și autoritatea necesare. Dacă deployerul controlează datele de intrare, acestea trebuie să fie relevante și suficient de reprezentative pentru scopul sistemului.

Deployerul monitorizează funcționarea. Dacă are motive să considere că utilizarea conform instrucțiunilor prezintă un risc, informează furnizorul sau distribuitorul și autoritatea de supraveghere a pieței, apoi suspendă utilizarea. Incidentele grave au propriul circuit de notificare. Logurile generate automat se păstrează, dacă se află sub controlul deployerului, pentru o perioadă adecvată și de cel puțin șase luni, în lipsa unei alte norme aplicabile.

Angajatorul informează reprezentanții lucrătorilor și persoanele afectate înaintea utilizării unui sistem high-risk la locul de muncă. Pentru deciziile sau asistența decizională privind persoane, articolul 26 alineatul (11) cere și informarea persoanei supuse utilizării unui sistem high-risk din anexa III.

Aceste obligații au nevoie de suport contractual: instrucțiunile articolului 13, acces la logurile disponibile, notificarea incidentelor și a actualizărilor, asistență pentru monitorizare și condiții clare de suspendare. O garanție generală că produsul este conform nu le înlocuiește.

Supravegherea umană din articolul 14

Articolul 14 cere ca sistemul high-risk să poată fi supravegheat efectiv în timpul utilizării. Măsurile trebuie să fie proporționale cu riscul, autonomia și contextul. Unele sunt construite de furnizor în sistem, altele sunt definite de furnizor și puse în practică de deployer.

Persoana desemnată trebuie să înțeleagă capacitățile și limitele sistemului, să poată detecta anomalii, să interpreteze rezultatul și să rămână atentă la automation bias. Trebuie să poată ignora, modifica sau inversa rezultatul și, unde este necesar, să oprească sistemul în siguranță.

Controlul uman nu este o semnătură adăugată la final. Fișa operațională trebuie să spună ce informații vede evaluatorul, cât timp are, ce prag declanșează revizuirea, cum documentează abaterea de la recomandare și cine poate suspenda sistemul. Dacă nimeni nu poate contrazice ieșirea fără aprobarea furnizorului, supravegherea este mai degrabă declarativă.

FRIA și informarea persoanelor

Evaluarea impactului asupra drepturilor fundamentale din articolul 27, cunoscută drept FRIA, nu este obligatorie pentru orice IMM și pentru orice sistem high-risk. Ea vizează anumite entități publice sau private care prestează servicii publice și anumite utilizări din anexa III, inclusiv evaluarea bonității și riscul sau tarifarea în asigurările de viață și sănătate.

Când se aplică, evaluarea acoperă procesul, perioada și frecvența utilizării, grupurile afectate, prejudiciile previzibile, supravegherea umană, guvernanța internă și mecanismele de reclamație. Trebuie finalizată înainte de utilizare și actualizată când elementele relevante se schimbă.

Articolul 86 prevede, în condițiile sale, un drept la explicații clare și relevante despre rolul sistemului high-risk din anexa III și elementele principale ale deciziei pentru persoana afectată negativ de o decizie cu efect juridic sau similar semnificativ. Procedura de conformitate trebuie să poată reconstrui decizia concretă, nu doar să trimită la descrierea generală a produsului.

Unde se întâlnește, punctual, AI Act cu GDPR

Dacă sistemul prelucrează date cu caracter personal, GDPR se aplică în paralel. Aceasta este o interfață, nu schema de clasificare a AI Act. Temeiul juridic, transparența, minimizarea, perioadele de stocare, DPIA și articolul 22 se analizează separat, în funcție de fluxul de date și efectul deciziei.

AI Act recunoaște legătura fără să confunde instrumentele. Documentația furnizorului trebuie să sprijine, unde este relevant, evaluarea de impact asupra protecției datelor a deployerului. Articolul 27 permite integrarea elementelor FRIA în alte evaluări, dar scopul și concluziile fiecăreia trebuie să rămână identificabile.

Supravegherea umană din articolul 14 nu dovedește automat că o decizie nu este exclusiv automatizată în sensul GDPR. Este un motiv bun ca juridicul și DPO-ul să lucreze pe același flux, nu un motiv să transforme articolul despre AI Act într-o analiză GDPR.

Clauzele pe care trebuie să le ceară achizițiile

Contractul trebuie să identifice rolurile AI Act, sistemul și versiunea, scopul prevăzut, clasificarea, instrucțiunile aplicabile și documentația disponibilă. Pentru un sistem high-risk, clientul are nevoie de informații privind populațiile și condițiile de testare, limitele cunoscute, măsurile de supraveghere, logurile, indicatorii de performanță, acuratețea, robustețea și securitatea cibernetică.

Actualizările care pot schimba comportamentul trebuie anunțate înainte de activare sau controlate printr-un mecanism convenit. Contractul trebuie să acopere notificarea incidentelor, cooperarea cu autoritățile, accesul la informații pentru investigații, auditul proporțional și ieșirea din serviciu.

Articolul 25 cere, în lanțul high-risk, acorduri scrise privind informațiile, capacitățile, accesul tehnic și asistența necesare conformității. Secretul comercial nu poate deveni o formulă prin care clientul este lăsat fără instrucțiunile necesare. Dacă există și o relație de împuternicire GDPR, DPA-ul rămâne un document separat.

Cum arată dosarul de conformitate al deployerului

Dosarul începe cu o fișă pentru fiecare utilizare: proprietarul procesului, sistemul și versiunea, furnizorul, rolul organizației, scopul prevăzut, scopul real, datele de intrare, ieșirea și consecința operațională. Urmează analiza definiției din articolul 3, testul de articol 5 și memoriul de clasificare în baza articolului 6.

Pentru utilizările relevante se adaugă poziția furnizorului față de articolul 6 alineatul (3), instrucțiunile, contractul, dovezile de transparență, procedura de supraveghere, criteriile de acceptanță, logurile, incidentele și circuitul de suspendare. Decizia privind FRIA trebuie consemnată, inclusiv atunci când concluzia este că articolul 27 nu se aplică.

Registrul trebuie să separe controalele aplicabile acum de cele pregătite pentru 2 decembrie 2027 sau 2 august 2028. Astfel, funcția de conformitate poate arăta conducerii ce trebuie oprit, ce trebuie implementat și ce trebuie contractat înaintea termenului.

Testul practic: filtrul de CV-uri

Un furnizor oferă un instrument care extrage competențe din CV-uri, calculează compatibilitatea și afișează recrutorului primii douăzeci de candidați. Ceilalți nu ajung în interfața de lucru. Produsul este vândut drept asistent pentru prioritizare.

Utilizarea se află în zona recrutării din anexa III punctul 4 litera (a). Furnizorul poate analiza filtrul din articolul 6 alineatul (3), dar argumentul unei sarcini doar pregătitoare devine dificil dacă scorul stabilește cine poate fi văzut. Dacă sistemul realizează profilare, derogarea nu este disponibilă. Regimul high-risk relevant se aplică de la 2 decembrie 2027.

Până atunci, compania nu trebuie să simuleze o procedură de evaluare a conformității care aparține furnizorului. Trebuie să obțină clasificarea documentată, să păstreze utilizarea în scopul prevăzut, să elimine orice funcție interzisă, să contracteze accesul necesar și să proiecteze supravegherea reală, logurile și suspendarea. GDPR și dreptul muncii se verifică separat dacă sunt prelucrate datele candidaților.

Dacă recrutorul nu poate vedea candidaturile aflate sub prag, nu cunoaște factorii folosiți și nu poate recupera un candidat exclus greșit, problema nu se repară printr-o politică internă. Fluxul trebuie schimbat sau produsul nu trebuie folosit pentru acea decizie.

Sancțiunile nu înlocuiesc analiza rolului

Articolul 99 stabilește plafoane diferite după încălcare. Practicile interzise pot atrage plafonul cel mai ridicat. Încălcarea obligațiilor furnizorilor, deployerilor sau a articolului 50 are alt plafon, iar informațiile incorecte ori incomplete transmise autorităților au un regim distinct.

Pentru IMM-uri, regulamentul folosește procentul sau suma fixă, oricare este mai mică, iar autoritățile trebuie să țină seama de interesele și viabilitatea economică a IMM-urilor și start-up-urilor. Aceasta nu este o imunitate, dar nici nu susține mesajul comercial că orice greșeală produce automat amenda maximă.

Expunerea se estimează numai după ce sunt stabilite rolul, obligația, data aplicării și fapta concretă. O prezentare care începe și se termină cu 35 de milioane de euro nu este o analiză de conformitate.

Ce trebuie să poată demonstra funcția de conformitate

La finalul analizei, organizația trebuie să poată explica de ce un produs intră sau nu în definiția AI, în ce rol îl folosește, dacă atinge articolul 5 și cum a fost clasificat. Pentru fiecare obligație trebuie să existe un proprietar, un termen și o dovadă, nu doar o politică generală despre utilizarea responsabilă a AI.

La fel de concret trebuie stabilit cine supraveghează sistemul, cine îi poate contrazice rezultatul, cine îl suspendă, ce loguri există și ce se întâmplă după o actualizare. Răspunsurile nu pot rămâne împărțite între contract, prezentarea comercială și memoria unui manager.

Dosarul bun este proporțional cu utilizarea, dar suficient de exact încât un coleg nou, un auditor sau o autoritate să poată reconstrui decizia. Aceasta este munca reală adusă de AI Act în funcția de conformitate.