Del acuerdo en papel a la política ejecutable: ODRL y la automatización de las reglas de uso de datos

Todo el que haya trabajado con acuerdos de compartición de datos conoce la escena: el contrato dice que “los datos solo podrán utilizarse con fines de investigación y deberán eliminarse a los doce meses”, y a partir de ahí… la cláusula queda confiada a la buena fe del consumidor y a alguna auditoría ocasional. Entre lo que el papel dice y lo que los sistemas hacen se abre un abismo, y ese abismo es tolerable cuando se gestionan tres acuerdos, pero letal cuando se aspira a participar en un espacio de datos con cientos de ofertas, miles de transacciones y contrapartes que no se conocen entre sí.

La respuesta de los espacios de datos a este problema es uno de sus rasgos más distintivos: las condiciones de uso de los datos no solo se pactan, sino que se ejecutan. Para ello, las reglas se expresan en un lenguaje que las máquinas pueden interpretar y hacer cumplir, y el estándar de referencia se llama ODRL (Open Digital Rights Language), una recomendación del W3C. En este artículo —el hermano técnico del que dedicamos a los data permits, data contracts y data sharing agreements— explicamos cómo una cláusula jurídica se convierte en una política ejecutable, qué puede y qué no puede automatizarse, y por qué esta pieza es la que hace escalable la confianza.

El problema: el contrato no compila

Las cláusulas de uso de los acuerdos de datos están escritas en lenguaje jurídico, y el lenguaje jurídico está pensado para personas: admite matices, contexto e interpretación. Los sistemas que mueven los datos, en cambio, solo entienden condiciones evaluables: verdadero o falso, permitido o denegado. Mientras la regla viva únicamente en el papel, su cumplimiento depende de que alguien la lea, la recuerde y la respete.

En un intercambio bilateral esa dependencia se puede sobrellevar. En un espacio de datos, no: el volumen de ofertas y transacciones hace inviable la vigilancia manual, y la ausencia de relación previa entre las partes hace insuficiente la buena fe. La conclusión a la que han llegado todas las arquitecturas de referencia es la misma: las reglas de acceso y uso deben viajar con los datos en un formato que los sistemas puedan evaluar y aplicar automáticamente. Es la continuación natural de la cascada que describimos al hablar del rulebook: de las reglas comunes del espacio a las cláusulas del acuerdo, y de las cláusulas a la política ejecutable.

¿Qué es ODRL?

ODRL es un lenguaje estandarizado por el W3C para expresar políticas sobre activos digitales: qué se puede hacer con ellos, qué está prohibido y qué obligaciones acompañan al uso. Una política ODRL se construye con un vocabulario deliberadamente sencillo:

• • Permisos (permissions): acciones que el beneficiario puede realizar sobre el activo, como usar, reproducir, distribuir o agregar.
  • Prohibiciones (prohibitions): acciones expresamente vetadas, como redistribuir a terceros o intentar reidentificar personas.
  • Obligaciones (duties): deberes que condicionan o acompañan al permiso, como eliminar los datos en una fecha, atribuir la fuente o notificar el uso.
  • Restricciones (constraints): condiciones que acotan cualquiera de los anteriores: la finalidad, el periodo temporal, el ámbito geográfico, el número de usos.
  • Partes y activos: quién otorga (assigner), quién recibe (assignee) y sobre qué conjunto de datos concreto aplica todo lo anterior.

Con estas piezas, nuestra cláusula inicial —“solo con fines de investigación y eliminación a los doce meses”— deja de ser prosa y se convierte en una estructura: un permiso de uso con una restricción de finalidad (investigación) y una obligación de borrado con restricción temporal (doce meses desde el acceso). Expresada en JSON-LD, el formato habitual de ODRL, tendría un aspecto como este (simplificado):

{
  "@type": "Agreement",
  "target": "https://espacio.ejemplo/datasets/estudio-2026",
  "permission": [{
    "action": "use",
    "constraint": [{ "leftOperand": "purpose", "operator": "eq", "rightOperand": "research" }],
    "duty": [{
      "action": "delete",
      "constraint": [{ "leftOperand": "elapsedTime", "operator": "lteq", "rightOperand": "P12M" }]
    }]
  }],
  "prohibition": [{ "action": "distribute" }]
}

No hace falta ser desarrollador para leer lo esencial: la política dice quién puede hacer qué, bajo qué condición y con qué deber asociado, en un formato que un sistema puede evaluar sin ambigüedad. Esa es toda la magia, y es mucha.

¿Y cómo se hace cumplir? El papel de los conectores

Una política legible por máquina solo es útil si alguien la ejecuta, y en los espacios de datos ese alguien son los conectores: los componentes de software que cada participante despliega para intercambiar datos con los demás (los del modelo IDS o implementaciones abiertas como Eclipse Dataspace Components, por citar las más extendidas). El ciclo completo funciona así:

1. 1. El proveedor publica su oferta en el catálogo con la política ODRL asociada: es su propuesta de condiciones.
   2. Los conectores de proveedor y consumidor negocian: el consumidor acepta la oferta o propone variaciones, y el resultado es un acuerdo (agreement) en ODRL que vincula a ambas partes para ese activo concreto.
   3. Durante el intercambio, los conectores aplican la política: verifican la finalidad declarada, bloquean las acciones prohibidas, exigen las credenciales requeridas.
   4. Todo el proceso deja evidencias: registros de la negociación, del acuerdo y de su cumplimiento, que permiten auditar a posteriori quién hizo qué y bajo qué condiciones.

Este ciclo no es una ocurrencia de los tecnólogos: es exactamente lo que la estandarización europea está consolidando. El borrador prEN 18235-3 del comité CEN/CLC JTC 25, vinculado a las obligaciones de interoperabilidad del artículo 33 del Data Act, recoge requisitos para la negociación y ejecución automatizadas de los contratos de compartición de datos y para su observabilidad, es decir, para que el cumplimiento del contrato pueda vigilarse de forma continua y no descubrirse en la siguiente auditoría.

Ejemplo de uso: en un espacio de datos de movilidad, un operador publica sus datos de ocupación con una política que permite el uso para planificación urbana, prohíbe la comercialización a terceros y obliga a la agregación previa a cualquier publicación. Un ayuntamiento acepta la oferta; su conector negocia el acuerdo, accede a los datos y, cuando un técnico intenta descargar registros sin agregar para un informe público, el sistema lo impide y deja constancia. La cláusula ya no depende de que alguien la recuerde.

Lo que ODRL no puede hacer (y conviene saber)

La honestidad intelectual obliga a marcar los límites, porque el entusiasmo por la automatización tiene su propia trampa:

• • No todo lo jurídico es formalizable. Conceptos como “uso razonable”, “interés legítimo” o “medidas apropiadas” requieren juicio humano; al traducir una cláusula a ODRL se produce inevitablemente una pérdida de matiz, y pretender lo contrario genera una falsa sensación de cobertura. La traducción debe ser consciente y documentada: qué parte de la cláusula ejecuta la máquina y qué parte sigue vigilando el jurista.
  • El vocabulario genérico se queda corto. ODRL define las piezas comunes, pero cada sector necesita precisar sus términos (¿qué significa exactamente “finalidad de investigación” en salud?, ¿y “agregación suficiente” en movilidad?). Para eso existen los perfiles ODRL, extensiones del vocabulario que cada espacio de datos define en coherencia con su rulebook; elaborarlos es parte del trabajo de gobernanza, no un detalle técnico.
  • La política ejecutable no sustituye al acuerdo jurídico: lo implementa. El data sharing agreement sigue siendo la fuente de las obligaciones; la política ODRL es su brazo ejecutor para todo aquello que puede verificarse automáticamente. Cuando ambos se desalinean —se firma una cosa y se ejecuta otra— el problema es mayúsculo, y por eso la trazabilidad entre cláusula y política debería mantenerse de forma explícita.

La automatización de las reglas de uso es la pieza que convierte la confianza de los espacios de datos en algo escalable: las condiciones pactadas dejan de depender de la memoria y la buena fe para pasar a ser evaluadas, aplicadas y registradas por los propios sistemas que mueven los datos. ODRL aporta el lenguaje, los conectores el músculo, y la estandarización europea —con la serie EN 18235 y el Data Act como telón de fondo— el marco que lo hace exigible. Pero conviene retener la lección completa: la máquina ejecuta bien lo que las personas han gobernado bien antes, y por eso el camino empieza, como siempre, en un rulebook claro y en cláusulas pensadas para ser ejecutables.

Si tu organización quiere traducir sus acuerdos de datos en políticas ejecutables, definir el perfil ODRL de su espacio de datos o asegurar la trazabilidad entre sus cláusulas y sus sistemas, en DQTeam podemos ayudarte. ¡Hablemos de datos!

---