En beslutningsliste for oversight registrerer, hvem der traf hvilken beslutning om hvilket AI-system, på baggrund af hvilken information, og med hvilket forbehold. Det lyder enkelt. I praksis mislykkes den første version ofte, fordi den bliver opstillet som en ny proces sideløbende med eksisterende møder. En anden proces sideløbende med den eksisterende bliver ignoreret, ikke fordi folk er uvillige, men fordi ingen afsætter tid til noget, der ikke passer ind i en dagsorden, der allerede er fuld.
Listen er ikke en aktivitetslog og heller ikke et risikoregister. Den indeholder beslutninger: øjeblikke hvor en person med beslutningskompetence godkendte, afviste, udskød eller lod noget fortsætte under betingelser. Hver linje bør som minimum indeholde fire elementer: det system eller den anvendelse, beslutningen handler om, navnet og rollen på beslutningstageren, datoen og begrundelsen eller forbeholdet. Uden begrundelse er en beslutningsliste en fremmødeliste. Med begrundelse bliver den beviset på, at der er blevet tænkt, ikke blot at der er blevet sat kryds.
Listen bør også give plads til revision. En beslutning, der blev truffet et halvt år tidligere på baggrund af den information, der dengang var tilgængelig, kan være forældet. En god beslutningsliste viser, hvornår en beslutning er blevet bekræftet igen eller trukket tilbage, ikke kun hvornår den oprindeligt blev truffet.
Bestyrelser og direktioner har allerede en rytme: kvartalsmøder, risikoudvalg, revisionsudvalg. Den, der opsætter en ny oversight-struktur, som er løsrevet fra den rytme, ber folk om at finde ekstra tid til noget, der ikke har en klar plads. Det sker sjældent strukturelt. De første par gange lykkes det måske med en indsats. Derefter forsvinder det fra dagsordenen, så snart noget mere presserende dukker op, og der dukker altid noget mere presserende op.
Løsningen er ikke at bygge en ny proces, men at lade beslutningslisten koble sig på det, der allerede sker. Hvis der allerede findes et risikoudvalg, der samles hvert kvartal, bør AI-beslutningslisten være et fast punkt på den dagsorden, ikke en separat session. Hvis der allerede findes et revisionsspor for finansielle beslutninger, bør logikken i det spor — hvem underskriver, hvem kontrollerer, hvor det opbevares — genbruges til AI-beslutninger. Det er også grunden til, at tilknytning til den eksisterende risikostruktur er et separat emne: en beslutningsliste, der ikke kobles til, hvordan risiko allerede diskuteres andre steder, bliver et isoleret dokument, som ingen konsulterer.
En beslutningsliste fungerer ikke i sig selv. Den nærer den rapportering, en bestyrelse har brug for for at kunne sige, at der er overblik over AI-risiko, og den forudsætter, at der findes en vej for, når en beslutning ikke længere kan forsvares. Uden en board-rapportering på en side, der opsummerer beslutningslisten, forsvinder informationen i et arkiv, som ingen blader igennem. Uden eskaleringsveje, der fungerer forbliver en forældet beslutning simpelthen stående, fordi ingen ved, hvem den skal rejses hos.
De tre hænger sammen: beslutningslisten fastlægger, hvad der er blevet besluttet, rapporteringen gør det synligt på det niveau, hvor det har betydning, og eskalering sørger for, at en beslutning kan genoptages, hvis situationen ændrer sig. Bygger man den ene uden de andre to, opstår et skin af overblik, som ved den første prøve — en hændelse, et spørgsmål fra en tilsynsmyndighed, en journalist — ikke viser sig at dække det, der virkelig sker.
En beslutningsliste er kun så god som den information, der kommer ind i den. Hvis ingen ved, hvilke AI-systemer der faktisk er i brug — inklusive det, der er anskaffet eller sat op uden om IT — registrerer listen kun beslutninger om de synlige, formelt godkendte anvendelser. Resten forbliver ubesluttet, ikke fordi der ikke var brug for en beslutning, men fordi ingen vidste, at der var noget at beslutte om. Det er grunden til, at en oversigt altid går forud for en beslutningsliste, ikke kommer efter den. Hvad en bestyrelsesmedlem bør vide om det, er beskrevet i hvad en bestyrelsesmedlem skal vide om AI-risiko; hvad en CIO bør genkende i den kortlægning, står i hvad en CIO skal vide om AI-risiko.
Hvad der står fast: en beslutningsliste uden kobling til et eksisterende møde bliver ikke vedligeholdt, og en beslutningsliste uden fuldt overblik over, hvad der er i drift, registrerer kun en del af virkeligheden. Hvad der afhænger af organisationen: hvilket møde der er det rette forankringspunkt, hvor ofte det møde samles, og hvem der har kompetencen til at træffe en beslutning, som ender på listen. Det varierer efter sektor, bestyrelsesstruktur og risikokultur, og derfor findes der ingen fast skabelon, der fungerer overalt uden tilpasning.
Responsible AI Scan er under opbygning. Den, der lige nu har brug for en beslutningsliste, der kobler sig på den eksisterende struktur, kan tilmelde sig ventelisten; der udbydes endnu ikke noget, som ikke allerede findes.
En beslutningsliste siger, hvem der besluttede, ikke hvor meget arbejde et system faktisk overtager eller kunne overtage. Til det spørgsmål — hvilken del af en opgave der kan overdrages til AI, og hvilken del der ikke kan — er der brug for et andet blik end det, governance alene giver. Werkscan fra FTE TO AI beregner pr. opgave, hvilken del af arbejdet der kan overtages, som et supplement til det overblik, en beslutningsliste og den tilhørende oversight-struktur giver.
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.