AI-incidentplan: vad gör ni när leverantören hackar?

AI-statussidor är lätta att ignorera tills de plötsligt handlar om ert eget arbetsflöde. Den 7 juni syntes fyra olika sorters störningar i samma dygn: modellfel hos Claude, OCR-problem hos Mistral, högre tokenanvändning i Gemini API:s context caching och ChatGPT-konversationer som påverkade Free- och Go-användare hos OpenAI.

Det är inte ett argument för att sluta använda AI. Det är ett argument för att sluta säga "AI ligger nere" som om allt vore samma fel.

Om AI redan skriver kundutkast, läser inkommande dokument, söker i interna regler eller kör administrativa delsteg behöver ni en enkel incidentplan. Inte en stor krispärm. Bara en rutin som säger: vad pausar vi, vad får köra vidare, vad byter fallback och vad måste köras om?

Källa: Claude Status, Mistral AI Status, Google AI Studio Status, OpenAI Status.

En AI-incident är nästan aldrig "hela AI:n"

Det viktiga är komponenten. Ett chattproblem för en viss användarnivå är inte samma sak som ett API-fel. Ett OCR-avbrott påverkar dokumentflöden men inte nödvändigtvis vanliga textsvar. Ett cachingproblem kan ge korrekta svar men fel kostnadsbild.

Det gör incidenthanteringen mer praktisk än dramatisk. Fråga först:

• Vilken leverantör och vilken komponent är påverkad?
• Gäller det chatten, API:t, en modell, OCR, filuppladdning, caching eller kontoinloggning?
• Vilka av våra arbetsflöden använder just den komponenten?
• Har vi jobb som skapades under incidentfönstret och behöver granskas eller köras om?

I Claude-fallet handlade den 7 juni om förhöjda fel på flera modeller och senare Opus 4.7. Mistral-incidenten var tydligt avgränsad till OCR API i knappt en halvtimme. OpenAI-statusen gällde ChatGPT-konversationer för Free/Go, inte OpenAI API eller Codex. Gemini-signalen var ännu mer lurig: context caching kunde ge högre tokenanvändning än väntat, vilket kan vara ett kostnadsproblem även när svaren ser bra ut.

Källa: Claude Status, incidenthistorik, Mistral OCR API Degraded, OpenAI Status RSS, Google AI Studio Status.

Gör statusraden till ett beslut

En bra incidentplan behöver inte börja med teknik. Den kan börja med ett litet beslutskort för varje AI-flöde.

Skriv ner primär leverantör, kritisk komponent, acceptabel fallback, stoppregel, ansvarig person och vad som ska loggas. Det räcker långt. Poängen är att slippa uppfinna beslutet när någon redan väntar på ett svar, en faktura eller ett kundutkast.

Exempel:

• Ett internt sammanfattningsflöde kan ofta vänta eller byta modell.
• En agent som godkänner fakturaunderlag ska hellre pausa än gissa.
• Ett OCR-flöde för ansökningar bör lägga dokument i kö och markera vilka filer som OCR-tolkades under incidentfönstret.
• En kostnadsincident ska inte bara märkas som "lyckad körning" om tokenförbrukningen blev fel.

Det låter torrt. Bra. Incidentrutiner ska vara lite tråkiga. Panik är dyrare.

Första versionen av runbooken

Börja med detta, inte med ett tjugosidigt dokument.

1. Upptäck. Prenumerera på statuskällor för de leverantörer ni faktiskt använder. Logga också era egna fel, svarstider, tokenkostnader och ovanliga omkörningar.

2. Avgränsa. Skriv incidenten som komponent plus arbetsflöde: "Mistral OCR för inkommande PDF:er", "Claude API för supportutkast", "Gemini context caching för utvärderingar". Undvik den breda etiketten "AI-problem".

3. Pausa riskabla steg. Stoppa jobb som ändrar data, skickar kundkommunikation, godkänner ekonomi eller bygger beslutsunderlag direkt från osäker input.

4. Byt fallback där det är säkert. Utkast, sammanfattningar och interna sökfrågor kan ofta byta modell eller köas om. Juridik, ekonomi, HR och databasskrivningar kräver hårdare regler.

5. Kör om med spårning. Spara tidsfönster, input-ID, leverantör, modell, komponent, kostnad och resultatstatus. Kör om bara de jobb som faktiskt berördes.

6. Skriv enkel mänsklig text. Om kunder eller kollegor påverkas, säg vad som hände, vad ni har pausat och när ni väntar er nästa uppdatering. Skriv inte "vår AI är nere" om det egentligen var OCR, caching eller en viss chatttier.

7. Gör efterkontrollen. Justera fallback-regler, budgetvarningar och testfall medan händelsen fortfarande är färsk.

OpenAI:s SchemaFlow-exempel är relevant här även om det handlar om databasändringar, inte driftstörningar. Mönstret är nyttigt: låt AI skapa spårbara artefakter och planer, men kör inte riskabla ändringar utan kontroller, tester och godkännande.

Källa: OpenAI Cookbook: SchemaFlow.

Det här är inte bara för utvecklare

De flesta incidentbeslut är verksamhetsbeslut. Ska kundservice vänta med svar? Ska ekonomi stoppa attest? Ska skolan skicka ut elevsammanfattningar om källfilen lästes under en OCR-störning? Ska en konsult använda fallbackmodellen för ett första utkast men inte för ett skarpt råd?

Det är därför ansvaret behöver ligga nära arbetsflödet, inte bara hos den som råkade koppla API:t. En ägare för processen kan säga: "Det här får vänta", "det här kan köras om" eller "det här behöver mänsklig granskning innan det lämnar huset".

En enkel Hammer-väg framåt

Om ni redan använder AI i riktiga rutiner, börja med en halvtimmes övning. Välj ett flöde. Skriv ner leverantör, komponent, stoppregel, fallback och omkörningslogg. Testa sedan frågan: vad hade vi gjort om felet kom i dag klockan 14:00?

Hammer kan hjälpa till att göra detta praktiskt i Tool Forge eller Mindset Forge: kartlägga AI-flöden, sätta stoppregler, lägga in status- och kostnadsloggar och bygga omkörning där det behövs. Inte för att varje incident är farlig. Utan för att AI som används i vardagen också behöver vardagliga rutiner.