buenas prácticas

“Voy a subirte un fichero CSV. Quiero que lo analices y me resumas las conclusiones más relevantes que puedas extraer de los datos”. Hace unos años, el análisis de datos era territorio de quien sabía escribir código y utilizar entornos técnicos complejos, y una petición así habría requerido programación o habilidades avanzadas de Excel. Hoy, poder analizar en poco tiempo ficheros de datos con herramientas de IA nos aporta una gran autonomía profesional. Formular preguntas, contrastar ideas preliminares y explorar de primera mano la información cambia nuestra relación con el conocimiento, sobre todo, porque dejamos de depender de intermediarios para obtener respuestas. Ganar la capacidad de analizar datos con IA de manera independiente acelera los procesos, pero también puede provocarnos un exceso de confianza en las conclusiones.

A partir del ejemplo de un fichero de datos en bruto, vamos a revisar posibilidades, precauciones y pautas básicas para explorar la información sin asumir conclusiones demasiado rápido.

El fichero:

Para mostrar un ejemplo de análisis de datos con IA utilizaremos un fichero del Instituto Nacional de Estadística (INE) que recoge información sobre flujos turísticos en Europa, en concreto sobre ocupación en alojamientos de turismo rural. El fichero de datos contiene información desde enero de 2001 hasta diciembre de 2025. Contiene desagregaciones por sexo, edad y comunidad o ciudad autónoma, lo que permite realizar análisis comparativos a lo largo del tiempo. En el momento de escribir este artículo, la última actualización de este conjunto de datos fue el 28 de enero de 2026.

Figura 1. Información del dataset. Fuente: Instituto Nacional de Estadística (INE).

1. Exploración inicial

Para esta primera exploración vamos a utilizar una versión gratuita de Claude, el chat multitarea basado en IA desarrollado por Anthropic. Es uno de los modelos de lenguaje más avanzados en benchmarks de razonamiento y análisis, lo que lo hace especialmente adecuado para este ejercicio, y es la opción más utilizada actualmente por la comunidad para realizar tareas que requieren código.

Pensemos que nos enfrentamos al fichero de datos por primera vez. Sabemos a grandes rasgos qué contiene, pero desconocemos la estructura de la información. Nuestro primer prompt, por tanto, debería centrarse en describirla:

PROMPT: Quiero trabajar con un fichero de datos sobre ocupación en alojamientos de turismo rural. Explícame qué estructura tiene el fichero: qué variables contiene, qué mide cada una y qué posibles relaciones existen entre ellas. Señala también posibles valores ausentes o elementos que requieran aclaración.

Figura 2. Exploración inicial del fichero de datos con Claude. Fuente: Claude.

Una vez que Claude nos ha dado la idea general y la explicación de las variables, es buena práctica abrir el fichero y hacer una comprobación rápida. El objetivo es evaluar que, como mínimo, el número de filas, el número de columnas, los nombres de las variables, el período temporal y el tipo de datos coinciden con lo que nos ha dicho el modelo.

Si detectamos algún error en este punto, el LLM puede no estar leyendo correctamente los datos. Si después de intentarlo en otra conversación el error persiste, es señal de que hay algo en el fichero que dificulta su lectura automática. En este caso, lo más recomendable es no proseguir con el análisis, ya que las conclusiones serán muy aparentes, pero estarán basadas en datos mal interpretados.

2. Gestión de anomalías

En segundo lugar, si hemos descubierto anomalías, lo habitual es documentarlas y decidir cómo manejarlas antes de seguir con el análisis. Podemos pedir al modelo que nos sugiera qué hacer, pero las decisiones finales serán nuestras. Por ejemplo:

• Valores faltantes: si hay celdas vacías, tenemos que decidir si rellenarlas con un valor “promedio” de la columna o simplemente eliminar esas filas.
• Duplicados: tenemos que eliminar filas repetidas o que no aportan información nueva.
• Errores de formato o inconsistencias: debemos corregirlos para que las variables sean coherentes y comparables. Por ejemplo, fechas representadas en distintos formatos.
• Outliers: si aparece un número que no tiene sentido o es exageradamente distinto del resto, tenemos que decidir si corregirlo, ignorarlo o tratarlo tal y como está.

 Figura 3. Ejemplo de análisis de valores faltantes con Claude. Fuente: Claude.

En el caso de nuestro fichero, por ejemplo, hemos detectado que en Ceuta y Melilla los valores ausentes en la variable Total son estructurales, no hay turismo rural registrado en esas ciudades, por lo que podríamos excluirlas del análisis.

Antes de tomar la decisión, una buena práctica en este punto es pedir al LLM los pros y contras de la modificación en los datos. Su respuesta puede darnos alguna pista de cuál es la mejor opción, o indicarnos algún inconveniente que no habíamos tenido en cuenta.

Figura 4. Análisis de Claude sobre la posibilidad de eliminar o no valores. Fuente: Claude.

Si decidimos seguir adelante y excluir las ciudades de Ceuta y Melilla del análisis, Claude puede ayudarnos a efectuar esta modificación directamente sobre el fichero. El prompt sería el siguiente:

PROMPT: Elimina del fichero todas las filas correspondientes a Ceuta y Melilla, de manera que el resto de los datos se mantenga intacto. Explica también los pasos que estás siguiendo para que pueda revisarlos.

Figura 5. Paso a paso en la modificación de datos en Claude. Fuente: Claude.

En este punto, Claude nos ofrece descargar de nuevo el fichero modificado, así que una buena práctica de comprobación sería validar de forma manual que la operación se hizo bien. Por ejemplo, revisar el número de filas en un fichero y otro o cotejar algunas filas al azar con el primer fichero para asegurarnos de que los datos no se han corrompido.

3. Primeras preguntas y visualizaciones

Si el resultado hasta aquí es satisfactorio, ya podemos empezar a explorar los datos para hacernos preguntas iniciales y buscar patrones interesantes. Lo ideal al empezar la exploración es hacer preguntas grandes, claras y fáciles de responder con los datos, porque nos dan una primera visión.

PROMPT: Trabaja con el fichero sin Ceuta y Melilla a partir de ahora. ¿Cuáles han sido las cinco comunidades con más turismo rural en el período total?

Figura 6. Respuesta de Claude a las cinco comunidades con más turismo rural en el período. Fuente: Claude.

Por último, podemos pedirle a Claude que nos ayude a visualizar los datos. En lugar de hacer el esfuerzo de indicarle un tipo de gráfico concreto, le damos libertad para elegir el formato que mejor muestre la información.

PROMPT: ¿Puedes visualizar esta información en un gráfico? Elige el formato más adecuado para representar los datos.

Figura 7. Gráfico elaborado por Cloude para representar la información. Fuente: Claude.

Aquí, la pantalla se desdobla: a la izquierda, podemos continuar con la conversación o descargar el fichero, mientras que a la derecha podemos visualizar el gráfico directamente. Claude ha generado una gráfica de barras horizontales muy visual y lista para usar. Los colores diferencian las comunidades y se indica correctamente el período y el tipo de datos.

¿Qué ocurre si le pedimos cambiar la paleta de color del gráfico por una inadecuada? En este caso, por ejemplo, vamos a pedirle una serie de tonos pastel que apenas se diferencian.

PROMPT: ¿Puedes cambiar la paleta de colores del gráfico por esta otra? #E8D1C5, #EDDCD2, #FFF1E6, #F0EFEB, #EEDDD3

Figura 8. Ajustes realizados en el gráfico por Claude para representar la información. Fuente: Claude.

Ante el reto, Claude ajusta por sí mismo el gráfico de manera inteligente, oscurece el fondo y cambia el texto de las etiquetas para mantener legibilidad y contraste.

Todo el ejercicio anterior se ha realizado con Claude Sonnet 4.6, que no es el modelo de mayor calidad de Anthropic. Sus versiones superiores, como Claude Opus 4.6, tienen mayor capacidad de razonamiento, comprensión profunda y resultados más finos. Además, existen muchas otras herramientas para trabajar con datos y visualizaciones basadas en IA, como Julius o Quadratic. Aunque en ellas las posibilidades son casi infinitas, cuando trabajamos con datos sigue siendo fundamental mantener una metodología y un criterio propios.

Contextualizar en la vida real los datos que estamos analizando y conectarlos con otros conocimientos no es una tarea que se pueda delegar; necesitamos tener una mínima idea previa de qué queremos conseguir con el análisis para poder transmitirla al sistema. Esto nos permitirá hacer mejores preguntas, interpretar adecuadamente los resultados y por tanto hacer un prompting más eficaz. 

Contenido elaborado por Carmen Torrijos, experta en IA aplicada al lenguaje y la comunicación. Los contenidos y los puntos de vista reflejados en esta publicación son responsabilidad exclusiva de su autor.

La adopción del nuevo perfil DCAT-AP-ES alinea a España con el perfil de aplicación en Europa (DCAT-AP), facilitando la federación automática entre catálogos de datos definidos en RDF (Resource Description Framework).

En este entorno de grafos RDF donde la flexibilidad es la norma, la ausencia de esquemas rígidos tradicionales puede derivar en una degradación silenciosa de la calidad de los datos, si no se sigue de forma rigurosa el estándar. Para mitigar este riesgo, existe el lenguaje de restricciones de formas SHACL (Shapes Constraint Language), recomendación del W3C. Estas pautas permiten definir «formas» que funcionan como verdaderos guardianes de la calidad y el cumplimiento de la interoperabilidad. 

Las etapas del proceso de validación SHACL son las siguientes:

1. Se dispone de un grafo de datos RDF
2. Se selecciona un subgrado del grafo anterior
3. Se comprueban las restricciones SHACL que aplican al subgrafo anterior
4. Se obtiene un informe de validación con los elementos conformes, con errores o con recomendaciones.

En la siguiente figura se muestran estas etapas:

Figura 1: Etapas principales del proceso de validación SHACL 

Objetivos y audiencia destino

Esta guía técnica tiene como objetivo ayudar a que los publicadores y reutilizadores incorporen la validación SHACL como una práctica continua de mejora de calidad, mediante un enfoque didáctico y accesible, inspirado en recursos claros y herramientas de validación abiertas del ecosistema de datos.

Además, se profundiza de forma especial en su relación con DCAT-AP-ES, detallando un caso práctico y exhaustivo del flujo de trabajo completo de validación y gobernanza de un catálogo conforme a dicho perfil.

Estructura y contenidos

El documento sigue un enfoque progresivo, partiendo de fundamentos teóricos hasta llegar a la implementación técnica e integración automática, estructurándose en los siguientes bloques clave:

• Fundamentos de la validación semántica: RDF y el desafío del mundo abierto que supone así como SHACL como mecanismo de realizar validaciones, definiendo conceptos clave como Shape o Validation Report.
• DCAT-AP-ES y la adopción de SHACL para su validación: se explican las formas SHACL definidas en DCAT-AP-ES y el caso de aplicación de las mismas en el proceso de federación del Catálogo Nacional.
• Caso práctico: Validación de grafos RDF: un tutorial paso a paso sobre cómo validar un catálogo con las formas SHACL de DCAT-AP-ES, resolución de problemas comunes y herramientas disponibles.
• Conclusiones: reflexiones sobre las ventajas de integrar validación SHACL para mejorar la gobernanza de catálogos de datos.

La validación mediante SHACL representa un cambio de paradigma en la gestión de la calidad de metadatos en los catálogos de datos. Esta guía recorre el proceso completo desde los fundamentos teóricos hasta la aplicación práctica, demostrando que la adopción de SHACL no es simplemente un requisito técnico, sino una oportunidad para fortalecer y mejorar la gobernanza de datos. 

Vivimos en una era en la que la ciencia depende cada vez más de datos. Desde la planificación urbana hasta la transición climática, el gobierno del dato se ha convertido en un pilar estructural de la toma de decisiones basada en evidencia. Sin embargo, existe un ámbito donde los principios tradicionales de gestión, validación y control del dato se ven sometidos a tensiones extremas: el universo.

Los datos espaciales —producidos por satélites científicos, telescopios, sondas interplanetarias y misiones de exploración— no describen realidades accesibles ni repetibles. Observan fenómenos que ocurrieron hace millones de años, a distancias imposibles de recorrer y bajo condiciones que nunca podrán replicarse en laboratorio. No existe una medición “in situ” que confirme directamente estos fenómenos.

En este contexto, el gobierno del dato deja de ser una cuestión organizativa y pasa a ser un elemento estructural de la confianza científica. La calidad, la trazabilidad y la reproducibilidad no pueden apoyarse en referencias físicas directas, sino en la transparencia metodológica, la documentación exhaustiva y la solidez de los marcos instrumentales y teóricos.

Gobernar datos del universo implica, por tanto, enfrentarse a retos únicos: gestionar incertidumbre estructural, documentar escalas extremas y garantizar la confianza en información que nunca podremos tocar.

A continuación, exploramos los principales desafíos que plantea el gobierno del dato cuando el objeto de estudio está más allá de la Tierra.

I. Retos específicos del dato del universo

1. Más allá de la Tierra: nuevas fuentes, nuevas reglas

Cuando hablamos de datos espaciales, nos referimos a mucho más que a imágenes de satélite de la superficie terrestre. Nos adentramos en un ecosistema complejo que incluye telescopios espaciales y terrestres, sondas interplanetarias, misiones de exploración planetaria y observatorios diseñados para detectar radiación, partículas o fenómenos físicos extremos.

Estos sistemas generan datos con retos claramente diferentes respecto a otros dominios científicos:

Figura 1. Desafíos en el gobiernos de datos del universo. Fuente: elaboración propia - datos.gob.es.

A diferencia de los datos de observación de la Tierra —que en muchos casos pueden contrastarse mediante campañas de campo o sensores redundantes— los datos del universo dependen fundamentalmente de la arquitectura de la misión, la calibración del instrumento y los modelos físicos utilizados para interpretar la señal capturada.

En numerosos casos, lo que se registra no es el fenómeno en sí, sino una señal indirecta: variaciones espectrales, emisiones electromagnéticas, alteraciones gravitacionales o partículas detectadas tras recorrer millones de kilómetros. El dato es, en esencia, una traducción instrumental de un fenómeno inaccesible.

Por todo ello, en el espacio el dato no puede entenderse sin el contexto técnico que lo genera.

2. Incertidumbre estructural y escalas extremas

La incertidumbre se refiere al grado de margen de error o indeterminación asociado a una medición, interpretación o resultado científico debido a los límites de los instrumentos, las condiciones de observación y los modelos utilizados para analizar los datos. Si en otros ámbitos la incertidumbre es un factor que se intenta reducir mediante mediciones directas, repetibles y contrastables, en la observación del universo la incertidumbre forma parte del propio proceso de conocimiento. No se trata simplemente de “no saber lo suficiente”, sino de enfrentarse a límites físicos y metodológicos que no pueden eliminarse por completo.

Por tanto, en la observación del universo la incertidumbre es estructural. No se trata de una anomalía puntual, sino de una condición inherente al objeto de estudio.

Existen varias dimensiones críticas:

• Escalas espaciales y temporales extremas: las distancias cósmicas impiden cualquier validación directa. Las escalas temporales implican que, con frecuencia, el dato captura un “instante” del pasado remoto y no una realidad presente verificable.
• Señales débiles y ruido inevitable: los instrumentos capturan emisiones sumamente sutiles. La señal útil convive con interferencias, limitaciones tecnológicas y ruido de fondo. La interpretación depende de tratamientos estadísticos avanzados y de modelos físicos complejos.
• Fenómenos de observación limitada: algunos fenómenos astrofísicos —como determinadas supernovas, estallidos de rayos gamma o configuraciones gravitacionales singulares— no pueden recrearse experimentalmente y solo pueden observarse cuando ocurren. En estos casos, el registro disponible puede ser único o profundamente limitado, lo que incrementa la responsabilidad en su documentación y preservación.

No todos los fenómenos son irrepetibles, pero en muchos casos las oportunidades de observación son escasas o dependen de condiciones excepcionales.

II. Construir confianza cuando no podemos tocar el objeto observado

Ante estos retos, el gobierno del dato adquiere un papel estructural. No se limita a garantizar almacenamiento o disponibilidad, sino que define las reglas mediante las cuales los procesos científicos quedan documentados, trazables y auditables.

En este contexto, gobernar no significa producir conocimiento, sino garantizar que su producción sea transparente, verificable y reutilizable.

1. Calidad sin validación física directa

Cuando no puede verificarse directamente el fenómeno observado, la calidad del dato se apoya en:

• Protocolos rigurosos de calibración: los instrumentos deben someterse a procesos sistemáticos de calibración antes, durante y después de su operación. Esto implica ajustar sus mediciones frente a referencias conocidas, caracterizar sus márgenes de error, documentar desviaciones y registrar cualquier modificación en su configuración. La calibración no es un evento puntual, sino un proceso continuo que garantiza que la señal registrada refleje, con la mayor precisión posible, el fenómeno observado dentro de los límites físicos del sistema.
• Validación cruzada entre instrumentos independientes: cuando distintos instrumentos —ya sea en la misma misión o en misiones diferentes— observan un fenómeno similar, la comparación de resultados permite reforzar la fiabilidad del dato. La convergencia entre observaciones obtenidas con tecnologías distintas reduce la probabilidad de sesgos instrumentales o errores sistemáticos. Esta coherencia inter-instrumental actúa como un mecanismo de verificación indirecta.
• Repetición observacional cuando es posible:  aunque no todos los fenómenos pueden repetirse, muchas observaciones sí pueden realizarse en diferentes momentos o bajo distintas condiciones. La repetición permite evaluar la estabilidad de la señal, identificar anomalías y estimar variabilidad natural frente a error de medición. La consistencia en el tiempo fortalece la robustez del resultado.
• Revisión por pares y consenso científico progresivo: los datos y sus interpretaciones son sometidos a evaluación por parte de la comunidad científica. Este proceso implica escrutinio metodológico, análisis crítico de supuestos y verificación de coherencia con el conocimiento existente. El consenso no surge de forma inmediata, sino a través de acumulación de evidencia y debate científico. La calidad, en este sentido, es también una construcción colectiva.

La calidad no es solo una propiedad técnica; es el resultado de un proceso documentado y auditable.

2. Trazabilidad científica completa

En el contexto espacial, el dato es inseparable del proceso técnico y científico que lo genera. No puede entenderse como un resultado aislado, sino como la culminación de una cadena de decisiones instrumentales, metodológicas y analíticas.

Por ello, la trazabilidad debe cubrir de forma explícita y documentada:

• Diseño y configuración del instrumento: es necesario conservar información sobre las características técnicas del instrumento que capturó la señal, por ejemplo, su arquitectura, capacidades de detección, límites de resolución y configuraciones operativas. Estas condiciones determinan qué tipo de señal puede registrarse y con qué precisión.
• Parámetros de calibración: deben registrarse los ajustes aplicados para asegurar que el instrumento opere dentro de los márgenes previstos, así como las modificaciones realizadas a lo largo del tiempo. Los parámetros de calibración influyen directamente en la interpretación de la señal obtenida.
• Versiones del software de procesamiento: el tratamiento del dato bruto depende de herramientas informáticas específicas. Conservar las versiones utilizadas permite comprender cómo se generaron los resultados y evitar ambigüedades si el software evoluciona.
• Algoritmos aplicados en la reducción de ruido: dado que las señales suelen estar acompañadas de interferencias o ruido de fondo, es esencial documentar los métodos empleados para filtrar, limpiar o transformar la información antes de su análisis. Estos algoritmos influyen en el resultado final.
• Supuestos científicos utilizados en la interpretación: la lectura del dato no es neutra: se apoya en marcos teóricos y modelos físicos aceptados en el momento del análisis. Registrar estos supuestos permite contextualizar las conclusiones y comprender posibles revisiones futuras.
• Transformaciones sucesivas del dato bruto al dato publicado: desde la señal original hasta el producto científico final, el dato atraviesa distintas fases de procesamiento, agregación y análisis. Cada transformación debe poder reconstruirse para entender cómo se llegó al resultado comunicado.

Sin trazabilidad exhaustiva, la reproducibilidad se debilita y la interpretabilidad futura se compromete. Cuando no es posible reconstruir el proceso completo que dio lugar a un resultado, su evaluación independiente se vuelve limitada y su reutilización científica pierde solidez.

3. Reproducibilidad a largo plazo

Las misiones espaciales pueden extenderse durante décadas, y sus datos pueden seguir siendo relevantes mucho después de que la misión haya finalizado. Además, la interpretación científica evoluciona con el tiempo: nuevos modelos, nuevas herramientas y nuevas preguntas pueden requerir volver a analizar información generada años atrás.

Por ello, los datos deben mantenerse interpretables incluso cuando los equipos originales ya no existen, los sistemas tecnológicos han cambiado o el contexto científico ha evolucionado.

Esto exige:

• Metadatos ricos y estructurados: la información contextual que acompaña al dato —sobre su origen, condiciones de adquisición, procesamiento y limitaciones— debe estar organizada de forma clara y normalizada. Sin metadatos suficientes, el dato pierde significado y se vuelve difícil de reinterpretar en el futuro.
• Identificadores persistentes: cada conjunto de datos debe poder localizarse y citarse de manera estable en el tiempo. Los identificadores persistentes permiten mantener la referencia incluso si cambian los sistemas de almacenamiento o las infraestructuras tecnológicas.
• Políticas de preservación digital robustas: la conservación a largo plazo requiere estrategias que contemplen la obsolescencia de formatos, la migración tecnológica y la integridad de los archivos. No basta con almacenar; es necesario asegurar que los datos sigan siendo accesibles y legibles con el paso del tiempo.
• Documentación accesible de los pipelines de procesamiento: el proceso que transforma el dato bruto en producto científico debe estar descrito de forma comprensible. Esto permite que investigadores futuros puedan reconstruir el análisis, verificar los resultados o aplicar nuevos métodos sobre los mismos datos originales.

La reproducibilidad, en este contexto, no significa repetir físicamente el fenómeno observado, sino poder reconstruir el proceso analítico que condujo a un resultado determinado. La gobernanza no solo gestiona el presente; garantiza la reutilización futura del conocimiento y preserva la capacidad de reinterpretar la información a la luz de nuevos avances científicos.

El siguiente visual resumen los tres desafíos: 

 Figura 2. Reglas para capturar datos espaciales documentados, trazables y auditables. Fuente: elaboración propia - datos.gob.es.

Conclusión: gobernar lo que no podemos tocar

Los datos del universo nos obligan a repensar cómo entendemos y gestionamos la información. Estamos trabajando con realidades que no podemos visitar, tocar ni comprobar directamente. Observamos fenómenos que ocurren a distancias inmensas y en tiempos que superan la escala humana, a través de instrumentos altamente especializados que traducen señales complejas en datos interpretables.

En este contexto, la incertidumbre no es un error ni una debilidad, sino una característica natural del estudio del cosmos. La interpretación de los datos depende de modelos científicos que evolucionan con el tiempo, y la calidad no se basa en una verificación directa, sino en procesos rigurosos, bien documentados y revisados por la comunidad científica. La confianza, por tanto, no surge de la experiencia directa, sino de la transparencia, la trazabilidad y la claridad con la que se explican los métodos utilizados.

Gobernar datos espaciales no significa únicamente almacenarlos o ponerlos a disposición del público. Significa conservar toda la información que permite entender cómo se obtuvieron, cómo se procesaron y bajo qué supuestos fueron interpretados. Solo así pueden ser evaluados, reinterpretados y reutilizados en el futuro.

Más allá de la Tierra, el gobierno del dato no es un detalle técnico ni una tarea administrativa. Es el fundamento que sostiene la credibilidad del conocimiento humano sobre el universo y la base que permite que nuevas generaciones continúen explorando lo que aún no podemos alcanzar físicamente.

Contenido elaborado por Mayte Toscano, Senior Consultant en Tecnologías ligadas a la economía del dato. Los contenidos y los puntos de vista reflejados en esta publicación son responsabilidad exclusiva de su autora

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.

Figura 1. Visual elaborado para explicar la diferencia entre SLI, SLO y SLA. Fuente: elaboración propia - datos.gob.es.

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.

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 acceso a datos a través de API se ha convertido en una de las piezas clave del ecosistema digital actual. Administraciones públicas, organismos internacionales y empresas privadas publican información para que terceros puedan reutilizarla en aplicaciones, análisis o proyectos de inteligencia artificial. En esta situación, hablar de datos abiertos es, casi inevitablemente, hablar también de API.

Sin embargo, el acceso a una API rara vez es completamente libre e ilimitado. Existen restricciones, controles y mecanismos de protección que buscan equilibrar dos objetivos que, a primera vista, pueden parecer opuestos: facilitar el acceso a los datos y garantizar la estabilidad, seguridad y sostenibilidad del servicio. Estas limitaciones generan dudas frecuentes: ¿son realmente necesarias?, ¿van contra el espíritu de los datos abiertos?, ¿hasta qué punto pueden aplicarse sin cerrar el acceso?

Este artículo aborda cómo se gestionan estas limitaciones, por qué son necesarias y cómo encajan —lejos de lo que a veces se piensa— dentro de una estrategia coherente de datos abiertos.

Por qué es necesario limitar el acceso a una API

Una API no es simplemente un “grifo” de datos. Detrás suele haber infraestructura tecnológica, servidores, procesos de actualización, costes operativos y equipos responsables de que el servicio funcione correctamente.

Cuando un servicio de datos se expone sin ningún tipo de control, aparecen problemas bien conocidos:

• Saturación del sistema, provocada por un número excesivo de consultas simultáneas.
• Uso abusivo, intencionado o no, que degrade el servicio para otros usuarios.
• Costes descontrolados, especialmente cuando la infraestructura está desplegada en la nube.
• Riesgos de seguridad, como ataques automatizados o scraping masivo.

En muchos casos, la ausencia de límites no conduce a más apertura, sino a un deterioro progresivo del propio servicio.

Por este motivo, limitar el acceso no suele ser una decisión ideológica, sino una necesidad práctica para asegurar que el servicio sea estable, predecible y justo para todos los usuarios.

La API Key: control básico, pero efectivo

El mecanismo más habitual para gestionar el acceso es la API Key. Mientras que en algunos casos como la API del catálogo nacional de datos abiertos de datos.gob.es no se requiere ningún tipo de clave para poder acceder a la información publicada, otros catálogos solicitan una clave única que identifica a cada usuario o aplicación y que se incluye en cada llamada a la API.

Aunque desde fuera pueda parecer una simple formalidad, la API Key cumple varias funciones importantes. Permite identificar quién consume los datos, medir el uso real del servicio, aplicar límites razonables y actuar ante comportamientos problemáticos sin afectar al resto de usuarios.

En el contexto español existen ejemplos claros de plataformas de datos abiertos que funcionan así. La Agencia Estatal de Meteorología (AEMET), por ejemplo, ofrece acceso abierto a datos meteorológicos de alto valor, pero exige solicitar una API Key gratuita para consultas automatizadas. El acceso es libre y gratuito, pero no anónimo ni descontrolado.

Hasta aquí, el enfoque es relativamente conocido: identificación del consumidor y límites básicos de uso. Sin embargo, en muchas situaciones nos esto ya no es suficiente.

Cuando la API se convierte en un activo estratégico

Las plataformas líderes de gestión de API, como MuleSoft o Kong entre otros, fueron pioneras en implantar mecanismos avanzados de control y protección del acceso a las API. Su foco inicial estaba ligado a entornos empresariales complejos, donde múltiples aplicaciones, organizaciones y países consumen servicios de datos de forma intensiva y continuada.

Con el tiempo, muchas de estas prácticas han ido extendiéndose también a plataformas de datos abiertos. A medida que ciertos servicios de datos abiertos ganan relevancia y se convierten en dependencias clave para aplicaciones, investigaciones o modelos de negocio, los retos asociados a su disponibilidad y estabilidad se vuelven similares. La caída o degradación de servicios de datos abiertos de gran escala —como los relacionados con observación de la Tierra, clima o ciencia— puede tener un impacto significativo en múltiples sistemas que dependen de ellos.

En este sentido, la gestión avanzada del acceso deja de ser una cuestión exclusivamente técnica y pasa a formar parte de la propia sostenibilidad de un servicio que se vuelve estratégico. No se trata tanto de quién publica los datos, sino del papel que esos datos juegan dentro de un ecosistema más amplio de reutilización. Por ello, muchas plataformas de open data están adoptando, de forma progresiva, mecanismos ya probados en otros ámbitos, adaptándolos a sus principios de apertura y acceso público. A continuación, se detallan algunos de ellos.

Limitar el caudal: regular el ritmo, no el derecho de acceso

Una de las primeras capas adicionales es la limitación del caudal de uso, lo que habitualmente se conoce como rate limiting. En lugar de permitir un número ilimitado de llamadas, se define cuántas peticiones pueden realizarse en un intervalo de tiempo determinado.

La clave aquí no es impedir el acceso, sino regular el ritmo. Un usuario puede seguir utilizando los datos, pero se evita que una única aplicación monopolice los recursos. Este enfoque es habitual en las API de datos meteorológicos, movilidad o estadísticas públicas, donde muchos usuarios acceden simultáneamente.

Las plataformas más avanzadas van un paso más allá y aplican límites dinámicos, que se ajustan según la carga del sistema, el momento del día o el comportamiento histórico del consumidor. El resultado es un control más justo y flexible.

Contexto, origen y comportamiento: más allá del volumen

Otra evolución importante es dejar de mirar solo cuántas llamadas se hacen y empezar a analizar desde dónde y cómo se realizan. Aquí entran medidas como la restricción por direcciones IP, el control geográfico (geofencing) o la diferenciación entre entornos de prueba y producción.

En algunos casos, estas limitaciones responden a marcos regulatorios o licencias de uso. En otros, simplemente permiten proteger partes más sensibles del servicio sin cerrar el acceso general. Por ejemplo, una API puede ser accesible globalmente en modo consulta, pero limitar determinadas operaciones a situaciones muy concretas.

Las plataformas también analizan patrones de comportamiento. Si una aplicación empieza a realizar consultas repetitivas, incoherentes o muy distintas a su uso habitual, el sistema puede reaccionar automáticamente: reducir temporalmente el caudal, lanzar alertas o exigir un nivel adicional de validación. No se bloquea “porque sí”, sino porque el comportamiento deja de encajar con un uso razonable del servicio.

Medir impacto, no solo llamadas

Una tendencia especialmente relevante es dejar de medir únicamente el número de peticiones y empezar a considerar el impacto real de cada una. No todas las consultas consumen los mismos recursos: algunas transfieren grandes volúmenes de datos o ejecutan operaciones más costosas.

Un ejemplo claro en datos abiertos sería una API de movilidad urbana. Consultar el estado de una parada o el tráfico en un punto concreto implica pocos datos y un impacto limitado. En cambio, descargar de una sola vez todo el histórico de posiciones de vehículos de una ciudad durante varios años supone una carga mucho mayor para el sistema, aunque se realice en una única llamada.

Por este motivo, muchas plataformas introducen cuotas basadas en volumen de datos transferidos, tipo de operación o peso de la consulta. Esto evita situaciones en las que un uso aparentemente moderado genera una carga desproporcionada sobre el sistema.

¿Cómo encaja todo esto con el open data?

Llegados a este punto, surge inevitablemente la pregunta: ¿siguen siendo abiertos los datos cuando existen todas estas capas de control?

La respuesta depende menos de la tecnología y más de las reglas del juego. Los datos abiertos no se definen por la ausencia total de control técnico, sino por principios como el acceso no discriminatorio, la ausencia de barreras económicas, la claridad en las licencias y la posibilidad real de reutilización.

Solicitar una API Key, limitar el caudal o aplicar controles contextuales no contradice estos principios si se hace de forma transparente y equitativa. De hecho, en muchos casos es la única manera de garantizar que el servicio siga existiendo y funcionando correctamente a medio y largo plazo.

La clave está en el equilibrio: reglas claras, acceso gratuito, límites razonables y mecanismos pensados para proteger el servicio, no para excluir. Cuando este equilibrio se consigue, el control deja de percibirse como una barrera y pasa a ser parte natural de un ecosistema de datos abiertos, útiles y sostenibles.

Los datos poseen una naturaleza fluida y compleja: cambian, crecen y evolucionan constantemente, mostrando una volatilidad que los diferencia profundamente del código fuente. Para responder al desafío de gestionar esta evolución de manera fiable, hemos elaborado la nueva "Guía técnica: Control de versiones de datos".

Esta guía aborda una disciplina emergente que adapta los principios de la ingeniería de software al ecosistema de datos: el Control de Versiones de Datos (CVD). El documento no solo explora los fundamentos teóricos, sino que ofrece un enfoque práctico para resolver problemas críticos en la gestión de datos, como la reproducibilidad de modelos de Machine Learning, la trazabilidad en auditorías regulatorias y la colaboración eficiente en equipos distribuidos.

¿Por qué es necesaria una guía sobre versionado de datos?

Históricamente, la gestión de versiones de datos se ha realizado de forma manual (archivos con sufijos "_final_v2.csv"), un enfoque propenso a errores e insostenible en entornos profesionales. Aunque herramientas como Git han revolucionado el desarrollo de software, no están diseñadas para manejar eficientemente archivos de gran volumen o binarios, características intrínsecas de los conjuntos de datos.

Esta guía nace para cubrir esa brecha tecnológica y metodológica, explicando las diferencias fundamentales entre versionar código y versionar datos. El documento detalla cómo herramientas especializadas como DVC (Data Version Control) permiten gestionar el ciclo de vida de los datos con la misma rigurosidad que el código, garantizando que siempre se pueda responder a la pregunta: "¿Qué datos exactos se usaron para obtener este resultado?".

Estructura y contenidos

El documento sigue un enfoque progresivo, partiendo de los conceptos básicos hasta llegar a la implementación técnica, estructurándose en los siguientes bloques clave:

• Fundamentos del versionado: análisis de la problemática actual (el "modelo fantasma", auditorías imposibles) y definición de conceptos clave como snapshots, linaje de datos y checksums.
• Estrategias y metodologías: adaptación del versionado semántico (SemVer) a los conjuntos de datos, estrategias de almacenamiento (incremental vs. completo) y gestión de metadatos para garantizar la trazabilidad.
• Herramientas en la práctica: un análisis detallado de herramientas como DVC, Git LFS y soluciones nativas en la nube (AWS, Google Cloud, Azure), incluyendo una comparativa para elegir la más adecuada según el tamaño del equipo y los datos.
• Caso de estudio práctico: un tutorial paso a paso sobre cómo configurar un entorno local con DVC y Git, simulando un ciclo de vida real de datos: desde la generación y primer versionado, hasta la actualización, sincronización remota y recuperación de versiones anteriores (rollback).
• Gobernanza y mejores prácticas: recomendaciones sobre roles, políticas de retención y compliance para asegurar una implementación exitosa en la organización.

Figura 1: Ejemplo práctico de uso de commandos GIT y DVC incluido en la guía.

¿A quién va dirigida?

Esta guía está diseñada para un perfil técnico amplio dentro del sector público y privado: científicos de datos, ingenieros de datos, analistas y responsables de catálogos de datos.

Es especialmente útil para aquellos profesionales que buscan profesionalizar sus flujos de trabajo, garantizar la reproducibilidad científica de sus investigaciones o asegurar el cumplimiento normativo en sectores regulados. Aunque se recomienda tener conocimientos básicos de Git y línea de comandos, la guía incluye ejemplos prácticos y explicaciones detalladas que facilitan el aprendizaje.

Vivimos rodeados de resúmenes generados por inteligencia artificial (IA). Tenemos la opción de generarlos desde hace meses, pero ahora se imponen en las plataformas digitales como el primer contenido que ven nuestros ojos al usar un buscador o abrir un hilo de emails. En plataformas como Microsoft Teams o Google Meet las reuniones por videollamada se transcriben y se resumen en actas automáticas para quien no ha podido estar presente, pero también para quien ha estado. Sin embargo, aquello que un modelo de lenguaje ha considerado importante, ¿es realmente lo importante para quien recibe el resumen?

En este nuevo contexto, la clave es aprender a recuperar el sentido detrás de tanta información resumida. Estas tres estrategias te ayudarán a transformar el contenido automático en una herramienta de comprensión y toma de decisiones.

1. Haz preguntas expansivas

Solemos resumir para reducir un contenido que no somos capaces de abarcar, pero corremos el riesgo de asociar breve con significativo, una equivalencia que no siempre se cumple. Por tanto, no deberíamos enfocarnos desde el inicio en resumir, sino en extraer información relevante para nosotros, nuestro contexto, nuestra visión de la situación y nuestra manera de pensar. Más allá del prompt básico “hazme un resumen”, esta nueva manera de enfocar un contenido que se nos escapa consiste en cruzar datos, conectar puntos y sugerir hipótesis, lo que llaman sensemaking o “construcción de sentido”. Y pasa, en primer lugar, por tener claro qué queremos saber.

Situación práctica:

Imaginemos una reunión larga a la que no hemos podido acudir. Esa tarde, recibimos en nuestro correo electrónico un resumen de los temas tratados. No siempre es posible, pero una buena práctica en este punto, si nuestra organización lo permite, es no quedarnos solo con el resumen: si está permitido, y siempre respetando las directrices de confidencialidad, sube la transcripción completa a un sistema conversacional como Copilot o Gemini y haz preguntas específicas:

• ¿Qué tema se repitió más o recibió más atención durante la reunión?

• En una reunión anterior, la persona X usó este argumento. ¿Se usó de nuevo? ¿Lo discutió alguien? ¿Se dio por válido?

• ¿Qué premisas, suposiciones o creencias están detrás de esta decisión que se ha tomado?

• Al final de la reunión, ¿qué elementos parecen más críticos para el éxito del proyecto?

• ¿Qué señales anticipan posibles retrasos o bloqueos? ¿Cuáles tienen que ver o podrían afectar a mi equipo?

Cuidado con:

Ante todo, revisa y confirma las atribuciones. Los modelos generativos son cada vez más precisos, pero tienen una gran capacidad para mezclar información real con información falsa o generada. Por ejemplo, pueden atribuir una frase a alguien que no la dijo, relacionar como causa-efecto ideas que en realidad no tenían conexión, y seguramente lo más importante: asignar tareas o responsabilidades de próximos pasos a alguien a quien no le corresponden.

2. Pide contenido estructurado

Los buenos resúmenes no son más cortos, sino más organizados, y el texto redactado no es el único formato al que podemos recurrir. Busca la eficacia y pide a los sistemas conversacionales que te devuelvan tablas, categorías, listas de decisiones o mapas de relaciones. La forma condiciona el pensamiento: si estructuras bien la información, la entenderás mejor y también la transmitirás mejor a otros, y por tanto irás más lejos con ella.

Situación práctica:

En este caso, imaginemos que recibimos un informe largo sobre el avance de varios proyectos internos de nuestra empresa. El documento tiene muchas páginas con párrafos descriptivos de estado, feedback, fechas, imprevistos, riesgos y presupuestos. Leerlo todo línea por línea sería imposible y no retendríamos la información. La buena práctica aquí es pedir una transformación del documento que nos sea útil de verdad. Si es posible, sube el informe al sistema conversacional y solicita contenido estructurado de manera exigente y sin escatimar en detalles:

• Organiza el informe en una tabla con las siguientes columnas: proyecto, responsable, fecha de entrega, estado, y una columna final que indique si ha ocurrido algún imprevisto o se ha materializado algún riesgo. Si todo va bien, imprime en esa columna “CORRECTO”.

• Genera un calendario visual con los entregables, sus fechas de entrega y los responsables, que empiece el 1 de octubre de 2025 y termine el 31 de enero de 2026, en forma de diagrama de Gantt.

• Quiero una lista en la que aparezcan exclusivamente el nombre de los proyectos, su fecha de inicio y su fecha de entrega. Ordena por la fecha de entrega, las más cercanas primero.

• Del apartado de feedback de los clientes que encontrarás en cada proyecto, crea una tabla con los comentarios más repetidos y a qué áreas o equipos suelen hacer referencia. Colócalos en orden, de los que más se repiten a los que menos.

• Dame la facturación de los proyectos que están en riesgo de no cumplir plazos, indica el precio de cada uno y el total.

Cuidado con:

La ilusión de veracidad y exhaustividad que nos va a proporcionar un texto limpio, ordenado, automático y con fuentes es enorme. Un formato claro, como una tabla, una lista o un mapa, puede dar una falsa sensación de precisión. Si los datos de origen son incompletos o erróneos, la estructura solo maquilla el error y tendremos más dificultades para verlo. Las producciones de la IA suelen ser casi perfectas. Como mínimo, y si el documento es muy extenso, haz comprobaciones aleatorias ignorando la forma y centrándote en el contenido.

3. Conecta los puntos

El sentido estratégico rara vez está en un texto aislado, y mucho menos en un resumen. El nivel avanzado en este caso consiste en pedir al chat multimodal que cruce fuentes, compare versiones o detecte patrones entre varios materiales o formatos, como por ejemplo la transcripción de una reunión, un informe interno y un artículo científico. Lo que interesa realmente ver son claves comparativas como los cambios evolutivos, las ausencias o las inconsistencias.

Situación práctica:

Imaginemos que estamos preparando una propuesta para un nuevo proyecto. Tenemos varios materiales: la transcripción de una reunión del equipo directivo, el informe interno del año anterior y un artículo reciente sobre tendencias del sector. En lugar de resumirlos por separado, puedes subirlos al mismo hilo de conversación o a un chat que hayas personalizado sobre el tema, y pedirle acciones más ambiciosas.

• Compara estos tres documentos y dime qué prioridades coinciden en todos, aunque se expresen de maneras distintas.

• ¿Qué temas del informe interno no se han mencionado en la reunión? Genera una hipótesis para cada uno sobre por qué no se han tratado.

• ¿Qué ideas del artículo podrían reforzar o cuestionar las nuestras? Dame ideas fuerza de la investigación que no estén reflejadas en nuestro informe interno.

• Busca artículos en prensa de los últimos seis meses que avalen las ideas fuerza del informe interno.

• Encuentra fuentes externas que complementen la información ausente en estos tres documentos sobre el tema X y genera un informe panorámico con referencias.

Cuidado con:

Es muy habitual que los sistemas de IA simplifiquen de forma engañosa debates complejos, no porque tengan un objetivo oculto sino porque en el entrenamiento se les ha premiado siempre la sencillez y la claridad. Además, la generación automática introduce un riesgo de autoridad: como el texto se presenta con apariencia de precisión y neutralidad, asumimos que es válido y útil. Y, por si fuera poco, los resúmenes estructurados se copian y comparten rápido. Antes de reenviar, asegúrate de que el contenido está validado, sobre todo si contiene decisiones, nombres o datos sensibles.

Conclusión

Los modelos basados en IA pueden ayudarte a visualizar convergencias, lagunas o contradicciones y, a partir de ahí, formular hipótesis o líneas de acción. Se trata de encontrar con mayor agilidad eso tan valioso que llamamos insights. Ese es el paso del resumen al análisis: lo más importante no es comprimir la información, sino seleccionarla bien, relacionarla y conectarla con el contexto. Intensificar la exigencia desde el prompt es la manera más adecuada de trabajar con los sistemas IA, pero también nos exige un esfuerzo personal previo de análisis y aterrizaje.

Contenido elaborado por Carmen Torrijos, experta en IA aplicada al lenguaje y la comunicación. Los contenidos y los puntos de vista reflejados en esta publicación son responsabilidad exclusiva de su autor.

La Inteligencia Artificial (IA) está transformando la sociedad, la economía y los servicios públicos a una velocidad sin precedentes. Esta revolución trae enormes oportunidades, pero también desafíos relacionados con la ética, la seguridad y la protección de derechos fundamentales. Consciente de ello, la Unión Europea aprobó la Ley de Inteligencia Artificial (AI Act), en vigor desde el 1 de agosto de 2024, que establece un marco armonizado y pionero para el desarrollo, la comercialización y el uso de sistemas de IA en el mercado único, fomentando la innovación mientras protege a la ciudadanía.

Un ámbito especialmente relevante de esta normativa son los modelos de IA de propósito general (GPAI), como los grandes modelos de lenguaje (LLM) o los modelos multimodales, que se entrenan con enormes volúmenes de datos de muy diversa procedencia (texto, imágenes y vídeo, audio e incluso datos generados por usuarios). Esta realidad plantea retos críticos en propiedad intelectual, protección de datos y transparencia sobre el origen y el tratamiento de la información.

Para afrontarlos, la Comisión Europea, a través de la Oficina Europea de IA, ha publicado la Plantilla de Resumen Público de los Datos de Entrenamiento: un formato estandarizado que los proveedores deberán completar y publicar para resumir información clave sobre los datos usados en el entrenamiento. A partir del 2 de agosto de 2025, todo modelo de propósito general que se comercialice o distribuya en la UE deberá ir acompañado de este resumen; los modelos ya presentes en el mercado disponen hasta el 2 de agosto de 2027 para adaptarse. Esta medida materializa el principio de transparencia de la AI Act y pretende arrojar luz sobre las “cajas negras” de la IA.

En este artículo te contamos las claves de esta plantilla: desde sus objetivos y estructura, hasta información sobre plazos, sanciones y próximos pasos.

Objetivos y relevancia de la plantilla

Los modelos de IA de propósito general se entrenan con datos de muy diversa procedencia y modalidad, como:

• Texto: libros, artículos científicos, prensa o redes sociales.

• Imágenes y vídeos: contenidos digitales de Internet y colecciones visuales.

• Audio: grabaciones, pódcast, programas de radio o conversaciones.

• Datos de usuarios: información generada en la interacción con el propio modelo o con otros servicios del proveedor.

Este proceso de recopilación masiva de datos suele ser opaco, lo que genera preocupación entre titulares de derechos, usuarios, reguladores y la sociedad en su conjunto. Sin transparencia, resulta difícil evaluar si los datos se han obtenido de forma legal, si incluyen información personal no autorizada o si representan adecuadamente la diversidad cultural y lingüística de la Unión Europea.

El Considerando 107 de la AI Act establece que el objetivo principal de esta plantilla es incrementar la transparencia y facilitar el ejercicio y la protección de derechos. Entre los beneficios que aporta destacan:

1. Protección de la propiedad intelectual: permite que autores, editores y demás titulares de derechos identifiquen si sus obras han sido utilizadas durante el entrenamiento, facilitando la defensa de sus derechos y un uso justo de sus contenidos.

2. Salvaguarda de la privacidad: ayuda a detectar si se han empleado datos personales, aportando información útil para que las personas afectadas puedan ejercer sus derechos conforme al Reglamento General de Protección de Datos (RGPD) y otras normas del mismo ámbito.

3. Prevención de sesgos y discriminación: proporciona información sobre la diversidad lingüística y cultural de las fuentes utilizadas, clave para evaluar y mitigar sesgos que puedan generar discriminaciones.

4. Fomento de la competencia y la investigación: reduce los efectos de “caja negra” y facilita el escrutinio académico, al tiempo que ayuda a otras empresas a comprender mejor la procedencia de los datos, favoreciendo mercados más abiertos y competitivos.

En definitiva, esta plantilla no es solo un requisito legal, sino una herramienta para generar confianza en la inteligencia artificial, creando un ecosistema en el que la innovación tecnológica y la protección de derechos se refuercen mutuamente.

Estructura de la plantilla

La plantilla, publicada oficialmente el 24 de julio de 2025 tras una consulta pública con más de 430 organizaciones participantes, ha sido diseñada para que la información se presente de forma clara, homogénea y comprensible, tanto para especialistas como para la ciudadanía.

Se compone de tres secciones principales, que abarcan desde la identificación básica del modelo hasta los aspectos legales relacionados con el tratamiento de los datos.

1. Información general

Proporciona una visión global sobre el proveedor, el modelo y las características generales de los datos de entrenamiento:

• Identificación del proveedor, como nombre y datos de contacto.

• Identificación del modelo y sus versiones, incluyendo dependencias si se trata de una modificación (fine-tuning) de otro modelo.

• Fecha de puesta en el mercado del modelo en la UE.

• Modalidades de datos utilizadas (texto, imagen, audio, vídeo u otras).

• Tamaño aproximado de los datos por modalidad, expresado en rangos amplios (por ejemplo, menos de 1.000 millones de tokens, entre 1.000 millones y 10 billones, más de 10 billones).

• Cobertura lingüística, con especial atención a las lenguas oficiales de la Unión Europea.

Esta sección ofrece un nivel de detalle suficiente para comprender la magnitud y naturaleza del entrenamiento, sin revelar secretos comerciales.

2. Lista de fuentes de datos

Es el núcleo de la plantilla, donde se detalla la procedencia de los datos de entrenamiento. Está organizada en seis categorías principales, además de una categoría residual (Otros).

1. Conjuntos de datos públicos:

   • Datos disponibles gratuitamente y descargables como un todo o en bloques (p. ej., portales de datos abiertos, Common Crawl, repositorios académicos).

   • Se deben identificar los conjuntos “grandes”, definidos como aquellos que representan más del 3% del total de datos públicos utilizados en una modalidad específica.

2. Conjuntos privados licenciados:

   • Datos obtenidos mediante acuerdos comerciales con titulares de derechos o sus representantes, como licencias con editoriales para el uso de libros digitales.

   • Se proporciona únicamente una descripción general.

3. Otros datos privados no licenciados:

   • Bases de datos adquiridas a terceros que no gestionan directamente los derechos de autor.

   • Si son públicamente conocidas, deben listarse; si no, basta una descripción general (tipo de datos, naturaleza, idiomas).

4. Datos obtenidos mediante web crawling/scraping:

   • Información recopilada por el proveedor o en su nombre mediante herramientas automatizadas.

   • Se debe especificar:

     • Nombre/identificador de los rastreadores.

     • Finalidad y comportamiento (respeto a robots.txt, captchas, paywalls, etc.).

     • Periodo de recogida.

     • Tipos de sitios web (medios, redes sociales, blogs, portales públicos, etc.).

     • Lista de dominios más relevantes, que cubra al menos el 10% superior por volumen. Para PYMES, este requisito se ajusta al 5% o un máximo de 1.000 dominios, lo que sea menor.

5. Datos de usuarios:

   • Información generada a través de la interacción con el modelo o con otros servicios del proveedor.

   • Se debe indicar qué servicios contribuyen y la modalidad de los datos (texto, imagen, audio, etc.).

6. Datos sintéticos:

   • Datos creados por o para el proveedor mediante otros modelos de IA (por ejemplo, destilación de modelos o refuerzo con retroalimentación humana - RLHF).

   • Cuando corresponda, se debe identificar el modelo generador si está disponible en el mercado.

Categoría adicional – Otros: incluye datos que no encajan en las categorías anteriores, como fuentes offline, digitalización propia, etiquetado manual o generación humana.

3. Aspectos del procesamiento de datos

Se centra en cómo se han gestionado los datos antes y durante el entrenamiento, con especial atención al cumplimiento legal:

• Respeto a las reservas de derechos (Text and Data Mining, TDM): medidas adoptadas para honrar el derecho de exclusión previsto en el artículo 4(3) de la Directiva 2019/790 sobre derechos de autor, que permite a los titulares impedir la minería de textos y datos. Este derecho se ejerce mediante protocolos de opt-out, como etiquetas en archivos o configuraciones en robots.txt, que indican que ciertos contenidos no pueden usarse para entrenar modelos. Los proveedores deben explicar cómo han identificado y respetado estos opt-outs en sus propios datasets y en los adquiridos a terceros.

• Eliminación de contenido ilegal: procedimientos utilizados para evitar o depurar contenido ilícito bajo la legislación de la UE, como material de abuso sexual infantil, contenidos terroristas o infracciones graves de propiedad intelectual. Estos mecanismos pueden incluir listas negras, clasificadores automáticos o revisión humana, pero sin revelar secretos empresariales.

El siguiente visual resumen estos tres apartados:

Equilibrio entre transparencia y secretos comerciales

La Comisión Europea ha diseñado la plantilla buscando un equilibrio delicado: ofrecer información suficiente para proteger derechos y fomentar la transparencia, sin obligar a revelar información que pueda comprometer la competitividad de los proveedores.

• Fuentes públicas: se exige el mayor nivel de detalle, incluyendo nombres y enlaces a los conjuntos de datos “grandes”.

• Fuentes privadas: se permite un nivel de detalle más limitado, mediante descripciones generales cuando la información no sea pública.

• Web scraping: se requiere un listado resumido de dominios, sin necesidad de detallar combinaciones exactas.

• Datos de usuarios y sintéticos: la información se limita a confirmar su uso y describir la modalidad.

Gracias a este enfoque, el resumen es “generalmente completo” en alcance, pero no “técnicamente detallado”, protegiendo tanto la transparencia como la propiedad intelectual y comercial de las empresas.

Cumplimiento, plazos y sanciones

El artículo 53 de la AI Act detalla las obligaciones de los proveedores de modelos de propósito general, entre las que destaca la publicación de este resumen de datos de entrenamiento.

Esta obligación se complementa con otras medidas, como:

• Disponer de una política pública de derechos de autor.

• Implementar procesos de evaluación y mitigación de riesgos, especialmente para modelos que puedan generar riesgos sistémicos.

• Establecer mecanismos de trazabilidad y supervisión de los datos y procesos de entrenamiento.

El incumplimiento puede acarrear multas significativas, de hasta 15 millones de euros o el 3% de la facturación global anual de la empresa, lo que suponga una mayor cantidad.

Próximos pasos para los proveedores

Para adaptarse a esta nueva obligación, los proveedores deberían:

1. Revisar procesos internos de recopilación y gestión de datos para garantizar que la información necesaria esté disponible y sea verificable.

2. Establecer políticas claras de transparencia y derechos de autor, incluyendo protocolos para respetar el derecho de exclusión en minería de textos y datos (TDM).

3. Publicar el resumen en canales oficiales antes de la fecha límite correspondiente.

4. Actualizar el resumen periódicamente, al menos cada seis meses o cuando se produzcan cambios materiales en el entrenamiento.

La Comisión Europea, a través de la Oficina Europea de IA, supervisará el cumplimiento y podrá solicitar correcciones o imponer sanciones.

Una herramienta clave para gobernar los datos

En nuestro artículo anterior, “Gobernar los datos para gobernar la Inteligencia Artificial”, destacábamos que una IA confiable solo es posible si existe un gobierno sólido de los datos.

Esta nueva plantilla refuerza ese principio, ofreciendo un mecanismo estandarizado para describir el ciclo de vida de los datos, desde su origen hasta su tratamiento, y fomentando la interoperabilidad y la reutilización responsable.

Se trata de un paso decisivo hacia una IA más transparente, justa y alineada con los valores europeos, donde la protección de derechos y la innovación tecnológica puedan avanzar juntas.

Conclusiones

La publicación de la Plantilla de Resumen Público marca un hito histórico en la regulación de la IA en Europa. Al exigir que los proveedores documenten y hagan públicos los datos utilizados en el entrenamiento, la Unión Europea da un paso decisivo hacia una inteligencia artificial más transparente y confiable, basada en la responsabilidad y el respeto a los derechos fundamentales. En un mundo donde los datos son el motor de la innovación, esta herramienta se convierte en la clave para gobernar los datos antes de gobernar la IA, asegurando que el desarrollo tecnológico se construya sobre la confianza y la ética.

Contenido elaborado por Dr. Fernando Gualo, Profesor en UCLM y Consultor de Gobierno y Calidad de datos. El contenido y el punto de vista reflejado en esta publicación es responsabilidad exclusiva de su autor.

Para alcanzar sus objetivos de sostenibilidad medioambiental, Europa necesita información precisa, accesible y actualizada que permita tomar decisiones basadas en evidencias. El Espacio de Datos del Pacto Verde (Green Deal Data Space o GDDS) facilitará esta transformación al integrar diversas fuentes de datos en una infraestructura digital común, interoperable y abierta.

Desde Europa, se está trabajando en su desarrollo a través de diversos proyectos, que han permitido obtener recomendaciones y buenas prácticas para su implementación. ¡Descúbrelas en este artículo!

¿Qué es el Green Deal Data Space?

El Green Deal Data Space (GDDS) es una iniciativa de la Comisión Europea para crear un ecosistema digital que reúna datos de múltiples sectores. Su fin es apoyar y acelerar los objetivos del Pacto Verde: la hoja de ruta de la Unión Europea para lograr una economía sostenible, climáticamente neutra y justa. Los pilares del Pacto Verde incluyen:

• Una transición energética que reduzca las emisiones y mejore la eficiencia.
• El fomento de la economía circular, promoviendo el reciclaje, la reutilización y la reparación de productos para minimizar residuos.
• El impulso de prácticas agrícolas más sostenibles.
• La restauración de la naturaleza y la biodiversidad, protegiendo hábitats naturales y reduciendo la contaminación de aire, agua y suelo.
• La garantía de la justicia social, a través de una transición que facilite que ningún país o comunidad quede atrás.

A través de esta estrategia integral, la UE aspira a convertirse en la primera economía del mundo competitiva y eficiente en el uso de los recursos, logrando emisiones netas de gases de efecto invernadero cero para 2050. El Espacio de Datos del Pacto Verde se posiciona como una herramienta clave para alcanzar estos objetivos. Integrados en la Estrategia Europea del Dato, los espacios de datos son entornos digitales que permite el intercambio fiable de datos, al tiempo que se mantiene la soberanía y se garantiza la confianza y la seguridad en virtud de un conjunto de normas acordadas mutuamente.

En este caso concreto, el GDDS integrará datos de gran valor sobre biodiversidad, contaminación cero, economía circular, cambio climático, servicios forestales, movilidad inteligente y cumplimiento medioambiental. Estos datos serán fáciles de localizar, interoperables, accesibles y reutilizables bajo los principios FAIR (Findability, Accessibility, Interoperability, Reusability).

El GDDS se implementará a través del proyecto SAGE (Espacio de datos para una Europa verde y sostenible) y se basará en los resultados de la iniciativa GREAT (Gobernanza de la innovación responsable).

Un informe con recomendaciones para el GDDS

Como vimos en un artículo anterior, cuatro proyectos pioneros están sentando las bases de este ecosistema: AD4GD, B-Cubed, FAIRiCUBE y USAGE.  Estos proyectos, financiados en el marco de la convocatoria HORIZON, han analizado y documentado durante varios años los requisitos necesarios para garantizar que el GDDS siga los principios FAIR. Fruto de ese trabajo, se ha elaborado el informe “Policy Brief: Unlocking The Full Potential Of The Green Deal Data Space”. Se trata de un conjunto de recomendaciones que buscan servir de guía para la implementación exitosa del Espacio de Datos del Pacto Verde. 

El informe destaca cinco grandes áreas en las que se concentran los desafíos de la construcción del GDDS: 

1. Armonización de datos 

Los datos ambientales son heterogéneos, ya que provienen de distintas fuentes: satélites, sensores, estaciones meteorológicas, registros de biodiversidad, empresas privadas, institutos de investigación, etc. Cada proveedor utiliza sus propios formatos, escalas y metodologías. Esto provoca incompatibilidades que dificultan la comparación y la combinación de datos. Para solucionarlo, es esencial:

• Adoptar estándares y vocabularios internacionales ya existentes, como INSPIRE, que abracan múltiples ámbitos temáticos.
• Evitar formatos propietarios, primando aquellos abiertos y bien documentados.
• Invertir en herramientas que permitan transformar datos de un formato a otro de forma sencilla.

2. Interoperabilidad semántica

Garantizar la interoperabilidad semántica es crucial para que los datos puedan entenderse y reutilizarse en diferentes contextos y disciplinas, algo fundamental cuando se comparten datos entre comunidades tan diversas como las que participan en los objetivos del Pacto Verde. A ello hay que sumar que la Ley de Datos (Data Act) obliga a que los participantes en espacios de datos ofrezcan descripciones legibles por máquinas de los datasets, garantizando así su localización, acceso y reutilización. Además, exige que los vocabularios, taxonomías y listas de códigos empleados estén documentados de forma pública y coherente. Para lograrlo es necesario:

• Usar datos enlazados (linked data) y metadatos que ofrezcan conceptos claros y compartidos, a través de vocabularios, ontologías y estándares como los desarrollados por el OGC o las normas ISO.
• Usar los estándares que ya existen para organizar y describir los datos, y solo crear extensiones nuevas cuando sea realmente necesario.
• Mejorar los vocabularios internacionales ya aceptados, dándoles más precisión y aprovechando que las comunidades científicas ya los utilizan ampliamente.

3. Metadatos y curación de datos

Los datos solo alcanzan su máximo valor si están acompañados de metadatos claros que expliquen su origen, calidad, restricciones de uso y condiciones de acceso. Sin embargo, la gestión deficiente de metadatos sigue siendo una barrera importante. En muchos casos, los metadatos son inexistentes, están incompletos o mal estructurados, y a menudo se pierden al traducirse entre estándares no interoperables. Para mejorar esta situación se debe:

• Ampliar los estándares de metadatos existentes para incluir elementos críticos como observaciones, mediciones, trazabilidad de origen, etc.
• Fomentar la interoperabilidad entre estándares de metadatos en uso, mediante herramientas de mapeo y transformación que respondan tanto a las necesidades de datos comerciales como abiertos.
• Reconocer y financiar la creación y mantenimiento de metadatos en proyectos europeos, incorporando la obligación de generar un catálogo estandarizado desde el inicio en los planes de gestión de datos.

4. Intercambio de datos y provisión federada

El GDDS no busca solo centralizar toda la información en un solo repositorio, sino permitir que múltiples actores compartan datos de manera federada y segura. Por tanto, es necesario conseguir un equilibrio entre el acceso abierto y la protección de derechos y privacidad. Para ello se requiere:

• Adoptar y promover tecnologías abiertas y fáciles de usar, que permitan la integración entre datos abiertos y protegidos, cumpliendo con el Reglamento General de Protección de Datos (RGPD).
• Garantizar la integración de diversas API utilizadas por los proveedores de datos y las comunidades de usuarios, acompañadas de demostradores y directrices claras. No obstante, es necesario impulsar el uso de API estandarizadas para facilitar una implantación más fluida, como por ejemplo, las API de OGC (Open Geospatial Consortium) para activos geoespaciales.
• Ofrecer herramientas de conversión y especificaciones claras para permitir la interoperabilidad entre API y formatos de datos.

En paralelo al desarrollo del Eclipse Dataspace Connectors  (una tecnología de código abierto para facilitar la creación de espacios de datos), se propone explorar alternativas como catálogos en blockchain o certificados digitales, siguiendo ejemplos como el sistema FACTS (Federated Agile Collaborative Trusted System).

5. Gobernanza inclusiva y sostenible

El éxito del GDDS dependerá de establecer un marco de gobernanza sólido que garantice transparencia, participación y sostenibilidad a largo plazo. No se trata solo de normas técnicas, sino también de reglas justas y representativas. Para avanzar en ello es clave:

• Usar exclusivamente nubes europeas para asegurar la soberanía de los datos, reforzar la seguridad y cumplir con la normativa de la UE, algo que cobra especial importancia ante los desafíos globales actuales.
• Integrar plataformas abiertas como Copernicus, el Portal Europeo de Datos e INSPIRE en el GDDS fortalece la interoperabilidad y facilita el acceso a datos públicos. En este sentido, es necesario diseñar estrategias eficaces para atraer proveedores de datos abiertos y evitar que el GDDS se convierta en un entorno comercial o restringido.
• Obligar a citar los datos en publicaciones académicas financiadas con fondos públicos aumenta su visibilidad y apoyar iniciativas de estandarización fortalece la visibilidad de los datos y asegura su mantenimiento a largo plazo.
• Ofrecer formación integral y promover el uso cruzado de herramientas de armonización evita la creación de nuevos silos de datos y mejora la colaboración entre dominios.

La siguiente imagen resume la relación entre estos bloques: 

Conclusión

Todas estas recomendaciones inciden en una idea central: construir un Espacio de Datos del Pacto Verde que cumpla con los principios FAIR no solo es una cuestión técnica, sino también estratégica y ética. Requiere colaboración entre sectores, compromiso político, inversión en capacidades y una gobernanza inclusiva que garantice la equidad y la sostenibilidad. Si Europa logra consolidar este ecosistema digital, estará mejor preparada para afrontar los desafíos medioambientales con decisiones informadas, transparentes y orientadas al bien común.