KI-Halluzinationen abfangen: 3 Schutzschichten für B2B-Teams

Wie KI-Halluzinationen in B2B-Workflows aussehen

Eine Halluzination liegt vor, wenn das Modell eine selbstbewusst klingende, aber falsche Antwort liefert. Im B2B zeigt sich das in drei Mustern: (1) eine nicht existierende Bestellnummer für eine Support-Anfrage erfinden, (2) beim Zusammenfassen ein Datum "zitieren", das gar nicht im Vertrag steht, (3) beim Klassifizieren von Rechnungen eine Kategorie erfinden, die nicht zum festgelegten Kategoriensatz gehört.

Alle drei teilen sich dasselbe Muster: Findet das Modell keinen echten Anker, füllt es die Lücke. Das Problem: Die Ausgabe wirkt überzeugend — auch wenn sie falsch ist. "KI irrt" ist keine Maßnahme; man muss wissen, wo und warum. Die drei Schutzschichten unten leisten das.

Drei Schutzschichten: Quelle, Regel, Mensch

Quellenprüfung: Dokument und Belegstelle zur Antwort anzeigen; prüfen, ob die Stelle die Aussage tatsächlich stützt. Eine vorhandene Quellenangabe allein reicht nicht. Fehlende oder widersprüchliche Belege gehen in die Prüfung.

Regelprüfung: Existenz des Auftrags, Berechtigung, Betrag und zulässige Kategorie im Anwendungscode kontrollieren. Ein korrektes Format beweist keine sachliche Richtigkeit.

Menschliche Freigabe: Vor Zahlung, Erstattung oder verbindlicher Nachricht prüft eine befugte Person die genaue Ausgabe. Änderungen erfordern eine neue Freigabe. Eine allgemeingültige Erfolgsquote gibt es nicht. Mit richtigen, falschen und unbelegten Beispielen testen, ob ungültige Ausgaben stoppen und die Prüffälle die zuständige Person erreichen.

Einen Evaluierungsprozess vor dem Launch aufbauen

Sie können eine Halluzinationsrate nicht erfassen, indem Sie sich Ergebnisse einfach ansehen; Sie brauchen ein Testset. Erstellen Sie ein Golden Set aus 50 bis 200 realen Beispielen mit bekannten korrekten Antworten und stellen Sie sicher, dass es Randfälle abdeckt – fehlende Daten, mehrdeutige Anfragen, Anfragen außerhalb des Umfangs. Lassen Sie das Modell vor jeder Prompt- oder Modelländerung dagegen laufen, nicht nur beim Launch.

Erfassen Sie getrennt, wie oft das Modell richtig antwortet und wie oft es auf eine Antwort verzichtet. Die Enthaltungsrate zeigt nur die Häufigkeit dieses Verzichts. Prüfen Sie mit entsprechend gekennzeichneten Testfällen zusätzlich, ob der Verzicht berechtigt war, und dokumentieren Sie die Berechnungsgrundlage jeder Kennzahl. Weder seltenes noch häufiges Enthalten beweist für sich genommen Sicherheit. Legen Sie Schwellen anhand der Folgen falscher Antworten, unnötiger Enthaltungen und notwendiger menschlicher Prüfung fest.

Adversariales Testen ist genauso wichtig wie das Testen normaler Fälle – füttern Sie das Modell absichtlich mit Anfragen, die darauf ausgelegt sind, Halluzinationen hervorzurufen: Fragen zu nicht existierenden Entitäten, Anfragen, die zwei Datensätze vermischen, Prompts, die es bitten, über das Ausgangsdokument hinaus zu extrapolieren. Wenn es in einem kontrollierten Test nicht kontrolliert mit Fehlern umgehen kann, wird es das auch im Produktivbetrieb nicht können.

Behandeln Sie dies als lebendige Pipeline, nicht als einmaliges Nadelöhr. Jedes Mal, wenn Sie den Prompt ändern, das Modell wechseln oder eine neue Dokumentenquelle hinzufügen, führen Sie das Evaluierungsset erneut aus und vergleichen die neuen Genauigkeits- und Enthaltungszahlen vor dem Deployment mit Ihrer Baseline. Es ist dieselbe Disziplin wie Regressionstests in traditioneller Software – nur dass hier Urteilsvermögen statt Logik getestet wird.

Welche Aufgaben das höchste Halluzinationsrisiko tragen

Risiko hängt nicht nur von freiem oder strukturiertem Text ab. Auch eine falsche Buchung in einer gültigen Kategorie kann schaden. Auswirkungen, Umkehrbarkeit, sensible Daten und Empfänger bewerten. Ein Entwurfsprozess braucht andere Berechtigungen als ein Prozess, der Kunden kontaktiert oder Geld bewegt.