Als ich anfing, mit Sprachmodellen zu arbeiten, haben sie ständig Dinge erfunden. Seitdem sind sie deutlich besser geworden, aber das Problem ist nicht verschwunden: Eine falsche Antwort sieht genauso aus wie eine richtige. Das Modell aufzurufen ist der einfache Teil, wenn man KI in einen Ablauf einbaut. Die eigentliche Arbeit liegt in der Frage, was passiert, wenn die Antwort plausibel und trotzdem falsch ist.

Nehmen Sie ein gemeinsames Postfach, in dem Rechnungen, Lieferavis und ganz normale Anfragen eingehen. Diese Nachrichten zu sortieren, kann Interpretation erfordern. Eine Rechnungsnummer mit bekannten Datensätzen abzugleichen oder nach einer Freigabe eine Benachrichtigung zu verschicken, erfordert keine. Solche Aufgaben lassen sich mit gewöhnlicher Software meist leichter testen und betreiben. Ein Modell kann trotzdem beim Einordnen oder beim Auslesen von Informationen helfen, aber sein Ergebnis bleibt unsicher.

Den genauen Schritt festlegen

Schreiben Sie den Schritt auf, den Sie automatisieren wollen, und was passiert, wenn er schiefgeht. „E-Mails mit KI bearbeiten“ ist zu weit gefasst, um es zu bewerten. „Eingehende Nachrichten lesen, Rechnungsanfragen erkennen und die relevanten an die Buchhaltung weiterleiten“ ist konkret genug, um es zu prüfen.

Fragen Sie dann, was der Schritt tatsächlich verlangt:

  • Daten von einem System in ein anderes kopieren
  • Eine feste Geschäftsregel anwenden
  • Einen Datensatz nachschlagen
  • Einen Wert berechnen
  • Text, Bilder oder Sprache interpretieren
  • Einer Person eine Handlung empfehlen

Für die ersten vier reichen meist normaler Anwendungscode, eine Datenbankabfrage oder eine Anbindung. Die letzten beiden können ein Modell rechtfertigen, aber nur, wenn der Ablauf mit einem unsicheren Ergebnis umgehen kann.

Oft reicht eine feste Regel

Für eine Bedingung, die sich direkt formulieren lässt, ist ein Modell ein schlechter Ersatz. Nutzen Sie gewöhnliche Automatisierung, wenn die Aufgabe darin besteht:

  • Eine Kundennummer aus einem freigegebenen Feld zu übernehmen
  • Einen Import abzulehnen, wenn ein Pflichtwert fehlt
  • Eine Bestellung nach Land oder Bestellart weiterzuleiten
  • Eine Summe aus festgelegten Werten zu berechnen
  • Ein Dokument aus einer festen Vorlage zu erzeugen

Regeln haben hier eine nützliche Eigenschaft: Dieselbe Eingabe führt zum selben Ergebnis, und eine nicht erfüllte Bedingung kann erklären, warum der Ablauf angehalten hat. Die Umsetzung braucht trotzdem Fehlerbehandlung, Berechtigungen und Protokollierung, aber die Entscheidung selbst lässt sich nachvollziehen.

Ein Modell in einem deterministischen Schritt bringt eine weitere Abhängigkeit mit, ohne die zugrunde liegende Regel zu ersetzen. Außerdem kann es einen einfachen Fehler schwerer auffindbar machen.

Wenn die Eingabe unordentlich ist

KI kann passen, wenn sich die Eingabe mit einer kurzen Liste von Regeln schwer verarbeiten lässt. Beispiele sind eine E-Mail ohne festes Format, die eingeordnet werden muss, Informationen aus Dokumenten verschiedener Absender oder eine erste Zusammenfassung, die eine Person anschließend prüft.

Vertrauenswürdig ist das Ergebnis dadurch noch nicht. Das Modell kann eine Formulierung missverstehen, ein Detail auslassen oder einen plausiblen Wert liefern, der in der Quelle nie stand. Der Ablauf drumherum muss solche Fälle sichtbar machen.

Eine sinnvolle Grenze sieht so aus:

  1. Die ursprüngliche Eingabe aufbewahren.
  2. Vom Modell eine eng begrenzte Ausgabe verlangen.
  3. Die Ausgabe im Anwendungscode validieren.
  4. Unsichere oder ungültige Ergebnisse an eine Person geben.
  5. Festhalten, was passiert ist, damit es sich später prüfen lässt.

Das Modell kann bei der Interpretation helfen. Es sollte das führende System nicht unbemerkt verändern.

Eine Grenze um das Ergebnis ziehen

Bevor Sie ein Modell an einen laufenden Prozess anschließen, beschreiben Sie seine Ausgabe als Vertrag. Legen Sie erlaubte Kategorien, Felder, Formate und Werte fest. Lehnen Sie jede Ausgabe ab, die diesen Vertrag nicht erfüllt.

Beim Auslesen von Rechnungen könnte der Vertrag Lieferantenname, Rechnungsnummer, Datum, Währung und Gesamtbetrag verlangen. Die Anwendung kann prüfen, ob das Datum ein gültiges Format hat, ob die Währung unterstützt wird und ob sich der Gesamtbetrag als Zahl lesen lässt. Sie kann auch den ausgelesenen Lieferanten mit bekannten Datensätzen vergleichen.

Diese Prüfungen beweisen nicht, dass das Modell das Dokument richtig gelesen hat. Sie verhindern aber, dass fehlerhaft aufgebaute Ausgaben weiter in den Ablauf gelangen.

Nehmen Sie eine Rechnung mit „Rechnungsnummer 2026-0412“, bei der das Modell 2026-0421 zurückgibt. Das Format stimmt, das Datum lässt sich lesen, der Betrag ist eine Zahl und den Lieferanten gibt es. Jede der genannten Prüfungen besteht also. Die vertauschten Ziffern fallen nur bei einem Abgleich mit etwas auf, das nicht vom Modell stammt: den offenen Bestellungen, den früheren Rechnungsnummern des Lieferanten oder einer Person, die Quelle und Ergebnis nebeneinander sieht. Wo es einen solchen Abgleich gibt, nutzen Sie ihn. Wo nicht, muss dieses Feld geprüft werden.

Bei Konfidenzwerten ist dieselbe Vorsicht angebracht. Ein Modell kann für eine falsche Antwort 95 % Sicherheit angeben. Nutzen Sie den Wert als ein Signal neben Validierungsregeln, dem Abgleich mit bekannten Datensätzen und einer Schwelle für die Prüfung. Legen Sie diese Schwelle anhand beobachteter Ergebnisse fest und nicht, weil eine Zahl beruhigend klingt.

Belege vor dem Livegang

Ein Prompt, der in einer Demo funktioniert, sagt wenig über den Betrieb aus. Sammeln Sie vor dem Livegang repräsentative Beispiele: normale Fälle, unvollständige Eingaben, ungewöhnliche Formate und Fälle, in denen die richtige Antwort „Das kann ich nicht entscheiden“ lautet. Entfernen oder schützen Sie personenbezogene Daten wie vorgeschrieben und halten Sie die Annahmen hinter dem Testdatensatz fest.

Notieren Sie für jedes Beispiel:

  • Die erwartete Kategorie oder die erwarteten Felder
  • Die Ausgabe des Modells
  • Ob die Ausgabe die Validierung bestanden hat
  • Ob eine prüfende Person sie übernommen oder korrigiert hat
  • Was bei einer mehrdeutigen Eingabe passiert ist

Betrachten Sie falsch positive und falsch negative Ergebnisse getrennt. Eine normale Anfrage, die in der Rechnungsablage landet, ist lästig. Ein übersehenes Dokument, das dringend bearbeitet werden muss, kann ganz andere Folgen haben. Welches Fehlermuster akzeptabel ist, hängt vom Ablauf ab. Eine einzelne Trefferquote reicht deshalb selten.

Wiederholen Sie den Test, wenn sich Prompt, Modell, Anbieter, Dokumentformat oder Geschäftsregel ändern. Ein Ablauf, der mit den Beispielen vom letzten Monat funktioniert, kann sich anders verhalten, sobald sich die Eingaben ändern.

Eine Prüfwarteschlange braucht eine zuständige Person

„Das kann ja jemand prüfen“ ist noch kein Prüfkonzept. Wer prüft, braucht eine Warteschlange, die ursprüngliche Quelle, das ausgelesene oder eingeordnete Ergebnis, den Grund für die Weiterleitung und eine klare Möglichkeit, das Ergebnis zu übernehmen oder zu korrigieren.

Die Korrektur sollte etwas nützen. Wenn jemand einen Lieferantennamen ändert oder eine Einordnung verwirft, speichern Sie diese Entscheidung dort, wo sie bei der Fehlersuche und späteren Auswertungen hilft. Zwingen Sie niemanden, eine Ausgabe freizugeben, die er nicht nachprüfen kann.

Die Prüfung braucht außerdem eine zuständige Person und eine Reaktionszeit, die zum Prozess passt. Wenn sich niemand um die Warteschlange kümmert, hat das Modell die Handarbeit nur an eine weniger sichtbare Stelle verschoben.

Festlegen, was bei einem Fehler passiert

Ein Anbieter kann ausfallen, ein Dokument kann die Eingabegrenzen überschreiten, die Ausgabe kann an der Validierung scheitern oder das Modell liefert eine Antwort ohne verwertbaren Beleg. Für jeden dieser Fälle braucht es ein festgelegtes Ergebnis.

Je nach Ablauf kann die sichere Reaktion sein:

  • Den Vorgang in einem Zustand lassen, aus dem er wiederholt werden kann
  • Ihn an die manuelle Bearbeitung geben
  • Eine korrigierte Eingabe anfordern
  • Den Fehler festhalten und die zuständige Person benachrichtigen
  • Mit einer eingeschränkten Aktion weitermachen, die keine wichtigen Daten ändert

„Einfach weitermachen, als hätte das Modell recht“ ist keine Rückfallebene. Bewahren Sie den Vorgang und seinen Status auf, damit im Betrieb sichtbar ist, was noch offen ist.

Wartung und Prüfung einrechnen

Vergleichen Sie die KI-Variante mit einer Regel, einer Funktion eines Standardprodukts, einer API-Anbindung oder einem kleinen internen Tool. Rechnen Sie die Arbeit rund um das Modell mit ein, nicht nur den Aufruf selbst:

  • Eingaben vorbereiten und schützen
  • Ausgaben validieren und speichern
  • Unsichere Fälle prüfen
  • Fehler und Änderungen beim Anbieter überwachen
  • Ergebnisse kontrollieren, wenn sich die Eingaben ändern
  • Eine Rückfallebene pflegen

Dokumentieren Sie diese Entscheidung, einschließlich der Frage, wer sich um Ausnahmen kümmert, bevor der Ablauf zum ersten Mal live läuft.