Când se aplică supravegherea umană și ce trebuie făcut în continuare

Supravegherea umană în temeiul Legii UE privind inteligența artificială se aplică ca o cerință legală specifică sistemelor IA cu risc ridicat. Nu este mulțumit doar pentru că un angajat poate vedea un rezultat sau pentru că o politică spune că o persoană rămâne responsabilă. Furnizorii trebuie să conceapă sisteme cu risc ridicat, astfel încât persoanele fizice să le poată supraveghea în mod eficient, în timp ce angajatorii trebuie să atribuie supravegherea persoanelor cu competența, formarea, autoritatea și sprijinul necesare.

Pentru o echipă SaaS, secvența practică este: clasifică sistemul, identifică dacă compania acționează ca furnizor sau implementator, definește ceea ce poate înțelege și schimba omul, testa calea intervenției și păstrează dovezile. Dacă sistemul nu prezintă un risc ridicat, revizuirea umană poate fi totuși un produs adecvat, siguranța, confidențialitatea sau controlul contractual, dar este diferit de susținerea că se aplică articolul 14.

De ce contează supravegherea umană în practică

Legea AI tratează supravegherea ca pe o modalitate de a preveni sau de a minimiza riscurile la adresa sănătății, siguranței și drepturilor fundamentale care rămân chiar și după ce au fost aplicate alte controale. Articolul 14 spune că măsurile trebuie să fie proporționale cu riscurile sistemului, autonomia și contextul de utilizare. De asemenea, se așteaptă ca persoana desemnată să fie capabilă, acolo unde este cazul, să înțeleagă limitările, să monitorizeze funcționarea, să recunoască părtinirea automatizării, să interpreteze ieșirile, să ignore sau să inverseze o ieșire și să oprească sistemul în siguranță.

Asta face ca supravegherea să fie o capacitate de operare, nu o aprobare ceremonială. Un evaluator care nu are timp, informații despre sistem, acces sau autoritate nu poate oferi o supraveghere semnificativă. Nici o persoană nu poate interveni eficient dacă produsul prezintă o recomandare ca finală, ascunde incertitudinea sau nu oferă nicio modificare utilizabilă.

Acest lucru este strâns legat de așteptările de guvernare AI pentru furnizorii SaaS. Cumpărătorii se întreabă din ce în ce mai mult nu numai dacă un om este „în buclă”, ci și unde are loc intervenția și ce dovezi arată că funcționează.

Când se aplică cerința Actului AI

Începeți cu clasificarea, nu cu o listă de verificare a supravegherii. Conform articolului 6, un sistem poate prezenta un risc ridicat prin două căi principale:

1. Este un produs sau o componentă de siguranță a unui produs, acoperită de legislația UE privind siguranța produselor specificată și supus evaluării conformității de către terți.
2. Scopul său se încadrează într-un caz de utilizare cu risc ridicat din anexa III, sub rezerva filtrului de la articolul 6 alineatul (3) și a excepțiilor acestuia.

Anexa III acoperă utilizări definite în domenii precum biometria, infrastructura critică, educația, ocuparea forței de muncă, accesul la servicii esențiale, aplicarea legii, migrația și administrarea justiției. A fi „alimentat de inteligență artificială”, prelucrarea datelor cu caracter personal sau influențarea unui flux de lucru obișnuit de afaceri nu face automat un sistem un risc ridicat în conformitate cu articolul 6.

Pentru unele sisteme din anexa III, articolul 6 alineatul (3) oferă o posibilă cale de ieșire din clasificarea cu risc ridicat în cazul în care sistemul nu prezintă un risc semnificativ de vătămare și îndeplinește condițiile enumerate – de exemplu, atunci când îndeplinește o sarcină procedurală sau pregătitoare restrânsă. Profilarea persoanelor fizice într-un caz de utilizare din anexa III rămâne cu risc ridicat. Un furnizor care se bazează pe filtru trebuie să documenteze acea evaluare.

Clasificarea depinde în mare măsură de scopul propus și rolul real. O companie SaaS poate fi furnizorul atunci când dezvoltă un sistem sau are unul dezvoltat și îl comercializează sau îl pune în funcțiune sub propriul nume. Poate fi un implementator atunci când folosește sistemul AI al altui furnizor sub autoritatea sa. O companie poate, de asemenea, să creeze obligații ale furnizorului prin modificarea substanțială a unui sistem cu risc ridicat sau prin schimbarea scopului propus într-un mod care să-l facă să prezinte un risc ridicat. Echipele ar trebui să confirme regulile tranzitorii actuale înainte de a trata o obligație viitoare ca fiind deja aplicabilă.

Citiți prezentarea practică a Legii UE AI pentru furnizorii SaaS alături de evaluarea clasificării.

Când articolul 14 nu se aplică

Articolul 14 nu este o regulă universală pentru fiecare chatbot, rezumat, funcție de recomandare, semnal de fraudă sau copilot intern. Dacă un sistem se află în afara domeniului de aplicare al Legii AI, nu este un sistem AI în temeiul Legii sau nu este clasificat ca fiind cu risc ridicat, cerința privind sistemul cu risc ridicat de la articolul 14 nu i se aplică.

Asta nu înseamnă „nu este nevoie de o revizuire umană”. Alte obligații pot apărea în conformitate cu normele privind protecția datelor, consumatorul, angajarea, sectorul specific, siguranța sau contractuale. O evaluare a riscurilor poate arăta, de asemenea, că aprobarea umană este controlul cel mai proporțional chiar și fără un mandat legal specific.

Folosiți un limbaj precis în înregistrări și răspunsuri ale clienților:

• Cerință legală: „Sistemul este cu risc ridicat, iar aceste măsuri pun în aplicare articolele 14 și 26.”
• Controlul riscurilor: „Sistemul nu este în prezent clasificat ca fiind cu risc ridicat, dar o revizuire umană este cerută de politica noastră internă privind riscurile.”
• Întrebare deschisă: „Clasificarea depinde de scopul final prevăzut și de contextul de implementare; lansarea este blocată până când evaluarea este aprobată.”

Această distincție împiedică echipele să exagereze conformitatea și face modificările ulterioare mai ușor de gestionat.

Responsabilitățile furnizorului și distribuitorului

Furnizorii și implementatorii au o activitate conectată, dar diferită.

Furnizori: supravegherea proiectării în sistem

Un furnizor ar trebui să traducă evaluarea riscului în măsuri tehnice și procedurale utilizabile. În funcție de cazul de utilizare, acesta poate include:

• arătarea încrederii relevante, limitări și context de intrare;
• a face vizibile anomaliile si performantele neasteptate;
• împiedicarea interfeței să încurajeze acceptarea oarbă;
• permiterea persoanelor autorizate să ignore, să anuleze, să inverseze sau să întrerupă ieșirile;
• definirea măsurilor de supraveghere pe care trebuie să le implementeze angajatorul; şi
• explicarea acelor măsuri în mod clar în instrucțiunile de utilizare.

Designul trebuie să se potrivească cu condițiile de lucru previzibile. O modificare ascunsă în spatele fluxului de lucru al administratorului poate fi inutilă atunci când un examinator din prima linie trebuie să acționeze imediat.

Deployeri: faceți supravegherea operațională

Articolul 26 impune implementatorilor de sisteme cu risc ridicat să atribuie supravegherea persoanelor fizice cu competența, pregătirea, autoritatea și sprijinul necesare. Implementatorii trebuie să utilizeze sistemul conform instrucțiunilor acestuia, să-i monitorizeze funcționarea, să acționeze în privința riscurilor identificate sau a incidentelor grave și să păstreze jurnalele generate automat sub controlul lor pentru o perioadă adecvată de cel puțin șase luni, cu excepția cazului în care altă lege aplicabilă prevede altfel.

Din punct de vedere operațional, asta înseamnă alegerea unor roluri numite, protejarea timpului de revizuire, controlul accesului, definirea escaladării și verificarea dacă instrucțiunile furnizorului se potrivesc cu implementarea reală. Un angajat nu poate fi responsabil pentru o anulare pe care nu este autorizat să o facă.

Un flux de lucru practic de supraveghere umană

1. Scrieți o înregistrare de clasificare

Înregistrați sistemul, scopul vizat, utilizatorii, persoanele afectate, intrările, ieșirile, impactul deciziei, rolurile furnizorului/deployerului și ruta luată în considerare la articolul 6. Conectați concluzia cu versiunea produsului și contextul de implementare. Reevaluați-l atunci când oricare se schimbă.

2. Hartă decizii și moduri de eșec

Identificați unde rezultatul AI poate afecta o persoană, siguranța, accesul, prioritizarea sau un proces reglementat. Pentru fiecare punct, descrieți erori realiste: o potrivire falsă, o excepție ratată, o clasare părtinitoare, un rezumat înșelător, o recomandare nesigură sau o deviere a performanței.

3. Definiți acțiunea omului, nu doar prezența acestuia

Pentru fiecare decizie materială, specificați:

• ce informații vede recenzentul;
• ce trebuie să verifice în mod independent;
• când trebuie să respingă sau să escaladeze;
• dacă pot întrerupe, anula sau inversează rezultatul;
• cât de repede trebuie să acționeze; şi
• care are autoritatea finală.

Evitați controalele vagi, cum ar fi „un manager revizuiește atunci când este necesar”. Un declanșator și o regulă de decizie fac controlul testabil.

4. Antrenează-te pentru sarcina reală

Instruirea ar trebui să acopere scopul propus al sistemului, limitările cunoscute, semnalele relevante, părtinirea automatizării, utilizările interzise, instrumentele de intervenție, păstrarea înregistrărilor și escaladarea. Confirmați competența prin scenarii, nu doar prezența. Aceasta completează întrebările mai ample pe care echipele ar trebui să le pună înainte de a adopta noi instrumente AI la nivel intern.

5. Testați calea completă

Efectuați exerciții realiste. Poate recenzentul să identifice o ieșire proastă? Au suficient context? Funcționează override? Oprirea sistemului îl lasă într-o stare sigură? Evenimentul este înregistrat? Escaladarea ajunge la cineva care poate acționa?

Înregistrați defectele și retestați după remedieri. O captură de ecran a unui ecran de aprobare se dovedește mult mai puțin decât un scenariu finalizat cu rezultate așteptate și observate.

6. Monitorizați și îmbunătățiți

Urmăriți anulări, inversări, escalade, plângeri, detectări ratate, dezacord ale recenzenților și performanță anormală. Tendințele pot dezvălui o pregătire slabă, o interfață inutilizabilă, intrări modificate sau un sistem care funcționează în afara scopului său aprobat. Definiți praguri care declanșează investigarea, suspendarea sau reevaluarea.

Greșeli frecvente

• Clasificarea după eticheta produsului. Un nume de caracteristică nu determină dacă utilizarea prevăzută este cu risc ridicat.
• Folosirea „uman în buclă” ca întreg control. Prezența fără informații, timp sau autoritate nu este o supraveghere eficientă.
• Revizuirea după consecință este ireversibilă. Punctul de intervenție trebuie să apară în timp ce persoana poate încă modifica rezultatul.
• Lăsarea aceleiași rezultate să se valideze. Verificarea independentă necesită dovezi suplimentare, nu o a doua lectură a explicației AI.
• Ignorarea părtinirii automatizării. Ieșirile precise în mod repetat pot face ca recenzenții să fie mai puțin probabil să conteste eșecul excepțional.
• Lăsarea dreptului de proprietate cu „afacerea”. Numiți un rol responsabil și o rezervă operațională.
• Fără nicio dovadă. Politicile singure nu arată că recenzenții au fost instruiți, că au funcționat anulări sau că problemele au fost escaladate.

Exemplu: selecția candidaților asistată de IA

Să presupunem că un furnizor SaaS oferă software care clasifică candidații la un loc de muncă pentru un angajator. Utilizările IA legate de ocuparea forței de muncă enumerate în anexa III pot fi cu risc ridicat, astfel încât furnizorul ar trebui să completeze și să documenteze evaluarea articolului 6, mai degrabă decât să presupună că un recrutor care face clic pe „aprobă” rezolvă problema.

Supravegherea semnificativă ar putea impune recrutorului să vadă factorii relevanți pentru recomandare, să verifice informațiile sursă, să identifice datele lipsă sau care induc în eroare, să ignore clasamentul, să restabilească un candidat și să intensifice prejudecățile sistematice suspectate. Angajatorul, în calitate de angajator, ar atribui persoane instruite cu autoritate și va monitoriza sistemul în conformitate cu instrucțiunile.

În schimb, un instrument intern care reformatează un e-mail scris de recrutor fără a clasifica candidații sau a influența o decizie de angajare poate să nu se încadreze în acel caz de utilizare cu risc ridicat. Echipa poate să interzică în continuare intrările sensibile și să solicite aprobarea umană înainte de a trimite, dar ar trebui să documenteze acest lucru ca un control intern, mai degrabă decât să îl descrie în mod automat drept conformitate cu articolul 14.

Întrebări frecvente

Care este scopul practic al supravegherii umane?

Scopul său este de a permite oamenilor competenți să înțeleagă, să monitorizeze și să intervină, astfel încât riscurile reziduale pentru sănătate, siguranță sau drepturile fundamentale să poată fi prevenite sau reduse. Fluxul de lucru trebuie să le ofere informații reale, timp, instrumente și autoritate.

Când se aplică supravegherea umană echipelor SaaS?

Atribuțiile specifice AI Act se aplică atunci când echipa furnizează sau implementează un sistem AI cu risc ridicat. Alte sisteme de inteligență artificială pot avea nevoie în continuare de revizuire umană din cauza unei alte legi, contract, evaluare a riscurilor sau politici interne.

Este suficientă o aprobare umană finală?

Nu automat. Aprobarea este semnificativă numai dacă examinatorul poate înțelege limitările relevante, poate detecta probleme, poate contesta rezultatul și poate modifica sau opri rezultatul înainte de a se produce un prejudiciu.

Ce ar trebui să documenteze mai întâi echipele?

Începeți cu înregistrarea de clasificare și scopul propus. Apoi documentați persoanele responsabile, analizați declanșatorii, informațiile afișate, intervențiile permise, calea de escaladare, formarea, rezultatele testelor și dovezile operaționale.

Fiecare decizie AI trebuie verificată de două persoane?

Nu. Articolul 14 include o regulă specifică de verificare pentru două persoane pentru anumite sisteme de identificare biometrică la distanță, cu excepții definite. Nu este o regulă generală pentru toate sistemele AI cu risc ridicat.

Ce să faci acum

Clasificați cazul de utilizare înainte de a promite că „supravegherea umană” îl rezolvă. Dacă sistemul prezintă un risc ridicat, conectați măsurile tehnice ale furnizorului la persoanele, permisiunile și procedurile reale ale implementatorului. Apoi testați calea și păstrați dovezile că un om poate recunoaște problemele și poate acționa la timp.

Aceasta este diferența dintre o persoană din apropierea sistemului și supravegherea umană eficientă.

Surse

• Regulamentul (UE) 2024/1689 (Legea privind inteligența artificială)
• Articolul 6: Reguli de clasificare pentru sistemele AI cu risc ridicat
• Articolul 14: Supravegherea umană
• Articolul 26: Obligațiile implementatorilor de sisteme AI cu risc ridicat