Seznam odločitev za nadzor ni nov obrazec in ni nov sestanek. Je stalno mesto, kjer se zabeleži, katera AI-aplikacija je bila ocenjena, kdo jo je ocenil, na podlagi katere ocene tveganja, in s katero odločitvijo. Odobreno, zavrnjeno, pod pogoji ali začasno dovoljeno v pričakovanju nadaljnje preiskave. Brez tega seznama odločitev obstaja le v spominu tistih, ki so bili prisotni, in izgine, brž ko nekdo zamenja funkcijo ali pogovor ni bil zapisan v zapisnik.
Seznam za vsako aplikacijo vsebuje kratek opis naloge, klasifikacijo po vlogi in stopnji tveganja, ime lastnika procesa, datum ocene, sprejeto odločitev in razlog zanjo. Brez tehnične specifikacije, brez dokumentacije dobavitelja: to sodi v dosje same aplikacije, ne v seznam odločitev. Seznam je pregled na eno raven višje — kdo je odločil kaj in kdaj je bila ta odločitev nazadnje ponovno potrjena. Aplikacija, ki je bila pred letom dni odobrena za nalogo z omejenim tveganjem, se lahko medtem uporablja za nekaj drugega. Brez občasne ponovne potrditve stara odločitev še naprej velja za situacijo, ki ne obstaja več.
Razlog, da ločeni registri AI pogosto ostanejo prazni, ni nevoljnost, temveč vrstni red. Vsaka organizacija že ima mesto, kjer se tveganja obravnavajo in beležijo: odbor za tveganja, revizijsko komisijo, sestanek uprave s stalno točko dnevnega reda o operativnem tveganju. Kdor poleg tega vzpostavi ločen dnevnik AI, od ljudi zahteva, da vodijo drugo evidenco za nekaj, kar vsebinsko sodi k prvi. Ta drugi proces sistematično izgublja proti vsakodnevnim pritiskom. Seznam odločitev za nadzor deluje le, če je vgrajen v obstoječe strukture — kot stalen del obstoječega posveta, s stalnim mestom na dnevnem redu, namesto kot nova dodatna obveznost.
To pomeni tudi, da seznam uporablja enako lestvico in jezik kot preostala struktura obvladovanja tveganj. Aplikacija z visoko stopnjo tveganja dobi enako vrsto pozornosti kot kateri koli drug dosje z visoko stopnjo tveganja: stalno pogostost poročanja, stalnega lastnika, stalno linijo eskalacije. Kako ta povezava izgleda v praksi, je odvisno od obstoječega upravljanja organizacije in je opisano na strani o priključitvi na obstoječo strukturo obvladovanja tveganj.
Seznam odločitev je neuporaben brez poti za to, kaj se zgodi, ko se nekdo z njim ne strinja, ali ko se aplikacija spremeni, ne da bi kdo to sporočil. Ta pot ne sodi v sam seznam, mora pa se nanj navezovati: kdo lahko izpodbija zavrnitev, kdo mora podaljšati začasno dovoljenje in h komu pride zadeva, kadar se lastnik procesa in funkcija za tveganja ne strinjata. Kako te linije potekajo, ne da bi vsako vprašanje pristalo na vrhu organizacije, je opisano na strani o eskalacijskih poteh, ki delujejo.
Seznam odločitev je spomin; uprava poleg tega potrebuje povzetek, ki ga ni treba vsako četrtletje znova sestavljati iz posameznih zapisnikov. Kaj mora vsebovati ta povzetek — in česa ravno ne, ker je to že v seznamu odločitev — je opisano na strani o poročilu za upravo na eni strani. Brez tega koraka seznam odločitev ostane dokument, ki ga berejo le lastniki procesov, medtem ko uprava ostaja pravno odgovorna za sprejete odločitve.
Zabeležiti odločitev ni enako kot vedeti, ali se odločitev tudi upošteva. Aplikacija, ki je bila zavrnjena, lahko vseeno ostane v uporabi, če nihče ne preveri, ali je bila zavrnitev tudi izvedena. To je razlog, da seznam odločitev brez nadaljnjega ukrepanja prinese le malo: dokumentira namene, ne vedenja. Kaj je potrebno, da se ugotovi, ali odločitev tudi drži, in kateri signali sodijo zraven, je opisano na strani o spremljanju, ki resnično prinaša rezultate.
Seznam odločitev lahko vsebuje le tisto, kar je bilo prijavljeno. Kdor je odvisen od prijav prek IT-oddelka, vidi le delček tega, kar se resnično uporablja: največji del uporabe AI v organizaciji nastane zunaj formalnih postopkov nabave, v ekipah, ki preizkusijo orodje, ker deluje. Ali te aplikacije kdaj pristanejo na seznamu odločitev, je odvisno od tega, ali si zaposleni upajo povedati, kaj uporabljajo — in to se zgodi le, če vprašanja o tem ne dajejo občutka predsobe za sankcijo.
Prvo vprašanje, ki pri tem pomaga, ni 'katera AI je odobrena', temveč 'kateri del tega dela pravzaprav že opravlja, ali bi lahko opravljala, AI'. To je drugačen pristop kot seznam odločitev, in popolnejše izhodišče: delovni sken podjetja FTE TO AI za vsako nalogo izračuna, kateri delež dela je mogoče prevzeti z AI, s čimer postavi osnovo, ki ni odvisna od tega, kaj je bilo naključno prijavljeno. Iz tega rezultata postane vidno, katere aplikacije pravzaprav že delujejo, še preden je seznam odločitev sploh kdaj izvedel zanje.
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.