Warum eine halluzinierte Fundstelle eine Tretmine ist

Fragen Sie einen gewöhnlichen Chatbot, ob ein KI-System dem EU AI Act entspricht, bekommen Sie eine flüssige, selbstbewusste, gut gegliederte Antwort — und irgendwo darin steht ein Verweis wie „nach Artikel 14 Absatz 4 muss der Anbieter …“, wobei der Absatz entweder etwas anderes sagt oder schlicht nicht existiert. Der Text liest sich exakt gleich überzeugend, ob die Fundstelle echt oder erfunden ist. Genau darin liegt die Gefahr: Ein Sprachmodell halluziniert am gefährlichsten nicht dann, wenn es offensichtlich falsch liegt, sondern wenn es im Tonfall eines Experten falsch liegt.

In den meisten Anwendungen ist ein falscher Verweis ein Ärgernis. In einem Compliance-Bericht ist er eine Haftung, die Sie unterschreiben. Jemand handelt auf Basis dieses Berichts — ein Datenschutzbeauftragter, ein Auditor, ein Vorstand, der entscheidet, ob ein System live gehen darf. Eine Fundstelle, die sich nicht auflösen lässt oder auf einen Text verweist, der das Gegenteil sagt, ist kein kleines Qualitätsthema; sie ist der Fehler, der jeden korrekten Befund ringsum entwertet. Als wir also KomplAI bauten — Tippels laufenden Prüfer für EU AI Act, DORA und DSGVO —, begannen wir bei dem Ergebnis, das wir uns nicht leisten konnten, und arbeiteten rückwärts. Alles Weitere folgt aus einer Regel: Keine Rechtsfundstelle erreicht den Bericht auf das Wort des Modells hin.

Der eine Gedanke, schlicht gesagt. Das LLM schlägt vor; ein deterministischer Prüfer entscheidet. Das Modell darf Befunde entwerfen und vorschlagen, auf welcher Norm sie beruhen. Es darf nicht die Instanz sein, die entscheidet, ob diese Norm existiert oder das aussagt, was der Befund behauptet. Diese Instanz steckt im Code und prüft gegen die Quelle.

Warum RAG allein die Lücke nicht schließt

Die naheliegende erste Antwort ist Retrieval-augmented Generation: die Gesetzestexte in einen Vektorspeicher legen, die relevanten Passagen abrufen und das Modell daraus antworten lassen. Wir setzen Retrieval ein, und Sie sollten das auch — eine RAG-Pipeline auf EUR-Lex ist weit besser als ein Modell, das aus dem Gedächtnis seiner Trainingsdaten antwortet. Aber Retrieval verkleinert das Problem; es beseitigt es nicht, und die verbleibende Lücke ist genau der Ort, an dem Compliance-Arbeit stattfindet.

Zwei Fehlerarten überleben das Retrieval. Erstens die Fehlzitierung: Das Modell ruft die richtige Passage ab, denkt korrekt darüber nach und schreibt dann die falsche Artikelnummer daneben — ein Übertragungsfehler, den keine noch so gute Retrieval-Qualität verhindert, weil er nach dem Retrieval passiert. Zweitens das Fehllesen: Das Modell ruft eine Passage ab und überdehnt sie, behandelt einen Erwägungsgrund (also Auslegungskontext) wie eine operative Pflicht oder liest eine bedingte Pflicht als absolute. Das Retrieval hat den richtigen Text vor das Modell gelegt. Es hat nichts dafür getan, dass der Satz, den das Modell dann schreibt, diesem Text treu ist. Warum Grounding hilft, aber keine Garantie ist, lohnt sich in voller Länge unter wie RAG wirklich funktioniert.

Die Lehre reicht über Compliance hinaus. Retrieval steuert, was das Modell sieht; es steuert nicht, was das Modell behauptet. Überall dort, wo die Behauptung Folgen hat, brauchen Sie einen Schritt, der die Behauptung selbst prüft — nicht den Kontext, aus dem sie stammt.

Zur Generierungszeit verifizieren

Der Schritt, den wir eingezogen haben, ist bewusst unspektakulär: Nachdem das Modell einen Befund samt Fundstelle entworfen hat und bevor dieser Befund irgendwo in die Nähe des Berichts gelangt, wird die Fundstelle programmatisch aufgelöst und nachgeprüft. Genau diesen Teil überspringen die meisten Demos, weil er Arbeit macht und bremst. Es ist auch der Teil, der aus einem plausibel klingenden Werkzeug eines macht, dessen Ausgabe Sie verteidigen können.

Modell entwirft Befund + Fundstelle Fundstelle gegen EUR-Lex auflösen Adversariale Prüfung gegen Quelltext & Gesetz Geprüfter Bericht Word / Excel Löst nicht auf → markiert für den Menschen, nie gedruckt
Das Modell schlägt nur vor. Eine Fundstelle, die sich gegen EUR-Lex auflöst, geht in eine adversariale Prüfung gegen den tatsächlichen Artikeltext; eine, die sich nicht auflöst, wird für einen Menschen markiert und nie als Tatsache gedruckt. Der Bericht ist der Rest dessen, was beide Tore überstanden hat.

Jede Fundstelle gegen EUR-Lex auflösen

Das erste Tor ist deterministisch und langweilig — und genau das ist der Punkt. Die Ausgabe des Modells wird auf jeden Rechtsverweis geparst — „Art. 9 Abs. 2 lit. a AI Act“, „Erwägungsgrund 60“, ein DORA-Artikel, ein DSGVO-Absatz — und jeder wird in eine kanonische Kennung normalisiert und im maßgeblichen EUR-Lex-Text nachgeschlagen. Löst sich der Verweis auf, haben wir die tatsächliche Vorschrift für den nächsten Schritt in der Hand. Löst er sich nicht auf — die Artikelnummer existiert nicht, der Absatz liegt außerhalb des Bereichs, das Instrument ist falsch —, wird der Befund nicht mit einer erfundenen Fundstelle gedruckt. Er wird markiert. Eine Lücke, die der Nutzer sieht, schlägt eine Erfindung, die er nicht sieht.

Der wirklich schwierige Teil ist hier nicht das Nachschlagen; es sind das Parsen und die Versionierung. Rechtsverweise kommen in losen, mehrsprachigen, abgekürzten Formen, und Sie müssen jede Variante auf dasselbe kanonische Ziel abbilden. Und EUR-Lex führt konsolidierte Fassungen neben dem ursprünglichen Amtsblatt-Text, mit einer Artikelnummerierung, die sich bei Änderungen verschieben kann — „auflösen“ bedeutet also erst etwas, wenn Sie festgelegt haben, gegen welche Fassung Sie auflösen. Diese Klempnerarbeit ist unspektakulär, und sie ist der größte Teil der Arbeit.

Die adversariale Nachprüfung

Eine Fundstelle aufzulösen beweist, dass der Artikel existiert. Es beweist nicht, dass der Befund stimmt. Dass Artikel 11 eine echte Vorschrift ist, sagt nichts darüber, ob das geprüfte System ihn tatsächlich verletzt. Das zweite Tor ist deshalb ein adversarialer Durchgang: Für jeden Befund wird ein eigener Schritt auf den aufgelösten Quelltext und das Gesetz gerichtet und im Kern aufgefordert, den Befund zu widerlegen — trägt die zitierte Vorschrift diese Schlussfolgerung wirklich, oder ist die Behauptung eine Überdehnung, ein fehlgelesener Erwägungsgrund, eine bedingte Pflicht, die als absolute dargestellt wird? Ein Befund, der es übersteht, gegen ihn zu argumentieren, ist weit mehr wert als einer, dem ein gefälliges Modell gern zustimmte. Es ist der Unterschied zwischen „das Modell hat es gesagt“ und „die Behauptung wurde am Text geprüft und hielt stand“.

Was wir nicht tun würden. Wir würden das Modell keine Fundstelle ausgeben lassen, die sich nicht aufgelöst hat, mit der Begründung, sie sei „wahrscheinlich richtig“. Wir würden die Flüssigkeit des Modells nicht als Beleg werten — flüssig-und-falsch ist genau der Fall, für den der ganze Entwurf existiert. Und wir würden das Werkzeug nicht als die Instanz darstellen, die über Compliance entscheidet. Es liefert einen verteidigbaren, nachvollziehbaren Entwurf; das Urteil bleibt bei einem menschlichen Experten.

Was es kostet — und wann es sich lohnt

Nichts davon ist umsonst, und die Rechnung gehört ehrlich benannt. Sie zahlen in Latenz und Tokens: Jeder Befund löst zusätzliche Auflösung und einen zweiten Modelldurchgang aus, ein geprüfter Bericht kostet also grob den doppelt erzeugten Bericht. Sie zahlen in Komplexität: ein Fundstellen-Parser, ein versionsfest fixierter Korpus, ein Resolver und ein expliziter Markierungspfad sind weit mehr bewegliche Teile als „das Modell fragen und die Antwort formatieren“. Und Sie zahlen in Wartung: EUR-Lex ändert sich, Instrumente werden angepasst, und die Zuordnung aktuell zu halten ist laufende Arbeit statt eines einmaligen Baus. Bei KomplAI ist das der Grund, warum EU-AI-Act-, DORA- und DSGVO-Prüfungen, die früher Tage an Expertenlektüre waren, in Minuten zurückkommen — aber die Minuten sind nur deshalb belastbar, weil die Maschinerie dahinter steht.

Der ehrliche Rat lautet daher: Dieses Muster ist nicht für jede LLM-Funktion. Bauen Sie einen Brainstorming-Assistenten oder einen Erstentwurf-Schreiber, ist Verifikation zur Generierungszeit übertrieben und die Latenz den Aufwand nicht wert. Es verdient seine Kosten in genau einer Lage — wenn eine falsche Tatsachenbehauptung Folgen hat. Compliance und Recht sind die offensichtlichen Fälle; medizinische, finanzielle und sicherheitskritische Ausgaben haben dieselbe Form. Der Test ist einfach: Würde eine selbstbewusste, gut formulierte, falsche Fundstelle in Ihrer Ausgabe echten Schaden oder echte Haftung auslösen, brauchen Sie den deterministischen Prüfer. Wäre sie nur ein wenig peinlich, brauchen Sie ihn nicht.

Das wiederverwendbare Muster — und wo Tippel hineinpasst

Ziehen Sie die Compliance-Besonderheiten ab, ist das Muster übertragbar: Verankern Sie jede Tatsachenbehauptung eines LLM in einer maßgeblichen Quelle der Wahrheit und verifizieren Sie sie programmatisch im Moment der Generierung. Retrieval entscheidet, was das Modell sieht; eine deterministische Prüfung entscheidet, was es behaupten darf; ein adversarialer Durchgang entscheidet, was der Prüfung standhält. Die Aufgabe des Modells ist, gut vorzuschlagen. Die Aufgabe des Systems ist, dafür zu sorgen, dass nichts, was es vorschlägt, als Tatsache beim Nutzer ankommt, bevor etwas anderes als das Modell es bestätigt hat. Das ist, was „verifizierbar“ in der Praxis heißt — und der Teil, den tausend dünne Wrapper überspringen.

KomplAI ist die Fassung davon, die wir für uns selbst gebaut haben, in Produktion, und die wir wieder genauso bauen würden. Haben Sie ein LLM-System, für dessen Ausgabe jemand geradestehen muss — einen Bericht, eine Einschätzung, eine Antwort, auf die gehandelt wird —, gilt dieselbe Architektur, und sie ist das meiste dessen, was wir bei Tippel tun. Wollen Sie herausfinden, ob Ihr Anwendungsfall Verifikation zur Generierungszeit wirklich braucht oder davon überkonstruiert würde, ist genau das die Frage des KI-Readiness-Checks — oder nehmen Sie Kontakt auf und beschreiben Sie die Ausgabe, die Sie verteidigen können müssen.