Wenn die KI lügt: Halluzinationen in Geschäftsprozessen
Sprachmodelle erfinden manchmal Fakten — mit derselben Sicherheit wie bei der richtigen Antwort. Für Spielereien irrelevant, für Geschäftsprozesse ein reales Risiko. Wie man damit umgeht.
Wenn die KI lügt
Ein Kunde hatte einen Workflow gebaut, der eingehende Verträge automatisch zusammenfasste: Laufzeit, Kündigungsfristen, Vertragspartner. Das Sprachmodell lieferte täglich Dutzende saubere Zusammenfassungen. Niemand prüfte sie mehr.
Drei Monate später: Einer der Verträge hatte eine Kündigungsfrist von zwölf Wochen. Das Modell hatte vier Wochen ausgegeben, mit demselben sicheren Ton wie bei jeder anderen Zusammenfassung. Der Vertrag verlängerte sich automatisch um ein weiteres Jahr.
Das nennt man Halluzination. Und in Geschäftsprozessen ist das kein akademisches Problem.
Was das eigentlich bedeutet
Der Begriff ist irreführend. Das Modell lügt nicht. Es erzeugt statistische Vorhersagen, Token für Token, Wort für Wort. Wenn die relevante Information nicht eindeutig im Kontext vorliegt, füllt das Modell plausibel wirkende Details ein. Nicht aus Böswilligkeit, sondern weil es das tut, wofür es trainiert wurde: kohärente Sprache produzieren.
Das Problem: Kohärent klingt auch die falsche Antwort. Keine Warnung. Keine anderen Formulierungen. Dieselbe Sicherheit wie bei der richtigen.
Halluzinationen passieren besonders häufig bei spezifischen Zahlen, Daten und Namen, bei langen Dokumenten mit ähnlichem Inhalt an mehreren Stellen, und bei Fragen, auf die es mehrere plausible Antworten gibt. Die Fehlerrate ist oft gering genug, um im Alltag nicht aufzufallen. Bis ein Fehler Konsequenzen hat.
Drei Prozesse, bei denen es wirklich teuer wird
Vertragsanalyse ist einer davon. Kündigungsfristen, Haftungsklauseln, Zahlungsbedingungen. Wer Sprachmodelle für die Extraktion dieser Informationen nutzt, ohne einen Verifizierungsschritt einzubauen, spielt mit realem Risiko. Die Fehlerrate ist gering genug, um nicht sofort aufzufallen, aber hoch genug, um gelegentlich erhebliche Konsequenzen zu haben.
Finanzdaten sind ähnlich kritisch. Beträge, IBANs, Steuernummern. Selbst kleine Fehler führen zu falschen Buchungen, Rückbuchungen oder Compliance-Problemen. Ein falsch gelesener Betrag aus einer Rechnung kann eine Lieferantenbeziehung belasten, und die Nachforschungen kosten intern mehr als die ursprüngliche Transaktion.
Der dritte Bereich ist weniger offensichtlich: Wissensdatenbanken mit Faktenanspruch. Wenn Kunden- oder Mitarbeiter-KIs aus internen Dokumenten zitieren, entstehen implizite Faktenansprüche. "Laut unserem Handbuch gilt folgendes Vorgehen..." Wenn das falsch ist, trägt das Unternehmen die Verantwortung. Nicht das Modell.
Was dagegen hilft
Nicht jedes Ausgabefeld ist gleich riskant. Identifizieren Sie die 10%, bei denen ein Fehler wirklich Konsequenzen hat, und bauen Sie dafür eine Prüfschleife ein, manuell oder automatisiert gegen eine Referenzquelle. Für den Rest braucht es das nicht.
Prompts lassen sich so formulieren, dass das Modell bei Unsicherheit "Nicht eindeutig erkennbar" antwortet. Unsichere Fälle landen dann in einer manuellen Queue statt unbemerkt als Ergebnis durchzugehen.
Gegenchecks gegen strukturierte Quellen fangen die meisten Fehler ab: Lieferantenname aus der Rechnung gegen das CRM, Betrag gegen den Bestellrahmen, Bankverbindung gegen die Stammdaten. Abweichungen triggern eine Prüfung, bevor sie weiterverarbeitet werden.
Viele Halluzinationen sind formal erkennbar: eine IBAN mit falscher Prüfziffer, ein Datum, das es nicht gibt, eine Postleitzahl mit sechs Stellen. Einfache Validierungsregeln vor der Datenübergabe kosten wenig Aufwand.
Wann man kein LLM nehmen sollte
Für Prozesse mit vollständig strukturiertem, einheitlichem Input ist ein Sprachmodell oft das falsche Werkzeug, unabhängig von Halluzinationen.
OCR plus Regelwerk ist deterministisch, billiger und einfacher zu debuggen. Wenn der Input jedes Mal gleich aussieht und die Regeln klar definiert sind, gibt es keinen guten Grund, probabilistische Technologie einzusetzen.
Die Frage sollte nicht sein: "Wo können wir KI einsetzen?" Sondern: "Welches Werkzeug löst dieses Problem am zuverlässigsten?" Manchmal ist die Antwort ein Parser. Manchmal ein Regelwerk. Manchmal ein Sprachmodell mit Prüfschleife. Manchmal ein Mensch.
Was das für die Praxis bedeutet
Wer KI in Geschäftsprozesse einbaut, trägt die Verantwortung für die Ausgaben. "Das Modell hat das so ausgegeben" ist keine Entschuldigung, weder gegenüber Kunden noch gegenüber dem Regulierer.
Das bedeutet nicht, keine KI einzusetzen. Es bedeutet: Jeder Prozess, in dem eine falsche KI-Ausgabe Konsequenzen hat, braucht ein Design, das diesen Fall abfängt. Nicht weil KI unzuverlässig ist. Sondern weil jedes System, das Fehler machen kann, einen Mechanismus braucht, der diese Fehler erkennt.
Welche Ihrer KI-Anwendungen haben diesen Mechanismus schon eingebaut? Unser kostenloser Automations-Check hilft Ihnen, das in 30 Minuten herauszufinden.