Gran Canaria GobLab figura entre los proyectos seleccionados por Red.es en RedCyTI, reforzando un laboratorio que ya trabaja en innovación colaborativa e inteligencia artificial aplicada a Administraciones Públicas.
La resolución nacional incluye Gran Canaria GobLab entre las iniciativas de Canarias y lo integra en una convocatoria orientada a infraestructuras tecnológicas, innovación y desarrollo económico.
Qué se ha confirmado sobre Gran Canaria GobLab
El propio GobLab describe un modelo de co-creación con Administraciones, ciudadanía, empresas y startups, con pilotajes de IA aplicados a procesos administrativos, formación y evaluación antes de decidir su continuidad.
La iniciativa forma parte de RedCyTI, el programa de Red.es orientado a impulsar desarrollo económico y productivo mediante ciudades y territorios inteligentes. La resolución de septiembre de 2026 selecciona 52 proyectos y prevé movilizar más de 126 millones de euros entre financiación pública estatal, fondos FEDER y aportaciones de las entidades beneficiarias.
En esta fase es importante separar el nombre y el alcance confirmado del proyecto de las decisiones que todavía deben concretarse en memorias, pliegos, adjudicaciones e implantación. La arquitectura final, las fuentes de datos, los proveedores y los indicadores de impacto serán los elementos que determinen la calidad real del resultado.
Qué necesidad intenta resolver
Muchas Administraciones quieren experimentar con IA pero carecen de equipos para desarrollar, probar y evaluar soluciones sin comprometerse desde el principio con una compra de gran escala.
Los proyectos de economía inteligente buscan que la tecnología tenga efectos sobre actividad económica, empleo, innovación y capacidad de gestión. Esto exige conectar cada inversión con un problema medible, evitando que sensores, plataformas o gemelos digitales se conviertan en objetivos en sí mismos.
La definición del caso de uso debería describir quién utilizará la solución, qué decisión pretende mejorar, qué información necesita y qué situación actual sirve de referencia. Sin esta línea base, evaluar el retorno resulta difícil.
La capa de datos será determinante
Los pilotos necesitan conjuntos controlados, permisos y documentación. Cuando sea posible, conviene utilizar datos anonimizados o entornos de prueba separados de producción.
Una plataforma pública necesita identificar fuentes autoritativas, periodicidad, responsables, calidad y restricciones de uso. Si los datos proceden de múltiples departamentos o de actores privados, conviene documentar linaje y transformaciones para poder explicar cualquier indicador o recomendación.
Los proyectos más sostenibles separan el dato de la herramienta que lo visualiza. Esta arquitectura facilita cambiar de plataforma, incorporar nuevos análisis y reutilizar información en otros servicios sin reconstruir todo el sistema.
Interoperabilidad y reutilización
Los prototipos deberían diseñarse con interfaces reutilizables para que una solución probada en una entidad pueda adaptarse a otra sin rehacer toda la arquitectura.
Las APIs documentadas, los formatos abiertos y los modelos semánticos comunes reducen el coste de conectar nuevas aplicaciones. También permiten que una misma capacidad pueda reutilizarse en distintas áreas municipales o incluso por otras Administraciones.
La interoperabilidad no implica utilizar un único producto. Al contrario, permite que varias soluciones colaboren mediante reglas conocidas. Esto favorece competencia y reduce dependencia de proveedor.
Inteligencia artificial y automatización
El valor del laboratorio está precisamente en probar IA con casos reales y limitar riesgos antes de escalar. La evaluación debe incluir precisión, utilidad, carga de supervisión y seguridad.
La IA aporta valor cuando existe un problema suficientemente definido y datos adecuados. Para tareas sencillas puede ser preferible una regla determinista o una consulta analítica. La elección tecnológica debe justificarse por precisión, coste y mantenibilidad.
Cuando se generan recomendaciones o predicciones, la Administración debería conservar mecanismos de supervisión y conjuntos de prueba. Los modelos pueden degradarse con el tiempo si cambian datos, comportamiento de usuarios o condiciones económicas.
Seguridad y continuidad
Los entornos de pilotaje necesitan aislamiento, gestión de accesos y reglas estrictas sobre información que puede procesarse.
Los entornos de ciudad inteligente suelen conectar múltiples proveedores, dispositivos y servicios. La seguridad debe incluir identidades, segmentación, registros, actualizaciones, copias, gestión de vulnerabilidades y procedimientos de incidente.
También hay que definir qué ocurre cuando la plataforma no está disponible. Si una unidad empieza a depender de sus recomendaciones o paneles para la operación diaria, el sistema necesita niveles de servicio y recuperación acordes con esa criticidad.
Contratación pública: cómo evitar un lock-in
El modelo de pilotaje previo puede mejorar futuras contrataciones porque permite especificar requisitos con evidencia en lugar de hacerlo solo sobre hipótesis.
Los contratos deberían exigir exportación de datos y configuraciones, documentación de arquitectura, inventario de componentes y derechos suficientes para continuar el servicio con otro adjudicatario. La reversibilidad debe diseñarse desde el principio.
También es útil separar en lotes o capas cuando ello favorezca competencia y mantenibilidad: infraestructura, plataforma de datos, analítica, sensores o acompañamiento pueden tener ciclos tecnológicos distintos.
Qué métricas deberían publicarse
Número de pilotos no es suficiente: deberían medirse decisiones de continuidad, ahorro, calidad y reutilización por otras entidades.
Los indicadores de despliegue —usuarios, sensores, integraciones o datasets— permiten seguir la ejecución, pero no demuestran impacto. La evaluación debe relacionarse con actividad económica, tiempos, costes, ventas, empleo, innovación o calidad de servicio, según el objetivo concreto.
Conviene definir la metodología antes de comenzar para evitar que el éxito se mida únicamente con indicadores que mejoran por diseño. La transparencia sobre resultados aumenta la posibilidad de aprendizaje y reutilización.
Gobernanza y capacidad interna
El Cabildo actúa como referente institucional y la colaboración exige participación técnica y de responsables con capacidad de decisión.
Una plataforma transversal necesita responsables funcionales y técnicos, además de propietarios para los principales conjuntos de datos. La organización debe conservar suficiente conocimiento interno para evaluar cambios, revisar al proveedor y decidir la evolución futura.
También conviene establecer un procedimiento para incorporar nuevas fuentes, corregir errores, retirar datos obsoletos y priorizar nuevos casos de uso.
Qué debería revisar una entidad antes de replicar el modelo
- Definir el problema público o económico con una línea base.
- Inventariar datos y sistemas existentes.
- Asignar responsables de datos y de servicio.
- Exigir APIs, estándares y exportación completa.
- Separar la información del proveedor de visualización o IA.
- Aplicar seguridad y privacidad por diseño.
- Probar con usuarios reales y escenarios de excepción.
- Medir coste operativo y sostenibilidad después de la ayuda.
- Preparar reversibilidad y continuidad.
- Compartir resultados y componentes reutilizables cuando sea posible.
Qué habrá que observar en los próximos meses
La nueva financiación permitirá comprobar si GobLab escala su red, genera componentes reutilizables y convierte pilotos en servicios estables.
La financiación abre el proyecto, pero el valor se comprobará durante contratación, implantación y evaluación. Será importante observar qué estándares se utilizan, qué fuentes se integran, cómo se protege la información y qué capacidades permanecen una vez finalice la fase financiada.
La continuidad presupuestaria también será clave. Las plataformas que generan valor deben poder mantenerse sin depender indefinidamente de nuevas convocatorias.
Preguntas frecuentes
¿RedCyTI financia todo el presupuesto?
No necesariamente. La financiación de Red.es varía según territorio y se complementa con aportaciones de las entidades beneficiarias.
¿La selección significa que el proyecto ya está funcionando?
No. Confirma la concesión y el proyecto seleccionado. La ejecución técnica llega después.
¿Qué requisitos técnicos conviene vigilar?
Interoperabilidad, seguridad, calidad de datos, documentación, trazabilidad y reversibilidad son elementos especialmente relevantes.
¿Cómo se debería medir el éxito?
Con indicadores vinculados al objetivo económico y de servicio, no solo con métricas de instalación tecnológica.
Fuentes
La selección nacional se basa en la información publicada por Red.es. Los detalles específicos se contrastan además con Fundación Emprende / GobLab Gran Canaria.
Lecturas relacionadas
Puede ampliarse contexto con nuestros análisis sobre gobierno del dato, gemelos digitales, interoperabilidad y código abierto y ciberseguridad municipal.
Una hoja de ruta de implantación para Gran Canaria GobLab RedCyTI
La primera fase debería centrarse en el diseño operativo. Antes de adquirir tecnología conviene definir qué procesos utilizarán la nueva capacidad, qué departamentos participan y qué decisiones se esperan mejorar. Esta fase permite detectar si ya existen herramientas municipales que pueden reutilizarse y evita duplicar inversiones.
El segundo paso es elaborar un mapa de datos y dependencias. Deben identificarse sistemas origen, propietarios, frecuencia de actualización, calidad esperada y restricciones de acceso. También conviene clasificar las integraciones según criticidad para decidir cuáles necesitan redundancia, monitorización o tiempos de recuperación más exigentes.
Una tercera fase puede dedicarse a un piloto controlado. Es preferible probar con un conjunto limitado de usuarios y casos de uso antes de desplegar a toda la organización. El piloto debe contar con métricas definidas antes de comenzar, de forma que el resultado pueda compararse con la situación inicial y no dependa únicamente de impresiones subjetivas.
Cómo preparar los datos antes de incorporar analítica o IA
Una parte importante del trabajo suele estar en limpiar y contextualizar información. Los equipos deberían detectar duplicidades, valores ausentes, identificadores inconsistentes y fuentes que ofrecen datos contradictorios. Automatizar sobre una base defectuosa puede aumentar la velocidad con la que se producen conclusiones incorrectas.
También conviene separar claramente datos operativos, estadísticos y personales. No todo lo que puede técnicamente combinarse debe combinarse. La finalidad del proyecto debe justificar cada fuente utilizada y los permisos deben limitarse a lo necesario para el caso de uso.
Los metadatos son otra pieza fundamental. Saber cuándo se actualizó una fuente, qué unidad la mantiene y qué nivel de precisión tiene ayuda a interpretar correctamente paneles, predicciones y recomendaciones. Esta información debería acompañar a los datos durante todo su ciclo de vida.
Pruebas de interoperabilidad y calidad
Las integraciones deberían probarse con escenarios normales y con errores. Datos incompletos, servicios caídos, formatos inesperados o cambios de versión deben formar parte de la batería de pruebas. Una plataforma que solo funciona en el caso ideal puede generar incidencias costosas cuando entra en producción.
Automatizar pruebas permite detectar regresiones cuando un proveedor actualiza una API o cambia un esquema. También facilita incorporar nuevos participantes sin depender de comprobaciones manuales extensas.
La Administración debería conservar documentación de estas pruebas y de los resultados. Esto mejora la capacidad de auditar el proyecto y ofrece una base objetiva para aceptar entregas o exigir correcciones.
Capacitación interna y transferencia de conocimiento
Los proyectos de datos e inteligencia urbana no deberían depender exclusivamente de consultoras externas. El personal municipal necesita comprender la lógica de los indicadores, la procedencia de la información y los límites de los modelos utilizados. Esta capacidad es necesaria para detectar resultados anómalos y decidir qué cambios tienen sentido.
La formación puede organizarse por perfiles. Los usuarios funcionales necesitan aprender a interpretar paneles y recomendaciones; los equipos TIC, a operar integraciones y seguridad; y los responsables de contratación, a evaluar dependencia, licencias y condiciones de salida.
La documentación debe ser práctica y mantenerse actualizada. Manuales que describen una versión inicial pero no reflejan cambios posteriores generan dependencia del proveedor y dificultan la continuidad.
Coste total y sostenibilidad después de la ayuda
La financiación inicial puede cubrir desarrollo e implantación, pero la entidad debe prever almacenamiento, conectividad, mantenimiento, licencias, soporte, sustitución de equipos y actualización de modelos. Un proyecto puede resultar viable durante la subvención y convertirse en una carga si estos costes no se estiman con antelación.
Conviene calcular varios escenarios de crecimiento. Más sensores, usuarios, datos o consultas de inteligencia artificial pueden aumentar el coste de forma no lineal. La arquitectura debería permitir controlar consumo y priorizar funciones que demuestran utilidad.
También es recomendable fijar criterios para retirar componentes que no aporten valor. La sostenibilidad incluye la capacidad de simplificar el sistema y no solo de añadir nuevas funciones.
Transparencia y rendición de cuentas
Las entidades públicas pueden publicar información sobre objetivos, presupuesto, hitos y resultados sin exponer detalles sensibles. Esta transparencia ayuda a explicar por qué se invierte en tecnología y permite valorar si las mejoras prometidas se producen realmente.
Cuando existen modelos predictivos o recomendaciones automatizadas, conviene describir de forma comprensible qué papel tienen y qué decisiones siguen correspondiendo a personas. La transparencia operativa genera más confianza que mensajes genéricos sobre innovación.
La publicación de indicadores comunes entre proyectos RedCyTI también facilitaría comparar enfoques y aprender qué soluciones resultan más eficaces en contextos diferentes.
Conclusión
Gran Canaria GobLab entra en RedCyTI para ampliar la innovación pública y el pilotaje de IA representa una oportunidad para convertir financiación tecnológica en una capacidad pública útil, pero el resultado dependerá de arquitectura, datos, gobernanza y operación diaria. El éxito no se medirá únicamente por completar la ejecución presupuestaria, sino por mantener un servicio que mejore decisiones o actividad económica después de la fase financiada.
Las entidades que documenten sus decisiones, utilicen estándares, conserven control sobre los datos y midan resultados estarán en mejor posición para evolucionar el proyecto y compartir aprendizajes con otros territorios.
Fotografía: Pavel Danilyuk / Pexels.