En oversight-beslutslogg registrerar vem som fattade vilket beslut om vilket AI-system, utifrån vilken information, och med vilket förbehåll. Det låter enkelt. I praktiken misslyckas den första versionen ofta eftersom den sätts upp som en ny process bredvid befintliga möten. En andra process bredvid den befintliga blir ignorerad, inte eftersom människor är ovilliga, utan eftersom ingen avsätter tid för något som inte passar in i en agenda som redan är full.
Listan är inget aktivitetslogg och inget riskregister. Den innehåller beslut: ögonblick då någon med behörighet godkände, avslog, sköt upp eller lät något fortsätta under villkor. Per rad hör minst fyra element: systemet eller tillämpningen som beslutet gäller, namnet och rollen på beslutsfattaren, datumet, och motiveringen eller förbehållet. Utan motivering är en beslutslogg en närvarolista. Med motivering blir den beviset att man har tänkt igenom saken, inte bara att man har kryssat av.
Listan bör också ge utrymme för omprövning. Ett beslut som fattades för ett halvår sedan utifrån den information som då fanns tillgänglig kan vara inaktuellt. En god beslutslogg visar när ett beslut har bekräftats på nytt eller dragits tillbaka, inte bara när det ursprungligen fattades.
Styrelser och ledningar har redan ett rytm: kvartalsmöten, riskkommittéer, revisionsutskott. Den som sätter upp en ny oversight-struktur som står fristående från den rytmen ber människor att hitta extra tid för något som inte har en tydlig plats. Det sker sällan strukturerat. De första gångerna kan det gå, med ansträngning. Därefter försvinner det från agendan så snart något mer akut dyker upp, och något mer akut dyker alltid upp.
Lösningen är inte att bygga en ny process, utan att låta beslutslistan kopplas till det som redan sker. Om det redan finns en riskkommitté som sammanträder varje kvartal, bör AI-beslutslistan vara en fast punkt på den agendan, inte en separat session. Om det redan finns ett revisionsspår för finansiella beslut, bör logiken i det spåret — vem undertecknar, vem kontrollerar, var det lagras — återanvändas för AI-beslut. Det är också anledningen till att koppling till den befintliga riskstrukturen är ett separat ämne: en beslutslogg som inte kopplas till hur risk redan diskuteras på andra håll förblir ett isolerat dokument som ingen konsulterar.
En beslutslogg fungerar inte fristående. Den förser den rapportering som en styrelse behöver för att kunna säga att man har överblick över AI-risk, och den förutsätter att det finns en väg för när ett beslut visar sig inte längre hålla. Utan en styrelserapport på en sida som sammanfattar beslutslistan försvinner informationen i ett arkiv som ingen bläddrar igenom. Utan eskaleringsvägar som fungerar blir ett beslut som är inaktuellt bara kvar, eftersom ingen vet vem man ska ta upp det med.
De tre hänger samman: beslutslistan fastställer vad som har beslutats, rapporteringen gör det synligt på den nivå där det har tyngd, och eskalering gör att ett beslut kan tas upp igen om situationen förändras. Bygger man en av dem utan de andra två uppstår en sken av överblick som vid det första provet — en incident, en fråga från en tillsynsmyndighet, en journalist — visar sig inte täcka vad som verkligen sker.
En beslutslogg är bara så bra som informationen som förs in i den. Om ingen vet vilka AI-system som faktiskt används — inklusive vad som har anskaffats eller satts upp utanför IT — registrerar listan bara beslut om de synliga, formellt godkända tillämpningarna. Resten förblir obeslutat, inte eftersom det inte behövdes ett beslut, utan eftersom ingen visste att det fanns något att besluta om. Det är varför en inventering alltid föregår en beslutslogg, inte kommer efter den. Vad en styrelseledamot bör veta om detta beskrivs i vad en styrelseledamot bör veta om AI-risk; vad en CIO bör känna igen i den inventeringen beskrivs i vad en CIO bör veta om AI-risk.
Vad som står fast: en beslutslogg utan koppling till ett befintligt möte underhålls inte, och en beslutslogg utan fullständig bild av vad som är i drift registrerar bara en del av verkligheten. Vad som beror på organisationen: vilket möte som är den lämpliga ankarpunkten, hur ofta det mötet sammanträder, och vem som har behörighet att fatta ett beslut som hamnar på listan. Det varierar per sektor, per styrelsestruktur och per riskkultur, och därför finns det inget fast mall som fungerar överallt utan anpassning.
Responsible AI Scan är under uppbyggnad. Den som just nu behöver en beslutslogg som ansluter till den befintliga strukturen kan anmäla sig till väntelistan; det erbjuds ännu inget som inte redan finns.
En beslutslogg anger vem som beslutade, inte hur mycket arbete ett system faktiskt tar över eller skulle kunna ta över. För den frågan — vilken del av en uppgift som kan överlåtas till AI, och vilken del som inte kan det — behövs en annan blick än vad governance ensam erbjuder. Werkscan från FTE TO AI räknar per uppgift ut vilken del av arbetet som kan tas över, som ett komplement till den överblick som en beslutslogg och den tillhörande oversight-strukturen erbjuder.
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.