Inom många organisationer finns en fast lista över tillämpningar som anses falla "utanför scope". Ett textförslag i ett ordbehandlingsprogram, ett spamfilter, en chatbot som bara svarar utifrån en fast FAQ. Antagandet är att dessa tillämpningar är för små, för gamla eller för oskyldiga för att omfattas av styrning. Det antagandet stämmer ibland. Det stämmer inte alltid, och det stämmer sällan permanent.
Om något faller utanför scope är inte en egenskap hos tekniken. Det är en indelning som följer av vad systemet gör, för vem, och med vilken effekt om det går fel. Samma textförslag som idag faller utanför scope eftersom det bara föreslår ett ord till en medarbetare, kan imorgon falla inom scope så snart det automatiskt färdigställer och skickar e-post utan mänsklig inblandning.
Tre faktorer avgör tillsammans om en tillämpning faller inom eller utanför scope.
Den första är funktionen: fattar systemet ett beslut, eller levererar det bara information som en människa bedömer? Ett verktyg som rangordnar arbetssökande ligger närmare scope än ett verktyg som bara gör CV:n sökbara. Var exakt en tillämpning befinner sig på det spektrumet och varför, kan ni läsa om i analysen av vad en hög risknivå innebär för er organisation.
Den andra är organisationens egen roll. Den som köper ett system och använder det oförändrat förhåller sig annorlunda till det än den som själv bygger, tränar eller anpassar det. Samma tillämpning kan för en organisation falla utanför scope och för en annan inte, rent baserat på vem som bär vilket ansvar. Denna uppdelning behandlas i frågan om ni är leverantör eller användare, och förändras så snart någon i organisationen anpassar eller tränar om en modell, som beskrivs i vad som förändras när ni själva anpassar en modell.
Den tredje faktorn är tid. Ett system som nu faller utanför scope kan ett år senare inte längre göra det, inte eftersom reglerna har förändrats, utan eftersom användningen förändrades. En chatbot som började som en informationskälla kan växa till ett system som hanterar klagomål. Rollen för ett team eller en avdelning gentemot ett sådant system förskjuts då med, och när det sker beskrivs i när er roll förändras och vad det beror på.
Konsekvensen av dessa tre faktorer är att "utanför scope" aldrig är en permanent status. Det är en ögonblicksbild som måste ses över på nytt så snart ett systems funktion förändras, så snart organisationen får en annan roll gentemot det systemet, eller så snart användningen utvidgas till något som inte var förutsett vid anskaffningen.
Det är precis här skugg-AI stör indelningen. En tillämpning som på IT-listan noterats som "utanför scope" kan i praktiken användas på ett sätt som inte längre stämmer med det. Ett team som använder en språkmodell för att skriva utkast till kundkommunikation använder den kanske också för att skicka slutgiltiga svar utan att rapportera det. Klassificeringen på papper och användningen i praktiken går då isär, och ingen som bara tittar på de inköpta licenserna ser den skillnaden.
Det enda sättet att få insikt i det är att fråga. Inte ett system, utan de personer som använder det. Det fungerar bara om att ställa frågor inte likställs med att bli granskad: den som är rädd för konsekvenser anpassar sitt svar eller ger inget svar alls. En indelning som enbart bygger på inköpta licenser missar därför systematiskt de tillämpningar som har uppstått ur praktisk användning, och det är ofta just de tillämpningarna som ingen längre vet om de fortfarande faller utanför scope eller redan ligger långt inom det.
Frågan "faller detta utanför scope" kan alltså inte besvaras separat från frågan om vad som exakt sker, vem som beslutar om det, och hur länge situationen har varit sådan. En inventering som fastställer dessa tre faktorer per tillämpning ger en indelning som stämmer med den verkliga situationen i stället för med det antagande som ett system en gång köptes in utifrån. Vad som redan nu kräver uppmärksamhet och vad som lugnt kan planeras beror på samma faktorer och behandlas i skillnaden mellan vad som måste hanteras nu och vad som kan planeras.
Så snart det är klart vilka tillämpningar som faller inom scope och vilken roll er organisation spelar i det, uppstår en följdfråga som inte handlar om styrning utan om arbete: vilken del av en uppgift tas egentligen över av en sådan tillämpning, och vilken del förblir mänskligt arbete? Den frågan besvarar inte styrningsanalysen. Det är vad FTE TO AI:s arbetsanalys är till för, som per uppgift räknar ut vilken del av arbetet som kan tas över av AI, och därmed ger en bild av den insats som ligger bakom klassificeringen.
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.