Einheit 6 — Fehler einplanen
Was du nach dieser Einheit weißt: Du weißt welche typischen Fehler in Workflows auftreten, wie du von Anfang an damit umgehst und wie du verhinderst, dass ein Workflow stillschweigend falsche Ergebnisse produziert.
Das gefährlichste Ergebnis: kein Fehler
Ein Workflow der mit einer Fehlermeldung abbricht, ist unangenehm — aber du siehst es und kannst reagieren.
Ein Workflow der stillschweigend falsche Ergebnisse produziert, ist gefährlich. Er bucht den falschen Betrag im ERP, ordnet die Rechnung dem falschen Lieferanten zu oder legt das Dokument im falschen Ordner ab — und niemand merkt es, weil der Workflow „grün" ist.
Fehler einplanen bedeutet nicht: jeden Fehler verhindern. Es bedeutet: dafür sorgen, dass Fehler sichtbar werden statt stillschweigend durchzulaufen.
📹 Video: [Platzhalter — Screencast: Ein Workflow der „grün" durchläuft aber ein falsches Ergebnis produziert — und derselbe Workflow mit eingebauter Prüfung die den Fehler meldet]
Typische Fehlerquellen
1. Leere oder fehlende Daten
Die KI-Extraktion findet keine Rechnungsnummer im PDF. Das Feld rechnungsnummer ist leer — aber der Workflow macht weiter und versucht im ERP nach einer leeren Nummer zu suchen.
Lösung: Nach der Extraktion prüfen ob Pflichtfelder vorhanden sind. Wenn nicht → Workflow abbrechen oder an einen Menschen eskalieren.
📸 Screenshot: [Platzhalter — Switch Agent nach KI-Extraktion: Bedingung prüft ob rechnungsnummer leer ist — wenn ja, Eskalation per E-Mail]
2. Unerwartete API-Antworten
Du erwartest vom ERP eine JSON-Antwort mit einem Feld customer_id. Aber die API liefert einen HTTP-Fehler (500), oder sie liefert eine leere Liste (der Kunde existiert nicht), oder sie liefert mehrere Ergebnisse statt einem.
Lösung: Nach jedem API-Aufruf den Response-Code und die Antwortstruktur prüfen. Nicht davon ausgehen, dass die Antwort immer das erwartete Format hat.
// Erwartet:
{ "results": [{ "customer_id": 42, "name": "Müller GmbH" }] }
// Mögliche Realitäten:
{ "results": [] } // Kein Ergebnis
{ "error": "Internal Server Error" } // Serverfehler
{ "results": [{ ... }, { ... }] } // Mehrere Treffer
📸 Screenshot: [Platzhalter — Switch Agent nach Post Agent: Drei Pfade — „genau 1 Ergebnis" (Normalfall), „kein Ergebnis" (Eskalation), „Fehler/Mehrere" (Eskalation)]
3. KI-Halluzinationen
Ein Generative AI Agent „erfindet" Daten die nicht im Dokument stehen — z. B. eine plausibel aussehende Rechnungsnummer die es nicht gibt. Das ist besonders tückisch, weil das Ergebnis auf den ersten Blick korrekt aussieht.
Lösung: KI-Ergebnisse nicht blind vertrauen. Kritische Felder gegen eine Datenquelle validieren — z. B. die extrahierte Kreditor-Nummer im ERP nachschlagen. Wenn sie dort nicht existiert, ist sie wahrscheinlich falsch.
4. Timeouts und Netzwerkfehler
Eine API antwortet nicht, ein SMB-Share ist nicht erreichbar, eine E-Mail kann nicht gesendet werden. Netzwerkprobleme sind unvermeidbar — aber sie müssen nicht den gesamten Prozess blockieren.
Lösung: Überlege bei jedem externen Aufruf was passieren soll wenn er fehlschlägt. Manchmal ist die richtige Antwort „abbrechen und melden", manchmal „in eine Warteschlange legen und später wiederholen".
5. Datenformat-Abweichungen
Ein Datum kommt als 01.04.2026 statt 2026-04-01. Ein Betrag kommt als 1.234,56 statt 1234.56. Ein Name enthält Sonderzeichen die das Zielsystem nicht versteht.
Lösung: Daten nicht „wie sie kommen" weitergeben, sondern an den kritischen Übergabestellen normalisieren — in das Format bringen, das das Zielsystem erwartet.
Muster: Die Prüfschicht
Ein bewährtes Muster ist die Prüfschicht — ein Switch Agent (oder mehrere) nach einer Datenerhebung, der prüft ob die Daten vollständig und plausibel sind, bevor der Workflow weiterarbeitet.
Datenquelle → Prüfschicht → Weiterverarbeitung
↓
Eskalation (wenn Prüfung fehlschlägt)
📸 Screenshot: [Platzhalter — Workflow-Designer: Prüfschicht-Muster — nach KI-Extraktion ein Switch Agent der Pflichtfelder prüft, mit zwei Pfaden: „OK" und „Eskalation"]
Die Prüfschicht kann einfache Bedingungen prüfen:
- Ist das Feld leer?
- Ist der Betrag größer als 0?
- Hat die API einen 200er-Status zurückgegeben?
- Hat die Suche genau einen Treffer ergeben?
Eskalation: Was passiert wenn etwas schiefgeht?
Wenn ein Fehler erkannt wird, muss etwas passieren. Die häufigsten Eskalationswege:
| Eskalation | Wann sinnvoll |
|---|---|
| E-Mail an verantwortliche Person | Einzelfälle die menschliche Entscheidung brauchen |
| Eintrag in eine Fehlerliste (z. B. Internal Storage) | Wenn Fehler gesammelt und periodisch abgearbeitet werden |
| Workflow abbrechen | Wenn Weiterverarbeitung Schaden anrichten würde |
| In Warteschlange legen | Bei temporären Fehlern (Netzwerk, Timeout) |
📹 Video: [Platzhalter — Screencast: Eskalations-E-Mail einrichten — Switch Agent erkennt fehlende Rechnungsnummer, Mail Agent sendet Benachrichtigung mit den vorhandenen Daten]
Ein Workflow der einen Fehler erkennt und meldet ist besser als ein Workflow der keinen Fehler erkennt. Plane die Eskalation von Anfang an mit ein — nicht als Nachgedanken.
Zusammengefasst
| Fehlerquelle | Risiko | Gegenmaßnahme |
|---|---|---|
| Leere/fehlende Daten | Falsches Ergebnis | Pflichtfelder nach Extraktion prüfen |
| Unerwartete API-Antwort | Abbruch oder falsches Ergebnis | Response-Code und Struktur prüfen |
| KI-Halluzination | Plausibel-falsche Daten | Gegen Datenquelle validieren |
| Timeout/Netzwerkfehler | Abbruch | Fehlerbehandlung oder Warteschlange |
| Datenformat-Abweichung | Fehler im Zielsystem | Normalisierung vor Übergabe |
Weiter: Einheit 7 — LLM vs. Hard-Coded