Wenn eine KI-Automation falsch entscheidet, muss der Prompt überarbeitet werden. Das ist eine verbreitete Annahme, aber als erste Diagnose unzureichend. Zwischen der ursprünglichen Eingabe und der sichtbaren Aktion liegen meist mehrere Verarbeitungsschritte. Jeder davon kann Informationen verlieren, Werte verändern oder ein korrektes Modellergebnis falsch weitergeben.
Eine belastbare Fehleranalyse verfolgt deshalb einen fehlgeschlagenen Vorgang durch die gesamte Automation. Entscheidend ist die erste Stelle, an der das tatsächliche Ergebnis vom erwarteten Zustand abweicht. Alles danach kann fehlerhaft aussehen und trotzdem nur die Folge eines früheren Problems sein.
Warum der sichtbare Fehler selten die Ursache verrät
Angenommen, eine Automation klassifiziert eingehende Supportanfragen und legt daraus Tickets an. Eine Nachricht beschreibt, dass die Website erreichbar ist, aber der Produktexport nicht mehr funktioniert. Im Ticketsystem erscheint sie als vollständiger Website-Ausfall mit höchster Priorität.
Auf den ersten Blick hat die KI falsch klassifiziert. Der tatsächliche Ablauf kann jedoch ganz anders aussehen:
- Die Automation hat nur den Betreff an das Modell übergeben und den Nachrichtentext wegen eines Fehlers bei der HTML-Bereinigung verworfen.
- Der vollständige Text kam beim Modell an, aber die Kriterien für einen kritischen Ausfall waren im Prompt nicht definiert.
- Das Modell hat eine mittlere Priorität zurückgegeben, während die nachfolgende Zuordnung diesen Wert mit dem höchsten Prioritätscode des Ticketsystems verbunden hat.
- Die Antwort war formal ungültig und ein unscheinbarer Standardwert hat daraus automatisch die höchste Priorität gemacht.
Alle Varianten erzeugen dasselbe sichtbare Ergebnis. Nur eine davon lässt sich sinnvoll durch eine Promptänderung beheben. Wer sofort am Prompt arbeitet, kann den Fehler daher überdecken oder neue Abweichungen einbauen. Fünf Formulierungsänderungen später ist dann immerhin zuverlässig unklar, welche davon etwas bewirkt hat.
Untersuche zuerst genau einen fehlgeschlagenen Vorgang
Beginne nicht mit einer Sammlung sämtlicher Auffälligkeiten. Wähle einen einzelnen Vorgang, dessen Eingabe und falsches Ergebnis du nachvollziehen kannst. Dieser Fall wird zu deinem Referenzfall für die Analyse.
Halte dafür schriftlich fest:
- Welche ursprüngliche Eingabe die Automation erhalten hat
- Welches Ergebnis tatsächlich entstanden ist
- Welches Ergebnis du stattdessen erwartet hast
- Auf welche konkrete Information du diese Erwartung stützt
- Welche Folgeaktion die Automation ausgeführt hat
„Die Klassifizierung ist falsch“ reicht als Erwartung nicht aus. Besser ist eine prüfbare Beschreibung: „Die Anfrage soll als Exportproblem mit mittlerer Priorität eingeordnet werden, weil die Website laut Nachricht erreichbar bleibt und keine Bestellungen verloren gehen.“
Diese Begründung trennt fachliche Regeln von persönlichem Bauchgefühl. Wenn sich schon im Team niemand auf das richtige Ergebnis einigen kann, fehlt der Automation keine bessere KI. Dann fehlt eine klare Entscheidungsregel.
Verfolge den Datenweg über feste Prüfpunkte
Für den Referenzfall brauchst du einen Ausführungsverlauf, der die wichtigen Zwischenstände sichtbar macht. Ein einzelner Eintrag wie „KI-Schritt erfolgreich“ hilft dabei kaum. Technisch erfolgreich bedeutet zunächst nur, dass der Schritt keinen behandelten Fehler ausgelöst hat. Auch eine tadellos übermittelte Fehlentscheidung kann technisch erfolgreich sein.
Prüfe den Vorgang in dieser Reihenfolge:
- Roheingabe: Was hat das Formular, Postfach, CRM oder andere Quellsystem tatsächlich geliefert?
- Aufbereitete Eingabe: Welche Inhalte blieben nach Bereinigung, Kürzung, Zusammenführung oder Konvertierung übrig?
- Modellanfrage: Welcher Systemtext, welche Anweisung, welche Daten und welche Ausgabevorgaben wurden wirklich gesendet?
- Rohe Modellantwort: Was kam unverändert vom Modell zurück?
- Verarbeitetes Ergebnis: Wie wurden Text, JSON-Felder oder Funktionsparameter aus der Antwort übernommen?
- Validierung: Welche Prüfungen wurden ausgeführt, bestanden oder übersprungen?
- Zielaktion: Welche Werte gingen schließlich an das Ticketsystem, CRM, CMS oder eine andere Anwendung?
Ergänze nach Möglichkeit die verwendete Promptversion, Workflowversion und Modellbezeichnung. Ohne diese Angaben lässt sich ein älterer Fehler möglicherweise nicht mit denselben Bedingungen wiederholen.
Solche Protokolle können Kundendaten, interne Texte oder personenbezogene Informationen enthalten. Speichere deshalb nur, was du für die Diagnose benötigst, begrenze den Zugriff und entferne sensible Inhalte, wenn sie für den Fehler unerheblich sind. Weitere Entscheidungshilfe dazu findest du im Artikel über den sicheren Umgang mit Projektdaten in KI-Prompts.
Suche die erste Abweichung, nicht den auffälligsten Fehler
Vergleiche nun jeden Prüfpunkt mit dem Zustand, den du an dieser Stelle erwartest. Sobald du die erste Abweichung findest, hältst du an. Die späteren Fehler sind zunächst nur Folgewirkungen.
Die Roheingabe ist bereits unvollständig
Fehlen Informationen schon in der Quelle, kann das Modell sie nicht zuverlässig rekonstruieren. Typische Ursachen sind nicht übertragene Formularfelder, fehlende Anhänge, Berechtigungsprobleme oder ein Ereignis, das ausgelöst wird, bevor alle Daten gespeichert wurden.
Die Korrektur gehört an die Schnittstelle zum Quellsystem. Eine zusätzliche Promptanweisung wie „Berücksichtige alle relevanten Angaben“ beschafft keine Angaben, die nie übertragen wurden.
Die Aufbereitung verändert den Inhalt
Vor einem KI-Aufruf werden Inhalte häufig gekürzt, von HTML befreit oder aus mehreren Feldern zusammengesetzt. Dabei können Verneinungen, Absätze, Tabellen oder Feldbezeichnungen verloren gehen. Auch eine vermeintlich harmlose Zeichenbegrenzung kann ausgerechnet den Teil entfernen, der eine Anfrage fachlich einordnet.
Vergleiche die Roheingabe direkt mit dem aufbereiteten Text. Prüfe besonders fehlende Abschnitte, vertauschte Feldnamen, leere Platzhalter und abgeschnittene Enden. Liegt hier die erste Abweichung, musst du die Transformation korrigieren.
Die Modellanfrage enthält falschen oder widersprüchlichen Kontext
Manchmal sind alle Daten vorhanden, werden aber zusammen mit veralteten Regeln oder widersprüchlichen Anweisungen gesendet. Das passiert beispielsweise, wenn ein allgemeiner Systemtext „kritische Probleme großzügig erkennen“ verlangt, während der eigentliche Arbeitsschritt nur bestätigte Komplettausfälle hoch priorisieren soll.
Prüfe die tatsächlich gesendete Anfrage und nicht nur die Promptvorlage im Editor. Variablen, bedingte Textbausteine oder ältere Workflowstände können dazu führen, dass beide voneinander abweichen.
Die Anfrage ist korrekt, die Antwort fachlich falsch
Erst an dieser Stelle ist die Arbeit am Prompt oder an der Modellnutzung begründet. Die Eingabe ist vollständig, die fachliche Erwartung eindeutig und die Modellantwort weicht trotzdem davon ab.
Eine sinnvolle Korrektur kann dann darin bestehen, Entscheidungskriterien ausdrücklich zu definieren, mehrdeutige Begriffe zu ersetzen oder relevante Gegenbeispiele einzubauen. Für die Ticketklassifizierung könntest du etwa festlegen, dass ein kritischer Website-Ausfall nur vorliegt, wenn zentrale öffentliche Funktionen nicht erreichbar sind. Ein gestörter Export wäre eine andere Kategorie.
Verlange außerdem eine kurze Begründung anhand der Eingabe. Sie macht eine falsche Zuordnung leichter nachvollziehbar. Eine Begründung garantiert allerdings keine richtige Entscheidung; ein Modell kann auch einen Fehler sprachlich überzeugend dekorieren.
Die Modellantwort ist richtig, wird aber falsch verarbeitet
Bei strukturierten Antworten kann der Fehler nach dem Modellaufruf entstehen. Feldnamen werden verwechselt, Wahrheitswerte als Text behandelt oder interne Kennzahlen falsch zugeordnet. Besonders tückisch sind unterschiedliche Bedeutungen numerischer Codes. Die Priorität „1“ kann in einem System niedrig und in einem anderen kritisch bedeuten.
Vergleiche die rohe Antwort mit dem daraus erzeugten Datensatz. Wenn die fachliche Aussage dort kippt, liegt das Problem im Parser, in der Feldzuordnung oder in einem nachfolgenden Transformationsschritt.
Die Validierung akzeptiert ein unbrauchbares Ergebnis
Ein gültiges JSON-Objekt ist noch kein fachlich brauchbares Ergebnis. Eine technische Validierung prüft beispielsweise, ob das Feld priority vorhanden ist und einen erlaubten Wert enthält. Sie erkennt nicht automatisch, ob eine hohe Priorität durch den Inhalt gedeckt ist.
Ergänze deshalb fachliche Prüfungen, soweit sie sich eindeutig formulieren lassen. Eine Klassifizierung kann etwa abgelehnt werden, wenn Pflichtinformationen fehlen oder sich Kategorie und vorgesehene Folgeaktion widersprechen. Unklare Fälle sollten einen definierten Ausweichweg erhalten, statt stillschweigend mit einem riskanten Standardwert weiterzulaufen.
Wiederhole den Fall unter kontrollierten Bedingungen
Nach der ersten Einordnung führst du denselben Referenzfall erneut aus. Deaktiviere dabei nach Möglichkeit echte Schreibaktionen, damit die Analyse keine doppelten Tickets, E-Mails oder CRM-Einträge erzeugt. Für die Wiederholung sollten Eingabe, Promptversion, Modell und weitere Einstellungen unverändert bleiben.
Weicht das Ergebnis zwischen den Durchläufen ab, deutet das auf eine instabile oder mehrdeutige Entscheidung hin. Prüfe dann, ob die Regeln genügend trennscharf sind und ob die erwartete Antwort überhaupt eindeutig aus der Eingabe hervorgeht. Eine niedrigere Zufallsvariation kann Ausgaben gleichförmiger machen, ersetzt aber keine klare fachliche Definition.
Bleibt der falsche Wert bei jeder Wiederholung gleich, spricht das eher für einen systematischen Fehler in den Daten, Anweisungen oder Zuordnungen. Diese Unterscheidung ist keine endgültige Diagnose, grenzt die weitere Suche aber deutlich ein.
Ändere nur eine Ursache pro Test
Sobald du eine plausible Ursache gefunden hast, korrigiere zunächst nur diese Stelle. Ändere nicht gleichzeitig den Prompt, das Modell, die Datenaufbereitung und die Feldzuordnung. Andernfalls weißt du bei einem erfolgreichen Test nicht, welche Änderung erforderlich war. Bei einem weiterhin falschen Ergebnis weißt du noch weniger.
Führe anschließend den Referenzfall erneut aus und kontrolliere alle Prüfpunkte ab der geänderten Stelle. Eine lokale Korrektur kann schließlich neue Nebenwirkungen erzeugen. Eine großzügigere Textkürzung überträgt vielleicht den entscheidenden Absatz, überschreitet bei längeren Eingaben aber eine andere Grenze. Eine strengere Validierung verhindert einen falschen Datensatz, blockiert möglicherweise jedoch einen zulässigen Sonderfall.
Baue aus dem Fehler einen kleinen Regressionstest
Ein behobener Fall sollte nicht in einem Chatverlauf oder Supportticket verschwinden. Übernimm ihn anonymisiert in eine kleine Sammlung von Testfällen. Ein Regressionstest prüft, ob ein früherer Fehler nach späteren Änderungen erneut auftritt.
Zu jedem Testfall gehören:
- Eine repräsentative Eingabe
- Das erwartete strukturierte Ergebnis
- Die fachliche Begründung für diese Erwartung
- Die Merkmale, die auf keinen Fall entstehen dürfen
Ergänze zum fehlerhaften Ausgangsfall mindestens einen ähnlichen Fall mit bewusst anderem Ergebnis. Wenn der Exportfehler keine kritische Störung ist, brauchst du auch ein Beispiel für einen tatsächlichen Komplettausfall. Sonst optimierst du die Automation womöglich so stark gegen die erste Fehlentscheidung, dass sie künftig echte Notfälle herunterstuft.
Spiele diese Fälle nach Änderungen an Prompt, Aufbereitung, Modell oder Zuordnung erneut durch. Bei variierenden Modellausgaben solltest du nicht nur den Wortlaut vergleichen, sondern die fachlich relevanten Felder und zulässigen Grenzen.
Wann die Automation selbst neu begrenzt werden muss
Manche Fehler lassen sich nicht durch eine präzisere Anweisung zuverlässig ausschließen. Wenn die Eingaben regelmäßig unvollständig sind, die fachlichen Kategorien nicht trennscharf definiert werden können oder eine Fehlentscheidung hohe Schäden auslösen würde, braucht die Automation engere Befugnisse.
Die KI kann dann beispielsweise einen Vorschlag erzeugen, während eine feste Regel die erlaubten Folgeaktionen begrenzt. Ebenso kann sie unklare Vorgänge kennzeichnen, statt eigenständig einen endgültigen Status zu setzen. Für Entscheidungen, die vollständig durch eindeutige Regeln beschrieben werden können, ist ein deterministischer Programmablauf oft besser geeignet als eine Modellentscheidung.
Das Ergebnis der Fehleranalyse kann also lauten, dass der Prompt gar nicht repariert werden muss. Vielleicht benötigt der Ablauf eine vollständigere Datenquelle, eine korrigierte Zuordnung oder eine belastbare fachliche Grenze.
Fazit: Folge dem Fehler rückwärts bis zur ersten Abweichung
Bei falschen Ergebnissen einer KI-Automation solltest du nicht mit einer Promptüberarbeitung beginnen. Nimm einen konkreten Fehlfall, definiere das erwartete Ergebnis und verfolge Roheingabe, Aufbereitung, Modellanfrage, Antwort, Validierung und Zielaktion in ihrer tatsächlichen Reihenfolge.
Die erste Abweichung bestimmt die passende Korrektur. Dadurch behandelst du die Ursache statt des sichtbaren Symptoms. Aus dem behobenen Fall entsteht anschließend ein Regressionstest, der spätere Änderungen absichert. So wird die Automation nicht durch hektisches Nachjustieren zuverlässiger, sondern durch nachvollziehbare Fehlergrenzen.
Häufige Fragen
Kurz beantwortet, damit du schneller einschätzen kannst, was für dein Projekt wichtig ist.
Ist bei einer falschen KI-Entscheidung meistens der Prompt schuld?
Nicht zwingend. Die Ursache kann bereits in einer unvollständigen Eingabe, der Datenaufbereitung, einer falschen Feldzuordnung oder einer zu schwachen Validierung liegen. Prüfe zuerst den vollständigen Datenweg.
Wie teste ich eine KI-Automation, deren Ergebnisse variieren?
Wiederhole denselben Fall mit unveränderter Eingabe, Promptversion, Modellbezeichnung und denselben Einstellungen. Vergleiche die fachlich relevanten Felder statt nur den genauen Wortlaut der Antwort.
Welche Daten sollte ich für die Fehleranalyse protokollieren?
Hilfreich sind Roheingabe, aufbereitete Eingabe, tatsächlich gesendete Modellanfrage, rohe Antwort, verarbeitetes Ergebnis, Validierung und Zielaktion. Speichere nur erforderliche Daten und schütze sensible Inhalte.
Wann sollte eine KI-Automation keine direkte Aktion ausführen?
Wenn Eingaben häufig unvollständig sind, die Entscheidung nicht eindeutig definiert werden kann oder Fehler erhebliche Folgen hätten, sollte die KI nur einen Vorschlag liefern oder den Vorgang zur Prüfung weitergeben.
