Minden szervezet, amely elér egy bizonyos méretet, már rendelkezik kockázati struktúrával. Kockázati bizottság, audit funkció, jelentési vonal a vezetőség felé, egy formátum, amelyben a kockázatokat besorolják és nyomon követik. Aki ehhez egy új, kifejezetten AI-ra szabott folyamatot állít mellé, saját bizottsággal, saját naptárral és saját nyelvvel, egy éven belül olyan folyamatot kap, amelyet már senki nem tölt ki. Nem azért, mert az AI-t nem tartják fontosnak, hanem mert a második struktúra versenyben áll az elsővel az időért, a figyelemért és a mandátumért. A meglévő struktúra majdnem mindig győz, mert be van ágyazva az értékelésekbe, a teljesítményciklusokba és a vezetőségi napirendekbe. Az új struktúra ezen kívül áll.
A kérdés tehát nem az, hogyan épít fel egy AI-governance struktúrát. A kérdés az, hogyan kap az AI helyet a már meglévő struktúrában.
A legtöbb kockázati struktúra már tartalmaz néhány fix elemet: egy kockázati leltárt, amelyet rendszeresen frissítenek, egy súlyosság és valószínűség szerinti osztályozást, egy felelőst minden kockázathoz, egy eszkalációs vonalat magasabb szintre, ha egy határ átlépődik, és egy jelentést a vezetőség felé fix időpontokban. Ez az a struktúra, amelybe az AI-nak be kell illeszkednie, nem mellé.
Ez azt jelenti, hogy egy AI-alkalmazásnak nem egy külön AI-nyilvántartásban van a helye, hanem kockázati tételként a meglévő nyilvántartásban, ugyanazokkal a mezőkkel, mint bármely más kockázatnál: felelős, súlyosság, valószínűség, mitigáció, státusz dátuma. Az AI-használat leltárához tartozó, kockázati szint szerinti osztályozásnak a már használt, operatív kockázatokra vonatkozó skálához kell illeszkednie, nem egy csak az AI-ra kitalált új skálához. Aki elolvassa mit kell egy CIO-nak tudnia az AI-kockázatról című anyagot, láthatja, hogy pontosan ez az illeszkedés az, ahol gyakran hiba csúszik be: egy technikailag korrekt AI-kockázati pontszám, amelyet senki nem tud összehasonlítani a kockázati nyilvántartás többi részével.
Két dolog nehezíti a beágyazást. Az első a nyelv. A kockázatkezelők olyan fogalmakkal dolgoznak, mint hatás, valószínűség és mitigáló intézkedés. Az AI-beszállítók és a technikai csapatok modellverziókkal, tréningadatokkal és teljesítménymutatókkal dolgoznak. Egy governance-készletet, amely csak technikai nyelven van megírva, a kockázati bizottság nem fogja elolvasni. Egy governance-készletet, amely csak kockázati nyelven van megírva, a technikai felelős nem fogja kitölteni. A készletnek mindkét irányban olvashatónak kell lennie: elég technikainak, hogy helyes legyen, és elég vezetőinek szólónak, hogy megérthető legyen. Ez az elv visszatér egy olyan AI-szabályzatnál, amelyet elolvasnak: egy dokumentumnál, amely illeszkedik ahhoz, ahogyan az emberek már olvasnak és döntenek, helyette hogy új olvasási módot kényszerítene ki.
A második a tempó. Egy kockázati bizottság fix ciklusban ülésezik, gyakran negyedévente vagy havonta. Az AI-használat gyorsabban változik: egy csapat ezen a héten kezd egy új eszközzel, anélkül hogy ezt ülés előzné meg. A governance-készletnek ezért nem szabad függnie az ülésciklustól ahhoz, hogy működjön. Kell lennie egy könnyebb mechanizmusnak, amely a fix időpontok között felfogja az eltéréseket, és amelyet csak a következő ciklusnál erősítenek meg formálisan. Az, hogyan működik ez a mechanizmus a gyakorlatban, le van írva a működő eszkalációs útvonalaknál: egy útvonalnál, amely elég rövid ahhoz, hogy használható legyen, mielőtt a következő negyedéves bizottság összeül.
Egy governance-készlet, amely illeszkedik a meglévő kockázati struktúrához, nagy vonalakban a következőket tartalmazza: egy leltártételt minden AI-alkalmazáshoz, felelőssel és kockázati osztállyal, egy kapcsolatot a meglévő eszkalációs útvonalhoz, hogy egy eltérés ne egy külön csatornán tűnjön el, és egy fix helyet a vezetőség felé történő rendszeres jelentésben. Nem külön AI-fejezetként, hanem sorként azon a táblázaton belül, amelyet a vezetőség már ismer. Az, hogyan nézhet ki ez a jelentés anélkül, hogy új formátumot vezetne be, le van írva itt: hogyan kapja meg egy oldalas board-jelentést beépítve abba, amit már használnak.
A szabályok tartalma maga, hogy pontosan mi tartozik melyik kockázati szinthez és milyen határidők vonatkoznak rá, máshol van rögzítve és változik; ez az oldal a mechanizmusról szól, amely ennek a tartalomnak helyet ad a meglévő struktúrában, nem a szabályok szövegéről.
A beágyazás csak akkor sikerül, ha a leltár először helyes. És az csak akkor helyes, ha az emberek merik elmondani, mit használnak. Aki a kockázati tétel kitöltésekor úgy érzi, hogy egy őszinte válasz megjegyzést von maga után egy értékelésben, nem fogja őszintén kitölteni. A governance-készletnek ezért már az első verziótól kezdve tisztáznia kell, hogy a cél az átláthatóság, nem a szankció. E vállalás nélkül a használat egy része kívül marad a látókörön, és a kockázati struktúrához való illeszkedés hiányos listára épül. Amit egy vezetőnek erről tudnia kell, mielőtt az első leltározás elkezdődik, le van írva itt: mit kell egy vezetőnek tudnia az AI-kockázatról.
Ez a beágyazás a kockázatról, a felelősségről és a jelentésről szól: gondoskodik arról, hogy amit az AI tesz, látható és kezelhető legyen a már meglévő struktúrán belül. Egy másik kérdés, amely logikusan következik ebből, amint megvan az átláthatóság, az, hogy az AI ezen a munkán belül valójában mit tud átvenni. A FTE TO AI munkascan feladatonként kiszámítja, hogy a munka mekkora része vehető át AI által, mint következő lépés, amint a governance-oldal rendben van.
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.