Anhand der Drucksache BT-Drs. 21/6003 (Änderung kindergeldrechtlicher Regelungen) – Schritt für Schritt durch die KI-Pipeline.

Diese Seite erklärt, was zwischen „Drucksache liegt im Bundestag” und „Synopse ist auf lagedergesetze.org/synopsen” eigentlich passiert. Keine Marketing-Sicht – die echte Mechanik.

In Kürze

• Sechs spezialisierte KI-Agenten arbeiten zusammen – alle Claude-Sessions, jede gezielt anders instruiert.

• Jede Synopse durchläuft sechs Stationen (Dirigent, Synopsen-Bearbeitung, zwei Gutachten zur Synopse, Klartext-Bearbeitung, Klartext-Gutachten). Bei Beanstandungen kommt eine Korrekturrunde dazu.

• Ziel ist, künftig Modelle mehrerer Anbieter unabhängig voneinander prüfen zu lassen (Claude, GPT, Gemini) – aktuell laufen alle Rollen auf Claude Sonnet 4.5/4.6.

• Alle Befunde sind im Audit-Trail jeder Synopse sichtbar. Nichts wird versteckt; auch fehlerhafte Drucksachen werden 1:1 übernommen und transparent markiert.

Die Rollen

Jede Rolle hat einen kurzen Anweisungstext (einen sogenannten Skill) – ein paar Bildschirmseiten, die die Rolle, das erwartete Format, die Korrektheits-Disziplin und typische Fehler beschreiben. Die Vollversion liegt im Repo.

Schritt 1 – Drucksache holen

Der Dirigent fragt täglich die DIP-API des Bundestages nach neuen Gesetzentwürfen. Für 21/6003 lädt er die PDF von dserver.bundestag.de, konvertiert sie mit pdftotext in Plaintext und legt sie unter Originalquellen/BT-21/2106003.txt ab.

Parallel sorgt eine deterministische Hilfsschicht dafür, dass die im Gesetzentwurf geänderten Gesetze in einer aktuellen Markdown-Fassung vorliegen – für 21/6003 also Einkommensteuergesetz § 66 und Bundeskindergeldgesetz § 6, jeweils direkt aus dem amtlichen XML von gesetze-im-internet.de.

Schritt 2 – Der Synopsen-Bearbeiter erzeugt den Diff

Der Bearbeiter wird mit drei Pfaden gestartet:

• Pfad zum Drucksachen-Plaintext

• Pfad zur lokalen Gesetzes-Datenbank

• Pfad, an den die fertige JSON-Datei geschrieben werden soll

Skill-Auszug (gekürzt; volle Fassung im Repo):

Du bist Synopsen-Bearbeiter für eine Drucksache. Du liest sie, du liest die betroffenen Gesetze, du schreibst eine strukturierte Synopse als JSON. Du machst nichts anderes.

Pro Änderungsbefehl der Drucksache schreibst du einen Block:

• vorher = der vollständige Norm-Block VOR der Änderung – wortgenau aus dem Gesetz.

• nachher = derselbe Block mit angewendeter Änderung.

• konfidenz ehrlich: hoch wenn eindeutig, unbestimmt wenn du es nicht belastbar lösen konntest.

Niemals halluzinieren. Findest du vorher nicht 1:1 im Gesetz, ist der Block unbestimmt und unsicherheiten muss begründen.

Was 21/6003 ergibt: Zwei Änderungs-Blöcke – jeweils eine Einfügung in einen bestehenden Paragraphen:

Konfidenz bedeutet hier: Wie sicher ist die Pipeline, dass sie den Änderungsbefehl korrekt angewendet hat? Hier ist sie nur mittel – und dafür gibt es einen Grund.

Was 21/6003 lehrreich macht – drei Auffälligkeiten im Drucksachentext

Beim Lesen der Drucksache stieß der Bearbeiter auf:

1. Selbstreferenz im normativen Text: Der eingefügte Absatz 4 enthält den Satz „Satz 2 ist nicht anzuwenden …” – und ist selbst „Satz 2” im neuen Absatz. Der Verweis zeigt damit offenbar auf den gerade eingefügten Satz selbst, was die Anwendung unklar macht. Gemeint war fast sicher „Satz 1”.

2. Widerspruch zwischen Norm und Begründung: Die Begründung der Drucksache spricht von „Satz 3 stellt sicher, dass …” – der normative Text hat aber nur zwei Sätze.

3. Grammatikfehler: „werden die folgende Sätze eingefügt” – fehlendes End-n.

Der Bearbeiter glättet das nicht. Er übernimmt den Drucksachen-Wortlaut 1:1 (inklusive Fehler) und dokumentiert die Beobachtungen im unsicherheiten[]-Feld jedes betroffenen Blocks. Konfidenz fällt deshalb auf „mittel”. So bleibt für jede:n Lesende:n transparent, dass die Auffälligkeit aus dem Drucksachentext stammt, nicht aus der Bearbeitung.

Schritt 3 – Synopsen-Gutachter und Stand-Gutachter prüfen parallel

Sobald die JSON da ist, startet der Dirigent zwei Gutachter – beide laufen gleichzeitig, unabhängig voneinander, ohne den Befund des anderen zu sehen.

Synopsen-Gutachter

Lade die Synopse + die Originalquellen. Prüfe Block für Block:

• Steht befehl_original wortgenau in der Drucksache?

• Steht vorher wortgenau im geltenden Norm-Markdown?

• Wende den Befehl gedanklich auf vorher an – kommt nachher heraus? Wurde nichts ergänzt, nichts still weggelassen?

Stille Auslassungen sind ein kritischer Fehler – wenn vorher ein ganzer Absatz ist und nachher plötzlich nur ein einzelner Satz, ohne dass die Drucksache eine Löschung verlangt: Befund „abgelehnt”, Synopse zurück an Bearbeiter.

Befund für 21/6003: „konsistent” – beide Blöcke wortgenau, kein still weggelassener Text, Adressierung stimmt.

Stand-Gutachter

Beantworte eine einzige Frage: Bezieht sich die Drucksache auf die Gesetzes-Fassung, die wir im Repo haben?

Wenn die Drucksache von einem Stand spricht, der bei uns schon weiter ist (Änderung bereits eingearbeitet) oder noch nicht da ist (Paragraph existiert nicht), kann keine sinnvolle Synopse entstehen.

Befund für 21/6003: „stand passt” – die Drucksache nennt EStG i.d.F. v. 4.2.2026, und unser lokales EStG hat exakt dieses Datum als letzter_stand_builddate.

Schritt 4 – Klartext-Bearbeiter erzeugt die laienverständlichen Erklärungen

Erst wenn die fachliche Synopse durch ist, schreibt der Klartext-Bearbeiter die Übersetzung in Alltagssprache:

Pro Block: ein bis drei Sätze in sachlicher dritter Person.

Keine Wertung. Keine Wirkungs-Adjektive („drastisch”, „massiv”). Konkret bleiben – Beträge, Daten, Behörden mit Namen, sofern die Synopse sie nennt.

Klartext darf nichts hinzufügen, was nicht in der Synopse steht. Externes Hintergrundwissen (Urteile, Begründungs-Zahlen, Gesetzgebungsgeschichte) ist verboten – das wäre Quellen-Recherche, eine andere Rolle. Kontext aus anderen Blöcken derselben Synopse ist erlaubt.

Schritt 5 – Klartext-Gutachter prüft die Erklärungen

Prüfe die Klartext-Felder auf sachliche Richtigkeit und Lesbarkeit. Keine Wertung, keine Wirkungs-Adjektive, keine Hinzufügung aus externem Hintergrundwissen.

Erster Befund für 21/6003: „unsicher”. Der Klartext beider Blöcke hatte das juristisch saubere „nicht nach § 1 Absatz 1 oder 2 unbeschränkt einkommensteuerpflichtig” zu „Wohnsitz nicht in Deutschland” verkürzt. Klingt ähnlich – ist aber juristisch ein anderes Kriterium (beschränkt steuerpflichtige Personen ohne deutschen Wohnsitz fallen anders darunter). Eine verfälschende Vereinfachung.

Schritt 6 – Bei Beanstandung: Korrekturrunde

Der „unsicher”-Befund läuft zurück zum Klartext-Bearbeiter. Der korrigiert gezielt: das juristische Tatbestandsmerkmal wird ausgeschrieben, die voreilige „Wohnsitz”-Vereinfachung entfernt, die unklare Ausnahme (wegen der Drucksachen-Selbstreferenz) ehrlich als „nicht eindeutig bestimmbar” markiert.

Anschließend prüft der Klartext-Gutachter erneut. Befund: „konsistent”. Die Korrektur ist sauber, keine neuen Fehler eingeführt.

Schritt 7 – Freigabe & Veröffentlichung

Mit drei positiven Gutachten ergibt sich automatisch Befund „geprüft”. Der Dirigent:

1. Befüllt den audit-Block der Synopse (alle drei Gutachten + Freigabe-Zeitstempel).

2. Lässt die Render-Schicht aus der JSON eine Markdown-Seite mit Vorher/Nachher-Diff + Audit-Trail erzeugen.

3. Bereitet die Webseite für die Veröffentlichung vor und spielt sie nach Freigabe auf Cloudflare Pages aus.

4. Synct die Synopse-JSON auf den API-Server, sodass die iOS-App sie sofort sieht.

Hätte einer der Gutachter „mit vorbehalt” gemeldet (etwa weil ein Block konfidenz: niedrig hat), würde die Synopse trotzdem veröffentlicht – aber mit gelbem „MIT VORBEHALT”-Badge in der Übersicht und allen Details im Audit-Trail.

Typische Fehler-Muster

Transparenz

Jede Synopse trägt ihren Befund offen oben auf der Synopsen-Karte: GEPRÜFT, MIT VORBEHALT oder PRÜFUNG NÖTIG. Auf der Detail-Seite zeigt die Audit-Trail-Sektion alle Stufen mit ihren Modellen, Befunden und (bei den Gutachtern) den jeweiligen Beobachtungen.

Die Synopse-Daten selbst sind unter CC0 / Public Domain frei nutzbar – alles ist über die API abrufbar. Der Quellcode der Pipeline soll Open Source werden, sobald die Architektur stabil ist.

Der Befund wird nie versteckt – er ist auf der Synopsen-Liste, in der API (befund-Feld) und im PDF-Download immer sichtbar. Wie die drei Gutachten zustande kommen, erklärt der Beitrag Das Vier-Augen-Prinzip.

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.