En eskaleringsväg för AI-incidenter som placeras vid sidan av den befintliga strukturen blir i praktiken förbisedd. Inte därför att ingen vill använda den, utan därför att det redan finns en väg: för dataintrång, för klagomål, för operativa störningar. Den som vid ett incidenttillfälle måste välja mellan två vägar, väljer den väg han redan känner. En andra process vid sidan av den första är ingen extra säkerhet, det är en avgrening som försvinner under tryck vid den första.
Frågan är inte om det ska finnas en eskaleringsväg. Frågan är var den kopplas in. En eskaleringsväg för AI fungerar när den inte öppnar en ny lucka, utan ger en befintlig lucka en extra ingång. Det innebär: samma anmälningsstruktur som redan används för incidenter, kompletterad med en fråga som anger om AI spelade en roll. Samma ägare som redan är ansvarig för riskhantering, med en tydlig bild av när en AI-relaterad signal ska hamna hos honom. Samma rapporteringslinje uppåt, utan en separat AI-linje bredvid.
Vad som ska ingå är därmed mindre en lista med steg och mer en uppsättning anslutningspunkter: vem anmäler, var det kommer in, vem bedömer om det eskalerar, och till vem. Vid varje sådan punkt är frågan inte "hur borde detta fungera" utan "var sker detta redan, och vad måste läggas till där för att inkludera AI". En eskaleringsväg som är uppbyggd på det sättet behöver ingen separat instruktion, eftersom den inte kräver något annat beteende än det som redan är känt.
Det finns ett igenkännbart mönster: en organisation skapar en AI-specifik process, med ett eget formulär, en egen kommitté, ett eget rapporteringstillfälle. På pappret är det komplett. I praktiken ignoreras det, och inte av ovilja. En andra process kräver att någon vid ett incidenttillfälle först avgör om det handlar om AI innan han vet vilken väg han ska följa. Det extra steget faller bort så snart det är tidspress, och den befintliga vägen — den väg som redan används för liknande situationer — vinner.
Därtill kommer att en separat AI-process oftast får en egen ägare, skild från den som redan är ansvarig för riskeskalering i allmänhet. Det splittrar överblicken vid ett tillfälle då överblick behövs. Den som får en signal om ett AI-system som inte fungerar som avsett måste kunna placera den bredvid andra risksignaler, inte i en isolerad kanal där den bedöms fristående från resten av organisationen.
Inbäddning innebär att eskaleringsvägen för AI inte är en synlig separat del, utan en utbyggnad av det som redan finns. Det kräver ett par konkreta val, oavsett bransch: vilken befintlig anmälningskanal får frågan om AI-inblandning tillagd, vilken befintlig riskägare får befogenheten att bedöma om något ska gå vidare, och vid vilket befintligt rapporteringstillfälle tas AI med i stället för att sätta ett nytt tillfälle bredvid.
De valen beror på hur organisationen redan är uppbyggd. En organisation med en stark compliance-funktion lägger bedömningen där; en organisation där riskhantering är placerad hos den operativa linjen, lägger den där. Det finns inget fast schema som ger samma eskaleringsväg för alla organisationer, eftersom eskaleringsvägen per definition är en avspegling av strukturen den läggs in i.
Denna inbäddning berör hur risker redan indelas — hur den anslutningen till den befintliga riskstrukturen ser ut beskrivs på sidan om anslutning till befintlig riskklassificering — och vad som händer med en eskalering när den når styrelsebordet, som beskrivs på sidan om en styrelserapport som får plats på en sida. Utan den anslutningen förblir en eskaleringsväg ett dokument som ligger någonstans, i stället för en väg som någon faktiskt följer när det behövs.
En eskaleringsväg är bara till nytta om det finns något som eskalerar. Det kräver en form av övervakning som ger signaler innan en incident inträffar, inte bara en rekonstruktion efteråt. Hur den övervakningsdelen byggs upp utan att den blir en ny rapporteringsbörda beskrivs på sidan om övervakning som ansluter till befintlig rapportering i stället för att lägga till ett nytt lager. Tillsammans bildar inventering, övervakning och eskalering en kedja: utan en av de tre fungerar inte resten fullt ut heller.
Den som ritar upp denna väg gör det oftast utifrån en roll med ansvar för risk eller styrning. Vad en styrelseledamot i detta sammanhang bör veta sammanfattas på sidan vad en styrelseledamot bör veta om AI-risk; den tekniska och operativa sidan av samma fråga finns på sidan vad en CIO bör veta om AI-risk. Båda infallsvinklarna möts i själva eskaleringsvägen, som verkar i skärningspunkten mellan styrelseansvar och operativt genomförande.
Denna sida beskriver mekanismen; den exakta utformningen beror på organisationen och fastställs inte här. FTE TO AI arbetar på verktyg som stödjer denna inbäddning; den som redan arbetar med detta kan anmäla sig till väntelistan.
En eskaleringsväg reglerar vad som händer så snart något går fel eller hotar att gå fel. En annan fråga, som ofta förblir fristående vid sidan om, är vad AI redan gör dagligen i det vanliga arbetet. Arbetsskanningen från FTE TO AI räknar per uppgift ut vilken del av arbetet som kan tas över av AI, och ger därmed en bild av den sida av AI-användning som inte är tillfällig, utan strukturell — en bild som är nyttig vid sidan av den riskinventering som denna sida handlar om.
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.