Priežiūros sprendimų sąrašas registruoja, kas priėmė kokį sprendimą dėl kurios AI sistemos, remiantis kokia informacija ir su kokia išlyga. Skamba paprastai. Praktikoje pirmoji versija dažnai nepasiseka, nes ji pateikiama kaip naujas procesas šalia esamų susitikimų. Antrasis procesas šalia esamo yra ignoruojamas – ne todėl, kad žmonės nenoro, o todėl, kad niekas neskiria laiko tam, kas neatitinka jau pilnos darbotvarkės.
Šis sąrašas nėra veiklos žurnalas ir ne rizikos registras. Jame yra sprendimai: momentai, kai kompetentingas asmuo kažką patvirtino, atmetė, atidėjo arba leido tęsti su sąlygomis. Kiekvienoje eilutėje turi būti mažiausiai keturi elementai: sistema arba taikymas, dėl kurio priimtas sprendimas, sprendimą priėmusio asmens vardas ir pareigos, data, ir pagrindimas arba išlyga. Be pagrindimo sprendimų sąrašas yra tik dalyvių sąrašas. Su pagrindimu jis tampa įrodymu, kad buvo apmąstyta, o ne tik pažymėta varnele.
Sąrašas taip pat turi suteikti vietos peržiūrai. Sprendimas, priimtas prieš pusmetį remiantis tuo metu turėta informacija, gali būti pasenęs. Geras sprendimų sąrašas parodo, kada sprendimas buvo patvirtintas iš naujo arba atšauktas, ne tik kada jis buvo priimtas iš pradžių.
Valdybos ir vadovybės jau turi savo ritmą: ketvirtiniai susitikimai, rizikos komitetai, audito komitetai. Kas sukuria naują priežiūros struktūrą, nepriklausančią nuo šio ritmo, prašo žmonių rasti papildomo laiko tam, kas neturi aiškios vietos. Tai retai vyksta struktūriškai. Pirmus kelis kartus tai gal ir pavyksta, dedant pastangas. Vėliau tai išnyksta iš darbotvarkės, kai atsiranda kas nors skubesnio, o kažkas skubesnio visada atsiranda.
Sprendimas nėra kurti naują procesą, bet leisti sprendimų sąrašui prisijungti prie to, kas jau vyksta. Jei jau yra rizikos komitetas, kuris susitinka kas ketvirtį, AI sprendimų sąrašas turi būti nuolatinė šios darbotvarkės dalis, ne atskira sesija. Jei jau egzistuoja audito pėdsakas finansiniams sprendimams, to pėdsako logika – kas pasirašo, kas tikrina, kur tai saugoma – turi būti pakartotinai naudojama AI sprendimams. Tai taip pat priežastis, kodėl prisijungimas prie esamos rizikos struktūros yra atskira tema: sprendimų sąrašas, kuris nesijungia su tuo, kaip rizika jau aptariama kitur, išlieka izoliuotu dokumentu, kurio niekas neskaito.
Sprendimų sąrašas neveikia pats sau. Jis papildo ataskaitas, kurių valdybai reikia, kad galėtų pasakyti, jog yra priežiūra AI rizikos atžvilgiu, ir jis numato, kad egzistuoja kelias tam, kai sprendimas paaiškėja neišlaikąs laiko. Be vieno puslapio valdybos ataskaitos, kuri apibendrina sprendimų sąrašą, informacija dingsta archyve, kurio niekas neperžiūri. Be veikiančių eskalavimo kelių, sprendimas, kuris tapo pasenęs, tiesiog paliekamas, nes niekas nežino, kam apie tai pranešti.
Šie trys elementai yra susiję: sprendimų sąrašas fiksuoja, kas buvo nuspręsta, ataskaita tai padaro matomą tame lygmenyje, kur tai turi svorio, o eskalavimas leidžia sprendimą atnaujinti, kai pasikeičia situacija. Jei sukuriate vieną be kitų dviejų, atsiranda apžvalgos iliuzija, kuri per pirmąjį patikrinimą – incidentą, priežiūros institucijos klausimą, žurnalistą – nepasirodo apimanti tai, kas iš tikrųjų vyksta.
Sprendimų sąrašas yra tik toks geras, kokia į jį patenkanti informacija. Jei niekas nežino, kokios AI sistemos iš tikrųjų naudojamos – įskaitant tas, kurios buvo įsigytos arba sukurtos aplenkiant IT skyrių – tada sąrašas registruoja tik sprendimus dėl matomų, formaliai patvirtintų taikymų. Likusios lieka nesprendžiamos, ne todėl, kad sprendimo nereikėjo, o todėl, kad niekas nežinojo, jog yra kas dėl ko spręsti. Todėl inventorizacija visada vyksta prieš sprendimų sąrašą, ne po jo. Kas vadovui turi būti žinoma apie tai, aprašyta ką vadovas turi žinoti apie AI riziką; kas CIO turi atpažinti šioje inventorizacijoje, aprašyta ką CIO turi žinoti apie AI riziką.
Kas yra tvirta: sprendimų sąrašas, nesusietas su esamu susitikimu, nebus prižiūrimas, o sprendimų sąrašas, neturintis pilno vaizdo apie tai, kas veikia, registruoja tik dalį realybės. Kas priklauso nuo organizacijos: koks susitikimas yra tinkamas atskaitos punktas, kaip dažnai tas susitikimas vyksta, ir kas turi kompetenciją priimti sprendimą, kuris atsiduria sąraše. Tai skiriasi pagal sektorių, valdymo struktūrą ir rizikos kultūrą, todėl nėra vieno fiksuoto šablono, kuris veiktų visur nepritaikytas.
Responsible AI Scan yra kuriamas. Kam šiuo metu reikia sprendimų sąrašo, kuris jungiasi su esama struktūra, gali užsiregistruoti į laukimo sąrašą; kol kas nesiūloma nieko, kas jau neegzistuotų.
Sprendimų sąrašas parodo, kas priėmė sprendimą, ne kiek darbo sistema iš tikrųjų perima ar galėtų perimti. Šiam klausimui – kokia užduoties dalis gali būti perduota AI, o kokia ne – reikia kitokio požiūrio, nei suteikia vien valdymas. FTE TO AI darbo skenavimas apskaičiuoja kiekvienai užduočiai, kokią darbo dalį galima perimti, papildant apžvalgą, kurią teikia sprendimų sąrašas ir su juo susijusi priežiūros struktūra.
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.