En AI-programledare får vanligtvis ett mandat: se till att AI blir adopterad, att teamen blir snabbare med hjälp av den, att programmet visar resultat. Sällan tillkommer ett andra mandat: se till att allt som samtidigt uppstår är ansvarsfullt. Ändå bedöms han utifrån båda så snart något går fel. Det är kärnan i hans risk: han är ansvarig för ett program vars gränser han inte känner till.
Vad han vinner med adoption — snabbare processer, nöjda team, en synlig förnyelsehistoria — står mot vad han förlorar om det går fel: en incident med ett verktyg som inte stod på hans lista, en revision som ställer frågor han inte kan besvara, en styrelse som frågar varför programmet inte såg vad som redan pågick. Den asymmetrin gör hans position sårbar, även om programmet i sig går bra.
Hans fråga är inte "vilka AI-verktyg har vi godkänt". Den listan har han, och den är ofta kortare än verkligheten. Hans fråga är: vad använder team som inte står på min lista, och hur får jag insyn i det utan att människor döljer det. En programledare som vill stimulera adoption kan inte tillåta sig att användare gömmer sina verktyg av rädsla för en korrigering. Den som frågar vad som används och sedan gör det till ett problem, får inte längre svar på nästa fråga. Governance och adoption motverkar varandra här om det angrips på fel sätt.
Ett svar han inte accepterar är en enkel blockad: "AI-användning är inte tillåten utan godkännande." Det svaret tillfredsställer en revisor för ett ögonblick, men förflyttar användningen till platser ingen ser. Det är motsatsen till vad en programledare vill uppnå: han vill att AI-användning ska vara synlig och vägledd, inte att den går under jorden. Ett förbud utan mekanism för att rapportera och lära sig är för honom en förlust, även om det låter compliant på papper.
Han accepterar heller inte ett svar som behandlar allt lika. Ett verktyg som sammanfattar text för internt bruk innebär inte samma risk som ett verktyg som automatiskt fattar beslut om kunder eller medarbetare. Utan åtskillnad efter roll och risknivå kan ett program inte prioritera, och en programledare som inte kan prioritera kan inte utföra sitt mandat.
Vad som fungerar är en inventering som utgår från vad som finns, inte från vad som är godkänt. Det innebär att ställa frågor till team om vad de faktiskt använder, och göra det på ett sätt som inte medför någon bestraffning. Bara då blir skugg-AI synlig — de system som införts utan formell process, ofta eftersom de underlättade arbetet och ingen såg någon anledning att vänta på godkännande.
Därefter följer klassificering: vilken tillämpning berör kunder, vilken berör endast intern process, vilken fattar beslut utan en människa mellan. Den indelningen avgör var tillsynen måste vara tung och var den kan förbli lätt. Utan den indelningen behandlar ett program allt lika tungt eller lika lätt, och båda är ett problem: det första bromsar adoptionen, det andra lämnar risker obevakade.
Governance-strukturen som följer därefter måste anknyta till vad som redan finns inom organisationen — de befintliga riskkommittéerna, de befintliga rapporteringslinjerna — inte en ny krets bredvid. Det är också där en programledare skiljer sig från andra roller i organisationen: en styrelseledamot vill veta vad en styrelseledamot behöver veta om AI-risk på nivån av yttersta ansvar, en CIO angriper det utifrån system och åtkomst som beskrivs i vad en CIO behöver veta om AI-risk, och en General Counsel ser på ansvarsskyldighet och dokumentationsplikt via vad en General Counsel behöver veta om AI-risk. En programledare måste kunna tillgodose dessa tre perspektiv utan att förlora sin egen uppgift — adoption.
Vilka konkreta skyldigheter som gäller för vilken riskkategori, och inom vilka tidsramar, är inte ämnet för den här sidan. Den texten förändras, skärps och förklaras på andra platser. Här handlar det om mekanismen: hur ett program får insyn i vad som pågår, hur det översätter det till risknivåer, och hur det gör det påvisbart gentemot styrelse och tillsyn, oavsett vad den exakta regeltexten föreskriver vid ett givet tillfälle.
Så snart det är klart vad som pågår och vem som är ansvarig för det, uppstår en annan fråga: vad ger det om det arbetet organiseras väl. Det är en fråga som måste besvaras per uppgift, inte per organisation. Arbetsanalysen från FTE TO AI räknar ut på den nivån vilken del av arbetet som kan tas över av AI, så att en programledare inte bara vet vad som pågår, utan även var tillförd kapacitet faktiskt gör skillnad.
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.