Validieren gegen ein bewegliches Ziel: regulatorisches Wissen versionieren
Notizen aus dem BrainTrainAI-Pilotprojekt: wie eine Regelbasis aktuell bleibt, wenn sich die Regeln selbst laufend ändern – und warum ein Validator nur so vertrauenswürdig ist wie die Version, gegen die er prüft.
Jede regulierte Organisation hat ein Versionsproblem, das sie nicht so nennt. Die Regeln ändern sich, die Dokumente, die diese Regeln beschreiben, ändern sich, und die Systeme, die sie einhalten sollen, ändern sich – selten zur selben Zeit.
Im europäischen Bahnsektor sind TEL TSI und OSDM lebende Spezifikationen. Eine Konformitätsprüfung, die gegen das Release des Vorjahres bestanden wurde, kann heuer scheitern – nicht weil die Implementierung fehlerhaft geworden ist, sondern weil sich das Ziel bewegt hat. Weiß der Validator nicht, gegen welche Version er prüft, sagt ein grünes Ergebnis sehr wenig aus.
Wo das Wissen tatsächlich liegt
In den Organisationen, mit denen wir arbeiten, verteilt sich regulatorisches Wissen auf mindestens vier Orte: die veröffentlichte Spezifikation, deren interne Auslegung, die Konfiguration der umsetzenden Systeme und die Köpfe jener zwei oder drei Personen, die lange genug dabei sind, um die Ausnahmen zu kennen.
- Die Spezifikation ist maßgeblich, aber nicht operativ – sie sagt nicht, wie Ihre Nachrichten aussehen sollen.
- Die interne Auslegung ist operativ, aber nicht dokumentiert – oder einmal dokumentiert und nie aktualisiert.
- Die Systemkonfiguration ist präzise, aber undurchsichtig; niemand liest XSDs zum Vergnügen.
- Die Expertinnen und Experten sind die eigentliche Quelle der Wahrheit – und sie gehen in Pension.
Erst strukturieren, dann validieren
Der erste Schritt von BrainTrainAI ist unspektakulär: Aus diesen Quellen entsteht eine strukturierte, versionierte Wissensbasis. Jede Regel trägt die Version der Spezifikation, aus der sie stammt, das Datum, ab dem sie gilt, und – wo relevant – die zugehörige interne Auslegung.
Ein Validator ist nur so vertrauenswürdig wie die Version, gegen die er prüft.
Erst wenn diese Struktur vorhanden ist, wird automatisierte Validierung aussagekräftig. Der Validator prüft Dokumente, Nachrichten und Datenstrukturen gegen eine bestimmte Version der Regelbasis und hält fest, welche Version er verwendet hat. Genau diesen Nachweis will ein Auditor sehen.
Änderungen steuern
Versionierung ohne Governance ist nur eine längere Liste von Fehlern. Die dritte Ebene ergänzt Rollen, Freigaben und einen lückenlosen Audit-Trail: wer eine Regeländerung vorgeschlagen hat, wer sie freigegeben hat, wann sie in Kraft getreten ist und was sie ersetzt.
Wie das in der Praxis aussieht
- Ein Release der Spezifikation wird eingelesen und mit der aktuellen Regelbasis verglichen.
- Geänderte Regeln werden zur Prüfung durch die fachlich Verantwortlichen markiert.
- Freigegebene Änderungen werden als neue Version der Regelbasis mit Gültigkeitsdatum veröffentlicht.
- Validiert wird gegen die Version, die am Datum des Artefakts gültig war – nicht gegen die neueste.
Über die Bahn hinaus
Nichts davon ist bahnspezifisch. Energie, Finanzwesen und jeder Sektor mit einem sich wandelnden regulatorischen Rahmen stehen vor demselben Problem – nur mit anderem Vokabular. Wir haben bei der Bahn begonnen, weil dort das Domänenwissen der Gruppe am tiefsten ist und weil die Standards öffentlich sind, was die Arbeit leichter zeigbar macht.
Das Pilotprojekt läuft 2026 mit europäischen Bahnorganisationen weiter. Wenn Sie am selben Problem arbeiten, tauschen wir uns gerne aus.
Häufig gestellte Fragen
Ersetzt BrainTrainAI eine Konformitätsbewertung?
Nein. Es bereitet Sie darauf vor. Die automatisierte Validierung gegen eine versionierte Regelbasis findet Probleme früher und dokumentiert, was geprüft wurde; die formale Bewertung wird weiterhin von einer unabhängigen Stelle ausgestellt.
Welche Versionen von TEL TSI und OSDM deckt das Pilotprojekt ab?
Das Pilotprojekt verarbeitet die aktuell veröffentlichten Releases und das vorangegangene Major-Release, sodass historische Artefakte gegen die damals geltenden Regeln validiert werden können.
Kann die Regelbasis unsere internen Auslegungen enthalten?
Ja. Interne Auslegungen werden als Regeln gespeichert, die an der jeweiligen Klausel der Spezifikation hängen, haben eine eigene Versions- und Freigabehistorie und werden gemeinsam mit den öffentlichen Regeln validiert.
IT-Manager und Berater mit mehr als 30 Jahren Erfahrung in Softwareentwicklung und digitaler Transformation, davon über zwei Jahrzehnte im europäischen Eisenbahnsektor. Ehemaliger CTO von RailNetEurope; Promotion in Informatik an der Technischen Universität Graz.