Det finns ofta redan ett dokument med titeln eskaleringsprocedur. Det innehåller ett schema med pilar, en rad namn, och några tröskelvärden. Problemet är inte att dokumentet saknas. Problemet är att ingen öppnar det i det ögonblick det behövs.
Det sker inte av ovilja. Det sker eftersom det redan finns en väg längs vilken problem förs uppåt: linjechefen som anmäler IT-incidenten, compliance-ansvarige som talar med verksamheten, teamledaren som lägger sitt problem hos sin egen chef. Den vägen finns, används dagligen, och fungerar — för det den är avsedd för. En ny eskaleringsväg specifikt för AI-incidenter blir då en andra rutt vid sidan av en rutt som redan är i bruk. Vid tvivel väljer alla den rutt de känner till.
En eskaleringsväg som står separat från den befintliga strukturen kräver att medarbetaren först inser att något är en AI-incident, sedan minns att en annan process gäller för det, och därefter gör sig besväret att följa den processen istället för att bara ringa sin chef. Varje steg i den kedjan är ett tillfälle då vägen släpps.
Därtill kommer en andra orsak, mindre synlig men lika avgörande: den som anmäler en avvikelse vill inte omedelbart hamna på organisationens incidentformulär. Om eskalering likställs med avstraffning, eskaleras inget. Det gäller för en medarbetare som använde ett AI-verktyg som inte var godkänt, och det gäller för en chef som lät en modell köra utan att någon visste om det. En eskaleringsväg som verkligen används är en väg där den första anmälan inte är en dom, utan en signal.
En eskaleringsväg som fungerar beskriver tre saker, och inte mer än det.
Den som iakttar något — en medarbetare, en kund, en extern part — måste veta vem han eller hon kan vända sig till utan att först behöva ta reda på om det är en AI-fråga eller en vanlig operativ fråga. Vägen ansluter till den anmälningspunkt som redan finns, med en extra förgrening i det ögonblick det visar sig att AI är inblandad.
Vem som fattar beslutet — om något ska stoppas, justeras, eller anmälas till en tillsynsmyndighet — måste vara fastställt innan incidenten inträffar. Inte som en abstrakt befattningstitel, utan som ett namn, med en ersättare. Eskalering som fastnar vid ett tomt mandat är ingen eskalering.
Vad som händer därefter med anmälaren måste vara tydligt. Om en andra process endast består av en anmälningsplikt utan klarhet om konsekvenserna för den som anmäler, undviks den. Det är exakt där skugg-AI gömmer sig: inte i de system som IT känner till, utan i verktygen som någon börjat använda utan att anmäla det, eftersom anmälan kändes som ett erkännande.
Lösningen är inte ett tjockare dokument. Det är en eskaleringsväg som utnyttjar den struktur som redan finns — anmälningspunkten, eskaleringslinjen, riskkommittén — och lägger till en AI-specifik förgrening på de punkter där den gör en skillnad. Hur den anslutningen fungerar i detalj, även för den bredare policyn och tillsynsorganets beslutslogg, beskrivs i hur ni får en AI-policy som läses eftersom den är inbäddad i det som redan finns och i hur ni får en oversight-beslutslogg som ansluter till det befintliga beslutsrytmen. Båda dokumenten berör samma punkt: en process som står vid sidan av organisationen ignoreras; en process som ligger inbäddad i den följs.
Denna utgångspunkt gäller inte bara för eskalering. Den gäller för hela styrningsstrukturen kring AI. Den som vill veta hur det ser ut i ett bredare perspektiv — hur riskklassificering ansluter till befintliga riskkategorier, hur anslutning till den befintliga riskstrukturen förhindrar att en parallell byråkrati uppstår — hittar där den underliggande principen. Samma gäller för rapportering uppåt: en styrelserapport på en sida fungerar bara om eskaleringarna den innehåller verkligen har anmälts. Och utan löpande observation av vad som förändras föråldras varje eskaleringsväg inom ett år; vad det innebär i praktiken förklaras på övervakning som ger resultat.
En eskaleringsväg kan bara skrivas när det är känt vad som kan eskaleras. Så länge ingen vet vilken AI som körs i organisationen — inklusive det som inte godkändes — förblir dokumentet teoretiskt. Responsible AI Scan börjar därför inte vid eskaleringsvägen, utan vid inventeringen: vad körs, vem använder det, och vilken risknivå passar det. Först utifrån det kan en eskaleringsväg skrivas som ansluter till det som redan finns, istället för till det som på papper borde finnas.
Eskaleringsvägar handlar om vad som går fel med AI som redan används. En annan fråga, lika underbelyst, är var AI själv skulle kunna ta över arbetet. Arbetsscanen från FTE TO AI räknar per uppgift ut vilken del av arbetet som är lämplig för det, oavsett om det redan sker eller ännu måste organiseras.
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.