Un sistem cu risc ridicat nu este un model cu risc ridicat

Riscul nu locuiește într-un model ca o etichetă de avertizare. El apare din scopul intenționat, implementare, autoritate, interfețe și oamenii care trebuie...

Un sistem cu risc ridicat nu este un model cu risc ridicat

Eticheta este atașată unei utilizări, nu unui cutii

Un model poate fi copiat de pe un server pe altul fără să învețe nimic. Greutățile, codul și capacitățile sale publicitate pot rămâne neschimbate. Totuși, întrebarea pe care Europa o pune despre lucrul din jurul său se poate schimba complet. Pentru ce este? Cine îl folosește? A cui poziție o poate schimba? Ce înregistrare intră în fluxul de lucru? Cine poate contesta răspunsul, îl poate corecta, îl poate opri sau poate descoperi mai târziu de ce a fost urmat?

Nu este o încercare de a face un subiect simplu mai grandios decât este. Este diferența obișnuită dintre o componentă și un sistem. Un disc de frână nu este un vehicul rutier. O formulă de calcul tabelar nu este o decizie fiscală. Un model AI general nu este, prin el însuși, fiecare sistem AI care poate fi construit ulterior în jurul său. Distincția este ușor de aprobat din cap și remarcabil de ușor de pierdut odată ce o întâlnire de achiziții începe să vorbească despre un model ca și cum acesta ar conține deja întreaga implementare viitoare.

Regulamentul UE privind inteligența artificială menține distincția în vedere. Acesta definește un sistem AI și definește separat un model AI general. Regulile sale privind riscul ridicat se referă la sistemele AI în circumstanțe particulare, inclusiv sisteme care sunt componente de siguranță ale produselor reglementate și sisteme utilizate în domeniile enumerate. Regulamentul face, de asemenea, scopul intenționat central pentru clasificarea și documentarea unui sistem AI. Nu invită o echipă să indice numele unui model, să atașeze o etichetă roșie, galbenă sau verde și să declare munca încheiată.

Aceasta ar trebui să fie eliberatoare, precum și exigentă. Un model nu poartă un horoscop moral permanent. O analiză atentă poate fi restrânsă acolo unde scopul intenționat este restrâns și poate deveni serioasă acolo unde autoritatea, expunerea și consecințele devin serioase. Problema este că analiza trebuie să urmeze sistemul real. Nu demonstrația. Nu prezentarea furnizorului. Nu sarcina inofensivă care a deschis proiectul acum șase luni. Sistemul care va primi intrări, va pune la dispoziție rezultate, va modela o decizie și va fi operat într-o marți obișnuită.

Luați în considerare o ilustrare deliberat ipotetică. Același model de limbaj este conectat mai întâi la un instrument intern de căutare a cunoștințelor. Acesta recuperează pasaje de politică pentru un coleg instruit, care poate deschide sursa originală și își poate scrie propriul răspuns. Mai târziu, o organizație conectează modelul la un formular de primire, oferă recomandării sale un loc în partea de sus a unei înregistrări de caz, aplică un cronometru cazului și face acceptarea recomandării cea mai rapidă modalitate de a goli coada. Nu este nevoie de niciun consiliu, pacient, angajat sau incident fictiv pentru a observa schimbarea. Modelul poate fi identic. Rolul rezultatului, calea datelor, stimulentul, persoana afectată și autoritatea practică a interfeței nu sunt.

Acesta este argumentul articolului: un sistem cu risc ridicat nu este un model cu risc ridicat. Un model poate fi o parte importantă a sistemului și poate avea obligații proprii. Dar analiza riscurilor devine semnificativă doar atunci când ajunge la scopul intenționat, contextul de implementare, utilizatori, persoanele afectate și integrarea ulterioară. Aceste detalii nu sunt documente atașate după inginerie. Ele sunt circumstanțele care conferă unui rezultat forță instituțională.

Plasează cursorul peste un strat sau selectează-l. Modelul este un singur strat; consecința apare doar când straturile se întâlnesc.

Europa folosește în mod deliberat două substantive diferite

Distincția începe în definițiile din regulament. Un sistem de IA este un sistem bazat pe mașini, proiectat să funcționeze cu niveluri variate de autonomie și care poate prezenta adaptivitate după implementare, care inferă din datele de intrare cum să genereze rezultate precum predicții, conținut, recomandări sau decizii ce pot influența medii fizice sau virtuale. Un model de IA cu scop general este diferit: este un model de IA capabil să execute cu competență o gamă largă de sarcini distincte, indiferent dacă este sau nu introdus pe piață, și poate fi integrat într-o varietate de sisteme sau aplicații din aval.

Aceste definiții se suprapun în conversația de zi cu zi, pentru că același cuvânt, IA, face o cantitate mare de muncă neremunerată. Nu ar trebui să se suprapună într-o evaluare. Un model cu scop general este făcut să circule. Posibilele sale utilizări sunt în mod deliberat largi. Un sistem de IA este aranjamentul operațional prin care rezultatele influențează un mediu. Are un scop, o configurație, o interfață și un cadru. Poate include un model, mai multe modele, reguli deterministe, baze de date, senzori, oameni, proceduri și o mulțime de decizii mici pe care nimeni nu le numește inteligență artificială până nu eșuează.

De aceea, un furnizor de model de IA cu scop general și un furnizor sau un implementator de sistem de IA nu pot pur și simplu să facă schimb de liste de verificare. Orientările Comisiei privind modelele de IA cu scop general spun că furnizorii de modele trebuie să pună informații și documentație la dispoziția furnizorilor din aval de sisteme de IA, astfel încât aceștia să poată înțelege capacitățile și limitările modelului și să își îndeplinească propriile obligații. Această propoziție este mai interesantă decât pare la prima vedere. Presupune că furnizorul din aval are o activitate care nu poate fi finalizată de furnizorul de model. Documentația modelului circulă, dar nu parcurge întreaga călătorie.

Există o umilință practică în aceasta. Un furnizor de model poate descrie arhitectura, procesul de instruire, evaluarea, sarcinile preconizate, cerințele de integrare, datele de intrare și de ieșire, limitările și condițiile cunoscute. O echipă din aval știe dacă un utilizator este un specialist instruit, dacă o persoană afectată poate contesta un rezultat, dacă o recomandare este consultativă doar cu numele, dar obligatorie în practică, dacă un apel către un serviciu extern modifică o înregistrare și dacă o acțiune defectuoasă poate fi inversată. Nicio parte nu are o imagine completă de una singură.

Diviziunea nu este o portiță. Este o hartă a responsabilității. Spune că un sistem nu poate fi guvernat cerându-i furnizorului de model să promită control asupra unei implementări pe care nici nu o operează, nici nu o vede. Spune, de asemenea, că un integrator nu poate invoca ignoranța acolo unde documentația face vizibilă o limitare importantă. Scopul nu este de a face o predare curată între entități juridice. Este de a evita pierderea întrebării în golul dintre ele.

Există o a doua distincție care merită păstrată, pe lângă prima. Clasificarea ca risc ridicat nu echivalează în sine cu o permisiune, cu siguranță, echitate sau legalitate. În opinia comună privind propunerea inițială a Comisiei, Comitetul European pentru Protecția Datelor și Autoritatea Europeană pentru Protecția Datelor au subliniat că clasificarea ca risc ridicat nu însemna în mod necesar că un sistem era legal ca atare sau că putea fi implementat ca atare de către utilizatorul său. Actul final a schimbat peisajul juridic de la acea opinie, dar avertismentul de fond rămâne util. Clasificarea este o condiție de reglementare. Nu este o chitanță care să ateste că instituția se poate opri din gândit.

Acest lucru contează pentru că o etichetă de risc ridicat poate produce două erori opuse. O echipă o poate trata ca pe o pată permanentă asupra unui model și poate decide că soluția este pur și simplu să nu mai caute mai departe. Alta poate trata un proces de conformitate finalizat ca pe o permisiune pentru orice context ulterior. Ambele abordări substituie o etichetă unei argumentări. Europa a ales o abordare mai incomodă: identifică sistemul, scopul său și rolul său, apoi examinează riscurile și obligațiile relevante pe parcursul ciclului său de viață.

Scopul preconizat este punctul de reper al analizei

Scopul preconizat sună modest, aproape birocratic. Nu este deloc așa. Actul îl definește ca fiind utilizarea pentru care un sistem de IA este destinat de furnizorul său, inclusiv contextul specific și condițiile de utilizare specificate în informațiile furnizate de furnizor. Cu alte cuvinte, scopul nu este un slogan pe o pagină de produs. Include contextul și condițiile în care furnizorul declară că sistemul urmează să fie utilizat. O declarație utilă de scop are limite clare. Spune ce face sistemul, pentru cine, cu ce intrări, în cadrul cărui flux de lucru și unde se termină autoritatea sa.

Comparați două descrieri. Prima spune că un sistem folosește IA pentru a ajuta organizațiile să ia decizii mai bune. Este suficient de largă pentru a încăpea pe fundalul unei conferințe și prea largă pentru a funcționa. A doua spune că un sistem prezintă rezumate draft cu surse indicate dintr-un dosar existent unor evaluatori instruiți; nu poate lua, transmite sau implementa o decizie; evaluatorul trebuie să verifice sursele citate înainte de a folosi un rezumat; iar funcția nu este disponibilă pentru categorii care necesită un proces statutar separat. A doua descriere este mai puțin captivantă. Este, de asemenea, ceva cu care un inginer, un responsabil de achiziții, un coleg din conformitate și o persoană afectată pot fi în dezacord în termeni concreți.

Scopul nu trebuie să fie o singură propoziție. Într-un sistem serios, este de obicei un pachet compact: sarcină, rezultat, utilizator, populație afectată, mediu, autoritate, excluderi, dependențe și condiții. Cerințele Actului privind documentația tehnică fac loc tocmai unui astfel de raport. Anexa IV solicită o descriere generală a sistemului de IA, inclusiv scopul preconizat, persoanele și grupurile asupra cărora se preconizează utilizarea acestuia și versiunile sau formele specifice în care este introdus pe piață. Solicită, de asemenea, descrieri ale arhitecturii sistemului, cerințelor privind datele, măsurilor de supraveghere umană, monitorizării ciclului de viață și măsurilor de gestionare a riscurilor. Documentația are această amploare pentru că o singură fișă de model nu poate descrie o implementare.

Scopul este, de asemenea, locul în care o echipă descoperă că a descris o ambiție, nu o operațiune. Vom sprijini lucrătorii de caz poate ascunde o duzină de aranjamente diferite. Instrumentul caută documente, ordonează munca, redactează un răspuns, recomandă o categorie, respinge o cerere, escaladează o alertă, stabilește o prioritate sau apelează un alt serviciu? Colegul îl folosește înainte sau după formarea unei opinii independente? Rezultatul este o sugestie într-un panou lateral sau un câmp care trebuie completat înainte ca dosarul să poată avansa? Efectul este imediat, întârziat, reversibil sau dificil de observat? Răspunsul schimbă sistemul chiar și acolo unde interfața cu utilizatorul pare familiară.

Scopul declarat al unui furnizor nu poate face realitatea să dispară. O echipă nu poate oferi unui sistem o autoritate practică largă, să îl descrie drept un asistent inofensiv și să se aștepte ca descrierea să rezolve problema. Dar un scop delimitat corespunzător rămâne totuși un control. Acesta le spune utilizatorilor ce dovezi au fost luate în considerare, le spune integratorilor ce nu trebuie să extindă în mod necugetat și le spune evaluatorilor ce schimbare ar redeschide evaluarea. Un scop vag transformă fiecare întrebare ulterioară într-o dispută despre ce s-a intenționat. Un scop delimitat permite unei organizații să verifice dacă încă face ceea ce a aprobat.

Acest aspect devine deosebit de important atunci când o organizație efectuează o modificare substanțială. Actul conține norme privind cazurile în care un distribuitor, un importator, un furnizor de implementare sau un alt terț poate deveni furnizor, inclusiv atunci când plasează un sistem pe piață sub numele propriu, efectuează o modificare substanțială sau modifică scopul declarat într-un mod care face ca sistemul să devină cu risc ridicat. Aplicarea juridică exactă depinde de circumstanțe și trebuie verificată în context. Lecția operațională este mai simplă: o schimbare de integrare poate fi un eveniment de guvernanță. Mutarea rezultatului unui model dintr-un panou de lucru într-o coadă de decizii poate fi simultan o schimbare de produs, o schimbare de flux de lucru și o schimbare de responsabilitate.

Contextul nu este decor

Contextul de implementare este adesea tratat ca partea care vine după munca reală: o listă de țări, o alegere de găzduire, câteva profiluri de utilizatori, poate o diagramă cu săgeți care duc obedient de la stânga la dreapta. Dar contextul dă formă riscului. Același tip de rezultat poate fi neconvenabil într-un mediu și cu consecințe importante în altul. O completare greșită într-un instrument de scriere poate fi corectată în propoziția următoare. O prioritate greșită într-un flux de lucru cu resurse limitate poate decide ce fișier vede o persoană primul. Un scor care pare a fi doar unul dintre multe elemente de intrare poate deveni decisiv dacă toate celelalte elemente sunt lente, vagi sau ascunse în spatele altei echipe.

Abordarea privind riscul ridicat din Act reflectă acest lucru. Articolul 6 leagă clasificarea ca risc ridicat de sistemele destinate a fi utilizate ca componente de siguranță ale anumitor produse sau de sistemele menționate în anexa III. Anexa III enumeră domenii în care sistemele de IA pot prezenta risc ridicat deoarece sunt destinate unor utilizări specifice, cum ar fi anumite utilizări biometrice, infrastructuri critice, educație și formare profesională, ocuparea forței de muncă, accesul la servicii și beneficii esențiale private și publice, aplicarea legii, migrație și control la frontieră, precum și administrarea justiției și procesele democratice. Detaliul juridic contează, dar contează și gramatica. Nu se spune că un artefact tehnic este cu risc ridicat în abstract. Se spune în mod repetat destinat a fi utilizat.

Articolul 6 conține și o calificare pentru anumite sisteme din anexa III: acestea nu trebuie considerate cu risc ridicat atunci când nu prezintă un risc semnificativ de vătămare a sănătății, siguranței sau drepturilor fundamentale ale persoanelor fizice, inclusiv prin faptul că nu influențează în mod material rezultatul procesului decizional. Furnizorii trebuie să documenteze această evaluare înainte de a plasa sistemul pe piață sau de a-l pune în funcțiune. Aceasta nu este o carte de scutire generală. Este o reamintire că efectul real al sistemului contează. O analiză utilă are suficiente detalii pentru a explica de ce un sistem influențează sau nu influențează în mod material un rezultat. Dacă această explicație nu poate fi scrisă fără a recurge la generalități vagi, echipa a învățat ceva înainte de lansare.

Contextul include timpul. O recomandare făcută la începutul unei investigații ample are un efect diferit față de o recomandare făcută în momentul în care o persoană are o singură șansă să furnizeze materialul lipsă. Include volumul. Un evaluator individual poate contesta un rezultat atunci când primesc cinci cazuri pe zi și îl pot accepta implicit atunci când primesc cinci sute înainte de prânz. Include limba. Un evaluator care poate citi dovezile în propria limbă de lucru poate exercita un alt tip de supraveghere decât un evaluator care primește un rezumat ferm al unui material pe care nu îl poate verifica independent. Include procedura locală, drepturile de contestație, personalul, accesul la un specialist, disponibilitatea unei soluții de rezervă și dacă un rezultat ajunge la o persoană cu suficientă autoritate pentru a face ceva util.

Nimic din toate acestea nu necesită ca un dezastru inventat să fie real. Este pur și simplu modul în care funcționează sistemele. O politică formală poate spune că omul este în buclă, dar sistemul poate fi totuși funcțional automat dacă persoana nu are timp, informații, autoritate sau o cale practică de a nu fi de acord. Articolul 14 din Act se referă, prin urmare, la supravegherea umană efectivă, adecvată riscurilor, nivelului de autonomie și contextului de utilizare. Acesta impune ca sistemele cu risc ridicat să fie proiectate și dezvoltate astfel încât oamenii să poată înțelege capacitățile și limitările relevante, să rămână conștienți de tendința de a se baza automat pe rezultate, să interpreteze corect rezultatele, să decidă să nu le folosească, să le anuleze sau să le inverseze și să oprească sistemul în siguranță acolo unde este cazul. Acestea sunt întrebări operaționale. Nu pot fi răspunse doar dintr-un benchmark de model.

Selectați o poziție de implementare. Modelul rămâne pe loc; granița sistemului, autoritatea și dovezile necesare nu rămân.

Utilizatorii fac parte din suprafața de control

Este tentant să vorbim despre utilizatori ca și cum ar sta în afara sistemului, ținând o tastatură și făcând ca partea umană să se întâmple. Ei fac parte din aranjamentul de operare. Cunoștințele lor, volumul de muncă, autoritatea, stimulentele și căile de ajutor determină ce face rezultatul. Un sistem proiectat pentru un specialist care poate inspecta materialul sursă nu este automat potrivit pentru un generalist care trebuie să lucreze într-un ritm alert. Un instrument util pentru un evaluator care poate respinge o recomandare nu este automat potrivit pentru un coleg care poate doar să facă clic pe aprobare sau să aștepte pe altcineva.

Acest lucru nu înseamnă că utilizatorul trebuie să pună la îndoială fiecare componentă de fiecare dată. Ar fi o definiție ciudată a tehnologiei utile. Înseamnă că supravegherea ar trebui proiectată ca o sarcină reală. Persoana trebuie să știe când este folosit sistemul, care este limitarea relevantă, ce dovezi sunt disponibile, ce tip de dezacord poate înregistra și ce se întâmplă după ce îl înregistrează. Are nevoie de autoritate care să corespundă responsabilității. A cere cuiva să supravegheze o ieșire pe care nu o poate opri, corecta sau direcționa este mai puțin supraveghere umană și mai mult decor uman.

Regulamentul oferă furnizorilor de sisteme un rol aici. Articolul 26 impune furnizorilor de sisteme cu risc ridicat să ia măsuri tehnice și organizatorice adecvate pentru a se asigura că utilizează sistemele în conformitate cu instrucțiunile însoțitoare. Le cere furnizorilor să atribuie supravegherea umană unor persoane fizice cu competența, pregătirea și autoritatea necesare și să monitorizeze funcționarea pe baza instrucțiunilor. În anumite cazuri, impune și păstrarea jurnalelor generate automat sub controlul lor. Aceasta nu este o cerere de a ține o persoană competentă în apropiere, în caz că interfața devine nervoasă. Este o cerere de a organiza o practică de lucru.

Pregătirea este adesea discutată ca fiind soluția completă. Nu este. Pregătirea poate ajuta o persoană să recunoască o limitare, dar nu poate crea o înregistrare sursă pe care interfața o ascunde. Nu poate crea timpul pe care un design de coadă îl consumă. Nu poate crea autoritatea pe care un contract o rezervă în altă parte. Nu poate repara o integrare care transformă o recomandare prudentă într-o acțiune ireversibilă. O organizație ar trebui să pregătească oamenii, desigur. Ar trebui, de asemenea, să facă posibilă sarcina pentru care sunt pregătiți în sistemul pe care îl primesc efectiv.

Există un test util: descrieți acțiunea utilizatorului fără a folosi verbul a revizui. Ce citesc? Ce comparație pot face? Ce pot refuza? Unde ajunge motivul? Cine îl vede? Ce se întâmplă cu recomandarea după respingere? Poate persoana afectată de rezultat să întrebe ce s-a întâmplat? Poate un coleg ulterior să reconstituie starea relevantă? Dacă răspunsurile rămân generale, probabil că și proiectarea supravegherii este generală.

Acest test se aplică dincolo de sistemele cu risc ridicat. Legea are un domeniu de aplicare și termene specifice; bunul simț operațional nu așteaptă o etichetă de categorie înainte de a întreba dacă o persoană a fost plasată într-un rol performativ. Este perfect posibil să construiești un instrument cu consecințe reduse care face oamenii mai puțin competenți în propria lor muncă, pentru că ieșirea este prea lină pentru a fi contestată. Este, de asemenea, posibil să construiești un instrument constrâns care crește capacitatea unei persoane de a pune întrebări bune, pentru că păstrează dovezile, își limitează autoritatea și face vizibilă incertitudinea. Modelul poate contribui la oricare dintre rezultate. Sistemul decide care rezultat are unde să se întâmple.

Persoanele afectate stau în afara consolei

Multe dintre cele mai importante persoane dintr-un sistem de inteligență artificială nu îl ating niciodată. Pot fi candidați, elevi, muncitori, pacienți, pasageri, rezidenți, clienți, reclamanți, debitori, martori sau membri ai publicului. S-ar putea să nu știe că un model a fost implicat. S-ar putea să experimenteze doar un răspuns care ajunge rapid, o cerere care este întârziată, un serviciu care devine indisponibil, o prioritate care se schimbă sau o decizie care pare imposibil de înțeles. Absența lor din interfață nu îi face absenți din sistem.

Acesta este unul dintre motivele pentru care cadrul de risc al Regulamentului se referă la sănătate, siguranță și drepturi fundamentale. Direcționează atenția către consecințe care nu pot fi reduse la întrebarea dacă un coleg autentificat s-a bucurat de instrument. Este și motivul pentru care o declarație de scop ar trebui să numească persoanele și grupurile asupra cărora se intenționează utilizarea sistemului, așa cum cere Anexa IV. Un sistem construit în jurul unei categorii numite utilizator poate ascunde în liniște diferența dintre persoana care operează interfața și persoana care trăiește cu rezultatul.

Persoanele afectate schimbă întrebările pe care o echipă trebuie să și le pună. Există o modalitate de a ști că sistemul a avut un rol semnificativ? Decizia se bazează pe informații care pot fi corectate? O limbă, un handicap, un dispozitiv, o locație sau un statut administrativ fac participarea mai dificilă? Echipa care operează sistemul primește semnale de la persoanele afectate sau doar de pe tabloul de bord? O corecție ajunge la date, la recomandare, la decizie și la orice material derivat care s-a bazat pe ele? Aceste întrebări nu sunt o cerere de a transforma fiecare sistem într-o consultare publică. Sunt o cerere de a urmări consecința suficient de departe pentru a vedea persoana de la celălalt capăt.

Legislația privind protecția datelor este relevantă acolo unde au loc prelucrări de date personale, alături de cadrul Regulamentului privind inteligența artificială. CEPD și AEPD au subliniat acest punct clar în avizul lor comun din 2021 privind propunerea: legislația existentă a UE privind protecția datelor se aplică prelucrării datelor personale din domeniul de aplicare al propunerii. Analiza juridică exactă va depinde de prelucrare și de actorii implicați. Concluzia privind guvernanța este simplă. Un exercițiu de clasificare nu poate absorbi toate celelalte obligații. Confidențialitatea, nediscriminarea, obligațiile sectoriale, cerințele de drept administrativ, normele de protecție a consumatorilor și angajamentele contractuale nu dispar pentru că o echipă a realizat un registru de riscuri care arată bine.

Există, de asemenea, o chestiune de bază privind lizibilitatea. O persoană nu trebuie să devină specialist în învățare automată pentru a înțelege cum să solicite o corecție. Dar un sistem nu trebuie să folosească complexitatea tehnică drept motiv pentru a face corecția imposibilă. O cale bună distinge ce a înregistrat sistemul, ce a decis un om, ce dovezi au fost luate în considerare, ce rămâne incert și ce poate fi încă schimbat. Nu pretinde o precizie pe care înregistrările nu o pot susține. În acest domeniu, onestitatea nu este doar un ton al vocii. Este parte din serviciu.

Integrarea este locul unde responsabilitățile își schimbă deținătorul

Echipele descriu uneori o arhitectură de inteligență artificială ca pe un lanț ordonat: model, prompt, răspuns, utilizator. Implementările reale seamănă mai degrabă cu o hartă municipală după ce cineva și-a amintit de conductele de servicii. Există sisteme de identitate, depozite de regăsire, permisiuni pentru instrumente, cozi, scheme, cache-uri, platforme de observabilitate, extensii de browser, job-uri în lot, reguli de aprobare, setări de păstrare, furnizori și persoane care moștenesc o sarcină pentru că persoana anterioară a plecat în concediu. Modelul este important. Rareori este singur.

Fiecare integrare poate modifica ce poate face sistemul și cum se deplasează o eroare. Regăsirea poate face ca o ieșire a modelului să pară fundamentată, în timp ce sursa este învechită, incompletă sau aplicată greșit. Un apel de instrument poate transforma o schiță într-o modificare de stare. O coadă poate transforma o recomandare la timp într-una întârziată. Un strat de orchestrare poate selecta un model sau o versiune de prompt diferită. O interfață cu utilizatorul poate ascunde incertitudinea care există într-un strat inferior. O integrare de identitate poate oferi unui instrument util acces la material pe care un utilizator nu l-ar putea deschide altfel. Niciuna dintre aceste observații nu acuză un anumit produs sau o anumită organizație. Ele descriu proprietăți obișnuite ale sistemelor, ceea ce este exact motivul pentru care ar trebui documentate înainte de a deveni surprinzătoare.

Orientările Comisiei privind modelele cu scop general (GPAI) sunt utile aici, deoarece plasează informațiile în punctul de predare. Documentația pentru furnizorii din aval este menită să îi ajute să înțeleagă capacitățile și limitările modelului, sarcinile preconizate, cerințele tehnice de integrare, specificațiile de intrare și ieșire și informațiile despre datele de antrenare. Aceste informații sunt necesare. Nu sunt suficiente. Echipele din aval trebuie totuși să decidă cum este utilizat promptul modelului, dacă o ieșire este afișată cu dovezi, ce permisiuni de instrumente sunt permise, cum este testată o modificare, ce jurnale sunt păstrate și dacă o recomandare poate influența un anumit flux de lucru.

De aceea, achiziția unui serviciu de model nu este achiziția unei posturi de risc complete. Documentația furnizorului poate informa o echipă că un model are o limitare cunoscută sau că a fost evaluat în anumite condiții. Nu poate dovedi că propriul index de regăsire al cumpărătorului este actualizat, că personalul cumpărătorului are autoritatea necesară sau că o persoană afectată are acces la o rută de contestare. În schimb, cumpărătorul nu poate cere ca furnizorul de model să cunoască fiecare politică locală sau proces din aval. Lucrul responsabil nu este să pretindem că o singură parte poate cunoaște întregul sistem. Este să facem granița explicită și să menținem dovezile în mișcare peste ea.

Articolul 25 oferă un reper juridic util pentru această realitate operațională. Acesta stabilește circumstanțele în care o parte, alta decât furnizorul inițial, este considerată furnizor al unui sistem de IA cu risc ridicat. Acestea includ introducerea sistemului pe piață sub numele sau marca comercială a acelei părți, efectuarea unei modificări substanțiale sau modificarea scopului preconizat într-un mod care face ca sistemul să devină cu risc ridicat. Prevederea este tehnică și specifică faptelor; nimeni nu ar trebui să se auto-clasifice pe baza unui articol de blog. Dar direcția ei este clară. Integrarea și reutilizarea pot schimba cine poartă obligațiile de furnizor. Un aranjament din aval nu rămâne pentru totdeauna în aval doar pentru că modelul original a venit din altă parte.

Există un motiv instituțional să luăm acest lucru în serios. Când responsabilitatea se schimbă în tăcere, siguranța și căile de remediere devin un joc de ping-pong organizațional. Furnizorul de model indică spre implementare. Implementatorul indică spre model. Integratorul indică spre serviciul cloud. Proprietarul serviciului indică spre o configurație care nu mai există. Persoanele afectate primesc o explicație elegantă despre cât de complex este totul. Poate fi corect, dar nu este un răspuns. Sistemul are nevoie de o evidență a organizației care deține întrebarea la fiecare graniță și de o rută pentru ca întrebarea să călătorească atunci când răspunsul este în altă parte.

Documentația ar trebui să descrie un sistem care se poate schimba în continuare

Documentația tehnică are reputația de a ajunge la sfârșitul unui proiect cu un vag miros de panică. Actul descrie un rol diferit. Pentru sistemele cu risc ridicat, documentația tehnică trebuie întocmită înainte ca sistemul să fie introdus pe piață sau pus în funcțiune și menținută la zi. Lista din Anexa IV depășește comportamentul modelului, acoperind scopul preconizat, versiunile, arhitectura sistemului, dezvoltarea, cerințele de date, validarea și testarea, supravegherea umană, măsurile de acuratețe și securitate cibernetică, gestionarea riscurilor, modificările și monitorizarea post-lansare. Aceasta nu este o anexă decorativă. Este o încercare de a păstra suficientă memorie pentru ca cineva să inspecteze sistemul după ce întâlnirea de lansare a devenit folclor.

Documentația funcționează doar atunci când poate arăta relații. O versiune de model trebuie conectată la versiunea de sistem care a folosit-o. Un test trebuie conectat la condițiile sale de intrare și la scopul său. O politică trebuie conectată la un punct de aplicare. Un rol de utilizator trebuie conectat la autoritatea pe care o are în interfață. O politică de logare trebuie conectată la evenimentul pe care îl poate reconstrui. O modificare trebuie conectată la evaluarea pe care a declanșat-o. În caz contrar, o echipă are o bibliotecă de documente bune și nicio modalitate de a răspunde la o anumită întrebare.

Jurnalele sunt un caz similar. Articolul 12 impune ca sistemele de IA cu risc ridicat să aibă capacități tehnice de înregistrare automată a evenimentelor pe durata de viață a sistemului, proporționale cu scopul preconizat. Jurnalele pot sprijini trasabilitatea, monitorizarea post-comercializare și monitorizarea operațională. Ele nu explică o decizie ca prin minune. Un jurnal îi poate spune unui investigator ulterior că a fost apelat un instrument, că o versiune era activă sau că un evaluator a făcut clic pe un control. Nu poate, de unul singur, să stabilească dacă evaluatorul a înțeles dovezile, dacă sursa de intrare era autoritară sau dacă un proces a fost corect. Înregistrările sunt valoroase pentru că oferă unei investigații un punct de plecare onest, nu pentru că elimină nevoia de raționament.

Monitorizarea post-comercializare completează imaginea. Articolul 72 impune furnizorilor de sisteme cu risc ridicat să stabilească și să documenteze un sistem de monitorizare post-comercializare într-o manieră proporțională cu natura tehnologiilor și cu riscurile sistemului de IA cu risc ridicat. Aceasta are o implicație simplă pentru echipele de implementare: o lansare nu este momentul în care sistemul devine pe deplin cunoscut. Organizația are nevoie de o modalitate de a primi informații relevante, de a distinge un semnal de o concluzie, de a decide dacă limita scopului preconizat rămâne valabilă și de a face o modificare sau de a opri o utilizare acolo unde dovezile o impun.

Această muncă nu este spectaculoasă. Arată ca identificatori de versiune, criterii clare de lansare, o evidență a dependențelor, un test pentru o rută de revenire, un proprietar desemnat pentru o limitare și o decizie care rămâne vizibilă după ce persoana care a luat-o își schimbă rolul. Arată ca întrebarea dacă o integrare s-a schimbat înainte de a întreba dacă modelul s-a schimbat. Arată ca păstrarea suficienților de dovezi pentru a corecta o consecință, mai degrabă decât doar explicarea acesteia ulterior. Plictisitor nu este opusul ambițios aici. Este partea care face ca ambiția să încapă într-o instituție.

Cum să raționezi despre întregul sistem fără a pretinde certitudine

O analiză completă nu este o căutare a unui scor universal de risc. Este o succesiune de întrebări care devine mai exactă pe măsură ce un design devine mai exact. Prima întrebare este scopul: ce este menit să facă acest sistem și ce nu este menit în mod specific să facă? A doua este consecința: cine poate fi afectat, cum și prin care decizie sau serviciu? A treia este autoritatea: care rezultat poate modifica o stare, influența o decizie, stabili o prioritate sau schimba ceea ce primește o persoană? A patra este dovada: ce susține utilizarea sistemului în acest context și care condiții fac ca acea dovadă să călătorească?

Apoi vin întrebările incomode. Ce se întâmplă când modelul este incert, greșit, indisponibil sau utilizat în afara limitei sale declarate? Ce se schimbă când o sursă este veche sau un instrument este refuzat? Ce se întâmplă dacă un utilizator este grăbit, nou în rol sau incapabil să inspecteze materialul de bază? Ce se întâmplă dacă o persoană afectată cere o corecție? Ce se întâmplă dacă o actualizare schimbă un prompt, corpusul de regăsire, valoarea implicită a interfeței, versiunea modelului sau permisiunea unui rol? Răspunsul este uneori un control tehnic, uneori o procedură, uneori o utilizare mai restrânsă, uneori un alt proprietar și uneori o decizie de a nu implementa. O guvernanță care nu permite niciodată ultimul răspuns este doar aprobare într-o jachetă mai frumoasă.

Este util să ții separate mai multe afirmații. Un fapt confirmat spune ce a documentat furnizorul modelului sau ce a observat organizația într-un test definit. O inferență spune de ce acel fapt poate conta într-un flux de lucru particular. Un control propus spune ce intenționează echipa să implementeze. Un risc rezidual spune ce rămâne după control. O concluzie juridică spune ce se aplică conform legii. Acestea nu sunt interschimbabile. Un document bun le etichetează pentru că cititorul poate avea nevoie să conteste una fără să le respingă pe celelalte.

De exemplu, se poate spune: documentația furnizorului menționează că modelul are o anumită limitare; echipa de implementare deduce că limitarea ar putea afecta o utilizare specificată; echipa propune o verificare a sursei; verificarea nu a fost încă testată în condițiile de lucru preconizate; iar consilierea juridică trebuie să evalueze utilizarea rezultată în conformitate cu legislația aplicabilă. Această frază este mai puțin satisfăcătoare decât o bifă verde. Este mai utilă decât o bifă verde, pentru că nu lasă nicio îndoială cu privire la ceea ce a fost stabilit și ceea ce nu a fost stabilit.

Echipele ar trebui să fie deosebit de atente la cuvântul uman. Un rol uman poate fi un control, dar doar acolo unde are o sarcină definită, informații adecvate, timp, instruire, autoritate și o cale de acțiune. Un rol uman poate deveni, de asemenea, o modalitate de a transfera vina către persoana cea mai apropiată de ecran. Distincția nu este filosofică. Este vizibilă în fluxul de lucru. Dacă un evaluator poate doar să aprobe, dacă dezacordul dispare într-un câmp de comentarii nemonitorizat sau dacă nimeni nu poate corecta consecința din aval, sistemul nu a dobândit o supraveghere semnificativă doar pentru că o persoană a dat clic pe ceva.

Aceeași precauție se aplică și transparenței. Un document lung poate face un sistem descriabil fără a-l face contestabil. Un tablou de bord îl poate face vizibil fără a-l face inteligibil. O declarație poate informa un utilizator că este implicată inteligența artificială, fără a-i spune ce poate face în legătură cu o eroare. Întrebarea utilă este una practică: poate persoana relevantă să găsească limita, dovezile, rolul responsabil și calea de corectare în punctul în care acestea contează? Dacă nu, informația există în locul greșit pentru ca guvernanța să aibă loc.

O mică notă din partea noastră

La Dweve, Centrul nostru public de încredere tratează înregistrarea modelului și integrarea din aval ca înregistrări separate, dar conexe. Pagina sa din aval menționează că echipele care integrează sau implementează Loom au nevoie de capacități actuale, limite, interfețe, context de evaluare și modificări, în timp ce înregistrarea publică afirmă că un model este un fir într-o țesătură mai largă de componente și limite operaționale. Aceasta este o poziție de documentare, nu o afirmație că o pagină publică clasifică fiecare implementare posibilă sau dovedește conformitatea pentru un integrator. Scopul separării este mai modest: o înregistrare a modelului ar trebui să însoțească integrarea fără a pretinde că înlocuiește analiza de sistem a integratorului însuși.

Acesta este standardul care merită păstrat. Un furnizor de modele ar trebui să pună la dispoziție informații utile. O organizație care implementează sau integrează modelul ar trebui să descrie sistemul real pe care l-a creat: scop, oameni, date, interfețe, autoritate, monitorizare și corectare. Nicio parte nu ar trebui să folosească documentația ca pe un schimb ceremonial în care o parte primește un PDF, iar cealaltă primește absolvirea.

Întrebarea mai dificilă este de obicei cea mai bună

Când o echipă întreabă dacă un model prezintă un risc ridicat, poate că încearcă să obțină un răspuns rapid la o preocupare rezonabilă. Dar întrebarea mai utilă este de obicei mai lungă: ce sistem construim din acest model, în ce scop, în ce context, cu ce oameni și ce se întâmplă când acesta greșește? La această întrebare nu se poate răspunde întotdeauna într-o singură întâlnire. Poate dezvălui că utilizarea propusă este mai restrânsă decât se aștepta, că dovezile sunt incomplete, că un rol de utilizator nu are autoritate, că un contract lasă o limită importantă fără proprietar sau că o integrare din aval a devenit, în liniște, centrul sistemului.

Niciuna dintre aceste constatări nu reprezintă un eșec al inovației. Sunt lucrurile pe care o instituție le învață înainte de a da unui sistem puterea de a modela opțiunile altei persoane. Abordarea europeană este adesea descrisă ca un set de obligații. Este, de asemenea, o disciplină a denumirii: numește scopul, actorul, contextul, versiunea, persoana afectată, limitarea, dovezile și calea de intervenție. Odată numite, aceste lucruri pot fi testate, modificate și contestate. Înainte de a fi numite, ele tind să reapară mai târziu ca surpriză.

Un model poate fi capabil, documentat cu atenție și valoros. Poate fi, de asemenea, plasat într-un sistem care îi cere prea mult, ascunde prea mult de la utilizatorii săi sau lasă prea puțin loc unei persoane afectate de rezultat. Diferența se face în afara ponderilor. Acolo se află munca dificilă și, de asemenea, oportunitatea serioasă: construiește sisteme a căror autoritate se potrivește cu dovezile lor, ale căror limite supraviețuiesc integrării și ai căror operatori pot spune în continuare nu.

Surse