Hackathon Gaia X España

Resuelve los retos de la economía del dato

Agenda:

9:15 – 9:30 Recepción y registro

9:30 – 9:45 Presentación del Hackathon

9:45 – 11:30 Explicación de los retos y realización de equipos

11:30 – 12:00 Coffee – break

12:00 – 17:00 Desarrollo del Hackathon

17:00 – 18:00 Entrega de premios y final de la jornada

EVENTO HÍBRIDO EN LA UPM Y ONLINE

Register to the hackaton

Retos del Hackathon

Los equipos participantes podrán elegir entre los siguientes cinco retos. Cada uno incluye el contexto, la descripción del desafío y lo que se espera como resultado.

Reto 1: Data Space in 60 Minutes

La carrera del despliegue

Contexto

Uno de los mayores frenos para la adopción de espacios de datos federados es la complejidad inicial de configuración, negociación de catálogos y arranque de conectores. Eunomia busca romper esta barrera reduciendo la curva de entrada a minutos.

El reto

Partiendo de los artefactos y repositorios base de Eunomia (eunomia-deployment), cada equipo debe configurar, arrancar y orquestar un ecosistema funcional de espacio de datos que incluya:

1. Entorno de Autoridad: emisión y validación de identidades y credenciales.
2. Al menos un nodo Proveedor (Provider): publicando catálogos DCAT y servicios de datos.
3. Al menos un nodo Consumidor (Consumer): realizando la negociación de contrato (Dataspace Protocol) y la transferencia efectiva del dato.

Hito clave

Lograr que todo el ciclo (bootstrapping, negociación y transferencia) se complete y verifique en menos de 60 minutos desde un entorno limpio.

Reto 2: Espacios de Datos Efímeros «Al Vuelo» ante Catástrofes

Escenario DANA

Contexto

En situaciones de emergencia extrema como inundaciones, riadas o catástrofes naturales, los tiempos de respuesta son críticos. La coordinación requiere compartir datos en tiempo real entre administraciones públicas (servicios de rescate, meteorología, fuerzas de seguridad) y entidades ciudadanas o privadas en el terreno.

El reto

Desarrollar y demostrar el aprovisionamiento «al vuelo» de un espacio de datos de emergencias que permita:

• Ingesta e intercambio inmediato de flujos críticos: puntos de anegamiento en tiempo real, estado de vías, localización de personas atrapadas y necesidad de suministros.
• Coexistencia operativa de actores oficiales y no oficiales: UME, Protección Civil, AEMET y 112, junto a plataformas de voluntariado, empresas de maquinaria y ONG.
• Canales de contingencia: que un nodo de campo pueda sumarse a la red en cuestión de minutos y comenzar a transferir telemetría sin pasar por semanas de homologación burocrática.

Resultado esperado

Una demostración funcional de un espacio de datos de emergencias que se aprovisiona en minutos y permite el intercambio de datos en tiempo real entre todos los actores implicados.

Reto 3: Orquestación Cloud-Native Multi-Entorno y Resiliencia Elástica

Del localhost a producción

Contexto

Un espacio de datos no puede depender exclusivamente de entornos localhost o instancias locales frágiles. Requiere desplegarse de manera declarativa tanto en nubes públicas o soberanas como en nodos edge o centros de datos descentralizados.

El reto

Evolucionar la base de despliegue de Eunomia (docker-compose / scripts bash) hacia una arquitectura cloud-native lista para producción:

• Manifiestos declarativos (Kubernetes / Helm Charts / Terraform) para desplegar nodos Eunomia en cualquier proveedor cloud: AWS, GCP, Azure o nubes europeas compatibles con Gaia-X.
• Auto-recuperación (self-healing), balanceo de carga en el plano de datos y separación estricta entre plano de control y plano de transferencia.
• Telemetría y observabilidad integrada: métricas de latencia de negociación, estado del almacén de identidades y paneles de control en tiempo real.

Resultado esperado

Una base de despliegue cloud-native, resiliente y observable, que además pueda utilizarse para despliegues rápidos en situaciones de emergencia.

Reto 4: Gobernanza Ética y Verificación Computacional en Espacios de Datos

Perfil ODRL Dialéctico

Contexto

Los espacios de datos federados (alineados con estándares como UNE 0087:2025 y la arquitectura de Gaia-X) garantizan la soberanía y el control de acceso mediante reglas deterministas síncronas. Sin embargo, carecen de mecanismos estandarizados para evaluar compromisos éticos sustantivos, como la equidad algorítmica, la huella de carbono o el impacto social, que no pueden resolverse en milisegundos en el gateway.

Este reto busca cerrar la brecha entre la declaración de intenciones éticas y su coerción técnica mediante agentes computacionales y credenciales verificables.

El reto

1. Identificar limitadores de ética aplicada: analizar y tipificar las dimensiones éticas (datos, plataforma, algoritmo) aplicables a un caso de uso real dentro de un espacio de datos, definiendo umbrales medibles (p. ej., niveles de anonimización, métricas de mitigación de sesgos o límites de intensidad de carbono).
2. Especificación semántica con ODRL Ético: modelar las restricciones identificadas con el Perfil ODRL Dialéctico (hegel-odrl y eth:), generando el contrato JSON-LD que incluya las clases de compromiso ético (hegel:EthicalCommitment) separadas de las reglas deterministas de la pasarela.
3. Interfaces de identificación y verificación de comportamientos: definir la arquitectura telemétrica y las interfaces necesarias para extraer evidencias de comportamiento en tiempo de ejecución (p. ej., metadatos de linaje bajo W3C PROV-O u otras interfaces de observabilidad) sin comprometer el rendimiento I/O del sistema.
4. Emisión de Credenciales Verificables (W3C VC v2.0): una credencial ex-ante (adhesión), mediante la cual el consumidor asume, firma y vincula a su Identificador Descentralizado (DID) los compromisos éticos antes de obtener el acceso provisional; y una credencial ex-post (auditoría), emitida por el agente evaluador, que certifique de manera inmutable las verificaciones realizadas sobre la telemetría y dictamine el nivel de riesgo o conformidad.
5. Agentes computacionales y oráculos de certificación: diseñar e implementar (o esbozar funcionalmente) un agente evaluador asíncrono que ingiera la telemetría, audite el cumplimiento de los limitadores, emita las credenciales de inspección y actualice los registros de revocación (BitstringStatusListEntry) que alimentan el Punto de Decisión de Políticas (PDP).

Entregables

• Un documento de arquitectura que defina los limitadores éticos del caso de uso seleccionado.
• Un archivo JSON-LD válido con la oferta y el acuerdo ODRL integrando las extensiones del perfil ético propuesto.
• Ejemplos funcionales en JSON-LD de las Credenciales Verificables: la firmada por el consumidor y la emitida por el agente u oráculo de inspección.
• Un prototipo, script o diagrama de secuencia que muestre cómo el agente intercepta el comportamiento asíncrono, evalúa el grafo de procedencia y emite el certificado de cumplimiento o actualiza la lista de revocación.

Reto 5 de Tree Technology: TrustED PETs Transformer

Protege los datos, conserva su valor

Contexto

Las organizaciones a menudo necesitan compartir, analizar o publicar datos, pero los datos originales pueden contener información personal, sensible, confidencial o sujeta a otras restricciones. Eliminar los nombres u otros identificadores evidentes rara vez es suficiente: cada tipo de dato requiere técnicas de protección diferentes, y las transformaciones demasiado agresivas pueden destruir el valor del conjunto de datos.

El reto

Inspirado en el proyecto europeo TrustED (GA n.º 101168467), este reto propone desarrollar un prototipo funcional que aplique tecnologías de mejora de la privacidad (PET, por sus siglas en inglés) a conjuntos de datos sensibles, preservando su utilidad analítica.

Los equipos deberán:

1. Detectar o clasificar los tipos de datos presentes e identificar los principales riesgos de privacidad asociados.
2. Seleccionar y justificar las PET o técnicas de transformación adecuadas para los datos y riesgos relevantes, teniendo en cuenta el escenario de intercambio proporcionado.
3. Transformar el conjunto de datos y generar una versión protegida o una vista protegida de este.
4. Aportar evidencias de que las transformaciones aplicadas reducen los riesgos de privacidad identificados, mediante métricas, pruebas o evaluaciones adecuadas a las PET seleccionadas.
5. Demostrar que la versión protegida conserva un nivel de utilidad suficiente para el propósito analítico de referencia.

Los datos

Se proporcionarán uno o varios conjuntos de datos sintéticos realistas de ámbitos como ciberseguridad, sanidad, ciudades inteligentes, movilidad, energía, finanzas, educación, administración pública o atención al cliente. Podrán incluir identificadores directos, cuasiidentificadores, marcas de tiempo, ubicaciones, campos de texto libre, identificadores técnicos, atributos categóricos, mediciones numéricas o estadísticas agregadas.

Junto con cada conjunto de datos, se proporcionará un escenario de intercambio y, al menos, un propósito analítico de referencia cuya utilidad deberá evaluarse antes y después de la transformación. Los equipos podrán proponer análisis adicionales, siempre que estén debidamente justificados.

PET y transformaciones posibles

Entre otras técnicas, podrán utilizarse enmascaramiento, seudonimización, tokenización, generalización, agrupación en intervalos, supresión, agregación, generación de datos sintéticos, ocultación de información sensible en texto libre, la reducción de la precisión de las ubicaciones, el redondeo de marcas de tiempo o la privacidad diferencial para consultas agregadas.

Esta lista es orientativa y no exhaustiva. No se espera que los equipos apliquen todas las técnicas, sino que seleccionen una combinación adecuada para los riesgos identificados y el escenario planteado.

Entregables

La demostración final deberá mostrar:

1. Los tipos de datos y los principales riesgos de privacidad identificados en el conjunto original.
2. Las PET o técnicas de transformación seleccionadas para cada tipo de dato y la justificación de su elección.
3. El prototipo funcional y el conjunto de datos transformado o la vista protegida generada.
4. Evidencias de la reducción de los riesgos de privacidad mediante una o varias métricas, pruebas o evaluación coherentes con las técnicas aplicadas y los riesgos identificados.
5. Una comparación de la utilidad antes y después de la transformación para el propósito analítico de referencia, aplicando el mismo análisis o criterio de evaluación.
6. Una explicación de por qué los datos protegidos pueden resultar adecuados para el escenario de intercambio proporcionado, incluyendo  los posibles riesgos residuales, limitaciones y condiciones de uso.

Las mejores soluciones demostrarán un equilibrio justificado entre privacidad y utilidad: aportarán evidencias de que se han reducido los riesgos relevantes, manteniendo en un grado suficiente lospatrones, las distribuciones, las tendencias, las relaciones o los indicadores necesarios para el caso de uso previsto.

Este proyecto ha recibido financiación del programa de investigación e innovación Horizonte Europa de la Unión Europea en virtud del acuerdo de subvención n.º 101168467.