AI-hendelser blir operasjonelle kriser. Vi må behandle dem slik.

De siste årene har de fleste organisasjoner snakket om AI-risiko i språket til styring.

Er modellen nøyaktig? Er den rettferdig? Er dataen godkjent? Er vi i samsvar med fremvoksende regulering? Disse er viktige spørsmål, men de er ikke de eneste spørsmålene. Det mer presserende spørsmålet er hva som skjer når noe går galt?

Hva skjer når en AI-agent tar en handling den aldri var ment å ta? Hva skjer når en modell lekker følsomme data? Hva skjer når en hallusinert svar skaper juridisk eksponering, eller en automatisert beslutning påvirker en kunde, ansatt, pasient eller partner på en måte som ikke lett kan omgjøres?

Og kanskje mest praktisk: Hvor går organisasjonen for å koordinere responsen? Det er skiftet som nå skjer. AI-risiko blir et operasjonelt resilient problem, ikke bare et styringsproblem.

AI flytter fra eksperimentering inn i den virksomme maskineriet til bedriften. Det blir innbygget i kundesupport, programvareutvikling, finansielle operasjoner, helsearbeidsflyt, rekruttering, kravbehandling, leverandørkjeder og interne automatisering. Etterhvert som AI blir mer koblet til bedriften, blir AI-feil bedriftsulykker.

Den OECD AI-ulykkesovervåking sporet 596 AI-ulykker i januar 2026 alene, 200% vekst fra året før. Slike innsats som OECD AI-ulykkesovervåking og AI-ulykkesdatabase dokumenterer negative eller skadelige resultater med AI-systemer så industrien kan lære fra erfaringer på samme måte som luftfart og cybersikkerhet har gjort i årevis.

Den sammenligningen er viktig. Modne industrier spør hvordan de kan forebygge feil og hvordan de kan respondere når feil likevel skjer.

AI-ulykker oppfører seg ikke som tradisjonelle programfeil

En tradisjonell programfeil har vanligvis en relativt klar grense. Noe feiler, ingeniører undersøker, og teamet reproduserer problemet, fikser koden og sender en løsning.

Men AI-ulykker er mer kompliserte. De kan være probabilistiske, intermittent og oppstå fra interaksjonen mellom en modell, en prompt, et oppbevaringssystem, en plug-in, en agent, en bruker og en nedstrøms forretningsprosess. Noen ganger fungerer AI-systemet eksakt som det er designet, men designet er ufullstendig for miljøet det brukes i. Det gjør responsen mer utfordrende.

En hallusinering i en forbrukerchatbot er ett type problem. En hallusinering innen en juridisk, finansiell, klinisk eller HR-arbeidsflyt er et annet. En forvrengt utgang i testing er alvorlig. En forvrengt beslutningsprosess som kjører i skala i produksjon er noe helt annet. En AI-assistent som utarbeider en e-post er en ting, men en agent som kan endre tilgang, utstedde refusjoner, oppdatere poster, utløse arbeidsflyt eller kjøre kode er en helt annen kategori risiko.

MIT AI-risikorepository fanger en bred rekke av AI-risiko, inkludert falsk eller misvisende informasjon, personvern- og sikkerhetsfeil, diskriminering, misbruk og systemsikkerhetsproblemer. OWASP’s Top 10 for LLM-applikasjoner høydepunkter risikoer som promptinjeksjon, sensitive informasjonsavsløring, usikker utgangshåndtering og overdriven agent. Disse er praktiske feilmodi, ikke abstrakte tekniske bekymringer.

Hvis en AI-agent har for mye myndighet, kan den iverksette handlinger ingen menneske har til hensikt. Hvis en promptinjeksjon lykkes, kan systemet avsløre informasjon eller følge fiendtlige instruksjoner. Hvis sensitive data lekker gjennom en modell eller oppbevaringssystem, har responsen juridiske, regulative, kunderelaterte og omdømmessmessige implikasjoner. Det er derfor språket til AI-styring kan noen ganger bli for passivt. Styring forteller oss hva som bør være sant. Ulykkesrespons forteller oss hva vi skal gjøre når virkeligheten beveger seg raskere enn politikken.

Responsen vil være tverrfaglig

En av de største lærdommene fra cybersikkerhet er at ulykker sjelden holder seg innenfor sikkerhetsteamet. I begynnelsen kan en hendelse se teknisk ut. Veldig raskt involverer det juridisk, kommunikasjon, ledelse, compliance, kundeteam, eksterne rådgivere, forsikringselskaper, forensiske eksperter og noen ganger styret.

AI-ulykker vil følge samme mønster.

Tenk deg en modell som eksponerer følsomme kundedata. Sikkerhets- og personvernsteamene må forstå hva som skjedde. Juridisk må vurdere forpliktelser. Kommunikasjon kan måtte forberede seg for kunder, regulatorene eller media. Ingeniører kan måtte deaktivere eller rulle tilbake et system. Ledere kan måtte veie kontinuitet mot innhold.

Eller tenk deg en AI-agent som begynner å iverksette uventede handlinger over bedriftssystemer. Det tekniske teamet kan kanskje lukke det ned, men organisasjonen trenger likevel å vite hva det gjorde, hvem som ble berørt, hvilke beslutninger ble fattet, om kontraktforpliktelser ble utløst og hvordan samme feil vil bli forhindret i fremtiden. Det kan ikke løses av AI-teamet alene.

Organisasjoner bør bygge tverrfaglig muskelminne før de trenger det. Det betyr klare eskalasjonsutløsere, klare roller, klare beslutningsrettigheter, klare kommunikasjonsveier, klare dokumentasjon og øving.

I en krise er koordinasjon infrastruktur, ikke bare en myk ferdighet.

AI som blir undersøkt, bør ikke kontrollere responsen

Det er et annet problem organisasjonene må tenke mye mer omhyggelig på. Hvis AI-systemet som undersøkes kan aksessere samme kommunikasjon, dokumenter, arbeidsflyt eller automatisering som brukes til å koordinere responsen, har organisasjonen et problem.

I cybersikkerhet er dette en kjent prinsipp. Hvis ransomware har kompromittert det korporative nettverket, koordinerer du ikke responsen på systemer angrepet kan lese, forstyrre eller manipulere. Du flytter ut av bandet. Du skiller ulykken fra responsen.

Samme logikk gjelder for AI.

En AI-system kan ikke være ondsinnet i menneskelig forstand, men hvis den kan se responsplanen, summerere responsmøtet, påvirke arbeidsflyten, anbefale neste skritt eller operere innen samme miljø som brukes til å inneholde det, så har organisasjonen ikke isolert responsen fullstendig.

Dette blir enda viktigere med agens AI. Google’s Sikker AI-rammeverk høydepunkter risikoer som promptinjeksjon, datapforgiftning og rogue-handlinger, og kartlegger dem til kontroller over AI-livssyklusen. Det er riktig rammeverk. Etterhvert som AI-systemer blir mer kapable til å handle over verktøy, data og arbeidsflyt, må organisasjonene tenke på modellsikkerhet og på operasjonell adskillelse.

Tenk på det som å undersøke en brann. Du ville ikke ønske sprinklerkontrollene koblet til samme feilfungerende system du prøver å diagnostisere.

Forbered, øv, respond, rapporter

En nyttig rammeverk for AI-ulykkesberedskap er det samme som har modnet i cybersikkerhet: forbered, øv, respond, rapporter.

Forbered betyr å definere ulykketyper før de skjer, som for eksempel forvrengning, hallusinering, datalekkasje, modellforflytning, promptinjeksjon, agens feil, uautorisert verktøybruk og tredjepartsmodellfeil. Hver av disse krever forskjellige interessenter og forskjellige beslutninger.

En god playbook bør ikke være en 200-siders dokument som ligger i en mappe. Ingen åpner side 137 under en krise. En god playbook er rollebasert, tilgjengelig og handlingsoverbyggende. Juridisk vet hva juridisk må gjøre. Ingeniører vet hva ingeniører må gjøre. Kommunikasjon vet når de skal engasjere. Styret vet når ledelsen vil eskalere.

Øv betyr å kjøre bordssimulatorer. Ikke bare en gang om året som en flått, men ofte nok til å bygge muskelminne. Første gang styret diskuterer en AI-ulykke, bør ikke være under en virkelig AI-ulykke. Første gang juridisk, ingeniører, personvern, sikkerhet og kommunikasjon arbeider gjennom en AI-feil sammen, bør ikke være når kunder allerede stiller spørsmål.

Respond betyr å koordinere den levende hendelsen med disiplin. Hvem er i rommet? Hva er faktiske kjent? Hva er fortsatt usikre? Hva ble besluttet? Hvem godkjente dem? Hva endret seg mellom time 12 og time 48?

Rapporter betyr å erkjenne at AI-regulering blir mer konkrekt. EU AI-loven inkluderer alvorlige ulykkesrapporteringsforpliktelser for leverandører av visse høyrisiko AI-systemer. Detaljene vil variere etter jurisdiksjon, bransje og brukstilfelle, men retningen er klar. AI-ulykker vil økende kreve en forsvarlig rekord av hva som skjedde, hva som var kjent, hva handlinger ble gjort og når.

AI kan hjelpe, men kan ikke erstatte dømmekraft

Det er en fristelse til å tro at AI-ulykkesrespons bør være fullstendig automatisert. Jeg mener at det er feil rammeverk.

AI kan hjelpe enormt. Det kan summerere fakta. Det kan identifisere manglende informasjon. Det kan sammenligne en ulykke med tidligere mønster. Det kan utarbeide etterrapporter. Det kan hjelpe med å kartlegge regulative forpliktelser. Det kan redusere administrativt arbeid når mennesker er under press.

Men i en alvorlig ulykke er mennesker fortsatt uvurderlige.

Noen må bestemme om fakta er tilstrekkelige. Noen må vurdere kundeimpakt. Noen må bestemme om å pause et system. Noen må avgjøre om organisasjonen har krysset en rapporteringsgrense. Noen må kommunisere med ansvar og empati.

Riktig rolle for AI i ulykkesrespons er ikke å erstatte kriseteamet. Det er å gi kriseteamet bedre kontekst, raskere.

NIST’s AI-risikostyringsrammeverk er nyttig fordi det rammeverk AI-risikostyring rundt fire funksjoner: styre, kartlegge, måle og forvalte. For ulykkesrespons ville jeg legge til en praktisk utvidelse: øv.

En plan som aldri har blitt testet er ikke virkelig en plan. Det er en teori.

Styret trenger en playbook, også

AI-risiko blir et styretema, men styreinnsats kan ikke stoppe ved oversiktssider. Styret må forstå sin rolle før en krise skjer.

Når vil styret bli informert? Hva beslutninger krever styreinnsats? Hva informasjon vil ledelsen gi? Hvordan vil materielitet, kundeimpakt, juridisk eksponering, regulative forpliktelser og operasjonell forstyrrelse bli vurdert?

Mange organisasjoner har sikkerhetsplaybook, personvernplaybook, kommunikasjonsplaybook og juridiske playbook. Langt færre har et styreplaybook for AI-ulykker. Denne gapen vil bli mer synlig ettersom AI-systemer flytter inn i regulerte, inntektsbaserte og kundeorienterte arbeidsflyt. Styrets rolle er å hjelpe organisasjonen med å ta bedre beslutninger under press, ikke å bli mer teknisk.

Troverdig AI krever operasjonell resilient

Det er mye samtale om troverdig AI. Det er riktig aspirasjon, men tillit skapes ikke bare av prinsipper. Tillit skapes når organisasjoner kan vise hvordan de forbereder seg, hvordan de oppdager problemer, hvordan de responderer, hvordan de kommuniserer, hvordan de dokumenterer beslutninger og hvordan de forbedrer seg.

Cybersikkerhet gikk gjennom samme utvikling. Organisasjoner har brukt år på å investere i forebygging, og de bør fortsatt gjøre det. Men modne organisasjoner lærte til slutt at forebygging ikke er nok. Du trenger også resilient. AI går inn i samme fase.

Vi bør absolutt bygge tryggere modeller, sterkere kontroller, bedre vurderinger, bedre red-teaming og bedre styring, men vi bør også akseptere at ulykker vil skje. Modeller vil feile, agenter vil oppføre seg uventet, data vil lekke, mennesker vil misbruke systemer, leverandører vil gjøre feil og reguleringer vil utvikle seg.

Spørsmålet er om organisasjonen kan respondere med hastighet, koordinasjon, dømmekraft og ansvar når en ulykke skjer. Det er hvordan AI flytter fra eksperimentering til pålitelig infrastruktur, og det er hvordan resilient blir kultur.