AI-ulykker bliver til operationelle kriser. Vi skal behandle dem på den måde.

I de sidste få år har de fleste organisationer talt om AI-risiko i sprogbrug omkring governance.

Er modellen præcis? Er den fair? Er dataen godkendt? Overholder vi de nye regler? Disse spørgsmål er vigtige, men de er ikke de eneste. Det mest presserende spørgsmål er, hvad der sker, når noget går galt?

Hvad sker der, når en AI-agent tager en handling, den aldrig var ment til at tage? Hvad sker der, når en model lækker følsomme data? Hvad sker der, når en hallucineret svar skaber juridisk eksponering, eller en automatiseret beslutning påvirker en kunde, medarbejder, patient eller partner på en måde, der ikke let kan omgøres?

Og måske mest praktisk: Hvor går organisationen hen for at koordinere responsen? Det er skiftet, der er i gang lige nu. AI-risiko bliver et operationelt resilience-problem, ikke kun et governance-problem.

AI bevæger sig fra eksperimenter til den fungerende maskineri i virksomheden. Det indbygges i kundesupport, softwareudvikling, finansielle operationer, sundhedsrelaterede arbejdsprocesser, rekruttering, kravbehandling, forsyningskæder og interne automatisering. Da AI bliver mere tilknyttet forretningen, bliver AI-fejl til forretningsulykker.

Den OECD AI Incidents Monitor registrerede 596 AI-ulykker i januar 2026 alene, en vækst på 200% i forhold til året før. Initiativer som OECD AI Incidents Monitor og AI Incident Database dokumenterer negative eller skadelige resultater, der involverer AI-systemer, så industrien kan lære af erfaringerne på samme måde, som luftfart og cybersikkerhed har gjort i årevis.

Den sammenligning er vigtig. Modne industrier spørger, hvordan man kan forhindre fejl, og hvordan man kan reagere, når fejlen alligevel sker.

AI-ulykker opfører sig ikke som traditionelle software-fejl

En traditionel software-fejl har normalt en relativt klar grænse. Noget går galt, ingeniører undersøger sagen, og holdet genskaber problemet, retter koden og sender en løsning.

Men AI-ulykker er mere rodende. De kan være probabilistiske, intermitterende og opstå fra interaktionen mellem en model, en prompt, et søgesystem, en plug-in, en agent, en bruger og en nedstrøms forretningsproces. Nogle gange fungerer AI-systemet præcis, som det er designet til, men designet er ufuldstændigt for den omgang, det bruges i. Det gør responsen mere udfordrende.

En hallucination i en forbruger-chatbot er ét problem. En hallucination inde i en juridisk, finansiell, klinisk eller HR-arbejdsproces er noget andet. En fordomsfuld output under test er alvorlig. En fordomsfuld beslutningsproces, der køres i stor skala i produktion, er noget helt andet. En AI-assistent, der udarbejder en e-mail, er én ting, men en agent, der kan ændre tilladelser, udstede refunderinger, opdatere poster, udløse arbejdsprocesser eller køre kode, er en meget anden kategori af risiko.

The MIT AI Risk Repository fanget en bred vifte af AI-risici, herunder falsk eller misvisende information, privatlivs- og sikkerhedsfejl, diskrimination, misbrug og system-sikkerhedsproblemer. OWASP’s Top 10 for LLM Applications fremhæver lignende risici som prompt-injektion, følsom informationsafsløring, usikker output-håndtering og excessiv agent.

Hvis en AI-agent har for megen myndighed, kan den tage handlinger, som ingen menneske havde til hensigt. Hvis en prompt-injektion lykkes, kan systemet afsløre information eller følge fjendtlige instruktioner. Hvis følsomme data lækker gennem en model eller et søgesystem, har responsen juridiske, regulerende, kunderelaterede og rygte-relaterede implikationer. Det er derfor, sprogbrugen omkring AI-governance kan blive for passiv. Governance fortæller os, hvad der burde være sandt. Incident-respons fortæller os, hvad vi skal gøre, når virkeligheden bevæger sig hurtigere end politikken.

Responsen vil være tværfaglig

En af de største lærdomme fra cybersikkerhed er, at ulykker sjældent bliver inden for sikkerhedsteamet. Til at begynde med kan en begivenhed se teknisk ud. Meget hurtigt involverer det juridisk, kommunikation, ledelse, compliance, kundeteams, eksterne rådgivere, forsikringsfolk, retsmedicinske specialister og nogle gange bestyrelsen.

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

Forestil dig en model, der afslører følsomme kundeinformationer. Sikkerheds- og privatlivsteams skal forstå, hvad der skete. Juridisk skal vurdere forpligtelser. Kommunikation måske skal forberede sig på kunder, myndigheder eller medier. Ingeniørteamet måske skal deaktivere eller rulle tilbage et system. Ledere måske skal veje kontinuitet mod indhold.

Eller forestil dig en AI-agent, der begynder at tage uventede handlinger på tværs af virksomhedssystemer. Det tekniske team kan måske lukke det ned, men organisationen har stadig brug for at vide, hvad det gjorde, hvem der blev påvirket, hvilke beslutninger blev truffet, om kontraktforpligtelser blev udløst, og hvordan samme fejl kan forhindres i fremtiden. Det kan ikke løses af AI-teamet alene.

Organisationer skal bygge tværfaglig muskelhukommelse, før de har brug for det. Det betyder klare eskalationsudløsere, klare roller, klare beslutningsrettigheder, klare kommunikationsveje, klart dokumentation og øvelse.

I en krise er koordination infrastruktur, ikke kun en blød færdighed.

Den AI, der undersøges, skal ikke kontrollere responsen

Der er et andet problem, organisationer skal tænke meget mere omhyggeligt over. Hvis AI-systemet under undersøgelse kan få adgang til samme kommunikation, dokumenter, arbejdsprocesser eller automatisering, der bruges til at koordinere responsen, har organisationen et problem.

I cybersikkerhed er dette et velkendt princip. Hvis ransomware har kompromitteret det corporate netværk, koordinerer du ikke responsen på systemer, angriberen måske kan læse, forstyrre eller manipulere. Du flytter udenfor båndet. Du adskiller ulykken fra responsen.

Samme logik gælder for AI.

En AI-system kan ikke være ondsindet i menneskers forstand, men hvis den kan se responsplanen, sammenfatte responsmødet, påvirke arbejdsprocessen, anbefale næste skridt eller fungere inde i samme miljø, der bruges til at indeholde den, har organisationen ikke isoleret responsen.

Dette bliver endnu vigtigere med agens-ai. Google’s Secure AI Framework fremhæver risici som prompt-injektion, datap forgiftning og rogue-handlinger og kortlægger dem til kontroller på tværs af AI-livscyklussen. Det er den rigtige ramme. Da AI-systemer bliver mere kapable til at fungere på tværs af værktøjer, data og arbejdsprocesser, skal organisationer tænke på modelsikkerhed og om operationel adskillelse.

Tænk på det som at undersøge en brand. Du ville ikke ønske, at brandslukningskontrollerne var knyttet til samme fejlende system, du forsøger at diagnosticere.

Forbered, øv, reager, rapportér

En nyttig ramme for AI-ulykkesparathed er den samme, der er modnet i cybersikkerhed: forbered, øv, reager, rapportér.

Forbered betyder at definere ulykkesskemaer, før de sker, som f.eks. fordom, hallucination, datalekkage, modeldrift, prompt-injektion, agens-udbrud, uautoriseret værktøjsbrug og tredjepartsmodel-fejl. Hver kræver forskellige interessenter og forskellige beslutninger.

En god playbook skal ikke være en 200-siders dokument, der ligger i en mappe. Ingen åbner side 137 under en krise. En god playbook er rollebaseret, tilgængelig og handlebar. Juridisk ved, hvad juridisk skal gøre. Ingeniørteamet ved, hvad ingenørteamet skal gøre. Kommunikation ved, hvornår de skal engagere sig. Bestyrelsen ved, hvornår ledelsen vil eskalere.

Øv betyder at køre bordsskemaøvelser. Ikke én gang om året som en afkrydsningsfelt, men ofte nok til at bygge muskelhukommelse. Den første gang bestyrelsen diskuterer en AI-ulykke skal ikke være under en rigtig AI-ulykke. Den første gang, juridisk, ingenørteam, privatliv, sikkerhed, kommunikation og ledelse arbejder igennem en AI-fejl sammen, skal ikke være, når kunder allerede stiller spørgsmål.

Reager betyder at koordinere den levende begivenhed med disciplin. Hvem er i rummet? Hvad er kendte fakta? Hvad er fakta, der stadig er usikre? Hvad var beslutningerne? Hvem godkendte dem? Hvad ændrede sig mellem time 12 og time 48?

Rapportér betyder at erkende, at AI-regulering bliver mere konkrete. Den EU AI Act inkluderer alvorlige ulykkesrapporteringsforpligtelser for udbydere af visse højrisiko-AI-systemer. Detaljerne vil variere efter jurisdiktion, branche og anvendelsesområde, men retningen er klar. AI-ulykker vil mere og mere kræve en forsvarlig optegnelse af, hvad der skete, hvad der var kendt, hvilke handlinger blev udført og hvornår.

AI kan hjælpe, men kan ikke erstatte dømmekraft

Der er en fristelse til at tro, at AI-ulykkesrespons skal være fuldstændigt automatiseret. Jeg mener, det er den forkerte ramme.

AI kan hjælpe utroligt. Det kan sammenfatte fakta. Det kan identificere manglende information. Det kan sammenligne en ulykke med tidligere mønstre. Det kan udarbejde efter-aktion-rapporter. Det kan hjælpe med at kortlægge reguleringsforpligtelser. Det kan reducere administrativt arbejde, når mennesker er under pres.

Men i en alvorlig ulykke er mennesker stadig uundværlige.

Nogen skal beslutte, om fakta er tilstrækkelige. Nogen skal veje kundeimpakt. Nogen skal beslutte, om at pause et system. Nogen skal bestemme, om organisationen har overskredet en rapporteringsgrænse. Nogen skal kommunikere med ansvar og empati.

Den rigtige rolle for AI i ulykkesrespons er ikke at erstatte kriseteamet. Det er at give kriseteamet bedre kontekst, hurtigere.

NIST’s AI Risk Management Framework er nyttig, fordi det rammer AI-risikostyring omkring fire funktioner: styre, kortlægge, måle og styre. For ulykkesrespons ville jeg tilføje en praktisk udvidelse: øve.

En plan, der aldrig er testet, er ikke rigtig en plan. Det er en teori.

Bestyrelser har brug for en playbook, too

AI-risiko bliver et bestyrelsesniveau-emne, men bestyrelsesindblanding kan ikke stoppe ved oversigtsskemaer. Bestyrelser skal forstå deres rolle, før en krise opstår.

Hvornår skal bestyrelsen underrettes? Hvad kræver bestyrelsesindput? Hvad information skal ledelsen give? Hvordan skal materiel indvirkning, kundeimpakt, juridisk eksponering, reguleringsforpligtelser og operationel forstyrrelse vurderes?

Mange organisationer har sikkerhedsplaybooks, privatlivsplaybooks, kommunikationsplaybooks og juridiske playbooks. Få har en bestyrelsesplaybook for AI-ulykker. Denne lukning vil blive mere synlig, da AI-systemer flytter ind i regulerede, omsætningsgenererende og kunderelaterede arbejdsprocesser. Bestyrelsens rolle er at hjælpe organisationen med at træffe bedre beslutninger under pres, ikke at blive mere teknisk.

Tillid til AI kræver operationel resilience

Der er meget snak om tillid til AI. Det er den rigtige aspiration, men tillid skabes ikke af principper alene. Tillid skabes, når organisationer kan vise, hvordan de forbereder sig, hvordan de opdager problemer, hvordan de reagerer, hvordan de kommunikerer, hvordan de dokumenterer beslutninger og hvordan de forbedrer sig.

Cybersikkerhed gik igennem samme evolution. Organisationer brugte år på at investere i forebyggelse, og de skal fortsætte med det. Men modne organisationer lærte til sidst, at forebyggelse ikke er nok. Du har også brug for resilience. AI er på vej ind i samme fase.

Vi skal absolut bygge sikrere modeller, stærkere kontroller, bedre evalueringer, bedre red-teaming og bedre governance, men vi skal også acceptere, at ulykker vil ske. Modeller vil fejle, agenter vil opføre sig uventet, data vil lække, mennesker vil misbruge systemer, leverandører vil begå fejl, og regler vil udvikle sig.

Spørgsmålet er, om organisationen kan reagere med hast, koordination, dømmekraft og ansvar, når en ulykke opstår. Det er, hvordan AI flytter sig fra eksperimenter til pålidelig infrastruktur, og det er, hvordan resilience bliver kultur.