De fleste AI-demoer fejler alt for høfligt. Eksempelinputtet er rent. Dataene er aktuelle. Værktøjet virker. Brugeren stiller et normalt spørgsmål. Modellen giver et godt svar. Alle nikker.
Produktionen er mindre høflig. Brugerne indsætter ustrukturerede input. Kildedokumenterne er forældede. API’er får timeout. Prompts ændrer sig. Modellen følger den forkerte instruktion. En kunde stiller et spørgsmål lige uden for det tilgængelige korpus. Et værktøjskald lykkes, men opdaterer den forkerte post. Workflowet producerer noget, der er så velformuleret, at ingen opdager fejlen før senere.
Denne artikel er et register over fejltilstande i AI-systemer i produktion. Brug det før lancering, ikke efter den første hændelse.
Et review af AI til produktion bør spørge »Hvordan fejler dette?« før »Hvor imponerende er det ideelle forløb?« Hver fejltilstand skal have en kontrol, en test, en ejer og en stopbetingelse.
Fejltilstand 1: plausibelt, men forkert output
Systemet genererer et svar, der lyder korrekt, men mangler belæg eller er forkert.
Almindelige udløsere:
- Konkrete fakta uden forankring i kilder.
- Juridiske, medicinske, finansielle eller politiske spørgsmål.
- Nylige begivenheder.
- Retrieval af lav kvalitet.
- Opsummeringer af lange dokumenter, hvor den relevante dokumentation er gemt langt inde i teksten.
Kontroller:
- Kræv kildehenvisninger eller kildeuddrag til faktuelle påstande.
- Afvis spørgsmål, der ligger uden for det tilgængelige kildemateriale.
- Tilføj eval-cases for kendte mønstre med forkerte svar.
- Send output med store konsekvenser til menneskeligt review.
- Log de kilde-id’er, der blev anvendt i svaret.
Dette kontrolleres ikke med formuleringer som »vær præcis«. Det kontrolleres med kilder, test og reviewporte.
Fejltilstand 2: forældet kontekst
Svaret er forankret i kilder, men kilderne indeholder forældede oplysninger.
Eksempler:
- Gammel prisside.
- Politik, der er blevet erstattet.
- Tidligere kontraktversion.
- Forældet produktdokumentation.
- Cachelagret kundestatus.
Kontroller:
- Gem dato, version, ejer og regel for aktualitet for hver kilde.
- Foretræk autoritative kilder frem for opsummeringer.
- Marker forældede kilder i retrieval-outputtet.
- Tilføj test af aktualitet.
- Underret en ejer, når vigtige kilder er ældre end deres reviewperiode.
RAG-systemer kan med stor sikkerhed svare ud fra forældede dokumenter. Retrieval-laget skal vide, hvad »aktuelt« betyder.
Fejltilstand 3: medløberi og overdreven enighed
Modellen spejler brugerens antagelse i stedet for at udfordre den.
Det har betydning ved strategi, analyse, planlægning og beslutningsstøtte. En bruger spørger: »Denne lanceringsplan virker solid, ikke?« og får en bekræftelse i stedet for en risikoanalyse.
Kontroller:
- Bed eksplicit om modargumenter og usikkerheder.
- Brug beslutningsrubrikker frem for åbne anmodninger om godkendelse.
- Kræv svar på spørgsmålet: »Hvad ville gøre dette forkert?«
- Adskil idégenerering fra review.
- Medtag eksempler i evalueringerne, hvor brugerens præmis er forkert.
Systemet skal hjælpe brugeren med at tænke bedre, ikke blot få brugerens nuværende synspunkt til at lyde mere overbevisende.
Fejltilstand 4: prompt injection
Modellen behandler indhold, der ikke er tillid til, som en instruktion.
Eksempler:
- En webside siger: »Ignorer tidligere instruktioner.«
- En supportmail indeholder skadelige instruktioner.
- Et dokument i et RAG-korpus beder assistenten om at afsløre skjulte data.
- Et værktøjsresultat indeholder tekst, der forsøger at ændre workflowet.
Kontroller:
- Marker tydeligt indhold, der ikke er tillid til.
- Placer aldrig retrieved indhold på samme autoritetsniveau som system- eller udviklerinstruktioner.
- Begræns værktøjernes tilladelser.
- Brug positivlister til udgående handlinger.
- Test eksempler på injection i evalueringerne.
- Hold secrets ude af promptkonteksten.
Prompt injection løses ikke af én snedig systemprompt. Risikoen reduceres gennem arkitektur: datagrænser, værktøjstilladelser og validering af output.
Fejltilstand 5: usikker værktøjsbrug
Modellen kalder det forkerte værktøj, kalder det rigtige værktøj med forkerte argumenter eller udfører en handling, før den har tilstrækkelig kontekst.
Eksempler:
- Opdaterer den forkerte CRM-kontakt.
- Sender en e-mail til den forkerte modtager.
- Opretter dubletter.
- Reserverer en tid uden at bekræfte tidszonen.
- Sletter eller overskriver data.
Kontroller:
- Begynd med skrivebeskyttet adgang.
- Brug smalle værktøjer med eksplicitte skemaer.
- Valider værktøjsargumenter uden for modellen.
- Kræv bekræftelse ved skrivehandlinger.
- Tilføj idempotensnøgler.
- Log værktøjskald og resultater.
- Tilføj en nødstopfunktion.
Værktøjsbrug skal afgrænses af workflowet, ikke overlades til modellens dømmekraft.
Fejltilstand 6: skema- og kontraktdrift
Formatet på modellens output ændrer sig, eller det efterfølgende API ændrer sig, så workflowet går i stykker uden tydelig fejl.
Kontroller:
- Brug strukturerede output, hvor det er muligt.
- Valider hvert modeloutput før anvendelse.
- Behandl forkert formateret output som en fejl, der kan håndteres.
- Versioner prompts og skemaer sammen.
- Tilføj kontrakttest til efterfølgende API’er.
- Overvåg parsingfejl.
Hvis en efterfølgende node forudsætter gyldig JSON, skal workflowet bevise, at JSON-dataene er gyldige.
Fejltilstand 7: svag fallback
Systemet registrerer et problem, men retter ikke sikkert op på det.
Dårlige fallbacks:
- Tomt svar.
- Fejl uden besked.
- Generisk undskyldning uden handling.
- Endeløkke med gentagne forsøg.
- Menneskelig eskalering uden kontekst.
Gode fallbacks:
- Tydelig besked til brugeren.
- Menneskelig kø med input, kilde, fejl og den forsøgte handling.
- Nyt forsøg med backoff, men kun hvor et nyt forsøg er sikkert.
- Manuel vej til hastesager.
- Stopbetingelse ved gentagne fejl.
Fallbacken er en del af produktet. Hvis den ikke er designet, bliver fejloplevelsen improviseret.
Fejltilstand 8: manglende observerbarhed
Noget går galt, og ingen kan rekonstruere hvorfor.
Kontroller:
- Log promptskabelon og version.
- Log model og indstillinger.
- Log kilde-id’er, ikke kun svarteksten.
- Log værktøjskald, argumenter og resultater med maskering.
- Log valideringsfejl.
- Overvåg latenstid, omkostninger og fallbackfrekvens.
- Hold opbevaringsperioden kort, medmindre krav til regelefterlevelse kræver andet.
Gem ikke private ræsonneringskæder. Gem beslutningsopsummeringer, kildehenvisninger, værktøjsinput og -resultater samt valideringsresultater.
Et register over fejltilstande i produktion
Opret én række pr. fejltilstand:
| Fejltilstand | Eksempel | Kontrol | Test | Måling | Ejer | Stopbetingelse |
|---|---|---|---|---|---|---|
| Forældet kilde | Gammel pris returneres | Kontrol af kildedato | Forespørg efter gammel og ny pris | Andel af svar fra forældede kilder | Dokumentationsejer | Enhver forældet pris, der vises til en kunde |
| Usikker værktøjsbrug | Forkert CRM-opdatering | Argumentvalidering og bekræftelse | Case med dublet eller forkert kontakt | Andel af forkerte handlinger | RevOps | Én forkert skrivehandling |
Det tilhørende register, som artiklen linker til, indeholder skabelonen.
Gør ikke dette endnu
Lancér ikke kundevendt AI uden et register over fejltilstande.
Lad ikke værktøjer med skriveadgang omgå validering.
Stol ikke kun på manuelle stikprøver efter lancering.
Mål ikke kun den gennemsnitlige kvalitet. Sjældne fejl kan udgøre hele risikoen.
Accepter ikke »vi kan rulle tilbage«, medmindre nogen faktisk kan beskrive rollbackforløbet.
Konklusion
AI-systemer i produktion fejler på gentagelige måder. Hallucinationer, forældet kontekst, medløberi, prompt injection, usikker værktøjsbrug, skemadrift, svage fallbacks og manglende observerbarhed er ikke edge cases. De er en normal del af arbejdet med at sætte AI i produktion.
Den modne tilgang er at navngive fejltilstandene, indføre kontroller, teste og overvåge dem samt tildele ejerskab. En demo viser, hvad der virker én gang. Et register over fejltilstande viser, om systemet kan overleve reel brug.
