Multe organizații presupun că rolul lor este fix: sunt utilizatorul unui sistem construit de un furnizor, iar obligațiile care decurg din asta sunt clare și permanente. Această presupunere este adesea corectă, dar nu întotdeauna. Rolul pe care îl are o organizație în raport cu un sistem AI nu este o etichetă fixă. Este rezultatul a ceea ce se întâmplă efectiv cu sistemul, iar acest rezultat se poate schimba fără a se semna un contract nou sau a se face o achiziție nouă.
Clasificarea unui rol depinde de o serie de elemente factuale, nu de modul în care un furnizor denumește sistemul sau de modul în care un departament intern îl poziționează intern. Relevant este, printre altele, cine a introdus sistemul pe piață, cine folosește sistemul efectiv într-un proces propriu și cine a modificat sistemul după livrare. De asemenea, contează sub ce nume este prezentat sistemul către exterior și dacă o organizație redistribuie sistemul altora fără a-l folosi ea însăși. Aceste elemente determină împreună dacă o organizație acționează ca furnizor, ca utilizator sau ca parte care se situează undeva la mijloc.
Motivul pentru care acest lucru este relevant pentru guvernanță este că rolul determină ce obligații revin cărei părți. O organizație care este doar utilizator are alte responsabilități decât o organizație care acționează de facto ca furnizor. Ce se așteaptă exact de la fiecare rol este descris în altă parte; aici este vorba despre mecanismul care determină ce rol se aplică și despre semnalarea momentului în care acest mecanism produce un alt rezultat decât înainte.
Un rol nu este legat de un sistem pe toată durata de viață a acestuia. Este legat de ceea ce se întâmplă efectiv la un moment dat. Aceasta înseamnă că aceeași organizație poate avea, pentru același sistem, roluri diferite în două momente diferite. Câteva situații în care se întâmplă acest lucru: o echipă care ajustează (finetune) un model achiziționat pe baza propriilor date, un departament care reetichetează un sistem și îl oferă altor departamente sub nume propriu, sau o organizație care redistribuie unui client sau partener un sistem destinat inițial uzului intern. În fiecare dintre aceste cazuri, rolul factual se schimbă, chiar dacă în exterior se schimbă puțin.
Ce se schimbă în practică nu este abstract. Determină cine este responsabil pentru documentație, cine trebuie să demonstreze că un sistem face ceea ce pretinde că face și cine trebuie să reacționeze dacă ceva nu funcționează corect. Mai multe despre ce se schimbă exact atunci când un model este ajustat este descris pe pagina despre ajustările aduse unui model. Această schimbare este unul dintre cele mai clare exemple despre modul în care un rol se poate schimba fără o decizie conștientă anterioară.
Motivul pentru care acest subiect este relevant nu doar din punct de vedere juridic, ci și organizatoric, este că o schimbare de rol se produce adesea neobservată. O echipă care ajustează un model se gândește la o îmbunătățire tehnică, nu la o schimbare de responsabilitate. Un departament care transferă un instrument către alt departament se gândește la comoditate, nu la un nou rol de furnizor. Guvernanța care se uită doar la ce a fost achiziționat ratează sistematic aceste schimbări.
Acest lucru este legat de întrebarea ce aplicații se încadrează exact într-o reglementare și care nu; această limită este tratată pe pagina despre domeniul de aplicare al aplicațiilor. Un sistem care se afla în afara domeniului de aplicare atunci când a fost achiziționat poate intra în domeniul de aplicare de îndată ce rolul organizației se schimbă. Acest lucru face ca o verificare unică la achiziție să nu fie suficientă; verificarea trebuie să evolueze odată cu ceea ce se întâmplă efectiv cu un sistem.
De asemenea, nivelul de risc al unei aplicații se poate schimba odată cu o schimbare de rol. Ce înseamnă exact un nivel de risc ridicat pentru obligațiile unei organizații și de ce depinde acest lucru este explicat pe pagina despre consecințele unui nivel de risc ridicat. O organizație care, printr-o schimbare de rol, este considerată brusc furnizor al unui sistem cu nivel de risc ridicat poartă alte responsabilități decât atunci când era doar utilizator al aceluiași sistem.
Pentru a semnala schimbările de rol înainte ca acestea să devină o problemă, o organizație trebuie să știe ce sisteme există, cine le ajustează și cine le redistribuie către cine. Acest lucru necesită un inventar care depășește lista aprobată de departamentul IT, precum și un loc fix unde sunt înregistrate deciziile privind ajustarea, redistribuirea și reetichetarea. Un astfel de loc fix, și întrebările care îl acompaniază, sunt descrise pe pagina despre un registru de decizii de supraveghere.
Responsible AI Scan este construit pentru a face vizibile aceste schimbări: ce sisteme funcționează efectiv, cine le folosește, cine le-a ajustat și ce rol rezultă din asta în acest moment. Instrumentul care susține acest lucru este în construcție; cei care doresc să îl folosească se pot înscrie pe lista de așteptare.
O schimbare de rol nu afectează doar guvernanța. Atunci când un sistem se transformă dintr-un instrument izolat într-ceva care preia structural o parte dintr-o sarcină, se schimbă și întrebarea cât de multă muncă preia de fapt sistemul respectiv și cât rămâne la oameni. Scanul de muncă al FTE TO AI calculează, pentru fiecare sarcină, ce parte din muncă poate fi preluată de AI, făcând astfel vizibil unde o schimbare de rol în guvernanță coincide cu o schimbare factuală în distribuția muncii.
Vraag maar. Governance begint bij weten wat er draait — ook wat niemand heeft goedgekeurd.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.