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

Immaginate un mondo in cui, ogni volta che entrate in un negozio, un robot custode controlla il vostro documento d'identità, la vostra lista della spesa e il vostro budget prima di lasciarvi prelevare anche un solo articolo. Quel robot non sta solo tirando a indovinare; sta seguendo un rigido libro di regole scritto dal proprietario del negozio. Nel mondo digitale, questo libro di regole è chiamato "policy". Esso dice ai computer cosa sono autorizzati a fare, cosa devono fare e cosa è loro severamente vietato fare. Per molto tempo, scrivere questi libri di regole digitali è stato come cercare di costruire un grattacielo a mano, un mattone alla volta. È un processo lento, soggetto all'errore umano e, se si sbaglia anche un solo mattone, l'intera struttura potrebbe crollare.

Entra in scena il concetto di "compliance". Questa è la parola elegante per assicurarsi che tutti rispettino le regole. Nel mondo del business, le aziende trascorrono anni a disegnare mappe di come viene svolto il loro lavoro. Queste mappe sono chiamate Business Process Models (BPMN). Pensatele come le planimetrie di una fabbrica o la sceneggiatura di un'opera teatrale. Mostrano chi fa cosa, quando e in quale ordine. La grande domanda che gli scienziati si sono posti è stata: "Se abbiamo già queste mappe dettagliate, perché dobbiamo scrivere di nuovo il libro delle regole?". Le planimetrie contengono già le regole; solo che parlano una lingua diversa. Questo articolo riguarda la costruzione di un traduttore che trasformi direttamente quelle planimetrie in un moderno libro di regole leggibile dalle macchine, in modo da non dover scrivere le regole due volte.

Il Traduttore Magico: Dalle Planimetrie alle Regole

Gli autori di questo articolo, un team di ricercatori spagnoli e italiani, hanno costruito una pipeline intelligente che agisce come un detective digitale. Il loro compito è guardare la mappa dei processi di un'azienda (il file BPMN) ed estrarre automaticamente le regole nascoste al suo interno, trasformandole in un formato chiamato ODRL. Potete pensare all'ODRL come al "linguaggio universale" per i diritti e le regole digitali, uno standard che i computer ovunque possono comprendere.

Ecco come funziona il loro "lavoro da detective", suddiviso in semplici passaggi:

1. La Planimetria è già un Libro di Regole
I ricercatori si sono resi conto che il modo in cui viene disegnata una mappa di processo è, in realtà, un insieme di regole. Se una mappa mostra che un lavoratore deve controllare un ordine prima di spedirlo, quella è una regola chiamata "Duty" (Dovere). Se la mappa mostra che un lavoratore può saltare un passaggio se si verifica una certa condizione, quella è una "Permission" (Permesso). Se la mappa mostra che un lavoratore non può procedere finché non accade un evento specifico, quella è una "Prohibition" (Proibizione). Il problema è che queste regole sono bloccate all'interno del disegno. La nuova pipeline le sblocca.

2. Il Graph Traversal (Il Corridore del Labirinto)
Il software del team tratta la mappa di processo come un labirinto. Utilizza una tecnica chiamata "graph traversal" (attraversamento di un grafo), che è essenzialmente un modo sistematico per percorrere ogni sentiero nel labirinto per vedere cosa succede.

• Il controllo del "Dover Fare": Il software chiede: "Se rimuoviamo questo compito, il processo può ancora terminare?". Se la risposta è "No, il processo si ferma", allora quel compito è un Duty (un obbligo).
• Il controllo del "Si può saltare": Se il compito si trova su un percorso che non viene sempre seguito, è un Permission (un permesso).
• La regola dell' "Aspetta" (La Grande Scoperta): È qui che l'articolo diventa davvero ingegnoso. Nei metodi più vecchi, se un processo doveva attendere un'email o un segnale (chiamato "intermediate catch event"), la regola veniva spesso ignorata o trattata come un semplice ritardo. Gli autori sostengono che questo sia sbagliato. Dicono: "Se stai aspettando, sei in realtà proibito dal procedere finché il segnale non arriva". Così, hanno inventato un nuovo modo per etichettare questi momenti come Prohibitions (proibizioni) con un "lifting constraint" (vincolo di rilascio). È come un semaforo rosso che diventa verde solo quando passa una specifica auto (l'evento).

3. L'Output
Dopo aver attraversato il labirinto, il software produce un libro di regole pulito e valido in un formato chiamato JSON-LD. Si tratta di un file che i computer possono leggere istantaneamente. La parte migliore? L'azienda non ha dovuto scrivere una singola nuova regola. Il software ha semplicemente estratto le regole che erano già nascoste nelle loro mappe esistenti.

Cosa hanno scoperto (e cosa non hanno scoperto)

Il team ha testato il loro traduttore su cinque diversi scenari di riferimento ("benchmark"), che vanno da un semplice processo di "Spedizione Merci" a un complesso "Self-Service Restaurant" con tre diverse persone (pool) che interagiscono tra loro.

• Il Successo: In tutti e cinque i casi, il software ha trasformato con successo le mappe in libri di regole senza crashare. Ha identificato correttamente chi doveva fare cosa, chi poteva saltare i passaggi e chi doveva aspettare. Ad esempio, nello scenario "Credit Scoring", ha capito che una banca deve richiedere un punteggio, ma un servizio di valutazione non può calcolare il punteggio finché i dati non arrivano. Ha gestito perfettamente anche le complicate regole di "attesa", etichettandole come proibizioni che si sollevano quando l'evento avviene.
• I Limiti: L'articolo è onesto riguardo a dove finisce la magia.
  • Loop (Cicli): Se un processo contiene un ciclo (come un cliente che riprova ripetutamente), il software lo semplifica. Tratta il ciclo come un singolo compito "da fare", il che è sicuro ma fa perdere la sfumatura del "ripetere fino al successo".
  • Nomi: A volte le mappe non hanno nomi per le persone coinvolte (come "Banca" o "Impiegato"). In questi casi, il software utilizza semplicemente etichette generiche come "Participant_1", il che rende il libro di regole un po' difficile da leggere per gli umani, anche se il computer lo comprende perfettamente.
  • Tempistiche Complesse: Il software non è ancora in grado di esprimere regole temporali complesse come "Il compito A deve finire esattamente 5 minuti prima che il compito B inizi". Cattura l'ordine, ma non il tempo preciso.

Perché questo è importante

L'articolo non sostiene di aver risolto ogni problema nel mondo delle regole. Non dice che questa sia la soluzione finale e perfetta. Inveve, dimostra che un modo specifico e automatico di trasformare le mappe di processo in libri di regole funziona.

Prima di allora, se un'azienda voleva essere conforme a nuove leggi (come le regole sulla privacy dei dati), doveva assumere esperti per scrivere manualmente migliaia di documenti di policy. Questo era lento e costoso. Se l'azienda cambiava il suo processo, doveva riscrivere le policy. Questo nuovo approccio suggerisce che, se cambiate la vostra mappa di processo, il libro delle regole si aggiorna automaticamente. Crea un collegamento diretto e verificabile tra ciò che un'azienda fa e le regole che segue.

I ricercatori sottolineano con cura che, sebbene il loro metodo funzioni molto bene per le mappe di processo standard, necessita ancora di lavoro per gestire cicli complessi e tempistiche precise. Ma per ora, hanno dimostrato che le regole sono già lì, nascoste in piena vista, in attesa di un traduttore per essere liberate. È un passo verso un futuro in cui la compliance non è un incubo burocratico, ma un prodotto naturale del modo in cui progettiamo il nostro lavoro.