Ciencia y tecnología

Las visualizaciones de datos actúan como puentes entre la información compleja y la comprensión humana. Un gráfico bien diseñado puede comunicar en segundos datos que llevaría minutos o incluso horas descifrar en formato tabular. Más aún, las visualizaciones interactivas permiten a cada usuario explorar los datos desde su propia perspectiva, filtrando, comparando y descubriendo insights personalizados.

Para alcanzar estos fines existen múltiples herramientas, algunas de las cuales hemos abordado en ocasiones anteriores. Hoy nos acercamos a un nuevo ejemplo: la librería gratuita D3.js. En este post te explicamos cómo permite generar visualizaciones de datos útiles y atractivas junto con la herramienta de código abierto Observable.

¿Qué es D3?

D3.js (Data-Driven Documents) es una biblioteca de JavaScript que permite crear visualizaciones de datos personalizadas en navegadores web. A diferencia de herramientas que ofrecen gráficos predefinidos, D3.js proporciona los elementos fundamentales para construir prácticamente cualquier tipo de visualización imaginable.

La biblioteca es completamente gratuita y de código abierto, publicada bajo licencia BSD, lo que significa que cualquier persona u organización puede utilizarla, modificarla y distribuirla sin restricciones. Esta característica ha contribuido a su adopción generalizada: medios de comunicación internacionales como The New York Times, The Guardian, Financial Times y locales como El País o el ABC utilizan D3.js para crear visualizaciones periodísticas que ayudan a contar historias con datos.

D3.js funciona manipulando el DOM (Document Object Model) del navegador. En términos prácticos, esto significa que toma información (por ejemplo, un archivo CSV con datos de población) y la transforma en elementos visuales (círculos, barras, líneas) que el navegador puede mostrar. La potencia de D3.js reside en su flexibilidad: no impone una forma específica de visualizar datos, sino que proporciona las herramientas para crear exactamente lo que se necesita.

¿Qué es Observable?

Observable es una plataforma web para crear y compartir código, especialmente diseñada para trabajar con datos y visualizaciones. Aunque ofrece un servicio freemium con algunas funcionalidades gratuitas y otras de pago, mantiene una filosofía de código abierto que resulta particularmente relevante para el trabajo con datos públicos.

La característica distintiva de Observable es su formato de "cuadernos computacionales" (notebooks). Similar a herramientas como Jupyter Notebooks en Python, un cuaderno de Observable combina código, visualizaciones y texto explicativo en un mismo documento interactivo. Cada celda del cuaderno puede contener código JavaScript que se ejecuta inmediatamente, mostrando resultados al instante. Esto crea un entorno de experimentación ideal para explorar datos.

Puedes verlo en la práctica en este ejercicio de ciencia de datos que hemos publicado en datos.gob.es

Observable se integra naturalmente con D3.js y otras bibliotecas de visualización. De hecho, el creador de D3.js, es también uno de los fundadores de Observable, por lo que ambas herramientas trabajan conjuntamente de manera fluida. Los cuadernos de Observable pueden compartirse públicamente, permitiendo que otros usuarios vean tanto el código como los resultados, los bifurquen (fork) para crear sus propias versiones, o los integren en sus propios proyectos.

Ventajas de la herramienta para trabajar con todo tipo de datos

Tanto D3.js como Observable presentan características que pueden resultar útiles para trabajar con datos, entre ellos, con datos abiertos:

• Transparencia y reproducibilidad: al publicar una visualización creada con estas herramientas es posible compartir tanto el resultado final como todo el proceso de transformación de datos. Cualquier persona puede inspeccionar el código, verificar los cálculos y reproducir los resultados. Esta transparencia resulta fundamental cuando se trabaja con información pública, donde la confianza y la verificabilidad son esenciales.
• Sin costes de licencia: tanto D3.js como la versión gratuita de Observable permiten crear y publicar visualizaciones sin necesidad de adquirir licencias de software. Esto elimina barreras económicas para organizaciones, periodistas, investigadores o ciudadanos que desean trabajar con datos abiertos.
• Formatos web estándar: las visualizaciones creadas funcionan directamente en navegadores web sin necesidad de plugins o software adicional. Esto facilita su integración en sitios web institucionales, artículos periodísticos o informes digitales, haciéndolas accesibles desde cualquier dispositivo.
• Comunidad y recursos: existe una amplia comunidad de usuarios que comparten ejemplos, tutoriales y soluciones a problemas comunes. Observable, en particular, alberga miles de cuadernos públicos que sirven como ejemplos y plantillas reutilizables.
• Flexibilidad técnica: a diferencia de herramientas con opciones predefinidas, estas bibliotecas permiten crear visualizaciones completamente personalizadas que se adapten exactamente a las necesidades específicas de cada conjunto de datos o historia que se quiera contar.

Es importante señalar que estas herramientas requieren conocimientos de programación, específicamente de JavaScript. Para personas sin experiencia en programación, existe una curva de aprendizaje que puede resultar pronunciada inicialmente. Otras herramientas como hojas de cálculo o software de visualización con interfaces gráficas pueden ser más apropiadas para usuarios que buscan resultados rápidos sin necesidad de escribir código.

Para quienes buscan alternativas open source con una curva de aprendizaje suave, existen herramientas basadas en interfaz visual que no requieren programar. Por ejemplo, RawGraphs permite crear visualizaciones complejas simplemente arrastrando y soltando archivos, mientras que Datawrapper es una opción excelente y muy intuitiva para generar gráficos y mapas listos para publicar.

Además, existen numerosas alternativas tanto de código abierto como comerciales para visualizar datos: Python con bibliotecas como Matplotlib o Plotly, R con ggplot2, Tableau Public, Power BI, entre muchas otras. En la sección didáctica de ejercicios de visualización y ciencia de datos de datos.gob.es puedes encontrar ejemplos prácticos de uso de algunas de ellas.

En resumen, la elección de herramientas debe basarse siempre en una evaluación de requisitos específicos, recursos disponibles y objetivos del proyecto. Lo importante es que los datos abiertos se transformen en conocimiento accesible, y existen múltiples caminos para lograr este objetivo. D3.js y Observable ofrecen uno de estos caminos, particularmente adecuado para quienes buscan combinar flexibilidad técnica con principios de apertura y transparencia. Si conoces alguna otra herramienta o te gustaría que profundizáramos en otra temática, háznosla llegar a través de nuestras redes sociales o en el formulario de contacto.

Desde sus orígenes el movimiento de datos abiertos se ha centrado fundamentalmente en el impulso de la apertura de los datos y en el fomento de su reutilización. El objetivo que ha articulado la mayoría de las iniciativas, tanto públicas como privadas, ha sido el de vencer los obstáculos para publicar catálogos de datos cada vez más completos y asegurar que la información del sector público estuviera disponible para que la ciudadanía, las empresas, los investigadores y el propio sector público pudieran crear valor económico y social.

Sin embargo, a medida que hemos ido dando pasos hacia una economía cada vez más dependiente de los datos y, más recientemente, de la inteligencia artificial -y en un futuro próximo de las posibilidades que nos traen los agentes autónomos a través de la inteligencia artificial agéntica-, las prioridades han ido cambiando y el foco ha ido girando hacia cuestiones como la mejora de la calidad de los datos publicados.

Ya no es suficiente con que los conjuntos de datos estén publicados en un portal de datos abiertos cumpliendo buenas prácticas, ni tan siquiera con que el dato cumpla unos estándares de calidad en el momento de su publicación. También es necesario que esta publicación de los conjuntos de datos cumpla con unos niveles de servicio que transformen la mera puesta a disposición en un compromiso operativo que mitigue las incertidumbres que, a menudo, obstaculizan la reutilización.

Cuando un desarrollador integra una API de datos de transporte en tiempo real en su app de movilidad, o cuando un científico de datos trabaja en un modelo de IA con datos climáticos históricos está asumiendo un riesgo si no tiene certeza sobre las condiciones en las que los datos estarán disponibles. Si en un momento dado los datos publicados dejan de estar disponibles porque cambia el formato sin previo aviso, porque el tiempo de respuesta se dispara o por cualquier otra razón, los procesos automatizados fallan y la cadena de suministro de datos se rompe, provocando fallos en cascada en todos los sistemas dependientes.

En este contexto, la adopción de acuerdos de nivel de servicio (ANS) también conocidos por su terminología en inglés, service level agreements (SLA), podrían ser el siguiente paso para que portales de datos abiertos evolucionen desde el habitual modelo “best effort” hasta convertirse en infraestructuras digitales críticas, fiables y robustas.

¿Qué son un ANS o SLA y un contrato de datos en el contexto de los datos abiertos?

En el contexto de la ingeniería de fiabilidad (site reliability engineering o SRE), un ANS es un contrato negociado entre un proveedor de servicios y sus clientes con objeto de fijar el nivel de calidad del servicio prestado. Es, por tanto, una herramienta que ayuda a ambas partes a llegar a un consenso en aspectos tales como el tiempo de respuesta, la disponibilidad horaria o la documentación disponible.

En un portal de datos abiertos, donde a menudo no existe una contraprestación económica directa, un ANS podría ayudar a responder preguntas como:

• ¿Cuánto tiempo estará disponible el portal y sus API?
• ¿Qué tiempos de respuesta podemos esperar?
• ¿Con qué frecuencia se actualizarán los conjuntos de datos?
• ¿Cómo se gestionan los cambios en metadatos, enlaces y formatos?
• ¿Cómo se gestionarán incidencias, cambios y avisos a la comunidad?

Adicionalmente, en esta transición hacia una mayor madurez operativa surge el concepto, aún inmaduro, del contrato de datos (data contract). Si el ANS es un acuerdo que define las expectativas de nivel de servicio, el contrato de datos es una implementación que formaliza este compromiso. Un contrato de datos no solo especificaría el esquema y el formato, sino que actuaría como una salvaguarda: si una actualización del sistema intenta introducir un cambio que rompa la estructura prometida o que degrade la calidad del dato, el contrato de datos permite detectar y bloquear dicha anomalía antes de que afecte a los usuarios finales.

INSPIRE como punto de partida: disponibilidad, rendimiento y capacidad

La infraestructura de la Unión Europea para la información espacial (INSPIRE) ha establecido uno de los marcos más rigurosos del mundo en cuanto a calidad de servicio para datos geoespaciales. La Directiva 2007/2/CE, conocida como INSPIRE, actualmente en su versión 5.0, incluye algunas obligaciones técnicas que podrían servir como referencia para cualquier portal de datos modernos. En particular el Reglamento (CE) nº 976/2009 establece criterios que bien podrían servir como patrón para cualquier estrategia de publicación de datos de alto valor:

• Disponibilidad: la infraestructura debe estar disponible el 99% del tiempo durante el horario de funcionamiento normal.
• Rendimiento: para un servicio de visualización la respuesta inicial debe llegar en menos de 3 segundos.
• Capacidad: para un servicio de localización el mínimo número de peticiones simultáneas servidas con rendimiento garantizado debe ser de 30 por segundo.

Para ayudar al cumplimiento de estos estándares de servicio, la Comisión Europea ofrece herramientas como el INSPIRE Reference Validator. Esta herramienta ayuda no solo a verificar la interoperabilidad sintáctica (que el XML o GML esté bien formado), sino también a asegurar que los servicios de red cumplen con las especificaciones técnicas que permiten medir esos ANS.

En este punto, los exigentes ANS de la infraestructura de datos espaciales europea nos hacen preguntarnos si no deberíamos aspirar a lo mismo para datos críticos de salud, energía o movilidad o para cualquier otro conjunto de datos de alto valor.

Qué podría cubrir un ANS en una plataforma de datos abiertos

Cuando hablamos de conjuntos de datos abiertos en sentido amplio, la disponibilidad del portal es una condición necesaria, pero no suficiente. Muchas incidencias que afectan a la comunidad de reutilizadores no son caídas completas del portal, sino errores más sutiles como enlaces rotos, conjuntos de datos que no se actualizan con la periodicidad indicada, formatos inconsistentes entre versiones, metadatos incompletos o cambios silenciosos en el comportamiento de las API o en los nombres de las columnas de los conjuntos de datos.

Por ello, convendría complementar los ANS propios de la infraestructura del portal con ANS de “salud del dato” que pueden basarse en marcos de referencia ya consolidados como:

• Modelos de calidad como ISO/IEC 25012, que permite desglosar la calidad del dato en dimensiones medibles como la exactitud (que el dato represente la realidad), la completitud (que no falten valores necesarios) y la consistencia (que no haya contradicciones entre tablas o formatos) y convertirlas en requisitos medibles.
• Principios FAIR, siglas de Findable (Localizable), Accessible (Accesible), Interoperable (Interoperable), y Reusable (Reutilizable). Estos principios enfatizan que los activos digitales no solo deben estar disponibles, sino que deben ser localizables mediante identificadores persistentes, accesibles bajo protocolos claros, interoperables mediante el uso de vocabularios estándar y reutilizables gracias a licencias claras y procedencia documentada. Los principios FAIR se pueden poner en práctica midiendo de forma sistemática la calidad de los metadatos que hacen posible la localización, el acceso y la interoperabilidad. Por ejemplo, el servicio Metadata Quality Assurance (MQA) de data.europa.eu ayuda a hacer una evaluación automática de los metadatos de los catálogos, a calcular métricas y a ofrecer recomendaciones de mejora.

Para convertir en operativos estos conceptos, podemos centrarnos en cuatro ejemplos donde establecer compromisos de servicio específicos aportaría un valor diferencial:

• Conformidad y vigencia del catálogo: el ANS podría garantizar que los metadatos estén siempre alineados con los datos que describen. Un compromiso de conformidad aseguraría que el portal se somete a validaciones periódicas (siguiendo especificaciones como DCAT-AP-ES o HealthDCAT-AP) para evitar que la documentación se volviese obsoleta respecto al recurso real.
• Estabilidad del esquema y versionado: uno de los mayores enemigos de la reutilización automatizada es el "cambio silencioso". Si una columna cambia de nombre o un tipo de dato varía, los flujos de ingesta de datos fallarán inmediatamente. Un compromiso de nivel de servicio podría incluir una política de versionado. Esto implicaría que cualquier cambio que rompiese la compatibilidad se anunciase con una antelación mínima y, preferiblemente, mantuviese la versión anterior en paralelo durante un tiempo prudencial.
• Frescura y frecuencia de actualización: no resulta infrecuente encontrar conjuntos de datos etiquetados como de actualización diaria pero cuya última modificación real fue hace meses. Una buena práctica podría ser la definición de indicadores de latencia de publicación. Un posible ANS establecería el valor del tiempo medio entre actualizaciones y contaría con sistemas de alerta que notificasen automáticamente si un dato no se ha refrescado según la frecuencia declarada en su metadato.
• Tasa de éxito: en el mundo de las API de datos, no es suficiente con recibir un código HTTP 200 (OK) para determinar si la respuesta es válida. Si la respuesta es, por ejemplo, un JSON sin contenido, el servicio no es útil. El nivel de servicio tendría que medir la tasa de respuestas exitosas y con contenido válido, asegurando que el endpoint no solo responde, sino que entrega la información esperada.

Un primer paso, SLA, SLO y SLI: medir antes de comprometer

Dado que establecer este tipo de compromisos es realmente complejo, una posible estrategia para pasar a la acción de forma gradual es adoptar un enfoque pragmático basado en las mejores prácticas de la industria. Por ejemplo, en la ingeniería de fiabilidad, se propone una jerarquía de tres conceptos que ayuda a evitar compromisos poco realistas:

• Indicador de Nivel de Servicio (SLI): es el indicador medible y cuantitativo. Representa la realidad técnica en un momento dado. Ejemplos de SLI en datos abiertos podrían ser el "porcentaje de peticiones exitosas a la API", la "latencia p95" (el tiempo de respuesta del 95% de las solicitudes) o el "porcentaje de enlaces de descarga que no devuelven error".
• Objetivo de Nivel de Servicio (SLO): es el objetivo interno que se marca sobre ese indicador. Por ejemplo: "queremos que el 99,5% de las descargas funcionen correctamente" o "la latencia p95 debe ser inferior a 800 ms". Es la meta que guía el trabajo del equipo técnico.
• Acuerdo de Nivel de Servicio (ANS o SLA): es el compromiso público y formal sobre esos objetivos. Es la promesa que el portal de datos hace a su comunidad de reutilizadores y que incluye, idealmente, los canales de comunicación y los protocolos de actuación en caso de incumplimiento.

Esta distinción es especialmente valiosa en el ecosistema de los datos abiertos debido a la naturaleza híbrida de un servicio en el que no solo se opera una infraestructura, sino que se gestiona el ciclo de vida de los datos.

En muchos casos, el primer paso podría ser no tanto publicar un ANS ambicioso de inmediato, sino empezar por definir sus SLI y observar sus SLO. Una vez que la medición estuviese automatizada y los niveles de servicio se estabilizasen y fuesen predecibles, sería el momento de convertirlos en un compromiso público (SLA).

En última instancia, la implementación de niveles de servicio en los datos abiertos podría tener un efecto multiplicador. No solo reduciría la fricción técnica para los desarrolladores y mejoraría la tasa de reutilización, sino que facilitaría la integración de los datos públicos en sistemas de IA y agentes autónomos. Los nuevos usos como la evaluación de sistemas de Inteligencia Artificial generativa, la generación y validación de conjuntos de datos sintéticos o incluso la propia mejora de la calidad de los datos abiertos se verían muy beneficiados.

Establecer un SLA de datos sería, por encima de todo, un potente mensaje: significaría que el sector público no solo publica los datos como un acto administrativo, sino que los opera como un servicio digital de alta disponibilidad, fiable, predecible y, en definitiva, preparado para los retos de la economía del dato.

Introducción

Cada año se producen en España decenas de miles de accidentes, en los que miles de personas resultan heridas de diversa consideración, y que ocurren en circunstancias muy diversas, tanto de tipo de vía, como por el tipo de accidente.

Muchas de las estadísticas relacionadas con estos parámetros están recogidas en las bases de datos de la Dirección General de Tráfico (DGT) y algunas de ellas en el catálogo albergado en datos.gob.es.  

En este ejercicio examinaremos el contenido de la base de datos de siniestralidad de la DGT para el año 2024 con el fin de realizar una serie de visualizaciones básicas que nos permitan ver de forma rápida e intuitiva cuáles son los hechos a destacar respecto a la incidencia de accidentes y sus consecuencias en ese año.  

Para ello vamos a desarrollar código en Python que nos permita la lectura y cálculo de métricas básicas respecto al número total de víctimas, las particularidades de las infraestructuras así como las diferentes casuísticas de los accidentes. Y una vez tengamos disponibles esos datos, los visualizaremos utilizando la librería de Javascript D3.js, que nos permite tanto la representación de datos en su forma más tradicional como en diseños más contemporáneos, habituales en la prensa, favoreciendo así una narrativa fluída en estilo y coherente en contenido. 

En el entorno de Python utilizaremos librerías de uso común y frecuente como son Numpy, para el cálculo básico - sumas, máximos y mínimos-, y Pandas, para estructurar los datos de forma intuitiva, facilitando tanto su organización como su transformación. Igualmente trabajaremos con Datetime, tanto para el formateo de los datos de entrada en tipos de fecha estándares dentro del mundo de la programación en Python, como para agregar los datos de forma fácil e intuitiva. De esta forma aprenderemos a abrir cualquier tipo de fichero de datos en formato .CSV, a estructurarlo de forma ordenada y a realizar transformaciones y operaciones básicas de forma sencilla.  

En el entorno de Javascript desarrollaremos notebooks en D3.js gracias al uso de Observable, una iniciativa abierta y gratuita, para poder ejecutar código de Javascript directamente en un interfaz web, y sin tener que recurrir a servidores locales o complejas instalaciones. En diferentes notebooks crearemos visualizaciones clásicas -como las series temporales en ejes cartesianos o mapas- junto con otras propuestas tales como distribuciones de burbujas o elementos apilados por categorías. 

En la Figura 1 se pueden ver las principales etapas de este ejercicio, desde la lectura de los datos dentro del fichero de la DGT, hasta las operaciones y las variables de salida en formato JSON, que nos servirán a su vez en un entorno Javascript para poder desarrollar las visualizaciones en D3.js.

Figura 1. Pasos en los cuales se estructura este ejercicio, con punto de partida en la base de datos de la DGT, el procesado y manipulación de esos datos en Python, la creación de ficheros de salida en formato JSON y su uso en Javascript para visualizar los resultados. 

El acceso al repositorio de Github, el notebook de Google Colab y los notebooks de Observable se pueden realizar a través de los siguientes enlaces:

Accede al repositorio del laboratorio de datos en GitHub

Accede al notebook de GoogleColab

Accede a los notebooks de Observable

Proceso de Desarrollo 

1. Lectura del fichero de datos 

El primer paso será leer el fichero de la DGT que contiene todos los registros de accidentes del año 2024. Este paso nos permitirá identificar los campos de interés y sobre todo en qué formato se encuentran. Podremos identificar si se precisa de alguna transformación sobre todo en la información de la fecha, tal y como está estructurada en el fichero de origen.  

Igualmente veremos cómo traducir los códigos de muchas de las categorías que nos ofrece la DGT, de modo que podamos hacer una interpretación real más allá de los números de categorías como tipo de accidente, tipo de vía o titularidad de la vía.  

Una vez entendemos la estructura y contenido de los datos podemos empezar a operar con ellos.  

2. Cálculo de métricas 

La librería Pandas de Python nos permite operar con las diferentes columnas de datos y realizar cálculos básicos que serán suficientemente representativos para entender mínimamente la casuística de los accidentes en las carreteras españolas.  

En este apartado se realizarán tres tipos de cálculos.  

• El primero de ellos será el cálculo del número total de víctimas por hora del día para cada uno de los días de la semana. La base de datos de la DGT viene estructurada por día de la semana, de forma que utilizaremos también esa escala temporal para representar los datos en una serie. Cabe hacer notar que por víctima se considera toda aquella persona que ha fallecido o que sea diagnosticada como herida grave o leve.
• El segundo cálculo será la suma total de accidentes para diferentes categorías, tales como la titularidad de la vía, el tipo de accidente o el tipo de vía. Esto nos permitirá ver cuáles son las condiciones en las cuales los accidentes son más frecuentes.
• El tercer cálculo será el de número de accidentes por municipio. En este caso realizaremos el cálculo restringido a la provincia de Valencia como ejemplo, y que sería aplicable a cualquier provincia o municipio de nuestro interés. En este caso observaremos las diferencias entre los núcleos urbanos y no urbanos, así como aquellos municipios por los que pasan las principales vías de comunicación.

3. Diseño de las visualizaciones  

Una vez hemos calculado las métricas de interés, desarrollaremos cinco ejercicios de visualización en D3.js. Para ello exportaremos en formato JSON el resultado de las métricas y crearemos notebooks en Observable. En concreto realizamos las siguientes visualizaciones:  

• Serie temporal con el número total de víctimas en cada hora y día de la semana, con un menú desplegable interactivo para seleccionar el día de la semana de interés. A mayores de la curva que describe el número de víctimas dibujaremos sobre el fondo de la gráfica la incertidumbre de todos los días de la semana, de forma que la serie temporal diaria queda enmarcada en el contexto de toda la semana como referencia.
• Mapa de la provincia de Valencia con el número total de accidentes por municipio.
• Diagrama de burbujas, con las diferentes magnitudes de los diferentes tipos de accidentes con el número total de accidentes en cada caso escrita de forma detallada.
• Diagrama de puntos apilados, donde acumulamos círculos o cualquier otra forma geométrica para las diferentes titularidades de la vía y su número total de accidentes dentro del marco de cada titularidad.
• Diagrama de sierra, con la altura de cada montaña correspondiente al número de accidentes en cada tipo de vía en escala logarítmica. 

Visualización de las métricas  

El resultado de este ejercicio se podrá ver de forma gráfica y explícita en forma de visualizaciones realizadas para el formato web y accesibles desde una interfaz también web, tanto para su desarrollo como para su posterior publicación.  Todo el conjunto de visualizaciones se encuentra en el repositorio de Datos.gob.es en Observable: 

Accede a los notebooks de Observable

En la Figura 2 tenemos el resultado de la serie temporal del total de víctimas respecto a la hora del día para diferentes días de la semana. La serie temporal está enmarcada dentro de la incertidumbre del total de días de la semana, para dar una idea del margen de variabilidad que podemos tener dependiendo de la hora del día.  

Figura 2. Serie temporal del total de víctimas en accidentes por hora del día para todos los días de la semana en 2024. En el fondo en color azul claro se indica la incertidumbre asociada a todos los días de la semana como contexto, con menú desplegable para seleccionar el día de la semana.

En la Figura 3 podemos observar el mapa de la provincia de Valencia con una intensidad de color proporcional al número de accidentes en cada municipio. Aquellos municipios en los cuales no se han registrado accidentes aparecen en color blanco. De forma intuitiva se puede adivinar el trazado de las principales carreteras que atraviesan la provincia, tanto la carretera hacia el este de la ciudad de Valencia en dirección Madrid como la carretera del interior hacia el sur de la ciudad en dirección a Alicante.  

Figura 3. Mapa del número de accidentes por municipio en la provincia de Valencia en 2024. 

En la Figura 4 vemos una forma geométrica, el círculo, asociada a los tipos de accidente, con el detalle del número de accidentes asociada a cada categoría. En este tipo de visualización emerge de forma natural aquellos accidentes más frecuentes en torno al centro del diagrama, mientras que aquellos minoritarios o residuales ocupan el perímetro del diagrama para dar igualmente una forma redonda al conjunto de formas.

Figura 4. Diagrama de burbujas del número de accidentes por tipo de accidente en 2024. 

En la Figura 5 se puede contemplar el tradicional diagrama de barras pero esta vez descompuesto en unidades más pequeñas, para afinar la cantidad de accidentes asociada a la titularidad de la vía donde han sucedido. Este tipo de diagramas permite discernir pequeñas diferencias entre magnitudes parecidas, preservando el mensaje general que obtenemos de un cálculo de estas características.  

Figura 5. Diagrama de barras con discretización de puntos para el número de accidentes por titularidad de la vía en el 2024. 

En la Figura 6 creamos una serie de formas geométricas que replican una cordillera o sierra donde los diferentes picos apuntan a la diferencia de número de accidentes por tipo de vía. Dada la diferencia en órdenes de magnitud establecemos una escala logarítmica, que permita comparar en el mismo diagrama diferentes casuísticas. 

Figura 6. Diagrama en cordillera para los diferentes órdenes de magnitud del número de accidentes por tipo de vía en el 2024. 

Lecciones aprendidas 

A través de estos pasos aprenderemos toda una serie de habilidades transversales que nos permiten trabajar con aquellos conjunto de datos que se nos presentan en formato CSV en columnas, un formato muy popular para el cual podremos realizar tanto su análisis como su visualización. Estas lecciones son en concreto:  

• Universalidad de lectura y estructuración de datos: el uso de herramientas como Python, con sus librerías Numpy y Pandas, permiten acceder a los datos en detalle y estructurarlos de forma ordenada e intuitiva con pocas líneas de código.
• Cálculos sencillos en Pandas: la propia librería de Python permite cálculos sencillos pero esenciales para la interpretación preliminar de resultados.
• Formato Datetime: a través de esta librería de Python podemos familiarizarnos con el estándar del formato de fecha, y así realizar todo tipo de transformaciones, filtros y selecciones que más nos interesen en cualquier intervalo temporal.
• Formato JSON: una vez que decidimos dar espacio a nuestras visualizaciones en la web, aprender la estructura y uso del formato JSON es de gran utilidad dado su amplio uso en todo tipo de aplicaciones y arquitecturas web.
• Espectro de posibilidades de D3.js: esta librería de Javascript nos permite explorar de lo más tradicional y conservador a lo más creativo gracias a sus principios basados en las formas más básicas, sin plantillas, templates o diagramas predefinidos. 

Conclusiones y próximos pasos 

Hemos aprendido a leer y a estructurar datos según los estándares de los formatos más utilizados en el mundo del análisis y visualización. Este ejercicio también sirve como módulo introductorio al mundo de D3.js, una herramienta muy versátil, vigente y popular dentro del mundo del storytelling y la visualización de datos a todos los niveles.  

Para poder avanzar en este ejercicio se recomienda:  

• Para los analistas y desarrolladores, se puede prescindir de la librería Pandas y estructurar los datos con objetos más elementales de Python como arrays y matrices, buscando qué funciones y qué operadores permiten realizar las mismas tareas que hace Pandas pero de una forma más fundamental, sobre todo si pensamos en entornos de producción para los cuales necesitamos el menor número de librerías posibles para aligerar la aplicación.
• Para los creadores de visualizaciones, la información sobre los municipios puede proyectarse igualmente sobre bases cartográficas ya existentes como OpenStreetMap y de esta forma vincular la incidencia de accidentes a características orográficas o infraestructuras ya reflejadas en esas bases cartográficas. Para las magnitudes de los números de accidentes se pueden explorar diagramas de tipo Treemap o diagramas de Voronoi y ver si transmiten el mismo mensaje que los que presentamos en este ejercicio.   

Ámbitos de aplicación 

Los pasos descritos en este ejercicio pueden pasar a formar parte de cualquier caja de herramientas de uso habitual para los siguientes perfiles:  

• Analistas de datos: aquí se encuentran los pasos básicos para la descripción de un fichero de datos en formato CSV y los cálculos básicos a realizar tanto en el campo de la fecha como de operaciones entre variables de diferentes columnas. Estas herramientas pueden servir para introducirse en el mundo del análisis de datos y ayuda en esos primeros pasos a la hora de enfrentarse a un dataset.
• Científicos y personal investigador: la universalidad de las herramientas aquí descritas aplican a una gran variedad de origen de datos, como el que se experimenta en las ciencias experimentales y de observaciones o medidas de todo tipo. Estas herramientas permiten un análisis rápido a la vez que riguroso sin importar el campo de conocimiento en el que se trabaje.
• Desarrolladores web: la exportación de datos en formato JSON así como el código en Javascript que se ofrece en los notebooks de Observable son fácilmente integrables en todo tipo de entornos (Svelte, React, Angular, Vue) y permite la creación de visualizaciones en una web de forma sencilla e intuitiva.
• Periodistas: abarcar todo el proceso de vida de un fichero de datos, desde su lectura a su visualización, otorga al periodista o investigador independencia a la hora de evaluar e interpretar los datos por sí mismo sin depender de recursos técnicos ajenos. La creación del mapa por municipios abre la puerta a utilizar cualquier otro dato similar, como por ejemplo procesos electorales, con el mismo formato de salida para mostrar variabilidad geográfica respecto a cualquier tipo de magnitud.
• Diseñadores Gráficos: el manejo de herramientas de visualización con un amplio grado de libertad permite a los diseñadores cultivar toda su creatividad dentro del rigor y la exactitud que los datos necesitan. 

La Comisión Europea ha presentado recientemente el documento en el que se establece una nueva Estrategia de la Unión en el ámbito de los datos. Entre otros ambiciosos objetivos, con esta iniciativa se pretende hacer frente a un reto trascendental en la era de la inteligencia artificial generativa: la insuficiente disponibilidad de datos en las condiciones adecuadas.

Desde la anterior Estrategia de 2020 hemos asistido a un importante avance normativo con el que se pretendía ir más allá de la regulación de 2019 sobre datos abiertos y reutilización de la información del sector público. 

En concreto, por una parte, la Data Governance Act sirvió para impulsar una serie de medidas que tendían a facilitar el uso de los datos generados por el sector público en aquellos supuestos donde se vieran afectados otros derechos e intereses jurídicos —datos personales, propiedad intelectual. 

Por otra, a través de la Data Act se avanzó, sobre todo, en la línea de impulsar el acceso a datos en poder de sujetos privados atendiendo a las singularidades del entorno digital.

El necesario cambio de enfoque en la regulación sobre acceso a datos. 

A pesar de este importante esfuerzo regulatorio, por parte de la Comisión Europea se ha detectado una infrautilización de los datos que, además, con frecuencia se encuentran fragmentados en cuanto a las condiciones de su accesibilidad. Ello se debe, en gran parte, a la existencia de una importante diversidad regulatoria. Por ello se requieren medidas que faciliten la simplificación y la racionalización del marco normativo europeo sobre datos. 

En concreto, se ha constatado que existe una fragmentación regulatoria que genera inseguridad jurídica y costes de cumplimiento desproporcionados debido a la complejidad del propio marco normativo aplicable. En concreto, el solapamiento entre el Reglamento General de Protección de Datos (RGPD), la Data Governance Act, la Data Act, la Directiva de datos abiertos y, asimismo, la existencia de regulaciones sectoriales específicas para algunos ámbitos concretos ha generado un complejo entramado normativo al que resulta arduo enfrentarse, sobre todo si pensamos en la competitividad de pequeñas y medianas empresas. Cada una de estas normas fue concebida para hacer frente a retos específicos que fueron abordados de manera sucesiva, por lo que resulta necesaria una visión de conjunto más coherente que resuelva posibles incoherencias y, en última instancia, facilite su aplicación práctica.

En este sentido, la Estrategia propone impulsar un nuevo instrumento legislativo —la propuesta de Reglamento denominado Ómnibus Digital—, con el que se pretende consolidar en una única norma las reglas relativas al mercado único europeo en el ámbito de los datos. En concreto, con esta iniciativa:

• Se fusionan las previsiones de la Data Governance Act en la regulación de la Data Act, eliminando así duplicidades.
• Se deroga el Reglamento sobre datos no personales, cuyas funciones se cubren igualmente a través de la Data Act;
• Se integran las normas sobre datos del sector público en la Data Act, ya que hasta ahora estaban incluidas tanto en la Directiva de 2019 como en la Data Governance Act. 

Con esta regulación se consolida, por tanto, el protagonismo de la Data Act como normal general de referencia en la materia. Asimismo, se refuerza la claridad y la precisión de sus previsiones, con el objetivo de facilitar su función como instrumento normativo principal a través del cual se pretende impulsar la accesibilidad de los datos en el mercado digital europeo.

Modificaciones en materia de protección de datos personales

La propuesta Ómnibus Digital también incluye importantes novedades por lo que se refiere a la normativa sobre protección de datos de carácter personal, modificándose varios preceptos del Reglamento (UE) 1016/679 del Parlamento Europeo y del Consejo de 27 de abril de 2016, relativo a la protección de las personas físicas en lo que respecta al tratamiento de datos personales.

Para que se puedan utilizar los datos personales —esto es, cualquier información referida a una persona física identificada o identificable— es necesario que concurra alguna de las circunstancias a que se refiere el artículo 6 del citado Reglamento, entre las que se encuentra el consentimiento del titular o la existencia de un interés legítimo por parte de quien vaya a tratar los datos.

El interés legítimo permite tratar datos personales cuando es necesario para un fin válido (mejorar un servicio, prevenir fraudes, etc.) y no afecta negativamente a los derechos de la persona.

Fuente: Guía sobre interés legítimo. ISMS Forum y Data Privacy Institute. Disponible aquí: guiaintereslegitimo1637794373.pdf

Respecto a la posibilidad de acudir al interés legítimo como base jurídica para entrenar las herramientas de inteligencia artificial, la actual regulación permite tratar datos personales siempre que no prevalezcan los derechos de los interesados titulares de dichos datos. 

Sin embargo, dada la generalidad del concepto “interés legítimo”, a la hora de decidir cuándo se pueden utilizar los datos personales al amparo de esta cláusula no siempre existirá una certeza absoluta, habrá que analizar caso por caso: en concreto, será necesario llevar a cabo una actividad de ponderación de los bienes jurídicos en conflicto y, por tanto, su aplicación puede generar dudas razonables en muchos supuestos.

Aunque el Comité Europeo de Protección de Datos ha intentado establecer algunas pautas para concretar la aplicación del interés legítimo, lo cierto es que el uso de conceptos jurídicos abiertos e indeterminados no siempre permitirá llegar a respuestas claras y definitivas. Para facilitar la concreción de esta expresión en cada supuesto, la Estrategia alude como criterio a tener en cuenta el beneficio potencial que puede suponer el tratamiento para el propio titular de los datos y para la sociedad en general. Asimismo, dado que no será necesario el consentimiento del titular de los datos —y por tanto, no sería aplicable su revocación—, refuerza el derecho de oposición por parte del titular a que sus datos sean tratados y, sobre todo, garantiza una mayor transparencia respecto de las condiciones en que se van a tratar los datos. De este modo, al reforzar la posición jurídica del titular y aludir a dicho beneficio potencial, la Estrategia pretende facilitar la utilización del interés legítimo como base jurídica que permita utilizar los datos personales sin consentimiento del titular, pero con garantías adecuadas.

Otra de las principales medidas en materia de protección de datos se refiere a la distinción entre datos anónimos y seudonimizados. El RGPD define la seudonimización como un tratamiento de datos que, hasta ahora, hacía que ya no pudieran atribuirse a un interesado sin recurrir a información adicional, que se encuentra separada. Eso sí, los datos seudonimizados siguen siendo datos personales y, por tanto, sometidos a dicha regulación. En cambio, los datos anónimos no guardan relación con personas identificadas o identificables y, por tanto, su uso no estaría sometido al RGPD. En consecuencia, para saber si hablamos de datos anónimos o seudonimizados resulta esencial concretar si existe una “probabilidad razonable” de identificación del titular de los datos.

Ahora bien, las tecnologías actualmente disponibles multiplican el riesgo de reidentificación del titular de los datos, lo que afecta directamente a lo que podría considerarse razonable, generando una incertidumbre que incide negativamente en la innovación tecnológica. Por esta razón, la propuesta Ómnibus Digital, en la línea ya manifestada por el Tribunal de Justicia de la Unión Europea, pretende establecer las condiciones en las cuales los datos seudonimizados ya no se podrían considerar datos de carácter personal, facilitando así su uso. A tal efecto habilita a la Comisión Europea para que, a través de actos de implementación, pueda concretar tales circunstancias, en concreto teniendo en cuenta el estado de la técnica y, asimismo, ofreciendo criterios que permitan evaluar el riesgo de reidentificación en cada concreto supuesto. 

La ampliación de los conjuntos de datos de alto valor

La Estrategia pretende también ampliar el catálogo de Datos de Alto Valor (HVD) que se contemplan en el Reglamento de Ejecución UE 2023/138. Se trata de conjuntos de datos con potencial excepcional para generar beneficios sociales, económicos y ambientales, ya que son datos de alta calidad, estructurados y fiables que están accesibles en condiciones técnicas, organizativas y semánticas muy favorables para su tratamiento automatizado. Actualmente se incluyen seis categorías (geoespacial, observación de la Tierra y medio ambiente, meteorología, estadística, empresas y movilidad), a las que se añadirían por parte de la Comisión, entre otros conjuntos, datos legales, judiciales y administrativos.

Oportunidad y reto

La Estrategia Europea de Datos representa un giro paradigmático ciertamente relevante: no sólo se trata de promover marcos normativos que faciliten en el plano teórico la accesibilidad de los datos sino, sobre todo, de hacerlos funcionar en su aplicación práctica, impulsando de esta manera las condiciones necesarias de seguridad jurídica que permitan dinamizar una economía de datos competitiva e innovadora.

Para ello resulta imprescindible, por una parte, evaluar la incidencia real de las medidas que se proponen a través del Ómnibus Digital y, por otra, ofrecer a las pequeñas y medianas empresas instrumentos jurídicos adecuados —guías prácticas, servicios de asesoramiento idóneos, cláusulas contractuales tipo…— para hacer frente al reto que para ellas supone el cumplimiento normativo en un contexto de enorme complejidad. Precisamente, esta dificultad requiere, por parte de las autoridades de control y, en general, de las entidades públicas, adoptar modelos de gobernanza de los datos avanzados y flexibles que se adapten a las singularidades que plantea la inteligencia artificial, sin que por ello se vean afectadas las garantías jurídicas.

Contenido elaborado por Julián Valero, catedrático de la Universidad de Murcia y Coordinador del Grupo de Investigación “Innovación, Derecho y Tecnología” (iDerTec). Los contenidos y los puntos de vista reflejados en esta publicación son responsabilidad exclusiva de su autorR

Visor web que muestra en un único mapa los despliegues de fibra de todos los programas PEBA y UNICO, a partir de los datos disponibles en abierto. Cada área tiene el color de fondo del operador adjudicado, y el borde es de un color diferente para cada programa. Para el caso del plan PEBA 2013-2019, como los despliegues se asignan a entidades singulares de población, se muestra un marcador con la ubicación obtenida del CNIG. Además, cuando no se hace zoom sobre el mapa, se muestra un mapa de calor en el que se puede ver la distribución por zonas de los despliegues.

Esta visualización permite evitar tener que comparar en diferentes visores cartográficos si lo que nos interesa es ver qué operadores llegan a qué zonas o simplemente tener una visión global de qué despliegues quedan pendientes en mi zona, y además permite consultar aspectos como la fecha de finalización actualizada, que antes solamente estaban disponibles en los diferentes Excel de cada programa. También creo que podría ser útil de cara a análisis de cómo se reparten las zonas entre los diferentes programas (por ejemplo, si una zona cubierta en el UNICO 2021 luego tiene zonas cercanas en UNICO 2022 cubiertas por ejemplo por otro operador), o incluso posibles solapes (por ejemplo debido a zonas que quedaron sin ejecutar en anteriores programas)

¿Sabías que España creó en 2023 la primera agencia estatal dedicada específicamente a la supervisión de la inteligencia artificial (IA)? Anticipándose incluso al Reglamento Europeo en esta materia, la Agencia Española de Supervisión de Inteligencia Artificial (AESIA) nació con el objetivo de garantizar el uso ético y seguro de la IA, fomentando un desarrollo tecnológico responsable.

Entre sus principales funciones está asegurar que tanto entidades públicas como privadas cumplan con la normativa vigente. Para ello promueve buenas prácticas y asesora sobre el cumplimiento del marco regulatorio europeo, motivo por el cual recientemente ha publicado una serie de guías para asegurar la aplicación consistente de la regulación europea de IA.

En este post profundizaremos en qué es la AESIA y conoceremos detalles relevantes del contenido de las guías.

¿Qué es la AESIA y por qué es clave para el ecosistema de datos?

La AESIA nace en el marco del Eje 3 de la Estrategia Española de IA. Su creación responde a la necesidad de contar con una autoridad independiente que no solo supervise, sino que oriente el despliegue de sistemas algorítmicos en nuestra sociedad.

A diferencia de otros organismos puramente sancionadores, la AESIA está diseñada como un Think & Do Tank de inteligencia, es decir, una organización que investiga y propone soluciones. Su utilidad práctica se divide en tres vertientes:

1. Seguridad jurídica: proporciona marcos claros para que las empresas, especialmente las pymes, sepan a qué atenerse al innovar.
2. Referente internacional: actúa como el interlocutor español ante la Comisión Europea, asegurando que la voz de nuestro ecosistema tecnológico sea escuchada en la elaboración de estándares europeos.
3. Confianza ciudadana: garantiza que los sistemas de IA utilizados en servicios públicos o áreas críticas respeten los derechos fundamentales, evitando sesgos y promoviendo la transparencia.

Desde datos.gob.es, siempre hemos defendido que el valor de los datos reside en su calidad y accesibilidad. La AESIA complementa esta visión asegurando que, una vez que los datos se transforman en modelos de IA, su uso sea responsable. Por ello, estas guías son una extensión natural de los recursos que publicamos habitualmente sobre gobernanza y apertura de datos.

Recursos para el uso de la IA: guías y checklist

La AESIA ha publicado recientemente unos materiales de apoyo a la implementación y el cumplimiento de la normativa europea de Inteligencia Artificial y sus obligaciones aplicables. Aunque no tienen carácter vinculante ni sustituyen ni desarrollan la normativa vigente, proporcionan recomendaciones prácticas alineadas con los requisitos regulatorios a la espera de que se aprueben las normas armonizadas de aplicación para todos los Estados miembros.

Son el resultado directo del piloto español de Sandbox Regulatorio de IA. Este entorno de pruebas permitió a desarrolladores y autoridades colaborar en un espacio controlado para entender cómo aplicar la normativa europea en casos de uso reales.

Es fundamental destacar que estos documentos se publican sin perjuicio de las guías técnicas que la Comisión Europea está elaborando. De hecho, España está sirviendo de "laboratorio" para Europa: las lecciones aprendidas aquí proporcionarán una base sólida al grupo de trabajo de la Comisión, asegurando una aplicación consistente de la regulación en todos los Estados miembros.

Las guías están diseñadas para ser una hoja de ruta completa, desde la concepción del sistema hasta su vigilancia una vez está en el mercado.

Figura 1. Guías de AESIA para cumplir con la regulación. Fuente: Agencia Española de la Supervisión de la IA

• 01. Introductoria al Reglamento de IA: ofrece una visión general sobre las obligaciones, los plazos de aplicación y los roles (proveedores, desplegadores, etc.). Es el punto de partida esencial para cualquier organización que desarrolle o despliegue sistemas de IA.
• 02. Práctica y ejemplos: aterriza los conceptos jurídicos en casos de uso cotidianos (por ejemplo, ¿es mi sistema de selección de personal una IA de alto riesgo?). Incluye árboles de decisión y un glosario de términos clave del artículo 3 del Reglamento, ayudando a determinar si un sistema específico está regulado, qué nivel de riesgo tiene y qué obligaciones son aplicables.
• 03. Evaluación de conformidad: explica los pasos técnicos necesarios para obtener el "sello" que permite comercializar un sistema de IA de alto riesgo, detallando los dos procedimientos posibles según los Anexos VI y VII del Reglamento como valuación basada en control interno o evaluación con intervención de organismo notificado.
• 04. Sistema de gestión de la calidad: define cómo las organizaciones deben estructurar sus procesos internos para mantener estándares constantes. Abarca la estrategia de cumplimiento regulatorio, técnicas y procedimientos de diseño, sistemas de examen y validación, entre otros.
• 05. Gestión de riesgos: es un manual sobre cómo identificar, evaluar y mitigar posibles impactos negativos del sistema durante todo su ciclo de vida.
• 06. Vigilancia humana: detalla los mecanismos para que las decisiones de la IA sean siempre supervisables por personas, evitando la "caja negra" tecnológica. Establece principios como comprensión de capacidades y limitaciones, interpretación de resultados, autoridad para no usar el sistema o anular decisiones.
• 07. Datos y gobernanza de datos: aborda las prácticas necesarias para entrenar, validar y testear modelos de IA asegurando que los conjuntos de datos sean relevantes, representativos, exactos y completos. Cubre procesos de gestión de datos (diseño, recogida, análisis, etiquetado, almacenamiento, etc.), detección y mitigación de sesgos, cumplimiento del Reglamento General de Protección de Datos, linaje de datos y documentación de hipótesis de diseño, siendo de especial interés para la comunidad de datos abiertos y científicos de datos.
• 08. Transparencia: establece cómo informar al usuario de que está interactuando con una IA y cómo explicar el razonamiento detrás de un resultado algorítmico.
• 09. Precisión: define métricas apropiadas según el tipo de sistema para garantizar que el modelo de IA cumple su objetivo.
• 10. Solidez: proporciona orientación técnica sobre cómo garantizar que los sistemas de IA funcionan de manera fiable y consistente en condiciones variables.
• 11. Ciberseguridad: instruye sobre protección contra amenazas específicas del ámbito de IA.
• 12. Registros: define las medidas para cumplir con las obligaciones de registro automático de eventos.
• 13. Vigilancia poscomercialización: documenta los procesos para ejecutar el plan de vigilancia, documentación y análisis de datos sobre el rendimiento del sistema durante toda su vida útil.
• 14. Gestión de incidentes: describe el procedimiento para notificar incidentes graves a las autoridades competentes.
• 15. Documentación técnica: establece la estructura completa que debe incluir la documentación técnica (proceso de desarrollo, datos de entrenamiento/validación/prueba, gestión de riesgos aplicada, rendimiento y métricas, supervisión humana, etc.).
• 16. Manual de checklist de Guías de requisitos: explica cómo utilizar las 13 checklists de autodiagnóstico que permiten realizar evaluación del cumplimiento, identificar brechas, diseñar planes de adaptación y priorizar acciones de mejora.

Todas las guías están disponibles aquí y tienen una estructura modular que se adapta a diferentes niveles de conocimiento y necesidades empresariales.

La herramienta de autodiagnóstico y sus ventajas

En paralelo, la AESIA publica un material que facilita la traducción de requisitos abstractos en preguntas concretas y verificables, proporcionando una herramienta práctica para la evaluación continua del grado de cumplimiento.

Se trata de listas de verificación que permiten a una entidad evaluar su nivel de cumplimiento de forma autónoma.

La utilización de estas checklists proporciona múltiples beneficios a las organizaciones. En primer lugar, facilitan la identificación temprana de brechas de cumplimiento, permitiendo a las organizaciones tomar medidas correctivas antes de la comercialización o puesta en servicio del sistema. También promueven un enfoque sistemático y estructurado del cumplimiento normativo. Al seguir la estructura de los artículos del Reglamento, garantizan que ningún requisito esencial quede sin evaluar.

Por otro lado, facilitan la comunicación entre equipos técnicos, jurídicos y de gestión, proporcionando un lenguaje común y una referencia compartida para discutir el cumplimiento normativo. Y, por último, las checklists sirven como base documental para demostrar la debida diligencia ante las autoridades supervisoras.

Debemos entender que estos documentos no son estáticos. Están sujetos a un proceso permanente de evaluación y revisión. En este sentido, la AESIA continúa desarrollando su capacidad operativa y ampliando sus herramientas de apoyo al cumplimiento.

Desde la plataforma de datos abiertos del Gobierno de España, te invitamos a explorar estos recursos. El desarrollo de la IA debe ir de la mano con datos bien gobernados y supervisión ética.

Durante más de una década, las plataformas de datos abiertos han medido su impacto a través de indicadores relativamente estables: número de descargas, visitas a la web, reutilizaciones documentadas, aplicaciones o servicios creados en base a ellos, etc. Estos indicadores funcionaban bien en un ecosistema donde los usuarios - empresas, periodistas, desarrolladores, ciudadanos anónimos, etc. - accedían directamente a las fuentes originales para consultar, descargar y procesar los datos.

Sin embargo, el panorama ha cambiado radicalmente. La irrupción de los modelos de inteligencia artificial generativa ha transformado la forma en que las personas acceden a la información. Estos sistemas generan respuestas sin necesidad de que el usuario visite la fuente original, lo que está provocando una caída global del tráfico web en medios, blogs y portales de conocimiento.

En este nuevo contexto, medir el impacto de una plataforma de datos abiertos exige repensar los indicadores tradicionales para incorporar a las métricas ya utilizadas otras nuevas que capturen también la visibilidad e influencia de los datos en un ecosistema donde la interacción humana está cambiando.

Un cambio estructural: del clic a la consulta indirecta

El ecosistema web está experimentando una transformación profunda impulsada por el auge de los modelos de lenguaje de gran tamaño (LLM, por sus siglas en inglés). Cada vez más personas formulan sus preguntas directamente a sistemas como ChatGPT, Copilot, Gemini o Perplexity, obteniendo respuestas inmediatas y contextualizadas sin necesidad de recurrir a un buscador tradicional.

Al mismo tiempo, quienes continúan utilizando motores de búsqueda como Google o Bing también experimentan cambios relevantes derivados de la integración de la inteligencia artificial en estas plataformas. Google, por ejemplo, ha incorporado funciones como AI Overviews, que ofrece resúmenes generados automáticamente en la parte superior de los resultados, o el Modo IA, una interfaz conversacional que permite profundizar en una consulta sin navegar por enlaces. Esto genera un fenómeno conocido como Zero-Click: el usuario realiza una búsqueda en un motor como Google y obtiene la respuesta directamente en la propia página de resultados. En consecuencia, no tiene necesidad de hacer clic en ningún enlace externo, lo cual limita las visitas a las fuentes originales de las que está extraída la información.

Todo ello implica una consecuencia clave: el tráfico web deja de ser un indicador fiable de impacto. Una página web puede estar siendo extremadamente influyente en la generación de conocimiento sin que ello se traduzca en visitas.

Figura 1. Métricas para medir el impacto de los datos abiertos en la era de la IA. Fuente: elaboración propia.

Nuevas métricas para medir el impacto

Ante esta situación, las plataformas de datos abiertos necesitan nuevas métricas que capturen su presencia en este nuevo ecosistema. A continuación, se recogen algunas de ellas.

1. Share of Model (SOM): presencia en los modelos de IA

Inspirado en métricas del marketing digital, el Share of Model mide con qué frecuencia los modelos de IA mencionan, citan o utilizan datos procedentes de una fuente concreta. De esta forma, el SOM ayuda a ver qué conjuntos de datos concretos (empleo, clima, transporte, presupuestos, etc.) son utilizados por los modelos para responder preguntas reales de los usuarios, revelando qué datos tienen mayor impacto.

Esta métrica resulta especialmente valiosa porque actúa como un indicador de confianza algorítmica: cuando un modelo menciona una página web, está reconociendo su fiabilidad como fuente. Además, contribuye a aumentar la visibilidad indirecta, ya que el nombre de la web aparece en la respuesta incluso cuando el usuario no llega a hacer clic.

2. Análisis de sentimiento: tono de las menciones en IA

El análisis de sentimiento permite ir un paso más allá del Share of Model, ya que no solo identifica si un modelo de IA menciona una marca o dominio, sino cómo lo hace. Habitualmente, esta métrica clasifica el tono de la mención en tres categorías principales: positivo, neutro y negativo.

Aplicado al ámbito de los datos abiertos, este análisis ayuda a comprender la percepción algorítmica de una plataforma o conjunto de datos. Por ejemplo, permite detectar si un modelo utiliza una fuente como ejemplo de buenas prácticas, si la menciona de forma neutral como parte de una respuesta informativa o si la asocia a problemas, errores o datos desactualizados.

Esta información puede resultar útil para identificar oportunidades de mejora, reforzar la reputación digital o detectar posibles sesgos en los modelos de IA que afecten a la visibilidad de una plataforma de datos abiertos.

3. Categorización de prompts: en qué temas destaca una marca

Analizar las preguntas que hacen los usuarios permite identificar en qué tipos de consultas aparece con mayor frecuencia una marca. Esta métrica ayuda a entender en qué áreas temáticas -como economía, salud, transporte, educación o clima- los modelos consideran más relevante una fuente.

Para las plataformas de datos abiertos, esta información revela qué conjuntos de datos están siendo utilizados para responder preguntas reales de los usuarios y en qué dominios existe mayor visibilidad o potencial de crecimiento. También permite detectar oportunidades: si una iniciativa de datos abiertos quiere posicionarse en nuevas áreas, puede evaluar qué tipo de contenido falta o qué conjuntos de datos podrían reforzarse para aumentar su presencia en esas categorías.

4. Tráfico procedente de IA: clics desde resúmenes generados

Muchos modelos ya incluyen enlaces a las fuentes originales. Aunque muchos usuarios no hacen clic en dichos enlaces, algunos sí lo hacen. Por ello, las plataformas pueden empezar a medir:

• Visitas procedentes de plataformas de IA (cuando estas incluyen enlaces).
• Clics desde resúmenes enriquecidos en buscadores que integran IA.

Esto supone un cambio en la distribución del tráfico que llega a las webs desde los distintos canales. Mientras el tráfico orgánico —el que proviene de los motores de búsqueda tradicionales— está disminuyendo, empieza a crecer el tráfico referido desde los modelos de lenguaje.

Este tráfico será menor en cantidad que el tradicional, pero más cualificado, ya que quien hace clic desde una IA suele tener una intención clara de profundizar.

Es importante que se tengan en cuenta estos aspectos a la hora de fijar objetivos de crecimiento en una plataforma de datos abiertos.

5. Reutilización algorítmica: uso de datos en modelos y aplicaciones

Los datos abiertos alimentan modelos de IA, sistemas predictivos y aplicaciones automatizadas. Conocer qué fuentes se han utilizado para su entrenamiento sería también una forma de conocer su impacto. Sin embargo, pocas soluciones proporcionan de manera directa esta información. La Unión Europea está trabajando para promover la transparencia en este campo, con medidas como la plantilla para documentar los datos de entrenamiento de modelos de propósito general, pero su implantación -y la existencia de excepciones a su cumplimiento- hacen que el conocimiento sea aún limitado.

Medir el incremento de accesos a los datos mediante API podría dar una idea de su uso en aplicaciones para alimentar sistemas inteligentes. Sin embargo, el mayor potencial en este campo pasa por colaboración con empresas, universidades y desarrolladores inmersos en estos proyectos, para que ofrezcan una visión más realista del impacto.

Conclusión: medir lo que importa, no solo lo que es fácil de medir

La caída del tráfico web no significa una caída del impacto. Significa un cambio en la forma en que la información circula. Las plataformas de datos abiertos deben evolucionar hacia métricas que reflejen la visibilidad algorítmica, la reutilización automatizada y la integración en modelos de IA.

Esto no significa que las métricas tradicionales deban desaparecer. Conocer los accesos a la web, los conjuntos de datos más visitados o los más descargados sigue siendo una información de gran valor para conocer el impacto de los datos proporcionados a través de plataformas abiertas. Y también es fundamental monitorizar el uso de los datos a la hora de generar o enriquecer productos y servicios, incluidos los sistemas de inteligencia artificial. En la era de la IA, el éxito ya no se mide solo por cuántos usuarios visitan una plataforma, sino también por cuántos sistemas inteligentes dependen de su información y la visibilidad que ello otorga.

Por eso, integrar estas nuevas métricas junto a los indicadores tradicionales a través de una estrategia de analítica web y SEO * permite obtener una visión más completa del impacto real de los datos abiertos. Así podremos saber cómo circula nuestra información, cómo se reutiliza y qué papel juega en el ecosistema digital que hoy da forma a la sociedad.

*El SEO (Search Engine Optimization) es el conjunto de técnicas y estrategias destinadas a mejorar la visibilidad de un sitio web en los motores de búsqueda.

El contenido masivo y superficial generado por IA no es solo un problema, también es un síntoma. La tecnología amplifica un modelo de consumo que premia la fluidez y agota nuestra capacidad de atención.

Escuchamos entrevistas, pódcasts y audios de nuestra familia al 2x. Vemos vídeos recortados en highlights, y basamos decisiones y criterios en artículos e informes que solo hemos leído resumidos con IA. Consumimos información en modo ultrarrápido, pero a nivel cognitivo le damos la misma validez que cuando la consumíamos más despacio, e incluso la aplicamos en la toma de decisiones. Lo que queda afectado por este proceso no es la memoria básica de contenidos, que parece mantenerse según los estudios controlados, sino la capacidad de conectar esos conocimientos con los que ya teníamos y elaborar con ellos ideas propias. Más que la superficialidad, inquieta que esta nueva modalidad de pensamiento resulte suficiente en tantos contextos.

¿Qué es nuevo y qué no?

Podemos pensar que la IA generativa no ha hecho más que intensificar una dinámica antigua en la que la producción de contenido es infinita, pero nuestra capacidad de atención es la misma. No podemos engañarnos tampoco, porque desde que existe Internet la infinitud no es novedad. Si dijéramos que el problema es que hay demasiado contenido, estaríamos quejándonos de una situación en la que vivimos desde hace más de veinte años. Tampoco es nueva la crisis de autoridad de la información oficial o la dificultad para distinguir fuentes fiables de las que no lo son.

Sin embargo, el AI slop, que es la inundación de contenido digital generado con IA en Internet, aporta una lógica propia y consideraciones nuevas, como la ruptura del vínculo entre esfuerzo y contenido, o que todo lo que se genera es un promedio estadístico de lo que ya existía. Este flujo uniforme y descontrolado tiene consecuencias: detrás del contenido generado en masa puede haber una intención orquestada de manipulación, un sesgo algorítmico, voluntario o no, que perjudique a determinados colectivos o frene avances sociales, y también una distorsión de la realidad aleatoria e impredecible.

¿Pero cuánto de lo que leo es IA?

En 2025 se ha estimado que una gran parte del contenido online incorpora texto sintético: un análisis de Ahrefs de casi un millón de páginas web publicadas en la primera mitad del año detectó que el 74,2 % de las nuevas páginas contenían señales de contenido generado con IA. Una investigación de Graphite del mismo año cita que, solo durante el primer año de ChatGPT, un 39% de todo el contenido online estaba ya generado con IA. Desde noviembre de 2024 esa cifra se ha mantenido estable en torno al 52%, lo que significa que desde entonces el contenido IA supera en cantidad al contenido humano. 

No obstante, hay dos preguntas que deberíamos hacernos cuando nos encontramos estimaciones de este tipo:

1. ¿Existe un mecanismo fiable para distinguir un texto escrito de un texto generado? Si la respuesta es no, por muy llamativas y coherentes que sean las conclusiones, no podemos darles valor, porque tanto podrían ser ciertas como no serlo. Es un dato cuantitativo valioso, pero que aún no existe.

Con la información que tenemos actualmente, podemos afirmar que los detectores de "texto generado por IA" fallan con la misma frecuencia con la que fallaría un modelo aleatorio, por lo que no podemos atribuirles fiabilidad. En un estudio reciente citado por The Guardian, los detectores acertaron si el texto estaba generado con IA o no en menos de un 40% de los casos. Por otro lado, ante el primer párrafo de El Quijote, también determinados detectores han devuelto un 86% de probabilidad de que el texto estuviera creado por IA.

2. ¿Qué significa que un texto está generado con IA? Por otro lado, no siempre el proceso es completamente automático (lo que llamamos copiar y pegar) sino que se dan muchos grises en la escala: la IA inspira, organiza, asiste, reescribe o expande ideas, y negar, deslegitimar o penalizar esta escritura sería ignorar una realidad instalada. 

Los dos matices anteriores no anulan el hecho de que existe el AI slop, pero este no tiene por qué ser un destino inevitable. Existen maneras de mitigar sus efectos en nuestras capacidades.

¿Cuáles son los antídotos?

Podemos no contribuir a la producción de contenido sintético, pero no podemos desacelerar lo que está ocurriendo, así que el reto consiste en revisar los criterios y los hábitos mentales con los que abordamos tanto la lectura como la escritura de contenidos.

1. Prioriza lo que hace clic: una de las pocas señales fiables que nos quedan es esa sensación de clic en el momento en que algo conecta con un conocimiento previo, una intuición que teníamos difusa o una experiencia propia, y la reorganiza o la hace nítida. Solemos decir también que “resuena”. Si algo hace clic, merece la pena seguirlo, confirmarlo, investigarlo y elaborarlo brevemente a nivel personal.

2. Busca la fricción con datos: anclar el contenido en datos abiertos y fuentes contrastables introduce una fricción saludable frente al AI slop. Reduce, sobre todo, la arbitrariedad y la sensación de contenido intercambiable, porque los datos obligan a interpretar y poner en contexto. Es una manera de poner piedras en el río excesivamente fluido que supone la generación de lenguaje, y funciona cuando leemos y cuando escribimos.

3. ¿Quién se responsabiliza? el texto existe fácilmente ahora, la cuestión es por qué existe o qué quiere conseguir, y quién se hace cargo en última instancia de ese objetivo. Busca la firma de personas u organizaciones, no tanto por la autoría sino por la responsabilidad. Desconfía de las firmas colectivas, también en traducciones y adaptaciones.

4. Cambia el foco del mérito: evalúa tus inercias al leer, porque quizá un día aprendiste a dar mérito a textos que sonaban convincentes, utilizaban determinadas estructuras o subían a un registro concreto. Desplaza el valor a elementos no generables como encontrar una buena historia, saber formular una idea difusa o atreverse a dar un punto de vista en un contexto polémico.

En la otra cara de la moneda, también es un hecho que el contenido creado con IA entra con ventaja en el flujo, pero con desventaja en la credibilidad. Esto significa que el auténtico riesgo ahora es que la IA pueda llegar a crear contenido de alto valor, pero las personas hayamos perdido la capacidad de concentración para valorarlo. A esto hay que añadirle el prejuicio instalado de que, si es con IA, no es un contenido válido. Proteger nuestras capacidades cognitivas y aprender a diferenciar entre un contenido comprimible y uno que no lo es no es por tanto un gesto nostálgico, sino una habilidad que a la larga puede mejorar la calidad del debate público y el sustrato del conocimiento común.

Los agentes de IA (como los de Google ADK, LangChain, etc.) son "cerebros". Pero un cerebro sin "manos" no puede actuar en el mundo real (consultar APIs, buscar en bases de datos, etc.). Esas "manos" son las herramientas.

El desafío es: ¿cómo conectas el cerebro con las manos de forma estándar, desacoplada y escalable? La respuesta es el Model Context Protocol (MCP).

Como ejercicio práctico, construiremos un sistema de agente conversacional que permite explorar el Catálogo Nacional de datos abiertos albergado en datos.gob.es mediante preguntas en lenguaje natural, facilitando así el acceso a datos públicos.

En este ejercicio práctico, el objetivo principal es ilustrar, paso a paso, cómo construir un servidor de herramientas independiente que hable el protocolo MCP.

Para hacer este ejercicio tangible y no solo teórico, usaremos, FastMCP para construir el servidor. Para probar que nuestro servidor funciona, crearemos un agente simple con Google ADK que lo consuma. El caso de uso (consultar la API de datos.gob.es) ilustra esta conexión entre herramientas y agentes. El verdadero aprendizaje es la arquitectura, que podrías reutilizar para cualquier API o base de datos.

A continuación se muestran las tecnologías que usaremos y un esquema de cómo están realizados entre sí los diferentes componentes

• FastMCP (mcp.server.fastmcp): implementación ligera del protocolo MCP que permite crear servidores de herramientas con muy poco código mediante decoradores Python. Es el 'protagonista' del ejercicio.
• Google ADK (Agent Development Kit): framework para definir el agente de IA, su prompt y conectarlo a las herramientas. Es el 'cliente' que prueba nuestro servidor.
• FastAPI: para servir el agente como una API REST con interfaz web interactiva.
• httpx: para realizar llamadas asíncronas a la API externa de datos.gob.es.
• Docker y Docker Compose: para paquetizar y orquestar los dos microservicios, permitiendo que se ejecuten y comuniquen de forma aislada.

Figura 1. Arquitectura desacoplada con comunicación MCP.

El diagrama ilustra una arquitectura desacoplada dividida en cuatro componentes principales que se comunican mediante el protocolo MCP. Cuando el usuario realiza una consulta en lenguaje natural, el Agente ADK (basado en Google Gemini) procesa la intención y se comunica con el servidor MCP a través del Protocolo MCP, que actúa como intermediario estandarizado. El servidor MCP expone cuatro herramientas especializadas (buscar datasets, listar temáticas, buscar por temática y obtener detalles) que encapsulan toda la lógica de negocio para interactuar con la API externa de datos.gob.es. Una vez que las herramientas ejecutan las consultas necesarias y reciben los datos del catálogo nacional, el resultado se propaga de vuelta al agente, que finalmente genera una respuesta comprensible para el usuario, completando así el ciclo de comunicación entre el "cerebro" (agente) y las "manos" (herramientas).

Accede al repositorio del laboratorio de datos en GitHub

Ejecuta el código de pre-procesamiento de datos sobre Google Colab

La arquitectura: servidor MCP y agente consumidor

La clave de este ejercicio es entender la relación cliente-servidor:

1. El Servidor (Backend): es el protagonista de este ejercicio. Su único trabajo es definir la lógica de negocio (las "herramientas") y exponerlas al mundo exterior usando el "contrato" estándar de MCP. Es el responsable de encapsular toda la lógica de comunicación con la API de datos.gob.es.
2. El Agente (Frontend): es el "cliente" o "consumidor" de nuestro servidor. Su rol en este ejercicio es probar que nuestro servidor MCP funciona. Lo usamos para conectarnos, descubrir las herramientas que el servidor ofrece y llamarlas.
3. El Protocolo MCP: es el "lenguaje" o "contrato" que permite que el agente y el servidor se entiendan sin necesidad de conocer los detalles internos del otro.

Proceso de desarrollo

El núcleo del ejercicio se divide en tres partes: crear el servidor, crear un cliente para probarlo y ejecutarlos.

1. El servidor de herramientas (el backend con MCP)

Aquí es donde reside la lógica de negocio y el foco de este tutorial. En el archivo principal (server.py), definimos funciones Python simples y usamos el decorador @mcp.tool de FastMCP para exponerlas como 'herramientas' consumibles.

La description que añadimos al decorador es crucial, ya que es la documentación que cualquier cliente MCP (incluyendo nuestro agente ADK) leerá para saber cuándo y cómo usar cada herramienta.

Las herramientas que definiremos en el ejercicio son:

• buscar_datasets(titulo: str): para buscar datasets por palabras clave en el título.
• listar_tematicas(): para descubrir qué categorías de datos existen.
• buscar_por_tematica(tematica_id: str): para encontrar datasets de un tema específico.

• obtener_detalle_dataset(dataset_id: str): para obtener la información completa de un dataset.

2. El agente consumidor (el frontend con Google ADK)

Una vez construido nuestro servidor MCP, necesitamos una forma de probarlo. Aquí es donde entra Google ADK. Lo usamos para crear un "agente consumidor" simple.

La magia de la conexión ocurre en el argumento tools. En lugar de definir las herramientas localmente, simplemente le pasamos la URL de nuestro servidor MCP. El agente, al iniciarse, consultará esa URL, leerá el "contrato" MCP y sabrá automáticamente qué herramientas tiene disponibles y cómo usarlas.

# Ejemplo de configuración en agent.py
root_agent = LlmAgent(
   ...
   instruction="Eres un asistente especializado en datos.gob.es...",
   tools=[
       MCPToolset(
           connection_params=StreamableHTTPConnectionParams(
               url="http://mcp-server:8000/mcp",
           ),
       )
   ]
)

3. Orquestación con Docker Compose

Finalmente, para ejecutar nuestro Servidor MCP y el agente consumidor juntos, usamos docker-compose.yml. Docker Compose se encarga de construir las imágenes de cada servicio, crear una red privada para que se comuniquen (por eso el agente puede llamar a http://mcp-server:8000) y exponer los puertos necesarios.

Probando el servidor MCP en acción

Una vez que ejecutamos docker-compose up --build, podemos acceder a la interfaz web del agente (http://localhost:8080).

El objetivo de esta prueba no es solo ver si el bot responde bien, sino verificar que nuestro servidor MCP funciona correctamente y que el agente ADK (nuestro cliente de prueba) puede descubrir y usar las herramientas que este expone.

Figura 2. Pantalla del agente demostrando sus herramientas.

El verdadero poder del desacoplamiento se ve cuando el agente encadena lógicamente las herramientas que nuestro servidor le proveyó.

Figura 3. Pantalla del agente demostrando el uso conjunto de las herramientas.

¿Qué puedes aprender?

El objetivo de este ejercicio es aprender los fundamentos de una arquitectura de agentes moderna, centrándonos en el servidor de herramientas. En concreto:

• Cómo construir un servidor MCP: cómo crear un servidor de herramientas desde cero que hable MCP, usando decoradores como @mcp.tool.
• El patrón de una arquitectura desacoplada: el patrón fundamental de separar el 'cerebro' (LLM) de las 'herramientas' (lógica de negocio).
• Descubrimiento dinámico de herramientas: cómo un agente (en este caso, de ADK) puede conectarse dinámicamente a un servidor MCP para descubrir y consumir herramientas.
• Integración de API externas: el proceso de 'envolver' una API compleja (como la de datos.gob.es) en funciones simples dentro de un servidor de herramientas.
• Orquestación con Docker: cómo gestionar un proyecto de microservicios para desarrollo.

Conclusiones y futuro

Hemos construido un servidor de herramientas MCP robusto y funcional. El verdadero valor de este ejercicio es el cómo: una arquitectura escalable centrada en un servidor de herramientas que habla un protocolo estándar.

Esta arquitectura basada en MCP es increíblemente flexible. El caso de datos.gob.es es solo un ejemplo. Podríamos fácilmente:

• Cambiar el caso de uso: reemplazar el server.py por uno que conecte a una base de datos interna o a la API de Spotify, y cualquier agente que hable MCP (no solo ADK) podría consumirlo.
• Cambiar el "cerebro": cambiar el agente ADK por un agente de LangChain o cualquier otro cliente MCP, y nuestro servidor de herramientas seguiría funcionando sin cambios.

Para aquellos interesados en llevar este análisis al siguiente nivel, las posibilidades se centran en mejorar el servidor MCP:

• Implementar más herramientas: añadir filtros por formato, publicador o fecha al servidor MCP.
• Integrar caché: usar Redis en el servidor MCP para cachear las respuestas de la API y mejorar la velocidad.
• Añadir persistencia: guardar el historial de chat en una base de datos (esto sí sería en el lado del agente).

Más allá de estas mejoras técnicas, esta arquitectura abre la puerta a múltiples aplicaciones en contextos muy diversos. 

• Periodistas y académicos pueden disponer de asistentes de investigación que les ayuden a descubrir conjuntos de datos relevantes en segundos.
• Organizaciones de transparencia pueden construir herramientas de monitorización que detecten automáticamente nuevas publicaciones de datos de contratación pública o presupuestos.
• Consultoras y equipos de inteligencia de negocio pueden desarrollar sistemas que crucen información de múltiples fuentes gubernamentales para elaborar informes sectoriales.
• Incluso en el ámbito educativo, esta arquitectura sirve como base didáctica para enseñar conceptos avanzados de programación asíncrona, integración de API y diseño de agentes de IA.

El patrón que hemos construido —un servidor de herramientas desacoplado que habla un protocolo estándar— es la base sobre la que puedes desarrollar soluciones adaptadas a tus necesidades específicas, independientemente del dominio o la fuente de datos con la que trabajes.
 

Los datos abiertos son una pieza central de la innovación digital en torno a la inteligencia artificial ya que permiten, entre otras cosas, entrenar modelos o evaluar algoritmos de aprendizaje automático. Pero entre “descargar un CSV de un portal” y acceder a un conjunto de datos listo para aplicar técnicas de aprendizaje automático hay, todavía, un abismo.

Buena parte de ese abismo tiene que ver con los metadatos, es decir cómo se describen los conjuntos de datos (a qué nivel de detalle y con qué estándares). Si los metadatos se limitan a título, descripción y licencia, el trabajo de comprensión y preparación de datos se hace más complejo y tedioso para la persona que diseña el modelo de aprendizaje automático. Si, en cambio, se usan estándares que faciliten la interoperabilidad, como DCAT, los datos se vuelven más FAIR (Findable, Accessible, Interoperable, Reusable) y, por tanto, más fáciles de reutilizar. No obstante, es necesario metadatos adicionales para que los datos sean más fáciles de integrar en flujos de aprendizaje automático.

Este artículo realiza un itinerario por las diversas iniciativas y estándares necesarios para dotar a los datos abiertos de metadatos útiles para la aplicación de técnicas de aprendizaje automático.

DCAT como columna vertebral de los portales de datos abiertos

El vocabulario DCAT (Data Catalog Vocabulary) fue diseñado por la W3C para facilitar la interoperabilidad entre catálogos de datos publicados en la Web. Describe catálogos, conjuntos de datos y distribuciones, siendo la base sobre la que se construyen muchos portales de datos abiertos.

En Europa, DCAT se concreta en el perfil de aplicación DCAT-AP, recomendado por la Comisión Europea y ampliamente adoptado para describir conjuntos de datos en el sector público, por ejemplo, en España con DCAT-AP-ES. Con DCAT-AP se responde a preguntas como:

• ¿Qué conjuntos de datos existen sobre un tema concreto?
• ¿Quién los publica, bajo qué licencia y en qué formatos?
• ¿Dónde están las URL de descarga o las API de acceso?

El uso de un estándar como DCAT es imprescindible para descubrir conjuntos de datos, pero es necesario ir un paso más allá con el fin de saber cómo se utilizan en modelos de aprendizaje automático o qué calidad tienen desde la perspectiva de estos modelos.

MLDCAT-AP: aprendizaje automático en el catálogo de un portal de datos abiertos

MLDCAT-AP (Machine Learning DCAT-AP) es un perfil de aplicación de DCAT desarrollado por SEMIC y la comunidad Interoperable Europe, en colaboración con OpenML, que extiende DCAT-AP al dominio del aprendizaje automático.

MLDCAT-AP incorpora clases y propiedades para describir:

• Modelos de aprendizaje automático y sus características.
• Conjuntos de datos utilizados en el entrenamiento y la evaluación.
• Métricas de calidad obtenidas sobre los conjuntos de datos.
• Publicaciones y documentación asociadas a los modelos de aprendizaje automático.
• Conceptos relacionados con riesgo, transparencia y cumplimiento del contexto regulatorio europeo del AI Act.

Con ello, un catálogo basado en MLDCAT-AP ya no solo responde a “qué datos hay”, sino también a:

• ¿Qué modelos se han entrenado con este conjunto de datos?
• ¿Cuál ha sido el rendimiento de ese modelo según determinadas métricas?
• ¿Dónde se describe este trabajo (artículos científicos, documentación, etc.)?

MLDCAT-AP representa un gran avance en trazabilidad y gobernanza, pero se mantiene la definición de metadatos a un nivel que todavía no considera la estructura interna de los conjuntos de datos ni qué significan exactamente sus campos. Para eso, se necesita bajar a nivel de la propia estructura de la distribución de conjunto de datos.

Metadatos a nivel de estructura interna del conjunto de datos

Cuando se quiere describir qué hay dentro de las distribuciones de los conjuntos de datos (campos, tipos, restricciones), una iniciativa interesante es Data Package, parte del ecosistema de Frictionless Data.

Un Data Package se define por un archivo JSON que describe un conjunto de datos. En este archivo se incluyen no sólo metadatos generales (como el nombre, título, descripción o licencia) y recursos (es decir, los ficheros de datos con su ruta o una URL de acceso a su correspondiente servicio), sino también se define un esquema con:

• Nombres de campos.
• Tipos de datos (integer, number, string, date, etc.).
• Restricciones, como rangos de valores válidos, claves primarias y ajenas, etc.

Desde la óptica del aprendizaje automático, esto se traduce en la posibilidad de realizar una validación estructural automática antes de usar los datos. Además, también permite una documentación precisa de la estructura interna de cada conjunto de datos y mayor facilidad para compartir y versionar conjuntos de datos.

En resumen, mientras que MLDCAT-AP indica qué conjuntos de datos existen y cómo encajan en el ámbito de modelos de aprendizaje automático, Data Package especifica exactamente “qué hay” dentro de los conjuntos de datos.

Croissant: metadatos que preparan datos abiertos para aprendizaje automático

Aun con el concurso de MLDCAT-AP y de Data Package, faltaría conectar los conceptos subyacentes en ambas iniciativas. Por una parte, el ámbito del aprendizaje automático (MLDCAT-AP) y por otro el de las estructuras internas de los propios datos (Data Package). Es decir, se puede estar usando los metadatos de MLDCAT-AP y de Data Package pero para solventar algunas limitaciones que adolecen ambos, es necesario complementarlo. Aquí entra en juego Croissant, un formato de metadatos para preparar los conjuntos de datos para la aplicación de aprendizaje automático. Croissant está desarrollado en el marco de MLCommons, con participación de industria y academia.

Específicamente, Croissant se implementa en JSON-LD y se construye sobre schema.org/Dataset, un vocabulario para describir conjuntos de datos en la Web. Croissant combina los siguientes metadatos:

• Metadatos generales del conjunto de datos.
• Descripción de recursos (archivos, tablas, etc.).
• Estructura de los datos.
• Capa semántica sobre aprendizaje automático (separación de datos de entrenamiento/validación/test, campos objetivo, etc.)

Cabe destacar que Croissant está diseñado para que distintos repositorios (como Kaggle, HuggingFace, etc.) puedan publicar conjuntos de datos en un formato que las librerías de aprendizaje automático (TensorFlow, PyTorch, etc.) puedan cargar de forma homogénea. También existe una extensión de CKAN para usar Croissant en portales de datos abiertos.

Otras iniciativas complementarias

Merece la pena mencionar brevemente otras iniciativas interesantes relacionadas con la posibilidad de disponer de metadatos que permitan preparar a los conjuntos de datos para la aplicación de aprendizaje automático (“ML-ready datasets”):

• schema.org/Dataset: usado en páginas web y repositorios para describir conjuntos de datos. Es la base sobre la que se apoya Croissant y está integrado, por ejemplo, en las directrices de datos estructurados de Google para mejorar la localización de conjuntos de datos en buscadores.
• CSV on the Web (CSVW): conjunto de recomendaciones del W3C para acompañar ficheros CSV con metadatos en JSON (incluyendo diccionarios de datos), muy alineado con las necesidades de documentación de datos tabulares que luego se usan en aprendizaje automático.
• Datasheets for Datasets y Dataset Cards: iniciativas que permiten desarrollar una documentación narrativa y estructurada para describir el contexto, la procedencia y las limitaciones de los conjuntos de datos. Estas iniciativas son ampliamente adoptadas en plataformas como Hugging Face.

Conclusiones

Existen diversas iniciativas que ayudan a realizar una definición de metadatos adecuada para el uso de aprendizaje automático con datos abiertos:

• DCAT-AP y MLDCAT-AP articulan el nivel de catálogo, modelos de aprendizaje automático y métricas.
• Data Package describe y valida la estructura y restricciones de los datos a nivel de recurso y campo.
• Croissant conecta estos metadatos con el flujo de aprendizaje automático, describiendo cómo los conjuntos de datos son ejemplos concretos para cada modelo.
• Iniciativas como CSVW o Dataset Cards complementan las anteriores y son ampliamente utilizadas en plataformas como HuggingFace.

Estas iniciativas pueden usarse de manera combinada. De hecho, si se adoptan de forma conjunta, se permite que los datos abiertos dejen de ser simplemente “ficheros descargables” y se conviertan en una materia prima preparada para el aprendizaje automático, reduciendo fricción, mejorando la calidad y aumentando la confianza en los sistemas de IA construidos sobre ellos.