Von der Prosa zum Modell

Ein Gesetz ist Prosa. Bevor Software es anwenden kann, muss jemand den Text lesen, deuten und in Regeln übersetzen, und das geschieht heute in jeder Behörde, jedem Softwarehaus und jedem Unternehmen aufs Neue. Im ersten Beitrag dieser Serie haben wir beschrieben, was ein digitaler Gesetzeszwilling leisten soll. Dieser Beitrag zeigt, wie er entsteht: in vier Schichten, die Text, Bedeutung, Parameter und Berechnung voneinander trennen, damit nichts verloren geht und jedes Ergebnis auf den Wortlaut zurückführbar bleibt.

Warum ein Übersetzungsschritt nicht genügt

Der heutige Weg vom Gesetz in die Software ist ein einziger großer Sprung. Juristinnen und Juristen formulieren den Text, er wird kundgemacht, und danach beginnt die Arbeit der Umsetzung: Fachabteilungen interpretieren, Entwicklerinnen und Entwickler kodieren, und mit jeder Novelle beginnt der Zyklus von vorn. Dag Wiese Schartum hat diesen Übergang von Rechtsquellen zu Programmcode 2020 als mehrstufigen Transformationsprozess beschrieben („From Legal Sources to Programming Code“); genau in diesem Prozess entstehen Aufwand, Fehler und abweichende Auslegungen, und zwar bei jeder Organisation, die ihn durchläuft. Bei der oberösterreichischen Tourismusabgabe, unserem aktuellen Anwendungsfall am Institut für Wirtschaftsinformatik – Data & Knowledge Engineering der Johannes Kepler Universität Linz, müssen rund 29.000 beitragspflichtige Betriebe dieselbe Berechnung in ihre Buchhaltungssysteme oder Tabellenkalkulationen übernehmen. Ein Gesetz, tausende Implementierungen.

Wir haben selbst zwei Wege ausprobiert, die nicht ausreichen. Für das Buch „Der selbstfahrende Staat“ (Springer Gabler 2024) haben wir den IT-Kollektivvertrag als rein strukturelles XML-Dokument abgebildet. Die Struktur war sauber, aber ein Programm konnte daraus nichts ableiten, weil die Bedeutung der Begriffe fehlte; die angestrebten Einsparungen blieben aus. Später haben wir die oberösterreichische Landschaftsabgabe als Prolog-Programm modelliert. Das war ausführbar, aber in der noch laufenden Evaluierung zeigt sich bisher, dass der Code weder für Juristinnen und Juristen noch für die meisten Informatikerinnen und Informatiker gut lesbar ist. Die Lehre aus beiden Versuchen: Struktur allein ist zu wenig, und Logik allein ist zu undurchsichtig. Was fehlt, ist eine Architektur, die beides verbindet und dabei die Spur zum Text nie abreißen lässt.

Das Vorbild: Smart Contracts und digitale Zwillinge

Zwei Konzepte aus anderen Disziplinen liefern die Bauanleitung. Smart Contracts, wie sie das Accord Project für automatisierte Verträge standardisiert hat, trennen drei Ebenen: den Text der Vereinbarung, ein Modell mit den Parametern und die Logik, die bei Eintritt der Bedingungen ausgeführt wird. Jason Allen beschreibt diese Verschränkung natürlicher und formaler Sprache 2022 als „wrapped and stacked“: Der formale Teil ist in den natürlichen Text eingebettet, nicht an seine Stelle gesetzt.

Digitale Zwillinge aus Maschinenbau und Fertigung steuern das zweite Prinzip bei. Ein Zwilling bildet nie die ganze Wirklichkeit ab, sondern einen bewusst begrenzten Ausschnitt, und er bleibt mit seinem Original synchron (Tao et al. 2018). Übertragen auf Gesetze heißt das: Wir modellieren nicht das gesamte Recht, sondern jene Bestimmungen, die deterministisch entscheidbar sind, und jede Novelle wird im Modell nachgezogen.

In unserem Beitrag zum Internationalen Rechtsinformatik Symposion IRIS 2025 im Februar haben wir beide Prinzipien zusammengeführt und um eine weitere Schicht ergänzt: die Ontologie. Ein Vertrag kennt seine Parteien, ein Gesetz aber muss seine Begriffe für alle definieren, die es anwenden. Ohne eine gemeinsame, maschinenlesbare Bedeutung von „Betrieb“, „Umsatz“ oder „Ortsklasse“ rechnet jedes System mit einer eigenen Deutung.

Die vier Schichten

Die Architektur trennt vier Anliegen, die im Gesetzestext ineinander verwoben sind. Die Tabelle zeigt sie am Beispiel der Tourismusabgabe, die das Oö. Tourismusgesetz 2018 als Tourismusbeitrag der Unternehmerinnen und Unternehmer regelt.

Text: das Gesetz bleibt das Gesetz

Die unterste Schicht ist der Gesetzestext selbst, in seinem Originalformat und ohne jede Anpassung an technische Bedürfnisse. Das ist keine Nostalgie, sondern Voraussetzung: Jede Klasse der Ontologie, jeder Parameter und jede Codezeile muss auf eine Stelle im Text zurückführbar sein. Dafür erhält jede Bestimmung einen eindeutigen Bezeichner, etwa nach dem European Legislation Identifier (ELI), den das Rechtsinformationssystem des Bundes bereits unterstützt. Wer später eine Entscheidung erklärt bekommen möchte, landet immer wieder hier, beim Wortlaut.

Ontologie: Bedeutung, die alle teilen

Die zweite Schicht legt fest, wovon das Gesetz spricht. Für die Tourismusabgabe sind das Klassen wie Tourismusbetrieb, beitragspflichtiger Umsatz, Tourismusgemeinde, Ortsklasse und Beitragsgruppe sowie ihre Beziehungen: Ein Betrieb liegt in einer Gemeinde, eine Gemeinde gehört einer Ortsklasse an, ein Betrieb ist einer Beitragsgruppe zugeordnet. Wir modellieren diese Ontologie in OWL, dem W3C-Standard für Ontologien, weil damit vorhandene Werkzeuge, bestehende Rechtsontologien und Verknüpfungen zu anderen Datenquellen nutzbar werden. Die Ontologie ist die Schicht, die Software, Gesetz und Wirklichkeit dieselbe Sprache sprechen lässt.

Konfiguration: was sich ändert, ohne dass sich das Verfahren ändert

Gesetze enthalten Zahlen: Prozentsätze, Freibeträge, Schwellen, Stichtage. Diese Werte gehören nicht in den Code, sondern in eine eigene Schicht, die die Ontologie um konkrete Axiome erweitert. Für die Tourismusabgabe sind das die Prozentsätze je Beitragsgruppe und Ortsklasse, die Mindestbeiträge und die Obergrenze der Bemessungsgrundlage. In unserem ersten Prototyp zur Einkommensteuer, den wir bei IRIS 2025 vorgestellt haben, waren es Tarifstufen mit Untergrenze, Obergrenze und Steuersatz. Ändert der Gesetzgeber einen Satz, ändert sich ein Wert in der Konfiguration; die Logik bleibt unberührt.

Die Konfiguration definiert außerdem die Schnittstelle des Zwillings: welche Eingaben eine Berechnung braucht und welche Ausgabe sie liefert. Dabei gilt eine bewusste Einschränkung. Eine Schnittstelle gibt es nur für Entscheidungsfragmente, die mit den definierten Eingaben deterministisch berechenbar sind. Wo Ermessen, unbestimmte Rechtsbegriffe oder fehlende Nachweise im Spiel sind, bietet der Zwilling keine Funktion an, sondern gibt den Fall an Menschen zurück.

Logik: die Berechnung, die sich erklärt

Die oberste Schicht ist die ausführbare Logik. Für die Tourismusabgabe liest sie sich in einem Satz: Der Beitrag ist der Prozentsatz für die Kombination aus Beitragsgruppe und Ortsklasse, angewendet auf den gedeckelten Umsatz, mindestens jedoch der Mindestbeitrag. Die Funktion holt Prozentsätze und Mindestbeiträge aus der Konfiguration, prüft die Zuordnung des Betriebs über die Ontologie und protokolliert jeden Schritt mit Verweis auf die zugrunde liegende Bestimmung. Aus diesem Protokoll entsteht die Erklärung, die eine Bürgerin, ein Bürger oder ein Unternehmen verlangen darf.

Wir implementieren diese Schicht in Python, nicht in einer eigens für das Recht erfundenen Sprache. Domänenspezifische Sprachen versprechen Eleganz, aber die Lernkurve ist steil, Expertinnen und Experten sind rar, und die Lesbarkeit für Juristinnen und Juristen ist nicht besser. Eine weit verbreitete Sprache mit Testwerkzeugen, Versionskontrolle und großer Community ist der pragmatischere Weg. Die Logik wird als Dienst mit einer REST-Schnittstelle bereitgestellt, sodass Fachanwendungen der Verwaltung ebenso darauf zugreifen können wie die Unternehmenssoftware der Betriebe.

Der Arbeitsweg von der Prosa zum Modell

Wie kommt man nun von einem Paragrafen zu diesen vier Schichten? In unseren Prototypen hat sich ein Vorgehen in fünf Schritten bewährt, das für jede Funktionalität eines Gesetzes wiederholt wird.

1. Abgrenzen. Welche Bestimmungen sind deterministisch entscheidbar, welche verlangen Wertung? Nur die ersten werden modelliert. Für die Tourismusabgabe ist die Beitragshöhe berechenbar, eine Nachsicht im Einzelfall bleibt Sache der Behörde.
2. In Funktionen schneiden. Das Gesetz wird in abgeschlossene Einheiten zerlegt, etwa „Berechnung der Beitragshöhe“ oder „Ermittlung des beitragspflichtigen Umsatzes“. Jede Einheit erhält Titel, Geltungsbereich und die Liste der Paragrafen, die sie abdeckt.
3. Begriffe fixieren. Aus dem Text der Einheit werden Klassen, Eigenschaften und Beziehungen für die Ontologie extrahiert; jeder Begriff verweist auf die Textstelle, aus der er stammt.
4. Parameter herauslösen. Alle Zahlen, Tabellen und Stichtage wandern in die Konfiguration; zugleich wird die Schnittstelle festgelegt.
5. Logik schreiben und prüfen. Die Berechnung wird implementiert und gegen Fälle getestet, die Steuerexpertinnen und Steuerexperten von Hand gerechnet haben. Erst wenn Modell und Expertenurteil übereinstimmen, gilt die Einheit als abgenommen.

Sprachmodelle können in den Schritten zwei bis fünf Vorschläge liefern, etwa eine erste Segmentierung oder Kandidaten für Ontologieklassen. Entscheidungen treffen sie nicht. Jeder Vorschlag wird von Menschen mit juristischer und technischer Expertise bestätigt, korrigiert oder verworfen. Das ist keine vorübergehende Vorsicht, sondern ein Gestaltungsprinzip: Der Zwilling ist ein prüfbares, versioniertes Artefakt, kein Chatverlauf.

Der Text bleibt das Gesetz. Das Modell ist seine überprüfbare Anwendung.

Was die Trennung bringt und wo sie endet

Der Nutzen der vier Schichten zeigt sich bei der Änderung. Ändert sich ein Begriff, wird die Ontologie angepasst; ändert sich ein Wert, die Konfiguration; ändert sich das Verfahren, die Logik. Jede Änderung bleibt lokal, und der Text zeigt, was sich warum geändert hat. Eine Prüferin oder ein Prüfer kann die Definitionen in der Ontologie, die zum Stichtag geltenden Werte in der Konfiguration und den Entscheidungspfad im Code getrennt nachvollziehen. Und statt tausendfacher Übersetzung gibt es eine: Ein zentral bereitgestellter Zwilling kann von allen Betroffenen über seine Schnittstelle genutzt werden, sei es aus der Fachanwendung einer Behörde oder aus der Buchhaltungssoftware eines Betriebs. In unserem Architekturentwurf übernimmt ein Digital Execution System die Aufgabe, Falldaten entgegenzunehmen, den Zwilling aufzurufen und die Ergebnisse weiterzugeben.

Ebenso wichtig ist, was die Architektur nicht verspricht. Sie ersetzt keine Auslegung. Unbestimmte Rechtsbegriffe, Abwägungen und Härtefälle bleiben ausdrücklich außerhalb des Modells; das ist keine Schwäche, sondern der Grund, warum das Modell rechtsstaatlich tragfähig ist. Ein Zwilling, der nur das berechnet, was das Gesetz eindeutig festlegt, und alles andere an Menschen zurückgibt, schafft Sicherheit auf beiden Seiten: für die Verwaltung, die ihn einsetzt, und für die Bürgerinnen und Bürger, die seinen Ergebnissen unterliegen.

Der nächste Schritt

Die Architektur haben wir im Februar beim IRIS 2025 in Wien vorgestellt und im März als Works-in-Progress beim ACM Symposium on Computer Science and Law 2025 in München zur Diskussion gestellt; beide Beiträge finden Sie unter Publikationen. Die Vision dahinter beschreibt die Seite Digitaler Gesetzeszwilling. Wer in einer Verwaltung oder einem Unternehmen eine Bestimmung kennt, die heute vielfach nachprogrammiert wird, ist eingeladen, sie mit uns durch die vier Schichten zu führen.