Monitorizarea Post-Comercializare conform Regulamentului UE privind IA (Art. 72): Obligații pentru Furnizorii AI de Risc Ridicat

Conformitatea nu se termină la intrarea pe piață. Art. 72 impune furnizorilor de sisteme AI de risc ridicat să mențină un sistem activ de monitorizare post-comercializare, să colecteze date de performanță și să raporteze incidentele grave. Iată ce trebuie să faceți — și când.

Ce Este Monitorizarea Post-Comercializare?

Evaluarea conformității și marcajul CE sunt biletul de intrare pe piața UE pentru un sistem AI de risc ridicat — nu linia de sosire. Articolul 72 al Regulamentului UE privind IA impune o obligație continuă: furnizorii trebuie să înființeze și să opereze un sistem de monitorizare post-comercializare (MPC) care colectează activ, analizează și acționează pe baza datelor de performanță din lumea reală pe tot parcursul duratei operaționale a sistemului.

Rațiunea este simplă. Un sistem AI validat pe un set de date fixat poate deriva pe măsură ce intrările din lumea reală se schimbă, pe măsură ce populația de utilizatori se modifică sau pe măsură ce mediul în care funcționează evoluează. Instantaneele statice de conformitate nu pot surprinde aceasta. MPC este mecanismul care transformă conformitatea dintr-un proces continuu mai degrabă decât un eveniment unic.

Sistemul MPC trebuie să fie proporțional cu natura și riscurile sistemului AI de risc ridicat în cauză. Un model de scorare a creditului implementat la scară în milioane de consumatori va necesita o monitorizare mai intensivă decât un instrument restrâns de clasificare a documentelor utilizat intern de o firmă reglementată.

Cine Trebuie să Înființeze un Sistem MPC?

Obligatoriu pentru:

• Furnizorii de sisteme AI autonome de risc ridicat Anexa III — sisteme enumerate în Anexa III care nu sunt componente de siguranță ale unui produs (de ex., AI utilizat în decizii de angajare, acces la educație, aplicarea legii, evaluarea solvabilității, gestionarea infrastructurii critice)
• Furnizorii de sisteme AI încorporate în produse Anexa I — componente de siguranță AI integrate în produse acoperite de legislația UE existentă de armonizare (dispozitive medicale, utilaje, vehicule)

Nu este necesar pentru:

• Furnizorii de sisteme AI cu risc minim (fără obligație formală MPC, deși se aplică bunele practici)
• Furnizorii de sisteme AI numai cu transparență (obligațiile Art. 50 nu se extind la MPC)
• Furnizorii de modele GPAI — aceștia sunt supuși unui regim separat conform Art. 61–62, care include raportarea incidentelor pentru modelele cu risc sistemic, dar este structurat diferit față de MPC Art. 72

Rolul operatorului este de susținere, dar nu opțional. Operatorii trebuie să opereze sistemul AI în conformitate cu instrucțiunile furnizorului, să activeze și să păstreze funcționalitatea de jurnalizare construită în sistem și — critic — să raporteze orice incidente grave despre care află furnizorului fără întârzieri nejustificate. Un operator care observă un incident grav și nu reușește să notifice furnizorul nu este conform.

Planul de Monitorizare Post-Comercializare (Anexa IV, Punctul 12)

Planul MPC este o componentă obligatorie a documentației tehnice (Anexa IV). Nu poate fi un document generic: trebuie să fie specific sistemului, contextului său de implementare și riscurilor identificate. Cel puțin, trebuie să definească:

1. Colectarea datelor — ce metrici de performanță sunt capturate (acuratețe, rate de erori, rezultatele deciziilor), cum sunt colectate datele (telemetrie automată, rapoarte ale operatorilor, feedback de la utilizatori) și la ce frecvență
2. Bucle de feedback — mecanismul prin care operatorii pot raporta furnizorului probleme de performanță, anomalii sau incidente în mod structurat și la timp
3. Monitorizarea acurateței — modul în care performanța sistemului este urmărită față de benchmark-ul validat utilizat în timpul evaluării conformității, inclusiv orice metodologie de detectare a derivei
4. Monitorizarea prejudecăților — pentru sistemele în care rezultatele demografice sunt materiale (angajare, credit, aplicarea legii), monitorizarea continuă a disparităților statistice în rândul grupurilor protejate, cu metodologie documentată și praguri
5. Factorii declanșatori ai actualizărilor — pragurile cantitative sau calitative specifice care solicită acțiuni corective, inclusiv reantrenarea modelului, ajustarea parametrilor sau suspendarea implementării
6. Programul de revizuire — cât de frecvent este revizuit și actualizat planul MPC în sine, asigurând că rămâne adecvat scopului pe măsură ce contextul de implementare evoluează

Planul MPC trebuie menținut actualizat. Un plan depășit care nu mai reflectă metodologia reală de monitorizare nu satisface Art. 72.

Raportarea Incidentelor Grave (Art. 73)

Ce constituie un incident grav?

Articolul 73 definește un incident grav ca orice incident sau defecțiune a unui sistem AI de risc ridicat care conduce direct sau indirect la:

• Deces sau vătămare gravă a sănătății (fizică sau psihologică)
• O perturbație gravă și ireversibilă a gestionării sau operării infrastructurii critice
• O încălcare gravă a drepturilor fundamentale (confidențialitate, nediscriminare, proces echitabil)
• O situație în care o persoană a evitat la limită oricare dintre cele de mai sus

Important, Regulamentul privind IA nu necesită stabilirea unei legături cauzale cu sistemul AI înainte de raportare. O suspiciune rezonabilă că sistemul AI a contribuit la sau nu a reușit să prevină prejudiciul este suficientă pentru a declanșa obligația. Furnizorii care așteaptă certitudinea înainte de raportare riscă neconformitatea.

Termenele de raportare

Ceasul de 15 zile pornește când furnizorul devine conștient de incident — ceea ce, în practică, înseamnă când operatorul îi notifică. Furnizorii ar trebui să proiecteze procedurile de notificare a operatorilor astfel încât informațiile să le parvină suficient de rapid pentru a respecta termenul-limită de raportare din aval.

Ce trebuie să conțină un raport de incident

Un raport de incident conform adresat autorității naționale de supraveghere a pieței ar trebui să includă:

• Identificarea sistemului: nume, versiune, număr de înregistrare în baza de date UE
• Descrierea incidentului: ce s-a întâmplat, ce prejudiciu a apărut sau a fost la limită evitat, data și locul
• Persoane afectate: numărul și categoriile de utilizatori afectați sau terți (anonimizat unde este necesar conform GDPR)
• Analiza cauzală preliminară: înțelegerea curentă a furnizorului despre cum a apărut incidentul, clar etichetată ca preliminară
• Măsuri corective sau de siguranță imediate luate: orice pași deja luați pentru a limita prejudiciul sau riscul suplimentar (de ex., suspendarea funcționalității afectate, notificările operatorilor)
• Punct de contact: persoana sau echipa responsabilă pentru corespondența ulterioară cu autoritatea

Raportul ar trebui să fie factual și proporțional. Rapoartele preliminare pot fi completate de rapoarte de urmărire pe măsură ce investigația avansează.

Jurnalizare Obligatorie (Art. 12)

Articolul 12 impune ca sistemele AI de risc ridicat să fie proiectate și construite cu capacitatea de a genera automat jurnale la un nivel de granularitate suficient pentru a permite:

• Monitorizarea post-comercializare în conformitate cu Art. 72
• Urmărirea evenimentelor care au condus la un incident grav
• Investigarea de autoritățile naționale

Aceasta este o cerință de proiectare impusă furnizorului. Furnizorul trebuie să construiască capacitatea de jurnalizare în sistem înainte de plasarea pe piață.

Obligația de a activa și păstra acele jurnale revine operatorului. Operatorii nu trebuie să dezactiveze funcționalitatea de jurnalizare și trebuie să păstreze jurnalele pentru perioada specificată în instrucțiunile furnizorului și documentația tehnică. Acolo unde nu este definită o perioadă specifică de retenție, jurnalele ar trebui păstrate pentru o perioadă corespunzătoare cu ciclul de viață operațional al sistemului și orice cerințe sectoriale specifice aplicabile (de ex., reguli de păstrare a evidențelor pentru servicii financiare conform DORA sau MiFID II).

Modificări Substanțiale și Reevaluare

Nu orice modificare a unui sistem AI implementat declanșează o nouă evaluare a conformității. Regulamentul distinge între actualizările minore și modificările substanțiale.

O modificare este substanțială — și necesită o nouă evaluare a conformității și documentație tehnică actualizată — când:

• Modifică scopul intenționat al sistemului (chiar parțial)
• Implică o modificare semnificativă a arhitecturii sau metodologiei de antrenare
• Utilizează date de antrenare noi care afectează material performanța sistemului în moduri care ar putea afecta comportamentul relevant pentru conformitate
• Degradează performanța dincolo de pragurile definite în documentația de gestionare a riscurilor în moduri care afectează siguranța sau drepturile fundamentale

Actualizările minore — patch-uri de securitate, corecții de erori care remediază defecte clar identificate fără a modifica comportamentul relevant pentru conformitate, modificări cosmetice ale interfeței — nu necesită o reevaluare completă. Cu toate acestea, acestea trebuie documentate, iar furnizorul trebuie să păstreze o evaluare scrisă care confirmă că modificarea nu constituie o modificare substanțială. Acel evidență este supusă inspecției de autoritățile de supraveghere a pieței.

Lista de Verificare Practică pentru Implementare

Următoarea listă de verificare reflectă cerințele operaționale minime conform Art. 72, Art. 73 și Art. 12. Nu este un substitut pentru consultanța juridică, dar oferă un punct de plecare pentru analiza lacunelor.

• [ ] Planul MPC documentat în dosarul tehnic (Anexa IV, punctul 12), specific sistemului și contextului său de implementare
• [ ] Capacitate de jurnalizare automată proiectată și construită în sistem înainte de plasarea pe piață
• [ ] Instrucțiunile operatorului includ o procedură clară, scrisă de raportare a incidentelor cu contact de escaladare
• [ ] Punct de contact intern pentru raportarea incidentelor înființat și notificat autorității naționale relevante de supraveghere a pieței
• [ ] Procese sau tablouri de bord de monitorizare a prejudecăților și acurateței definite, cu metodologie documentată și praguri
• [ ] Praguri de escaladare pentru acțiuni corective documentate și legate de sistemul de gestionare a riscurilor
• [ ] Procedura de evaluare a modificărilor substanțiale în vigoare, cu un șablon de evidență a deciziei pentru fiecare actualizare
• [ ] Politica de retenție a jurnalelor definită, comunicată operatorilor și aliniată cu regulile de retenție specifice sectorului

Referințe încrucișate: Documentația Tehnică — Sisteme AI de Risc Ridicat Anexa III — Furnizori față de Operatori