Rules as Code: Gesetze in ausführbare Anspruchs- und Berechnungslogik übersetzen

Regeln zu Leistungen, Steuern und Gebühren stehen als Fließtext im Gesetz und werden dann von jedem IT-Projekt neu ausgelegt. Das führt zu uneinheitlichen Umsetzungen und langsamer Reaktion auf Änderungen. „Rules as Code“ (RaC) macht aus dem Gesetz ein formales, versioniertes, testbares Modell, das viele Systeme gemeinsam nutzen können. LLMs entwerfen diesen Code und die zugehörigen Tests inzwischen aus dem Gesetzestext; Juristen und Fachleute der Rechtsetzung prüfen ihn. Das Ergebnis ist eine schnellere, besser nachvollziehbare Digitalisierung von Gesetzen, in der das Gesetz und nicht das Modell maßgeblich bleibt.

Problem & Nutzen

• Heute: Fachreferate schreiben Gesetze; getrennte IT-Teams legen sie in Spezifikationen und Code aus (oft mehrfach: Bürgerportal, Fachverfahren, Rechner). Abweichende Auslegungen führen zu falschen Entscheidungen, Widersprüchen und langsamer Reaktion, wenn sich ein Gesetz ändert. Die Formalisierung erfolgt von Hand, erfordert seltene Mischkompetenz aus Recht und Programmierung und geschieht kaum in größerem Umfang.
• KI-Nutzen: LLMs entwerfen Regeln, Parameterdateien und Testfälle Klausel für Klausel, markieren Mehrdeutigkeiten und leiten den Code neu ab, wenn eine Änderung eintrifft. Die Fachleute verwenden ihre Zeit darauf, zu prüfen und über Auslegungsfragen zu entscheiden, statt zu tippen.
• Belege: Die Experimente „AI-Powered Rules as Code“ des Georgetown Beeck Center (2024) testeten LLMs an den US-Regeln für SNAP und Medicaid und kamen zu dem Schluss, dass LLMs die Codeerzeugung beschleunigen können, komplexe Regellogik aber den Abruf externen Wissens und menschliche Prüfung braucht [1]. Das OECD OPSI hat RaC als Verwaltungspraxis mit internationalen Fallstudien dokumentiert [2]. Eine verlässliche, unabhängige Zahl zur Zeitersparnis über den gesamten Ablauf gibt es bislang nicht; Herstellerangaben sind mit Vorsicht zu behandeln.

Varianten

• Leistungsanspruch und -berechnung (Wohngeld, Kindergeld, Sozialhilfe): der klassische Fall, mit Simulation auf Haushaltsebene.
• Steuer- und Gebührenberechnung: Einkommensteuer, Sozialbeiträge, kommunale Gebühren; Catala wurde für Steuerrecht entworfen (z. B. französische und US-amerikanische Berechnungen) [4].
• Ex-ante-Simulation der Gesetzeswirkung: Gesetzentwurf vor Verabschiedung auf einer synthetischen Bevölkerung durchrechnen (LexImpact auf OpenFisca-France) [3].
• Bürgernahe Prüfer: Werkzeuge „Habe ich Anspruch?“, die dieselbe Regelbasis nutzen wie das Fachverfahren (CONV-011).
• Private/betriebliche Compliance: regulatorische oder vertragliche Regeln (Branchenregulierung, Tarifverträge, Versicherungsbedingungen) als DMN-Tabellen; gleiche Pipeline, geringere Anforderungen des öffentlichen Rechts.

So funktioniert es

1. Gesetzestext (versioniert, mit Zitier-IDs)
2. Segmentierung nach Artikel/Absatz + Glossar der Definitionen
3. LLM entwirft formale Regeln (Ziel-DSL) + Parameter, jedes Element mit Fundstelle markiert
4. LLM erzeugt Testfälle (positiv, Grenzfall, negativ) aus Text und amtlichen Beispielen
5. automatisierte Prüfungen: Parsen/Kompilieren, Typprüfung, Testläufe, Abdeckung der Klauseln, Konsistenz-/Konfliktprüfungen
6. Expertenprüfung (Jurist + Fachverantwortliche): Auslegung freigeben, Mehrdeutigkeit klären
7. Veröffentlichung als versioniertes Regelpaket (Geltungsdaten, Änderungen)
8. Verbraucher: Rechner, Fallsysteme, Simulationen, Entscheidungsunterstützungs-APIs

• Zielformalismen: OpenFisca (Python, Parameterdateien mit Geltungsdaten, von französischen Behördendiensten und Simulatoren im Stil von PolicyEngine genutzt) [3]; Catala (eine gemeinsam mit Juristen entworfene DSL, deren Default-Logik der Funktionsweise von Ausnahmen im Recht entspricht, von Inria) [4]; DMN (OMG-Standard für Entscheidungstabellen, breit unterstützt von Camunda, Flowable, Signavio) [5]; außerdem Prolog/Datalog, Blawx, Drools.
• Zentrale KI-Bausteine: ein Reasoning-LLM für den Entwurf, Retrieval über Gesetzestext, Definitionen und bisherigen Regelcode sowie ein getrennter „Reviewer“-Durchlauf, der den Code in verständliche Sprache zurückübersetzt, damit Nicht-Programmierer ihn mit dem Gesetz abgleichen können.
• Mensch-in-der-Schleife (Human-in-the-Loop, zwingend): juristische Freigabe jeder Auslegungsentscheidung; Freigabe durch die fachlich verantwortliche Stelle vor der Veröffentlichung; unabhängiger Testsatz, den Sachbearbeitende schreiben oder freigeben. Das LLM veröffentlicht Regeln nie selbstständig.

Datenaufbereitung

• Benötigte Daten: der Gesetzestext selbst (Gesetze, Verordnungen, Verwaltungsvorschriften), amtliche Rechenbeispiele und Berechnungsblätter, Parametertabellen (Sätze, Schwellenwerte, Indexierung) und ein Referenzsatz von durch Sachbearbeitende entschiedenen Fällen (Gold Set). Die Gesetze sind öffentlich und sauber; der Aufwand liegt an anderer Stelle.
• Wo sie liegen: Gesetze in gesetze-im-internet, EUR-Lex oder im Redaktionssystem (XML wie Akoma Ntoso oder LegalDocML); Hinweise und Rundschreiben als PDF auf Dateiablagen oder in einem DMS; Parametertabellen und Berechnungslogik in Excel-Tabellen; frühere Entscheidungen im Fachverfahren oder in Papierakten.
• Typische Lücken: gescannte Rundschreiben ohne Textebene, konsolidierte Fassungen vermischt mit veralteten, fehlende Geltungsdaten, Regeln, die in Tabellen oder in den Köpfen der Sachbearbeitenden stecken, und keine unabhängigen Testfälle. Reale Falldaten für das Gold Set enthalten personenbezogene Daten und unterliegen Zugriffsbeschränkungen.
• Aufbereitungsschritte: (1) pro Regelwerk einen versionierten, zitierfähigen Quelltext festlegen (Artikel- und Absatz-IDs); (2) verbleibende PDFs per OCR erfassen (PREP-006) und alte Formate konvertieren (PREP-007); (3) ein Definitionsglossar aufbauen (PREP-012, PREP-015); (4) 50-100 von Sachbearbeitenden entschiedene Fälle als Referenzstandard sammeln (PREP-016, PREP-018), pseudonymisiert (PREP-022); (5) Tabellenlogik in saubere Parametertabellen überführen (PREP-011).
• Aufwandsanteil: gering für den Text, aber etwa 20-30 Prozent des Projekts entfallen auf das Gold Set und das Glossar. Zur Reifeprüfung siehe GUIDE-003.

Umsetzungswege

Welcher Weg für wen

• Öffentliche Hand (B): Die Gesetze sind öffentlich, daher sind Cloud-KI-Dienste in EU-Regionen oder Souveränen Clouds für den Entwurf akzeptabel; Gesetzentwürfe und Falldaten bleiben aus den Prompts heraus oder wechseln zu Weg C, wo Vergabe- oder Souveränitätsvorgaben das verlangen.
• Unternehmen (B): Compliance- oder Vertragsregeln als DMN-Tabellen entwirft man am besten mit Cloud-Modellen im eigenen Repository und in der eigenen CI, weil die Regeln in die eigenen Entscheidungssysteme integriert werden müssen und kein Produkt zum Prozess passt.
• Entwickler (C): Ein Open-Weight-Codiermodell mit der Toolchain von OpenFisca oder Catala läuft lokal auf HW3 und hält Experimente, Regelentwürfe und Testdaten unter Ihrer Kontrolle.

Weg A — Kaufen (Standardsoftware)

Produkte speziell für RaC sind selten. Möglichkeiten: Business-Rules- und Entscheidungsplattformen mit DMN und KI-gestützter Erstellung (Camunda, Flowable, Sapiens Decision, IBM ODM, FICO, Produkte im Stil von Oracle Policy Automation), Low-Code-Plattformen für die Verwaltung und Civic-Tech-Dienste rund um OpenFisca/PolicyEngine. Zum deutschen und europäischen Verwaltungskontext: Der DigitalService (Bund) arbeitet an Prototypen für maschinenlesbare Gesetzgebung und am Digitalcheck für neue Gesetze [6]. Wählen Sie A für überschaubare Regelwerke (Gebühren, einfache Ansprüche), bei denen DMN-Tabellen genügen.

Weg B — Auf Cloud-KI-Diensten aufbauen (empfohlen)

• Führende Reasoning- und Codiermodelle (Claude, GPT, Gemini; Mistral als EU-Anbieter) in EU-Regionen mit strukturierten Ausgaben; Prompt mit Gesetzestext, Glossar und 2-3 geprüften Beispielregeln.
• Als Pipeline in einem normalen Repository orchestrieren: Regeln in Git, CI mit Kompilierung, Tests und Abdeckung, Pull-Request-Prüfung durch Juristen (zu agentischen Codier-Schleifen siehe CODE-002, zur Prüfung CODE-003).
• Retrieval über EUR-Lex / nationale Rechtsdatenbanken und frühere Regelpakete.

Weg C — Selbst betreiben (Open Source)

• Open-Weight-Modelle: Qwen3-Coder / Qwen3 Reasoning, DeepSeek, Mistral und Devstral, gpt-oss; betrieben über vLLM oder Ollama. HW3 (eine GPU mit 48-141 GB) für Modelle mit ca. 30-120 Mrd. Parametern; HW4 für die größten.
• Stack: Toolchain von OpenFisca oder Catala, Git-Plattform, CI, Vektordatenbank für Gesetzestexte. Übliche Wahl für Behörden mit Vorgaben zur Datensouveränität (Gesetze sind öffentlich, Gesetzentwürfe und Falldaten nicht).

Weg D — Eigenes Training

Selten gerechtfertigt. Feintuning auf die Formulierungskonventionen einer Rechtsordnung und vorhandene Regelkorpora kann die Syntaxtreue bei der DSL verbessern (Catala ist in den Vortrainingsdaten schwach vertreten); es braucht Hunderte geprüfter Text-Regel-Paare. RAG plus Compiler-Rückmeldung bringt meist den Großteil des Nutzens.

Stand der Technik (2026)

• LLMs erzeugen in gängigen Sprachen (Python/OpenFisca) zuverlässig syntaktisch gültigen Code, in Nischen-DSLs (Catala) weniger zuverlässig; Reparatur mit Compiler in der Schleife und Few-Shot-Beispiele schließen einen Großteil der Lücke.
• Die besten Ergebnisse liefern testzuerst-Abläufe: Tests aus dem Gesetz erzeugen, dann die Regeln, dann Abweichungen als Hinweise auf Mehrdeutigkeit abgleichen [1].
• Typische Fehlerbilder: übersehene Ausnahmen und Querverweise, falsche Geltungsdaten oder Übergangsvorschriften, stillschweigende Standardannahmen, falsch festgelegte Rundung sowie Zeitraum- und Aggregationssemantik, und Tests, die lediglich den erzeugten Code spiegeln (zirkuläre Validierung).
• Auslegung ist ein Rechtsakt: Wo der Text mehrdeutig ist, muss das Werkzeug die Wahlmöglichkeit sichtbar machen, statt eine auszuwählen. Gesetze, die „Rules-first“ formuliert werden (im Stil des Digitalchecks), mindern das Problem an der Quelle [6].
• Benchmarks speziell für Gesetz-zu-Code sind noch unausgereift; bewerten Sie anhand Ihres eigenen Gold Sets.

Gemeinsame Bausteine & Kombinationen

• Gleicher Stack wie CODE-001/002 (Codier-Assistenten und -Agenten), CODE-015 (Anforderungen aus Stakeholder-Eingaben), CODE-009 und CODE-004 (CI und Testerzeugung).
• Vorgelagert/angrenzend: KNOW-006 (Rechtsrecherche), LANG-026 (Auswertung von Konsultationen).
• Nachgelagert: AGENT-026 (Agenten zur Fallbearbeitung, die den Regeldienst aufrufen), CONV-011 (Bürger- Chatbot, der Regeln aufrufen muss, statt zu improvisieren), DOC-003 (Formularerfassung), ANOM-019 und PRED-029 (Fehler-/Betrugserkennung bei Leistungen und Risikoprofilierung: eigenständige Anwendungsfälle mit hohem Risiko).

Aufwand, Kosten & Kennzahlen

• Weg A: Wochen für Regelwerke im DMN-Umfang. Weg B: 2-6 Monate für ein erstes Gebiet (z. B. eine Leistung) einschließlich juristischer Prüfkapazität. Weg C: zusätzlich Modellbetrieb und Wartung. Hauptkosten sind die Prüfzeit der Fachleute, nicht die Modellnutzung.
• Kennzahlen: Anteil der Klauseln mit verknüpfter Regel und Test; Testbestehensquote auf einer unabhängigen, von Sachbearbeitenden verfassten Suite; Übereinstimmung mit früheren Entscheidungen in Stichproben; Zeit von der verkündeten Änderung bis zur veröffentlichten Regelversion; Korrekturen der Prüfenden je 100 Regeln; Widerspruchs- bzw. Aufhebungsquote im Produktivbetrieb.

Menschen & Veränderung

• Wer und wann: Beziehen Sie zuerst Leitung und Abteilungsleitung (Prozessverantwortliche) ein, um den Umfang festzulegen und die Regel, dass das Gesetz und nicht das Modell maßgeblich ist. Holen Sie Recht/Compliance vom ersten Tag an dazu, da sie jede Auslegung freigeben. Die IT integriert den Regeldienst; die/der Datenschutzbeauftragte kommt dazu, bevor reale Falldaten in das Gold Set gelangen (Datenschutz-Folgenabschätzung (DSFA) wahrscheinlich, wenn Falldaten durch Regeln laufen, die über Personen entscheiden, Art. 35 DSGVO; AVV mit jedem API-Anbieter, Art. 28). Sachbearbeitende schreiben oder genehmigen die unabhängige Testsuite.
• Betriebsrat / Personalrat: abhängig vom Einzelfall. Das Entwerfen von Regeln aus Gesetzen überwacht keine Beschäftigten. Sobald der Regeldienst die Fallbearbeitung steuert, ändern sich Arbeitsabläufe, daher müssen der Personalrat (Personalrat nach BPersVG oder Landesrecht) bzw. der Betriebsrat rechtzeitig unterrichtet werden (§ 90 Abs. 1 Nr. 3 BetrVG); er hat ein Mitbestimmungsrecht, wenn das System Verhalten oder Leistung der Sachbearbeitenden protokolliert (§ 87 Abs. 1 Nr. 6). Die Hinzuziehung eines KI-Sachverständigen gilt als erforderlich (§ 80 Abs. 3). Siehe GUIDE-004.
• KI-Kompetenz: Unterstützen Sie die Beschäftigten mit Schulungen zu LLM-Fehlerbildern (übersehene Ausnahmen, zirkuläre Tests) und zum Lesen zurückübersetzter Regeln (Art. 4 KI-Verordnung (AI Act), GUIDE-006).
• Kommunikation und Pilot: Beginnen Sie mit einer abgegrenzten Leistung oder einem Gebührenverzeichnis und einer kleinen Gruppe von Sachbearbeitenden und Juristen als Fürsprechern (GUIDE-008, GUIDE-009).
• Typische Bedenken: Angst vor automatisierten Entscheidungen und Arbeitsplatzverlust sowie Haftung für falsche Auslegung. Begegnen Sie ihnen mit verbindlicher juristischer Freigabe, sichtbarer Rückverfolgbarkeit vom Code zur Rechtsquelle, menschlicher Prüfung und Widerspruchswegen sowie gestufter Einführung mit Stichproben. Menschen behalten die Kontrolle über jede Veröffentlichung.

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): Das Erzeugen von Regelcode ist selbst kein aufgeführter Verwendungszweck; die Einstufung richtet sich nach dem eingesetzten System. Systeme, die den Anspruch auf öffentliche Leistungen und Dienste bewerten, gelten nach Anhang III Nr. 5 Buchst. a als hochriskant; rein deterministische, regelbasierte Software fällt wohl nicht unter die Definition eines „KI-Systems“, ein LLM im Entscheidungspfad dagegen schon. Holen Sie Rechtsrat ein. Die Verbote nach Art. 5 (z. B. Social Scoring) dürfen nicht berührt werden. Art. 4 KI-Kompetenz gilt. Kennzeichnung: depends [7].
• DSGVO: Gesetze enthalten keine personenbezogenen Daten, Falldaten, die durch die Regeln laufen, aber schon. Art. 22 beschränkt Entscheidungen, die ausschließlich auf automatisierter Verarbeitung beruhen und erhebliche Wirkung haben; nationales Recht (z. B. § 35a VwVfG für vollständig automatisierte Verwaltungsakte, nur wo kein Ermessen besteht) legt die Bedingungen fest [8]. Sehen Sie Erklärungen, menschliche Prüfung und Widerspruchsmöglichkeiten vor.
• Gesetzmäßigkeitsprinzip: Das veröffentlichte Gesetz ist maßgeblich; der Code ist ein abgeleitetes Artefakt. Veröffentlichen Sie Version, Fundstellen und Testsuite; halten Sie den Umgang mit Geltungsdaten prüfbar.
• Risiken und Gegenmaßnahmen: falsche Auslegung im großen Maßstab (unabhängige Prüfung, gestufte Einführung, Stichproben der Entscheidungen); Automatisierungsverzerrung; übermäßiges Vertrauen in von LLMs geschriebene Tests; Lieferketten- und Modellwechsel-Drift (Versionen festschreiben, Regressionssuite bei jedem Modellwechsel).

Erste Schritte

1. Wählen Sie ein abgegrenztes, gut verstandenes Regelwerk (z. B. ein Gebührenverzeichnis oder eine Leistung) mit bekannter Verantwortung.
2. Bauen Sie ein Gold Set auf: 50-100 Fälle mit erwarteten Ergebnissen von Sachbearbeitenden, getrennt vom LLM aufbewahrt.
3. Wählen Sie einen Zielformalismus (OpenFisca, Catala, DMN) und schreiben Sie 2-3 geprüfte Beispielregeln mit Fundstellen.
4. Lassen Sie die LLM-Pipeline mit Compiler- und Test-Rückmeldung laufen; prüfen Sie die Ausgabe mit Juristen anhand des zurückübersetzten Textes.
5. Veröffentlichen Sie als versionierten Dienst, überwachen Sie die Entscheidungen und üben Sie den Aktualisierungszyklus bei Gesetzesänderungen.

Quellen

1. Georgetown Beeck Center — AI-Powered Rules as Code: Experiments with Public Benefits Policy — https://digitalgovernmenthub.org/library/ai-powered-rules-as-code-experiments-with-public-benefits-policy/
2. OECD OPSI — Cracking the code: Rulemaking for humans and machines — https://oecd-opsi.org/publications/cracking-the-code/
3. OpenFisca — open-source rules-as-code engine — https://openfisca.org/en/
4. Catala — programming language for law — https://catala-lang.org/
5. OMG — Decision Model and Notation (DMN) — https://www.omg.org/spec/DMN/
6. DigitalService Bund — Digitalcheck / machine-readable legislation — https://digitalservice.bund.de/en
7. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
8. Regulation (EU) 2016/679 (GDPR), Art. 22 — https://eur-lex.europa.eu/eli/reg/2016/679/oj