Von einer Halluzination spricht man, wenn ein KI-Modell, typischerweise ein Large Language Model, Ausgaben erzeugt, die flüssig und selbstsicher klingen, faktisch aber falsch, erfunden oder nicht nachprüfbar sind. In Finanzteams kann eine halluzinierte Rechnungsnummer, ein halluzinierter Kundenname oder ein falscher Eurobetrag dazu führen, dass Zahlungen auf das falsche Konto gebucht werden, Kredite an die falsche Partei vergeben werden oder der Prüfpfad verfälscht wird.
Von Halluzination spricht man, wenn ein Sprachmodell eine Ausgabe erzeugt, die sprachlich souverän und mit großer Überzeugung daherkommt, faktisch aber falsch ist, frei erfunden oder anhand keiner realen Quelle überprüfbar. Das Modell lügt nicht im eigentlichen Sinne. Es wählt lediglich das wahrscheinlichste nächste Token auf Basis seines Trainings, und Wahrscheinlichkeit bedeutet nun einmal nicht Wahrheit.
Für einen Marketing-Assistenten ist eine Halluzination unangenehm. Für einen Debitoren- oder Order-to-Cash-Prozess ist sie ein Kontrollversagen. Cash Application (automatischer Zahlungsabgleich), Bonitätsbewertung, Abzugscodierung und Mahnansprache laufen allesamt über Identifikatoren: Kundennummern, Rechnungsreferenzen, Vertragskonditionen, Eurobeträge, Fälligkeitstermine. Ein Modell, das auch nur gelegentlich einen dieser Werte erfindet, ordnet einen Zahlungseingang von 45.000 Euro dem falschen Kunden zu, räumt einer verwechselbaren Firma Kredit ein oder verschickt eine Mahn-E-Mail, die sich auf eine gar nicht existierende Rechnung bezieht. Deshalb steht Halluzination ganz oben im Risikoregister jeder Finanzverantwortlichen, die eine KI-native oder agentische Debitoren-Plattform bewertet.
Nicht jede Halluzination sieht gleich aus, und die Gegenmaßnahmen unterscheiden sich je nach Typ.
Halluzinationen sind kein Fehler, den man einfach ausbessern kann. Sie gehören strukturell zur Funktionsweise heutiger LLMs, und dafür gibt es vier wesentliche Ursachen.
Erstens schwankt die Qualität der Trainingsdaten. Die Modelle lernen aus Texten in Internet-Größenordnung, die zutreffende wie auch falsche Aussagen enthalten, und sie können beides von Natur aus nicht gegeneinander gewichten. Zweitens: Ohne Retrieval-Augmented Generation zieht das Modell Informationen aus komprimierten Parametern, statt ein Quelldokument zu lesen. Dieser Abruf aus komprimierten Daten geht mit Verlusten einher. Drittens sind die Modelle darauf trainiert, eine Antwort zu liefern. Ein Ich weiß es nicht belohnt das Training nur selten. Deshalb neigt das Modell selbst dann zu einer selbstbewussten Antwort, wenn seine interne Wahrscheinlichkeit gering ist. Viertens kalibriert das Modell sein Selbstvertrauen schlecht. Spitzenmodelle klingen bei falschen Antworten ungefähr so überzeugt wie bei richtigen. Damit fällt das natürliche menschliche Signal weg, das sonst zu einer Überprüfung veranlassen würde.
Öffentliche Benchmarks und die von den Anbietern veröffentlichten Evaluierungen liefern grobe Anhaltswerte. Doch die Zahlen verschieben sich mit jeder neuen Modellversion und variieren je nach Aufgabe.
Für Finanzentscheider lautet die ehrliche Einschätzung: Selbst die besten Modelle halluzinieren so häufig, dass sich kein produktiver Debitorenprozess auf die rohe Modellausgabe verlassen kann, wenn eine Entscheidung Geld bewegt.
Risiken senken Sie nicht per Knopfdruck, sondern nur, wenn mehrere Maßnahmen zusammenspielen.
Retrieval-Augmented Generation. Verankern Sie das Modell in Dokumenten aus Ihrer Debitorenbuchhaltung, Ihrem ERP-System und Ihrem Vertragsarchiv. So fasst das Modell zusammen, was es tatsächlich liest, statt Inhalte aus seinen Parametern zu ziehen. RAG senkt die Halluzinationsrate deutlich, beseitigt sie aber nicht vollständig.
Verpflichtende Quellenangaben. Verlangen Sie, dass jede Tatsachenbehauptung und jeder Zahlenwert mit dem Quelldokument verknüpft wird, aus dem er stammt. Prüfen Sie anschließend programmatisch, ob das zitierte Dokument existiert und den genannten Wert auch enthält.
Deterministische Validierung. Jede Rechnungsnummer, jede Kundennummer und jeden Euro-Betrag, den das Modell ausgibt, müssen Sie gegen das offene Debitorenkonto, den Kundenstamm oder die Avisdatei validieren. Passt ein Wert zu keinem realen Datensatz, verwerfen Sie ihn, bevor er irgendeine nachgelagerte Aktion auslöst.
Konfidenzschwellen. Nutzen Sie die modelleigenen Log-Wahrscheinlichkeiten oder einen kalibrierten Klassifikator. So leiten Sie Ausgaben mit geringer Konfidenz an einen menschlichen Prüfer weiter, statt sie automatisch auszuführen.
Tool-Nutzung statt Gedächtnis. Weisen Sie das Modell nach Möglichkeit an, eine Datenbankabfrage aufzurufen, statt einen Fakt aus dem Gedächtnis zu ziehen. Ein SQL-Ergebnis lässt sich überprüfen, eine erinnerte Zahl nicht.
Chain-of-Thought-Reasoning. Bitten Sie das Modell, seinen Lösungsweg offenzulegen. Nachvollziehbare Denkschritte machen es einem Prüfer deutlich leichter zu erkennen, an welcher Stelle ein Schritt fehlgelaufen ist.
Feste Leitplanken senken nicht nur das Risiko. Überall dort, wo Geld oder verbindliche Zusagen im Spiel sind, brauchen Debitorensysteme sie zwingend.
Für einen CFO ist die ehrliche Haltung ganz einfach. Behandeln Sie das LLM wie einen selbstbewussten Nachwuchsanalysten: nützlich, schnell, oft richtig, aber niemals die letzte Unterschrift unter etwas, das Geld bewegt oder Kredit zusagt.
Nein. Spitzenmodelle senken die Halluzinationsrate gegenüber älteren oder kleineren Modellen, doch veröffentlichte Benchmarks zeigen je nach Aufgabe noch immer Fehlerquoten von rund 3 bis 15 Prozent. Bei finanzspezifischen Aufgaben fallen die Werte tendenziell sogar schlechter aus. Bei jedem Prozess in der Debitorenbuchhaltung, bei dem Geld fließt, müssen Sie die Modellausgabe weiterhin gegen die tatsächlichen Daten prüfen, bevor sie greift.
Nein. Retrieval-Augmented Generation reduziert Halluzinationen deutlich, weil das Modell abgerufene Dokumente zusammenfasst, statt aus dem Gedächtnis zu reproduzieren. Beseitigen kann es sie aber nicht. Das Modell kann ein abgerufenes Dokument dennoch falsch deuten, zwei Quellen vermischen oder ein Detail erfinden, das im Abruf gar nicht vorkam. Deshalb müssen Sie RAG mit einer Prüfung der Quellenangaben und einer deterministischen Validierung verbinden.
Ein normaler Fehler ist meist eine falsche Einordnung oder eine falsche Priorisierung, die das Modell selbst als unsicher kennzeichnet. Eine Halluzination dagegen klingt flüssig und selbstbewusst und lässt sich im Ton nicht von einer korrekten Antwort unterscheiden, ist dabei aber faktisch falsch oder frei erfunden. Die Gefahr liegt nicht allein in der Fehlerquote, sondern darin, dass jedes Signal fehlt, dass etwas nicht stimmt.
Subtile Zahlenhalluzinationen erkennen Sie beim Lesen am schwersten. Verlässlich ist nur ein Ansatz: Akzeptieren Sie niemals eine Zahl des Modells als verbindlich. Gleichen Sie jeden Euro-Betrag, jede Rechnungsnummer und jede Kundenkennung mit dem Quellsystem ab, und verwerfen oder markieren Sie jede Zahl, die nicht exakt mit einem realen Datensatz übereinstimmt.
Nein, sofern das System richtig aufgebaut ist. Das LLM sollte Zuordnungen, Kontierungen oder Empfehlungen vorschlagen, während eine deterministische Regel-Engine die verbindliche Entscheidung trifft. In Kombination mit RAG, der Validierung gegen die offenen Posten und einem menschlichen Kontrollpunkt bei Fällen mit geringer Konfidenz wird die Halluzination zu einem beherrschbaren Risiko statt zu einem Hindernis.
Stellen Sie es in drei Ebenen dar. Erstens: Räumen Sie ein, dass LLMs selbstbewusste, aber falsche Ausgaben erzeugen können, und beziffern Sie die Restfehlerquote aus den Evaluierungen der Anbieter. Zweitens: Beschreiben Sie die Kontrollstruktur, also die Verankerung durch Retrieval, die verpflichtende Angabe von Quellen, die deterministische Validierung gegen das Hauptbuch und die Konfidenzschwellen. Drittens: Zeigen Sie den Prüfpfad, denn Sie protokollieren jede Modellausgabe, jedes Validierungsergebnis und jede menschliche Freigabe, und alles bleibt nachvollziehbar.
