Un consiliu primește periodic rapoarte: financiare, operaționale, despre riscuri care au deja un loc în structura existentă. O raportare despre AI care stă separat de acestea, cu propriul ritm și propriul format, este în practică ignorată. Nu pentru că subiectul este neimportant, ci pentru că un al doilea proces în paralel cu unul existent necesită un efort separat care concurează cu tot ce se află deja pe agendă. Ceea ce este citit este ceea ce se încadrează în linia de raportare existentă: același ritm, aceeași lungime, același loc în ședință.
O raportare către consiliu privind AI nu are nevoie de un inventar tehnic complet. Consiliul are nevoie de un răspuns la un număr limitat de întrebări: ce aplicații AI există, în ce categorie de risc se încadrează, ce s-a schimbat de la raportarea anterioară și au existat escaladări. Acest ultim punct este acolo unde majoritatea rapoartelor rămân goale — nu pentru că nu se întâmplă nimic, ci pentru că nu există o rută prin care un semnal să ajungă la consiliu. Fără căi de escaladare care funcționează funcționale, o raportare este o fotografie a momentului fără istorie: arată ce există acum, nu ce a mers greșit pe parcurs sau ce a fost pe punctul de a merge greșit.
Raportarea se bazează pe ceea ce este deja stabilit. O listă de decizii de supraveghere cu privire la cine a aprobat ce este sursa din care se rezumă pagina, nu un document separat care există în paralel. Ceea ce se află pe pagină este o condensare a deciziilor deja luate; nu este o nouă evaluare pe care consiliul trebuie să o facă el însuși pe baza datelor brute.
Organizațiile au deja o structură de risc: un comitet de audit, un comitet de risc, un loc fix pe agenda consiliului pentru riscurile operaționale. O raportare AI care introduce propriul comitet, propriul calendar sau propriul șablon cere tuturor celor care participă deja la acest proces să facă ceva extra peste ceea ce fac deja. Această muncă suplimentară este postpusă de fiecare dată când agenda se umple, iar agenda se umple mereu. Rezultatul este că raportarea dispare după câteva încercări, nu pentru că cineva a decis că riscul AI nu este important, ci pentru că nimeni nu a decis că este mai important decât ceea ce exista deja.
Soluția nu se află într-un accent mai mare pus pe subiect, ci în mai puțină fricțiune la includerea acestuia. O pagină care apare în același ritm trimestrial ca celelalte raportări de risc, care utilizează același format și se află în același loc în pachet, este citită pentru că citirea ei nu necesită o acțiune separată. Ceea ce nu funcționează este un ciclu separat de guvernanță AI care rulează independent de ciclul existent — acesta este ignorat de îndată ce apare prima lună încărcată.
O raportare de o pagină poate fi scurtă doar dacă structura subiacentă este completă. Ea presupune o imagine de ansamblu de tip ce trebuie să știe un membru al consiliului despre riscul AI privind rolurile și responsabilitățile, astfel încât pagina să nu trebuiască să explice de fiecare dată cine este responsabil pentru ce. Ea presupune un inventar care nu conține doar ce a fost aprobat de IT, ci și ce departamentele au început să utilizeze pe cont propriu fără să raporteze acest lucru — AI din umbră, care devine vizibilă doar atunci când oamenii pot povesti fără consecințe ce folosesc de fapt. O raportare care arată doar lista aprobată raportează o fictiune.
Pagina presupune și că se întâmplă ceva între raportări: monitorizare care produce rezultate în loc de un registru pe care nimeni nu îl consultă. Fără acest strat intermediar, pagina trimestrială este o surpriză la fiecare ediție, în loc de un rezumat al a ceva ce a fost deja urmărit pe tot parcursul trimestrului. Și ea presupune că politica subiacentă nu este documentație de formă, ci o politică AI care este citită de oamenii care folosesc zilnic sistemele — pentru că o raportare despre conformitatea cu o politică pe care nimeni nu o cunoaște raportează în principal despre ea însăși.
Pagina destinată consiliului este o condensare; fundamentarea se află un strat mai profund, la persoana care cunoaște sistemele. Ce contribuie un CIO la aceasta este descris în ce trebuie să știe un CIO despre riscul AI, și aceste două straturi — imaginea de ansamblu la nivel de conducere și cunoștințele operaționale — trebuie să se alinieze înainte ca pagina de un sfert de oră de citit să spună cu adevărat ceva despre ce se întâmplă în organizație.
Această structură este construită, nu oferită ca produs finalizat. Cei care doresc scanarea care produce acest inventar, această clasificare și această structură de raportare intră pe o listă de așteptare; este în construcție și nu este vândut ca instrument gata de utilizare înainte de a fi cu adevărat așa.
Odată ce este clar ce AI funcționează și în ce categorie de risc se încadrează, urmează o altă întrebare, care nu are legătură cu riscul, ci cu organizarea muncii în sine: ce parte din sarcinile care sunt executate în prezent se pretează să fie preluate de AI. Acesta este un calcul separat, construit nu pe risc, ci pe sarcini. Scanarea de lucru a FTE TO AI calculează, pentru fiecare sarcină, ce parte din muncă este eligibilă pentru preluare, ca pas următor de îndată ce este clar ce AI este deja prezentă în organizație.
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.