När AI strular: bygg en status-tavla som visar vad som påverkas

Det värsta med en AI-incident är sällan att en modell krånglar i några minuter. Det värsta är när ingen vet om det påverkar dagens kundlöften, en intern rapport, ett skolpass, en offert eller bara en testprompt som kan vänta.

Det är därför fler verksamheter behöver en enkel AI-status-tavla. Inte en stor kontrollcentral. En plats där ni snabbt kan se: vilken leverantör strular, vilken del av tjänsten är påverkad, vilket arbetsflöde hos oss berörs och vem bestämmer nästa steg?

Statussidan räcker inte längre

De senaste dygnen visar varför. OpenAI hade två lösta incidenter i ChatGPT den 21 maj: en för betalda planer och en för ChatGPT 5.5 Thinking. Det säger något, men inte allt. Om ni använder ChatGPT i ett kundnära arbetsflöde behöver ni veta om felet rör er plan, er modell och just den uppgift som står i kö.

Källa: OpenAI Status, betalda ChatGPT-planer

Källa: OpenAI Status, ChatGPT 5.5 Thinking

Claude visade samma poäng på ett annat sätt. Den 21 maj var det en avklarad incident i Claude.ai. Morgonen den 22 maj visade statusflödet för Claude en pågående modellincident med Opus 4.7, Sonnet 4.6 och Haiku 4.5, och sidan listade påverkan på claude.ai, Console, API, Claude Code och Claude Cowork. Det är inte samma sak som "Claude är nere". Det är en karta över vilka vägar som kan vara osäkra.

Källa: Claude Status, incident i Claude.ai

Källa: Claude Status, incident för flera modeller

Mistrals statusaktivitet är ännu mer komponentstyrd. Den 21 maj listades korta lösta händelser för Conversations API, OCR API och Integrations API-kopplingar som document_library och deepwiki. För en organisation som använder AI för dokumenttolkning, ärendehistorik eller interna kunskapsbaser är det helt olika problem.

Källa: Mistral AI Status, aktivitet

En AI-status-tavla ska svara på en praktisk fråga

Frågan är inte "vilken leverantör hade en incident?". Den frågan är för grov.

Den praktiska frågan är: behöver vi vänta, försöka igen, byta verktyg, pausa ett arbetsflöde eller meddela någon?

Bygg tavlan så att den fångar beslutet, inte bara nyheten:

• Leverantör och tjänst: OpenAI ChatGPT, Claude API, Mistral OCR API, Gemini API, Manus eller Perplexity.
• Påverkad del: modell, app, API, koppling, filuppladdning, webbsökning, kodagent eller administrativ konsol.
• Vårt arbetsflöde: kundsvar, offertutkast, veckorapport, dokumenttolkning, lektionsplanering, kodgranskning, CRM-uppdatering.
• Ägare: personen som får säga "vi väntar", "vi byter väg" eller "vi skickar en förklaring".
• Reservväg: annan modell, manuell körning, senare nytt försök, fryst leverans eller färdig kundtext.
• Fönster för nytt försök: när ni testar igen och vem som stänger incidenten internt.
• SOP-effekt: ska rutinen uppdateras, eller var detta bara en notis?

Det räcker ofta med ett kalkylark, en Notion-sida eller en enkel Trello-lista. Poängen är inte verktyget. Poängen är att slippa gissa medan någon väntar på svar.

Lägg också in "ingen incident" som bevis

Det låter nästan för banalt, men det är viktigt: en lugn statussida är också data.

Manus och Perplexity hade inga rapporterade incidenter i de kontrollerade statusflödena när dagens research gjordes. Det betyder inte att alla användare alltid hade en perfekt upplevelse. Men det betyder att ni inte ska skylla ett misslyckat arbetsflöde på dem utan mer bevis. Kanske var det prompten. Kanske rättigheterna. Kanske en lokal integration. Kanske filen.

Källa: Manus Status

Källa: Perplexity Status

Samma sak gäller när Google AI Studio och Gemini API visar en specifik infrastrukturhändelse. Då ska tavlan säga "AI Studio / Gemini API" och berört arbetsflöde, inte bara "Google strulade". Den skillnaden gör felsökningen snabbare och kommunikationen mindre dramatisk.

Källa: Google AI Studio Status

Så använder du tavlan utan att skapa mer administration

Gör den liten först. En rad per händelse. En ägare. Ett beslut.

Börja med tre arbetsflöden som faktiskt får konsekvenser om AI:n krånglar:

• Ett kundnära flöde, till exempel svarsförslag, supportutkast eller offertunderlag.
• Ett internt deadline-flöde, till exempel veckorapport, fakturakontroll eller dokumentgranskning.
• Ett kunskapsflöde, till exempel sökning i dokument, OCR, utbildningsmaterial eller intern FAQ.

Skriv sedan vad som händer när varje flöde får rött eller gult ljus. Inte i perfekt juridiskt språk. Bara tillräckligt konkret för att en kollega ska kunna agera klockan 16:40 en torsdag.

Exempel:

• Om ChatGPT 5.5 Thinking är segt: kör enklare modell för utkast, men vänta med slutlig bedömning.
• Om OCR API strular: stoppa dokumentflödet och meddela att underlaget granskas manuellt.
• Om en koppling är påverkad: låt inte AI:n svara med gammal eller halv hämtad information.
• Om ingen statussida visar fel: kontrollera behörighet, prompt, filformat och lokal integration innan ni eskalerar.

När Hammer brukar komma in

Det här är typiskt Tool Forge / Verktygssmide-arbete: inte att jaga varje AI-rubrik, utan att göra arbetsflödet tryggare när AI redan används i vardagen.

Om ett AI-flöde påverkar kundlöften, ekonomi, utbildning, intern rapportering eller ärenden som människor väntar på, då förtjänar det en routingregel. Börja med en tavla som ni faktiskt orkar hålla uppdaterad. När den fungerar kan ni automatisera delar av den: statusbevakning, Slack-notiser, regler för nytt försök, kundtexter och SOP-uppdateringar.

En bra AI-status-tavla gör inte verksamheten immun mot driftstörningar. Den gör något mer realistiskt: den gör nästa beslut tydligt.