Red.es ha resuelto la convocatoria RedCyTI con la selección de 52 proyectos de economía inteligente en ciudades, diputaciones, cabildos, consejos insulares y comunidades autónomas uniprovinciales. La inversión total movilizada supera los 126 millones de euros, de los que más de 94 millones procederán de fondos propios de Red.es y del Fondo Europeo de Desarrollo Regional.
Los proyectos tienen presupuestos individuales de entre 1,5 y 6 millones de euros y recibirán financiación de entre el 40% y el 85% según el territorio. La convocatoria pretende utilizar tecnología para impulsar actividad económica, empleo y emprendimiento, no solo para digitalizar procesos internos municipales.
La escala nacional convierte RedCyTI en un laboratorio de políticas de smart economy. El reto principal será evitar 52 plataformas aisladas y conseguir que datos, componentes y metodologías puedan reutilizarse entre territorios.
52 proyectos seleccionados
La resolución distribuye iniciativas por numerosos puntos de España.
Los proyectos cubren sectores y tamaños territoriales muy distintos.
Esta variedad puede generar aprendizaje si existe una metodología común de seguimiento.
Más de 126 millones movilizados
La cifra combina financiación pública y aportación de beneficiarios.
El presupuesto permite desarrollar infraestructuras y servicios de escala relevante.
La ejecución deberá seguirse por proyecto.
Más de 94 millones de Red.es y FEDER
La aportación central procede de fondos propios y FEDER.
La financiación europea exige hitos y justificación.
Los territorios necesitan capacidad administrativa para cumplir calendarios.
Financiación entre el 40% y el 85%
La intensidad varía según condiciones territoriales.
La cofinanciación obliga a las entidades a comprometer recursos propios.
Esto puede favorecer sostenibilidad si la plataforma se integra en presupuesto ordinario.
Proyectos entre 1,5 y 6 millones
El rango evita actuaciones demasiado pequeñas.
A la vez, obliga a diseñar proyectos con varios componentes.
La complejidad debe gestionarse para no retrasar ejecución.
Economía inteligente frente a smart city clásica
La convocatoria se centra en actividad productiva.
Comercio, turismo, industria, agricultura, logística o talento aparecen entre los ejes.
El objetivo es conectar tecnología con desarrollo económico.
Gemelos digitales
Varios proyectos utilizan representaciones digitales del territorio.
Los gemelos pueden simular escenarios económicos o infraestructuras.
La primera versión del gemelo asturiano muestra cómo estas plataformas necesitan datos actualizados.
Espacios de datos
Algunas iniciativas crean entornos para compartir información entre administración y empresas.
Las reglas deben definir acceso, finalidad y derechos.
Un espacio de datos no es solo un repositorio.
Data hubs
Los hubs pueden centralizar ingesta y analítica.
La arquitectura debería evitar replicar datos sin necesidad.
Los catálogos facilitan descubrir fuentes.
IA y modelos predictivos
Las ciudades pueden utilizar IA para analizar demanda o anticipar tendencias.
Los modelos deben documentar precisión y limitaciones.
La supervisión humana es necesaria cuando influyen en decisiones públicas.
Comercio local
Los proyectos pueden ayudar a entender flujos y demanda.
Los datos deben utilizarse de forma agregada.
Las pequeñas empresas necesitan servicios simples para beneficiarse.
Turismo inteligente
La analítica puede mejorar planificación de afluencia y servicios.
Las plataformas deben evitar vigilancia innecesaria.
Los indicadores agregados suelen ser suficientes para muchas decisiones.
Industria 4.0
Algunos territorios orientan los fondos a hubs industriales.
La tecnología puede apoyar automatización, formación y proveedores.
La conexión con pymes locales es esencial.
Agricultura
Los proyectos rurales incorporan sensores, datos y analítica.
La tecnología debe demostrar retorno para explotaciones.
SembrAI 2026 refleja el interés creciente por estos casos.
Logística
Los territorios portuarios e insulares trabajan con flujos de mercancías.
Los datos en tiempo real pueden reducir ineficiencias.
Los estándares facilitan conectar operadores.
Talento
Algunas iniciativas buscan detectar necesidades de empleo y formación.
La analítica puede relacionar demanda empresarial y oferta formativa.
Las recomendaciones deben evitar sesgos.
Agua
La gestión hídrica aparece en proyectos de smart economy.
Sensores y modelos pueden optimizar consumo.
La precisión de medición es un requisito básico.
Datos municipales
Las entidades poseen información dispersa en diferentes aplicaciones.
RedCyTI puede ser una oportunidad para ordenar catálogos y calidad.
El gobierno del dato debe preceder a la IA.
APIs
Las nuevas plataformas deberían exponer interfaces documentadas.
Esto facilita reutilización por empresas.
Las APIs también reducen exportaciones manuales.
NGSI-LD
Los estándares de contexto se utilizan en entornos smart city.
Adoptar modelos compartidos facilita interoperabilidad.
La elección debe documentarse a nivel nacional.
Interoperabilidad semántica
Dos plataformas pueden utilizar APIs y aun así entender datos de forma diferente.
Vocabularios comunes resuelven parte del problema.
La experiencia de interoperabilidad semántica europea ofrece referencias, aunque cada sector necesita modelos propios.
Building blocks comunes
Identidad, catálogo, mapas o cuadros de mando pueden reutilizarse.
El enfoque GovStack propone componentes interoperables.
Red.es puede promover una lógica similar entre proyectos.
Evitar 52 silos
El mayor riesgo es que cada adjudicatario construya una arquitectura única.
Esto encarece mantenimiento y dificulta compartir.
Las especificaciones deberían exigir portabilidad.
Contratación
Los proyectos dependen de proveedores tecnológicos.
Los pliegos deben definir propiedad de datos y capacidad de salida.
La CNMC ofrece criterios útiles sobre competencia y dependencia.
Open source
Algunos componentes pueden publicarse.
Esto facilita reutilización entre ayuntamientos.
El código abierto necesita mantenimiento y comunidad.
Licencias
Los entregables deben indicar qué se puede reutilizar.
Una licencia ambigua bloquea transferencia.
Los contratos deberían resolverlo desde el inicio.
Protección de datos
Los proyectos pueden combinar información económica, movilidad o ciudadanía.
La minimización debe aplicarse.
La analítica no justifica recopilar datos individuales sin necesidad.
Ciberseguridad
Las plataformas municipales están expuestas a ataques.
La seguridad debe integrarse en arquitectura.
Servicios compartidos pueden ayudar a entidades pequeñas.
ENS
Los sistemas públicos deben aplicar el Esquema Nacional de Seguridad cuando corresponda.
La evolución del ENS legible por máquina facilita automatizar controles.
Las evidencias pueden generarse desde la plataforma.
Sostenibilidad después de FEDER
Los proyectos necesitarán presupuesto cuando termine la ayuda.
Licencias, nube y personal generan costes recurrentes.
El plan de sostenibilidad debe estar definido antes del cierre.
Capacitación municipal
Los empleados necesitan saber utilizar datos y herramientas.
La dependencia total de proveedores reduce autonomía.
La transferencia de conocimiento debe formar parte de contratos.
Participación empresarial
La smart economy busca beneficiar al tejido productivo.
Las empresas deben participar en diseño de servicios.
La administración necesita evitar capturas por intereses particulares.
Startups
Las plataformas abiertas pueden crear oportunidades GovTech.
Las startups necesitan APIs y entornos de prueba.
La compra pública innovadora puede facilitar pilotos.
Indicadores comunes
Red.es debería definir métricas comparables entre los 52 proyectos.
Empleo, empresas usuarias, datos compartidos y ahorro pueden formar parte.
Sin indicadores comunes será difícil evaluar el programa.
Indicadores específicos
Cada sector necesita métricas propias.
Turismo no se evalúa igual que agricultura.
Combinar un núcleo común con indicadores sectoriales ofrece una visión mejor.
Publicar resultados
Los cuadros de mando de ejecución pueden aumentar transparencia.
También permiten que otras ciudades aprendan.
Los resultados negativos deben documentarse.
Convocatorias anteriores
Red.es recuerda que programas previos destinaron más de 200 millones a 59 iniciativas.
Existe experiencia acumulada suficiente para comparar.
RedCyTI debería reutilizar lecciones de sostenibilidad e interoperabilidad.
Una red nacional de aprendizaje
Los 52 beneficiarios pueden compartir arquitectura, contratos y métricas.
Una comunidad de práctica reduce repetición.
El valor del programa aumenta si el conocimiento circula.
Fuente oficial
Red.es publicó la resolución el 15 de septiembre en la nota sobre los 52 proyectos RedCyTI y en su resumen de la convocatoria.
La gran prueba será si RedCyTI consigue que 52 inversiones locales funcionen como una cartera nacional reutilizable y no como 52 plataformas que deban mantenerse por separado durante años.
Arquitectura de referencia para los 52 proyectos
Red.es puede publicar una arquitectura mínima con capas de identidad, datos, APIs, observabilidad y seguridad. No obligaría a usar un único producto, pero sí a respetar interfaces y principios comunes.
Esto reduciría el coste de reutilizar un componente desarrollado en una provincia dentro de otro proyecto.
Catálogo nacional de componentes
Los beneficiarios pueden registrar software, modelos de datos, cuadros de mando y conectores creados con fondos públicos. El catálogo debería indicar licencia, versión, documentación y requisitos de despliegue.
Un buscador común evitaría que cada entidad encargue desde cero funciones ya financiadas en otra convocatoria.
Pruebas de interoperabilidad
No basta con declarar compatibilidad con un estándar. Red.es puede ofrecer un entorno de pruebas donde los proveedores validen APIs y modelos antes de integrar.
Los informes automáticos ayudan a detectar diferencias de implementación y reducen problemas durante el despliegue.
Gobierno de datos local
Cada proyecto debería identificar responsables para los principales datasets. Esta figura necesita autoridad para resolver duplicados, definiciones incompatibles y problemas de calidad.
Sin propietarios claros, el data hub puede convertirse en un repositorio que nadie mantiene.
Modelos de datos sectoriales
Agricultura, comercio, turismo e industria necesitan vocabularios diferentes. Red.es puede promover perfiles comunes por sector y permitir extensiones locales documentadas.
La semántica compartida es la condición para que las APIs sean realmente reutilizables.
Observabilidad desde el inicio
Los sistemas financiados deberían exponer métricas de disponibilidad, uso, errores y costes. Esta observabilidad permite saber si una plataforma se utiliza y cuánto cuesta mantenerla.
Los cuadros de mando de proyecto pueden alimentar un seguimiento agregado de la convocatoria.
Evaluar adopción empresarial
Una plataforma de economía inteligente fracasa si solo la utiliza el ayuntamiento. Cada beneficiario debería medir empresas registradas, consultas, APIs consumidas y decisiones apoyadas por el sistema.
El uso empresarial ofrece una señal directa de que la inversión está llegando al tejido productivo.
Programas de onboarding
Las pymes necesitan tutoriales, documentación y soporte para conectarse. Una API técnicamente correcta puede quedar infrautilizada si requiere conocimientos que el usuario objetivo no tiene.
Los proyectos pueden ofrecer ejemplos y kits de integración sencillos.
Costes unitarios comparables
Red.es puede calcular cuánto cuesta cada usuario, dataset o servicio activo. Estas métricas ayudan a detectar plataformas sobredimensionadas y servicios especialmente eficientes.
La comparación debe considerar alcance y territorio para evitar conclusiones engañosas.
Plan de cierre del proyecto
Antes de terminar FEDER, cada beneficiario debería identificar qué componentes continúan, quién los mantiene y con qué presupuesto. También debe decidir qué prototipos se retiran para no acumular sistemas sin responsable.
El cierre ordenado es parte de la sostenibilidad y reduce deuda tecnológica.
Repositorio de contratos y cláusulas
Las entidades pueden compartir modelos de cláusulas sobre propiedad de datos, portabilidad, seguridad y APIs. Reutilizar lenguaje jurídico probado reduce tiempo de contratación.
Este repositorio puede complementarse con lecciones sobre cláusulas que resultaron difíciles de ejecutar.
Interoperabilidad semántica con referencias reales
La experiencia europea de CAMSS y la eProcurement Ontology muestra cómo evaluar formalmente especificaciones frente a marcos de interoperabilidad. RedCyTI puede aplicar una lógica similar a modelos sectoriales.
Panel nacional de ejecución
Red.es puede publicar para cada proyecto hitos, presupuesto ejecutado y estado de entregables sin entrar en información comercial sensible. Un panel homogéneo permitiría detectar retrasos y compartir soluciones entre beneficiarios.
La transparencia también facilitaría que empresas locales conozcan cuándo estarán disponibles nuevos servicios o datos.
Evaluación a dos años
El impacto económico puede tardar en aparecer. Una revisión después del cierre debería medir qué plataformas continúan activas, cuántas empresas las usan y cuánto cuesta mantenerlas.
Esta evaluación es especialmente útil para decidir qué componentes merecen incorporarse a futuras convocatorias.
Compra conjunta de servicios comunes
Si muchos proyectos necesitan capacidades equivalentes, Red.es podría explorar mecanismos compartidos para pruebas de seguridad, interoperabilidad o alojamiento de componentes comunes.
La compra conjunta no debe eliminar autonomía local, pero puede reducir costes repetidos.
Documentación obligatoria de arquitectura
Cada beneficiario debería conservar diagramas, dependencias, APIs y procedimientos de recuperación. Esta documentación protege a la entidad cuando cambia el proveedor o el personal técnico.
La transferencia de conocimiento es parte del activo financiado con dinero público.
Panel nacional de ejecución
Red.es puede publicar para cada proyecto hitos, presupuesto ejecutado y estado de entregables sin entrar en información comercial sensible. Un panel homogéneo permitiría detectar retrasos y compartir soluciones entre beneficiarios.
La transparencia también facilitaría que empresas locales conozcan cuándo estarán disponibles nuevos servicios o datos.
Evaluación a dos años
El impacto económico puede tardar en aparecer. Una revisión después del cierre debería medir qué plataformas continúan activas, cuántas empresas las usan y cuánto cuesta mantenerlas.
Esta evaluación es especialmente útil para decidir qué componentes merecen incorporarse a futuras convocatorias.
Compra conjunta de servicios comunes
Si muchos proyectos necesitan capacidades equivalentes, Red.es podría explorar mecanismos compartidos para pruebas de seguridad, interoperabilidad o alojamiento de componentes comunes.
La compra conjunta no debe eliminar autonomía local, pero puede reducir costes repetidos.
Documentación obligatoria de arquitectura
Cada beneficiario debería conservar diagramas, dependencias, APIs y procedimientos de recuperación. Esta documentación protege a la entidad cuando cambia el proveedor o el personal técnico.
La transferencia de conocimiento es parte del activo financiado con dinero público.