El Cabildo Insular de Tenerife ha sido seleccionado en RedCyTI con Data Hub Tenerife.
Red.es incluye oficialmente Data Hub Tenerife, promovido por el Cabildo Insular de Tenerife, entre los 52 proyectos seleccionados en RedCyTI. La convocatoria movilizará más de 126 millones de euros y financia entre el 40% y el 85% del presupuesto subvencionable según el territorio.
Qué está confirmado
La denominación oficial sitúa el proyecto en la creación de un hub de datos a escala insular.
La selección confirma la iniciativa y su denominación, pero el detalle final dependerá de pliegos, adjudicaciones y ejecución. Arquitectura, proveedores, fuentes de datos y calendarios todavía deben concretarse.
RedCyTI busca impacto económico y productivo. La evaluación futura deberá observar resultados y no solo tecnología instalada.
Qué puede significar el enfoque
El reto será convertir el hub en infraestructura útil para varias áreas y actores, con reglas de acceso y reutilización claras.
La denominación orienta el análisis, pero no sustituye a una memoria técnica. El proyecto debería traducirse en casos de uso concretos con usuarios, datos, responsables, coste actual y resultado esperado.
Priorizar pocos casos de alto valor antes de extender alcance reduce riesgo y permite aprender con evidencia.
Línea base y diagnóstico
Antes de desplegar conviene medir tiempos, costes, incidencias, nivel de digitalización, volumen y satisfacción. Esa línea base permitirá saber si la inversión mejora realmente la situación.
También debe inventariarse la tecnología existente. Reutilizar APIs, plataformas o fuentes ya disponibles puede reducir coste y evitar otra capa aislada.
El diagnóstico debería detectar dependencias de proveedor, formatos cerrados, datos duplicados y procesos manuales que puedan simplificarse.
Gobierno del dato
Un hub insular necesita catálogo de fuentes, metadatos, calidad y permisos coherentes.
Cada fuente necesita propietario, periodicidad, nivel de calidad, finalidad, licencia y reglas de acceso. La organización debe saber cuál es la fuente autoritativa.
El linaje de datos permite conocer origen, transformaciones y fecha de actualización. Esto facilita auditorías, investigación de errores y uso responsable en analítica.
Separar datos de la herramienta de visualización o IA facilita cambiar de proveedor y crear nuevos servicios.
Interoperabilidad
Debe conectarse con sistemas del Cabildo, municipios y operadores sin exigir una única plataforma.
APIs documentadas, formatos abiertos e identificadores estables reducen integraciones a medida. La interoperabilidad semántica evita que sistemas distintos interpreten de manera diferente los mismos conceptos.
Las pruebas deben incluir errores, cambios de versión, datos incompletos y servicios no disponibles. Una integración que solo funciona en el caso ideal no es suficiente.
Los contratos de interfaz y ejemplos de uso deberían quedar documentados para facilitar nuevas integraciones.
IA y analítica
Una capa de datos sólida puede habilitar analítica e IA, pero primero debe asegurarse calidad.
La IA debe utilizarse cuando aporta una ventaja medible frente a reglas o análisis convencionales. Si se incorpora, conviene registrar modelo, versión, fuentes, métricas, limitaciones y supervisión humana.
Las pruebas deben incluir casos límite, no solo rendimiento medio. También debe existir un criterio para retirar un modelo cuando deje de ser útil.
Los resultados automatizados deberían poder ser revisados por personas cuando afecten a decisiones relevantes.
Seguridad y privacidad
Los distintos datasets requerirán clasificación y controles proporcionales.
La seguridad debe incluir identidades, mínimo privilegio, segmentación, registros, actualización, copias y respuesta ante incidentes. Las credenciales técnicas necesitan propietarios y fechas de renovación.
Si existen datos personales o empresariales sensibles, la minimización debe aplicarse desde el diseño.
Los permisos de proveedores y subcontratistas deben estar inventariados y poder revocarse al terminar el contrato.
Contratación y reversibilidad
Los datos y modelos deben ser portables y no quedar encerrados en una herramienta.
Los pliegos deberían exigir exportación de datos y configuraciones, documentación de arquitectura, inventario de componentes y condiciones de salida. La reversibilidad debe probarse durante el contrato.
La modularidad favorece competencia y permite sustituir capas sin reconstruir todo el servicio.
La dependencia también puede ser de conocimiento: la organización necesita capacidad interna para entender y supervisar el sistema.
Arquitectura modular
Separar captura, almacenamiento, lógica, analítica y presentación reduce impacto de los cambios. La Administración debería controlar identificadores, modelos de datos, credenciales principales y reglas de negocio.
Desarrollo, pruebas y producción deberían estar separados, con control de versiones y capacidad de reversión.
La observabilidad debe permitir conocer disponibilidad, latencia, errores y cambios relevantes.
Capacitación y transferencia
Equipos del Cabildo y municipios necesitarán capacidades de gobierno del dato.
Usuarios funcionales, TIC, seguridad, contratación y dirección necesitan formación distinta. La documentación debe mantenerse actualizada durante todo el ciclo de vida.
El objetivo es conservar capacidad para supervisar, decidir y cambiar incluso si parte de la operación está externalizada.
La transferencia de conocimiento debería formar parte de los entregables contractuales.
Coste total y sostenibilidad
El presupuesto inicial no representa todo el ciclo de vida. Almacenamiento, conectividad, licencias, soporte, mantenimiento, auditorías, renovación de equipos y futuras migraciones deben estimarse.
Más usuarios, sensores, datasets o consultas pueden elevar el coste de forma no lineal. Conviene modelar escenarios de crecimiento.
La sostenibilidad también implica poder retirar funciones poco utilizadas.
Cómo medir impacto
Datasets reutilizados, tiempo de integración, usuarios y nuevos servicios pueden medir valor.
Las métricas de despliegue deben combinarse con resultados. La metodología debería definirse antes de empezar y mantenerse estable.
También es útil medir tiempo de incorporación de nuevas fuentes, incidencias, coste operativo y dependencia tecnológica.
Publicar resultados agregados facilita aprendizaje entre Administraciones.
Participación del ecosistema
Empresas y centros de conocimiento pueden aportar casos de uso.
Empresas, asociaciones, universidades y usuarios pueden aportar casos de uso y validar si la solución responde a problemas reales.
Las barreras de entrada deben ser razonables para pymes y entidades pequeñas, y las reglas de selección de pilotos deberían ser transparentes.
La participación también ayuda a detectar necesidades que no aparecen en los datos administrativos.
Operación y continuidad
Todo servicio necesita responsables funcionales y técnicos, un canal de incidencias y una clasificación de problemas entre datos, integración, infraestructura, seguridad y uso.
Los niveles de servicio deben adaptarse a criticidad. Las restauraciones y procedimientos de recuperación deben ensayarse.
Una copia que nunca se ha restaurado es una hipótesis, no una garantía.
Reutilización
La financiación pública genera más valor cuando deja activos reutilizables: modelos de datos, APIs, cláusulas, código, pruebas, guías y metodologías.
La documentación y licencias deben permitir esa reutilización. Compartir también problemas y decisiones fallidas evita repetir inversiones poco útiles.
Las redes territoriales pueden servir para comparar resultados y acelerar aprendizaje.
Qué debería revisar otra Administración
- Problema y línea base.
- Sistemas y datos existentes.
- Responsables.
- APIs y estándares.
- Seguridad y privacidad.
- Portabilidad y reversibilidad.
- Pruebas de fallo.
- Coste total.
- Formación.
- Métricas de impacto.
Qué habrá que observar
Habrá que conocer las primeras fuentes y servicios del hub.
Las licitaciones permitirán conocer alcance, estándares y componentes. Después habrá que observar adopción, resultados y sostenibilidad cuando termine la financiación inicial.
Un proyecto maduro debería poder evolucionar sin depender de una nueva subvención para cada cambio.
Preguntas frecuentes
¿Está ya desplegado?
No. La fuente oficial confirma la selección; la ejecución se concretará después.
¿Cuánto financia Red.es?
Entre el 40% y el 85% del presupuesto subvencionable según el territorio. La fuente general no detalla aquí la cifra individual.
¿Qué requisitos deberían vigilarse?
Interoperabilidad, seguridad, documentación, portabilidad, reversibilidad y métricas.
¿Cómo se mide el éxito?
Con resultados ligados al objetivo económico o de servicio, no solo con tecnología instalada.
Fuentes
La selección y denominación proceden de Red.es, publicación del 15 de septiembre de 2026 sobre los 52 proyectos RedCyTI.
Lecturas relacionadas
Más contexto sobre gobierno del dato, gemelos digitales, interoperabilidad y ciberseguridad municipal.
Un hub de datos necesita gobernanza antes que volumen
Data Hub Tenerife puede ganar valor si comienza por ordenar fuentes y responsabilidades en lugar de intentar acumular toda la información disponible. Cada dataset debería tener propietario, finalidad, calidad esperada, frecuencia de actualización, licencia y reglas de acceso. Esta ficha básica permite saber qué información puede reutilizarse y quién debe corregirla cuando aparece un error.
También conviene establecer un catálogo común que permita descubrir datos sin necesidad de conocer de antemano qué departamento los mantiene. Los metadatos y la documentación reducen dependencia de contactos informales y facilitan incorporar nuevas áreas.
Arquitectura modular y separación de capas
La infraestructura debería separar almacenamiento, integración, catálogo, analítica y visualización. Esta división permite cambiar una herramienta sin reconstruir el conjunto y facilita que diferentes proveedores trabajen sobre componentes concretos.
El Cabildo debería conservar bajo su control los modelos de datos, identificadores, credenciales maestras y reglas de negocio. La herramienta de BI o de IA puede cambiar; el conocimiento estructural debe permanecer en la organización.
Interoperabilidad con municipios y terceros
Un hub insular tendrá más valor si los municipios pueden conectarse con un esfuerzo razonable. APIs documentadas, formatos abiertos y ejemplos de integración pueden reducir barreras para entidades con equipos técnicos pequeños.
Las integraciones deberían probarse con cambios de versión, datos incompletos y servicios no disponibles. También conviene disponer de un entorno de pruebas antes de conectar nuevas fuentes a producción.
Calidad, linaje y trazabilidad
La calidad del dato debe medirse de forma continua. Completitud, duplicados, coherencia y actualización son indicadores que permiten detectar degradaciones antes de que afecten a informes o automatizaciones.
El linaje —origen, transformación y fecha— permite explicar un resultado y reconstruir qué ocurrió ante una discrepancia. Esta trazabilidad es especialmente importante cuando la información alimenta modelos predictivos.
Seguridad y clasificación de la información
No todos los datos deben tratarse igual. El hub debería distinguir información abierta, interna, personal, empresarial sensible y datos de infraestructuras. Cada categoría necesita permisos y controles proporcionales.
Las cuentas técnicas, certificados y secretos de API deben inventariarse y revisarse periódicamente. Los accesos de proveedores deben poder revocarse al finalizar el contrato.
Operación y soporte
El servicio necesita responsables funcionales y técnicos, un canal de incidencias y procedimientos claros para problemas de datos, integración, infraestructura y seguridad. Esta clasificación evita que cualquier incidencia termine en el mismo equipo.
Los cuadros operativos deberían mostrar disponibilidad, latencia, errores, calidad y consumo. Cada indicador necesita umbral y responsable para que la monitorización sirva para actuar.
Transferencia de conocimiento
La documentación debe mantenerse junto con las versiones y permitir que un equipo distinto pueda operar la plataforma. Diagramas, conectores, políticas, configuraciones y procedimientos de recuperación son parte del activo público.
La formación debería alcanzar tanto a perfiles técnicos como a responsables de las áreas que aportan o consumen datos.
Sostenibilidad económica
El coste total incluye almacenamiento, conectividad, licencias, soporte, personal, monitorización, auditorías y futuras migraciones. Conviene modelar crecimiento para conocer cuánto costará incorporar nuevas fuentes y usuarios.
Las funciones poco utilizadas deberían poder retirarse sin afectar al núcleo. La capacidad de simplificar reduce coste y riesgo.
Cómo medir el valor del hub
Además de contar datasets, conviene medir tiempo de incorporación, reutilización, número de consumidores, incidencias y decisiones apoyadas. Un catálogo muy grande pero poco utilizado aporta menos valor que uno más pequeño integrado en procesos reales.
Seis meses después del despliegue debería compararse la situación con la línea base y revisar qué fuentes y servicios merecen ampliarse.
Conclusión
Data Hub Tenerife entra en RedCyTI como infraestructura insular de economía del dato tendrá recorrido si se convierte en una infraestructura de datos gobernada, interoperable y sostenible. El éxito dependerá menos del volumen acumulado y más de la calidad, reutilización y capacidad de mantener el servicio con autonomía.
Una revisión periódica del catálogo
El catálogo de Data Hub Tenerife debería revisarse de forma programada para detectar fuentes que han dejado de actualizarse, datasets duplicados, permisos heredados y consumidores que ya no utilizan determinados servicios. Esta limpieza reduce coste, simplifica operación y evita que los usuarios confíen en información obsoleta.
También conviene medir cuánto tarda una nueva área o municipio en publicar un dataset correctamente documentado. Si el proceso es demasiado complejo, la plataforma puede terminar concentrando solo la información de los equipos con mayor capacidad técnica.
La gobernanza debería incluir un mecanismo para proponer cambios en modelos de datos y APIs, con periodos de transición y pruebas. Así se evita que una evolución necesaria rompa aplicaciones existentes.
El éxito del hub no se medirá por volumen almacenado, sino por la facilidad con la que la información puede descubrirse, entenderse, reutilizarse y mantenerse con garantías.
Para reforzar la sostenibilidad, el Cabildo puede establecer una revisión anual de costes, calidad, uso y seguridad. Esta revisión debería decidir qué fuentes ampliar, cuáles corregir y cuáles retirar, evitando que el hub acumule activos sin mantenimiento.
La publicación de aprendizajes y componentes reutilizables también puede facilitar que otros territorios adopten enfoques compatibles sin comenzar desde cero.
La capacidad de incorporar nuevas fuentes sin rediseñar la arquitectura será una señal importante de madurez. Si cada alta exige desarrollos específicos, el coste crecerá rápidamente y limitará la expansión del hub.
La revisión periódica de uso, calidad, costes y permisos permitirá mantener Data Hub Tenerife alineado con necesidades reales y evitar que la infraestructura acumule componentes sin mantenimiento ni valor operativo.
Fotografía: Atlantic Ambience / Pexels.