Zum Inhalt springen

Das Vier-Augen-Prinzip

Warum wir KI gegen KI prüfen lassen: vier unabhängige Rollen, drei Kreuz-Prüfungen und ein maschinenlesbarer Audit-Trail pro Synopse.

Lage der Gesetze nutzt eine End-to-End-KI-Pipeline zur Erzeugung von Synopsen – vom Lesen der Drucksache bis zur Veröffentlichung greifen vier unabhängige KI-Rollen ineinander, jede mit klar abgegrenztem Auftrag. Damit das nicht zu einer Black Box wird, ist jeder Schritt im Audit-Trail maschinenlesbar dokumentiert.

Wer den Ablauf konkret an einem Beispiel sehen möchte, findet unter Wie eine Synopse entsteht eine Schritt-für-Schritt-Erklärung anhand der Drucksache 21/6003 (Kindergeld-Indexierung) – inklusive der typischen Fehlerklassen, die wir dort gefunden haben.

Wichtig: Bearbeiter und Gutachter sind in diesem Projekt immer KI-Modelle (Claude und GPT in unterschiedlichen Konfigurationen). Es gibt keine menschlichen Gutachter in der Schleife – Menschen werden nur bei Erratum-Meldungen aktiv und prägen das Goldstandard-Set, anhand dessen die Pipeline laufend kalibriert wird.

Datenfluss

  1. Abruf – Bundestags-DIP-API + gesetze-im-internet.de täglich abrufen (Drucksachen + geltender Norm-Stand)

  2. KI-Bearbeiter – liest die Drucksache + den aktuellen Gesetzestext und erzeugt das strukturierte Vorher/Nachher (Blöcke nach Änderungs-Typ: Wort-Ersetzung, Satz-Neufassung, Einfügung, Aufhebung, …) inklusive Klartext-Erklärung pro Block

  3. Drei KI-Gutachter (Vier-Augen-Prinzip) – jeweils unabhängig:

    • Inhalts-Gutachter prüft, ob der erzeugte Diff den Änderungsbefehl korrekt umsetzt

    • Stand-Gutachter prüft, ob der zitierte „Vorher”-Text dem tatsächlich geltenden Bezugsstand entspricht

    • Klartext-Gutachter prüft, ob die Klartext-Erklärung die juristische Änderung wahrheitsgetreu beschreibt

  4. Veröffentlichung – nur wenn alle drei Gutachten konsistent sind, wird die Synopse mit dem Befund geprüft öffentlich. Divergente Gutachten landen mit mit vorbehalt, teils unsicher oder prüfung nötig in der Liste – sichtbar markiert, nie versteckt.

Warum KI gegen KI?

Eine einzelne KI-Antwort ist nicht vertrauenswürdig – sie kann plausibel klingen und trotzdem halluzinieren. Deshalb baut die Pipeline drei voneinander unabhängige Kreuz-Prüfungen ein:

  1. Vier-Augen zwischen Anbietern. KI-Bearbeiter und KI-Gutachter laufen auf unterschiedlichen Modellfamilien (z.B. Anthropic Claude für die Bearbeitung, OpenAI GPT für die Prüfung – oder umgekehrt). Eine Halluzination müsste in beiden Modellen identisch entstehen, damit sie unentdeckt durchläuft.

  2. Drei verschiedene Blickwinkel. Jeder Gutachter hat einen klar abgegrenzten Auftrag (Inhalt / Bezugsstand / Klartext), keinen Gesamteindruck. Ein Fehler in einer Dimension wird von genau dem Gutachter erwischt, der diese Dimension prüft.

  3. Goldstandard-Tests. Eine wachsende Suite manuell verifizierter historischer Drucksachen prüft retroaktiv, ob neue Prompt- oder Modell-Versionen die Pipeline verbessern oder verschlechtern. Releases gegen die Test-Suite sind die Bremse gegen Regressionen.

Der Befund

Jede Synopse trägt am Ende einen Befund – das aggregierte Urteil aus den drei KI-Gutachten. Er ist nie versteckt und immer sichtbar: auf der Synopsen-Liste, in der API (befund-Feld) und im PDF-Download.

Welche Befund-Stufen es gibt und was jede konkret bedeutet, erklärt der eigene Beitrag Was die Befund-Stufen bedeuten.

Audit-Trail

Pro Synopse wird eine .audit.json mit allen Pipeline-Schritten dokumentiert. Diese Datei enthält:

  • Verwendete LLM-Modelle (Provider + Versions-ID)

  • Prompt-Versionen (versioniert im Repo)

  • Quell-URLs (Drucksache, Norm-Stand, Vorgang)

  • Validation-Ergebnisse (alle vier Strategien)

  • Manuell-verifiziert-Marker + Reviewer-ID + Timestamp

Damit ist jede Synopse forensisch rekonstruierbar.

Was wir explizit NICHT garantieren

Lage der Gesetze ist ein journalistisches und zivilgesellschaftliches Transparenz-Werkzeug, keine amtliche Rechtsfassung. Für rechtlich belastbare Aussagen ist immer das Bundesgesetzblatt (bgbl.de) maßgeblich.

Bei Fehlern: Erratum-Workflow – die korrigierte Version ersetzt das Original am gleichen URL, die alte Version bleibt versioniert zugänglich mit „Korrigiert”-Banner, und der Korrektur-Eintrag landet auf der öffentlichen Erratum-Seite.

Hat dir dieser Beitrag gefallen? Folge mir auf Bluesky und Mastodon für mehr Swift-Tipps und Indie-Dev-Updates.