Klokken 10.15 oppdager en kollega at en agent har endret leveringsopplysningene for feil kunde. Teamet lukker samtalevinduet og tror at feilen er stoppet. Ti minutter senere sender en planlagt jobb en ny serie oppdateringer.
Dette tenkte eksemplet viser hvorfor bedriften trenger en plan for KI-feil. Å lukke et samtalevindu stanser ikke nødvendigvis bakgrunnsjobber, tilkoblede verktøy eller handlinger i kø. Dere må vite hvordan dere stopper handlingene agenten fortsatt kan utføre. Deretter må dere få oversikt over hva den allerede har gjort.
Stans handlingen uten å ødelegge dokumentasjonen
Begynn med dette spørsmålet: Hva kan agenten fortsatt sende, endre eller sette i gang? Bruk de avtalte rutinene for å sette den berørte arbeidsprosessen på pause. Stans bakgrunnsjobber som kan fortsette arbeidet, og trekk ved behov tilbake agentens verktøytilganger eller tilgangsnøkler. Avklar stansen med den som har ansvar for tjenesten, slik at dere ikke slår ut annen viktig drift samtidig.
Ta vare på relevant dokumentasjon på et sted med begrenset tilgang: tidspunkter, oppgave-ID-er, versjoner av oppsettet, opplysninger agenten brukte, verktøykall og fullførte handlinger. Unngå å kopiere hele kundedatasett ukritisk inn i en felles chat om hendelsen. Logger kan inneholde personopplysninger eller konfidensielt innhold og trenger selv egnet tilgangsstyring og regler for oppbevaring.
Agentens forklaring kan være et spor, men dere kan ikke bruke den alene til å fastslå hva som skjedde. Sjekk loggene i systemene som faktisk sendte meldingen, endret ordren eller ga tilgang.
Lag en oversikt over berørt arbeid
Registrer for hver berørte sak hva som var meningen, hva som faktisk skjedde, hvem eller hva som ble berørt, og hva som fortsatt kan reverseres. Skill mellom utkast og handlinger som allerede har nådd kunder eller andre utenfor bedriften. En kø med usendte meldinger krever andre tiltak enn meldinger som allerede er levert.
I leveringseksemplet må dere sammenligne agentens aktivitet med endringene i ordresystemet og meldingene som faktisk er sendt. Sett usikre saker på vent for menneskelig gjennomgang. Hvis en rettelse er nødvendig, bør en ansvarlig medarbeider bekrefte riktig kunde og riktige opplysninger. Ikke be den samme ukontrollerte prosessen rette seg selv i stor skala.
La én person koordinere håndteringen, og samle beslutningene i én logg. Kundekommunikasjon, arbeidet med å stanse feilen og den juridiske vurderingen kan foregå samtidig. De som gjør dette, må ha samme situasjonsbilde.
Avgjør hva som må meldes
En KI-feil er ikke automatisk et meldepliktig brudd på personopplysningssikkerheten. Vurder om sikkerheten til personopplysninger er brutt, og risikoen for personers rettigheter og friheter. Personvernforordningen artikkel 33 krever at den behandlingsansvarlige melder til tilsynsmyndigheten uten ugrunnet opphold og, når det er mulig, innen 72 timer etter å ha fått kjennskap til bruddet, med mindre bruddet sannsynligvis ikke medfører slik risiko. Databehandlere skal varsle den behandlingsansvarlige uten ugrunnet opphold.
Artikkel 34 regulerer informasjon til berørte personer når bruddet sannsynligvis medfører høy risiko, med bestemmelsens vilkår og unntak. Ikke vent på en fullstendig teknisk årsaksrapport før pliktene vurderes. I Norge vil relevant tilsynsmyndighet ofte være Datatilsynet. Avklar faktisk jurisdiksjon og eventuelle ytterligere varslingsplikter etter sektorregler eller avtaler.
Behold vurderingen og begrunnelsen også når melding ikke kreves. Involver riktig personvernfaglig, sikkerhetsfaglig og juridisk kompetanse fremfor å la verktøyleverandøren ta selskapets beslutning som standard.
Kontroller rettelsen før dere starter igjen
Før ny oppstart ville jeg krevd en kort redegjørelse som besvarer fem spørsmål:
- Hva gjorde feilen mulig, og hva er endret for å hindre at den skjer igjen?
- Har dere kontrollert det agenten har gjort, det som ligger i kø, og følgene i andre systemer?
- Er rettelsen testet mot den opprinnelige feilen og representative normalsaker?
- Kan dere godta begrensningene som gjenstår, hvis dere starter i mindre omfang eller gjenopptar vanlig drift?
- Hvem godkjenner ny oppstart, og hvilken oppfølging vil raskt oppdage en gjentakelse?
Det kan være fornuftig å starte i mindre omfang: bare utkast, færre sakstyper eller ny godkjenning før handlinger utad. En forbedret instruksjon til modellen kan hjelpe, men bør ikke erstatte tilgangsstyring som mangler.
Øv med dem som faktisk må håndtere feilen
Gå gjennom leveringseksemplet med den som har ansvar for løsningen, en vanlig bruker og en stedfortreder. Kan de finne ut hvordan agenten stoppes? Vet de hvor handlingene er loggført, og hvem som vurderer varsling? Bruk øvelsen til å finne det som mangler i rutinene.
Læringen bør inn i vurderingen før løsningen settes i drift og styrets grenser for hva agenten får gjøre. En feil som kan rettes, kan fortsatt være kostbar. En udokumentert feil kan gjenta seg.
Kilder og avgrensning
Kildene ble kontrollert 11. oktober 2026. Fremgangsmåten er mitt forslag til håndtering, og leveringshendelsen er hypotetisk. Meldeplikter avhenger av hendelsen, virksomhetens rolle og gjeldende regler. Bestemmelsen om 72 timer er ikke en generell frist for alle KI-feil.