En AI-policy som läggs som ett fristående dokument bredvid den befintliga policyn blir i praktiken inte läst. Inte för att medarbetare är ovilliga, utan för att en andra process bredvid en befintlig process nästan alltid förlorar. Den som redan har ett riskramverk, en uppförandekod och en eskaleringslinje går inte och konsulterar ett parallellt system för just en specifik teknologi. Den AI-policy som faktiskt fungerar är den policy som synligt använder samma ramverk som resten av organisationen redan känner till.
Varje organisation med viss storlek har redan ramverk för risk, inköp, informationssäkerhet och uppförande. En AI-policy som står löst bredvid det introducerar ett nytt språk, nya roller och en ny plats att söka på. Det är precis anledningen till att den läggs undan efter lanseringen. Medarbetare följer minsta motståndets väg, och den vägen går via strukturen de redan känner. En policy som kräver ett nytt sätt att arbeta bredvid det gamla vinner sällan den konkurrensen.
Lösningen är inte ett bättre skrivet dokument. Det är ett dokument som inte gör anspråk på en ny plats, utan använder den befintliga platsen. En AI-risk behandlas då som en risk, med samma ägare, samma eskaleringslinje och samma rapporteringsform som varje annan risk. Den som vill underbygga detta hittar resonemanget på sidan om att ansluta till den befintliga riskstrukturen i stället för ett nytt ramverk bredvid.
En AI-policy som fungerar innehåller ingen uppräkning av vad som är tillåtet och inte per system. Det förändras för snabbt och blir inaktuellt inom ett år. Den innehåller i stället ett antal fasta element som inte beror på vilken modell eller vilken leverantör som används:
Dessa fyra delar bildar tillsammans inte ett separat AI-styrningssystem, utan en specificering av det riskystem som redan finns. Det är skillnaden mellan en policy som blir läst och en policy som blir liggande i en pärm.
Att bädda in en policy har liten mening om det inte är känt vad som exakt ska bäddas in. IT-listan över godkända system räcker inte till för det: den beskriver vad som har anskaffats, inte vad som används. Skugg-AI, verktyg som medarbetare själva har börjat använda utan formellt godkännande, faller utanför det, medan risken inte är mindre för det.
Det enda sättet att få insyn i det är att fråga. Och det fungerar bara om att fråga inte leder till en avräkning. Den som vid den första inventeringen genast kopplar sanktioner till svaret får inga svar längre. En AI-policy som söker inbäddning i den befintliga strukturen börjar därför med en inventering som är fristående från bedömning, och först därefter med klassificering efter roll och risknivå.
Styrelsen har inget intresse av ett tjockt policydokument, utan av en kompakt översikt över var riskerna finns och vad som görs åt dem. Den översikten bör ha samma form som andra riskrapporter som styrelsen redan tar emot, så att den inte läses som en separat AI-rapport utan som en del av den vanliga riskbilden. Hur den rapporten ser ut står på sidan om en styrelserapport av en sida som ansluter till befintliga riskrapporter. För den som först vill veta vad en styrelseledamot i allmänhet bör känna till om AI-risk innan policyn fastställs finns sidan om vad en styrelseledamot bör veta om AI-risk innan policy fastställs.
En policy som ansluter till den befintliga strukturen besvarar frågan om vem som beslutar om vad och hur risk bevakas. Den besvarar inte frågan om vilken del av det faktiska arbetet som kan tas över av AI och vilken del som inte kan det. Den frågan ligger på uppgiftsnivå, och det är det arbetsscanen från FTE TO AI handlar om: den räknar per uppgift ut vilken del av arbetet som kan tas över, så att policyn och praktiken bygger på samma bild av organisationen.
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.