Sageli on olemas juba dokument pealkirjaga eskaleerimisprotseduur. Selles on skeem noolte, nimede rea ja mõne lävendiga. Probleem ei ole see, et dokument puudub. Probleem on see, et keegi ei ava seda hetkel, mil see vajalik on.
See ei juhtu tahtmatuse tõttu. See juhtub, kuna juba on olemas tee, mille kaudu probleemid üles jõuavad: liinijuht, kes teatab IT-intsidendist, vastavusametnik, kes räägib äriga, meeskonnajuht, kes viib oma probleemi otse oma juhi ette. See tee on olemas, seda kasutatakse igapäevaselt ja see toimib — asjade jaoks, milleks see loodud on. Uus, spetsiaalselt AI-intsidentide jaoks mõeldud eskaleerimistee on siis teine marsruut kõrvuti juba toimiva marsruudiga. Kahtluse korral valib igaüks marsruudi, mida ta tunneb.
Eskaleerimistee, mis on eraldiseisev olemasolevast struktuurist, eeldab töötajalt, et ta esmalt tuvastab, et tegemist on AI-intsidendiga, seejärel meenutab, et selleks kehtib teine protsess, ja siis võtab ette selle protsessi järgimise, selle asemel, et lihtsalt oma juhile helistada. Iga selle ahela lüli on hetk, mil teest loobutakse.
Lisandub teine põhjus, vähem nähtav, kuid samavõrra määrav: kes teatab kõrvalekaldest, ei taha kohe organisatsiooni intsidendivormil figureerida. Kui eskaleerimine võrdub karistusega, ei eskaleerita. See kehdib nii töötaja kohta, kes kasutas AI-tööriista, mida ei olnud heaks kiidetud, kui ka juhi kohta, kes lasi mudelil töötada, ilma et keegi sellest teadnud oleks. Eskaleerimistee, mida tegelikult kasutatakse, on tee, kus esimene teavitus ei ole hukkamõist, vaid signaal.
Toimiv eskaleerimistee kirjeldab kolme asja, mitte enamat.
Kes midagi märkab — töötaja, klient, väline osapool — peab teadma, kelle poole ta pöörduda saab, ilma et ta peaks eelnevalt välja selgitama, kas see on AI-küsimus või tavaline operatiivküsimus. Tee peab sobituma juba olemasoleva teavitamispunktiga, koos täiendava hargnemisega hetkel, mil selgub, et AI on sellega seotud.
Kes teeb otsuse — kas midagi peatatakse, kohandatakse või teavitatakse järelevalveasutusele — peab olema kindlaks määratud enne, kui intsident aset leiab. Mitte abstraktse ametinimetusena, vaid nimena, koos asendajaga. Eskaleerimine, mis takerdub tühja mandaadi taha, ei ole eskaleerimine.
See, mis edasi teavitajaga juhtub, peab olema selge. Kui teine protsess koosneb ainult teavitamiskohustusest, selgusetuse tõttu tagajärgede osas teavitaja jaoks, hoidutakse sellest. Just seal peitub varju-AI: mitte süsteemides, mida IT tunneb, vaid tööriistades, mida keegi on hakanud kasutama, sellest teavitamata, kuna teavitamine tundus ülestunnistusena.
Lahendus ei ole paksem dokument. See on eskaleerimistee, mis kasutab juba olemasolevat struktuuri — teavitamispunkti, eskaleerimisliini, riskikomiteed — ja lisab sellele AI-spetsiifilise hargnemise punktides, kus see vahet teeb. Kuidas see sobitamine täpselt toimib, ka laiema poliitika ja järelevalveorgani otsuste nimekirja jaoks, on kirjeldatud kuidas saada AI-poliitika, mida loetakse, kuna see on põimitud olemasolevaga ja kuidas saada järelevalve otsuste nimekiri, mis sobitub olemasoleva otsustusrütmiga. Mõlemad dokumendid puudutavad sama punkti: protsess, mis seisab organisatsiooni kõrval, jäetakse ignoreerimatuks; protsess, mis on selle sees, järgitakse.
Seda põhimõtet ei kohaldata ainult eskaleerimisele. See kehtib kogu AI-ga seotud juhtimisstruktuuri kohta. Kes soovib teada, kuidas see laiemalt välja näeb — kuidas riskiklassifikatsioon sobitub olemasolevate riskikategooriatega, kuidas sobitumine olemasoleva riskistruktuuriga hoiab ära paralleelse bürokraatia tekke — leiab seal aluspõhimõtte. Sama kehtib ka ülemuste teavitamise kohta: ühe lehekülje pikkune juhatuse raport toimib ainult, kui sinna kirjutatud eskaleerimised on ka tegelikult teatatud. Ja pideva jälgimiseta selle kohta, mis muutub, vananeb iga eskaleerimistee aasta jooksul; mida see praktikas tähendab, on selgitatud lehel seire, mis midagi annab.
Eskaleerimisteed on võimalik kirjutada ainult siis, kui on teada, mis saab eskaleeruda. Kuni keegi ei tea, milline AI organisatsioonis töötab — kaasa arvatud see, mida ei kiidetud heaks — jääb dokument teoreetiliseks. Seetõttu ei alga Responsible AI Scan eskaleerimisteest, vaid inventuurist: mis töötab, kes kasutab seda ja milline riskitase sellele sobib. Ainult selle põhjal saab kirjutada eskaleerimistee, mis sobitub juba olemasolevaga, mitte sellega, mis paberil olemas peaks olema.
Eskaleerimisteed käsitlevad seda, mis läheb valesti juba kasutuses oleva AI-ga. Teine küsimus, samuti liiga vähe tähelepanu saanud, on see, kus AI võiks töö enda üle võtta. FTE TO AI töö-skann arvutab ülesande kaupa välja, milline osa tööst selleks kõlblik on, sõltumata sellest, kas see juba toimub või tuleb see veel korraldada.
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.