Málaga ha sido seleccionada en RedCyTI con Málaga Smart Economy, una nueva iniciativa de economía inteligente urbana.
Red.es incluye oficialmente Málaga Smart Economy, promovido por el Ayuntamiento de Málaga, entre los 52 proyectos seleccionados en RedCyTI. La convocatoria movilizará más de 126 millones de euros en España y financiará entre el 40% y el 85% del presupuesto subvencionable de cada iniciativa, según el territorio.
Qué está confirmado sobre Málaga Smart Economy
La fuente oficial confirma la selección del proyecto y su denominación. Red.es incluye el proyecto entre los seleccionados en Andalucía.
RedCyTI está orientado al desarrollo económico y productivo de ciudades y territorios inteligentes. Por tanto, la evaluación futura no debería limitarse a comprobar que se instala tecnología: será necesario observar si la actuación mejora actividad económica, productividad, empleo, innovación o calidad de los servicios asociados.
En esta fase no debe darse por cerrada la arquitectura técnica. Los pliegos, adjudicaciones y documentos de ejecución concretarán proveedores, componentes, fuentes de datos, calendarios e indicadores.
Qué sugiere el enfoque del proyecto
Málaga parte de un ecosistema tecnológico amplio, por lo que el reto será integrar la nueva iniciativa con activos existentes y no crear otra capa independiente.
La denominación ofrece una orientación útil, pero no sustituye a la memoria técnica. Conviene diferenciar entre el objetivo general que puede inferirse del nombre y las funcionalidades que finalmente se contraten.
Para que el proyecto genere valor, cada caso de uso debería describir un problema concreto, usuarios, datos necesarios, responsable, coste actual y resultado esperado. Esta disciplina ayuda a evitar plataformas amplias con pocas funciones utilizadas en la práctica.
Una línea base antes de invertir
Antes del despliegue, el Ayuntamiento de Málaga debería medir cómo funciona hoy el proceso que se pretende mejorar. Tiempos, costes, incidencias, demanda, nivel de digitalización y satisfacción son referencias que permiten comparar después.
Una línea base evita que el éxito se mida únicamente por número de sensores, aplicaciones, paneles o datasets. La tecnología es un medio; el resultado debe expresarse en cambios que puedan observarse.
También conviene identificar qué herramientas ya existen. Reutilizar sistemas, APIs o datos disponibles puede reducir coste y evitar que un nuevo proyecto duplique infraestructura pública.
Gobierno del dato
El proyecto puede beneficiarse de información empresarial, urbana y territorial ya disponible, siempre que exista catálogo y gobierno.
Cada fuente debería tener un propietario, frecuencia de actualización, nivel de calidad, licencia y reglas de acceso. La Administración necesita saber qué dato es autoritativo y cómo se corrigen discrepancias entre sistemas.
El linaje —origen, transformaciones y fecha— permite explicar un indicador y facilita auditorías. Esta trazabilidad es especialmente importante si más adelante se incorporan modelos predictivos o automatizaciones.
Los datos deberían separarse de la herramienta que los visualiza. Así será más sencillo cambiar de proveedor, crear nuevos servicios y reutilizar información sin reconstruir todo el sistema.
Interoperabilidad para evitar otro silo
La integración con plataformas existentes será más importante que crear nuevas bases duplicadas.
Las APIs documentadas, los formatos abiertos y los identificadores estables facilitan conectar nuevas soluciones. Si la información solo puede utilizarse dentro de una aplicación propietaria, el valor de la inversión disminuye.
La interoperabilidad también es semántica: dos sistemas pueden intercambiar un campo y entenderlo de forma distinta. Modelos de datos y vocabularios comunes reducen este riesgo.
La entidad debería probar las integraciones con escenarios de error, cambios de versión y servicios no disponibles. Una integración que solo funciona en el caso ideal no es suficiente para un servicio público estable.
Inteligencia artificial y analítica
La IA podría utilizarse para análisis económico o apoyo a servicios, pero debería probarse con objetivos medibles.
Cuando la IA aporte valor, conviene documentar modelo, versión, fuentes, métricas y supervisión humana. No todo problema necesita inteligencia artificial: una regla determinista o análisis estadístico puede ser más barato, explicable y sostenible.
Los modelos deben probarse con casos reales y situaciones límite. Una precisión media alta puede ocultar errores importantes en determinados perfiles o momentos.
También debería existir un criterio para retirar o sustituir un modelo cuando deje de ofrecer resultados suficientes.
Seguridad y privacidad desde el diseño
La reutilización de múltiples fuentes obliga a revisar permisos y finalidades.
Las infraestructuras smart city suelen conectar aplicaciones, dispositivos, proveedores y servicios externos. La seguridad debe incluir identidades, mínimo privilegio, segmentación, registros, actualización, copias y respuesta ante incidentes.
Si existen datos personales o empresariales sensibles, la minimización debe ser una regla práctica: utilizar solo lo necesario y limitar accesos y conservación.
Las cuentas técnicas, certificados y secretos de API necesitan propietarios y fechas de renovación. Muchas incidencias se producen por credenciales olvidadas o permisos que permanecen activos después de terminar un contrato.
Contratación pública y reversibilidad
Los pliegos deberían exigir compatibilidad con el ecosistema existente y portabilidad.
Los pliegos deberían exigir exportación completa de datos y configuraciones, documentación de arquitectura, inventario de componentes y condiciones de salida. La reversibilidad no debería quedarse en una cláusula abstracta.
Es útil probar durante el contrato que la información puede exportarse y que otro equipo podría reconstruir el servicio. Así se reduce el riesgo de descubrir la dependencia cuando ya es necesario cambiar de proveedor.
La modularidad también favorece competencia: almacenamiento, integración, visualización, sensores o analítica pueden tener ciclos tecnológicos distintos y no siempre necesitan adjudicarse como un bloque inseparable.
Arquitectura modular y sostenibilidad
Una arquitectura por capas separa adquisición de datos, almacenamiento, lógica de negocio, analítica y presentación. Esta división permite sustituir componentes con menor impacto y facilita la evolución del proyecto.
La Administración debería mantener bajo su control identificadores, modelos de datos, credenciales principales y reglas de negocio. Las herramientas pueden cambiar; el conocimiento estructural no debería desaparecer con ellas.
También conviene separar desarrollo, pruebas y producción y mantener control de versiones para poder revertir cambios problemáticos.
Capacitación y transferencia de conocimiento
Los equipos deben conservar conocimiento de arquitectura e indicadores.
La formación debe diferenciar perfiles. Los usuarios funcionales necesitan interpretar indicadores y excepciones; TIC debe conocer integraciones y seguridad; contratación y dirección necesitan entender costes, dependencia y criterios de aceptación.
La documentación debe actualizarse durante todo el proyecto. Un manual que solo refleja la primera versión termina generando dependencia del proveedor.
La organización debería conservar suficiente conocimiento interno para supervisar el servicio, aunque parte de la operación esté externalizada.
Coste total después de la ayuda
La financiación inicial no cubre necesariamente todo el ciclo de vida. Almacenamiento, conectividad, licencias, soporte, mantenimiento, renovación de equipos, auditorías y futuras migraciones deben estimarse.
Es recomendable modelar escenarios de crecimiento. Más usuarios, sensores, datasets o consultas de IA pueden incrementar el coste de forma no lineal.
La sostenibilidad incluye poder retirar funciones poco utilizadas. Mantener módulos por inercia aumenta complejidad y superficie de riesgo.
Cómo medir el impacto
Reutilización, tiempo de integración y resultados económicos son indicadores útiles.
Las métricas de despliegue —usuarios, integraciones, sensores o datasets— sirven para seguir ejecución, pero deben complementarse con indicadores de resultado.
La metodología debería definirse antes de comenzar y mantenerse estable. Esto evita seleccionar a posteriori únicamente los indicadores que mejoran.
También conviene publicar resultados agregados para que otras Administraciones puedan comparar enfoques y reutilizar aprendizajes.
Participación del ecosistema
El tejido tecnológico y empresarial malagueño puede participar en pilotos y nuevos servicios.
Si el proyecto busca impacto económico, empresas, asociaciones y usuarios deberían poder participar mediante pilotos, documentación, canales de feedback o acceso a datos cuando proceda.
Las barreras de entrada deben ser razonables para pymes y entidades pequeñas. Un ecosistema digital no debería quedar limitado a organizaciones con grandes equipos técnicos.
Las reglas de selección de pilotos y participantes deberían ser transparentes y estables.
Operación y continuidad
Todo servicio necesita un responsable funcional, un responsable técnico y un canal de incidencias. Los problemas deben poder clasificarse entre datos, integración, infraestructura, seguridad y uso.
Los niveles de servicio deben ajustarse a criticidad. Una herramienta consultada semanalmente no necesita las mismas garantías que una plataforma operativa en tiempo real.
Las restauraciones y procedimientos de recuperación deberían ensayarse. Una copia que nunca se ha restaurado es una hipótesis, no una garantía.
Qué debería revisar otra Administración antes de replicarlo
- Problema concreto y línea base medible.
- Sistemas y datos ya disponibles.
- Responsables funcionales, técnicos y de información.
- APIs, estándares y modelos semánticos.
- Seguridad, privacidad y continuidad.
- Portabilidad de datos y configuraciones.
- Pruebas de interoperabilidad y escenarios de fallo.
- Coste total de operación.
- Formación y documentación.
- Indicadores de impacto y criterios para retirar funciones.
Qué habrá que observar en los próximos meses
Las licitaciones permitirán conocer cómo se conecta Málaga Smart Economy con infraestructuras previas.
La publicación de licitaciones permitirá conocer alcance real, presupuesto por componente, estándares, fuentes de datos y condiciones de operación. Después, la fase de implantación mostrará si los objetivos generales se convierten en servicios utilizados.
La sostenibilidad posterior a RedCyTI será una prueba relevante: un proyecto maduro debería poder mantenerse y evolucionar sin depender de una nueva subvención para cada cambio.
Preguntas frecuentes
¿Está ya desplegado Málaga Smart Economy?
No. La fuente oficial confirma su selección dentro de RedCyTI; el detalle de ejecución se concretará en fases posteriores.
¿Cuánto financia Red.es?
RedCyTI financia entre el 40% y el 85% del presupuesto subvencionable de cada proyecto según el territorio. La fuente general consultada no detalla aquí la cifra individual de esta iniciativa.
¿Qué debería exigirse técnicamente?
Interoperabilidad, seguridad, documentación, portabilidad, reversibilidad y métricas de impacto son requisitos especialmente relevantes.
¿Cómo debería medirse el éxito?
Con resultados ligados al objetivo económico o de servicio, no solo con tecnología instalada.
Fuentes
La información confirmada sobre la selección y denominación del proyecto procede de Red.es, publicación del 15 de septiembre de 2026 sobre los 52 proyectos RedCyTI.
Lecturas relacionadas
Puede ampliarse contexto con nuestros análisis sobre gobierno del dato, gemelos digitales, interoperabilidad y código abierto y ciberseguridad municipal.
De proyecto financiado a servicio estable
La implantación de Málaga Smart Economy debería organizarse por fases. Primero, diseño e inventario: sistemas existentes, datos, usuarios, dependencias y responsables. Después, pilotos controlados con métricas definidas antes de empezar. Por último, industrialización: soporte, monitorización, copias, gestión de incidencias, formación y presupuesto recurrente.
Esta secuencia evita comprar tecnología antes de entender el problema. También permite detectar si una necesidad puede resolverse simplificando un procedimiento o reutilizando una capacidad ya disponible.
Cada fase debería cerrar con una decisión explícita sobre continuidad, cambios o retirada. La transformación digital mejora cuando los proyectos pueden aprender y corregirse, no cuando el alcance inicial se considera inamovible.
Pruebas con escenarios reales y de fallo
Las pruebas deberían cubrir usuarios reales, datos incompletos, caídas de servicios, cambios de versión y errores de integración. Un sistema que solo funciona en condiciones ideales puede generar una carga operativa importante cuando entra en producción.
Automatizar parte de las pruebas permite comparar versiones y detectar regresiones. La evidencia obtenida también sirve para aceptar entregas y exigir correcciones al proveedor con criterios objetivos.
La reversibilidad debería probarse durante el proyecto: exportar información, restaurar una copia, sustituir una credencial o conectar un componente alternativo. Esperar al final del contrato para comprobarlo aumenta el riesgo.
Observabilidad y trazabilidad operativa
Una plataforma pública necesita registros que permitan reconstruir qué ocurrió ante un error. Identificadores de transacción, tiempos, sistemas implicados y resultado ayudan a localizar la causa sin almacenar más información de la necesaria.
Los cuadros de mando operativos deberían centrarse en señales que permitan actuar: disponibilidad, latencia, errores, volumen, calidad y consumo de recursos. Acumular métricas sin responsables ni umbrales genera ruido y no mejora el servicio.
La trazabilidad también facilita auditorías y análisis de coste. Saber qué componentes se utilizan y cuánto consumen permite tomar decisiones de capacidad con datos.
Gobernanza del cambio
Las tecnologías, estándares y necesidades evolucionan. Por ello debe existir un proceso para aprobar cambios de versión, nuevas integraciones, modificación de políticas o sustitución de componentes. Cada cambio relevante debería tener responsable, pruebas y posibilidad de reversión.
Una hoja de ruta compartida ayuda a coordinar equipos internos y proveedores. También evita que actualizaciones aparentemente pequeñas introduzcan incompatibilidades en sistemas dependientes.
La documentación de decisiones técnicas reduce dependencia de personas concretas y facilita que nuevos equipos entiendan por qué la arquitectura funciona de determinada manera.
Capacidad interna y conocimiento público
Externalizar desarrollo o soporte no elimina la necesidad de conocimiento interno. La Administración debe conservar capacidad para interpretar indicadores, entender dependencias, revisar entregas y decidir prioridades.
La formación debería combinar sesiones iniciales con materiales prácticos y actualizaciones periódicas. Los usuarios necesitan saber cómo actuar ante excepciones, y los técnicos, cómo diagnosticar problemas sin depender siempre del proveedor.
También es útil documentar qué conocimiento debe permanecer en la organización al terminar el contrato: arquitectura, credenciales, configuraciones, procedimientos, inventarios y contactos.
Retorno y coste de oportunidad
El retorno no siempre es directamente financiero. Puede expresarse en tiempo ahorrado, reducción de errores, mayor disponibilidad, mejor información o capacidad de atender a más usuarios con los mismos recursos. Lo importante es definirlo antes de empezar.
También existe coste de oportunidad: recursos dedicados a una función poco utilizada no pueden destinarse a otras necesidades. Revisar uso real ayuda a evitar que el proyecto acumule módulos por inercia.
Una evaluación anual debería comparar beneficios, costes y riesgos para decidir qué ampliar, simplificar o retirar.
Reutilización y estándares comunes
Los proyectos financiados con fondos públicos generan más valor cuando producen activos reutilizables. Modelos de datos, APIs, cláusulas contractuales, pruebas, guías o componentes de código pueden reducir el coste de iniciativas futuras.
La reutilización requiere documentación y licencias adecuadas. Publicar un repositorio sin instrucciones, dependencias o modelo de mantenimiento ofrece un valor limitado a otras entidades.
Compartir también problemas y decisiones que no funcionaron ayuda a que otras Administraciones eviten repetir inversiones poco útiles.
Una revisión seis meses después del despliegue
Seis meses después de la puesta en marcha conviene revisar adopción real, incidencias, rendimiento, costes y satisfacción. Esta evaluación permite detectar si los usuarios han incorporado el servicio o continúan utilizando procesos anteriores en paralelo.
También debería compararse la situación con la línea base inicial. Si no mejoran los indicadores previstos, el proyecto necesita ajustes aunque técnicamente esté funcionando.
La revisión periódica convierte Málaga Smart Economy en una capacidad que aprende. Esa disciplina es lo que diferencia un proyecto tecnológico puntual de un servicio público sostenible.
Conclusión
Málaga Smart Economy entra en RedCyTI para reforzar la economía inteligente urbana tendrá valor si deja una capacidad operativa, medible y mantenible, además de la tecnología contratada. Datos, interoperabilidad, seguridad, gobernanza y conocimiento interno serán determinantes para que la inversión siga siendo útil después de la fase financiada.
El objetivo final debería ser que la organización pueda evolucionar el servicio con evidencia propia, sustituir componentes cuando sea necesario y compartir aprendizajes con otras Administraciones.
Fotografía: Aliaksei Lepik / Pexels.