Über 2.000 KI-Halluzinationsfälle vor Gericht: was man bauen sollte

Über 2.000 Gerichtsentscheidungen betreffen halluzinierte KI-Inhalte. Warum RAG allein das nicht löste – und Designmuster aus meiner Arbeit an Vertrags-KI.

Mit Stand vom 14. September 2026 verzeichnet die AI Hallucination Cases Database von Damien Charlotin 2.041 Entscheidungen von Gerichten und Tribunalen zu halluzinierten KI-Inhalten. In den meisten davon hat ein Gericht festgestellt oder nahegelegt, dass sich eine Partei auf solche Inhalte gestützt hat; ausnahmsweise enthält die Datenbank auch einige Entscheidungen, in denen ein KI-Einsatz behauptet, aber nicht bestätigt wurde. Retrieval allein ist nicht die Lösung: Drei führende Tools für die juristische Recherche halluzinierten in einer von Stanford geleiteten Studie aus dem Jahr 2024 jeweils in 17 bis 33 Prozent der Fälle. Bauen sollte man Struktur, die Ausgaben prüfbar macht, einen Ablauf, in dem ein Mensch entscheidet, und einen Evaluationsdatensatz, der zuerst entsteht.

Ich habe als AI Engineer an Kartez Contract gearbeitet. Hier steht, was ich aus dieser Arbeit beibehalten und was ich als Erstes tun würde.

Was die Datenbank zu KI-Halluzinationsfällen Entwicklern sagt – und was nicht

Charlotins Zählung hat die Marke von 2.000 überschritten. Bevor jemand die Zahl in einem Pitch oder einem Risikomemo zitiert, sind drei Punkte wichtig.

Sie zählt Entscheidungen, nicht Fehler. Die Datenbank erfasst nach eigener Angabe nicht „das (zwangsläufig größere) Universum aller erfundenen Zitate oder aller KI-Nutzung in gerichtlichen Schriftsätzen“. Sie ist ein Verzeichnis von Fehlern, die vor einem Richter gelandet sind, keine Halluzinationsrate.

Sie weist Tools keine Schuld zu. Laut ihrem eigenen Hinweis bedeutet die Nennung eines Tools „nicht zwangsläufig, dass dieses Tool für die betreffenden Halluzinationen verantwortlich war“. Nichts in diesem Artikel ordnet deshalb eine Entscheidung aus der Datenbank einem Tool zu. Die weiter unten genannten Tools stammen aus der Stanford-Studie, nicht aus der Datenbank.

Die Kategorien sind wichtiger als die Gesamtzahl. In Charlotins Datenbank tragen 1.690 Entscheidungen das Tag Fabricated (erfunden), 854 das Tag Misrepresented (falsch wiedergegeben) und 548 das Tag False Quotes (falsche Zitate); eine Entscheidung kann mehrere Tags tragen. Eine Prüfung, ob eine zitierte Quelle existiert, kann die meisten Fehler der ersten Art abfangen, also die erfundenen Rechtsquellen. Die anderen beiden lässt sie durch, wann immer die Quelle echt ist, das Zitat aber erfunden oder die Auslegung falsch ist. Ein Vertragstool kann beide Fehler machen und dabei auf eine Klausel verweisen, die es tatsächlich gibt.

Charlotin verzeichnet außerdem 1.174 Entscheidungen, in denen die Partei, die KI nutzte, sich selbst vertrat (pro se litigant), und 811, in denen es ein Anwalt war. Ein juristisches KI-Tool kann also weder davon ausgehen, dass ein Anwalt eingebunden ist, noch davon, dass dieser die Fehler des Tools bemerkt. Das Rechtsgebiet Contract (Vertragsrecht) ist mit 449 Entscheidungen das größte in seiner Datenbank. Gemeint sind Vertragsstreitigkeiten, in denen halluzinierte KI-Inhalte eine Rolle spielten, nicht von KI entworfene Verträge.

Verhindert RAG Halluzinationen bei juristischer KI?

Nein. Die unten beschriebene Stanford-Studie kommt zu dem Schluss, dass juristische Retrieval-Augmented Generation (RAG) „Halluzinationen im Vergleich zu Allzweck-KI-Systemen (hier GPT-4) verringern kann, Halluzinationen aber erheblich, breit gestreut und potenziell heimtückisch bleiben“. Heimtückisch trifft es: Eine falsch belegte Antwort kommt mit einer echten Quelle daher. Das allgemeine Design der Schutzmechanismen beschreibt der Artikel Guardrails gegen Halluzinationen in RAG-Systemen.

Die von Stanford geleitete Studie: 17 bis 33 Prozent

In einem Paper, das am 30. Mai 2024 auf arXiv eingestellt wurde, berichteten Forschende aus Stanford und Yale über „die erste präregistrierte empirische Evaluation KI-gestützter Tools für die juristische Recherche“. Präregistriert heißt: Die Studie und ihr Datensatz aus über 200 juristischen Anfragen wurden registriert, bevor die Evaluation lief. Das schützt davor, die Anfragen passend zu den Ergebnissen auszuwählen. Manche Anbieter hatten damit geworben, Retrieval „beseitige“ Halluzinationen oder „vermeide“ sie. Die Studie ergab, dass Lexis+ AI, Westlaw AI-Assisted Research und Ask Practical Law AI jeweils in 17 bis 33 Prozent der Fälle halluzinierten und dass „die Behauptungen der Anbieter übertrieben sind“.

Wichtiger als die Spanne ist die Definition. Eine Antwort gilt als halluziniert, „wenn sie entweder falsch oder falsch belegt ist“ (im Original: misgrounded), und falsch belegt heißt, dass zentrale Aussagen „zwar zitiert werden, die Quelle aber fehlinterpretieren oder auf eine nicht einschlägige Quelle verweisen“. Die Tools wurden 2024 getestet, und zwar bei der juristischen Recherche, nicht bei Verträgen. Die Spanne ist also keine Kennzahl für juristische KI von heute. Die Kategorie lässt sich aber übertragen: In einem Vertrag klingt eine falsch belegte Antwort richtig und verweist auf die falsche Klausel.

Googles Befund zu ausreichendem Kontext: mehr Kontext, weniger Enthaltungen

Das Paper „Sufficient Context“ trennt Fehler, bei denen das Modell guten Kontext falsch nutzt, von Fehlern, bei denen der Kontext nie für eine Antwort ausgereicht hat. Die größeren getesteten Modelle von Google, OpenAI und Anthropic „geben oft falsche Antworten aus, statt sich zu enthalten, wenn der Kontext nicht“ ausreicht.

Im Blogbeitrag von Google Research zu dieser Arbeit (14. Mai 2025) heißt es, RAG verbessere zwar „im Allgemeinen die Gesamtleistung“, verringere aber „paradoxerweise die Fähigkeit des Modells, sich einer Antwort zu enthalten, wenn das angebracht wäre“. In Googles Beispiel gab Gemma ohne Kontext auf 10,2 Prozent der Fragen falsche Antworten, mit unzureichendem Kontext auf 66,1 Prozent.

Retrieval ändert, was das Modell sieht, nicht, ob es weiß, dass das Gesehene ausreicht. Eine Frage zur Vertragsbeendigung kann von einer Begriffsbestimmung oder einer Mitteilungsklausel abhängen, die nie abgerufen wurde. Das Design muss „Ich brauche einen weiteren Abschnitt“ zu einer normalen Ausgabe machen, und die Evaluation muss genau das testen.

KI-Vertragsprüfung: die Fehler, auf die es ankommt

Eine erfundene Klausel wird zum Haftungsrisiko für jeden, der unterschreibt. Ein Modell, das eine erfindet, ist deshalb schlimmer als gar kein Modell. Die folgenden Fehler würde ich im Design als Erstes angehen. Keines der Muster unten beweist, dass eine Antwort richtig ist; die meisten machen eine falsche Antwort erkennbar.

Designmuster für Vertrags-KI aus dem Projekt Kartez Contract

Von November 2025 bis Juli 2026 habe ich als AI Engineer an Kartez Contract gearbeitet, einem dreisprachigen, auf Rechts-nach-links-Layout ausgelegten Arbeitsbereich für Verträge mit einem Entwurfsassistenten, einem Prüfablauf und einem Vertragsstudio. Die KI-Engine hinter diesen Workflows habe ich neu aufgebaut und erweitert, ausgehend von den ersten einfachen KI-Chains des Auftraggebers. Außerdem habe ich den Copiloten entwickelt, der jede Anfrage klassifiziert, die relevanten Klauseln findet und Änderungen über den gesamten Vertrag hinweg plant.

Die schwierigsten Probleme waren Retrieval und Verankerung, und die Verankerung wurde durch Struktur statt durch Vertrauen erreicht. Keines der sechs folgenden Muster ist eine gemessene Garantie; die ersten vier sind die Designvorgaben zur Verankerung selbst.

Antworten nur aus den Klauseln, die der Copilot ausgewählt hat

Der Vertrag des Nutzers wurde entlang seiner eigenen Struktur zerlegt, einschließlich der Artikel, Klauseln und Anmerkungen (ماده، بند، تبصره), die persische Verträge auf ihre eigene Weise nummerieren. Für die Antwort auf eine Frage wurden nur die dafür relevanten Abschnitte herangezogen, und der Copilot war angewiesen, zu sagen, wenn er Abschnitte brauchte, die ihm nicht vorgelegt worden waren.

Eine Klausel ist eine Einheit, in der Juristen ohnehin arbeiten. Eine Retrieval-Ergebnismenge aus Klauseln lässt sich deshalb bei der Evaluation labeln und prüfen. Die Anweisung bietet eine Alternative zum Raten, ist aber keine erzwungene Sperre; der Evaluationsdatensatz braucht deshalb Fragen, die die ausgewählten Klauseln nicht beantworten können. Retrieval auf Persisch hat eigene Fallstricke; für ein anderes System behandelt sie der Beitrag Hybride Suche für RAG auf Persisch.

Korrekturvorschläge, die den Vertrag exakt zitieren

Jeder Korrekturvorschlag musste den aktuellen Wortlaut wörtlich zitieren, damit sich die Stelle finden und ersetzen ließ, und lieferte sofort einsetzbaren Ersatztext mit. Erst diese Vorgabe macht die Validierung exakter Zitate (exact-quote validation) möglich: Ein Programm kann bestätigen, dass der zitierte Text existiert, bevor der Vorschlag angewendet wird.

Ob eine Umformulierung klug ist, ist eine juristische Wertung. Ob der Satz, den sie ersetzt, existiert, ist ein String-Abgleich. Die OWASP-Leitlinie zu Fehlinformationen durch LLMs formuliert den allgemeinen Grundsatz: „wichtige Ausgaben automatisch validieren, insbesondere Ausgaben aus Umgebungen mit hohem Risiko“. Würde ich es noch einmal bauen, würde ich jeden Vorschlag verwerfen, dessen Zitat nicht gefunden wird, ihn nie näherungsweise anwenden und die verworfenen Vorschläge als Frühwarnsignal zählen.

Diese Korrekturvorschläge gehören zum Prüfablauf, der bei Einstellung der Arbeit noch nicht vollständig getestet war. Das Muster stützt sich also auf seine Logik, nicht auf eine Messung.

Feste Ausgabeschemata, nie im Rohzustand angezeigt

Jede Analyse lieferte eine feste Struktur, sodass Zeitleisten, Risikoregister und Korrekturvorschläge jedes Mal gleich dargestellt wurden. Eine fehlerhaft formatierte Antwort durchlief einen mehrstufigen Parse-und-Reparatur-Schritt, der auch abgeschnittene Antworten reparierte, und wurde bei Bedarf mit mehr Spielraum erneut angefordert. Dem Nutzer wurde sie nie im Rohzustand angezeigt.

Das zielt auf einen stillen Fehler: Eine abgeschnittene Risikoliste wirkt beim Lesen vollständig. Reparatur allein löst das nicht, denn eine abgeschnittene Liste, die sauber geschlossen wird, lässt sich trotzdem parsen. Eine reparierte abgeschnittene Antwort würde ich deshalb erneut anfordern oder kennzeichnen, statt sie als vollständig anzuzeigen. Außerdem gibt ein Schema den übrigen Prüfungen eine bekannte Stelle, an der sie ansetzen können.

Geringe Zufälligkeit beim Entwerfen

Beim Entwerfen lief das Modell mit geringer Zufälligkeit. Das bringt Wiederholbarkeit, keine Korrektheit: Dieselbe Eingabe führt tendenziell zum selben Entwurf, sodass sich Fehler reproduzieren und Evaluationsläufe vergleichen lassen.

Geführte Workflows statt eines Chatfensters für alles

Entwerfen, Prüfen und Bearbeiten sind unterschiedliche Aufgaben, und jede braucht ihren eigenen geführten Workflow statt eines einzigen Chatfensters. Die Prüfung etwa ist aus Sicht des Nutzers verfasst; ihr erster Schritt fragt deshalb nach dessen Rolle im Vertragsverhältnis.

Anthropics Beitrag „Building effective agents“ verwendet „Workflow“ im Sinne der Orchestrierung: „Systeme, in denen LLMs und Tools über vordefinierte Codepfade orchestriert werden“. Workflows bieten laut dem Beitrag „Vorhersagbarkeit und Konsistenz bei klar definierten Aufgaben“. Jeder feste Schritt hat eine bekannte Ein- und Ausgabestruktur, die sich prüfen lässt. Ein leeres Chatfenster nimmt alles entgegen und gibt alles zurück.

Hervorgehobene Änderungen, die der Nutzer annimmt oder ablehnt

In allen drei Workflows galt die Regel: Die KI schlägt vor, der Nutzer entscheidet. Änderungen des Copiloten wurden im Editor hervorgehoben, damit der Nutzer sie annehmen oder ablehnen konnte. Eine Anweisung für den ganzen Vertrag, etwa die Umbenennung einer Vertragspartei, wurde zuerst geplant, dann auf jeden betroffenen Abschnitt angewendet und hervorgehoben.

Der Nutzer beurteilt markierte Änderungen, statt das Dokument erneut zu lesen, und eine Umbenennung ist überall hervorgehoben, wo sie gelandet ist, statt später als Inkonsistenz aufzufallen.

Ein anderes System: die Gates im Assistenten dieser Website

Nichts, was in diesem Abschnitt beschrieben wird, war Teil von Kartez Contract. Der Assistent dieser Website, den ich gebaut habe und pflege, antwortet nur aus den eigenen Inhalten der Website, abgesichert durch deterministische Gates.

Manche Fragen werden per Musterabgleich abgelehnt, bevor überhaupt etwas abgerufen wird: Konditionen und Verfügbarkeit, private Details, Spekulation, Angriffe auf den System-Prompt und Arbeitsaufträge wie Code schreiben oder Texte übersetzen. Geht es in einer Frage nicht um mich und erreicht kein abgerufenes Ergebnis eine Mindestschwelle für den Retrieval-Score, verweigert der Assistent die Antwort, und das Modell wird nie aufgerufen. Fragen über mich werden ebenfalls per Musterabgleich erkannt, etwa an meinem Namen oder einem Pronomen der dritten Person, und nicht schon deshalb abgelehnt, weil keine Passage die Schwelle erreicht. Stattdessen erhält das Modell die eigenen Einträge der Website aus Lebenslauf, Fallstudien, Artikeln und Beratungsangebot und die Anweisung, nur ein festes Token zurückzugeben, wenn diese die Frage nicht abdecken; Leser sehen dann dieselbe Ablehnung. Während eine Antwort gestreamt wird, prüft ein Satz-Gate jeden vollständigen Satz, bevor er angezeigt wird:

• Gültige Quellennummer. Jeder Zitiermarker verweist auf eine Quelle, die dem Modell übergeben wurde.

• Quellenangabe erforderlich. Jeder inhaltliche Satz trägt einen Marker.

• Belegte Werte. Jede Zahl, URL und E-Mail-Adresse kommt in einer Quelle vor, die der Satz zitiert.

• Perspektive. Kein Satz verwendet Pronomen der ersten Person wie ich, mir oder wir.

Ein einziger Satz, der die Prüfung nicht besteht, stoppt die Antwort, und dieser Satz wird nie angezeigt. Zitiermarker werden geprüft und dann entfernt, Leser sehen sie also nie.

Der Mechanismus ist in LLM-Guardrails im Streaming beschrieben. Die Demo RAG vs. ohne streamt eine echte, belegte Antwort neben einer Spalte ohne Retrieval, die bewusst leer bleibt. Fragen Sie dort etwas, bei dem es nicht um mich geht und das diese Website nicht abdeckt, und der Lauf endet, bevor ein Modell erreicht wird. Für ein Vertragstool würde ich dieselbe Art von Prüfung für Beträge, Datumsangaben und Parteinamen ergänzen, wobei jeder Wert wörtlich mit der Quelle übereinstimmen muss.

Juristische KI evaluieren: zuerst den Evaluationsdatensatz aufbauen

Die übliche Reihenfolge lautet: erst bauen, dann messen. Bei juristischer KI würde ich sie umkehren.

1. Eine Designvorgabe ist eine Hypothese. „Korrekturvorschläge müssen den Vertrag exakt zitieren“ ist eine Regel. Wie oft das Modell sie bricht, ist eine Zahl, und nur ein Evaluationsdatensatz liefert sie.

2. Jede Änderung braucht eine Regressionsprüfung. Ohne festen Datensatz wird jede Änderung an Modell, Prompt oder Retrieval nach Gefühl beurteilt.

3. Der Datensatz überdauert das Projekt. Ein gelabelter Datensatz und sein letzter Lauf sind Belege, die jemand anderes nutzen kann. Eine Liste von Designprinzipien ist das nicht.

Was bei Kartez Contract passiert ist

Der Auftraggeber stoppte das Projekt einen Monat vor der Fertigstellung, als kriegsbedingte finanzielle Schwierigkeiten die Finanzierung beendeten. Es war ein Finanzierungsausfall auf Seiten des Auftraggebers, kein Scheitern der Umsetzung. Zu diesem Zeitpunkt waren der Entwurfsassistent, das Vertragsstudio mit seinem Copiloten und die dreisprachige Oberfläche umgesetzt und durchgängig integriert. Der Prüfablauf war in allen fünf Schritten umgesetzt, aber noch nicht vollständig getestet und wurde noch verfeinert, als die Arbeit eingestellt wurde.

Eine Genauigkeitskennzahl gibt es nicht, weil das Projekt endete, bevor ein formaler Evaluationsdatensatz aufgebaut war. Die Designvorgaben waren real; die Zahl, die aus ihnen eine belegbare Aussage gemacht hätte, wurde nie erhoben.

Ein Evaluationsdatensatz für Vertrags-KI in der ersten Projektwoche

Das ist eine Empfehlung, keine Beschreibung von etwas, das Kartez Contract hatte. Jeder Punkt wird binär bewertet: bestanden oder nicht bestanden.

• Beantwortbare Fragen, gelabelt mit ihrer Klausel. Die Antwort muss richtig sein und sich auf diese Klausel stützen.

• Fragen, die der Vertrag nicht beantworten kann. Erwartet wird „Ich brauche Abschnitt X“ oder „Dazu sagt der Vertrag nichts“, keine Antwort.

• Änderungswünsche. Jede zitierte Textstelle in einem Korrekturvorschlag muss per String-Abgleich im Quelldokument gefunden werden.

• Änderungen am ganzen Vertrag. Die Umbenennung einer Partei muss jedes Vorkommen ändern und sonst nichts.

• Werte, die sich nicht ändern dürfen. Beträge, Datumsangaben, Kündigungsfristen und Parteinamen, vor und nach jeder Umformulierung wörtlich verglichen.

• Fehlerhafte Ausgaben. Abgeschnittene und falsch formatierte Antworten dürfen nie im Rohzustand auf dem Bildschirm landen, und eine reparierte abgeschnittene Antwort darf nie als vollständig angezeigt werden.

• Persische Struktur. Nummerierung nach ماده, بند und تبصره, Zeilen mit gemischter Schreibrichtung und persische Ziffern.

• Beide Vertragsseiten. Derselbe Vertrag, aus der Position jeder Partei geprüft.

Fristen der KI-Verordnung (EU AI Act) nach dem Digital Omnibus: eine technische Sicht

• Das Europäische Parlament hat den endgültigen Text am 16. Juni 2026 angenommen, der Rat am 29. Juni 2026.

• Die Kennzeichnung KI-generierter Inhalte ist für Systeme, die vor dem 2. August 2026 in Verkehr gebracht wurden, bis zum 2. Dezember 2026 fällig.

• Die übrigen Transparenzpflichten nach Artikel 50, etwa die Pflicht, Nutzer darüber zu informieren, dass sie es mit einem KI-System zu tun haben, gelten ab dem 2. August 2026.

• Die Pflichten für eigenständige Hochrisiko-KI-Systeme nach Anhang III verschieben sich auf den 2. Dezember 2027. Für KI in Produkten, die unter die Sicherheitsvorschriften nach Anhang I fallen, gilt der 2. August 2028.

Ob ein System in den Anwendungsbereich fällt, ist eine Frage für die Rechtsberatung. Keines der oben beschriebenen Muster ist eine Compliance-Maßnahme.

Checkliste: juristische KI bauen oder einkaufen

• Worauf stützt sich jede Antwort? Auf eine Klausel oder einen Abschnitt, nicht auf „das Dokument“.

• Lässt sich jede Änderung verorten? Jede Änderung zitiert den Text, den sie ersetzt, abgeglichen mit dem Dokument.

• Kann das System sagen, dass die Antwort nicht im Dokument steht? Lassen Sie es sich vorführen.

• Wird die Ausgabe vor der Anzeige validiert? Fehlerhafte Antworten werden repariert oder zurückgehalten.

• Ändert sich etwas ohne Zustimmung? Das sollte nie passieren.

• Gibt es einen Workflow pro Aufgabe? Entwerfen, Prüfen und Bearbeiten sollten sich nicht ein einziges Chatfenster teilen.

• Werden Werte wörtlich geprüft? Beträge, Datumsangaben und Parteinamen, abgeglichen mit der Quelle.

• Kann ich den Evaluationsdatensatz sehen? Was er enthält, welche Einträge die Enthaltung testen und wann er zuletzt lief.

Wenn Sie gerade den Zuschnitt eines KI-Systems für Verträge oder juristische Arbeit festlegen, macht die Projektanalyse aus fünf Fragen eine erste Architektur.

Häufige Fragen

Wie viele KI-Halluzinationsfälle sind vor Gericht gelandet?

Mit Stand vom 14. September 2026 verzeichnet die AI Hallucination Cases Database von Damien Charlotin 2.041 Entscheidungen von Gerichten und Tribunalen zu halluzinierten KI-Inhalten. In den meisten davon hat ein Gericht festgestellt oder nahegelegt, dass sich eine Partei auf solche Inhalte gestützt hat; ausnahmsweise sind auch einige enthalten, in denen ein KI-Einsatz behauptet, aber nicht bestätigt wurde. Die Datenbank erfasst Entscheidungen, nicht jedes erfundene Zitat und nicht jede KI-Nutzung in gerichtlichen Schriftsätzen.

Reduziert RAG Halluzinationen bei juristischer KI?

RAG verringert sie, stoppt sie aber nicht. In einer präregistrierten, von Stanford geleiteten Studie halluzinierten drei Retrieval-basierte Tools für die juristische Recherche seltener als GPT-4, beim Test im Jahr 2024 aber trotzdem jeweils in 17 bis 33 Prozent der Fälle. Googles Forschung zu ausreichendem Kontext ergab, dass größere Modelle oft falsch antworten, statt sich zu enthalten, wenn der abgerufene Kontext nicht ausreicht.

Kann KI Verträge zuverlässig prüfen?

Nicht auf Vertrauensbasis. Bauen lässt sich eine Vertragsprüfung, die Fehler prüfbar macht: Antworten aus ausgewählten Klauseln, Korrekturvorschläge, die den Vertrag exakt zitieren, feste Ausgabeschemata und ein Mensch, der jede Änderung annimmt oder ablehnt. Ob ein Tool Fehler tatsächlich abfängt, ist eine Frage der Messung; fragen Sie deshalb nach seinem Evaluationsdatensatz.

Was ist die Validierung exakter Zitate?

Sie prüft, ob der Text, den ein Korrekturvorschlag zitiert, Wort für Wort im aktuellen Dokument vorkommt, bevor der Vorschlag angewendet wird. Sie setzt eine Regel voraus, nach der jeder Vorschlag den Wortlaut zitiert, den er ersetzt, und macht einen Teil einer juristischen Änderung zu einem String-Abgleich.

Warum gibt es für Kartez Contract keine Genauigkeitskennzahl?

Der Auftraggeber stoppte das Projekt einen Monat vor der Fertigstellung aus kriegsbedingten Finanzierungsgründen, bevor ein formaler Evaluationsdatensatz aufgebaut war. Diese Website schätzt keine Zahlen, die nicht gemessen wurden. Genau diese Lücke ist der Grund, warum dieser Artikel dafür plädiert, den Evaluationsdatensatz zuerst aufzubauen.

Quellen

• Damien Charlotin, AI Hallucination Cases Database, zuletzt aktualisiert am 14. September 2026, abgerufen am 17. September 2026 (CC BY 4.0).

• Varun Magesh, Faiz Surani, Matthew Dahl, Mirac Suzgun, Christopher D. Manning und Daniel E. Ho, „Hallucination-Free? Assessing the Reliability of Leading AI Legal Research Tools“ (2024).

• Hailey Joren, Jianyi Zhang, Chun-Sung Ferng, Da-Cheng Juan, Ankur Taly und Cyrus Rashtchian, „Sufficient Context: A New Lens on Retrieval Augmented Generation Systems“ (2024).

• Google Research, „Deeper insights into retrieval augmented generation: The role of sufficient context“ (14. Mai 2025).

• OWASP GenAI Security Project, „LLM09:2025 Misinformation“.

• Anthropic, „Building effective agents“ (19. Dezember 2024).

• Freshfields, „EU AI Act unpacked #34: The final Digital Omnibus on AI“ (10. Juli 2026).

• Fallstudie Kartez Contract, auf dieser Website.