Compliance als ausführbarer Test: Warum Richtlinien im CI gehören
Eine Richtlinie wird einmal gelesen, ein Test läuft bei jedem Commit. Wie regulatorische Grenzen zu Code werden - mit Allowlist, die nur schrumpfen darf.
Compliance als ausführbarer Test: Warum Richtlinien im CI gehören
<p data speakable Die meisten Compliance Anforderungen an Software scheitern nicht an Unwissen, sondern an Halbwertszeit. Eine Kanzlei definiert eine Grenze, das Team setzt sie um, das Dokument wandert ins Wiki, und achtzehn Monate später hat niemand mehr im Kopf, warum ein bestimmter Satz so und nicht anders formuliert war. Dieser Artikel beschreibt ein Muster, das diese Halbwertszeit aufhebt: die regulatorische Grenze als automatisierter Test, der bei jeder Änderung mitläuft.</p
Das Problem mit Dokumenten
Sie kennen die Kette: Eine rechtliche Anforderung wird geklärt, in ein Konzeptpapier übersetzt, im Onboarding erwähnt, in einer Confluence Seite abgelegt.
Jeder Schritt dieser Kette hat eine Eigenschaft, die man selten ausspricht: Er wirkt zu einem Zeitpunkt, an dem der Fehler noch nicht passiert. Der Moment, in dem die Grenze verletzt wird, sieht anders aus. Da sitzt jemand unter Zeitdruck, ändert eine Formulierung, die sich sperrig liest, und macht sie flüssiger. Der Satz wird besser. Er wird auch unzulässig, aber das steht ihm nicht an.
Die Richtlinie war zu diesem Zeitpunkt zwei Jahre alt und drei Klicks entfernt.
Die Umkehrung
Das Muster ist unspektakulär: Man übersetzt die Grenze in einen Test und hängt ihn in die Pipeline.
```python FORBIDDEN = [ aus der juristischen Bewertung, nicht selbst erfunden r"\bDiagnose\b", r"\bTherapie\b", r"\bBehandlung\b", ]
Bekannte Altlasten. Diese Liste darf schrumpfen, nicht wachsen. BASELINE =
def test keine individualbewertung(): findings = scan(CONTENT PATHS, FORBIDDEN) neu = BASELINE assert not neu, f"Neue unzulaessige Formulierungen: " ```
Zwanzig Zeilen. Der Wert steckt nicht im Code, sondern in drei Entscheidungen dahinter.
Entscheidung 1: Die Liste kommt von außen
Der Test prüft gegen eine Liste, die aus der juristischen Bewertung stammt. Nicht gegen eine, die das Entwicklungsteam für plausibel hält.
Das klingt nach einer Selbstverständlichkeit und ist der häufigste Fehler. Ein Team, das die Begriffe selbst zusammenstellt, prüft am Ende gegen die eigene Vermutung darüber, was verboten sein könnte. Der Test läuft grün und beweist nichts.
Die Liste gehört ins Repository, versioniert, mit einem Verweis auf ihre Quelle. Wenn die Kanzlei nachschärft, ist die Änderung nachvollziehbar.
Entscheidung 2: Die Allowlist ist eine Einbahnstraße
Kein reales Projekt startet auf der grünen Wiese. Es gibt Altbestand, und der ist am ersten Tag nicht sauber.
Der Reflex ist eine Ausnahmeliste. Der Reflex ist richtig, aber unvollständig. Ohne eine zusätzliche Regel wird die Liste zur Mülltonne: Jeder neue Verstoß wandert hinein, weil gerade keine Zeit ist, und nach einem Jahr ist der Test Dekoration.
Die Regel, die den Unterschied macht: Einträge dürfen entfernt, nicht hinzugefügt werden.
Das lässt sich sozial durchsetzen (Review Regel) oder technisch (ein zweiter Test, der die Länge der Liste gegen den letzten Stand prüft). Wichtig ist, dass die Richtung feststeht. Dann ist der einzige mögliche Pfad der in Richtung sauber, auch wenn er langsam ist.
Entscheidung 3: Kontext schlägt Ausnahme
Der interessante Fall ist nicht der klare Verstoß, sondern der Grenzfall.
Ein Begriff kann in einem Abgrenzungssatz zulässig sein „diese Auswertung ist keine Diagnose" und im Fließtext nicht. Wer solche Fälle über Einzelausnahmen löst, höhlt die Prüfung aus, weil jede Ausnahme die nächste rechtfertigt.
Der bessere Weg ist eine Kontextregel: Der Treffer zählt nicht, wenn er innerhalb eines erkennbaren Abgrenzungsmusters steht. Das ist mehr Aufwand in der Einlaufphase und deutlich weniger Diskussion danach.
Rechnen Sie damit, dass die ersten Wochen Fehlalarme produzieren. Das ist keine Fehlfunktion, das ist die Arbeit. Jeder Fehlalarm schärft ein Muster.
Warum das mehr wert ist als es aussieht
Es wirkt zur richtigen Zeit. Nicht beim Onboarding, sondern in dem Moment, in dem die Änderung entsteht. Zwei Minuten nach dem Commit, mit einer Meldung, die die Stelle benennt.
Es überlebt Personalwechsel. Neue Teammitglieder müssen die Historie nicht kennen. Der Build erklärt die Grenze, wenn sie überschritten wird. Das ist die zuverlässigste Form von Wissenstransfer, die ich kenne.
Es ist ein Nachweis statt einer Behauptung. Bei einer Prüfung ist die Frage „wie stellen Sie sicher, dass das eingehalten wird?" mit einem Testlauf und einer Historie beantwortet. Ein Konzeptpapier beantwortet dieselbe Frage mit einer Absicht.
Es verhindert die schleichende Erosion. Kein einzelner Sprint bricht eine Compliance Anforderung. Vierzig Sprints tun es, jeder mit einer kleinen, gut gemeinten Textverbesserung.
Wo das Muster sonst greift
Nichts daran ist branchenspezifisch. Überall dort, wo Textausgaben rechtlichen Grenzen unterliegen, funktioniert derselbe Ansatz:
| Bereich | Was der Test verhindert | | | | | Medizinnahe Software | Formulierungen, die eine individuelle Einordnung transportieren | | Finanz und Anlageberatung | Sätze, die als Empfehlung gelesen werden können | | Versicherung | Zusagen zu Leistungsumfang außerhalb der Bedingungen | | Rechtsdienstleistung | Aussagen, die als Rechtsberatung gelten | | Personalauswahl | Kriterien, die diskriminierend wirken können |
Das Prinzip ist immer dasselbe: Eine Anforderung, die als Prosa formuliert ist, wird in eine Prüfung übersetzt, die bei jeder Änderung läuft.
Was der Test nicht leistet
Zur Ehrlichkeit gehört die Abgrenzung.
Er prüft Muster , nicht Bedeutung. Ein Text kann jedes verbotene Wort vermeiden und trotzdem inhaltlich eine unzulässige Aussage treffen. Der Test ist eine Untergrenze, keine Garantie.
Er ersetzt die juristische Bewertung nicht . Er konserviert ihr Ergebnis. Ohne die Vorarbeit prüft er gegen eine erfundene Liste.
Und er deckt nur ab, was in Dateien steht. Was ein Sprachmodell zur Laufzeit erzeugt, braucht eine zweite Ebene eine Prüfung der Ausgabe gegen die Wissensbasis, bevor sie den Nutzer erreicht. Wie das zusammenspielt, habe ich in der Case Study zur Art. 9 Plattform beschrieben.
Der Einstieg
Sie brauchen keinen großen Rahmen. Drei Schritte reichen für den ersten Durchlauf:
1. Die Liste besorgen. Fünf bis zehn Begriffe oder Muster aus der bestehenden rechtlichen Bewertung. Nicht selbst ausdenken. 2. Einmal ungefiltert scannen. Das Ergebnis ist unangenehm und die ehrlichste Bestandsaufnahme, die Sie bekommen. Alles Gefundene wird zur Baseline. 3. In die Pipeline hängen. Ab jetzt bricht jeder neue Verstoß den Build, der Altbestand nicht.
Ab dem dritten Schritt kann es nur noch besser werden. Das ist die ganze Idee.
Wenn Sie in einer regulierten Branche arbeiten und vor derselben Frage stehen: Ich baue Systeme, bei denen die Grenze im Code steht statt in einem Dokument, das niemand liest.