I de flesta AI-demonstrationer är även fellägena alltför välordnade. Exempelindatan är ren. Informationen är aktuell. Verktyget fungerar. Användaren ställer en normal fråga. Modellen ger ett bra svar. Alla nickar.
I produktion ser det annorlunda ut. Användare klistrar in rörig information. Källdokument blir inaktuella. API-anrop får timeout. Prompter förändras över tid. Modellen följer fel instruktion. En kund ställer en fråga strax utanför kunskapsunderlaget. Ett verktygsanrop lyckas men uppdaterar fel post. Arbetsflödet producerar något så välformulerat att felet upptäcks först långt senare.
Den här artikeln är ett fellägesregister för AI-system i produktion. Använd det före lansering, inte efter den första incidenten.
En granskning av AI för produktion bör fråga ”hur kan detta fallera?” före ”hur imponerande är normalfallet?”. Varje felläge behöver en kontroll, ett test, en ansvarig och ett stoppvillkor.
Felläge 1: trovärdigt men felaktigt svar
Systemet genererar ett svar som låter korrekt men saknar stöd eller är fel.
Vanliga utlösande faktorer:
- Specifika faktauppgifter utan källstöd.
- Juridiska, medicinska, finansiella eller policyrelaterade frågor.
- Nyligen inträffade händelser.
- Hämtning av låg kvalitet.
- Sammanfattningar av långa dokument där relevanta belägg ligger djupt begravda.
Kontroller:
- Kräv hänvisningar eller källutdrag för faktapåståenden.
- Avstå från att svara utanför det tillgängliga källunderlaget.
- Lägg till utvärderingsfall för kända mönster av felaktiga svar.
- Skicka svar med stor påverkan till mänsklig granskning.
- Logga de käll-ID:n som användes i svaret.
Försök inte styra detta med formuleringar som ”var korrekt”. Styr det med källor, tester och granskningsgrindar.
Felläge 2: inaktuell kontext
Svaret är källbaserat, men bygger på gammal information.
Exempel:
- En gammal prissida.
- En ersatt policy.
- En tidigare avtalsversion.
- Inaktuell produktdokumentation.
- Cachad kundstatus.
Kontroller:
- Lagra källans datum, version, ansvarig och aktualitetsregel.
- Prioritera auktoritativa källor framför sammanfattningar.
- Markera inaktuella källor i hämtningsresultatet.
- Lägg till tester av informationens aktualitet.
- Meddela en ansvarig när viktiga källor är äldre än sitt granskningsintervall.
RAG-system kan med stor säkerhet svara utifrån inaktuella dokument. Hämtningslagret måste veta vad ”aktuellt” betyder.
Felläge 3: överdriven medhållsamhet
Modellen bekräftar användarens antagande i stället för att ifrågasätta det.
Det är viktigt inom strategi, analys, planering och beslutsstöd. En användare frågar: ”Lanseringsplanen verkar väl genomtänkt, eller hur?” och får medhåll i stället för en riskanalys.
Kontroller:
- Be uttryckligen om motargument och osäkerheter.
- Använd beslutskriterier i stället för öppna frågor om godkännande.
- Kräv svar på frågan ”vad skulle kunna visa att detta är fel?”.
- Skilj idégenerering från granskning.
- Ta med utvärderingsfall där användarens premiss är felaktig.
Systemet ska hjälpa användaren att tänka bättre, inte bara få den befintliga uppfattningen att låta mer genomarbetad.
Felläge 4: promptinjektion
Modellen behandlar opålitligt innehåll som en instruktion.
Exempel:
- En webbsida säger ”ignorera tidigare instruktioner”.
- Ett supportmejl innehåller skadliga instruktioner.
- Ett dokument i ett RAG-underlag uppmanar assistenten att röja dold information.
- Ett verktygsresultat innehåller text som försöker ändra arbetsflödet.
Kontroller:
- Märk opålitligt innehåll tydligt.
- Placera aldrig hämtat innehåll på samma behörighetsnivå som system- eller utvecklarinstruktioner.
- Begränsa verktygens behörigheter.
- Använd tillåtelselistor för utgående åtgärder.
- Testa exempel på promptinjektion i utvärderingar.
- Håll hemligheter utanför promptens kontext.
Promptinjektion löses inte med en enda smart systemprompt. Risken minskas genom arkitektur: datagränser, verktygsbehörigheter och validering av utdata.
Felläge 5: osäker verktygsanvändning
Modellen anropar fel verktyg, anropar rätt verktyg med fel argument eller utför en åtgärd innan tillräcklig kontext finns.
Exempel:
- Uppdaterar fel kontakt i CRM-systemet.
- Skickar ett mejl till fel mottagare.
- Skapar dubblettposter.
- Bokar ett möte utan att bekräfta tidszonen.
- Raderar eller skriver över data.
Kontroller:
- Börja med skrivskyddad åtkomst.
- Använd avgränsade verktyg med explicita scheman.
- Validera verktygsargument utanför modellen.
- Kräv bekräftelse för skrivningar.
- Lägg till idempotensnycklar.
- Logga verktygsanrop och resultat.
- Lägg till en nödstoppsfunktion.
Verktygsanvändningen ska begränsas av arbetsflödet, inte överlåtas åt modellens omdöme.
Felläge 6: schema- och kontraktsdrift
Modellens utdataformat eller ett nedströms-API förändras och arbetsflödet slutar fungera utan tydliga fel.
Kontroller:
- Använd strukturerade utdata där det är möjligt.
- Validera alla modellutdata före användning.
- Behandla felformaterade utdata som ett återställningsbart fel.
- Versionshantera prompter och scheman tillsammans.
- Lägg till kontraktstester för nedströms-API:er.
- Övervaka tolkningsfel.
Om en nedströmsnod förutsätter giltig JSON måste arbetsflödet verifiera att JSON-innehållet är giltigt.
Felläge 7: bristfällig felhantering
Systemet upptäcker ett problem men återhämtar sig inte på ett säkert sätt.
Dålig felhantering:
- Tomt svar.
- Tyst fel.
- Generisk ursäkt utan nästa åtgärd.
- Oändlig slinga av nya försök.
- Eskalering till en människa utan kontext.
Bra felhantering:
- Ett tydligt meddelande till användaren.
- En manuell kö med indata, källa, fel och försökt åtgärd.
- Nya försök med backoff endast när det är säkert att försöka igen.
- En manuell väg för brådskande fall.
- Ett stoppvillkor vid upprepade fel.
Felhantering är en del av produkten. Om den inte utformas i förväg blir användarupplevelsen vid fel improviserad.
Felläge 8: luckor i observerbarheten
Något går fel och ingen kan i efterhand fastställa varför.
Kontroller:
- Logga promptmall och version.
- Logga modell och inställningar.
- Logga käll-ID:n, inte bara svarstexten.
- Logga verktygsanrop, argument och resultat med maskning av känsliga uppgifter.
- Logga valideringsfel.
- Följ latens, kostnad och andelen fall som går till reservflöde.
- Använd kort lagringstid om inte regelefterlevnad kräver något annat.
Lagra inte modellens privata tankekedja. Lagra beslutssammanfattningar, källhänvisningar, verktygsindata och -resultat samt valideringsutfall.
Ett fellägesregister för produktion
Skapa en rad per felläge:
| Felläge | Exempel | Kontroll | Test | Mätvärde | Ansvarig | Stoppvillkor |
|---|---|---|---|---|---|---|
| Inaktuell källa | Gammalt pris returneras | Kontroll av källdatum | Fråga efter gammalt/nytt pris | Andel svar från inaktuella källor | Dokumentansvarig | Ett enda inaktuellt pris visas för kund |
| Osäker verktygsanvändning | Fel CRM-uppdatering | Argumentvalidering + bekräftelse | Fall med dubblett/fel kontakt | Andel felaktiga åtgärder | RevOps | En enda felaktig skrivning |
Det tillhörande registret som länkas från artikeln innehåller mallen.
Gör inte detta ännu
Lansera inte kundinriktad AI utan ett fellägesregister.
Låt inte verktyg med skrivbehörighet kringgå validering.
Förlita dig inte enbart på manuella stickprov efter lansering.
Mät inte bara genomsnittlig kvalitet. Sällsynta fel kan utgöra hela risken.
Godta inte ”vi kan återställa” om ingen faktiskt kan beskriva återställningsvägen.
Slutsats
AI-system i produktion fallerar på återkommande sätt. Hallucinationer, inaktuell kontext, överdriven medhållsamhet, promptinjektion, osäker verktygsanvändning, schemadrift, bristfällig felhantering och luckor i observerbarheten är inte randfall. De är en normal del av att driftsätta AI.
Ett moget arbetssätt är att identifiera fellägen, införa kontroller, testa och övervaka dem samt utse ansvariga. En demo visar vad som fungerar en gång. Ett fellägesregister visar om systemet klarar verklig användning.
