Extracting ODRL Policies from Business Process Models: A Graph Traversal Approach to Compliance-by-Extraction

Stellen Sie sich eine Welt vor, in der jedes Mal, wenn Sie ein Geschäft betreten, ein Roboter-Wächter Ihren Ausweis, Ihre Einkaufsliste und Ihr Budget überprüft, bevor er Sie auch nur einen einzigen Artikel auswählen lässt. Dieser Roboter rät nicht einfach; er folgt einem strengen Regelbuch, das vom Ladenbesitzer geschrieben wurde. In der digitalen Welt wird dieses Regelbuch „Policy“ genannt. Es sagt Computern, was sie tun dürfen, was sie tun müssen und wovor sie strikt geschützt sind. Lange Zeit war das Schreiben dieser digitalen Regelbücher so, als würde man versuchen, einen Wolkenkratzer von Hand zu bauen, Stein für Stein. Es ist langsam, anfällig für menschliche Fehler, und wenn man einen einzigen Stein falsch setzt, kann das gesamte Bauwerk zusammenbrechen.

Hier kommt das Konzept der „Compliance“ ins Spiel. Dies ist das schicke Wort dafür, sicherzustellen, dass alle die Regeln befolgen. In der Geschäftswelt verbringen Unternehmen Jahre damit, Karten zu zeichnen, wie ihre Arbeit abläuft. Diese Karten werden Business Process Models (BPMN) genannt. Betrachten Sie sie als Blaupausen für eine Fabrik oder als Skript für ein Theaterstück. Sie zeigen, wer was, wann und in welcher Reihenfolge macht. Die große Frage, die Wissenschaftler gestellt haben, lautet: „Wenn wir bereits diese detaillierten Blaupausen haben, warum müssen wir das Regelbuch dann noch einmal neu schreiben? Die Blaupausen enthalten bereits die Regeln; sie sprechen nur eine andere Sprache. In dieser Arbeit geht es darum, einen Übersetzer zu bauen, der jene Blaupausen direkt in ein modernes, maschinenlesbares Regelbuch verwandelt, damit wir die Regeln nicht doppelt schreiben müssen.“

Der magische Übersetler: Von Blaupausen zu Regeln

Die Autoren dieser Arbeit, ein Forscherteam aus Spanien und Italien, haben eine clevere Pipeline entwickelt, die wie ein digitaler Detektiv agiert. Ihre Aufgabe ist es, die Prozesslandkarte eines Unternehmens (die BPMN-Datei) zu betrachten und die darin verborgenen Regeln automatisch zu extrahieren und sie in ein Format namens ODRL zu überführen. Sie können sich ODRL als die „Universalsprache“ für digitale Rechte und Regeln vorstellen, einen Standard, den Computer überall verstehen können.

So funktioniert ihre „Detektivarbeit“, unterteilt in einfache Schritte:

1. Die Blaupause ist bereits ein Regelbuch
Die Forscher erkannten, dass die Art und Weise, wie eine Prozesslandkarte gezeichnet ist, tatsächlich ein Satz von Regeln ist. Wenn eine Karte zeigt, dass ein Mitarbeiter eine Bestellung prüfen muss, bevor er sie versendet, dann ist das eine Regel namens „Duty“ (Pflicht). Wenn die Karte zeigt, dass ein Mitarbeiter einen Schritt überspringen kann, wenn eine bestimmte Bedingung erfüllt ist, dann ist das eine „Permission“ (Erlaubnis). Wenn die Karte zeigt, dass ein Mitarbeiter nicht fortfahren kann, bis ein bestimmtes Ereignis eintritt, dann ist das eine „Prohibition“ (Verbot). Das Problem ist, dass diese Regeln in der Zeichnung eingeschlossen sind. Die neue Pipeline schließt diese Regeln auf.

2. Die Graph-Traversierung (Der Maze Runner)
Die Software des Teams behandelt die Prozesslandkarte wie ein Labyrinth. Sie nutzt eine Technik namens „Graph Traversal“ (Graphen-Durchlauf), was im Grunde eine systematische Art ist, jeden Pfad durch das Labyrinth abzulaufen, um zu sehen, was passiert.

• Die „Muss-doch“-Prüfung: Die Software fragt: „Wenn wir diese Aufgabe entfernen, kann der Prozess dann immer noch abgeschlossen werden?“ Wenn die Antwort „Nein, der Prozess stoppt“ lautet, dann ist diese Aufgabe eine Duty (eine Pflicht).
• Die „Kann-man-überspringen“-Prüfe: Wenn die Aufgabe auf einem Pfad liegt, der nicht immer genommen wird, ist sie eine Permission (eine Erlaubnis).
• Die „Warte“-Regel (Die große Entdeckung): Hier wird das Papier wirklich clever. In älteren Methoden, wenn ein Prozess auf eine E-Mail oder ein Signal warten musste (ein sogenanntes „intermediate catch event“), wurde die Regel oft ignoriert oder als einfache Verzögerung behandelt. Die Autoren argumentieren, dass dies falsch ist. Sie sagen: „Wenn man wartet, ist man tatsächlich verboten, fortzufahren, bis das Signal eintrifft.“ Daher haben sie einen neuen Weg erfunden, diese Momente als Prohibitions (Verbote) mit einer „lifting constraint“ (aufhebenden Einschränkung) zu kennzeichnen. Es ist wie eine rote Ampel, die erst grün wird, wenn ein spezifisches Auto (das Ereignis) vorbeigefahren ist.

3. Der Output
Nachdem sie das Labyrinth durchlaufen haben, spuckt die Software ein sauberes, gültiges Regelbuch in einem Format namens JSON-LD aus. Dies ist eine Datei, die Computer sofort lesen können. Das Beste daran? Das Unternehmen musste kein einziges neues Regel schreiben. Die Software hat die Regeln einfach aus den bereits existierenden Karten gezogen.

Was sie fanden (und was sie nicht fanden)

Das Team testete ihren Übersetcher an fünf verschiedenen „Benchmark“-Szenarien, die von einem einfachen „Versand von Waren“-Prozess bis hin zu einem komplexen „Self-Service-Restaurant“ mit drei verschiedenen Personen (Pools), die miteinander interagieren, reichten.

• Der Erfolg: In allen fünf Fällen konnte die Software die Karten erfolgreich in Regelbücher umwandeln, ohne abzustürzen. Sie identifizierte korrekt, wer was tun musste, wer Schritte überspringen konnte und wer warten musste. Zum Beispiel fand sie im Szenario „Kreditprüfung“ heraus, dass eine Bank eine Bewertung anfordern muss, aber ein Scoring-Dienst die Bewertung nicht berechnen kann, bis die Daten eintreffen. Sie bewältigte sogar die kniffligen „Warte“-Regeln perfekt, indem sie diese als Verbote kennzeichnete, die sich aufheben, sobald das Ereignis eintritt.
• Die Grenzen: Das Paper ist ehrlich über die Punkte, an denen die Magie aufhört.
  • Schleifen (Loops): Wenn ein Prozess eine Schleife hat (wie ein Kunde, der es immer wieder versucht), vereinfacht die Software dies. Sie behandelt die Schleife als eine einzige „Muss-zu-tun“-Aufgabe, was zwar sicher ist, aber die Nuance des „Wiederholens, bis erfolgreich“ verliert.
  • Namen: Manchmal haben die Karten keine Namen für die beteiligten Personen (wie „Bank“ oder „Angestellter“). In diesen Fällen verwendet die Software einfach generische Bezeichnungen wie „Participant_1“, was das Regelbuch für Menschen etwas schwer lesbar macht, obwohl der Computer es perfekt versteht.
  • Komplexes Timing: Die Software kann noch keine komplexen Zeitregeln ausdrücken, wie etwa „Aufgabe A muss genau 5 Minuten vor dem Start von Aufgabe B abgeschlossen sein“. Sie erfasst die Reihenfolge, aber nicht die präzise Zeitmessung.

Warum das wichtig ist

Das Paper behauptet nicht, alle Probleme der Welt der Regeln gelöst zu haben. Es sagt nicht, dass dies die endgültige, perfekte Lösung ist. Stattdessen beweist es, dass eine spezifische, automatische Methode, Prozesslandkarten in Regelbücher zu verwandeln, funktioniert.

Vor diesem Ansatz mussten Unternehmen, wenn sie konform mit neuen Gesetzen (wie Datenschutzregeln) sein wollten, Experten engagieren, die manuell tausende von Richtliniendokumenten schrieben. Das war langsam und teuer. Wenn ein Unternehmen seinen Prozess änderte, musste es auch die Richtlinien neu schreiben. Dieser neue Ansatz legt nahe: Wenn Sie Ihre Prozesslandkarte ändern, aktualisiert sich das Regelbuch automatisch. Es schafft eine direkte, prüfbare Verbindung zwischen dem, was ein Unternehmen tut, und den Regeln, denen es folgt.

Die Forscher merken vorsichtig an, dass ihre Methode zwar sehr gut für Standard-Prozesslandkarten funktioniert, aber noch mehr Arbeit benötigt, um komplexe Schleifen und präzises Timing zu handhaben. Aber für den Moment haben sie gezeigt, dass die Regeln bereits da sind, unauffällig in der Landkarte verborgen, und darauf warten, dass ein Übersetzer sie befreit. Es ist ein Schritt in Richtung einer Zukunft, in der Compliance kein Papierkrieg ist, sondern ein natürliches Nebenprodukt dessen, wie wir unsere Arbeit gestalten.