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) ein Datum "zitieren", das gar nicht im Vertrag steht, beim Zusammenfassen, (3) eine neue Kategorie erfinden beim Klassifizieren von Rechnungen außerhalb des definierten Sets.

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 falsch. "KI irrt" ist keine Maßnahme; man muss wissen wo und warum. Die drei Guardrails unten leisten das.

Drei Guardrails: Quelle, Regel, Mensch

1) Quellenzitat: Das Modell gibt jede Antwort mit der ID oder Zeilennummer der Quelle zurück. Gibt es keine Quelle, antwortet es "Ich weiß es nicht." Halluzinationen sinken um ~80%.

2) Regel-Vorprüfung: Den Output vor der Übergabe gegen Domain-Regeln validieren — hat die Bestellnummer 8 Stellen? Steht die Rechnungskategorie auf der Liste? Ist das Datumsformat gültig? Diese günstigen Python-Checks fangen die meisten Halluzinationen.

3) Menschliche Freigabe: Risikoreiche Aktionen (Erstattungen, Vertragsunterschriften) schlägt die KI vor, ein Mensch genehmigt. Die KI erledigt ~95% allein; die 5% Ausnahmen kommen zur Prüfung zu Ihnen.

Zusammen: In unabhängigen Drittaudits fällt die Halluzinationsrate unter 2%.

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.

Verfolgen Sie zwei getrennte Kennzahlen: Genauigkeit (hat es die richtige Antwort gegeben) und Enthaltungsrate (hat es korrekt „ich weiß es nicht“ gesagt, wenn es das sollte). Ein Modell, das sich nie enthält, wirkt selbstbewusst, ist aber riskanter; ein Modell, das sich zu oft enthält, ist lästig, aber sicherer. Die richtige Schwelle hängt davon ab, wie teuer eine falsche Antwort im Vergleich zu einer vermiedenen Antwort ist.

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 elegant scheitern 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

Nicht jede KI-Aufgabe trägt das gleiche Risiko, daher sollte auch Ihr Budget für Schutzmechanismen nicht gleichmäßig verteilt werden. Offene Generierung – eine Kunden-E-Mail entwerfen, ein Meeting zusammenfassen, Marketingtexte schreiben – lässt Raum für Kreativität, aber genau in diesem Raum versteckt sich die Halluzination: erfundene Statistiken, fabrizierte Zitate, Versprechen, die das Unternehmen nie gemacht hat. Das ist die Kategorie mit dem höchsten Risiko, weil es kein festes „richtiges“ Ergebnis gibt, gegen das man abgleichen kann, sondern nur eine Bandbreite akzeptabler Ergebnisse.

Dicht dahinter folgt die numerische und finanzielle Datenextraktion. Eine Summe aus einer Rechnung ziehen, einen Rabatt berechnen, eine Steuernummer extrahieren – Fehler hier sind still (die Zahl wirkt plausibel) und teuer (sie fließen direkt in Geldbewegungen ein). Rechtliche und medizinnahe Behauptungen – Vertragspflichten, Compliance-Aussagen, Dosierungs- oder Sicherheitshinweise – gehören zur selben Hochrisikoebene: Ein einziger Fehler, und der entstehende Schaden ist keine Peinlichkeit, sondern Haftung.

Am anderen Ende steht strukturierte Extraktion nach festem Schema – diesen Lebenslauf in Name/E-Mail/Fähigkeiten aufteilen, dieses Ticket in eine von 12 Kategorien einordnen, diese Transaktion mit einem Händlercode versehen – vergleichsweise risikoarm. Das Modell hat weniger Spielraum zum Erfinden, weil der Ergebnisraum begrenzt und mechanisch leicht überprüfbar ist: Sie können prüfen, ob die Kategorie existiert, ob die E-Mail ein @-Zeichen enthält, ob der Wert eine der 12 Optionen ist. Klassifizierung in eine kleine geschlossene Menge verhält sich ähnlich – selbst wenn das Modell falsch liegt, versagt es innerhalb der von Ihnen definierten Grenzen, was ein grundsätzlich günstigerer Fehlermodus ist.

Nutzen Sie dieses Gefälle, um zu entscheiden, wo Sie Ihren Aufwand für Schutzmechanismen investieren. Risikoarme Aufgaben mit geschlossenem Schema können oft mit leichter Validierung und Stichprobenprüfungen laufen. Hochriskante, offene oder numerisch-rechtliche Aufgaben verdienen das volle Paket aus dem vorherigen Abschnitt – Quellenzitate, Regelprüfungen und einen Menschen im Loop –, bevor Sie die Automatisierung an einen Kunden oder ein Kontobuch lassen.