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

Imagine um mundo onde, toda vez que você entra em uma loja, um robô guarda verifica seu RG, sua lista de compras e seu orçamento antes de deixá-lo pegar um único item. Esse robô não está apenas adivinhando; ele está seguindo um livro de regras rigoroso escrito pelo dono da loja. No mundo digital, esse livro de regras é chamado de "política". Ele diz aos computadores o que eles podem fazer, o que eles devem fazer e o que é estritamente proibido fazer. Por muito tempo, escrever esses livros de regras digitais foi como tentar construir um arranha-céu à mão, tijolo por tijolo. É lento, propenso ao erro humano e, se você errar um único tijolo, toda a estrutura pode desmoronar.

Entre o conceito de "conformidade" (compliance). Esta é a palavra sofisticada para garantir que todos sigam as regras. No mundo dos negócios, as empresas passam anos desenhando mapas de como seu trabalho é realizado. Esses mapas são chamados de Modelos de Processo de Negócio (BPMN). Pense neles como os projetos de uma fábrica ou o roteiro de uma peça de teatro. Eles mostram quem faz o quê, quando e em que ordem. A grande questão que os cientistas têm feito é: "Se já temos esses projetos detalhados, por que temos que escrever o livro de regras novamente?" Os projetos já contêm as regras; eles apenas falam uma linguagem diferente. Este artigo trata da construção de um tradutor que transforma esses projetos diretamente em um livro de regras moderno e legível por máquina, para que não tenhamos que escrever as regras duas vezes.

O Tradutor Mágico: De Projetos a Regras

Os autores deste artigo, uma equipe de pesquisadores da Espanha e da Itália, construíram um pipeline inteligente que atua como um detetive digital. O trabalho deles é olhar para o mapa de processo de uma empresa (o arquivo BPMN) e extrair automaticamente as regras ocultas dentro dele, transformando-as em um formato chamado ODRL. Você pode pensar no ODRL como a "linguagem universal" para direitos e regras digitais, um padrão que computadores em todos os lugares podem entender.

Aqui está como o "trabalho de detetive" deles funciona, dividido em etapas simples:

1. O Projeto Já é um Livro de Regras
Os pesquisadores perceberam que a maneira como um mapa de processo é desenhado é, na verdade, um conjunto de regras. Se um mapa mostra que um trabalhador deve verificar um pedido antes de enviá-lo, essa é uma regra chamada "Dever" (Duty). Se o mapa mostra que um trabalhador pode pular uma etapa se uma certa condição for atendida, isso é uma "Permissão" (Permission). Se o mapa mostra que um trabalhador não pode seguir em frente até que um evento específico aconteça, isso é uma "Proibição" (Prohibition). O problema é que essas regras estão trancadas dentro do desenho. O novo pipeline destranca essas regras.

2. A Travessia de Grafo (O Corredor do Labirinto)
O software da equipe trata o mapa de processo como um labirinto. Ele utiliza uma técnica de "travessia de grafo", que é basicamente uma maneira sistemática de percorrer todos os caminhos em um labirinto para ver o que acontece.

• A Verificação do "Ter que Fazer": O software pergunta: "Se removermos esta tarefa, o processo ainda consegue terminar?" Se a resposta for "Não, o processo para", então essa tarefa é um Dever (um must-do).
• A Verificação do "Pode Pular": Se a tarefa estiver em um caminho que nem sempre é percorrido, é uma Permissão.
• A Regra de "Esperar" (A Grande Descoberta): É aqui que o artigo fica realmente inteligente. Em métodos antigos, se um processo tivesse que esperar por um e-mail ou um sinal (chamado de "evento de captura intermediário"), a regra era frequentemente ignorada ou tratada como um simples atraso. Os autores argumentam que isso está errado. Eles dizem: "Se você está esperando, você está na verdade proibido de seguir em frente até que o sinal chegue". Portanto, eles inventaram uma nova maneira de rotular esses momentos como Proibições com uma "restrição de levantamento" (lifting constraint). É como um semáforo vermelho que só fica verde quando um carro específico (o evento) passa por ele.

3. O Resultado
Após percorrer o labirinto, o software gera um livro de regras limpo e válido em um formato chamado JSON-LD. Este é um arquivo que os computadores podem ler instantaneamente. O melhor de tudo? A empresa não teve que escrever uma única regra nova. O software apenas extraiu as regras que já estavam escondidas em seus mapas existentes.

O Que Eles Descobriram (e O Que Não Descobriram)

A equipe testou seu tradutor em cinco diferentes cenários de "referência" (benchmarks), variando de um processo simples de "Despacho de Mercadorias" a um complexo "Restaurante de Autoatendimento" com três pessoas diferentes (pools) interagindo.

• O Sucesso: Em todos os cinco casos, o software transformou com sucesso os mapas em livros de regras sem travar. Ele identificou corretamente quem tinha que fazer o quê, quem poderia pular etapas e quem tinha que esperar. Por exemplo, no cenário de "Pontuação de Crédito" (Credit Scoring), ele percebeu que um banco deve solicitar uma pontuação, mas um serviço de pontuação não pode calcular a pontuação até que os dados cheguem. Ele até lidou perfeitamente com as regras complicadas de "espera", rotulando-as como proibições que se levantam quando o evento ocorre.
• Os Limites: O artigo é honesto sobre onde a magia termina.
  • Loops: Se um processo possui um loop (como um cliente tentando repetidamente), o software simplifica. Ele trata o loop como uma única tarefa de "dever", o que é seguro, mas perde a nuance de "repetir até o sucesso".
  • Nomes: Às vezes, os mapas não possuem nomes para as pessoas envolvidas (como "Banco" ou "Escriturário"). Nesses casos, o software usa apenas rótulos genéricos como "Participante_1", o que torna o livro de regras um pouco difícil de ler para humanos, embora o computador o entenda perfeitamente.
  • Tempo Complexo: O software ainda não consegue expressar regras de tempo complexas, como "A Tarefa A deve terminar exatamente 5 minutos antes da Tarefa B começar". Ele captura a ordem, mas não o tempo preciso.

Por Que Isso Importa

O artigo não afirma ter resolvido todos os problemas do mundo das regras. Não diz que esta é a solução final e perfeita. Em vez disso, prova que uma forma específica e automática de transformar mapas de processos em livros de regras funciona.

Antes disso, se uma empresa quisesse estar em conformidade com novas leis (como regras de privacidade de dados), ela teria que contratar especialistas para escrever manualmente milhares de documentos de política. Isso era lento e caro. Se a empresa mudasse seu processo, ela teria que reescrever as políticas. Esta nova abordagem sugere que, se você alterar seu mapa de processo, o livro de regras se atualiza automaticamente. Isso cria um vínculo direto e auditável entre o que uma empresa faz e as regras que ela segue.

Os pesquisadores observam cuidadosamente que, embora seu método funcione muito bem para mapas de processos padrão, ele ainda precisa de mais trabalho para lidar com loops complexos e tempo preciso. Mas, por enquanto, eles mostraram que as regras já estão lá, escondidas à vista de todos, esperando por um tradutor para libertá-las. É um passo em direção a um futuro onde a conformidade não seja um pesadelo burocrático, mas um subproduto natural de como desenhamos nosso trabalho.