Egy testület rendszeresen kap jelentéseket: pénzügyi, operatív, valamint kockázatokról szólót, amelyek már helyet kaptak a meglévő struktúrában. Egy AI-ról szóló jelentés, amely ettől elszigetelten áll, saját ritmussal és saját formátummal, a gyakorlatban kimarad. Nem azért, mert a téma nem fontos, hanem mert egy második folyamat egy meglévő folyamat mellett külön erőfeszítést igényel, amely versenyben áll mindennel, ami már a napirenden szerepel. Amit valóban elolvasnak, az az, ami beleillik a meglévő beszámolási vonalba: ugyanaz a ritmus, ugyanaz a hosszúság, ugyanaz a hely az ülésen.
Egy testületi jelentésnek az AI-ról nincs szüksége teljes technikai leltárra. A testületnek egy korlátozott számú kérdésre van szüksége válaszra: milyen AI-alkalmazások léteznek, melyik kockázati kategóriába tartoznak, mi változott az előző jelentés óta, és volt-e eszkaláció. Ez utóbbi pont az, ahol a legtöbb jelentés üres marad — nem azért, mert semmi nem történik, hanem azért, mert nincs útvonal, amelyen egy jelzés eljut a testülethez. Működő eszkalációs útvonalak, amelyek működnek nélkül egy jelentés csak egy pillanatfelvétel történet nélkül: megmutatja, mi van most, nem azt, hogy mi ment félre vagy majdnem félre útközben.
A jelentés arra támaszkodik, amit már rögzítettek. Egy oversight-döntéslista arról, ki mit hagyott jóvá, az a forrás, amelyből az oldal összesűrítve készül, nem egy külön dokumentum, amely mellette létezik. Amit az oldal tartalmaz, az a már meghozott döntések összesűrítése; nem egy új értékelés, amelyet a testületnek magának kell elvégeznie nyers adatok alapján.
A szervezeteknek már van kockázati struktúrájuk: egy auditbizottság, egy kockázati bizottság, egy állandó helyszín az operatív kockázatok számára a testületi napirenden. Egy AI-jelentés, amely saját bizottságot, saját naptárt vagy saját sablont vezet be, mindenkitől, aki már részt vesz benne, azt kéri, hogy tegyen valami extrát azon felül, amit már csinál. Ez az extra munka elhalasztódik, amint a napirend megtelik, és a napirend mindig megtelik. Ennek eredménye, hogy a jelentés néhány alkalom után elmarad, nem azért, mert valaki úgy döntött, hogy az AI-kockázat nem fontos, hanem mert senki nem döntött úgy, hogy fontosabb annál, amit már ott van.
A megoldás nem a téma nagyobb hangsúlyozásában van, hanem a felvételekor keletkező kevesebb frikcióban. Egy oldal, amely ugyanabban a negyedéves ritmusban jelenik meg, mint a többi kockázati jelentés, amely ugyanazt az elrendezést használja és ugyanazon a helyen van a csomagban, azért olvassák el, mert az elolvasása nem igényel külön műveletet. Amit nem működik, az egy külön AI-governance-ciklus, amely a meglévő ciklustól elkülönítve fut — ezt ignorálják, amint eljön az első zsúfolt hónap.
Egy egyoldalas jelentés csak akkor lehet rövid, ha az alapul szolgáló struktúra teljes. Feltételez egy mit kell tudnia egy testületi tagnak az AI-kockázatról-jellegű áttekintést a szerepekről és felelősségekről, hogy az oldalnak ne kelljen minden alkalommal újra elmagyaráznia, ki miért felelős. Feltételez egy leltárt, amely nem csak azt tartalmazza, amit az IT jóváhagyott, hanem azt is, amit az osztályok maguk kezdtek el használni anélkül, hogy ezt jelentették volna — árnyék-AI, amely csak akkor válik láthatóvá, ha az embereknek megengedik, hogy következmények nélkül elmondják, mit használnak valójában. Egy jelentés, amely csak a jóváhagyott listát mutatja, egy fikciót jelent.
Az oldal azt is feltételezi, hogy a jelentések között is történik valami: monitoring, amely valamit eredményez helyette egy naplónak, amelyet senki nem néz meg. E közbenső réteg nélkül a negyedéves oldal minden kiadásnál meglepetés, helyette egy összefoglalója valaminek, amit már az egész negyedévben követtek. És feltételezi, hogy az alapul szolgáló irányelv nem csak formaság dokumentáció, hanem egy AI-irányelv, amelyet elolvasnak azok az emberek, akik a rendszereket naponta használják — mert egy jelentés egy irányelvnek való megfelelésről, amelyet senki sem ismer, elsősorban önmagáról szól.
A testületi oldal egy összesűrítés; az alátámasztás egy réteggel lejjebb található, annál, aki a rendszereket ismeri. Amit egy CIO ehhez hozzátesz, az le van írva a mit kell tudnia egy CIO-nak az AI-kockázatról oldalon, és ezeknek a két rétegnek — a testületi áttekintésnek és az operatív tudásnak — illeszkednie kell egymáshoz, mielőtt a negyedórás olvasási idejű oldal valóban valamit mondana arról, mi történik a szervezetben.
Ez a struktúra épül, nem kész termékként kínálják. Aki azt a szkennelést szeretné, amely ezt a leltárt, osztályozást és beszámolási struktúrát eredményezi, várólistára kerül; ez épülőben van, és nem kész eszközként adják el, mielőtt valóban azzá válna.
Ha egyszer tisztázódott, milyen AI működik és milyen kockázati kategóriába tartozik, egy másik kérdés következik, amely nem a kockázatról szól, hanem a munka magának a berendezéséről: mely feladatok azon részéből, amelyeket most végeznek, alkalmasak arra, hogy az AI vegye át. Ez egy külön számítás, amely nem kockázatra, hanem feladatokra épül. A FTE TO AI munkaszkennere feladatonként kiszámítja, mely rész a munkából alkalmas az átvételre, mint következő lépés, amint tisztázódott, mi van már az AI-ból a szervezetben.
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.