Dažnai jau yra dokumentas pavadinimu eskalavimo procedūra. Jame yra schema su rodyklėmis, vardų sąrašas ir kelios ribinės reikšmės. Problema nėra tai, kad dokumento nėra. Problema yra ta, kad niekas jo neatidaro tuo momentu, kai jo reikia.
Tai vyksta ne dėl nenoro. Tai vyksta todėl, kad jau egzistuoja kelias, kuriuo problemos keliauja į viršų: linijos vadovas, praneša apie IT incidentą, atitikties pareigūnas, kalba su verslo padaliniu, komandos vadovas, savo problemą perduoda savo tiesioginiam vadovui. Šis kelias egzistuoja, naudojamas kasdien ir veikia – tiems dalykams, kuriems jis buvo sukurtas. Naujas eskalavimo kelias, skirtas specialiai AI incidentams, tuomet tampa antru maršrutu prie maršruto, kuris jau veikia. Kilus abejonei, visi renkasi kelią, kurį jau žino.
Eskalavimo kelias, kuris yra atskirtas nuo esamos struktūros, reikalauja, kad darbuotojas pirmiausia atpažintų, kad kažkas yra AI incidentas, tada prisimintų, kad tam taikomas kitas procesas, ir tada imtų vargo laikytis to proceso, o ne paprasčiausiai paskambintų savo vadovui. Kiekvienas žingsnis šioje grandinėje yra momentas, kai kelio galima nesilaikyti.
Prie to prisideda ir antra priežastis, mažiau pastebima, tačiau ne mažiau reikšminga: kas praneša apie nukrypimą, nenori tuoj pat atsidurti organizacijos incidentų formoje. Jei eskalavimas yra tolygus atsakomybės nustatymui, eskalavimo nebūna. Tai taikoma darbuotojui, kuris naudojo AI įrankį, kuris nebuvo patvirtintas, ir tai taikoma vadovui, kuris leido veikti modeliui, apie kurį niekas nežinojo. Eskalavimo kelias, kuris tikrai naudojamas, yra kelias, kuriame pirmasis pranešimas nėra nuosprendis, o signalas.
Veikiantis eskalavimo kelias aprašo tris dalykus, ir ne daugiau.
Kas pastebi kažką – darbuotojas, klientas, išorinė šalis – turi žinoti, į ką kreiptis, be to, kad pirmiausia turėtų išsiaiškinti, ar tai AI klausimas, ar įprastas operacinis klausimas. Kelias turi jungtis su tašku, kuris jau egzistuoja, su papildoma šaka tuo momentu, kai išaiškėja, kad į tai įsitraukęs AI.
Kas priima sprendimą – ar kažkas sustabdomas, koreguojamas, ar pranešama priežiūros institucijai – turi būti nustatyta prieš įvykstant incidentui. Ne kaip abstrakti pareigų pavadinimas, o kaip vardas, su pavaduotoju. Eskalavimas, kuris užstringa dėl tuščio mandato, nėra eskalavimas.
Kas vyksta po to su tuo, kuris pranešė, turi būti aišku. Jei antrasis procesas susideda tik iš pareigos pranešti, neaiškiai nurodant pasekmes tam, kuris praneša, jo bus vengiama. Tai tiksliai vieta, kur slepiasi šešėlinis AI: ne sistemose, kurias žino IT, o įrankiuose, kuriuos kažkas pradėjo naudoti, apie tai nepranešdamas, nes pranešti jautėsi kaip prisipažinti.
Sprendimas nėra storesnis dokumentas. Tai eskalavimo kelias, kuris naudojasi jau esama struktūra – pranešimo punktu, eskalavimo linija, rizikos komitetu – ir prie jo prideda AI-specifinę šaką tuose punktuose, kur tai turi reikšmę. Kaip tiksliai vyksta šis prijungimas, taip pat platesnės politikos ir priežiūros organo sprendimų sąrašo atveju, aprašyta kaip gauti AI politiką, kuri yra skaitoma, nes yra įdiegta į tai, kas jau egzistuoja ir kaip gauti priežiūros sprendimų sąrašą, kuris jungiasi su esamu sprendimų priėmimo ritmu. Abu dokumentai kalba apie tą patį dalyką: procesas, kuris stovi šalia organizacijos, ignoruojamas; procesas, kuris yra jos dalis, vykdomas.
Šis principas taikomas ne vien eskalavimui. Jis taikomas visai AI valdymo struktūrai. Kas norėtų sužinoti, kaip tai atrodo plačiau – kaip rizikos klasifikacija jungiasi su esamomis rizikos kategorijomis, kaip prijungimas prie esamos rizikos struktūros padeda išvengti lygiagrečios biurokratijos – tenai ras pagrindinį principą. Tas pats taikoma pranešimams į viršų: vieno lapo ataskaita valdybai veikia tik tada, kai eskalavimai, kurie joje minimi, iš tiesų buvo praneští. O be nuolatinio stebėjimo, kas kinta, kiekvienas eskalavimo kelias per metus pasensta; ką tai reiškia praktikoje, paaiškinta stebėjimas, kuris duoda naudos.
Eskalavimo kelią galima parašyti tik tada, kai žinoma, kas gali eskaluoti. Kol niekas nežino, kokie AI veikia organizacijoje – įskaitant tai, kas nebuvo patvirtinta – dokumentas išlieka teorinis. Todėl Responsible AI Scan nesiima eskalavimo kelio pirmiausia, o inventorizacijos: kas veikia, kas tuo naudojasi ir koks rizikos lygis tam tinka. Tik tuo pagrindu galima parašyti eskalavimo kelią, kuris jungiasi su tuo, kas jau egzistuoja, o ne su tuo, kas turėtų egzistuoti popieriuje.
Eskalavimo keliai kalba apie tai, kas nutinka blogai su AI, kuris jau naudojamas. Kitas klausimas, taip pat pakankamai neįvertintas, yra kur AI galėtų perimti darbą pats. FTE TO AI darbo skenavimas apskaičiuoja kiekvienai užduočiai, kokia darbo dalis tam tinka, nepaisant to, ar tai jau vyksta, ar dar turi būti įgyvendinta.
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.