O listă de decizii de supraveghere înregistrează cine a luat ce decizie despre ce sistem AI, pe baza căror informații, și cu ce rezervă. Sună simplu. În practică, prima versiune eșuează adesea pentru că este prezentată ca un proces nou pe lângă ședințele existente. Un al doilea proces în plus față de cel existent este ignorat, nu pentru că oamenii ar fi neîndoielnici, ci pentru că nimeni nu rezervă timp pentru ceva care nu se aliniază la o agendă deja plină.
Lista nu este un jurnal de activități și nici un registru de riscuri. Ea conține decizii: momentele în care o persoană cu autoritate a aprobat, respins, amânat sau a permis continuarea a ceva sub anumite condiții. Fiecare rând trebuie să conțină minimum patru elemente: sistemul sau aplicația la care se referă decizia, numele și rolul factorului de decizie, data, și motivarea sau rezerva. Fără motivare, o listă de decizii este o listă de prezență. Cu motivare, ea devine dovada că s-a gândit ceva, nu doar că s-a bifat ceva.
Lista trebuie de asemenea să ofere spațiu pentru revizuire. O decizie luată acum șase luni pe baza informațiilor disponibile atunci poate fi depășită. O listă de decizii bună arată când o decizie a fost reconfirmată sau anulată, nu doar când a fost luată inițial.
Consiliile de administrație și conducerile au deja un ritm: ședințe trimestriale, comitete de risc, comisii de audit. Cine construiește o structură nouă de supraveghere separată de acel ritm cere oamenilor să găsească timp suplimentar pentru ceva care nu are un loc clar. Acest lucru rareori se produce structural. Primele câteva dăți poate funcționează, cu efort. Apoi dispare de pe agendă imediat ce apare ceva mai urgent, și mereu apare ceva mai urgent.
Soluția nu este construirea unui proces nou, ci integrarea listei de decizii în ce se desfășoară deja. Dacă există deja un comitet de risc care se întrunește trimestrial, lista de decizii AI trebuie să fie o componentă fixă a acelei agende, nu o ședință separată. Dacă există deja un traseu de audit pentru deciziile financiare, logica acelui traseu — cine semnează, cine verifică, unde se arhivează — trebuie reutilizată pentru deciziile AI. Acesta este și motivul pentru care alinierea la structura de risc existentă este un subiect separat: o listă de decizii care nu se aliniază la modul în care riscul este deja discutat în altă parte rămâne un document izolat pe care nimeni nu îl consultă.
O listă de decizii nu funcționează de sine stătător. Ea alimentează raportarea de care are nevoie un consiliu de administrație pentru a putea afirma că are o imagine asupra riscului AI, și presupune că există un traseu pentru situația în care o decizie se dovedește a nu mai fi susținută. Fără o raportare pentru consiliu de o pagină care sintetizează lista de decizii, informația se pierde într-un arhivă pe care nimeni nu o răsfoiește. Fără căi de escaladare care funcționează, o decizie depășită rămâne pur și simplu în vigoare, pentru că nimeni nu știe cui trebuie să o semnaleze.
Cele trei sunt legate între ele: lista de decizii înregistrează ce s-a decis, raportarea face acest lucru vizibil la nivelul unde are pondere, iar escaladarea asigură că o decizie poate fi reluată dacă situația se schimbă. Dacă construiți una fără celelalte două, apare o aparență de imagine de ansamblu care, la primul test — un incident, o întrebare a unui organism de supraveghere, un jurnalist — nu se dovedește să acopere ce se întâmplă cu adevărat.
O listă de decizii este atât de bună pe cât sunt informațiile care intră în ea. Dacă nimeni nu știe ce sisteme AI sunt de fapt în uz — inclusiv ce a fost achiziționat sau creat pe lângă IT — atunci lista înregistrează doar deciziile privind aplicațiile vizibile, aprobate formal. Restul rămâne fără decizie, nu pentru că nu era nevoie de o decizie, ci pentru că nimeni nu știa că exista ceva despre care să se decidă. De aceea un inventar precede întotdeauna o listă de decizii, nu vine după ea. Ce trebuie să știe un administrator despre acest lucru este descris în ce trebuie să știe un administrator despre riscul AI; ce trebuie să recunoască un CIO în acel inventar este descris în ce trebuie să știe un CIO despre riscul AI.
Ce este cert: o listă de decizii fără aliniere la o ședință existentă nu este întreținută, iar o listă de decizii fără o imagine completă a ceea ce este în funcțiune înregistrează doar o parte din realitate. Ce depinde de organizație: care ședință este punctul de ancorare potrivit, cât de des se întrunește acea ședință, și cine are autoritatea de a lua o decizie care ajunge pe listă. Acest lucru diferă în funcție de sector, de structura de conducere și de cultura de risc, și de aceea nu există un șablon fix care să funcționeze pretutindeni fără adaptare.
Responsible AI Scan este în construcție. Cine are în acest moment nevoie de o listă de decizii care se aliniază la structura existentă se poate înscrie pe lista de așteptare; nu se oferă încă nimic care nu există deja.
O listă de decizii arată cine a decis, nu cât de multă muncă preia efectiv sau ar putea prelua un sistem. Pentru acea întrebare — ce parte a unei sarcini poate fi transferată către AI, și ce parte nu — este nevoie de o perspectivă diferită de cea oferită doar de guvernanță. Scanul de lucru al FTE TO AI calculează pentru fiecare sarcină ce parte din muncă poate fi preluată, ca supliment la imaginea de ansamblu oferită de o listă de decizii și de structura de supraveghere corespunzătoare.
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.