El Consejo de Ministros ha autorizado la celebración del nuevo Sistema Dinámico de Adquisición para el desarrollo y mantenimiento de programas a medida de la Administración electrónica, identificado como SDA 26/2026 y con un valor estimado de 1.082 millones de euros. El instrumento dará continuidad al SDA 26/2021 y permitirá contratar consultoría, desarrollo, implantación, auditoría y mantenimiento de aplicaciones utilizadas por las administraciones públicas.
El Ministerio de Hacienda presentó la autorización el 22 de septiembre. El nuevo sistema tendrá una duración inicial de dos años y podrá prorrogarse hasta un máximo de cinco. Su ámbito incluye a la Administración General del Estado, organismos autónomos, Seguridad Social y otras entidades públicas estatales, además de organismos autonómicos y locales que formalicen su adhesión.
La cifra de 1.082 millones es un valor estimado del sistema dinámico y no equivale a un contrato único adjudicado a una empresa. Cada organismo realizará contratos específicos dentro del SDA según sus necesidades y presupuesto.
Qué es un sistema dinámico de adquisición
Un SDA es una técnica de contratación completamente electrónica que permite incorporar proveedores durante todo su periodo de vigencia. A diferencia de un acuerdo marco cerrado tras su adjudicación, nuevas empresas pueden solicitar acceso si cumplen los requisitos establecidos.
Esta característica busca ampliar competencia y evitar que un mercado tecnológico quede cerrado durante varios años a los proveedores que no participaron en la primera fase.
1.082 millones como valor estimado
El importe refleja la previsión agregada de contratación que podrá canalizarse a través del sistema. No obliga a las administraciones a consumir toda esa cantidad y tampoco identifica de antemano qué empresas recibirán los contratos.
La ejecución real dependerá de los contratos específicos que liciten los organismos adheridos.
Dos años iniciales y hasta cinco de vigencia
Hacienda prevé una duración inicial de dos años. El sistema podrá ampliarse mediante prórrogas hasta alcanzar cinco años, lo que ofrece continuidad para proyectos de software que necesitan mantenimiento y evolución.
La administración deberá vigilar que una larga vigencia no convierta los contratos específicos en relaciones tecnológicas difíciles de sustituir.
Continuidad del SDA 26/2021
El nuevo instrumento sustituirá progresivamente al SDA anterior, puesto en marcha dentro del Sistema Estatal de Contratación Centralizada. Según Hacienda, en algo más de cuatro años el sistema previo admitió 217 empresas y permitió adjudicar más de 1.700 contratos específicos.
Estas cifras ofrecen una base real para evaluar si la contratación dinámica amplía competencia frente a procedimientos más cerrados.
Consultoría tecnológica
Los organismos podrán contratar análisis funcional, arquitectura, diseño y apoyo especializado. La consultoría debería producir documentación reutilizable y transferir conocimiento al equipo público.
Un diagnóstico que solo entiende el proveedor aumenta dependencia y dificulta una futura licitación.
Desarrollo de software a medida
El SDA cubre aplicaciones que no pueden resolverse únicamente con productos estándar. Sedes electrónicas, sistemas internos, registros o aplicaciones sectoriales suelen requerir adaptación a procedimientos concretos.
El desarrollo debe partir de necesidades verificables y no de una lista de tecnologías predeterminadas.
Implantación
Una aplicación no genera valor hasta que se integra en el flujo de trabajo. La implantación incluye migración de datos, formación, conexión con otros sistemas y pruebas con usuarios.
Los contratos específicos deberían distinguir claramente desarrollo e implantación para evitar considerar terminado un proyecto que todavía no funciona en producción.
Auditoría de aplicaciones
El nuevo SDA permitirá contratar revisiones técnicas y de seguridad. Las auditorías pueden analizar código, arquitectura, rendimiento, protección de datos o cumplimiento del Esquema Nacional de Seguridad.
Cuando sea posible, la revisión debería realizarla un equipo diferente al desarrollador original para aportar independencia.
Mantenimiento evolutivo y correctivo
La mayor parte del coste de una aplicación pública aparece después de su lanzamiento. Cambios normativos, vulnerabilidades, nuevas integraciones y necesidades de usuarios obligan a mantener el software durante años.
Los contratos deben diferenciar mantenimiento correctivo de nuevas funcionalidades y definir niveles de servicio.
Sedes electrónicas
Las sedes son uno de los ejemplos citados por Hacienda. Su disponibilidad afecta a presentación de solicitudes, notificaciones y procedimientos con plazos legales.
Las pruebas de carga, accesibilidad y recuperación ante fallos deberían formar parte de cualquier evolución relevante.
Portales públicos
Los portales institucionales necesitan gestores de contenido, buscadores, analítica y medidas de accesibilidad. La renovación tecnológica no debería obligar a cambiar toda la información si el contenido puede migrarse mediante formatos estructurados.
Separar contenido de presentación reduce el coste de futuras evoluciones.
Sistemas de tramitación
Los gestores de expedientes concentran lógica administrativa. Un cambio normativo puede requerir nuevas reglas, estados o documentos.
Diseñar componentes configurables reduce la necesidad de programar cada modificación desde cero.
Registros y bases de datos
El software público maneja grandes volúmenes de información. Los proyectos deben documentar modelos de datos, políticas de retención y calidad.
Una aplicación nueva no debería convertirse en otra base aislada si la información ya existe en un sistema corporativo.
Sistemas de intercambio de información
La interoperabilidad permite que el ciudadano no tenga que aportar documentos que ya posee otra administración. APIs y servicios compartidos reducen duplicidades.
El principio once-only y la experiencia italiana de PDND muestran cómo una plataforma común puede organizar intercambios a escala.
Aplicaciones móviles
El SDA incluye también desarrollo de apps. Antes de crear una aplicación independiente, cada organismo debería evaluar si la funcionalidad puede integrarse en canales existentes.
La fragmentación obliga al ciudadano a instalar múltiples herramientas y aumenta el coste de mantenimiento.
Herramientas de gestión interna
Recursos humanos, compras, inventario o planificación también pueden requerir desarrollos específicos. La digitalización interna debe medir horas ahorradas y reducción de errores.
Automatizar un proceso innecesariamente complejo no elimina la necesidad de simplificarlo primero.
Participación de pymes
Una ventaja del sistema dinámico es que nuevas empresas pueden incorporarse durante su vigencia. Esto abre oportunidades a proveedores que nacen o adquieren capacidad después de la licitación inicial.
Los contratos específicos deben mantener requisitos proporcionados para no excluir de facto a empresas pequeñas.
217 empresas en el sistema anterior
Hacienda utiliza esta cifra como indicador de apertura. El dato permite seguir qué porcentaje de contratos se distribuye entre grandes empresas y pymes.
La competencia real no se mide solo por número de empresas admitidas, sino por cuántas reciben invitaciones y adjudicaciones.
Más de 1.700 contratos específicos
La experiencia previa demuestra que el SDA puede canalizar gran cantidad de compras sin repetir una licitación completa para cada necesidad.
El seguimiento debería publicar importes, adjudicatarios y número de ofertas para evaluar competencia.
Contratación centralizada y autonomía
El sistema común simplifica la fase de selección de proveedores, pero cada organismo mantiene la responsabilidad sobre su contrato específico. Debe definir correctamente alcance, criterios y aceptación.
La centralización no sustituye la capacidad técnica de quien compra.
Adhesión de comunidades autónomas y entidades locales
El nuevo SDA podrá utilizarse más allá de la AGE mediante adhesión específica. Esto puede ser especialmente útil para administraciones que no tienen recursos para crear un sistema propio.
La adhesión debería acompañarse de guías para preparar contratos y supervisar entregables.
Interoperabilidad como requisito contractual
Los pliegos pueden exigir APIs documentadas, formatos abiertos y cumplimiento del Esquema Nacional de Interoperabilidad. Esta exigencia reduce el coste de conectar aplicaciones nuevas con servicios existentes.
La arquitectura modular de GovStack ofrece una referencia sobre componentes reutilizables.
Portabilidad y salida
Los contratos deben definir cómo se entregan datos, código y documentación cuando termina el servicio. Sin un plan de salida, cambiar de proveedor puede resultar más caro que continuar con el actual.
La CNMC ha señalado la importancia de la portabilidad en servicios tecnológicos públicos.
Propiedad del código
Cuando el sector público financia desarrollo a medida, conviene aclarar derechos de uso, modificación y reutilización. No todos los proyectos deben publicarse como software abierto, pero la administración necesita capacidad para mantenerlos con otro proveedor.
Las cláusulas de propiedad intelectual deben definirse antes de comenzar el desarrollo.
Open source
El SDA puede incorporar soluciones abiertas cuando sean adecuadas. La estrategia europea de software abierto refuerza la reutilización de soluciones financiadas con fondos públicos.
El código abierto no elimina la necesidad de soporte, seguridad ni gobierno del proyecto.
Ciberseguridad por diseño
Los nuevos desarrollos deberán gestionar vulnerabilidades, dependencias y actualizaciones. El contrato puede exigir análisis de composición de software y un procedimiento para corregir fallos críticos.
La seguridad incorporada desde el inicio resulta más barata que una auditoría tardía con cambios estructurales.
ENS
Las aplicaciones que entren en su ámbito deberán cumplir el Esquema Nacional de Seguridad según categoría y riesgo. Las evidencias pueden automatizarse parcialmente.
El avance hacia un ENS legible por máquina puede facilitar controles continuos.
Protección de datos
Los contratos deben definir roles, subencargados y condiciones de tratamiento. Un proveedor de desarrollo puede acceder a bases de pruebas o producción.
Utilizar datos sintéticos o anonimizados en entornos de desarrollo reduce exposición.
Accesibilidad
Portales, apps y sistemas que utilicen ciudadanos o empleados deben cumplir requisitos de accesibilidad. La aceptación del contrato debería incluir pruebas y no limitarse a una declaración del proveedor.
Corregir barreras antes de producción es más eficiente que hacerlo después de recibir reclamaciones.
Diseño centrado en usuario
La contratación tecnológica suele centrarse en especificaciones funcionales. Incorporar pruebas con usuarios permite detectar formularios confusos, lenguaje técnico o pasos innecesarios.
La calidad del servicio digital debe medirse desde la experiencia final.
Deuda técnica
El SDA también servirá para mantener sistemas existentes. Antes de añadir funciones conviene identificar componentes obsoletos y dependencias sin soporte.
Reservar presupuesto para reducir deuda técnica evita que cada evolución sea más costosa que la anterior.
Arquitectura de referencia
Los organismos pueden definir tecnologías, estándares y patrones corporativos para que proveedores diferentes trabajen de forma coherente. La arquitectura no debe convertirse en una lista rígida que impida innovación.
Su función es reducir incompatibilidades y costes de integración.
Observabilidad
Las aplicaciones necesitan métricas, logs y trazas. Sin observabilidad, un fallo puede tardar horas en diagnosticarse.
Los contratos deberían entregar cuadros de mando y documentación sobre qué indicadores se monitorizan.
Niveles de servicio
La disponibilidad requerida depende del sistema. Una sede con plazos administrativos puede necesitar un nivel más alto que una herramienta interna no crítica.
Los SLA deben relacionar prioridad, tiempo de respuesta y tiempo de resolución.
Pruebas automáticas
Los desarrollos a medida pueden incorporar tests unitarios, integración y seguridad. Esta base reduce regresiones cuando el software evoluciona.
La administración debería recibir el conjunto de pruebas como parte del entregable.
Integración continua
Los contratos modernos pueden utilizar pipelines de construcción y despliegue controlados. La automatización mejora trazabilidad y reduce cambios manuales en producción.
Los permisos de despliegue deben permanecer bajo control de la organización responsable.
Datos de calidad
Una aplicación nueva puede fallar aunque su código sea correcto si recibe datos incompletos. Los proyectos deben definir validaciones y responsables de información.
La calidad del dato forma parte del servicio, no es un problema externo al software.
Inteligencia artificial
El SDA puede acabar financiando funcionalidades basadas en IA dentro de aplicaciones públicas. Esos componentes necesitan evaluación específica, trazabilidad y supervisión según su función.
El Plan IA360 ofrece el contexto nacional para una adopción responsable.
Métricas del nuevo SDA
Hacienda podrá evaluar número de empresas admitidas, ofertas por contrato, tiempos de adjudicación, distribución entre pymes y grandes compañías, importes y ahorro administrativo.
Publicar estas métricas permitirá comparar el nuevo sistema con el SDA 26/2021.
Medir calidad además de velocidad
Una contratación rápida no garantiza un buen software. También deberían medirse incidencias, retrasos, disponibilidad y satisfacción de los organismos usuarios.
La evaluación puede identificar proveedores y modalidades de contrato que producen mejores resultados.
Fuente oficial
El Ministerio de Hacienda informó de la autorización el 22 de septiembre de 2026 en la nota sobre el nuevo SDA para Administración electrónica. La autorización figura igualmente en la referencia del Consejo de Ministros.
El reto no será únicamente canalizar 1.082 millones de euros, sino utilizar la escala de la contratación centralizada para obtener software público más interoperable, seguro, mantenible y fácil de sustituir.
Qué cambia para los organismos que ya usaban el SDA anterior
Las unidades de contratación que venían utilizando el SDA 26/2021 podrán apoyarse en una técnica conocida, pero tendrán que revisar las condiciones, categorías y documentación del nuevo sistema antes de lanzar contratos específicos. La continuidad del modelo reduce la curva de aprendizaje, aunque no elimina la necesidad de actualizar pliegos y criterios.
El dato más relevante para el mercado es que el sistema seguirá abierto a la incorporación de nuevos operadores durante toda su vigencia. Esto permite que empresas que hoy no cumplen requisitos puedan prepararse y solicitar admisión más adelante, en lugar de quedar fuera durante varios años.
El reto será medir competencia real
El número de empresas admitidas no basta para evaluar el funcionamiento. Hacienda podrá observar cuántos proveedores reciben invitaciones, cuántos presentan oferta, qué concentración existe por adjudicatario y cuánto tardan los contratos específicos desde la necesidad hasta la formalización.
Estos indicadores permitirán comprobar si el nuevo SDA mantiene la agilidad del sistema anterior al mismo tiempo que amplía la competencia y la participación de pymes.
Fotografía: cottonbro studio / Pexels.