Valdybai, kuri kelia AI klausimą darbotvarkėje, dažniausiai pasiūlomi du dokumentų tipai: storas dosjė, kurio niekas neperskaito prieš posėdį, arba santrauka, kuri sako tiek mažai, kad iš jos nekyla joks sprendimas. Vienos puslapio ataskaita valdybai nėra dosjė santrauka. Tai kitas klausimas: ką valdybos narys turi žinoti, kad galėtų prisiimti atsakomybę, ir kas yra tik triukšmas.
Tas skirtumas nėra menkas. Dauguma AI ataskaitų, kurias mes matome, skaičiuoja sistemas. Puslapis, kuriame tik nurodoma, kiek yra AI taikymų, valdybai nieko nepasako apie tai, kur slypi rizika. Skaičiavimas yra IT klausimas. Valdymas (governance) yra kitas klausimas: kurie taikymai susiję su sprendimais apie žmones, kurie buvo pradėti naudoti be priežiūros, ir kurie patenka į rizikos klasę, kuriai reikalingas parašas.
Veikiantis puslapis apima ribotą skaičių elementų, ir kiekvienam yra priežastis jį įtraukti:
Visa kita — kas kokį modelį apmokė, kokios sąlygos taikomos kokiam tiekėjui, kokia techninė mitigacija taikyta — priklauso žemesniam lygiui. Tas lygis egzistuoja, yra tvarkomas ir gali būti pareikalautas. Bet jam nėra vietos puslapyje, kurį skaito valdyba, nes tuomet valdyba jo tiesiog neskaitys.
Priežastis, kodėl tiek daug AI valdymo iniciatyvų užstringa, nėra proceso trūkumas. Tai, kad yra antrasis procesas, šalia esamo. Valdyba jau turi rizikos komitetą, jau turi audito kalendorių, jau turi formatą ataskaitoms apie operacinę riziką, atitiktį, informacijos saugumą. Kas prie to prideda atskirą AI procesą — su savo dažnumu, savo šablonu, savo atsakingu asmeniu — prašo to, kas pirmiausia bus praleista, kai darbotvarkė bus per pilna. Tai nevyksta iš nenoro. Tai vyksta, nes antrasis procesas iš prigimties sulaukia mažiau dėmesio nei pirmasis.
Ataskaita, kuri iš tikrųjų skaitoma, yra ta, kuri eina esamu ritmu: tas pats posėdis, tas pats formatas, tas pats eskalavimo būdas, kuris jau egzistuoja kitoms rizikoms. Kaip toks integravimas praktiškai įgyvendinamas, aprašyta puslapyje apie integravimą į esamą rizikos struktūrą, o būdas, kuriuo po to fiksuojami sprendimai, aptariamas puslapyje apie priežiūros sprendimų sąrašą, kuris integruojamas į esamą ritmą.
Vienos puslapio ataskaita naudinga tik tuomet, jei už jos slypintis inventorius yra tvarkingas. Tai dalis, kuri dažniausiai praleidžiama: valdybos nariai gauna puslapį su rizikos klasifikacija, kai niekas nepatikrino, ar pagrindinis AI taikymų sąrašas yra išsamus. Šešėlinis AI — naudojimas, kilęs už IT sąrašo ribų — tuomet tyliai išnyksta iš vaizdo, ne todėl, kad jis nesvarbus, o todėl, kad niekas jo neklausė. Darbuotojas, kuris naudoja AI įrankį be patvirtinimo, pats to nepraneša, jei gresia atsiskaitymas. Jis tai praneša tik tada, kai klausimai keliami be pasekmių.
Vienos pusės puslapis yra taigi proceso, kuris pradedamas nuo inventoriaus ir eskaluojasi per jau egzistuojančius kelius, viršūnė. Kaip toks eskalavimas veikia nesukuriant naujos hierarchijos, aprašyta puslapyje apie eskalavimo kelius, kurie tikrai naudojami. Ir kas turi būti struktūriškai fiksuojama, kad puslapį būtų galima kaskart pildyti iš naujo, netampant rekonstrukcija, aprašyta puslapyje apie stebėseną, kuri tikrai duoda naudos ataskaitoms.
Responsible AI Scan pateikia inventorių, klasifikaciją ir valdymo struktūrą, kuri integruojasi su tuo, kas jau egzistuoja — įskaitant formatą ataskaitai, kurią valdyba tikrai skaitys. Pats skanas kuriamas; kas nori kažko konkretaus dabar, gali užsirašyti į laukiančiųjų sąrašą.
Ataskaita, kuri parodo, kokia darbo dalis patenka į AI riziką, savaime kelia kitą klausimą: kokią darbo dalį pačią gali perimti AI. Tai kitas skaičiavimas, atliekamas kiekvienai užduočiai atskirai, o ne kiekvienai sistemai, ir tą skaičiavimą atlieka FTE TO AI darbo skanas.
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.