Gyakran már van egy dokumentum, amelynek címe eszkalációs eljárás. Van benne egy séma nyilakkal, egy sor névvel, és néhány küszöbértékkel. A probléma nem az, hogy a dokumentum hiányzik. A probléma az, hogy senki nem nyitja meg abban a pillanatban, amikor szükség lenne rá.
Ez nem akaratlanságból történik. Azért történik, mert már létezik egy útvonal, amelyen a problémák felfelé haladnak: a vonalvezető, aki bejelenti az IT-incidenst, a compliance-tisztviselő, aki a businesszel beszél, a csapatvezető, aki a saját problémáját a saját felettesénél teszi le. Ez az útvonal létezik, naponta használják, és működik — azokra a dolgokra, amelyekre szánták. Egy új eszkalációs útvonal, amely kifejezetten AI-incidensekre vonatkozik, ekkor egy második útvonal lesz egy már meglévő útvonal mellett. Kétség esetén mindenki azt az útvonalat választja, amelyet ismer.
Egy eszkalációs útvonal, amely elkülönül a meglévő struktúrától, azt kéri a munkavállalótól, hogy először felismerje, hogy valami AI-incidens, aztán emlékezzen arra, hogy erre másik folyamat vonatkozik, majd vegye a fáradságot, hogy azt a folyamatot követi, helyett hogy egyszerűen felhívja a felettesét. A lánc minden lépése egy olyan pillanat, amikor az útvonalat elhagyják.
Ehhez járul egy második ok, kevésbé látható, de ugyanolyan meghatározó: aki eltérést jelent, nem akar azonnal az organizáció incidensformájában szerepelni. Ha az eszkaláció egyenlő a felelősségre vonással, akkor nem eszkalálnak. Ez érvényes egy munkavállalóra, aki egy nem jóváhagyott AI-eszközt használt, és érvényes egy vezetőre, aki egy modellt futtatott anélkül, hogy bárki tudott volna róla. Egy eszkalációs útvonal, amelyet valóban használnak, olyan útvonal, amelynél az első bejelentés nem ítélet, hanem jelzés.
Egy eszkalációs útvonal, amely működik, három dolgot ír le, és nem többet.
Annak, aki valamit észlel — egy munkavállaló, egy ügyfél, egy külső fél — tudnia kell, kihez fordulhat anélkül, hogy előbb ki kellene derítenie, hogy AI-ügyről van-e szó, vagy egy szokásos operatív ügyről. Az útvonal illeszkedik a már létező bejelentőponthoz, egy extra elágazással azon a pillanaton, amikor kiderül, hogy AI is érintett.
Annak, aki a döntést hozza — arról, hogy valamit leállítanak, módosítanak vagy jelentenek egy felügyeleti hatóságnak — meg kell lennie rögzítve, mielőtt az incidens bekövetkezik. Nem absztrakt beosztásként, hanem névvel, és egy helyettessel. Az eszkaláció, amely egy üres mandátumnál elakad, nem eszkaláció.
Annak, hogy mi történik ezután a bejelentővel, világosnak kell lennie. Ha egy második folyamat csak egy bejelentési kötelezettségből áll, anélkül hogy tisztázná a bejelentőre vonatkozó következményeket, akkor kerülik. Pontosan itt bújik meg az árnyék-AI: nem azokban a rendszerekben, amelyeket az IT ismer, hanem azokban az eszközökben, amelyeket valaki elkezdett használni anélkül, hogy bejelentette volna, mert a bejelentés úgy érződött, mint egy beismerés.
A megoldás nem egy vastagabb dokumentum. Egy eszkalációs útvonal, amely a már meglévő struktúrát használja — a bejelentőpontot, az eszkalációs vonalat, a kockázati bizottságot — és ehhez egy AI-specifikus elágazást ad hozzá azokon a pontokon, ahol ez különbséget jelent. Az, hogy ez az illeszkedés pontosan hogyan működik, a szélesebb szabályzat és a felügyeleti szerv döntési listája vonatkozásában is, le van írva itt: hogyan kap olyan AI-szabályzatot, amelyet elolvasnak, mert be van ágyazva abba, ami már létezik és itt: hogyan kap olyan felügyeleti döntési listát, amely illeszkedik a meglévő döntéshozási ritmushoz. Mindkét dokumentum ugyanazt a pontot érinti: egy folyamat, amely a szervezet mellett áll, figyelmen kívül marad; egy folyamat, amely benne fekszik, azt követik.
Ez az alapelv nem csak az eszkalációra vonatkozik. A teljes AI körüli irányítási struktúrára vonatkozik. Aki tudni akarja, hogyan néz ez ki szélesebb kontextusban — hogyan illeszkedik a kockázati osztályozás a meglévő kockázati kategóriákhoz, hogyan előzi meg a meglévő kockázati struktúrához való illeszkedés, hogy egy párhuzamos bürokrácia keletkezzen — ott találja meg az alapelvet. Ugyanez érvényes a felfelé irányuló jelentésre: egy egyoldalas board-jelentés csak akkor működik, ha a benne szereplő eszkalációk valóban be lettek jelentve. És a változások folyamatos megfigyelése nélkül minden eszkalációs útvonal egy éven belül elavul; mit jelent ez a gyakorlatban, azt itt magyarázzuk: monitoring, amely valamit hoz.
Egy eszkalációs útvonalat csak akkor lehet megírni, ha ismert, mi eszkalálódhat. Amíg senki nem tudja, milyen AI működik a szervezetben — beleértve azt, amit nem hagytak jóvá — a dokumentum elméleti marad. A Responsible AI Scan ezért nem az eszkalációs útvonalnál kezdődik, hanem a leltárnál: mi működik, ki használja, és milyen kockázati szint illik hozzá. Csak ez alapján lehet olyan eszkalációs útvonalat megírni, amely illeszkedik ahhoz, ami már létezik, helyett ahhoz, aminek papíron kellene léteznie.
Az eszkalációs útvonalak arról szólnak, hogy mi mehet rosszul a már használt AI-val. Egy másik kérdés, ugyanolyan alulreprezentált, hogy hol vehetné át az AI magát a munkát. Az FTE TO AI munkaszkennere feladatonként kiszámítja, hogy a munka mekkora része alkalmas erre, függetlenül attól, hogy ez már megtörtént-e, vagy még ki kell alakítani.
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.