Un echipă a vrut să testeze ceva. Un chatbot pentru întrebările clienților, un script care rezumă rapoarte, o legătură cu un model de limbaj pentru sortarea e-mailurilor. Nu a fost nevoie de o decizie majoră: cineva avea un cont, o cheie API sau o perioadă de probă gratuită, și în decursul unei singure după-amiezi ceva era deja funcțional. Pilotul funcționa, sau funcționa suficient de bine, și nimeni nu mai avea vreun motiv să îl dezactiveze.
Aceasta nu este o excepție. Este modul obișnuit în care AI intră într-o organizație. Nu printr-o achiziție sau un buget aprobat, ci printr-o instalație de testare care își supraviețuiește propriul statut de test. Faza de testare nu a fost niciodată închisă formal, pentru că nici nu a existat vreodată un început formal care să fie închis.
Un pilot care funcționează, este folosit. Și ceea ce este folosit, devine dependență. Echipa care a construit rezumatorul de rapoarte a plecat poate, dar rezumatul continuă să apară în fiecare săptămână. Nimeni nu are misiunea de a-l dezactiva, și nimeni nu vrea să își asume riscul ca ceva să se oprească, fără să știe ce îi va lua locul.
În plus, o instalație de testare de obicei nu are un proprietar în sensul în care o structură de guvernanță se așteaptă. Nu s-a făcut nicio clasificare a riscului, nicio analiză a datelor, nicio decizie cu privire la cine este responsabil dacă lucrurile ies rău. Pilotul există într-un spațiu intermediar: prea folosit pentru a fi ignorat, prea informal pentru a fi gestionat. Acesta este exact modelul care duce la angajați care folosesc un instrument pe care nimeni nu l-a aprobat — doar că, în acest caz, la nivel de echipă, nu individual.
Reflexul la descoperirea unei instalații de testare neautorizate este de obicei: cine a permis asta, și de ce nu am știut. Această întrebare este de înțeles, dar are efect contrar. Cine simte, chiar de la prima discuție, că se apropie o întrebare de vinovăție, nu mai spune nimic la următoarea ocazie. Iar următoarea instalație de testare — care va apărea cu siguranță — va dispărea din vedere la fel ca și aceasta.
O inventariere construită pe încredere aduce mai mult decât un audit construit pe control. Nu pentru că oamenii nu ar avea nimic de ascuns, ci pentru că informația pe care o căutați se află la utilizator, și acel utilizator vorbește doar dacă nu este tras la răspundere pentru ceea ce a descoperit.
În momentul în care o instalație de testare este identificată, prima întrebare nu este dacă poate continua să existe, ci ce face ea exact. Ce date intră în ea, cine folosește rezultatul, și ce se întâmplă dacă rezultatul este greșit. Acestea sunt aceleași întrebări care se aplică oricărei alte aplicații de AI, iar răspunsul determină dacă este vorba despre un instrument informal sau despre un risc care merită atenție.
Apoi urmează clasificarea: se încadrează aplicația într-o categorie de risc care există deja, sau necesită o evaluare nouă. În continuare: ce trebuie înregistrat pentru a demonstra că organizația știe ce funcționează și de ce. Exact acest lucru este abordat în ce trebuie să înregistrați per aplicație — nu ca birocrație suplimentară, ci ca documentația minimă necesară pentru a distinge un pilot de un risc.
O instalație de testare care trece acest test poate continua să existe, acum cu un proprietar și o clasificare. O instalație de testare care nu trece testul trebuie eliminată treptat — dar acesta este un proces controlat, nu o pedepsire a persoanei care l-a pornit cândva.
Instalația de testare care nu a fost niciodată dezactivată este o formă a unui model mai amplu. Gândiți-vă la extensia de browser cu acces la e-mailul dumneavoastră pe care cineva a instalat-o cândva pentru a economisi timp, sau la datele companiei care ajung într-o fereastră de chat gratuită pentru că era mai rapid decât instrumentul oficial. Toate aceste situații au o caracteristică comună: au apărut dintr-o nevoie practică, nu dintr-o alegere de politică, și continuă să existe atâta timp cât nimeni nu întreabă despre ele.
Lista IT cu software aprobat nu este, prin urmare, punctul de start al unui inventar — este punctul de start al unei căutări pentru ceea ce se află în afara acelei liste. Cine dorește să știe cum se desfășoară o astfel de căutare, găsește o abordare în cum construiți un inventar AI.
O instalație de testare care este descoperită dă naștere, de obicei, unei întrebări ulterioare care merge dincolo de guvernanță: de ce a funcționat asta atât de bine, încât nimeni nu a osat să o oprească? Aceasta este o întrebare despre munca în sine, nu doar despre risc. Scanarea muncii de la FTE TO AI calculează, pentru fiecare sarcină, ce parte a muncii poate fi preluată de AI, făcând astfel vizibil ceea ce o instalație de testare arăta deja implicit: că o parte a muncii poate fi organizată diferit. În timp ce Responsible AI Scan cartografiază ce funcționează și sub ce risc, scanarea muncii arată de unde provine acea utilizare și ce înseamnă ea structural pentru repartizarea sarcinilor.
Responsible AI Scan, cu inventarierea, clasificarea și setul de guvernanță descrise mai sus, este în curs de dezvoltare. Cei care se confruntă deja cu acest lucru și doresc să fie informați imediat ce instrumentul devine disponibil se pot înscrie pe lista de așteptare.
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.