Ciencia y tecnología

Introducción

El baile celestial de los astros en el sistema solar ofrece cada cierto tiempo espectáculos únicos y singulares, como el fenómeno del eclipse total que se pudo contemplar en la península ibérica este año, y que se podrá ver de nuevo en 2027 y 2028. Durante un eclipse total, la Luna se interpone entre la Tierra y el Sol, ocultando al astro rey y proyectando durante unos minutos una sombra sobre una parte de la superficie terrestre.

El eclipse total del 12 de agosto de 2026 tuvo su comienzo hacia las 20h30 horas (GMT+01:00), cubriendo de penumbra desde Galicia hasta las Islas Baleares a lo largo de la hora y media de duración del eclipse.

El Centro Nacional de Información Geográfica (CNIG) ha puesto a disposición del público unos conjuntos de datos que ofrecen un amplio espectro de información astronómica relativa tanto al eclipse del pasado agosto como a los que se van a producir sobre la península ibérica durante los próximos dos años.

Estos conjuntos de datos incluyen información sobre la visibilidad por el propio relieve del terreno a la hora del eclipse, la duración del eclipse en cada punto de la geografía española, el nivel de oscurecimiento o la elevación del Sol en el punto máximo del eclipse, así como la sombra proyectada por la Luna en su trayecto por delante del Sol.

En este ejercicio  accederemos a los conjuntos de datos del CNIG y abriremos los ficheros tipo .TIFF y .GPKG con toda la información relativa al eclipse, y en concreto con todo lo relacionado con las zonas de sombra, tanto en lo referente a la visibilidad por efecto del relieve en la península, como en lo que respecta a la zona de sombra en sí debido al eclipse total.

Una vez hayamos accedido a los datos, delimitaremos nuestro análisis a una zona concreta sobre la visibilidad por relieve, recortaremos los datos originales con el perímetro de un municipio, exportaremos el resultado en formato GeoJSON y, haciendo uso de éste, seremos capaces de crear diferentes tipos de mapas con diversas herramientas útiles e intuitivas tales como KeplerGL, GoogleEarth, Leaflet o D3.js.

Datos para el ejercicio

Los datos disponibles para realizar este ejercicio se encuentran accesibles en el Catálogo de datos abiertos de datos.gob.es y constan de tres ficheros con información relevante para describir y caracterizar el eclipse. En concreto encontramos:

• Sombras del terreno: fichero donde se describe la visibilidad por relieve en una malla de puntos que cubre la península ibérica y la parte occidental del norte de África.
• Curvas de nivel: fichero que contiene la duración, el oscurecimiento máximo y las curvas de penumbra proyectadas desde la Luna sobre la Tierra.
• Efemérides: fichero que alberga las efemérides del eclipse, tales como elevación, azimut, salida y puesta de sol, así como inicio y final del eclipse.

En este ejercicio nos centraremos en los dos primeros , ya que contienen información sobre la sombra proyectada tanto por el relieve como por la Luna sobre la península ibérica.

Adicionalmente, recurriremos igualmente al Catálogo de datos para obtener el perímetro en formato SHP de algún municipio que nos permita analizar en detalle la sombra por relieve. De esta forma completaremos el acceso y lectura de tres formatos de datos georreferenciados diferentes:

• TIFF: formato popular para información gráfica de alta resolución que tolera altos grados de compresión sin pérdida de información y que por lo tanto es muy manejable. Las siglas hacen referencia a Tagged Image File Format.  
• GPKG: acrónimo de GeoPackage. Este formato se utiliza en sistemas de información geográfica para almacenar datos tanto en modo ráster como modo vectorial.
• SHP: formato de datos vectorial que contiene localizaciones geométricas, muy utilizado también en sistemas de información geográfica. Contiene exclusivamente puntos, líneas o polígonos y se compone de varios ficheros que contienen índices o atributos.

El formato SHP lo necesitaremos para disponer del perímetro de un municipio y así poder limitar nuestro estudio a una zona en concreta de interés. Dentro del Catálogo de datos tenemos perímetros municipales en el País Vasco en este conjunto de datos. Dentro de este fichero SHP podremos elegir uno de esos municipios ya que vienen caracterizados por su nombre.  

Proceso de desarrollo

En esta sección veremos las diferentes etapas que hay que cubrir para llegar desde el fichero comprimido original hasta desplegar mapas en diversas plataformas con la información relevante del eclipse total. El código de lectura y tratamiento de datos se ha realizado en Python y se puede consultar en Github, en Google Colab y, el resultado, en Observable. El repositorio en Github se encuentra en el siguiente enlace:

Accede al repositorio del laboratorio de datos en GitHub

En Google Colab tenemos dos notebooks. El primero nos permite extraer y representar las zonas de sombra por el relieve natural a la hora del eclipse, mientras que el segundo nos permite obtener y visualizar las zonas de sombra creadas por el eclipse en sí:

Accede a los notebooks de Google Colab

Por último, en Observable podemos consultar el código que nos permite crear los mapas con la información extraída tanto en Leaflet como en D3.js:  

Accede a los notebooks de Observable

1. Visibilidad por relieve  

El primer paso de este ejercicio consiste en identificar puntos en los cuales el eclipse fue visible en condiciones ideales sin ningún tipo de nubosidad, circunstancia que no fue completamente ideal el día del eclipse, sobre todo en zonas costeras donde el calor generó brumas y niebla a última hora de la tarde.

Los datos que analizamos hacen referencia a los puntos afectados por el propio relieve y orografía de la península ibérica. Los datos ofrecidos en formato .TIFF detallan aquellos puntos donde la visibilidad fue total, parcial o nula por efecto del relieve asignando cuatro valores:  

• Valor 0: el terreno impide ver el eclipse.
• Valor 1: el terreno permite ver la mitad superior del Sol.  
• Valor 2: el terreno permite ver la mitad superior y parte de la inferior del Sol.
• Valor 3: el terreno permite ver en Sol en su integridad.

1.1 Lectura del fichero TIFF

Para la lectura del .TIFF utilizaremos la librería Rioxarray de Python, que nos permite volcar el contenido de un TIFF en un xarray, una estructura de datos ampliamente utilizada para trabajar con información georreferenciada. Una vez cargados los datos y formateados como xarray, es posible recurrir a la librería Matplotlib para crear un mapa e inspeccionar el ámbito geográfico que comprende, mostrado a continuación.  

Figura 1: Mapa de visibilidad por relieve del Sol el 12 de agosto de 2026. Fuente: elaboración propia -datos.gob.es.    

Los datos, como se mencionaba en la introducción, abarcan toda la península ibérica, parte de Francia y la zona occidental del norte de África, de forma que las Islas Baleares y las Canarias forman parte de un único conjunto de datos. Se puede observar en este punto cómo las zonas de sombra se relacionan de forma intuitiva con la orografía de cordilleras y mesetas, así como con la puesta de sol y la sombra que induce en el levante a la hora del eclipse.  

Otra información relevante que podemos observar es la resolución de este conjunto de datos. En los ejes x e y se puede ver el número de puntos aproximado en cada una de las dimensiones, lo que se traduce en una alta resolución orientada a obtener el mayor detalle posible.  

Dado que nuestro objetivo es desarrollar mapas y visualizaciones que puedan ser publicadas en la web, así como el tratamiento ágil de datos, nos centraremos en una zona en concreta, tomando como muestra la extensión de un municipio. De este modo, los ficheros de salida son relativamente ligeros y siempre por debajo de los 10Mb, permitiendo que los navegadores actuales sean capaces de procesarlos de forma rápida y eficiente.  

1.2 Perímetro de estudio  

Utilizando los datos sobre los perímetros municipales en el País Vasco, procedemos a la lectura del fichero SHP y a su estructuración en formato GeoPandas, una librería de Python que permite crear geometrías asociadas a una serie de propiedades y atributos de forma intuitiva.  

Para la realización de este ejercicio seleccionamos el municipio de Amurrio, ya que presenta una orografía diversa que nos permite tener todo el espectro posible de visibilidades. En la siguiente imagen podemos observar los límites del municipio utilizando la librería Matplotlib de Python, contextualizados en coordenadas de longitud y latitud.  

Figura 2: Mapa del perímetro del municipio de Amurrio en el País Vasco a partir del SHP accesible como datos abiertos. Fuente: elaboración propia -datos.gob.es.  

1.3 Recorte del perímetro  

Gracias a la librería Shapely de Python es posible recortar un xarray con la información municipal contenida en el GeoPandas. Una vez recortado, utilizamos Matplotlib para representar el subconjunto de datos, donde observamos la variedad de valores y, por tanto, la diversidad de lugares con visibilidad total, parcial o nula en una región relativamente pequeña dentro de lo que es la extensión de la península ibérica. A continuación observamos el patrón de una zona dominante de buena visibilidad y de otras de visibilidad más pobre.  

Figura 3: Mapa de las zonas de sombra naturales por elevación del terreno a la hora del eclipse en el municipio de Amurrio. Fuente: elaboración propia -datos.gob.es.   

1.4 Exportar como GeoJSON

Una vez tenemos un conjunto de datos pequeño y manejable, podemos exportar cada uno de los puntos en formato GeoJSON. Este formato es muy versátil a la hora de exportar datos y utilizarlo en un gran número de aplicaciones y herramientas, a diferencia del TIFF original que suele estar restringido a programas específicos de sistemas de información geográfica.

1.5 Visualización en mapas del GeoJSON

El fichero GeoJSON resultante nos permite presentar la información en aplicaciones de visualización geográfica como KeplerGL o GoogleEarth, así como integrarla de forma sencilla en proyectos de visualización utilizando Javascript. Para ello, pueden utilizarse bibliotecas como Leaflet o D3.js, requiriendo únicamente unas pocas líneas de código.

La primera herramienta que utilizaremos para visualizar las zonas de sombra por relieve va a ser la herramienta KeplerGL, que ya introdujimos en un ejercicio anterior sobre de datos geoespaciales. Para ello, basta con arrastrar el fichero al interfaz de carga de archivos, tras lo cual  se genera de forma automática una representación por polígonos asociado a cada punto. En la configuración de la visualización, vinculamos el color a la variable shadow y establecemos la escala tipo Quantize para distribuir los valores de forma homogénea a lo largo del intervalo. Finalmente, seleccionamos una capa base de imágenes satelitales para contextualizar la información y facilitar la identificación del relieve subyacente que da lugar a las zonas de mayor y menor visibilidad, tal y como vemos en la siguiente imagen.  

Figura 4: Mapa en KeplerGL de las zonas de sombra naturales por elevación del terreno a la hora del eclipse en el municipio de Amurrio. Fuente: elaboración propia -datos.gob.es. 

La siguiente herramienta en la cual podremos visualizar el resultado de un GeoJSON es Google Earth. En su entorno de desarrollo podemos cargar el fichero GeoJSON, seleccionar la escala de colores y configurar distintos parámetros de visualización mediante el cuadro de diálogo correspondiente. A pesar de ser mucho más limitado en customización que KeplerGL, GoogleEarth cuenta con una precisa distribución tridimensional que permite asociar cada punto a su equivalente en el mapa, pero esta vez incorporando la altitud del punto. El efecto de distribuir puntos en altura dota de más realismo al mapa, tal y como se ilustra a continuación.  

Figura 5: Mapa en GoogleEarth de las zonas de sombra naturales por elevación del terreno a la hora del eclipse en el municipio de Amurrio. Fuente: elaboración propia -datos.gob.es. 

Finalmente, el fichero GeoJSON podemos incorporarlo a un frontal web donde la librería Leaflet permite crear una cartografía en la que poder proyectar los puntos contenidos dentro del archivo de datos. En la siguiente imagen podemos ver el resultado, muy similar a los casos anteriores, donde sobre una imagen satelital tenemos los puntos que hemos extraído del TIFF originalmente. Este tipo de mapas podemos incorporarlos a frontales web con un alto grado de customización, superando las posibilidades ofrecidas por herramientas como KeplerGL o GoogleEarth. El notebook con el código de Javascript para Leaflet se puede consultar en Observable.  

Figura 6: Mapa de las zonas de sombra naturales por elevación del terreno a la hora del eclipse en el municipio de Amurrio en Leaflet. Fuente: elaboración propia -datos.gob.es. 

2. Zona de sombra proyectada del eclipse

Una vez que hemos identificado los puntos de la geografía ibérica en los cuales es posible ver el eclipse en su plenitud, pasamos a visualizar la trayectoria y extensión de la zona de sombra que proyecta la Luna sobre la superficie terrestre.  

Para ello utilizamos el fichero .GPKG del CNIG, que incluye una capa dedicada a la localización y extensión de las zonas de sombra a determinados intervalos de tiempo.  

2.1 Lectura de .GPKG

La lectura del archivo .GPKG la realizaremos con la ayuda de la librería GeoPandas  de Python. En primer lugar, extraemos los nombres de las diferentes capas contenidas en el geopackage, siendo éstas definidas por las primeras dos palabras: oscurez_standard, moon_shadow y durtot_standard.

La capa que nos interesa es moon_shadow, así que volcamos el contenido de esa capa en un dataframe de GeoPandas. Para tener una perspectiva global de todo el recorrido de la sombra a través de la península, unimos todas las geometrías de cada intervalo temporal en una única forma geométrica.  

2.2 Zona de sombra agregada

Con la ayuda de la librería Cartopy podemos crear un sencillo mapa de la extensión de todo el recorrido del eclipse sobre la península. A continuación se muestra el recorrido contextualizado por las coordenadas de latitud y longitud.  

Figura 7: Mapa de la zona de sombra agregada creado por el eclipse desarrollado en Cartopy. Fuente: elaboración propia -datos.gob.es. 

Al igual que en el caso de las zonas de sombra por relieve, nos interesa focalizar sobre el detalle, en este caso un intervalo temporal determinado. Para ello elegimos un tiempo concreto de la duración del eclipse y creamos un mapa específico para ese momento, lo cual nos permite ver con gran realismo qué forma puede llegar a tener la zona de sombra sobre la Tierra. En la siguiente imagen se muestra la zona de sombra para t = 200, unos 20 minutos tras el comienzo del eclipse.

Figura 8: Mapa de la zona de sombra a los 20 minutos del comienzo del eclipse creado en Cartopy. Fuente: elaboración propia -datos.gob.es.

2.3 Exportar como GeoJSON

Una vez tenemos seleccionado un momento y zona de sombra determinados, podemos exportar esa geometría en formato GeoJSON para poder utilizar otras herramientas más sofisticadas o para incorporarla a un entorno web. Para ello, redefinimos el orden de las coordenadas de los puntos que forman la geometría. Este paso, poco intuitivo, nos permite garantizar la correcta definición de la forma de la geometría en Javascript. Hay que tener en cuenta que en una forma geométrica cerrada, el interior puede ser considerado el exterior y viceversa. Forzando el orden de los puntos que se sigue para crear una forma geométrica cerrada garantizamos la definición de lo que es exterior e interior, facilitando así el posterior coloreado de la geometría en Javascript.

2.4 Visualización en mapas del GeoJSON

Al igual que en la sección sobre las zonas de sombra por relieve y orografía, incorporamos el fichero GeoJSON a diferentes herramientas y métodos de cartografía en Javascript para explorar diferentes formas de visualización, sacando partida de las ventajas de cada una de ellas.  

En KeplerGL podemos subir el archivo GeoJSON de salida y crear una forma poligonal con todos los puntos contenidos en el fichero. El resultado es la zona de sombra proyectada sobre un mapa que podemos modificar tal y como explicamos en un ejercicio de datos previo. El resultado se muestra a continuación:   

Figura 9: Mapa de las zonas de sombra creadas por el eclipse en KeplerGL. Fuente: elaboración propia -datos.gob.es.

Alternativamente podemos utilizar Google Earth y aprovechar su proyección cartográfica en forma de esfera para resaltar el efecto que produce el eclipse a escala planetaria y donde las formas geométricas curvas y distorsionadas cobran más realismo y sentido. Un eclipse no deja de ser el resultado de la interferencia de la luz entre dos esferas proyectada sobre otra esfera. En este contexto las proyecciones "planas" pierden la coherencia de una proyección esférica. El resultado se puede ver en la siguiente imagen.  

Figura 10: Mapa de las zonas de sombra creadas por el eclipse en Google Earth. Fuente: elaboración propia -datos.gob.es. 

A la hora de integrar estas visualizaciones en un entorno web, librerías de Javascript como Leaflet o D3.js son de gran ayuda, ya que con unas pocas líneas de código se puede crear un mapa con los polígonos contenidos en un GeoJSON, y personalizar los estilos de ese polígono de forma fácil e intuitiva. En el caso de Leaflet, muestra a continuación la extensión de la zona de sombra sobre una proyección satelital. El código correspondiente para la creación de este mapa se encuentra en un notebook de Observable:  

Figura 11: Mapa de las zonas de sombra creadas por el eclipse en Leaflet. Fuente: elaboración propia -datos.gob.es. 

En el caso de D3.js, aprovechamos la extensa librería de proyecciones cartográficas para crear un globo terráqueo y, al igual que en el caso de Google Earth, dar esa perspectiva planetaria que resulta, sin duda, más realista para comprender la naturaleza de un eclipse y el efecto combinado de las geometrías esféricas implicadas. En la siguiente imagen se puede ver el trazo de la zona de sombra elegido para este ejercicio. Para replicar este mapa se puede utilizar el código del notebook de Observable:  

Figura 12: Mapa de las zonas de sombra creadas por el eclipse creado con D3.js. Fuente: elaboración propia -datos.gob.es. 

Lecciones aprendidas

En este ejercicio de datos hemos aprendido a leer un fichero .TIFF o .GPKG, extraer la información relevante, volcar los datos sobre estructuras como xarray o GeoPandas, hacer un mapa preliminar sin salir de Python, exportar los datos en formato GeoJSON y, finalmente, explorar diversas herramientas dependiendo del entorno que necesitemos para el proyecto de visualización. De esta manera, hemos conseguido:  

• Adquirir familiaridad con diferentes formatos de información geográfica tales como .TIFF, .GPKG o .SHP. Esto nos permite aprovechar la riqueza en formatos disponibles, tener la misma información geográfica representada en diferentes formas y, por lo tanto, habilitar el uso de una plétora de herramientas para representar los datos.  
• Leer ficheros .TIFF a través de Python tanto para su representación gráfica como para su transformación a formatos válidos para crear visualizaciones en la web. En este proceso aprendemos, además, a realizar conversión de datos geográficos, pasando de ficheros de entrada .TIFF y .GPKG a ficheros de salida en un formato manejable y adecuado a entornos web como es el formato GeoJSON.  
• Delimitar zonas de interés a partir de archivos con una amplia cobertura espacial, para centrarse en poblaciones o regiones precisas y poder transmitir un mensaje concreto a la hora de comunicar información relevante. En concreto, aprendemos a recortar información georreferenciada en formato TIFF sobre un contorno específico como pueden ser los límites de un municipio y a descartar aquellos datos que estén fuera de ese contorno.  
• Utilizar las librerías Cartopy o Matplotlib de Python para hacer una visualización preliminar de la información contenida en un fichero TIFF.
• Crear un globo terráqueo donde se pueda visualizar la zona de sombra de un eclipse utilizando Google Earth o D3.js, aportando una visualización con un mayor rigor astronómico.  
• Explorar distintas alternativas de visualización gracias a la diversidad de herramientas disponibles. En concreto, hacemos un recorrido por todo el espectro de complejidad de visualizaciones espaciales, desde herramientas intuitivas como GoogleEarth, con la cual el público ya está familiarizado gracias a GoogleMaps, hasta herramientas de código como Python o Javascript a través de D3.js.

Conclusiones

Este ejercicio de datos nos ha permitido pasar de formatos utilizados habitualmente en entornos profesionales de sistemas de información geográfica a otros más manejables para poder crear nuestros propios mapas, bien con la ayuda de aplicaciones populares como KeplerGL o GoogleEarth, bien con librerías de Javascript para su integración en proyectos web.  

Asimismo, hemos visto cómo con unas pocas líneas de código podemos manipular los datos de entrada para focalizar sobre regiones de interés, seleccionar intervalos temporales determinados o personalizar mapas a nuestro gusto y elección.  

Próximos pasos

Los pasos siguientes que se proponen para profundizar en el análisis son:

• Explorar los formatos NetCDF o KML/KMZ, también georreferenciados, para tener un mayor control y dominio sobre los formatos de datos más populares en cartografía y análisis geoespacial.
• Comparar las características astronómicas del eclipse de 2026 con los de 2027 y 2028, accesibles en el Catálogo de datos de datos.gob.es.
• Representar variables que no se han mostrado en este ejercicio, como las efemérides o parámetros tales como la duración, la elevación o el azimut de los cuerpos celestes implicados en el eclipse.

Ámbitos de aplicación

El resultado de este ejercicio de visualización de datos aplica y apela a los siguientes ámbitos del análisis de datos:

• Periodístico: para la divulgación de la información precisa referente a los eclipses de sol.
• Científico: una vez los datos son accesibles, se pueden explorar todas las variables astronómicas incluidas en el conjunto de datos del CNIG y hacer un retrato del fenómeno astronómico mucho más completo que el descrito en este ejercicio.
• Analítico: el ejercicio se ha ceñido a la visualización más tradicional en base a mapas y cartografías. Explorar otras formas de visualización con un conjunto de datos tan atractivo puede incentivar la creatividad y la innovación a la hora de representar este tipo de eventos.  

Los modelos de Inteligencia Artificial (IA) y los agentes autónomos se han convertido en consumidores habituales de datos abiertos. Ya no es solo el analista quien descarga un conjunto de datos: son sistemas automatizados los que consultan catálogos, interpretan columnas y cruzan fuentes sin intervención humana. Este cambio obliga a los publicadores a plantearse una pregunta clave: ¿están mis datos preparados para ser entendidos por una máquina?

Este post deriva del ejercicio práctico Análisis de precios de carburantes con GenAI como copiloto. A partir de las conclusiones extraídas durante su desarrollo, repasamos las tres dimensiones que determinan si un conjunto de datos es realmente “consumible” por la IA: los formatos y mecanismos de acceso, el contexto semántico y la privacidad.

1. Formatos y mecanismos de acceso: ¿cómo “consume” mejor la IA?

Formatos estructurados y planos

Los modelos de IA procesan mejor los datos cuando estos llegan en formatos limpios y estructurados: CSV, JSON o Parquet. Son formatos planos, predecibles y fáciles de interpretar de forma programática.

En el extremo opuesto están los archivos Excel sobre-formateados: celdas combinadas, encabezados multinivel, colores con significado implícito o totales intercalados entre filas de datos. Todo ese formato visual, útil para un lector humano, se convierte en “ruido” para el modelo, que puede malinterpretar la estructura de la tabla y generar resultados erróneos. La recomendación es clara: si se publica en Excel, que sea como tabla plana; y mejor aún ofrecer siempre una versión en CSV o Parquet.

Mecanismos de acceso eficientes e inteligentes

Más allá del formato, importa el canal. Las API REST bien documentadas permiten a los sistemas de IA realizar consultas dinámicas y precisas mediante “Function Calling”: el modelo traduce una pregunta en lenguaje natural a una llamada concreta a la API y obtiene solo los datos que necesita, sin descargar el conjunto de datos completo.

En esta línea, protocolos emergentes como MCP (Model Context Protocol) estandarizan la forma en que los modelos descubren y utilizan fuentes de datos, reduciendo el trabajo de integración y abriendo la puerta a que los agentes autónomos interactúen con los catálogos de datos abiertos de forma nativa.

El equilibrio con la descarga masiva (Bulk Download)

Ahora bien, el acceso vía API no sustituye a la descarga masiva: ambos mundos coexisten. Para grandes volúmenes de información, como los datos de alto valor (High Value Datasets o HVD), el Bulk Download sigue siendo esencial por dos razones:

• Eficiencia para el consumidor: entrenar o analizar sobre un conjunto de datos completo es más eficaz con una descarga única que con miles de llamadas a una API.

• Protección de la infraestructura del publicador: los accesos continuos de agentes autónomos pueden saturar los servidores. Ofrecer ficheros masivos descargables reduce esa carga y evita que los sistemas de publicación queden comprometidos por picos de peticiones automatizadas.

Accesos incrementales

Los mecanismos de descarga incremental o delta son un complemento imprescindible del bulk. Si el conjunto de datos incluye fechas de actualización fiables (o endpoints filtrables por fecha de modificación), un agente puede realizar una descarga completa inicial y, a partir de ahí, descargar solo los datos nuevos o modificados. El resultado: menos tráfico, menos carga en los servidores y datos siempre actualizados en el lado del consumidor.

2. Contexto semántico: darle “sentido” a las columnas

La IA no adivina: diccionarios de datos legibles y prácticos

Un modelo puede leer una columna llamada precio, pero no puede saber si incluye IVA, en qué divisa está expresada o si es un valor medio o puntual. Sin esa información, la IA rellenará los huecos con suposiciones, y las suposiciones generan errores.

Por eso, cada conjunto de datos debería publicarse acompañado de un diccionario de datos explícito: qué significa cada columna, qué unidades utiliza, qué valores son válidos y qué convenciones aplica (formatos de fecha, separadores decimales, tratamiento de nulos, etc.).

Concreción práctica para publicadores

Este es uno de los problemas más habituales entre publicadores, y tiene soluciones concretas según el formato:

• JSON: publicar un JSON Schema que defina tipos, campos obligatorios, rangos válidos y descripciones de cada propiedad.

• CSV: acompañar el fichero con un archivo sidecar de metadatos (por ejemplo, siguiendo el estándar CSV on the Web del W3C o un simple diccionario en formato legible) que describa cada columna.

• Parquet: aprovechar que el formato integra el esquema en el propio fichero, enriqueciéndolo con metadatos descriptivos a nivel de columna.

Normalización y consistencia

El nombre de la columna es la primera pista semántica que recibe el modelo. Un nombre como precio_medio_gasolina transmite significado por sí mismo; un código críptico como X_VAL_2026 obliga a adivinar. Utilizar nombres semánticos, legibles y consistentes entre conjuntos de datos —misma convención, mismo idioma, mismos identificadores para los mismos conceptos— facilita tanto el consumo por IA como la reutilización humana.

3. Privacidad y seguridad: el filtro previo irrenunciable

Anonimización en origen

Antes de que un dato interactúe con cualquier entorno de IA, debe haber pasado un filtro estricto de privacidad. La eliminación y el enmascaramiento de Datos de Carácter Personal (PII) no es una recomendación: es una obligación previa a la publicación. Nombres, direcciones, identificadores personales o combinaciones de campos que permitan reidentificar a individuos deben tratarse en origen, nunca confiando en que el consumidor final los filtrará.

Gobernanza y prevención de fugas

Existe además un riesgo crítico del lado del uso interno: subir información confidencial o estratégica a modelos comerciales abiertos. Muchos de estos servicios pueden reutilizar los datos introducidos para el reentrenamiento de sus modelos, con lo que un documento sensible podría acabar formando parte del conocimiento de un sistema accesible por terceros.

La respuesta pasa por la gobernanza: definir políticas claras sobre qué información puede procesarse con IA y en qué condiciones, y apoyarse en entornos corporativos e infraestructuras estancas y seguras, donde los datos no salen del perímetro de la organización ni se utilizan para entrenar modelos externos.

Conclusión

Preparar los datos abiertos para la IA no exige empezar de cero: exige aplicar con rigor buenas prácticas que, en su mayoría, ya conocemos. Formatos limpios y mecanismos de acceso que combinen API, descarga masiva y actualizaciones incrementales; contexto semántico explícito que elimine la ambigüedad; y un filtro de privacidad y gobernanza aplicado siempre en origen.

Conviene subrayarlo: ninguna de estas recomendaciones es nueva. Todas formaban ya parte del repertorio de buenas prácticas de cualquier analista o científico de datos. La diferencia es que ahora dejan de ser opcionales: son condición necesaria si queremos que los modelos y agentes de IA trabajen como copilotos con un alto grado de autonomía sobre nuestros datos.

Los publicadores que adopten estas prácticas no solo facilitarán el trabajo a los modelos de IA y a los agentes autónomos: multiplicarán el valor y el alcance de sus datos. Porque un dato que una máquina puede entender es un dato que puede generar conocimiento a una escala antes inalcanzable. El momento de adaptar nuestros catálogos es ahora.

Contenido elaborado por Alejandro Alija, experto en Transformación Digital e Innovación. Los contenidos y los puntos de vista reflejados en esta publicación son responsabilidad exclusiva de su autor.

Pensemos por un momento en cómo trabaja cualquier administración pública. Cada día se tramitan expedientes, se redactan informes técnicos, se levantan actas de reuniones y órganos colegiados, se intercambian miles de correos electrónicos, se publican contenidos en la sede electrónica, se digitalizan documentos en papel y se generan imágenes, grabaciones de audio y vídeos de todo tipo. Toda esa producción documental contiene información valiosa sobre cómo funciona la organización, qué decisiones toma y por qué las toma. Y, sin embargo, la mayor parte de esa información permanece fuera del radar de los sistemas de información tradicionales.

Cuando hablamos de los datos de una administración solemos pensar en bases de datos, hojas de cálculo, padrones, presupuestos o indicadores. Es lógico: durante décadas, la gestión del dato se ha centrado en este tipo de información estructurada. Sin embargo, esa visión solo muestra una pequeña parte de la realidad.

Gran parte del conocimiento que generan las administraciones no reside en sus bases de datos, sino en expedientes, informes, actas, resoluciones, correos electrónicos y contenidos multimedia que forman parte de su actividad diaria. Información que existe, que contiene un enorme valor y que, tradicionalmente, ha permanecido al margen de las estrategias de gobierno del dato.

La irrupción de la inteligencia artificial ha convertido ese patrimonio documental en una oportunidad sin precedentes, pero también ha puesto de manifiesto que la tecnología, por sí sola, no basta. En este artículo veremos por qué los datos no estructurados se han convertido en uno de los principales activos de las administraciones públicas, qué obstáculos impiden aprovechar todo su potencial y cómo una estrategia de gobierno del dato puede transformar ese enorme volumen de información en un recurso fiable, reutilizable y preparado para generar valor.

El dato que no vemos

La mejor forma de entender esta situación es imaginar un iceberg. La parte visible representa los datos estructurados sobre los que trabajan la mayoría de las aplicaciones corporativas, los cuadros de mando y las estadísticas oficiales. Bajo la línea de flotación, mucho más extensa, se encuentra el enorme volumen de información no estructurada que describe decisiones, procedimientos, conocimiento técnico y contexto administrativo.

Según estimaciones de firmas de análisis como IDG o Gartner, este tipo de contenido representa alrededor del 80 % de la información que maneja una organización, y todo apunta a que ese porcentaje seguirá creciendo.

 

Figura 1. Visual explicativo sobre el tipo de datos de una administración pública. Fuente: elaboración propia – datos.gob.es

La paradoja es evidente: la mayor parte del conocimiento de una administración no está en sus bases de datos, sino sumergida en sus documentos. Durante muchos años esa parte del iceberg apenas podía aprovecharse. Hoy, sin embargo, la situación ha cambiado radicalmente.

El valor latente que se está dejando pasar

Ignorar la parte sumergida del iceberg supone desperdiciar uno de los mayores activos de información del sector público. En esos contenidos se documentan la experiencia acumulada durante años, el conocimiento de los empleados públicos, las relaciones entre expedientes y buena parte del contexto que nunca llega a almacenarse en una base de datos. Su aprovechamiento tiene, por ello, un impacto directo y transversal en la gestión pública.

Cuando esa información puede localizarse, entenderse y relacionarse, un expediente deja de ser únicamente un conjunto de documentos para convertirse en una fuente de conocimiento reutilizable. El recorrido es siempre el mismo: los documentos contienen conocimiento institucional en forma de contexto, decisiones, criterios y evidencias, y es el gobierno del dato el que permite transformar ese conocimiento en valor público. Esto se traduce en mejores servicios para la ciudadanía, una mayor trazabilidad de la actividad administrativa, más transparencia, una mayor eficiencia interna y una mejor reutilización del conocimiento institucional.

Esta puesta en valor conecta, además, con una obligación legal muy concreta: el principio de "una sola vez", recogido en el artículo 28.2 de la Ley 39/2015, que reconoce el derecho de la ciudadanía a no aportar documentos que ya obren en poder de cualquier administración. Hacer efectivo ese derecho exige que la información que la administración ya posee, con frecuencia en forma de documentos, pueda localizarse, interpretarse e intercambiarse entre organismos: cada vez que se solicita a un ciudadano un dato que ya figura en un expediente, el problema no es normativo, sino de gestión e interoperabilidad de la información.

Pero hay un factor que ha convertido esta necesidad en una prioridad estratégica: la inteligencia artificial. Estos contenidos constituyen hoy la principal materia prima para las aplicaciones de IA, especialmente aquellas basadas en el procesamiento del lenguaje natural (PLN, por sus siglas en inglés) y los Grandes Modelos de Lenguaje (LLM, por sus siglas en inglés).

El aprovechamiento de la información no estructurada, sin embargo, no comenzó con la inteligencia artificial generativa. Desde hace años se utilizan técnicas como el reconocimiento óptico de caracteres, los procesos ETL (extraer, transformar, cargar, por sus siglas en inglés), el web scraping, las expresiones regulares, las taxonomías, los motores de reglas y las técnicas clásicas de procesamiento del lenguaje natural para extraer, clasificar, normalizar y trasladar información documental a estructuras explotables. Estas aproximaciones continúan siendo especialmente eficaces cuando las fuentes son relativamente homogéneas, los patrones son estables y las reglas de extracción pueden definirse de forma precisa. La inteligencia artificial no sustituye necesariamente estas técnicas, sino que amplía su alcance y permite abordar contenidos más variables, ambiguos o difíciles de procesar mediante reglas previamente definidas.

Hasta hace pocos años, gran parte de esta información podía explotarse mediante técnicas tradicionales, pero hacerlo exigía procesos muy específicos, dependientes del formato y difíciles de escalar o mantener cuando aumentaban la diversidad y la complejidad documental. Los documentos se generaban y almacenaban en sistemas y formatos muy diversos, su localización dependía a menudo de palabras clave o rutas de carpetas y la comprensión de los contenidos que no podían procesarse mediante reglas exigía una lectura manual lenta y costosa.La irrupción de la inteligencia artificial generativa ha cambiado completamente este escenario: hoy es posible resumir documentos, clasificar expedientes, extraer entidades relevantes, detectar relaciones entre documentos o responder preguntas sobre normativa de forma automática. La IA no ha creado el dato no estructurado; simplemente ha hecho posible aprovechar un patrimonio documental que llevaba décadas esperando su oportunidad.

El iceberg, por tanto, ya no es solo una metáfora sobre lo que no vemos: es una descripción bastante precisa de dónde está el valor que todavía no estamos capturando.

Sin embargo, existe un error frecuente: pensar que disponer de modelos de inteligencia artificial es suficiente para aprovechar todo ese conocimiento. Sin embargo, no lo es.

El obstáculo no es tecnológico, es de gobierno del dato

La tecnología ya está aquí: las herramientas capaces de procesar documentos y aplicar inteligencia artificial son cada vez más accesibles y evolucionan a un ritmo vertiginoso. Sin embargo, el verdadero reto no consiste en incorporar nuevos algoritmos, sino en gobernar adecuadamente la información sobre la que trabajan.

Un modelo de lenguaje puede resumir miles de expedientes en minutos, pero no puede determinar cuál es la versión válida de un documento, si su contenido sigue vigente o quién es responsable de mantenerlo actualizado. Únicamente puede trabajar con la información que recibe. Si esa información es incompleta, inconsistente o carece de contexto, sus respuestas heredarán esas mismas limitaciones.

 Figura 2. Visual explicativo sobre la inteligencia artificial sin gobierno del dato vs con gobierno del dato. Fuente: elaboración propia – datos.gob.es

Sin metadatos, catalogación, clasificación, criterios de calidad y responsabilidades claras, el dato no estructurado deja de ser un activo para convertirse en un pasivo organizativo: abundante, costoso de mantener y difícil de localizar, interpretar y reutilizar. Aplicar inteligencia artificial sobre documentación mal gobernada no genera conocimiento; genera respuestas aparentemente plausibles construidas sobre información poco fiable, probablemente el peor escenario posible para una administración pública.

Esta situación nos lleva directamente a un concepto que ya analizamos en el artículo De la ciénaga al lago: cómo evitar que tus datos se conviertan en un pantano. La acumulación de información sin gobierno acaba produciendo un data swamp, porque acumular información no equivale a generar conocimiento. Si esto ya es cierto para los datos estructurados, lo es aún más para los repositorios documentales, donde el volumen crece más rápido y el contexto se pierde antes. Sin gobierno del dato, la organización actúa como un simple trastero digital; con gobierno del dato, ese contenido se transforma en un activo útil, fiable y preparado para su explotación, tanto por las personas como por la inteligencia artificial.

La evolución natural del dato

El gobierno del dato cumple aquí otra función menos evidente y, sin embargo, fundamental: ayudar a identificar cuándo una información que nació como no estructurada debe dejar de serlo.

Muchas administraciones siguen almacenando determinados datos en documentos de texto, formularios PDF o campos de observaciones simplemente porque así se diseñó el proceso original. Con el paso del tiempo, esa información empieza a repetirse en miles de expedientes y deja de ser una excepción para convertirse en un patrón estable.

Figura 3. Visual explicativo sobre el paso del documento al dato. Fuente: elaboración propia – datos.gob.es

No todo dato no estructurado debe seguir siéndolo. Una de las funciones del gobierno del dato consiste precisamente en identificar cuándo ha llegado el momento de estructurarlo. Gobernar el dato significa decidir qué información debe conservar su riqueza documental y cuál conviene transformar en datos estructurados para facilitar su validación, interoperabilidad, explotación y reutilización. Es una decisión de diseño de la información, no una consecuencia inercial de cómo comenzaron a hacerse las cosas hace décadas.

Cómo activar ese valor: una hoja de ruta de gobernanza

Aprovechar este patrimonio documental no requiere comenzar implantando inteligencia artificial. Requiere construir primero unas bases sólidas de gobierno del dato. Los principios son los mismos que ya aplicamos al dato estructurado, extendidos ahora al conjunto de la información de la organización.

 

Pilar	Objetivo
Políticas y responsabilidades	Definir quién es responsable de cada tipo de contenido y bajo qué reglas se crea, modifica, comparte y elimina.
Metadatos	Describir los documentos para que puedan localizarse, comprenderse y relacionarse automáticamente.
Clasificación	Organizar la información mediante taxonomías, tipologías documentales y niveles de sensibilidad.
Calidad	Garantizar que la información esté completa, actualizada, libre de duplicidades y preparada para su reutilización.
Interoperabilidad	Facilitar que documentos, expedientes y sistemas puedan intercambiar información mediante estándares comunes.
Ciclo de vida	Gestionar la información desde su creación hasta su archivo o eliminación, aplicando criterios homogéneos durante todo el proceso.

Figura 4. Tabla sobre los pilares y objetivos de la hoja de ruta de gobernanza. Fuente: elaboración propia - datos.gob.es

Como referencia metodológica para recorrer este camino, España dispone del ecosistema de normas UNE sobre gobierno, gestión y calidad del dato (UNE 0077, UNE 0078, UNE 0079, UNE 0080 y UNE 0081). Este marco permite abordar de forma homogénea la gestión tanto del dato estructurado como del no estructurado, apoyándose en procesos, responsabilidades y mejora continua para convertir la información en un activo gobernado y medible.

Más allá del almacenamiento

Durante años, las administraciones públicas han realizado un enorme esfuerzo por digitalizar documentos y expedientes. Ese proceso ha permitido sustituir el papel por archivos electrónicos, pero digitalizar no siempre significa gestionar mejor la información.

El verdadero reto de los próximos años no consiste en almacenar más documentos, sino en convertir ese inmenso patrimonio documental en un activo gobernado, reutilizable y preparado para generar valor: mejorar los servicios públicos, reforzar la transparencia y proporcionar una base fiable para las aplicaciones de inteligencia artificial que ya están transformando la gestión pública.

Y conviene no perder de vista que el iceberg seguirá creciendo. La producción documental de las administraciones continuará aumentando, y con ella el volumen de conocimiento que permanece bajo la superficie. La diferencia entre las organizaciones que conviertan esa masa oculta en una ventaja y las que la sufran como un lastre no estará en la tecnología que utilicen, sino en cómo gobiernen su información.

Porque, como en todo iceberg, el mayor valor no está en la parte visible. Está bajo la superficie, esperando a que las administraciones desarrollen las capacidades necesarias para descubrirlo, comprenderlo y ponerlo al servicio de la ciudadanía.

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.

"Somos nuestro cerebro y por eso tenemos que hablar de derechos humanos, porque si tienes una tecnología que te permite medir la actividad del cerebro y cambiarla, esa misma tecnología te permitirá, antes o después, descifrar la actividad mental y alterarla."

Yuste, Rafael. (2025). Neuroderechos. Un viaje hacia la protección de lo que nos hace humanos. Paidós.

 

La neurotecnología incorpora un conjunto de métodos o dispositivos para registrar la actividad del cerebro o del sistema nervioso, pudiendo incluso llegar a alterarla. Por ello, a medida que aumentan las técnicas de análisis de la actividad cerebral y las posibilidades terapéuticas, crece la inquietud ética entre los profesionales.

Para integrar el análisis de este fenómeno con el marco jurídico europeo disponemos de una excelente guía: el trabajo del doctor Rafael Yuste y su libro “Neuroderechos” (2025). El método de imagen de calcio, en el que el Dr. Yuste fue pionero, revolucionó las posibilidades de la investigación neurocientífica. Se trata de una técnica óptica que usa colorantes o indicadores sensibles al calcio para inferir cuándo se activan las neuronas. Cuando una neurona se activa, aumenta su nivel de calcio, lo que produce una señal luminosa observable. Esta técnica ha evolucionado desde el uso de colorantes químicos hasta sensores genéticos que las propias neuronas producen, lo que permite estudiar tipos neuronales específicos y registrar su actividad durante periodos más prolongados.

Ejemplos de manipulación de conductas utilizando neurotecnología

El Dr. Yuste en su libro proporciona ejemplos muy gráficos que permiten entender las posibilidades que abre esta metodología:

•  Se puede estimular una conducta en un ratón de laboratorio para que succione un líquido como respuesta al visionado de unas imágenes en video. Para ello, se mapean los conjuntos neuronales que se activan ante el estímulo visual aprendido. Después, con el estímulo apagado, se activan esas mismas neuronas con un láser y el ratón ejecuta la respuesta conductual esperada, sin ver nada en términos físicos.
• En humanos, se han desarrollado neuroprótesis del habla capaces de decodificar intentos de producción verbal en pacientes con parálisis y pérdida del habla. A partir del registro de la actividad cortical durante la lectura e intento de articulación de frases, estos sistemas pueden generar texto, voz sintética y la animación de un avatar facial.
• Asimismo, se experimenta con técnicas de neuroestimulación para mejorar la situación clínica de pacientes con enfermedad de Parkinson y para intervenir sobre determinados aspectos conductuales. También estamos asistiendo al desarrollo de nuevas técnicas neuroquirúrgicas basadas en interfaces cerebro-computador, tanto invasivas -por ejemplo, mediante implantes o chips inalámbricos- como no invasivas, que pueden operar mediante haces de energía o ultrasonidos.
• Finalmente, el neurofeedback se perfila como una tecnología cercana a la aplicación clínica y comercial, al permitir modular la actividad cerebral en casos como el trastorno por estrés postraumático, mediante videojuegos o entornos interactivos conectados a dispositivos de medición capaces de detectar ciertos estados emocionales y generar condiciones que favorezcan la mejoría del paciente.

Paradójicamente, la inteligencia artificial, que está acelerando los procesos de investigación en neurociencia, se ha desarrollado en buena medida a partir de modelos inspirados en las redes neuronales profundas. Ahora, el estudio de las redes neuronales biológicas podría, a su vez, transformar de manera decisiva la evolución futura de la propia IA. Descubrir los algoritmos matemáticos que subyacen al funcionamiento del cerebro podría favorecer el diseño de sistemas más eficientes, inspirados, tanto en su capacidad de procesamiento, como en su bajísimo coste energético.

La importancia de los neuroderechos

El Dr. Yuste y la Neurorights Foundation, han planteado que estos avances científicos requieren de un enfoque ético y jurídico específico: los neuroderechos. A tal respecto han propuesto cinco categorías:

1. Derecho a la privacidad mental. 

   La investigación en esta área de conocimiento revela inevitablemente información privada, incorporando nuevos riesgos a las técnicas de perfilado que con fundamento en la neurociencia despliegan las redes sociales. 

2. Derecho a la identidad personal.

   Nuestra identidad es altamente dependiente de la información y la experiencia que consolida nuestra memoria. Algunas terapias pueden afectar a nuestra identidad. 

3. Derecho al libre albedrío: a poder decidir frente a las técnicas que generan alteraciones de la conducta.

   Se ha constatado que el uso de neuroestimulación para tratar ciertos trastornos hace que el paciente se comporte de modo distinto. En esta afectación, ya no se trata solo de preservar la identidad, sino de garantizar que cualquier cambio esperable en la personalidad y conducta del paciente resulten de su libre elección. 

4. Acceso justo a la neuroaumentación.

   Un resultado esperable a futuro puede ser la aparición de tecnologías que potencien nuestras capacidades cognitivas. Existe el peligro que se genere un mercado de servicios que privilegie solo a aquellas clases sociales o econónicas con capacidad para contratarlos. 

5. Protección contra sesgos y discriminaciones.

   Del mismo modo que ya sucediera con la investigación genética, cuanta más información tengamos sobre el cerebro humano existirá un mayor riesgo de incurrir en sesgos y/o discriminaciones. Aquí el riesgo ya no es meramente pasivo, puede ser incrementado, por ejemplo, por el uso de la inteligencia artificial cuando el riesgo de sesgo en su funcionamiento no haya sido previsto o gobernado adecuadamente.

Figura 1. Neuroderechos - Fuente: doctor Rafael Yuste (en su libro "Neuro derechos", 2025) y la Neurorights Foundation.

 

Esta propuesta inspiró la consideración de los neuroderechos por la Carta de Derechos Digitales impulsada por el Gobierno de España y está generando un profundo debate en los planos académico y legislativo. La propuesta de regular la neurotecnología a través de los neuroderechos va más allá de la investigación científica y su origen, y se convierte en algo urgente debido al significativo interés de la industria.

Garantizar los neuroderechos desde el marco normativo existente: el derecho a la intimidad

Uno de los retos que debemos superar desde el mundo del derecho consiste en ser capaces de abordar los impactos de la tecnología desde las herramientas que nos proporciona el ordenamiento jurídico vigente. La ausencia de un derecho específico no implica que se pueda desarrollar y desplegar esta tecnología sin límites. La UE ha entendido la importancia de garantizar una concepción humanista de la tecnología centrada en la garantía de los derechos fundamentales, en asegurar la indemnidad de los pacientes frente a cualquier repercusión física o psicológica y en asegurar que la tecnología no pondrá en riesgo ni la democracia ni el estado de derecho.

El derecho a la privacidad mental se propone como la primera herramienta disponible para la garantía de los derechos de las personas en el ámbito de la neurotecnología. Y, aunque la tentación natural sea situar el foco en el ámbito del derecho fundamental a la protección de datos, lo cierto es que el derecho a la vida privada -que reconoce el artículo 18.4 de la Constitución española y los artículos 7 y 8 de la Carta europea de los Derechos Fundamentales- ofrece un conjunto de instrumentos prometedores para un enfoque temprano de los riesgos que puede plantear el uso de esta tecnología.

En primer lugar, desde el punto de vista de la dignidad humana, la intimidad se proyecta sobre nuestro cuerpo como un escenario de garantía de la libre autodeterminación del paciente. Esta capacidad de control y disposición se manifiesta claramente en Ley reguladora de la autonomía del paciente, y define el consentimiento informado como una primera barrera. En esto coincide con los principios vigentes en materia de investigación biomédica. Por ello, tanto quienes pretendan desarrollar sistemas basados en neurotecnología como implantarlos en un ámbito clínico encuentran en el deber de transparencia y en la fijación de garantías para obtener un consentimiento libre del paciente la primera barrera jurídica infranqueable. Las neurotecnologías son instrumentos particularmente complicados cuya comprensión puede escapar a las capacidades de la mayoría de la población, incluidos los propios expertos legales. En consecuencia, no bastará con la promesa de las ventajas que nos ofrece el tratamiento o el servicio que se nos pretenda prestar: será fundamental que la información se proporcione de forma clara, accesible y entendible en un proceso verificable y exento de cualquier tipo de coacción.

En segundo lugar, el artículo 18 de la Constitución incluye la garantía del derecho a la intimidad familiar, así como del honor y de la propia imagen. Desde un punto de vista material, cabe entender que el impacto en la conducta de un sujeto derivada de la utilización de neurotecnología podría incidir sobre estos derechos. Por una parte, si se provoca algún tipo de cambio en la personalidad del sujeto, se podría afectar a las relaciones interpersonales en el ámbito privado. Por otra parte, el honor garantiza la estima o consideración social ha tenido un sujeto. Por su propia naturaleza, implica una determinada autopercepción por parte del sujeto respecto de su personalidad, conducta y estima social, y podría verse afectado en el caso de que, como consecuencia del tratamiento, se produzca un cambio de personalidad con impacto reputacional. Más complicado resulta determinar la existencia de afectaciones al derecho a la propia imagen, salvo en lo relativo a la difusión de imagen médica o a la posibilidad de teorizar con la idea de que los cambios conductuales pueden repercutir sobre la imagen que proyecta un determinado sujeto cuando éste decide cambiarla.

Sin embargo, y aunque no haya sido objeto de un desarrollo legal específico, hay una propiedad emergente que vincula el derecho a la vida privada del artículo 18.1 de la Constitución con el problema que nos ocupa: el derecho a la identidad. Sin ánimo de teorizar en exceso, a lo largo de los dos últimos siglos se ha señalado de modo muy preciso que la garantía de la vida privada opera como una esfera de protección del individuo ante terceros, que le proporciona un espacio de libertad en el que desarrollar su personalidad. Esto es particularmente notorio en el caso de los niños, niñas y adolescentes para los que ampliar de modo gradual su esfera de intimidad frente a su entorno familiar resulta crucial para garantizar los procesos que permiten alcanzar la debida madurez y autonomía. La conclusión es evidente: la garantía del derecho a la vida privada debe aplicarse con rigor en el ámbito de las neurotecnologías como instrumento necesario para la preservación de la dignidad humana, la libre autodeterminación individual y el desarrollo de la personalidad.

Del derecho fundamental a la protección de datos al Reglamento de Inteligencia Artificial: la apuesta por la ingeniería de procesos

La garantía de nuestros derechos fundamentales respecto del desarrollo y uso de las neurotecnologías va a depender de modo esencial de los procesos que definen el Reglamento General de Protección de Datos (RGPD) y el Reglamento de Inteligencia Artificial (RIA).

El derecho a la protección de datos posee una naturaleza instrumental que los proyecta sobre el conjunto de los derechos fundamentales. No se concibe en abstracto, sino con referencia a un tratamiento concreto para una finalidad específica en un contexto determinado. Por ejemplo, cuando mediante algoritmos comportamentales se pretende perfilar a un sujeto en una red social y orientar su consumo de información, podemos estar afectando a la libertad ideológica o de creencias. El ejemplo paradigmático de esto lo podemos encontrar en el negacionismo científico. Los algoritmos de personalización, al apostar por monetizar con publicidad la experiencia de usuario, no hacen otra cosa que consolidar el sesgo de confirmación que alimenta creencias irracionales. Por ello, cuando aplicamos los procedimientos de la RGPD para el desarrollo de los sistemas que van a ser capaces de obtener información neuronal, de procesarla, de desarrollar tratamientos o de desplegar servicios, estamos garantizando que esta tecnología sea respetuosa con el conjunto de nuestros derechos fundamentales.

El RGPD y el RIA comparten un doble enfoque altamente productivo. El primero es el del diseño centrado en la garantía de los derechos del ser humano. Por ello, en ambos casos, antes de desarrollar cualquier invención en el ámbito de la neurotecnología, debemos preguntarnos si lo que pretendemos conseguir vulnera algún derecho fundamental, incurre en alguna práctica prohibida o encuentra alguna restricción jurídica en el derecho vigente. Con carácter complementario, podremos aplicar los estándares éticos propios de la investigación biomédica, así como los estándares emergentes tanto en el ámbito del desarrollo de la inteligencia artificial.

La segunda gran apuesta en ambas regulaciones, -y expresamente en el RIA-, es lo que podemos definir como orientación a producto. Es decir, en ambos casos las dos normas definen un conjunto de ingeniería de procesos claramente articulado que debe acompañar al proceso de desarrollo:

• En el ámbito del RGPD será necesario desplegar un análisis de riesgos o, en los casos más significativos, una evaluación de impacto relativa a la protección de datos. Este tipo de procesos nos proporcionará una clara identificación de todo tipo de riesgos. Los más importantes, los primarios son los que se refieren a los derechos de las personas. Ello sin perjuicio de que podamos identificar riesgos respecto de los principios de protección de datos. Aquí poseen particular importancia los relacionados con la calidad de la información y el principio de minimización, la seguridad de la información, así como cualquier tipo de riesgo inherente a la organización, incluidas las necesidades de formación del personal.
• En el diseño de sistemas de alto riesgo en el RIA se abordan prácticamente todas las variables. Al igual que ocurre en el RGPD es fundamental desarrollar una evaluación de impacto aquí en los derechos fundamentales. Por otra parte, como en el diseño de cualquier aplicación basada en IA, va a ser fundamental monitorizar y gestionar los riesgos, asegurar la gobernanza de datos, adoptar medidas específicas para garantizar la robustez y la resiliencia, desplegar estrategias de supervisión humana, garantizar la formación de los equipos que utilizarán la herramienta y asegurar que, gracias al cumplimiento de la transparencia en el despliegue, la tecnología se implante con total seguridad.

Ambas normas están sujetas a controles. En el RGPD, estos controles son propios de la organización y se basan en el establecimiento de controles periódicos, el desarrollo de auditorías regulares y la implantación de metodologías de gestión de las incidencias. En el ámbito de los sistemas de alto riesgo del RIA, además de implementarse procedimientos equivalentes a los del RGPD, es importante señalar que, al requerir la autorización de un organismo notificado, las exigencias de documentación son muy altas. Por otra parte, se trata de productos sujetos a vigilancia post comercial.

Por lo tanto, se puede afirmar que existe un marco de regulación que puede desplegar funciones esenciales a la hora de garantizar nuestros neuroderechos. Toda regulación adicional que precise las condiciones de desarrollo y despliegue de la neurotecnología será siempre bienvenida. Y no debemos olvidar un aspecto esencial: las dos normas que hemos citado son relevantes por cuanto ofrecen un conjunto de procesos que nos permite orientar nuestra estrategia de desarrollo e implantación de estas técnicas. Sin embargo, en los sistemas constitucionales de los Estados miembros de la Unión Europea y en la propia Unión, los derechos fundamentales que se garantizan para todas las personas ya son norma jurídica y aplican directamente: no hay excusas para su vulneración.

Contenido elaborado por Ricard Martínez Martínez, Director de la Cátedra de Privacidad y Transformación Digital, Departamento de Derecho Constitucional de la Universitat de València. Los contenidos y los puntos de vista reflejados en esta publicación son responsabilidad exclusiva de su autor.

El debate sobre cómo debe ser la alfabetización en inteligencia artificial tiene un mínimo anclaje normativo en el artículo 4 del Reglamento de IA de la Unión Europea. Este artículo establece que los proveedores y responsables de la implantación de sistemas de IA deben garantizar un nivel suficiente de alfabetización en IA de su personal, basado en el tipo de organización, el nivel de conocimiento inicial y el contexto de trabajo.

Ni el texto del artículo ni la explicación de la AESIA entran en detalles sobre habilidades concretas como el prompting ni lo sitúan como elemento central del aprendizaje en IA. Sin embargo, un gran número de cursos y formaciones han colocado esta habilidad de escritura de peticiones en el centro del recorrido formativo para aprender a utilizar la IA. ¿Es realmente diferencial saber estructurar una petición o saber qué tipo de prompt necesitamos en cada momento? ¿Qué otros ángulos podemos explorar para medir la alfabetización y madurez en el uso de la IA?

Una visión 360º de la alfabetización en IA

En la práctica, la calidad de nuestras peticiones depende de cuatro factores fundamentales que influyen en nuestro prompting y en los resultados que obtenemos, y que tienen que ver, principalmente, con el conocimiento previo que tiene la persona que las formula. Construir y hacer sólida esa base de conocimiento debería ser el objetivo fundamental de toda formación en IA.

1. Conocimiento del mundo y de la profesión

La capacidad para hacer un prompting efectivo mejora de forma natural cuando existe experiencia en un ámbito concreto. Las personas que han trabajado durante mucho tiempo en un campo específico suelen formular mejores instrucciones simplemente porque son capaces de identificar mejor la información relevante y cómo llegar a un resultado con sentido. Solemos pensar primero en la generación de texto, pero es más fácil observar esto en la generación de imagen o vídeo, donde profesionales especialistas en diseño, ilustración o cine obtienen resultados más precisos porque conocen los códigos de expresión para obtener lo que buscan: iluminación, contraste, planos, coherencia o movimiento. Tanto nuestra madurez profesional como el uso habitual de la tecnología basada en IA nos serán útiles a la hora de detectar de manera autónoma el AI slop, tanto en texto escrito como en imagen o vídeo.

2. Conocimiento teórico de la tecnología

Actualmente, y sobre todo en el mundo de la empresa, la gran tendencia es ofrecer formaciones eminentemente prácticas y muy enfocadas al uso diario, incluso en formato taller, lo que favorece la formación funcional en herramientas y prompting. Sin embargo, por muy práctico que sea el enfoque, las cuestiones técnicas básicas no deberían nunca quedar al margen de la formación. El funcionamiento del aprendizaje automático, las redes neuronales, la construcción de los grandes modelos de lenguaje basada en texto de internet, la tecnología detrás de los modelos predictivos o las capas de reglas que se añaden a los productos digitales son conceptos que ayudan después a ajustar expectativas, utilizar mejor la tecnología y hacer un uso más consciente de ella.

3. Conocimiento del contexto social y cultural

La inteligencia artificial no opera en el vacío: está condicionada por quién la configura y la entrena, con qué tipo de datos, desde qué lugar del mundo y en qué idioma. Esto conlleva la existencia de sesgos lingüísticos, especialmente el predominio del inglés y la cultura occidental anglosajona, que pueden influir en cómo se representa el mundo. También se manifiestan sesgos de raza, género y otros ejes de desigualdad que es necesario controlar desde el uso. Hay que sumar las cuestiones empresariales, geopolíticas y culturales que hay que conocer para entender el contexto de la IA, la prioridad de las ideas en sus respuestas, qué tiene sentido preguntar y qué no, y cómo puede influir en nuestra creatividad y nuestro pensamiento. Por último, hay que estar al tanto del estado de la regulación en España y Europa para entender qué podemos hacer con el contenido que obtenemos de un sistema basado en IA.

4. El papel del pensamiento crítico

En los tres puntos anteriores hemos hablado del conocimiento necesario para utilizar conscientemente los sistemas de IA, siguiendo el primero de los pilares del pensamiento crítico: no podemos cuestionar algo si no podemos relacionarlo con información externa. Una vez establecida esta primera capa, formar el criterio requiere habilidades cognitivas de análisis, voluntad y actitud crítica, y un hábito de metacognición que nos permita pensar sobre cómo pensamos y ejercer una auditoría consciente de nuestro uso de la IA.

El pensamiento crítico no surge de forma espontánea en la interacción con la IA, sino que se construye a lo largo del recorrido vital y a partir del contraste con información obtenida en contextos externos a ella.

Cuatro pautas para dotar de sentido al prompting

Teniendo en cuenta estos factores, aquí tienes varias pautas que te ayudan a dotar de mayor efectividad a tus prompts:

1. Para evitar el predominio del inglés y el marco cultural anglosajón: indica en qué idioma o contexto estás trabajando.

2. Para evitar respuestas centradas de forma automática en Europa o EE. UU. y ampliar la representatividad: sitúa desde el principio el contexto geográfico y cultural.

3. Para evitar marcos interpretativos implícitos y forzar una lectura más consciente: aclara desde qué punto de vista quieres la respuesta.

4. Para no condicionar la respuesta con juicios previos o sesgos incorporados en la propia formulación: evita introducir opiniones o suposiciones previas en la pregunta.

Ejemplo:

🔴 Prompt 1: “Explica la participación democrática juvenil en países como España, Suecia y Japón y compáralas entre sí.”

🟢Prompt 2: “Explica la participación democrática juvenil en España, en Suecia y en Japón, teniendo en cuenta el contexto geográfico y cultural de cada caso. Utiliza un lenguaje adaptado a un público de España, pero evita asumir que los modelos occidentales son la norma o el punto de referencia principal. Analiza el fenómeno desde distintas perspectivas sin dar por hecho una única interpretación o causa, y sin introducir juicios previos.”

El prompting es una habilidad interesante y útil que, más allá de determinados trucos y funcionalidades no evidentes, puede adquirirse de un modo intuitivo, incluso por imitación y en poco tiempo, una vez que tenemos los conocimientos necesarios sobre el funcionamiento de los sistemas de IA. Su protagonismo en la actualidad se debe más a que se trata de una competencia fácil de identificar y explicar, que se convierte muy ágilmente en producto formativo. Sin embargo, si queremos aplicar un enfoque más amplio y contextual de la alfabetización en IA, el prompting no debe desplazar contenidos técnicos, regulatorios y culturales que constituyen la verdadera base del aprendizaje.

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.

Cuando hablamos de datos abiertos, es fácil perderse en laberintos técnicos. A menudo el debate  se centra en los formatos de archivo, la interoperabilidad semántica, las licencias de uso o la optimización de los metadatos. Sin embargo, detrás de cada conjunto de datos publicado por una administración pública, existe un potencial transformador que impacta de manera directa en la vida cotidiana de las personas.

En este post, explicamos tres proyectos concretos actualmente en marcha en España, que utilizan datos abiertos como materia prima, y que tienen consecuencias tangibles: en el control de la calidad del agua de un parque natural, en cómo la ciencia busca nuevos medicamentos contra el cáncer y en la mejora de la respuesta ante fenómenos meteorológicos extremos.

Medio ambiente: monitorizando en tiempo real la salud de la Albufera de València

La Albufera de València es uno de los humedales más importantes del Mediterráneo y, también, uno de los más presionados. Décadas de actividad agrícola, industrial y turística han dejado su huella en la calidad del agua y en la salud del ecosistema. Hasta ahora, la monitorización de este espacio se hacía con métodos discontinuos, costosos y con una capacidad de respuesta limitada ante eventos extremos. La DANA de octubre de 2024 puso en evidencia, una vez más, la necesidad de contar con información ambiental en tiempo real para poder actuar con rapidez.

En este contexto surge, a principios de 2026, OBEREK, un proyecto europeo en el que participa la Universitat Politècnica de València (UPV) y la Fundació Assut. El proyecto está desarrollando una plataforma de monitorización en tiempo real de la salud del ecosistema y la biodiversidad de la Albufera. La plataforma instalará nodos de transmisión y sensores en puntos críticos del lago como entradas de caudal o salidas de regadío para medir parámetros clave del agua y del entorno natural.

Lo que hace especialmente relevante esta iniciativa desde la perspectiva de los datos abiertos es su arquitectura de acceso: el sistema contará con un panel de control de acceso público para que ciudadanía, investigadores, agricultores y empresas puedan consultar y reutilizar los datos para la toma de decisiones. Además, el proyecto integrará diagramas de conocimiento que traducirán información técnica compleja en explicaciones comprensibles, pensados expresamente para facilitar su uso como herramienta de gobernanza participativa. En concreto, el proyecto es clave para:

• Prevención de crisis: permite detectar de forma precoz anomalías en la calidad del agua, evitando episodios de anoxia (falta de oxígeno) que pongan en peligro la fauna local.
• Gestión eficiente del agua: proporciona datos empíricos para regular las compuertas que conectan el humedal con el mar y los canales de riego, optimizando el recurso hídrico.
• Evidencia científica para políticas públicas: los gestores gubernamentales pueden diseñar normativas de protección basadas en un histórico de datos sólido y transparente.

El objetivo final, según los investigadores de la UPV, es que la solución sea replicable en al menos cinco nuevos humedales europeos en los próximos tres años.

Salud: inteligencia artificial para acelerar el descubrimiento de fármacos oncológicos

El segundo caso de uso se inscribe en el sector de la salud y la investigación biomédica, donde los datos abiertos están empezando a cambiar las reglas del juego en uno de los procesos más costosos y lentos de la ciencia moderna: el descubrimiento de nuevos medicamentos.

Desarrollar un fármaco desde cero puede llevar más de una década y costar miles de millones de euros. Una de las razones es la enorme dificultad para identificar qué moléculas tienen potencial terapéutico antes de iniciar los ensayos clínicos. Es aquí donde entra el proyecto europeo Ligand-IA, en el que participa el Vall d'Hebron Instituto de Oncología (VHIO), uno de los centros de investigación oncológica de referencia en España.

Este proyecto utiliza modelos computacionales avanzados y algoritmos de inteligencia artificial entrenados y alimentados de forma masiva mediante el uso de grandes bases de datos abiertos químicos, biológicos y clínicos de acceso público.

Las bases de datos abiertas aportan el volumen de información biológica y química necesario para entrenar algoritmos de inteligencia artificial. Mediante el análisis de estos datos, la IA es capaz de realizar una predicción masiva de interacciones moleculares en entornos virtuales, lo que optimiza el cribado de compuestos y reduce drásticamente los tiempos y costes en el descubrimiento acelerado de nuevos fármacos.

La inteligencia artificial requiere de un volumen masivo de datos previos para aprender y realizar predicciones precisas. Al reutilizar repositorios abiertos mundiales de estructuras moleculares y resultados de ensayos anteriores, el consorcio Ligand-IA puede simular virtualmente millones de interacciones entre proteínas tumorales y diferentes compuestos químicos. Así que Ligand-IA es especialmente útil para:

• Reducción drástica de plazos: lo que antes requería años de ensayo y error en el laboratorio de química, la IA lo puede cribar virtualmente en cuestión de semanas o meses.
• Optimización de recursos de investigación: permite a los científicos descartar de forma temprana aquellas moléculas que no serán efectivas, concentrando los esfuerzos económicos y humanos en los candidatos con mayores probabilidades de éxito.
• Democratización del conocimiento: al utilizar y enriquecer el ecosistema de datos abiertos, se fomenta un modelo de ciencia colaborativa global que beneficia a toda la comunidad médica.

Resiliencia climática: inteligencia de datos frente a fenómenos meteorológicos extremos

Predecir el tiempo a corto plazo mediante la observación meteorológica convencional es una práctica estandarizada. Sin embargo, anticipar con precisión matemática cómo, cuándo y dónde golpeará un evento climático extremo exige un nivel de computación muy superior. En el escenario actual de cambio climático, la clave para mitigar las pérdidas humanas y los millonarios costes económicos de estas catástrofes reside en transformar los flujos masivos de datos climáticos mundiales en conocimiento predictivo útil.

Con este propósito estratégico nace el proyecto europeo CLINT (Climate Intelligence), una iniciativa de vanguardia financiada por el programa marco de investigación, desarrollo e innovación (I+D+i) Horizonte Europa de la Unión Europea. En el consorcio internacional formado para el proyecto participa el Consejo Superior de Investigaciones Científicas (CSIC), contribuyendo en las líneas de investigación orientadas al desarrollo de algoritmos para la detección, causalidad y atribución de estos fenómenos meteorológicos extremos en escenarios futuros.

El núcleo operativo de CLINT consiste en el desarrollo de un marco avanzado de inteligencia artificial (IA) y machine learning que se nutre directamente de los grandes repositorios de datos abiertos y de acceso público globales. Entre ellos, destacan de manera muy especial los flujos de información paneuropeos procedentes del Servicio de Cambio Climático de Copernicus (C3S), así como, de análisis climáticos históricos y modelos de predicción estacional. Este proyecto es de ayuda para:

• Sistemas de alerta temprana de nueva generación: permite la creación de servicios climáticos operacionales basados en la web, ofreciendo a las confederaciones hidrográficas y a las autoridades de protección civil herramientas para anticipar sequías extremas o riadas con semanas de antelación en la Península Ibérica.
• Gestión eficiente del nexo agua-energía-alimentación: al refinar los modelos predictivos mediante datos abiertos, tanto las empresas del sector energético (hidroeléctrico) como las comunidades de regantes pueden tomar decisiones estratégicas fundamentadas sobre el almacenamiento de agua y la planificación de cultivos.
• Soporte científico a las políticas de adaptación locales: facilita a los planificadores y administraciones públicas datos rigurosos y proyecciones climáticas fiables a escala regional para diseñar planes de urbanismo y contingencia adaptados a los desafíos del calentamiento global.

En resumen, estos tres ejemplos ponen de manifiesto cómo al compartir información de manera accesible y estandarizada, el sector público actúa como un catalizador que multiplica exponencialmente las capacidades del tejido científico y empresarial.  Al liberar conocimiento, permitimos que la ciencia avance más rápido, que nuestros recursos naturales se gestionen con responsabilidad y que la sociedad sea más resiliente ante los desafíos del mañana. Impulsar, mantener y defender la cultura del dato abierto es, por tanto, una inversión estratégica, inteligente y colaborativa en nuestro bienestar colectivo futuro.

Abrir los datos públicos es solo el primer paso de un camino mucho más ambicioso. El verdadero éxito de las políticas de datos abiertos no se mide en el número de datasets publicados ni en el volumen de gigabytes descargados, sino en el impacto real que esos datos generan en la sociedad, la economía y la innovación. Es decir, en su reutilización para generar servicios de valor añadido, apoyo a la toma de decisiones estratégicas, etc.

Sin embargo, debido al anonimato que generalmente prima en la descarga de datos, las iniciativas de datos abiertos a menudo desconocen quién está utilizando la información y para qué. Implementar una metodología activa de captación de casos de uso es fundamental para romper esta barrera y conocer el valor del dato.

A continuación, analizamos por qué es crucial realizar esta práctica, qué criterios seguir para seleccionar los casos a considerar y qué información clave debemos recopilar.

¿Por qué es importante captar y publicar ejemplos de reutilización?

La captación y análisis de casos de uso es uno de los mecanismos que los publicadores de datos abiertos tienen para medir el impacto de sus iniciativas open data. En este ámbito, entendemos por caso de uso cualquier modelo de negocio, aplicación, plataforma, servicio, análisis, etc. desarrollado por una entidad (ya sea una empresa, startup, ONG o la propia ciudadanía) que genere un valor tangible mediante la reutilización de datos públicos. Es decir, nos centramos en procesos que transforman datos abstractos en soluciones prácticas que resuelven un problema real, mejoran la toma de decisiones o crean una nueva oportunidad de negocio en el mercado. Las plataformas de datos abiertos suelen contar con una sección donde publican los casos de uso localizados, ya sea mediante catálogos o repositorios donde se recopilan empresas con modelos de negocio basados en datos abiertos, aplicaciones, servicios o historias de éxito a través de artículos o informes concretos. Se trata de un escaparate que beneficia a todos los actores del ecosistema de datos:

• Para las empresas reutilizadoras: funciona como un escaparate institucional gratuito de alta visibilidad. Aparecer en portales oficiales, ya sean internacionales, nacionales, autonómicos o locales, avala su reputación, su capacidad tecnológica y su modelo de negocio ante potenciales clientes e inversores.
• Para la sociedad: actúa como un elemento inspirador que puede desencadenar un "efecto llamada". Mostrar soluciones reales y tangibles fomenta la cultura del dato y estimula a emprendedores, investigadores y desarrolladores a crear nuevos servicios.
• Para la Administración pública: permite conocer qué conjuntos de datos son los más demandados y qué aspectos tienen en común (calidad, formatos, frecuencias de actualización, etc.), lo cual da pistas sobre qué cuestiones se deben impulsar o mejorar en el ejercicio de publicación. Además, el conocimiento sobre el uso de los datos es de gran utilidad para justificar la inversión de recursos en la apertura de datos y demostrar el retorno social de la inversión (SROI).

Figura 1. Beneficios de recopilar casos de uso de datos abiertos. Fuente: elaboración propia - datos.gob.es.

Tres vías para nutrir el repositorio de forma continua

Localizar empresas con modelos de negocio basados en datos abiertos y casos de uso concretos puede parecer una tarea complicada al principio, pero el secreto reside en combinar la automatización con la presencia en los foros adecuados. Para mantener el catálogo actualizado de forma constante, se recomienda activar tres vías complementarias:

• Escucha proactiva: consiste en monitorizar de manera constante las redes sociales, los medios de prensa tecnológica, los listados de empresas de asociaciones del sector (como ASEDIE), así como los ganadores de hackatones y premios de innovación.
• Canales reactivos: en paralelo a la búsqueda proactiva, es necesario mantener un canal de comunicación permanente y visible en el portal web. Lo habitual es contar con un formulario sencillo para que las propias empresas puedan postularse de forma autónoma. Difundir este canal de comunicación a través de los diversos medios de la iniciativa (como redes sociales, boletines periódicos, etc.) es fundamental para garantizar el crecimiento del catálogo de casos de uso.
• Alianzas del ecosistema: otra buena opción es colaborar estrechamente con asociaciones de empresas, universidades, incubadoras de startups y parques tecnológicos, que suelen ser los principales dinamizadores y focos de nacimiento de estas empresas reutilizadoras.

 ¿Cómo elegir las empresas y casos a categorizar?

Para que la colección de casos de uso sea una herramienta de referencia y mantenga un alto estándar de calidad, es necesario aplicar criterios de filtrado objetivos. Se recomienda priorizar los proyectos bajo las siguientes premisas:

• Uso significativo de datos públicos: el modelo de negocio o solución debe basarse total o parcialmente en la reutilización de conjuntos de datos de origen público (locales, autonómicos, nacionales o europeos), destacando positivamente la hibridación de distintas fuentes de datos (mashup de datos).
• Impacto y relevancia social o económica: se priorizarán aquellas empresas y soluciones que resuelvan problemas reales de la ciudadanía o de los sectores productivos (por ejemplo, optimización de la movilidad urbana, herramientas de diagnóstico de salud, eficiencia energética o transparencia financiera).
• Madurez y viabilidad: deben considerarse empresas que ofrezcan aplicaciones, plataformas o servicios que ya estén operativos en el mercado o, como mínimo, que cuenten con un Producto Mínimo Viable (MVP) testado y funcional. Es recomendable evitar ideas o proyectos en fase puramente conceptual. Estas soluciones iniciales pueden tener su escaparate en los concursos de datos que organizan diversos organismos, como la Junta de Castilla y León o el Cabildo de Tenerife, entre otros.
• Calidad y funcionalidad: las soluciones tecnológicas deben presentar un correcto diseño y funcionamiento técnico, con una experiencia de usuario óptima. El objetivo es garantizar que la reutilización del dato se traduce en un servicio verdaderamente eficiente y robusto para su público objetivo.
• Diversidad sectorial: es importante buscar un equilibrio temático para demostrar que el dato abierto es transversal. El repositorio o catálogo debe reflejar casos en sectores tan diversos como la agricultura, el turismo, la cultura o la educación.

¿Qué información se debe incluir sobre cada caso de uso?

Para que las fichas de los casos de uso sean homogéneas, comparables y útiles para los usuarios del portal, la recogida de información debe estructurarse de forma homogénea. Algunos de los pilares básicos a incluir son:

1. Perfil del reutilizador: nombre de la empresa, organismo o persona que la ha puesto en marcha el modelo de negocio o desarrollado la solución. En el caso de las empresas se puede incluir su año de fundación, tamaño, sector de actividad, enlace a su web corporativa, etc.
2. Descripción del modelo de negocio / solución: nombre de los productos o servicios, problemas que soluciona, descripción de su funcionalidad, público objetivo al que van dirigida, etc.
3. Fuentes de datos abiertos utilizadas: detalle explícito de los datasets consumidos, incluyendo su fuente de procedencia (por ejemplo, "Datos meteorológicos de la Agencia Estatal de Meteorología - AEMET"). Esto ayuda de forma directa a conectar la oferta con la demanda de datos.
4. Impacto obtenido: Indicadores cuantitativos o cualitativos del beneficio generado tanto para la empresa como para el reutilizador (ahorro de tiempo, reducción de emisiones, facturación, puestos de trabajo creados, etc.).

Ejemplos de catálogos de casos de uso

Para inspirar el diseño de un repositorio propio o entender cómo se plasman estas metodologías en el entorno real, es útil analizar cómo lo están implementando diferentes administraciones públicas.

En el caso de datos.gob.es, contamos con dos secciones diferenciadas, una para empresas y otra para aplicaciones. Ambos apartados permiten filtrar por sector de actividad o etiquetas, y además incluyen un buscador de texto libre, para que los usuarios puedan encontrar más fácilmente los casos de uso que se corresponden con sus necesidades.

A nivel autonómico y local también son muchos los organismos que han decidido incluir una sección específica en sus plataformas que muestre el potencial de uso de los conjuntos de datos publicados. Es el caso de la Junta de Andalucía, el Gobierno Vasco o el Ayuntamiento de Madrid.

Si miramos a Europa, nuestros vecinos también cuentan con esta funcionalidad en sus plataformas open data. Iniciativas nacionales como las de Francia o Lituania, que ocupan las primeras posiciones de madurez en datos abiertos de acuerdo con el Open Data Maturity 2025, cuentan también con este tipo de escaparates.

Conclusión: pasar del dato publicado al valor compartido

Medir el impacto de los datos abiertos es fundamental para garantizar la sostenibilidad a largo plazo de las iniciativas de datos abiertos. Sin una metodología clara para captar y estructurar las historias de éxito, los portales corren el riesgo de convertirse en meros almacenes de archivos digitales inertes.

Al poner a disposición de la ciudadanía ejemplos reales de la utilidad de los datos abiertos, la Administración no solo justifica la inversión pública en esta materia, sino que devuelve a la sociedad el conocimiento necesario para seguir innovando.

La IA generativa ha pasado muy rápidamente de ser una tecnología relevante solo en los círculos académicos a convertirse en una herramienta de uso cotidiano para millones de personas y organizaciones, tanto privadas como públicas. Sin embargo, en el último año, el concepto que ha pasado a dominar la conversación sobre innovación tecnológica ha sido la IA agéntica.

En muchas ocasiones, la IA generativa y la IA agéntica se están presentando como tecnologías rivales, y en particular como si la IA agéntica hubiese nacido para sustituir a la IA generativa, cuando la realidad es que se trata de dos conceptos que podemos considerar complementarios. La confusión es comprensible, ya que en la práctica muchos sistemas agénticos incorporan modelos generativos, y algunos asistentes basados en IA generativa pueden utilizar herramientas  (aunque sea de forma limitada para, por ejemplo, recuperar información de una API o base de datos). Podemos simplificar la diferenciación diciendo que un modelo de IA generativa puede integrarse en un sistema de IA agéntica, pero no toda aplicación basada en un modelo generativo puede considerarse un agente de IA.

¿Qué es la IA generativa?

La IA generativa puede definirse de forma sencilla como la familia de sistemas que producen contenido nuevo a partir de estructuras aprendidas en grandes volúmenes de datos. El Instituto Nacional de Estándares y Tecnología (NIST)  del gobierno de los Estados Unidos la describe como la clase de modelos de IA inteligencia artificial que emula la estructura y las características de los datos de entrada para generar contenido sintético derivado, incluyendo texto, imagen, audio o y vídeo.

La Organización para la Cooperación y el Desarrollo Económicos lo explica de forma quizás más divulgativa, definiendo la IA generativa como la rama de la inteligencia artificial capaz de crear nuevo contenido (texto, imágenes, vídeo, música, código, etc.) a partir de patrones aprendidos en grandes volúmenes de datos. Esta tecnología ya se está utilizando en tareas tan distintas como la programación, la búsqueda de información, la educación o el diagnóstico médico.

Por tanto, su característica principal es la generación. Se pide algo a un sistema de IA generativa, el sistema interpreta el contexto y devuelve una salida probable que además intenta ser coherente con la petición. Incluso cuando se conecta con una base documental especializada para mejorar el contexto de la petición, por ejemplo mediante enfoques RAG, su misión principal sigue siendo la de producir una respuesta o una pieza de contenido útil para quien lo pide. Por ello la utilidad de un modelo de IA generativa se mide, sobre todo, a través de la evaluación de indicadores tales como la calidad, la pertinencia, la coherencia de la respuesta o el ahorro de tiempo en la realización de la tarea.

Desde el punto de vista funcional, los principales modelos de IA generativa ya han conseguido unos niveles de desempeño equivalentes o superiores a los humanos en tareas concretas de comprensión, generación y manipulación del lenguaje, aunque siempre conviene interpretar estos resultados dentro de los límites de cada marco de referencia (benchmark).

No obstante, estos resultados no implican una comprensión general equivalente a la humana, sino que deben interpretarse como un gran desempeño en tareas específicas. Por ello, en todos los usos de la IA generativa sigue siendo necesaria una validación muy rigurosa y una supervisión adecuada para que podamos confiar en sus resultados.

Los riesgos de la IA generativa también son conocidos: alucinación o generación de contenido erróneo presentado con seguridad, problemas de integridad de la información, sesgos, contenidos potencialmente peligrosos, riesgos para la privacidad de las personas, problemas de alineamiento con el comportamiento esperado o conflictos respecto a los derechos de propiedad intelectual. Además, tal y como reconoce el NIST en su marco para la gestión de riesgos de la IA generativa , esta no solo amplifica riesgos ya existentes en otros sistemas de IA, sino que introduce riesgos propios o aumentados por la capacidad de producir contenido a gran escala.

En cambio, cuando la salida del modelo empieza a decidir el flujo de trabajo, seleccionar herramientas o modificar el curso de la ejecución, entramos en un nivel diferente de autonomía, que corresponde a la IA Agéntica.

¿Qué entendemos por IA agéntica?

La definición de IA agéntica, por su novedad, tiene por el momento un nivel de consenso mucho menor que en el caso de la IA generativa. Por ejemplo, el Gobierno del Reino Unido (gov.uk) la define como el conjunto de sistemas compuestos por agentes de software que pueden comportarse e interactuar de forma autónoma para lograr un objetivo. En esa misma línea, el portal técnico del Gobierno de Singapur explica que se trata de sistemas en los que agentes de IA persiguen objetivos y ejecutan tareas con autonomía, especialmente en dominios donde deben tomar decisiones y actuar dentro de un marco delimitado.

La Comisión Europea no define aún la IA agéntica como una categoría regulatoria separada, por lo que podría situarse dentro de la evolución de los sistemas de IA avanzados. En la Apply AI Strategy, se refiere a los agentes de IA como sistemas capaces de tomar decisiones y ejecutar acciones de forma independiente, comprender lenguaje, razonar sobre tareas, actuar de manera autónoma para alcanzar objetivos predefinidos y relacionarse con su entorno, incluyendo la orquestación de interacciones con personas. Esta aproximación encaja con la definición amplia del Reglamento europeo de inteligencia artificial[RG12] , que entiende los sistemas de inteligencia artificial como “sistemas basados en máquinas diseñados para operar con distintos niveles de autonomía […] y generar salidas, como predicciones, contenidos, recomendaciones o decisiones, que pueden influir en entornos físicos o virtuales”.

Podemos resumir por tanto la idea central en que el objetivo no es solo “hablar” o “escribir” bien, sino actuar con criterio operativo dentro de una serie de capacidades previamente autorizadas. En lugar de devolver una única respuesta a una instrucción, un agente puede recibir un objetivo de alto nivel, descomponerlo en subtareas, elegir qué herramientas o funciones necesita, consultar API, recuperar datos, evaluar resultados intermedios y continuar iterando hasta completar la tarea. Gov.uk lo explica con bastante claridad: en los sistemas agénticos, la ruta de ejecución no está completamente prefijada, sino que se decide de forma inteligente durante el proceso, utilizando la IA generativa para planificar y utilizar las herramientas necesarias a través de estándares abiertos como el Protocolo de contexto de modelo (MCP).

Cómo cambian las arquitecturas de los sistemas

La arquitectura típica de un sistema de IA generativa debe responder a un flujo relativamente lineal: una persona hace una petición a través de unas instrucciones (prompt), el modelo de IA interpreta el contexto, y produce una respuesta. Tan sólo cuando se quiere aumentar la precisión en dominios concretos, se añaden técnicas como RAG para recuperar información más precisa en tiempo real desde bases documentales o bases vectoriales.

Sin embargo, en la IA agéntica el patrón es mucho más complejo, ya que el sistema combina varios módulos junto con el modelo base para incluir mecanismos para planificar, mantener memoria, llamar a herramientas, registrar decisiones y coordinar acciones entre componentes o incluso con otros agentes. Además, es necesario monitorizar el funcionamiento y, en muchos casos, incluir una capa de supervisión humana. La documentación del gov.uk distingue incluso entre orquestación (un controlador central que ordena pasos) y coreografía (comportamientos más distribuidos y orientados a eventos), una distinción especialmente útil para entender por qué los agentes son más flexibles, pero también más difíciles de evaluar y auditar.

El desarrollo de la IA agéntica requiere, además, datos y servicios preparados para ser consumidos con garantías por máquinas; y aquí es donde la disponibilidad metadatos ricos, catálogos, API, control de versiones, información sobre calidad, licencias o acuerdos de nivel de servicio, entre otros, pueden marcar la diferencia en el despliegue robusto y fiable de esta tecnología.

Cómo cambia la forma de evaluar y reducir riesgos

Partimos de la base de que la evaluación de la IA generativa ya es una actividad muy exigente por sí misma y que poder explicar las decisiones de un sistema de inteligencia artificial es ineludible cuando hablamos de delegar tareas que antes realizaba un humano.

Si la IA generativa se evalúa sobre todo por la calidad de las respuestas, la IA agéntica obliga a evaluar el comportamiento completo del sistema. Esto es, es necesario preguntarse cuestiones como si la planificación elegida ha sido la adecuada para resolver la tarea, si la herramienta seleccionada era la correcta, si la consulta de datos respetó las reglas fijadas, si el sistema supo detenerse cuando debía, si dejó trazas suficientes para auditar lo ocurrido o si preguntó a un humano para respetar los límites con que se diseñó su autonomía.

Los benchmarks más recientes para IA agéntica van precisamente en esa dirección: GAIA evalúa asistentes generales en navegación web y uso de herramientas, StableToolBench trabaja sobre tasas de resolución y estabilidad en el uso de API, MultiAgentBench introduce indicadores de colaboración y competición entre múltiples agentes y Agent Security Bench pone el foco en ataques y defensas, mostrando vulnerabilidades muy relevantes en prompt injection, memoria y uso de herramientas.

El Reglamento de IA en particular refuerza la importancia de la supervisión humana en su artículo 14, estableciendo que el objetivo de dicha supervisión es prevenir o reducir al mínimo los riesgos que puedan surgir durante el uso de sistemas de IA. Para la IA agéntica, esto resulta especialmente importante ya que cuanto mayor sea la autonomía operativa del sistema, más necesario será definir cuándo debe pedir confirmación, cuándo debe detenerse, qué acciones puede realizar sin autorización y qué decisiones deben quedar siempre bajo control humano. En España, la Agencia española Española de supervisión Supervisión de Inteligencia Artificial (AESIA) está ayudando a aterrizar el Reglamento europeo de IA en orientaciones más operativas a través de sus guías prácticas para el cumplimiento del RIA, elaboradas por la Secretaría de Estado de Digitalización e Inteligencia Artificial, a través de la Dirección General de Inteligencia Artificial, y con la colaboración de la propia AESIA.

Figura 1. Visual comparativo entre IA generativa e IA agéntica. Fuente: elaboración propia - datos.gob.es

En definitiva, la diferencia entre IA generativa e IA agéntica es sobre todo una cuestión de propósito. La primera se especializa en producir contenido útil a partir de instrucciones; la segunda en coordinar acciones para conseguir objetivos, pero en ambos casos, tanto los conjuntos de datos abiertos como la buena gobernanza del dato seguirán siendo pilares fundamentales para que puedan conseguir sus objetivos. Además, no todos los casos de uso necesitan completar el salto hacia la IA agéntica, ya que los agentes de IA son adecuados sobre todo cuando el flujo de trabajo es no determinista, esto es, cuando hace falta decidir el siguiente paso en función del contexto. Tal y como argumenta el propio GovTech de Singapur los agentes de IA inteligencia artificial pueden incluso resultar excesivos allí donde un sistema más simple ya resuelve bien la tarea.

Durante años la gestión del dato siguió una lógica centralizada: recoger información, transportarla, almacenarla y procesarla en el mismo lugar. La nube (cloud) concentró gran parte del procesamiento empresarial gracias a su capacidad de almacenamiento y cómputo. Sin embargo, la evolución de los sistemas conectados está modificando este modelo. Hoy, una parte creciente del valor asociado al dato se genera cerca de su punto de origen: fábricas, tiendas, vehículos, sensores o terminales de pago. Y en muchos casos, las decisiones deben tomarse allí mismo, sin depender de la conexión constante con un servidor remoto.

Qué es exactamente Edge AI

El edge (el borde) es cualquier punto de cómputo cercano al origen del dato: una cámara con procesador integrado, un PLC (por sus siglas en inglés, Programmable Logic Controller) en una línea de producción, una pasarela industrial, un smartphone, un sensor LiDAR en un vehículo, una antena de comunicaciones en una red móvil. Edge AI consiste en ejecutar modelos de inteligencia artificial directamente en esos dispositivos, en lugar de enviar el dato crudo a un servidor remoto para que decida.

La diferencia operativa se entiende mejor con cuatro ejes.

1. Latencia: un modelo local responde en milisegundos, frente a las decenas o cientos que añade un viaje a la nube. Esta diferencia resulta determinante en aplicaciones que requieren actuar en tiempo real, donde incluso pequeñas demoras pueden comprometer la utilidad o la seguridad del sistema.

2. Ancho de banda: no toda la información generada por los dispositivos tiene el mismo valor. Transferir datos sin filtrar a la nube implica un uso intensivo de la red y un coste asociado que crece con la escala. El procesamiento en el borde permite reducir drásticamente ese tráfico al enviar únicamente la información que aporta valor. Por ejemplo, enviar el flujo de vídeo en bruto de mil cámaras es caro e innecesario si lo que interesa es solo el evento puntual.

3. Autonomía: un sistema que decide en el dispositivo mismo sigue funcionando aunque la conectividad falle, algo que puede ser crítico en muchos sectores que operan las 24 horas de los 365 días del año.

4. Privacidad y soberanía del dato: hay información (como la sanitaria, biométrica, financiera o personal) que por sensibilidad o por exigencia regulatoria no puede salir del lugar donde se genera, ni cruzar fronteras geográficas, ni alojarse en la infraestructura de un tercero. Mantener el procesamiento en el borde no es solo una decisión técnica, en muchos sectores, es la única opción legalmente viable.

Estos cuatro factores han dejado de ser preferencias técnicas para convertirse en requisitos de muchos casos de uso.

Figura 1. Visual explicativo sobre las ventajas de procesar en el borde. Fuente: elaboración propia - datos.gob.es

Algunos ejemplos de aplicación real

Una parte importante del Edge AI no necesita una fábrica, un banco, ni un supermercado: ya está en el bolsillo. El teclado predictivo del teléfono que aprende cómo escribe cada uno, el reconocimiento facial para desbloquear la pantalla, la organización automática de fotos por personas o lugares, la transcripción de notas de voz, los efectos de cámara en tiempo real. Todo eso son modelos de inteligencia artificial que se ejecutan directamente en el dispositivo. Funcionan sin conexión, no envían el dato sensible fuera del aparato y responden con una inmediatez que ningún servicio remoto puede igualar.

Algo parecido ocurre fuera del móvil, en los dispositivos que pueblan el hogar. Cámaras de seguridad que distinguen una persona de una mascota o un coche aparcado; monitores que detectan el llanto de un bebé y diferencian si es de hambre, dolor o sueño; termostatos que aprenden la rutina de la casa y ajustan la temperatura sin instrucciones; robots aspiradores que reconocen y rodean obstáculos; auriculares que cancelan el ruido en tiempo real. Todos ellos ejecutan modelos de IA dentro del propio aparato, sin enviar a la nube la imagen, el audio o la lectura del sensor.

El salto al mundo industrial sigue la misma lógica . Un avión comercial moderno tiene miles de sensores repartidos por motores, fuselaje, sistemas hidráulicos y aviónica, que generan flujos continuos de información sobre vibración, temperatura, presión y consumo. Llevar todo ese caudal de datos en tiempo real a un servidor remoto es inviable: el avión cruza océanos sin conectividad fiable, la decisión útil se mide en segundos y el coste de transmitir cada lectura es prohibitivo. La solución es ejecutar los modelos a bordo. El edge procesa la señal en bruto, detecta el patrón que anuncia una anomalía y solo envía hacia atrás lo que de verdad importa: la alerta, el diagnóstico, el contexto. Cuando el aparato aterriza, el equipo de mantenimiento ya sabe qué pieza revisar antes de que las ruedas toquen el suelo.

La misma arquitectura se aplica, con matices, a múltiples sectores que requieren anticipar fallos y ajustar operaciones en tiempo real. Desde plataformas petrolíferas y parques eólicos hasta líneas de producción, redes ferroviarias o flotas de transporte. En todos los casos el patrón es el mismo: muchos sensores generando datos donde no hay conectividad fiable, decisiones que pierden valor si llegan tarde y modelos de IA ejecutándose a centímetros del problema.

Cloud o Edge AI: cuándo conviene cada alternativa

Conviene desmontar un equívoco frecuente: Edge AI no compite con el cloud. Lo complementa. La pregunta razonable no es cuál de los dos, sino qué parte del problema vive mejor en cada sitio.

El cloud sigue siendo el lugar natural para tres cosas:

1. Entrenar modelos a gran escala, donde se necesitan miles de GPU y conjuntos de datos masivos.

2. Consolidar información de múltiples emplazamientos para análisis agregado.

3. Operar cargas donde la latencia es secundaria, como reporting, planificación u optimización a largo plazo.

El edge AI gana terreno cuando concurren las condiciones contrarias:

• la decisión debe ser inmediata.

• el dato no debe o no puede salir del lugar donde se genera.

• y/o el coste de transportarlo en bruto es prohibitivo.

El patrón que se está consolidando es claramente híbrido. Los modelos se entrenan en el cloud, donde hay datasets masivos y capacidad de cómputo abundante, y se despliegan en el dispositivo para ejecutarse. Es una división del trabajo lógica: el entrenamiento es caro, más lento y consume muchos recursos; la inferencia, en cambio, es continua, en tiempo real, y conviene aproximarla al origen del dato.

El cloud actúa como el cerebro que aprende; Edge AI, como el sistema nervioso que reacciona.

Existe, además, un paso intermedio cada vez más relevante: el aprendizaje federado o federated learning. En lugar de subir los datos del usuario al cloud para entrenar el modelo, este se entrena parcialmente en cada dispositivo con los datos locales y solo los parámetros aprendidos vuelven al servidor central para consolidar una versión global mejorada. Es la técnica que usan, por ejemplo, los teclados predictivos para aprender de millones de usuarios.

Qué hace técnicamente posible el Edge AI

Que la inteligencia se ejecute fuera del data center no es solo una decisión de arquitectura, sino el resultado de varios avances que han madurado en paralelo. Hay cuatro especialmente importantes.

Frameworks de inferencia ligera

Son los entornos que permiten llevar modelos entrenados en la nube a dispositivos con recursos limitados. Herramientas como LiteRT, ONNX Runtime o Core ML actúan como un puente entre dos mundos muy distintos: el del entrenamiento (potente y flexible) y el del despliegue (restringido y específico). Sin esta capa, ejecutar modelos en Edge AI sería inviable.

Hardware especializado

Hoy en día muchos dispositivos incorporan chips diseñados para IA, como NPU o GPU  móviles, capaces de ejecutar modelos con bajo consumo. Este salto permite que tareas que antes requerían servidores ahora puedan realizarse directamente en un teléfono, una cámara o un sensor.

Optimización de modelos

Para que un modelo funcione en el edge, hay que adaptarlo. Técnicas como reducir su tamaño o simplificar su estructura permiten que consuma menos memoria y energía. Aquí el cambio es clave: ya no se busca solo la máxima precisión, sino el equilibrio entre precisión, velocidad y eficiencia.

Edge MLOps

El reto no termina al desplegar el modelo. Hay que mantenerlo actualizado, monitorizar su comportamiento y gestionarlo en miles de dispositivos distribuidos. A diferencia del entorno tradicional, aquí no se gestiona un servidor, sino una flota entera, lo que cambia completamente la complejidad del problema.

El giro reciente: LLM en el dispositivo

Hasta hace poco, el edge se asociaba a modelos pequeños y muy especializados como detección de objetos, clasificación de señales o anomalías estadísticas. La generación de lenguaje y el razonamiento complejo se daban por reservados a la nube. Esa frontera se está moviendo.

Los llamados Small Language Models (i.e. Microsoft Phi, Google Gemma, Meta Llama en sus variantes de 1B y 3B parámetros) alcanzan en tareas acotadas un rendimiento comparable al de modelos diez o cien veces mayores hace apenas año y medio. Y lo hacen con un consumo que cabe en un teléfono.

La infraestructura ha acompañado el movimiento. Apple ejecuta sus modelos de Apple Intelligence directamente en el Neural Engine del dispositivo, sin enviar el dato personal a un servidor. Qualcomm ha integrado NPU (Neural Processing Units) de 45 TOPS (Trillion Operations per Second) en sus Snapdragon para portátiles, capaces de mover modelos de varios miles de millones de parámetros en local. La hoja de ruta industrial apunta a cruzar la barrera de los 100 TOPS en gama de entrada antes de 2027.

Lo que esto cambia, en la práctica, es el catálogo de aplicaciones posibles en el borde. Un asistente que responde sin conexión, un sistema de soporte técnico que opera en planta sin enviar voz al cloud, un copiloto industrial que interpreta documentación local y genera resúmenes sin salir del perímetro de la empresa. El razonamiento generativo, que hasta hace nada exclusivo del data center, empieza a tener una versión local con sentido.

Una infraestructura que se vuelve distribuida

La fotografía que emerge no es la del cloud desplazado, sino la de una arquitectura verdaderamente distribuida. Inteligencia entrenada en el centro, ejecutada en los extremos, coordinada por el medio. El dato deja de ser un material que siempre se transporta para procesarse y pasa a ser una señal que se interpreta en muchos casos donde nace.

Para quien diseña sistemas, la implicación es directa: la pregunta ya no es solo dónde guardo los datos sino dónde vive la decisión. Y la respuesta, cada vez más, es la misma: donde está el sensor, la cámara, el cajero o el teléfono. El cerebro corporativo se ha vuelto policéntrico, y eso obliga a pensar la arquitectura, la seguridad y el ciclo de vida del modelo de otra manera.

Referencias

[1] EE Times. "Edge AI Is Forcing a Rethink of Predictive Maintenance Architecture." (2024). https://www.eetimes.com/edge-ai-is-forcing-a-rethink-of-predictive-maintenance-architecture/

[2] Oxmaint. "Predictive Maintenance in Aviation: Using IoT Sensors to Monitor Aircraft and Ground Assets." (2024). https://oxmaint.com/industries/aviation-management/predictive-maintenance-aviation-iot-sensors-aircraft-assets

[3] Google Research. "Federated Learning: Collaborative Machine Learning without Centralized Training Data." (2017). https://research.google/blog/federated-learning-collaborative-machine-learning-without-centralized-training-data/

[4] Local AI Master. "Best Small AI Models 2026: Phi-4, Gemma 3, Qwen 3 Picks." (2026). https://localaimaster.com/blog/small-language-models-guide-2026

[5] Apple Machine Learning Research. "Updates to Apple's On-Device and Server Foundation Language Models." (2025). https://machinelearning.apple.com/research/apple-foundation-models-2025-updates

[6] Heqingele. "Snapdragon X Plus: 64/100 Integrated AI Power for Your 2025 PC." (2025). https://heqingele.com/blog/snapdragon-x-plus-64-100-integrated-ai-power-2025-pcs/

[7] Google AI Edge. "LiteRT: lightweight runtime for on-device AI (antes TensorFlow Lite)." (2024). https://ai.google.dev/edge/litert

[8] ONNX Runtime. "High performance ML inferencing and training accelerator." (2025). https://onnxruntime.ai/

[9] tinyML Foundation. "Machine learning on ultra-low-power microcontrollers." (2025). https://www.tinyml.org/

[10] Intel. "OpenVINO toolkit documentation." (2025). https://docs.openvino.ai/

Contenido elaborado por Juan Benavente, ingeniero superior industrial y experto 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 autor.

Imagina un edificio sin mantenimiento. Al principio funciona perfectamente: las puertas abren, la fontanería fluye, todo está en orden. Pasa el tiempo y nadie se ocupa de las pequeñas cosas: una tubería que gotea, una ventana que no cierra bien, papeles que se acumulan en los pasillos. Cinco años después, el edificio sigue en pie, pero usarlo se ha convertido en una odisea. Nadie sabe dónde está nada, hay habitaciones a las que ya nadie entra, y cada vez que intentas arreglar algo aparecen tres problemas más.

Con los datos pasa lo mismo. Una organización puede empezar con las mejores intenciones: sistemas bien diseñados, datos ordenados, todo documentado. Pero sin mantenimiento activo, esos datos que, al principio, eran un activo valioso acaban convirtiéndose en una ciénaga: un espacio donde la información existe, pero es imposible encontrarla, entenderla o confiar en ella.

Del data lake al data swamp: una diferencia clave

El concepto de data lake se presentó como la solución definitiva: un repositorio centralizado donde almacenar datos en su formato nativo para que analistas y científicos pudieran explorarlos libremente. Muchos de estos lagos, sin embargo, han terminado convirtiéndose en lo que la industria llama data swamp, o pantano de datos: un repositorio de datos que, aunque contiene mucha información, se ha vuelto inútil en la práctica.

La diferencia entre un lago y una ciénaga no está en la tecnología. Dos organizaciones pueden usar arquitecturas similares y obtener resultados muy distintos. Lo que marca la diferencia es cómo se gestionan los datos: si se conocen sus responsables, si están descritos, si se puede evaluar su calidad, si se mantienen actualizados y si existen reglas claras para incorporarlos, transformarlos o retirarlos. Un data lake aporta valor cuando está gobernado; el pantano aparece cuando el almacenamiento crece más rápido que la capacidad de entender y reutilizar lo que se guarda.

¿Cómo se forma una ciénaga de datos?

El paso de un entorno saludable a uno degradado suele ser silencioso. Los pantanos, rara vez, son el resultado de un gran error puntual; son el efecto acumulado de pequeñas decisiones cotidianas: datos que se cargan sin documentar, sistemas que cambian sin avisar, responsables que se van y nadie sustituye. Con el tiempo, el repositorio pasa de ser un activo estratégico a un lastre operativo. Y, lo peor, es que este deterioro suele ser invisible hasta que alguien intenta hacer algo con los datos y descubre que no puede.

• Ingesta sin propósito: se almacenan datos "por si acaso", sin un proceso de catalogación previo. Una organización empieza a capturar datos de nuevas fuentes (sensores, formularios, APIs externas) sin establecer quién los valida, cómo se documentan o dónde se almacenan de forma ordenada.

• Falta de documentación desde el origen: los datos se ingresan sin explicar qué significan, de dónde vienen, con qué frecuencia se actualizan o bajo qué reglas se capturan. No se registra el linaje ni el propósito de cada conjunto de datos.

• Acumulación sin criterio: se guarda "todo por si acaso", sin una política clara de qué datos son relevantes, cuánto tiempo deben conservarse o cuándo pueden archivarse o eliminarse.

• Cambios organizativos sin seguimiento: personas que conocían los datos dejan la organización, se reorganizan departamentos, se migran sistemas… y nadie actualiza la documentación ni traspasa el conocimiento.

• Proyectos piloto que se quedaron a medias: se cargan datos para un proyecto experimental, el proyecto termina (o nunca arranca), pero los datos se quedan ahí, sin contexto ni responsable.

• Ausencia de controles de calidad: no se validan los datos antes de ingresar al sistema ni se monitorizan después, por lo que los errores y las inconsistencias se acumulan silenciosamente.

Figura 1. Visual explicativo sobre el proceso de formación de una ciénaga de datos. Fuente: elaboración propia - datos.gob.es

Data drift: cuando los datos envejecen sin que te des cuenta

Relacionado con los pantanos, el data drift (deriva de datos) es un fenómeno especialmente relevante en proyectos de inteligencia artificial, aunque afecta a cualquier análisis basado en datos históricos. Ocurre cuando los datos dejan de representar la realidad actual, bien porque el contexto ha cambiado, bien porque las fuentes se han modificado sin que nadie lo haya documentado.

Podemos identificar varios tipos de deriva:

• Drift en las fuentes: un sistema de origen cambia su estructura, añade campos, elimina otros o modifica la lógica de cálculo de un indicador, pero nadie actualiza la documentación ni avisa a los usuarios de esos datos.

• Drift en los patrones: la realidad que los datos describen cambia. Por ejemplo, los patrones de movilidad urbana antes y después de una pandemia son radicalmente distintos. Un modelo entrenado con datos previos dejará de funcionar bien si no se recalibra.

• Drift en las definiciones: el significado de un campo cambia con el tiempo. Imaginemos que "vivienda vacía" se redefinió en 2022 para incluir segundas residencias, pero nadie actualizó la documentación. Quien compare datos de 2020 y 2024 estará mezclando conceptos distintos sin saberlo.

Como vimos en el post sobre estructuras organizativas de gobierno del dato para IA, un sistema de IA es tan bueno como los datos que lo alimentan. Si esos datos envejecen, el sistema empieza a fallar. Y si no hay mecanismos de monitorización activa, el problema puede pasar desapercibido durante meses. Un ejemplo claro es lo ocurrido durante la COVID-19, donde varios modelos predictivos vieron cómo su precisión caía drásticamente porque habían sido entrenados con patrones de comportamiento que dejaron de aplicarse de un día para otro. Es un caso extremo, pero ilustra bien el riesgo: un modelo es tan vigente como los datos que lo sustentan. Cuanto peor gobernados estén esos datos, más difícil será detectar estos cambios a tiempo.

Cómo evitar la ciénaga

Los pantanos de datos se pueden evitar. La clave está en adoptar un enfoque proactivo, basado en el mantenimiento continuo y en responsabilidades claras.

Figura 2. Visual explicativo sobre cómo evitar que un pantano de datos se convierte en una ciénaga. Fuente: elaboración propia - datos.gob.es

• Gobierno en la ingesta: no todo lo que existe merece entrar: el primer error que lleva a la ciénaga es la ausencia de filtros en la entrada. Establecer una zona de aterrizaje (landing zone) donde se verifiquen unos mínimos antes de mover los datos a las zonas de consumo es fundamental. Eso requiere definir quién es responsable de cada conjunto de datos (data owner), quién garantiza su calidad y documentación en el día a día (data steward), y bajo qué criterios se puede cargar algo al sistema. Sin este marco básico, cada dato que entra es una semilla potencial de desorden.

• El catálogo de datos: metadatos desde el origen: los metadatos son la capa de información que permite entender, encontrar y confiar en los datos. Sin ellos, un repositorio es una caja negra. Un buen catálogo responde a preguntas básicas: ¿qué contiene este conjunto de datos?, ¿de dónde viene?, ¿quién lo mantiene?, ¿cuándo se actualizó por última vez?, ¿qué significa cada campo? La catalogación no es una tarea que se hace una vez y se olvida. Es un proceso continuo: cada modificación actualiza la descripción, cada error detectado se documenta y corrige, cada reutilización genera información que mejora la documentación. Las herramientas de catalogación automatizada pueden ayudar a escanear repositorios y detectar cambios, pero la responsabilidad de validar esa información sigue siendo humana. En el ámbito de los datos abiertos, el perfil de metadatos DCAT-AP-ES ofrece un estándar común para describir conjuntos de datos de forma homogénea; el mismo enfoque puede aplicarse a cualquier repositorio interno.

• Calidad continua y detección del drift:  la calidad de los datos no es un estado, es un proceso. Un conjunto de datos puede ser excelente hoy y volverse inservible mañana sin monitorización activa. Las prácticas útiles incluyen validar los datos antes de cargarlos al sistema, establecer métricas de calidad revisadas periódicamente, configurar alertas que detecten desviaciones respecto a patrones históricos y hacer auditorías manuales para capturar errores que las métricas automáticas no ven. En España, la especificación UNE 0081 establece criterios para evaluar dimensiones como exactitud, completitud, consistencia o actualidad, lo que permite medir la calidad de forma objetiva y establecer compromisos concretos con los usuarios. En contextos donde los datos alimentan modelos de IA, las técnicas estadísticas de detección de drift permiten comparar la distribución actual de los datos con la de entrenamiento y lanzar alertas cuando la diferencia supera un umbral. Detectar el problema a tiempo permite reentrenar modelos antes de que su rendimiento se degrade.

• Trazabilidad: saber de dónde viene cada dato: en entornos complejos es necesario conocer el origen de cada dato, las transformaciones que ha sufrido, los procesos que lo han generado y los productos que dependen de él. El linaje de datos permite detectar el impacto de un cambio en origen, depurar errores o cumplir con obligaciones legales. Sin él, cualquier problema se convierte en una búsqueda en el laberinto.

• Ciclo de vida activo: revisar, archivar, eliminar: mantener datos obsoletos o irrelevantes aumenta el ruido, dificulta las búsquedas y consume recursos. Una política de ciclo de vida del dato define cuánto tiempo debe conservarse cada tipo de dato, cómo moverse a sistemas de almacenamiento más económicos cuando ya no se usan activamente, y cuándo pueden eliminarse —siempre respetando las obligaciones legales en materia de protección de datos—. Revisiones periódicas permiten identificar conjuntos que nadie ha consultado en meses, documentación desactualizada o datos que ya no tienen valor operativo. Esta "limpieza activa" evita que el repositorio crezca indefinidamente.

• Acceso y uso: claridad sobre quién puede hacer qué: un pantano también aparece cuando no está claro quién puede acceder a qué datos y para qué. Las políticas de acceso deben clasificar los datos según su sensibilidad, definir permisos, documentar restricciones legales o éticas y asegurar que los usuarios conocen las condiciones de uso. En el ámbito de los datos abiertos, la apertura debe ir acompañada de información clara sobre licencias, formatos, periodicidad y contexto.

• Cultura organizativa: las herramientas no bastan: las herramientas y los procesos son importantes, pero sin una cultura que valore la calidad del dato cualquier sistema acaba degradándose. Fomentar esa cultura requiere formación continua para que quienes generan o mantienen datos entiendan por qué importa la documentación, visibilidad directiva que sitúe la calidad del dato como prioridad estratégica, reconocimiento a los equipos que mantienen datos bien gestionados, y canales que permitan a quienes reutilizan datos reportar errores y sugerir mejoras.

Mantener datos limpios no puede depender del esfuerzo heroico de una persona. Tiene que ser parte del modo de trabajo habitual. La gobernanza bien diseñada es una ayuda para trabajar mejor, no un freno burocrático.

Marcos de referencia en España

Para abordar estos retos de forma estructurada existen marcos concretos. La familia de especificaciones UNE —impulsada desde la Dirección del Dato— cubre gobierno (UNE 0077), gestión (UNE 0078), gestión de calidad (UNE 0079), madurez de procesos de datos (UNE 0080), evaluación de datasets (UNE 0081), e implantación progresiva (UNE 0085). Para datos abiertos, DCAT-AP-ES establece requisitos sobre identificación, descripción, formatos y condiciones de uso. Estos marcos están pensados para aplicarse de forma incremental: se empieza por lo más crítico, se consolida y se avanza.

Conclusión: del pantano al valor, la gobernanza como sistema de depuración

Los pantanos de datos son prevenibles y, si ya existen, reversibles. Los datos solo generan valor cuando pueden encontrarse, entenderse y utilizarse con confianza. Almacenar información es necesario, pero sin gobierno, calidad, metadatos, trazabilidad y responsabilidades claras, incluso la plataforma más avanzada puede convertirse en un entorno confuso e inaprovechable.

Los beneficios de hacerlo bien son tangibles: equipos que dedican menos tiempo a buscar y limpiar datos, modelos de IA que se mantienen precisos porque el drift se detecta a tiempo, usuarios externos que confían en los datos porque saben que están actualizados. En un contexto donde los datos abiertos, los espacios de datos y la , , artificial adquieren cada vez más protagonismo, cuidar la base sobre la que se construyen estos ecosistemas es una decisión estratégica. El reto no es tener más datos, sino disponer de mejores datos: comprensibles, gobernados y listos para reutilizarse con confianza.