Noch immer veröffentlichen die Regulierer Gesetze und Verordnungen als Text. So wie seit Tausenden von Jahren. Regulation as Code bedeutet einen radikalen Bruch mit dieser Praxis.

Ist es möglich, Gesetze in Algorithmen zu überführen? Warum wollte man dies tun? Wie sollten Sie sich als Regulierer, Hersteller, Behörde oder Benannte Stelle darauf vorbereiten?

Antworten liefert dieser Artikel.

1. Vorteile von „Regulation as Code“ a) Verständlichkeit, Klarheit, Eindeutigkeit Tatbestände und Rechtsfolgen

Ein Gesetz ist dann eindeutig, wenn für jeden unmissverständlich klar ist, was die Tatbestände und was die Rechtsfolgen sind, die das Gesetz beschreibt.

Was Tatbestände und Rechtsfolgen sind

Viele Gesetze – Juristen sprechen meist von „Rechtsnormen“ – bestehen aus zwei Teilen: dem Tatbestand und den Rechtsfolgen.

Der Tatbestand formuliert das „Wenn“. Das sind die Kriterien und Voraussetzungen, die erfüllt sein müssen, damit die Rechtsfolgen eintreten. Diese sind das „Dann“.

Beispiel

§ 1 BGB: „Die Rechtsfähigkeit des Menschen beginnt mit der Vollendung der Geburt.“ Die Rechtsfolge ist hier die Rechtsfähigkeit. Der Tatbestand ist, dass es ein Mensch sein muss, dessen Geburt vollendet ist.

Folgen unklarer Tatbestände und Rechtsfolgen

Gesetzestexte, insbesondere die Tatbestände, sind oft nicht ausreichend präzise, verständlich und eindeutig formuliert. Manchmal führt ein fehlerhaft platziertes Komma, manchmal ein Übersetzungsfehler, manchmal eine fehlende Definition dazu, dass die Bedeutung des Satzes nicht mehr dem Ziel des Gesetzgebers entspricht.

Zahllose Publikationen zeugen von diesem Mangel der Unklarheit, den sie versuchen zu beheben. Beispiele für solche Publikationen sind:

  • Wissenschaftliche Fachartikel, z. B. in juristischen Fachzeitschriften
  • Leitlinien (wie die MDCG und FDA Guidance Documents)
  • Normen
  • Gerichtsurteile

Regulatorischen Vorgaben, die als computerlesbare Algorithmen veröffentlicht werden, würden diese Unklarheiten und Uneindeutigen beseitigen.

b) Identifizierbarkeit von Anforderungen

Ein Computer-Algorithmus lässt sich mit einer eindeutigen ID eindeutiger identifizieren und referenzieren als das mit Gesetzestexten möglich ist:

Referenzen wie die folgende wären damit obsolet:

MDR Anhang XIV, Teil A, Satz 1, Unterpunkt a), achter Spiegelstrich, letzter Nebensatz “ .

c) Redundanzfreiheit

Die regulatorischen Vorgaben überlappen sich sowohl untereinander als auch innerhalb der einzelnen Vorgabe.

Beispiel

Die Anforderungen an das Risikomanagement beschreiben die MDR, die ISO 13485, die ISO 14971 und Hunderte weitere Normen, die alle die Festlegung von Akzeptanzkriterien fordern.

Auch innerhalb der einzelnen Regularien gibt es Redundanzen. So fordert die ISO 13485 gleich an drei Stellen in fast buchstabenidentischen Texten die Validierung computerisierter Systeme.

Diese Redundanzen lassen sich mit „Regulation as Code“ beseitigen.

d) Konsistenz, Widerspruchsfreiheit

Widersprüche in gesetzlichen Vorgaben fallen nicht so leicht auf, solange sie in Textform publiziert sind. Leider gibt es diese Widersprüche nicht nur zwischen den Vorgaben aus verschiedenen Rechtsbereichen, sondern auch innerhalb der jeweiligen Rechtsbereiche.

Logikbrüche finden sich beispielsweise in der IEC 62304, in den Dokumenten des Team-NB und den Auslegungen von Landesbehörden.

Mit formal prüfbaren Algorithmen lassen sich solche Widersprüche aufdecken und beseitigen.

e) Vollständigkeit

Gesetze haben oft nicht den Anspruch, die Menge der Tatbestände vollständig abzubilden. Zumindest werden sie diesem Anspruch häufig nicht gerecht.

Mit „Regulation as Code“ sind Lücken identifizierbar.

f) Automatisierbarkeit Die Qualität von Regularien lässt sich automatisiert prüfen

Die Automatisierbarkeit all der oben genannten Qualitätsaspekte (Vollständigkeit, Kons

...

zum Originalartikel