En styrelse som sätter AI på agendan får oftast två typer av underlag: en tjock dossier som ingen läser inför mötet, eller en sammanfattning som säger så lite att inget beslut kan fattas utifrån den. En styrelserapport på en sida är inte en sammanfattning av dossiern. Det är en annan fråga: vad behöver en styrelseledamot veta för att kunna ta ansvar, och vad är brus.
Den distinktionen är inte trivial. De flesta AI-rapporter vi ser räknar upp system. En sida som bara räknar hur många AI-tillämpningar det finns säger en styrelse ingenting om var risken ligger. Räkning är en IT-fråga. Governance är en annan fråga: vilka tillämpningar berör beslut om människor, vilka har tagits i bruk utan tillsyn, och vilka faller under en riskklass som kräver en underskrift.
En sida som fungerar innehåller ett begränsat antal element, varje gång med en anledning till att de tas med:
Resten — vem som har tränat vilken modell, vilken leverantör som tillämpar vilka villkor, vilken teknisk begränsning som har applicerats — hör till lagret därunder. Det lagret finns, underhålls och kan efterfrågas. Men det hör inte på sidan som styrelsen läser, för då läser styrelsen den inte.
Anledningen till att så mycket AI-governance kör fast är inte att det saknas en process. Det är att det finns en andra process, vid sidan av den befintliga. En styrelse har redan en riskkommitté, redan en revisionskalender, redan ett format för rapportering om operativ risk, om compliance, om informationssäkerhet. Den som sätter en separat AI-process bredvid detta — med egen frekvens, egen mall, egen ägare — ber om något som är det första som hoppas över när agendan är för full. Det sker inte av ovilja. Det sker eftersom en andra process per definition får mindre uppmärksamhet än den första.
Den rapport som faktiskt läses är den rapport som löper med i den befintliga rytmen: samma möte, samma format, samma sätt att eskalera som redan finns för andra risker. Hur den anslutningen tar form i praktiken beskrivs på sidan om anslutning till den befintliga riskstrukturen, och det sätt på vilket beslut därefter dokumenteras återkommer på sidan om en oversight-beslutslista som löper med i den befintliga rytmen.
En rapport på en sida är bara användbar om inventeringen bakom den är korrekt. Det är den del som oftast hoppas över: styrelseledamöter får en sida med en riskklassificering, utan att någon har kontrollerat om den underliggande listan av AI-tillämpningar är fullständig. Skugg-AI — användning som har uppstått vid sidan av IT-listan — försvinner då tyst ur bilden, inte eftersom det är oviktigt, utan eftersom ingen har frågat efter det. En medarbetare som använder ett AI-verktyg utan att det är godkänt anmäler inte det av egen vilja om en avräkning hotar. Han anmäler det bara om frågor ställs utan konsekvenser.
Sidan är alltså toppen av en process som börjar vid inventeringen och eskalerar via vägar som redan finns. Hur den eskaleringen fungerar utan att skapa en ny hierarki beskrivs på sidan om eskaleringsvägar som faktiskt används. Och vad som strukturellt behöver underhållas för att sidan varje gång ska kunna fyllas utan att det blir en rekonstruktion beskrivs på sidan om monitorering som faktiskt ger något för rapportering.
Responsible AI Scan levererar inventeringen, klassificeringen och den governance-struktur som ansluter till vad som redan finns — inklusive formatet för en rapport som styrelsen faktiskt läser. Skanningen i sig är under uppbyggnad; den som redan nu vill ha nytta av detta kan sätta sig på väntelistan.
En rapport som anger vilken del av arbetet som faller under AI-risk väcker naturligt en annan fråga: vilken del av arbetet självt som kan tas över av AI. Det är en annan uträkning, gjord per uppgift istället för per system, och den uträkningen görs av arbetsskanningen från FTE TO AI.
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.