Desarrollo de software gubernamental: guía 2026 de cumplimiento, costes y entrega

Yury Pukhov CEO & Mobile Engineering Lead, YuSMP Group

El desarrollo de software gubernamental en 2026 consiste tanto en escapar de los sistemas antiguos como en crear otros nuevos. En su revisión de 2025 de las TI federales, GAO-25-107795, la Oficina de Rendición de Cuentas del Gobierno de EE. UU. (GAO) constató que unos 83 mil millones de dólares, es decir, el 79 % del gasto en TI previsto para el ejercicio fiscal 2025 por las 24 principales agencias federales, se destinaban a operar y mantener sistemas existentes, y que las agencias suelen gastar en torno al 80 % de sus presupuestos de TI de este modo. Cada dólar dedicado a mantener vivo un sistema de hace décadas es un dólar que no se invierte en los servicios que realmente utilizan los ciudadanos.

Crear software público es además más difícil que crear software comercial. El mismo proyecto debe superar una autorización de seguridad, cumplir la legislación de accesibilidad, sobrevivir a un proceso de contratación pública, conservar registros durante años y resistir el escrutinio público cuando algo sale mal. Por eso las agencias confían cada vez más la entrega a equipos especializados en desarrollo de software GovTech que diseñan pensando en la autorización y la accesibilidad desde el primer día, en lugar de tratarlas como una lista de comprobación final.

Esta guía aborda el desarrollo de software para el sector público en tres ámbitos: agencias federales de EE. UU., gobiernos estatales y locales de EE. UU. y organismos públicos de la Unión Europea. Explica qué es el software gubernamental, qué sistemas desarrollan las agencias, qué normas de cumplimiento se aplican en 2026, en qué se diferencian los proyectos federales, estatales, locales y de la UE, cuándo desarrollar o comprar, el proceso de entrega, la modernización de sistemas heredados, el papel de la IA, costes y plazos realistas, la contratación pública y cómo elegir un partner de entrega.

¿Qué es el desarrollo de software gubernamental?

El desarrollo de software gubernamental es el diseño, la construcción y la operación de sistemas digitales para organismos públicos: portales ciudadanos, gestión de expedientes, plataformas fiscales y de prestaciones, sistemas de seguridad pública y las herramientas internas con las que trabajan las agencias. Sigue las mismas prácticas de ingeniería que el software comercial, pero añade cuatro restricciones que los equipos comerciales rara vez afrontan a la vez: autorización formal de seguridad, legislación de accesibilidad, normas de contratación pública y obligaciones de conservación de registros y transparencia a largo plazo.

Estas restricciones cambian la forma de planificar el trabajo. Un equipo de producto comercial puede lanzar una beta y corregir la accesibilidad más adelante; una agencia estatal normalmente no, porque la accesibilidad es una obligación legal desde la primera versión pública. Una startup puede elegir cualquier región de la nube; un programa federal debe funcionar sobre una infraestructura que tenga la autorización adecuada para sus datos. Una empresa privada puede cambiar de proveedor con un preaviso contractual; una agencia necesita un plan de salida documentado, portabilidad de datos y, en la UE, a veces la obligación de compartir su solución con otros organismos públicos.

La mayoría de los sistemas gubernamentales encajan en cuatro modelos de relación. El modelo indica quiénes son los usuarios, qué normas de identidad y accesibilidad se aplican y cuánta visibilidad pública tendrá el sistema.

Dentro de estos modelos, las agencias eligen entre productos estándar, plataformas configurables y desarrollo de software a medida para agencias gubernamentales. El trabajo a medida suele reservarse para procesos definidos por una ley concreta, para sistemas que deben comunicarse con mainframes heredados y para servicios en los que no encaja ningún producto autorizado. Las funciones estándar como RR. HH., nóminas y correo electrónico suelen resolverse mejor con productos comerciales autorizados.

¿Por qué las agencias modernizan su software gubernamental en 2026?

Las agencias se modernizan en 2026 porque los sistemas heredados consumen la mayor parte de los presupuestos de TI, varios plazos legales están cerca y los ciudadanos esperan ya que los servicios públicos funcionen con la misma fluidez que la app de su banco. La presión llega desde seis frentes a la vez:

• La operación y el mantenimiento se comen el presupuesto. La GAO informó en 2025 de que aproximadamente el 79 % del gasto en TI previsto para el FY2025 en las 24 agencias sujetas a la CFO Act, unos 83 mil millones de dólares, se destinaba a operación y mantenimiento, lo que dejaba poco para nuevas capacidades.
• Los sistemas críticos son muy antiguos. El mismo informe de la GAO constató que los 11 sistemas federales heredados más críticos tienen entre 23 y 60 años, y 8 de ellos funcionan con lenguajes de programación obsoletos como COBOL.
• Los planes de modernización van con retraso. En febrero de 2025, la GAO contabilizaba 28 de 65 modernizaciones de sistemas heredados previstas como completadas, es decir, el 43 %, por lo que la mayoría de las agencias llega a 2026 con trabajo de modernización pendiente.
• La experiencia digital es ya una exigencia legal. La 21st Century Integrated Digital Experience Act (21st Century IDEA) exige que los sitios web y servicios digitales federales sean accesibles, coherentes, adaptados a móviles y fáciles de buscar, lo que empuja a las agencias a reconstruir sus portales antiguos.
• Los plazos de accesibilidad están fijados. La norma ADA Title II del Departamento de Justicia de EE. UU. exige que el contenido web y las apps móviles estatales y locales cumplan WCAG 2.1 AA, con fechas de cumplimiento en abril de 2027 y abril de 2028 tras la prórroga de 2026.
• La UE avanza hacia la identidad digital. En virtud de eIDAS 2.0, cada Estado miembro de la UE debe ofrecer una Cartera Europea de Identidad Digital (EUDI Wallet) y las administraciones públicas deben aceptarla antes del 24 de diciembre de 2026, por lo que los servicios públicos de toda Europa necesitan flujos de acceso y de documentos preparados para la cartera.

La inteligencia artificial añade un séptimo factor de presión. Las agencias quieren que la IA reduzca los atrasos en el procesamiento de documentos y en los centros de atención, pero necesitan supervisión humana, registros de auditoría y pruebas de sesgo que los equipos comerciales a menudo pueden omitir.

¿Qué tipos de software gubernamental desarrollan las agencias?

Las agencias desarrollan nueve tipos principales de software gubernamental, desde portales de cara al público hasta sistemas financieros internos. Cada tipo tiene un perfil de riesgo distinto, de modo que el tipo determina el nivel de autorización, el esfuerzo de accesibilidad y el trabajo de integración mucho antes de escribir una línea de código.

Portales ciudadanos y servicios digitales

Los portales ciudadanos son la puerta de entrada a la Administración: un único lugar para solicitar, pagar, reservar, seguir una solicitud o actualizar datos personales. Un buen portal oculta el organigrama y se estructura en torno a acontecimientos vitales como mudarse, crear una empresa o tener un hijo. Una capacidad clave es una cuenta única con solicitudes guardadas y seguimiento del estado, para que los ciudadanos no tengan que volver a introducir los mismos datos en cada agencia. Nuestra guía de desarrollo de portales web recoge patrones de arquitectura que también se aplican a los portales públicos.

Gestión de expedientes, permisos y licencias

Los sistemas de gestión de expedientes ejecutan el trabajo que hay detrás de una decisión pública: llega una solicitud, el personal la revisa, pide documentos, aplica las normas y emite una resolución. Los sistemas de permisos y licencias son una variante habitual para licencias de obra, licencias de actividad y certificaciones profesionales. La capacidad más importante es un flujo de trabajo configurable, para que los cambios de reglas tras una nueva ley u ordenanza se apliquen sin un redesarrollo completo.

Plataformas fiscales, de recaudación y de prestaciones

Las plataformas fiscales, de recaudación y de prestaciones calculan lo que una persona o empresa debe o se le debe y mueven dinero real, por lo que la exactitud y la auditabilidad son lo primero. A menudo contienen información fiscal federal, lo que implica los controles de la IRS Publication 1075, o datos de salud, lo que implica HIPAA. Una capacidad típica es un motor de reglas que codifica la lógica de elegibilidad y de cálculo de forma comprobable y versionada, para que auditores y personal de políticas puedan revisarla.

Contratación pública y licitación electrónica

Los sistemas de contratación pública y licitación electrónica publican oportunidades, recogen ofertas, gestionan las evaluaciones y administran los contratos. Deben ser transparentes y dejar constancia de cualquier manipulación, porque una licitación impugnada puede paralizar un programa durante meses. Sus capacidades básicas son las presentaciones con sello de tiempo, la gestión de ofertas en sobre cerrado, las declaraciones de conflicto de intereses de los evaluadores y un registro de auditoría completo de cada decisión.

Seguridad pública y gestión de emergencias

El software de seguridad pública incluye el despacho asistido por ordenador, la gestión de registros policiales y de bomberos, las alertas de emergencia y la coordinación de incidentes. Todo sistema que maneje información de justicia penal debe cumplir la FBI CJIS Security Policy, que fija requisitos de control de acceso, cifrado y verificación del personal. La disponibilidad es el requisito dominante: estos sistemas necesitan conmutación por error probada y modos sin conexión para las unidades sobre el terreno.

Registros, gestión documental y FOIA

Los sistemas de registros y gestión documental capturan, clasifican, conservan y eliminan los registros públicos según los calendarios de conservación. También dan soporte a las solicitudes al amparo de la Freedom of Information Act (FOIA) y de acceso a registros públicos, donde importan la rapidez y el enmascaramiento preciso de datos. Una capacidad valiosa es el apoyo automatizado a la clasificación y al enmascaramiento, con un revisor humano que aprueba cada divulgación.

Plataformas geoespaciales, GIS y de ciudad inteligente

Las plataformas geoespaciales sustentan los mapas de zonificación, la gestión de activos, la planificación del transporte y la respuesta a emergencias, y los sistemas de ciudad inteligente añaden datos de sensores de semáforos, suministros y monitores ambientales. Combinan grandes conjuntos de datos con flujos en tiempo real, por lo que la arquitectura de datos y los estándares abiertos determinan si escalan. Una capacidad habitual es una capa de mapa pública que los ciudadanos pueden consultar, respaldada por capas internas de acceso restringido.

ERP, RR. HH. y finanzas internos para agencias

Los sistemas internos de ERP, RR. HH. y finanzas gestionan presupuestos, nóminas, compras, subvenciones y personal. Estas necesidades suelen estar bien cubiertas por productos comerciales autorizados, así que el trabajo a medida tiende a centrarse en las integraciones y en las reglas contables de subvenciones o fondos propias de cada agencia. La capacidad clave es una integración fiable con los sistemas de registro que alimentan los informes para legisladores y auditores.

API de datos abiertos y plataformas de interoperabilidad

Las plataformas de datos abiertos e interoperabilidad permiten a las agencias publicar conjuntos de datos e intercambiar información entre sí mediante API documentadas. En la UE, el Reglamento sobre la Europa Interoperable (Interoperable Europe Act) convierte la interoperabilidad en un requisito legal de diseño para los servicios públicos digitales transfronterizos. Una capacidad básica es un catálogo de API gobernado, con control de versiones, autenticación, límites de uso y documentación legible por máquina.

¿Qué funciones debe tener una plataforma pública?

Toda plataforma pública necesita identidad segura, formularios accesibles, pagos, control de acceso auditable y una capa de API, sea cual sea el servicio que preste. Incorporar estas capacidades a posteriori resulta caro, por lo que deben formar parte de las primeras decisiones de arquitectura y no de una versión posterior:

• Identidad y autenticación. Los servicios federales suelen usar Login.gov, que admite la verificación de identidad en el nivel 2 de garantía de identidad del NIST (IAL2); los servicios estatales pueden recurrir a proveedores de identidad estatales o a la verificación de identidad comercial; los servicios de la UE deben prepararse para la EUDI Wallet en virtud de eIDAS 2.0. La autenticación multifactor resistente al phishing es la opción segura por defecto para el personal.
• Formularios digitales y firma electrónica. Los formularios inteligentes que rellenan de antemano los datos conocidos, validan mientras el usuario escribe, guardan el progreso y aceptan documentos desde la cámara del móvil reducen el abandono y el trabajo repetido del personal.
• Pagos y desembolsos. El cobro de tasas, los reembolsos y el pago de prestaciones exigen conciliación con los sistemas financieros, justificantes claros y compatibilidad con los medios de pago que los ciudadanos realmente utilizan.
• Acceso basado en roles y registros de auditoría. Cada consulta y cada cambio de datos sensibles debe poder atribuirse a una persona y a un motivo, con registros a prueba de manipulaciones que respalden investigaciones y solicitudes de acceso a documentos.
• Notificaciones y seguimiento del estado. Las actualizaciones por correo electrónico, SMS y dentro de la aplicación sobre el estado de una solicitud reducen el volumen del centro de atención telefónica; las plantillas deben ser accesibles y estar disponibles en los idiomas que admite la agencia.
• Búsqueda en lenguaje claro y contenido multilingüe. Los ciudadanos buscan trámites, no nombres de departamentos. Un contenido redactado en lenguaje claro, traducido para las comunidades lingüísticas locales y probado con usuarios reales mejora las tasas de finalización más que el pulido visual.
• Analítica y una capa de API. Los paneles sobre tasas de finalización, tiempos de tramitación y puntos de abandono orientan las mejoras, mientras que las API documentadas permiten que otras agencias y socios autorizados reutilicen los datos sin recurrir al screen scraping.

¿Qué normas de cumplimiento se aplican al software público?

El software público debe cumplir normas de autorización de seguridad como FedRAMP, GovRAMP y FISMA, normas específicas de datos como CJIS, HIPAA e IRS Publication 1075, y leyes de accesibilidad como Section 508 y ADA Title II; los proyectos de la UE añaden el RGPD, NIS2, eIDAS 2.0, la Interoperable Europe Act y el Reglamento de IA de la UE (AI Act). Las normas aplicables dependen de quién es el cliente, qué datos contiene el sistema y dónde está alojado. El mapa de cumplimiento siguiente resume los marcos que afrontan la mayoría de los proyectos en 2026.

Los controles de seguridad y las prácticas de desarrollo seguro deben diseñarse desde el principio, no documentarse a posteriori. Nuestra guía sobre el NIST SSDF explica cómo las prácticas de desarrollo seguro se corresponden con la atestación que los compradores federales exigen ahora a los productores de software.

FedRAMP 20x explicado de forma sencilla

FedRAMP 20x es la iniciativa de FedRAMP para agilizar la autorización cloud sustituyendo largos documentos narrativos por evidencias automatizadas y legibles por máquina, junto con una validación continua. Según FedRAMP, las Consolidated Rules 2026 (CR26) se lanzaron el 25 de junio de 2026 y pusieron FedRAMP 20x al alcance general. El programa renombró los conocidos niveles de impacto Low, Moderate y High como Certification Classes B, C y D y añadió una nueva Class A de duración limitada.

El despliegue se hizo por etapas. FedRAMP informó de autorizaciones piloto de la Phase 2 en el nivel Moderate a partir del 6 de marzo de 2026 y abrió el proceso de la Class C el 31 de agosto de 2026. A finales de 2026, la lección práctica para agencias y proveedores es sencilla: construir sistemas capaces de generar evidencias de seguridad automáticamente a partir de la infraestructura como código, los registros y los escáneres, porque esa es la dirección que siguen tanto FedRAMP como las ATO de las agencias. Confirme siempre los requisitos vigentes en fedramp.gov antes de planificar una solicitud.

FedRAMP se aplica a los servicios cloud ofrecidos a agencias federales. El software a medida que una agencia aloja en su propio entorno cloud ya autorizado suele pasar, en cambio, por el proceso de ATO de la propia agencia, heredando controles de la plataforma autorizada. Los compradores estatales y locales buscan el estado GovRAMP (antes StateRAMP) en los productos cloud.

Accesibilidad: diseñar una sola vez para WCAG 2.2 AA

La estrategia de accesibilidad más eficiente en el desarrollo de software para el sector público es diseñar y probar para WCAG 2.2 nivel AA desde el inicio, porque ese único objetivo cubre tanto Section 508 (WCAG 2.0 AA) como la norma de ADA Title II (WCAG 2.1 AA). Las versiones de WCAG son retrocompatibles, de modo que cumplir 2.2 AA también cumple las versiones anteriores a las que remite la ley.

Para los gobiernos estatales y locales, los plazos cambiaron en 2026. La norma final provisional del Departamento de Justicia de EE. UU. publicada el 20 de abril de 2026 trasladó la fecha de cumplimiento de ADA Title II para las entidades que atienden a una población de 50,000 o más del 24 de abril de 2026 al 26 de abril de 2027, y para las entidades más pequeñas y los distritos especiales del 26 de abril de 2027 al 26 de abril de 2028. Las obligaciones en sí no cambiaron, así que el año adicional es tiempo para corregir, no un motivo para esperar.

Los escáneres automáticos solo detectan una parte de los problemas, así que planifique pruebas manuales con lectores de pantalla, navegación solo con teclado, ampliación y control por voz, e incluya a personas con discapacidad en la investigación de usabilidad. Nuestra guía de accesibilidad WCAG 2.2 enumera los criterios de conformidad que más a menudo fallan en las aplicaciones web. Los compradores federales también le pedirán un Accessibility Conformance Report basado en la plantilla VPAT, así que conserve las evidencias de las pruebas sobre la marcha.

¿En qué se diferencian los proyectos federales, estatales y locales?

Los proyectos federales, estatales, locales y del sector público de la UE se diferencian sobre todo en la autorización que exigen, la ley de accesibilidad aplicable, la forma de contratar y el tamaño de los presupuestos. Un proveedor que domina un nivel puede tropezar en otro, así que analice estas dimensiones antes de definir el alcance de un proyecto.

De ello se derivan dos consecuencias prácticas. Primero, un producto creado para un estado de EE. UU. rara vez puede revenderse a otro sin cambios en normas, formularios e integraciones, así que incorpore la configurabilidad desde el inicio. Segundo, los proyectos de la UE conllevan una obligación explícita de compartir: en virtud de la Interoperable Europe Act (Reglamento (UE) 2024/903), desde el 12 de enero de 2025 los organismos públicos deben realizar y publicar una evaluación de interoperabilidad antes de establecer requisitos vinculantes nuevos o sustancialmente modificados para servicios públicos digitales transeuropeos, y deben compartir las soluciones de interoperabilidad, incluido el código fuente documentado, con otros organismos públicos que lo soliciten.

Desarrollar, comprar o personalizar: ¿qué conviene a una agencia pública?

La mayoría de las agencias deberían comprar software comercial autorizado para las funciones estándar, configurar una plataforma low-code para el sector público en los flujos de casos habituales y reservar el desarrollo a medida para servicios definidos por una ley específica, una integración profunda con sistemas heredados u obligaciones de compartir código abierto. La respuesta correcta suele ser una combinación, decidida servicio a servicio y no de una vez para toda la agencia.

El desarrollo a medida gana cuando la lógica de elegibilidad o de cálculo está recogida en la ley y cambia a menudo, cuando el servicio depende de datos atrapados en sistemas con décadas de antigüedad o cuando la agencia debe publicar y compartir la solución. Comprar gana en correo electrónico, RR. HH., nóminas, finanzas estándar y otras funciones en las que los procesos son similares entre organizaciones. Nuestro marco para desarrollar o comprar explica un modelo de puntuación que puede adaptar a la cartera de una agencia.

El proceso de desarrollo de software para el sector público, paso a paso

El proceso de desarrollo de software para el sector público consta de ocho pasos, y lo que lo diferencia de la entrega comercial es que la autorización de seguridad y la accesibilidad recorren todos los pasos en lugar de esperar al final. Cada paso siguiente puede usarse como punto de control en un plan de proyecto.

1. Descubrimiento y mapa normativo. El equipo analiza la ley, los reglamentos y las políticas que definen el servicio, el proceso actual, los datos implicados y los sistemas afectados. El resultado es un backlog priorizado, una lista de restricciones legales y resultados medibles como el tiempo de tramitación o la tasa de finalización digital.
2. Investigación de usuarios, incluidos los usuarios de tecnologías de apoyo. Los investigadores entrevistan y observan a ciudadanos, empresas y personal de primera línea, incluidas personas que usan lectores de pantalla, ampliadores o control por voz y personas con un dominio limitado del inglés. El personal de primera línea suele ser la mejor fuente para conocer los apaños que el nuevo sistema debe eliminar.
3. Arquitectura y categorización de seguridad. El sistema se categoriza según el impacto de una brecha, por ejemplo conforme a FIPS 199 en los sistemas federales, lo que fija la línea base de controles. Los arquitectos eligen un alojamiento con la autorización adecuada, diseñan la identidad, los registros y los flujos de datos, y deciden qué controles se heredan de la plataforma.
4. Entrega ágil en pequeños incrementos. El trabajo se entrega en sprints de dos semanas y en cada uno se muestra software funcional a las partes interesadas. Un sistema de diseño compartido, como el U.S. Web Design System (USWDS) para servicios federales, mantiene las interfaces coherentes y accesibles por defecto.
5. Pruebas de seguridad y accesibilidad. El análisis automático de seguridad, las comprobaciones de dependencias y las pruebas de penetración se ejecutan junto con las comprobaciones automáticas de accesibilidad y las pruebas manuales con tecnologías de apoyo. Los defectos se gestionan como cualquier otro error, con gravedad y fecha de corrección.
6. Paquete de autorización. El equipo reúne el plan de seguridad del sistema (SSP), los resultados de la evaluación y el plan de acción e hitos (POA&M) para los riesgos abiertos, y da soporte a la evaluación independiente. Cuando las evidencias se recopilan automáticamente desde el primer sprint, este paso lleva semanas en lugar de meses.
7. Despliegue por fases y migración de datos. El nuevo servicio se lanza primero para un grupo piloto, una región o un tipo de solicitud, con los datos heredados migrados y conciliados en ejecuciones ensayadas. El funcionamiento en paralelo con el sistema antiguo protege a los ciudadanos si algo sale mal.
8. Operación y autorización continua. Tras el lanzamiento, la supervisión continua, la gestión de vulnerabilidades, las pruebas de regresión de accesibilidad y las versiones periódicas mantienen el sistema autorizado y en mejora constante. Presupueste esta fase desde el principio; dura mucho más que el desarrollo.

La tabla muestra una hoja de ruta típica de 12 meses para un servicio ciudadano de tamaño medio. Refleja un patrón habitual del sector, no un calendario fijo; la contratación, la calidad de los datos y la vía de autorización pueden desplazar cualquier fase.

Un ciclo de vida de desarrollo seguro es lo que hace posible este ritmo sin atajos. Nuestra guía del ciclo de vida de desarrollo de software seguro detalla las prácticas que hay detrás de los pasos 3 a 8.

¿Cómo modernizar sistemas públicos heredados sin interrumpir los servicios?

La mejor forma de modernizar los sistemas públicos heredados es por etapas, envolviéndolos primero con API y sustituyendo las funciones una a una, para que los ciudadanos nunca pierdan el acceso a un servicio durante la transición. Las sustituciones de golpe (big bang) de sistemas que pagan prestaciones o recaudan impuestos conllevan el mayor riesgo de fracaso público. Cuatro estrategias cubren la mayoría de las situaciones:

• Encapsular con API. Coloque una capa de API moderna delante del sistema heredado para que los nuevos portales y apps puedan leer y escribir datos sin tocar el código antiguo. Úsela cuando la lógica central funciona pero el problema es la interfaz; es la forma más rápida de mejorar la experiencia ciudadana.
• Rehost o re-platform. Traslade la aplicación existente a regiones cloud gubernamentales autorizadas, como AWS GovCloud o Azure Government, con cambios mínimos en el código, o a una base de datos o un entorno de ejecución gestionados. Úselo cuando el problema es el centro de datos, termina un contrato de hardware o los costes operativos deben bajar rápidamente.
• Refactorizar con el patrón «strangler fig». Reconstruya una función cada vez como un servicio nuevo, desvíe el tráfico hacia él y retire esa parte del sistema heredado, hasta que no quede nada. Úselo en sistemas grandes y críticos para el negocio, en los que una reescritura completa llevaría años y supondría demasiado riesgo.
• Reconstruir. Diseñe y desarrolle un sistema nuevo desde cero. Úselo cuando el sistema antiguo ya no se ajusta a la política, el código no puede entenderse ni mantenerse o la plataforma ha perdido el soporte sin vía de migración.

Elija la vía que elija, los datos suelen ser la parte más difícil. Los sistemas antiguos arrastran décadas de registros incoherentes, códigos que solo entiende el personal veterano y reglas de negocio ocultas en procesos por lotes. Perfile los datos desde el principio, acuerde las reglas de conciliación con los responsables de cada programa, ensaye las migraciones sobre copias completas y mantenga los sistemas antiguo y nuevo en paralelo hasta que los resultados coincidan. Nuestra guía sobre modernización de sistemas heredados compara estas estrategias con más detalle, y la página de nuestros servicios de modernización de software muestra cómo organizamos este trabajo por fases para organizaciones que no pueden permitirse interrupciones.

¿Dónde es útil la IA en el software para el sector público y dónde es de alto riesgo?

La IA resulta más útil en el software para el sector público en tareas repetitivas, de gran volumen y con mucha documentación, en las que una persona sigue tomando la decisión final; y es de alto riesgo cuando influye en decisiones sobre los derechos, las prestaciones o la libertad de las personas. Las agencias que separan pronto estas dos categorías pueden obtener mejoras de productividad sin crear exposición legal.

Los casos de uso más sólidos en 2026 son prácticos más que futuristas:

• Procesamiento inteligente de documentos. Extraer datos de formularios, documentos de identidad y justificantes cargados por los usuarios y derivar los expedientes a la cola adecuada.
• Asistentes para centros de atención y personal. Redactar respuestas a partir de contenido normativo aprobado para que los agentes las revisen, y resumir historiales de expedientes extensos.
• Detección de fraude y anomalías. Señalar solicitudes o pagos inusuales para que los investigue una persona, en lugar de denegarlos automáticamente.
• Apoyo a la traducción y al lenguaje claro. Elaborar primeros borradores de traducciones y de avisos simplificados que después revisa personal cualificado.

Los guardrails importan tanto como el modelo. Mantenga un revisor humano en cualquier decisión que afecte a una persona, registre las entradas y los resultados de salida, explique el razonamiento en términos que un ciudadano pueda impugnar y pruebe los sesgos entre grupos demográficos. En virtud del Reglamento de IA de la UE (AI Act), los sistemas de IA utilizados para evaluar el derecho a prestaciones públicas esenciales y muchos usos para la garantía del cumplimiento del Derecho se clasifican como de alto riesgo y exigen gestión de riesgos, gobernanza de datos, supervisión humana y documentación. Las agencias federales de EE. UU. publican inventarios de sus casos de uso de IA, así que dé por hecho que el uso de IA de su sistema será visible para el público. Si prevé funciones basadas en modelos de lenguaje, nuestro equipo de integración de IA generativa las desarrolla con recuperación desde fuentes aprobadas, registro de auditoría y revisión humana integrados, y nuestra lista de comprobación del Reglamento de IA de la UE resume las obligaciones de los proveedores.

¿Cuánto cuesta el desarrollo de software para el sector público?

El coste del desarrollo de software para el sector público depende sobre todo del alcance, del número y la antigüedad de los sistemas que hay que integrar y del esfuerzo de autorización y documentación, lo que puede hacer que un desarrollo público cueste varias veces más que una aplicación comercial con pantallas similares. Los rangos del sector publicados en 2026 varían mucho porque describen proyectos muy distintos, desde pequeñas herramientas municipales hasta plataformas de prestaciones de ámbito estatal.

La tabla combina rangos publicados en 2026 por dos empresas de desarrollo: Techanic Infotech, cuyas cifras describen herramientas públicas más pequeñas, de escala municipal o de pyme, y SISGAIN, cuyas cifras describen sistemas de mayor tamaño para agencias de EE. UU. Tómelas como orientación de mercado, no como presupuestos.

La distancia entre el extremo bajo y el alto no es ruido. Una sencilla herramienta de cita previa para un municipio pequeño y un sistema estatal de elegibilidad cuentan ambos como «software para el sector público», pero el segundo implica integraciones con sistemas heredados, normas federales sobre datos, una autorización formal y miles de usuarios internos. Al comparar presupuestos, compare el alcance y los supuestos de cumplimiento que los sustentan, no solo los totales. Para ver cómo se construyen en general los presupuestos de software a medida, consulte nuestro desglose del coste del desarrollo de software a medida; para obtener una estimación sobre su propio alcance, utilice el formulario al final de esta página.

¿Qué determina el coste del software para el sector público?

Siete factores influyen más en una estimación de software para el sector público que el número de pantallas o funciones:

• Cumplimiento y autorización. Preparar un paquete de ATO, FedRAMP o GovRAMP, las evaluaciones independientes y la supervisión continua puede absorber una gran parte del presupuesto.
• Integración con sistemas heredados. Conectar con mainframes, ficheros por lotes e interfaces sin documentar suele llevar más tiempo que desarrollar la nueva interfaz de usuario.
• Accesibilidad. El diseño, las pruebas manuales con tecnologías de apoyo y los informes de conformidad salen más baratos si se integran desde el principio, pero siempre necesitan tiempo específico.
• Migración de datos. Limpiar, mapear, conciliar y ensayar el traslado de décadas de registros es un proyecto en sí mismo.
• Identidad y acceso. La verificación de identidad, el inicio de sesión único para el personal y los permisos granulares añaden trabajo de integración y de pruebas.
• Alojamiento en entornos autorizados. Las regiones de nube para la Administración pública, la conservación de registros y las herramientas de seguridad cuestan más que el alojamiento comercial estándar.
• Costes de contratación pública y documentación. Las propuestas, los informes contractuales, el control de cambios y las obligaciones de archivo añaden tiempo tanto para la agencia como para el proveedor.

¿Cómo funcionan la contratación pública, los contratos y las RFP en el software para el sector público?

El software para el sector público se adquiere mediante contratación pública formal, y el tipo de contrato y el diseño de la RFP condicionan el resultado tanto como el propio proveedor. Las agencias que compran en módulos pequeños con requisitos basados en resultados obtienen software funcional antes y conservan la opción de cambiar de rumbo.

Cada tipo de contrato habitual se adapta a un grado de certidumbre distinto:

• Precio cerrado firme (firm-fixed-price): funciona para un alcance bien definido y estable, como la migración de un sistema conocido, pero empuja a los proveedores a incluir el riesgo en el precio y a resistirse a los cambios.
• Los contratos de tiempo y materiales o por horas de trabajo encajan en el descubrimiento y la entrega ágil cuando el alcance va a evolucionar, siempre que la agencia gestione activamente el backlog y fije topes.
• Los acuerdos marco de compra ágil (blanket purchase agreements) y los contratos IDIQ permiten a las agencias de EE. UU. precalificar a varios proveedores y emitir rápidamente órdenes de trabajo más pequeñas, lo que favorece la entrega iterativa.
• Los catálogos de ámbito gubernamental y los contratos cooperativos, como los multiple-award schedules federales o los acuerdos de compra cooperativa estatales, acortan la contratación pública de servicios habituales.
• Los procedimientos de la UE previstos en las directivas de contratación pública incluyen los procedimientos abierto y restringido, el diálogo competitivo para necesidades complejas y la asociación para la innovación para soluciones que todavía no existen en el mercado.

La contratación modular, es decir, adquirir un sistema grande como una serie de piezas más pequeñas licitadas por separado, reduce el riesgo de que fracase un único megacontrato. Redacte las RFP en torno a resultados y necesidades de los usuarios en lugar de una larga lista de funciones, pida a los proveedores que muestren software funcional o prototipos e incluya rondas de reto técnico en las que los equipos resuelvan un problema real. Nuestra guía para redactar una RFP de desarrollo de software incluye una plantilla, y nuestra comparativa de precio cerrado frente a tiempo y materiales ayuda a elegir el modelo comercial.

Resuelva pronto la propiedad intelectual. La agencia debe ser propietaria, o tener derechos sin restricciones, del código a medida, los datos, la documentación y la infraestructura como código, y el código fuente debe entregarse a un repositorio controlado por la agencia durante todo el proyecto. Muchos organismos públicos publican ya su código a medida como código abierto, y en la UE el Reglamento sobre la Europa Interoperable (Interoperable Europe Act) convierte en una expectativa legal compartir soluciones de interoperabilidad con otros organismos públicos.

¿Cómo elegir un socio de desarrollo de software para el sector público?

Elija un socio de desarrollo de software para el sector público por las pruebas de sistemas públicos entregados, la experiencia real en autorizaciones y la accesibilidad integrada en el proceso, no por la extensión de un folleto de capacidades. Al comparar servicios de desarrollo de software para el sector público, haga a todos los proveedores las mismas siete preguntas:

1. Trayectoria en el sector público. ¿Qué sistemas públicos o regulados en producción ha entregado el equipo y puede hablar con una referencia?
2. Experiencia en autorizaciones. ¿Ha preparado el equipo SSP, ha apoyado evaluaciones y ha gestionado supervisión continua, y frente a qué líneas base?
3. Accesibilidad integrada. ¿Diseña el proveedor según WCAG 2.2 AA, prueba manualmente con tecnologías de apoyo y entrega un Accessibility Conformance Report basado en el VPAT?
4. Personal y residencia de datos. ¿Puede el proveedor cumplir requisitos como personal con condición de US person, comprobación de antecedentes o tratamiento de datos exclusivamente en la UE cuando su sistema lo exija?
5. Ciclo de vida de desarrollo seguro. ¿Puede el proveedor firmar la declaración de desarrollo de software seguro (secure software development attestation) y mostrar cómo se aplican las prácticas del SSDF en su pipeline?
6. Informes ágiles transparentes. ¿Verá software funcional en cada sprint, un backlog compartido e informes honestos de velocidad y riesgos?
7. Condiciones de salida y traspaso. ¿Residirán el código, los datos, la documentación y la infraestructura en cuentas controladas por la agencia, con un plan de traspaso por escrito?

Señales de alarma en las propuestas de software para el sector público

Cinco señales de advertencia indican que una propuesta costará más o aportará menos de lo que promete:

• La autorización y la accesibilidad se describen en una sola línea o se presupuestan como extras opcionales.
• Un precio cerrado para un servicio complejo sin fase de descubrimiento ni supuestos enumerados.
• Afirmaciones como «FedRAMP compliant» o «508 certified» sin una inscripción de autorización ni un informe de conformidad que las respalden.
• Frameworks propietarios que solo el proveedor puede mantener, o código guardado en los repositorios del propio proveedor.
• Ningún plan de migración de datos, funcionamiento en paralelo o marcha atrás.

Las agencias grandes suelen combinar un equipo especializado en GovTech con una capacidad más amplia de desarrollo de software empresarial para integraciones, plataformas de datos y herramientas internas.

¿Cuáles son los errores habituales y qué métricas demuestran el éxito?

La mayoría de los proyectos de software público fallidos fracasan por motivos previsibles: lo lanzan todo de golpe, dejan la accesibilidad y la autorización para el final o ignoran al personal que usará el sistema a diario. La tabla empareja cada error habitual con una forma probada de evitarlo.

El éxito debe medirse en resultados para los ciudadanos y el personal, no en funciones entregadas. Cinco métricas sirven para la mayoría de los servicios:

• Tasa de finalización digital: la proporción de usuarios que inician un trámite en línea y lo terminan sin llamar ni acudir a una oficina.
• Tiempo hasta la resolución: la mediana del tiempo que transcurre desde una solicitud completa hasta la resolución.
• Defectos de accesibilidad: incidencias WCAG abiertas por gravedad, con tendencia a cero en las críticas.
• Disponibilidad frente al objetivo de nivel de servicio: disponibilidad y tiempo de respuesta medidos desde el lado del usuario.
• Coste por transacción: coste operativo total dividido entre las transacciones completadas, comparado con el canal heredado.

Preguntas frecuentes

Publicado el 8 de noviembre de 2026. Las fechas normativas y los detalles de los programas reflejan las fuentes públicas disponibles en el momento de la publicación: GAO-25-107795 (2025), la norma final provisional del Departamento de Justicia de EE. UU. en el Federal Register de 20 de abril de 2026, los anuncios de FedRAMP sobre FedRAMP 20x y las Consolidated Rules 2026, GovRAMP, las Revised Section 508 Standards, el Reglamento (UE) 2024/1183 (eIDAS 2.0) y el Reglamento (UE) 2024/903 (Interoperable Europe Act). Confirme siempre los requisitos vigentes con la autoridad competente. Los rangos de costes resumen cifras publicadas por empresas de desarrollo en 2026 y son solo orientativos; no son precios de YuSMP Group. YuSMP Group desarrolla según las líneas base de controles de FedRAMP y GovRAMP y no afirma contar con una autorización FedRAMP o GovRAMP. Los nombres de productos y programas pertenecen a sus respectivos titulares.