re-ai-gov Feliratkozás a várólistára

Kennisbank

Hogyan építi be az oversight-döntéslistát abba, ami már megvan

Egy oversight-döntéslista rögzíti, ki hozott milyen döntést melyik AI-rendszerről, milyen információ alapján, és milyen fenntartással. Ez egyszerűen hangzik. A gyakorlatban az első verzió gyakran megbukik, mert új folyamatként állítják be a meglévő megbeszélések mellé. Egy második, a meglévő mellé állított folyamatot figyelmen kívül hagynak, nem azért, mert az emberek nem hajlandók rá, hanem mert senki nem szán rá időt olyasmire, ami nem illeszkedik egy már így is zsúfolt napirendbe.

Mi tartozik egy döntéslistába

A lista nem tevékenységnapló és nem kockázati nyilvántartás. Döntéseket tartalmaz: pillanatokat, amikor valaki hatáskörrel rendelkező személy jóváhagyott, elutasított, elhalasztott vagy feltételekkel engedélyezett valamit. Soronként legalább négy elem szükséges: a rendszer vagy alkalmazás, amelyről a döntés szól, a döntéshozó neve és beosztása, a dátum, valamint az indoklás vagy a fenntartás. Indoklás nélkül a döntéslista csupán jelenléti ív. Indoklással viszont bizonyítékká válik arra, hogy volt gondolkodás, nem csak pipálgatás.

A listának teret kell adnia a felülvizsgálatnak is. Egy fél évvel korábban, akkor elérhető információ alapján hozott döntés mára elavulhat. Egy jó döntéslista megmutatja, mikor erősítettek meg vagy vontak vissza egy döntést, nem csak azt, mikor hozták eredetileg.

Miért hagyják figyelmen kívül a külön folyamatot

Az igazgatóságoknak és a vezetőségnek már megvan a saját ritmusuk: negyedéves üléseik, kockázati bizottságaik, audit bizottságaik. Aki ettől a ritmustól elszakadó, új oversight-struktúrát épít fel, azt kéri az emberektől, hogy találjanak extra időt olyasmire, aminek nincs egyértelmű helye. Ez ritkán valósul meg tartósan. Az első pár alkalommal erőfeszítéssel talán sikerül. Utána eltűnik a napirendről, mihelyt valami sürgősebb közbejön — és mindig közbejön valami sürgősebb.

A megoldás nem egy új folyamat felépítése, hanem az, hogy a döntéslista ráépüljön arra, ami már történik. Ha már van egy negyedévente ülésező kockázati bizottság, az AI-döntéslistának annak napirendjén állandó napirendi pontként kell szerepelnie, nem külön ülésként. Ha már létezik audit nyomvonal a pénzügyi döntésekhez, annak logikáját — ki ír alá, ki ellenőriz, hol tárolják — újra kell hasznosítani az AI-döntésekhez is. Ez az oka annak is, hogy a meglévő kockázati struktúrához való illeszkedés külön téma: egy döntéslista, amely nem illeszkedik ahhoz, ahogyan a kockázatot máshol már megbeszélik, elszigetelt dokumentum marad, amit senki nem néz meg.

A jelentéssel és az eszkalációval való kapcsolat

Egy döntéslista önmagában nem működik. Táplálja azt a jelentést, amelyre az igazgatóságnak szüksége van ahhoz, hogy kijelenthesse: rálátása van az AI-kockázatra, és feltételezi, hogy van egy útvonal arra az esetre, ha egy döntés már nem tartható tovább. Egy egyoldalas board-jelentés nélkül, amely összefoglalja a döntéslistát, az információ egy olyan archívumban tűnik el, amelyet senki nem lapoz át. Működő eszkalációs útvonalak nélkül egy elavult döntés egyszerűen érvényben marad, mert senki nem tudja, kinél kellene jelezni.

A három összefügg: a döntéslista rögzíti, mit döntöttek el, a jelentés láthatóvá teszi ezt azon a szinten, ahol súlya van, az eszkaláció pedig gondoskodik arról, hogy egy döntés újranyitható legyen, ha a helyzet megváltozik. Ha valaki egyet épít fel a másik kettő nélkül, akkor csak az áttekinthetőség látszata jön létre, amely az első próbánál — egy incidens, egy felügyeleti kérdés, egy újságíró — kiderül, hogy nem fedi azt, ami valójában történik.

Ki tölti fel a listát

Egy döntéslista annyit ér, amennyit a bekerülő információ ér. Ha senki nem tudja, ténylegesen milyen AI-rendszereket használnak — beleértve azokat is, amelyeket az IT-n kívül szereztek be vagy állítottak fel —, akkor a lista csak a látható, formálisan jóváhagyott alkalmazásokról szóló döntéseket rögzíti. A többi eldöntetlen marad, nem azért, mert nem volt szükség döntésre, hanem mert senki nem tudta, hogy van miről dönteni. Ezért előzi meg mindig a leltár a döntéslistát, nem pedig fordítva. Amit egy igazgatósági tagnak erről tudnia kell, azt amit egy igazgatósági tagnak tudnia kell az AI-kockázatról írja le; amit egy CIO-nak fel kell ismernie ebben a leltárban, azt amit egy CIO-nak tudnia kell az AI-kockázatról tartalmazza.

Mi biztos, és mi függ a szervezettől

Ami biztos: egy döntéslista, amely nem illeszkedik egy meglévő megbeszéléshez, nem lesz karbantartva, és egy döntéslista, amely nem ad teljes képet arról, mi van használatban, csak a valóság egy részét rögzíti. Ami a szervezettől függ: melyik megbeszélés a kijelölt horgonypont, milyen gyakran ülésezik az adott testület, és kinek van hatásköre olyan döntést hozni, amely bekerül a listába. Ez ágazatonként, vezetési struktúránként és kockázati kultúránként eltérő, ezért nincs olyan kész sablon, amely mindenhol módosítás nélkül működik.

A Responsible AI Scan jelenleg fejlesztés alatt áll. Aki most igényli a meglévő struktúrához illeszkedő döntéslistát, feliratkozhat a várólistára; egyelőre semmit nem kínálunk, ami még nem létezik.

Egy döntéslista azt mondja meg, ki döntött, nem azt, mennyi munkát vesz át ténylegesen vagy vehetne át egy rendszer. Erre a kérdésre — mely feladatrész adható át az AI-nak, és melyik nem — más nézőpont szükséges, mint amit a governance önmagában kínál. Az FTE TO AI munkaszkennere feladatonként kiszámítja, mekkora munkarész vehető át, kiegészítve azt az áttekintést, amelyet egy döntéslista és a hozzá tartozó oversight-struktúra nyújt.

Andrewde assistent van de Responsible AI Scan

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.