re-ai-gov Pe lista de așteptare

Kennisbank

O cale de escaladare pe care nimeni nu o folosește nu există

Există de obicei deja un document cu titlul procedură de escaladare. Conține o schemă cu săgeți, un rând de nume și câteva valori-limită. Problema nu este că documentul lipsește. Problema este că nimeni nu îl deschide în momentul în care este nevoie de el.

Asta nu se întâmplă din rea-voință. Se întâmplă pentru că există deja o cale prin care problemele sunt raportate în sus: managerul de linie care semnalează incidentul IT, ofițerul de compliance care discută cu business-ul, șeful de echipă care își pune problema în fața propriului superior. Această cale există, este folosită zilnic și funcționează — pentru lucrurile pentru care a fost concepută. O nouă cale de escaladare specifică pentru incidente de AI devine astfel o a doua rută pe lângă o rută care deja funcționează. În caz de îndoială, fiecare aleg ruta pe care o cunoaște.

De ce pierde al doilea proces

O cale de escaladare separată de structura existentă cere angajatului să recunoască întâi că este vorba de un incident de AI, apoi să își amintească că pentru acesta se aplică un alt proces, și apoi să facă efortul de a urma acel proces în loc să își sune pur și simplu superiorul. Fiecare pas din acest lanț este un moment în care calea este abandonată.

La aceasta se adaugă un al doilea motiv, mai puțin vizibil, dar la fel de determinant: cel care semnalează o abatere nu vrea să se trezească imediat pe formularul de incidente al organizației. Dacă escaladarea echivalează cu sancțiunea, nu se mai escaladează. Asta este valabil pentru un angajat care a folosit un instrument de AI neaprobat, și este valabil și pentru un manager care a lăsat un model să funcționeze fără ca nimeni să știe. O cale de escaladare care este efectiv folosită este o cale în care prima semnalare nu este o condamnare, ci un semnal.

Ce trebuie să conțină documentul

O cale de escaladare care funcționează descrie trei lucruri, și nimic mai mult.

Cel care observă ceva — un angajat, un client, o parte externă — trebuie să știe la cine se poate adresa fără să trebuiască să stabilească întâi dacă este o chestiune de AI sau o chestiune operațională obișnuită. Calea se aliniază cu punctul de semnalare care există deja, cu o ramificație suplimentară în momentul în care se constată implicarea AI-ului.

Cel care ia decizia — dacă ceva este oprit, ajustat sau raportat unei autorități de supraveghere — trebuie să fie stabilit înainte de producerea incidentului. Nu ca titlu abstract de funcție, ci ca nume, cu un supleant. Escaladarea care se blochează într-un mandat gol nu este escaladare.

Ce se întâmplă apoi cu cel care a semnalat trebuie să fie clar. Dacă un al doilea proces constă doar într-o obligație de raportare fără claritate asupra consecințelor pentru cel care raportează, acesta va fi evitat. Exact acolo se ascunde shadow AI: nu în sistemele pe care le cunoaște IT-ul, ci în instrumentele pe care cineva a început să le folosească fără să le raporteze, pentru că raportarea se simțea ca o recunoaștere de vină.

Aliniere în loc de adăugare

Soluția nu este un document mai stufos. Este o cale de escaladare care folosește structura care există deja — punctul de semnalare, linia de escaladare, comitetul de risc — și adaugă la aceasta o ramificație specifică AI-ului în punctele în care face diferența. Cum funcționează exact această aliniere, inclusiv pentru politica mai largă și lista de decizii a organului de supraveghere, este descris în cum obțineți o politică de AI care este citită pentru că este integrată în ceea ce există deja și în cum obțineți o listă de decizii de supraveghere care se aliniază cu ritmul existent de luare a deciziilor. Ambele documente ating același punct: un proces care stă lângă organizație este ignorat; un proces care este integrat în ea este urmat.

Acest principiu nu se aplică doar escaladării. Se aplică întregii structuri de guvernanță în jurul AI-ului. Cei care vor să știe cum se prezintă acest lucru la o scară mai largă — cum se aliniază clasificarea riscurilor cu categoriile de risc existente, cum alinierea cu structura de risc existentă previne apariția unei birocrații paralele — găsesc acolo principiul de bază. Același lucru este valabil pentru raportarea către nivelurile superioare: o raportare de o pagină către consiliu funcționează doar dacă escaladările pe care le conține au fost efectiv semnalate. Și fără o observare continuă a ceea ce se schimbă, orice cale de escaladare devine depășită într-un an; ce înseamnă asta în practică este explicat la monitorizare care produce rezultate.

Inventarul ca punct de pornire

O cale de escaladare poate fi scrisă abia atunci când se cunoaște ce poate fi escaladat. Cât timp nimeni nu știe ce AI funcționează în organizație — inclusiv ce nu a fost aprobat — documentul rămâne teoretic. De aceea, Responsible AI Scan nu începe cu calea de escaladare, ci cu inventarul: ce funcționează, cine îl folosește și ce nivel de risc i se aplică. Doar pe baza acestuia se poate scrie o cale de escaladare care se aliniază cu ceea ce există deja, în loc de ceea ce ar trebui să existe pe hârtie.

De la escaladare la preluare

Căile de escaladare privesc ceea ce nu funcționează bine cu AI-ul deja folosit. O altă întrebare, la fel de puțin abordată, este unde AI-ul ar putea prelua chiar munca. Scanul de muncă al FTE TO AI calculează pentru fiecare sarcină ce parte a muncii se califică pentru acest lucru, indiferent dacă acest lucru se întâmplă deja sau trebuie încă organizat.

Andrewde assistent van de Responsible AI Scan

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.