Seznam sklepov nadzora zapisuje, kdo je sprejel kateri sklep o katerem AI-sistemu, na podlagi katerih informacij in s katerim pridržkom. To se sliši preprosto. V praksi prva različica pogosto spodleti, ker se postavi kot nov proces poleg obstoječih posvetov. Drugi proces poleg obstoječega se ignorira, ne ker bi bili ljudje nevoljni, ampak ker si nihče ne vzame časa za nekaj, kar se ne ujema z že polnim dnevnim redom.
Seznam ni dnevnik dejavnosti in ni register tveganj. Vsebuje sklepe: trenutke, ko je nekdo s pooblastilom nekaj odobril, zavrnil, preložil ali dovolil pod pogoji. Vsaka vrstica mora vsebovati vsaj štiri elemente: sistem ali aplikacijo, na katero se sklep nanaša, ime in vlogo odločevalca, datum ter utemeljitev oziroma pridržek. Brez utemeljitve je seznam sklepov le seznam prisotnosti. Z utemeljitvijo postane dokaz, da je bilo premišljeno, ne le, da je bilo odkljukano.
Seznam mora ponujati tudi prostor za revizijo. Sklep, ki je bil sprejet pol leta nazaj na podlagi takrat razpoložljivih informacij, je lahko zastarel. Dober seznam sklepov pokaže, kdaj je bil sklep ponovno potrjen ali umaknjen, ne le, kdaj je bil prvotno sprejet.
Uprave in direkcije imajo že svoj ritem: četrtletne seje, komiteje za tveganja, revizijske komisije. Kdor postavi novo strukturo nadzora, ki je ločena od tega ritma, prosi ljudi, naj poiščejo dodaten čas za nekaj, kar nima jasnega mesta. To redko postane strukturno. Prvih nekaj krat morda uspe, z naporom. Nato izgine z dnevnega reda takoj, ko se pojavi nekaj bolj nujnega, in nekaj bolj nujnega se vedno pojavi.
Rešitev ni graditi nov proces, ampak seznamu sklepov omogočiti, da se navezuje na to, kar se že dogaja. Če že obstaja komite za tveganja, ki se sestaja vsako četrtletje, mora biti seznam sklepov o AI stalen del tega dnevnega reda, ne ločena seja. Če že obstaja revizijska sled za finančne sklepe, je treba logiko te sledi — kdo podpisuje, kdo preverja, kje se shranjuje — ponovno uporabiti za sklepe o AI. To je tudi razlog, zakaj je navezava na obstoječo strukturo tveganj samostojna tema: seznam sklepov, ki se ne navezuje na to, kako se tveganje že obravnava drugod, ostane izoliran dokument, ki ga nihče ne pregleduje.
Seznam sklepov ne deluje samostojno. Hrani poročanje, ki ga uprava potrebuje, da lahko trdi, da ima pregled nad tveganjem AI, in predpostavlja, da obstaja pot za primer, ko se izkaže, da sklep ni več vzdržen. Brez enostranskega poročila za upravni odbor, ki povzame seznam sklepov, informacija izgine v arhivu, ki ga nihče ne prebira. Brez poti eskalacije, ki delujejo, zastarel sklep preprosto obstane, ker nihče ne ve, komu ga sporočiti.
Vse tri so povezane: seznam sklepov zapisuje, kaj je bilo sklenjeno, poročanje to naredi vidno na ravni, kjer ima to težo, eskalacija pa poskrbi, da se sklep lahko ponovno odpre, ko se razmere spremenijo. Če zgradite enega brez drugih dveh, nastane navidezen pregled, ki se ob prvem preizkusu — incidentu, vprašanju nadzornika, novinarju — izkaže, da ne pokriva tega, kar se dejansko dogaja.
Seznam sklepov je toliko dober, kolikor dobre so informacije, ki gredo vanj. Če nihče ne ve, kateri AI-sistemi so dejansko v uporabi — vključno s tem, kar je bilo nabavljeno ali vzpostavljeno mimo IT — potem seznam zajema le sklepe o vidnih, formalno odobrenih aplikacijah. Preostalo ostane brez sklepa, ne ker sklep ni bil potreben, ampak ker nihče ni vedel, da obstaja kaj, o čemer bi bilo treba odločati. Zato inventar vedno pride pred seznamom sklepov, ne po njem. Kaj mora o tem vedeti član uprave, je opisano v kaj mora vedeti član uprave o tveganju AI; kaj mora CIO prepoznati v tem inventarju, je opisano v kaj mora vedeti CIO o tveganju AI.
Kaj je gotovo: seznam sklepov, ki se ne navezuje na obstoječi posvet, se ne vzdržuje, in seznam sklepov brez celovite slike o tem, kaj vse teče, zajame le del resničnosti. Kaj je odvisno od organizacije: kateri posvet je primerna sidrna točka, kako pogosto se ta posvet sestaja in kdo ima pooblastilo za sprejem sklepa, ki pride na seznam. To se razlikuje glede na panogo, strukturo upravljanja in kulturo tveganja, zato ni fiksne predloge, ki bi delovala povsod brez prilagoditve.
Responsible AI Scan je v izdelavi. Kdor trenutno potrebuje seznam sklepov, ki se navezuje na obstoječo strukturo, se lahko prijavi na čakalno listo; še se ne ponuja nič, česar še ni.
Seznam sklepov pove, kdo je odločal, ne pa, koliko dela sistem dejansko prevzame ali bi lahko prevzel. Za to vprašanje — kateri del naloge se lahko prenese na AI in kateri ne — je potreben drugačen pogled, kot ga ponuja zgolj upravljanje. Delovni sken FTE TO AI za posamezno nalogo izračuna, kateri del dela je mogoče prevzeti, kot dopolnilo pregledu, ki ga ponujata seznam sklepov in pripadajoča struktura nadzora.
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.