Ett team ville prova något. En chatbot för kundfrågor, ett skript som sammanfattar rapporter, en koppling till en språkmodell för att sortera e-post. Det krävdes inget stort beslut: någon hade ett konto, en API-nyckel eller en gratis provperiod, och inom en eftermiddag körde något. Piloten fungerade, eller fungerade tillräckligt bra, och ingen hade längre någon anledning att stänga den av.
Detta är inget undantag. Det är det vanliga sättet som AI kommer in i en organisation. Inte via en upphandling eller en godkänd budget, utan via en testuppställning som överlever sin egen teststatus. Testfasen avslutades aldrig formellt, eftersom det heller aldrig fanns en formell start att avsluta.
En pilot som fungerar, används. Och det som används blir ett beroende. Teamet som byggde rapportsammanfattaren har kanske slutat, men sammanfattningen kommer fortfarande in varje vecka. Ingen har fått uppdraget att stänga den av, och ingen vill ta risken att något slutar fungera utan att veta vad som kommer i dess ställe.
Därtill kommer att en testuppställning vanligtvis inte har en ägare i den mening som en styrningsstruktur förväntar sig. Ingen riskklassificering har gjorts, ingen dataanalys har utförts, inget beslut har fattats om vem som är ansvarig om det går fel. Piloten existerar i ett mellanrum: för mycket använd för att ignoreras, för informell för att hanteras. Det är exakt det mönster som leder till medarbetare som använder ett verktyg som ingen har godkänt — bara att det då sker på teamnivå istället för individuellt.
Reflexen vid upptäckten av en icke-godkänd testuppställning är ofta: vem tillät detta, och varför visste vi inte om det. Den frågan är förståelig, men den ger motsatt effekt. Den som redan vid det första samtalet känner att en skuldfråga är på väg, berättar inget mer nästa gång. Och nästa testuppställning — som utan tvekan kommer — försvinner då lika lätt ur sikte som denna.
En inventering som bygger på förtroende ger mer än en granskning som bygger på kontroll. Inte eftersom människor inte skulle ha något att dölja, utan eftersom informationen ni söker finns hos användaren, och den användaren pratar bara om han inte blir bestraffad för vad han hittar på.
Så snart en testuppställning är identifierad är den första frågan inte om den får fortsätta existera, utan vad den exakt gör. Vilken data går in, vem använder resultatet, och vad händer om resultatet är felaktigt. Det är samma frågor som gäller för varje annan AI-tillämpning, och svaret avgör om något är ett informellt hjälpmedel eller en risk som förtjänar uppmärksamhet.
Därefter följer klassificering: passar tillämpningen in i en riskkategori som redan finns, eller kräver den en ny bedömning. Sedan: vad måste dokumenteras för att kunna påvisa att organisationen vet vad som körs och varför. Det är precis vad vad ni måste dokumentera per tillämpning tar upp — inte som extra byråkrati, utan som den minimala dokumentation som krävs för att skilja en pilot från en risk.
En testuppställning som klarar denna prövning kan fortsätta existera, nu med en ägare och en klassificering. En testuppställning som inte klarar prövningen måste avvecklas — men det är en kontrollerad process, inte ett avsked av personen som en gång startade den.
Testuppställningen som aldrig stängdes av är en form av ett bredare mönster. Tänk på webbläsartillägget med tillgång till er e-post som någon en gång installerade för att spara tid, eller på företagsdata som hamnar i ett gratis chattfönster eftersom det gick snabbare än det officiella verktyget. Alla dessa situationer delar en egenskap: de uppstod ur ett praktiskt behov, inte ur ett policyval, och de fortsätter existera så länge ingen frågar om dem.
IT-listan med godkänd programvara är därför inte startpunkten för en inventering — den är utgångspunkten för en sökning efter vad som faller utanför den listan. Den som vill veta hur den sökningen ser ut, hittar ett tillvägagångssätt i hur ni bygger upp en AI-inventering.
En testuppställning som kommer fram i ljuset väcker vanligtvis en följdfråga som går längre än styrning: varför fungerade detta egentligen så bra att ingen vågade stoppa det? Det är en fråga om själva arbetet, inte bara om risken. Arbetsscanen från FTE TO AI räknar per uppgift ut hur stor del av arbetet som kan tas över av AI, och gör därmed synligt vad en testuppställning redan implicit visade: att en del av arbetet kan organiseras på ett annat sätt. Där Responsible AI Scan kartlägger vad som körs och under vilken risk, visar arbetsscanen var den användningen kommer från och vad den strukturellt innebär för uppgiftsfördelningen.
Responsible AI Scan, med inventeringen, klassificeringen och styrningspaketet som beskrivits ovan, är under utveckling. Den som redan nu har med detta att göra och vill informeras så snart verktyget blir tillgängligt, kan anmäla sig till väntelistan.
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.