AI-incidenter blir alltmer operativa kriser. Vi måste hantera dem på det sättet.

Under de senaste åren har de flesta organisationer talat om AI-risk i termer av styrning.

Är modellen exakt? Är den rättvis? Är data godkänd? Följer vi nya regler? Det är viktiga frågor, men de är inte de enda frågorna. Den mer brådskande frågan är vad som händer när något går fel?

Vad händer när en AI-agent vidtar en åtgärd som den aldrig var tänkt att vidta? Vad händer när en modell läcker känsliga data? Vad händer när en hallucinerad svar skapar rättsliga problem, eller när ett automatiserat beslut påverkar en kund, anställd, patient eller partner på ett sätt som inte lätt kan ångras?

Och kanske mest praktiskt: vart går organisationen för att samordna svaret? Det är den förändring som nu sker. AI-risk blir en operativ resilience-fråga, inte bara en styrningsfråga.

AI flyttar från experiment till företagets arbetsmaskineri. Det integreras i kundsupport, programvaruutveckling, finansiella operationer, hälsoflöden, rekrytering, anspråksbehandling, leverantörskedjor och intern automatisering. När AI blir mer kopplat till affären, blir AI-fel affärsincidenter.

Den OECD AI-incidentövervakning spårade 596 AI-incidenter i januari 2026 ensam, 200% tillväxt från föregående år. Insatser som OECD AI-incidentövervakning och AI-incidentdatabas dokumenterar negativa eller skadliga resultat som involverar AI-system så att branschen kan lära sig av erfarenhet på samma sätt som flyg och cybersäkerhet har gjort i åratal.

Den jämförelsen är viktig. Mogna industrier frågar hur man kan förhindra fel och hur man kan svara när felet ändå inträffar.

AI-incidenter beter sig inte som traditionella programvarufel

Ett traditionellt programvarufel har vanligtvis en relativt tydlig gräns. Något går sönder, ingenjörer undersöker, och teamet återskapar problemet, lagar koden och skickar en lösning.

Men AI-incidenter är smutsigare. De kan vara probabilistiska, intermittent och uppstå från interaktionen mellan en modell, en prompt, ett återvinningssystem, ett plug-in, en agent, en användare och en nedströms affärsprocess. Ibland fungerar AI-systemet exakt som det är tänkt, men designen är ofullständig för den miljö där det används. Det gör svaret mer utmanande.

En hallucination i en konsumentchattbot är en sorts problem. En hallucination inom ett juridiskt, finansiellt, kliniskt eller HR-flöde är en annan. En biased utdata i testning är allvarlig. En biased beslutsprocess som körs i produktion i stor skala är något annat helt. En AI-assistent som utarbetar ett e-postmeddelande är en sak, men en agent som kan ändra behörigheter, ge återbetalningar, uppdatera register, utlösa flöden eller köra kod är en helt annan kategori av risk.

MIT AI Risk Repository fångar en bred serie AI-risker, inklusive falsk eller vilseledande information, integritets- och säkerhetsbrott, diskriminering, missbruk och systemsäkerhetsproblem. OWASP:s topp 10 för LLM-applikationer höjer liknande risker som promptinjektion, känslig informationsläcka, osäker utdatahantering och överdriven agent. Dessa är praktiska felmoder, snarare än abstrakta tekniska problem.

Om en AI-agent har för stor auktoritet, kan den vidta åtgärder som ingen människa avsett. Om en promptinjektion lyckas, kan systemet läcka information eller följa fientliga instruktioner. Om känsliga data läcker genom en modell eller ett återvinningssystem, har svaret rättsliga, regulatoriska, kund- och ryktesmässiga konsekvenser. Det är därför språket för AI-styrning ibland kan bli för passivt. Styrning berättar vad som borde vara sant. Incidenthantering berättar vad man ska göra när verkligheten rör sig snabbare än policyn.

Svaret kommer att vara tvärfunktionellt

En av de största lärdomarna från cybersäkerhet är att incidenter sällan stannar inom säkerhetsteamet. I början kan en händelse se teknisk ut. Mycket snabbt involverar det juridiska, kommunikation, affärsledning, regelefterlevnad, kundteam, utomstående rådgivare, försäkringsgivare, forensiska specialister och ibland styrelsen.

AI-incidenter kommer att följa samma mönster.

Tänk dig en modell som exponerar känsliga kunduppgifter. Säkerhets- och integritetsteam behöver förstå vad som hände. Juridik behöver bedöma skyldigheter. Kommunikation kan behöva förbereda sig för kunder, myndigheter eller media. Teknikteam kan behöva inaktivera eller rulla tillbaka ett system. Affärsledare kan behöva väga kontinuitet mot inneslutning.

Eller tänk dig en AI-agent som börjar vidta oavsiktliga åtgärder över företagssystem. Det tekniska teamet kan stänga av det, men organisationen behöver fortfarande veta vad det gjorde, vem som påverkades, vilka beslut togs, om avtalsenliga skyldigheter utlöstes och hur samma fel kommer att förhindras i framtiden. Det kan inte lösas av AI-teamet ensamt.

Organisationer bör bygga tvärfunktionell muskelminne innan de behöver det. Det betyder tydliga eskaleringstriggers, tydliga roller, tydliga beslutsrättigheter, tydliga kommunikationsvägar, tydlig dokumentation och övning.

I en kris är samordning infrastruktur, inte bara en mjuk färdighet.

Den AI som undersöks bör inte kontrollera svaret

Det finns ett annat problem som organisationer behöver tänka på mycket mer noggrant. Om AI-systemet som undersöks kan komma åt samma kommunikation, dokument, flöden eller automatisering som används för att samordna svaret, har organisationen ett problem.

I cybersäkerhet är detta ett välkänt princip. Om ransomware har komprometterat det företagsnätverk, koordinerar du inte svaret på system som angriparen kan läsa, störa eller manipulera. Du flyttar utanför bandet. Du separerar incidenten från svaret.

Samma logik gäller för AI.

Ett AI-system kan inte vara illvilligt i mänsklig mening, men om det kan se svaret, sammanfatta svaretmötet, påverka arbetsflödet, rekommendera nästa steg eller fungera inom samma miljö som används för att innesluta det, då har organisationen inte isolerat svaret tillräckligt.

Detta blir ännu viktigare med agenterande AI. Googles Secure AI Framework betonar risker som promptinjektion, datapåverkan och obehöriga åtgärder och kartlägger dem till kontroller över hela AI-livscykeln. Det är rätt ram. När AI-system blir mer kapabla att agera över verktyg, data och arbetsflöden, behöver organisationer tänka på modellsäkerhet OCH operativ separation.

Tänk på det som att utreda en brand. Du skulle inte vilja att sprinklersystemets kontroller var kopplade till samma felaktiga system du försöker diagnostisera.

Förbered, öva, svara, rapportera

En användbar ram för AI-incidentberedskap är samma som den som har mognat i cybersäkerhet: förbered, öva, svara, rapportera.

Förbered betyder att definiera incidenttyper innan de händer, som bias, hallucination, data läcka, modellglidning, promptinjektion, agenter som springer amok, obehörig verktygsanvändning och tredjepartsmodellmisslyckande. Var och en kräver olika intressenter och olika beslut.

En bra playbook bör inte vara ett 200-sidigt dokument som ligger i en mapp. Ingen öppnar sida 137 under en kris. En bra playbook är rollbaserad, tillgänglig och handlingsbar. Juridik vet vad juridik behöver göra. Teknik vet vad teknik behöver göra. Kommunikation vet när den ska engagera sig. Styrelsen vet när ledning kommer att eskalera.

Öva betyder att köra bordssimuleringar. Inte en gång om året som en kryssruta, utan ofta nog för att bygga muskelminne. Den första gången styrelsen diskuterar en AI-incident bör inte vara under en riktig AI-incident. Den första gången juridik, teknik, integritet, säkerhet och kommunikation arbetar igenom ett AI-fel tillsammans bör inte vara när kunder redan ställer frågor.

Svara betyder att koordinera den levande händelsen med disciplin. Vem är i rummet? Vilka fakta är kända? Vilka fakta är fortfarande osäkra? Vilka beslut togs? Vem godkände dem? Vad ändrades mellan timme 12 och timme 48?

Rapportera betyder att inse att AI-reglering blir mer konkret. EU:s AI-lag innehåller allvarliga incidentrapporteringskrav för leverantörer av vissa högrisk-AI-system. Detaljerna kommer att variera beroende på jurisdiktion, industri och användningsfall, men riktningen är tydlig. AI-incidenter kommer alltmer att kräva en försvarbar post om vad som hände, vad som visste, vilka åtgärder vidtogs och när.

AI kan hjälpa, men det kan inte ersätta omdöme

Det finns en frestelse att tro att AI-incidenthantering bör vara helt automatiserad. Jag tycker att det är felaktigt.

AI kan hjälpa enormt. Det kan sammanfatta fakta. Det kan identifiera saknad information. Det kan jämföra en incident med tidigare mönster. Det kan utarbeta efteråt-rapporter. Det kan hjälpa till att kartlägga regulatoriska skyldigheter. Det kan minska administrativ börda när människor är under tryck.

Men i en allvarlig incident är människor fortfarande oumbärliga.

Någon måste bestämma om fakta är tillräckliga. Någon måste väga kundpåverkan. Någon måste bestämma om man ska pausa ett system. Någon måste avgöra om organisationen har överskridit en rapporteringströskel. Någon måste kommunicera med ansvar och empati.

Den rätta rollen för AI i incidenthantering är inte att ersätta krisgruppen. Det är att ge krisgruppen bättre sammanhang, snabbare.

NIST:s AI-riskhanteringsramverk är användbart eftersom det ramverkar AI-riskhantering kring fyra funktioner: styra, kartlägga, mäta och hantera. För incidenthantering skulle jag lägga till en praktisk utvidgning: öva.

En plan som aldrig har testats är inte riktigt en plan. Det är en teori.

Styrelser behöver en playbook, också

AI-risk blir ett styrelseämne, men styrelseengagemang kan inte sluta med tillsynssidor. Styrelser behöver förstå sin roll innan en kris inträffar.

När ska styrelsen informeras? Vilka beslut kräver styrelseinput? Vilken information kommer ledningen att tillhandahålla? Hur kommer materiell påverkan, kundpåverkan, rättsliga skyldigheter, regulatoriska skyldigheter och operativa avbrott att bedömas?

Många organisationer har säkerhetsplaybooks, integritetsplaybooks, kommunikationsplaybooks och juridiska playbooks. Färre har en styrelseplaybook för AI-incidenter. Det gapet kommer att bli mer synligt när AI-system flyttar in i reglerade, intäktsgenererande och kundorienterade flöden. Styrelsens roll är att hjälpa organisationen att fatta bättre beslut under tryck, inte att bli mer teknisk.

Tillförlitlig AI kräver operativ resilience

Det finns mycket diskussion om tillförlitlig AI. Det är rätt aspiration, men förtroende skapas inte av principer ensamma. Förtroende skapas när organisationer kan visa hur de förbereder sig, hur de upptäcker problem, hur de svarar, hur de kommunicerar, hur de dokumenterar beslut och hur de förbättrar.

Cybersäkerhet gick igenom samma utveckling. Organisationer investerade år i förebyggande, och de borde fortsätta att göra det. Men mogna organisationer lärde sig så småningom att förebyggande inte räcker. Du behöver också resilience. AI går in i samma fas.

Vi bör absolut bygga säkrare modeller, starkare kontroller, bättre utvärderingar, bättre red teaming och bättre styrning, men vi bör också acceptera att incidenter kommer att hända. Modeller kommer att misslyckas, agenter kommer att bete sig oväntat, data kommer att läcka, människor kommer att missbruka system, leverantörer kommer att göra misstag och regler kommer att utvecklas.

Frågan är om organisationen kan svara med hastighet, samordning, omdöme och ansvar när en incident inträffar. Det är hur AI flyttar från experiment till pålitlig infrastruktur, och det är hur resilience blir kultur.