Kennisbank

Monitorering som fungerar, är monitorering som ansluter till det som redan finns

Mycket monitorering av AI-användning kommer till som ett separat initiativ: ett nytt formulär, ett nytt möte, en ny instrumentpanel. Det ser komplett ut vid lanseringstillfället. Ett år senare har det urvattnats. Inte för att innehållet var dåligt, utan för att det stod bredvid den befintliga strukturen i stället för i den.

Frågan är alltså inte bara vad som ska övervakas, utan var den monitoreringen landar. En process som ingen behöver komma ihåg för att den redan är en del av en rutin som ändå pågår, överlever. En process som kräver ett extra steg av människor som redan är fullbokade, hoppas över efter en tid. Det är ingen ovilja. Det är en förutsägbar konsekvens av hur organisationer hanterar tid och uppmärksamhet.

Varför en andra process förlorar

Varje organisation har redan ett rytm: kvartalsrapporter, riskkommittéer, revisionscykler, teammöten. Om monitorering av AI-användning introducerar ett nytt rytm konkurrerar det med allt som redan finns — och förlorar oftast. Det finns ingen agendapunkt för det, ingen ägare som ser det som en kärndel av sin roll, inget ögonblick då det naturligt kommer upp.

Om monitorering däremot blir en fråga som redan ställs — i den befintliga riskkommittén, i den befintliga internkontrollen, i den befintliga rapporteringslinjen till styrelsen — behöver ingen komma ihåg något nytt. Frågan "vilka AI-tillämpningar har tillkommit eller ändrats" blir då lika naturlig som "finns det nya leverantörer" eller "har det förekommit incidenter". Hur den anslutningen exakt utformas beror på hur anslutning till den befintliga riskstrukturen redan är uppbyggd hos er — den strukturen är angreppspunkten, inte något vid sidan om.

Vad dokumentet bör innehålla

Ett fungerande monitoreringsdokument är kort nog för att användas upprepade gånger och specifikt nog för att kunna rapportera något om det förändras. Det innehåller i vart fall:

• En aktuell lista över AI-tillämpningar, inklusive vad som är anmält via IT och vad som används utanför den. Den andra kategorin är ofta störst, och försvinner ur varje dokument som endast förlitar sig på formellt godkännande.
• En riskklassificering per tillämpning, så att inte varje förändring kräver samma uppmärksamhet. En textgenerator för interna anteckningar kräver något annat än en modell som medverkar i beslut om kundacceptans.
• En ägare per tillämpning, ett namn, ingen avdelning. Utan ägare uppmärksammas en förändring ingenstans.
• Ett fast intervall för när listan revideras, kopplat till ett ögonblick som redan finns — inte ett nytt ögonblick som måste planeras separat.
• En plats där avvikelser blir synliga, så att en ny användning eller en förändrad tillämpning inte upptäcks förrän månader senare.

Dokumentets värde ligger inte i fullständighet på dag ett. Det är sällan uppnåeligt och inte heller nödvändigt. Värdet ligger i att det hålls uppdaterat, och att uppdateringen inte kräver en separat insats utöver det som redan sker.

Varför ansvarsutkrävande stoppar informationen

Monitorering är beroende av vad människor är villiga att rapportera. Så snart rapportering innebär risken att bli hållen ansvarig för något, stoppar informationen. Någon som slutför en uppgift snabbare än förväntat med hjälp av ett AI-verktyg rapporterar inte det om konsekvensen är indragen budget eller ett besvärligt samtal. Listan förblir då formellt komplett men innehållsmässigt tom — exakt det problem som upprätthåller skugg-AI.

Konsekvensen är att monitorering endast fungerar om frågor ställs utan ansvarsutkrävande. Inte för att användning ska förbli utan konsekvenser, utan för att det första steget — att veta vad som pågår — kräver en annan hållning än det andra steget — att bedöma om det är lämpligt. Den som låter dessa två steg sammanfalla får inget ärligt svar på något av dem.

Den distinktionen är också där governance och ansvarighet möts. Synlighet för styrelsen behöver inte innebära att varje enskild tillämpning läggs på bordet; det handlar om en rapporteringsnivå som möjliggör ett omdöme utan att fastna i detaljer, som beskrivs i en styrelserapport som får plats på en sida. Det som ligger under det — dokumentationen av beslut om konkreta tillämpningar — hör snarare hemma i en oversight-beslutslista än i dokumentet som går uppåt.

Om ett policydokument självt läses är en jämförbar fråga: en text som ingen konsulterar ger lika lite stöd som en monitoreringsprocess som ingen fyller i. Se därför en AI-policy som läses. Och för den som undrar vilken del av detta ansvar som ligger hos styrelsebordet och vilken del hos IT-governance finns det en distinktion mellan vad en styrelseledamot behöver veta om AI-risk och vad en CIO behöver veta om AI-risk — båda kräver olika detaljnivåer inom samma monitoreringsprocess.

Från att veta vad som pågår till att veta vad det ger

En monitoreringsstruktur som ansluter till det som redan finns ger vid ett tillfälle en tillförlitlig bild av vilka AI-tillämpningar som används och för vad. Den inventeringen är en annan fråga än hur mycket av det underliggande arbetet som faktiskt utförs av AI, och med vilken effekt. Den som vill räkna ut det per uppgift — vilken del av en funktion eller process som kan överföras till AI, baserat på uppgifterna som de utförs i dag — hittar det i arbetsscanen från FTE TO AI.