Un organismo que programe todo el software del Estado: qué parte de la idea funciona y qué parte falla siempre

Cualquiera que haya usado tres trámites digitales argentinos seguidos nota lo mismo: parecen hechos por planetas distintos. Distinto login, distinto criterio de diseño, distinta manera de pedir un CUIT, distinta pasarela de pago, distinto comportamiento en el celular. Algunos funcionan bien; otros son formularios que se rompen si tocás atrás en el navegador.

De ahí sale una idea intuitiva y bastante buena: centralizar. Un organismo con los mejores desarrolladores del país, que haga todo el software estatal siguiendo estándares serios de UX, performance, accesibilidad y seguridad. Software propio, no dependencia de proveedores externos.

La idea tiene respaldo real — existe, se implementó en varios países y funcionó. Pero también tiene una versión que fracasa de manera bastante predecible, y la diferencia entre ambas no está en el talento del equipo. Está en qué se centraliza exactamente.

---

1. El problema que se quiere resolver es real y caro

Antes de discutir la solución, conviene dimensionar el problema, porque suele subestimarse.

Cada organismo reinventa lo mismo. Autenticación de usuario, verificación de identidad, cobro, notificaciones, firma digital, generación de comprobantes, subida de documentación. Son las mismas seis o siete piezas en casi todos los trámites del Estado. Hoy cada organismo las resuelve por su cuenta, con presupuesto propio, con proveedor propio y con calidad dispar.

La calidad es aleatoria. No hay un piso exigible. Un servicio puede salir a producción sin haber pasado ninguna revisión de accesibilidad, sin auditoría de seguridad y sin métricas de performance. Depende enteramente de si el equipo que lo hizo tenía criterio.

No interoperan. El dato que ya le diste al Estado en un organismo te lo vuelve a pedir el siguiente. Esto no es un problema de UX: es un problema de arquitectura. Sin una capa de intercambio, cada sistema es una isla.

El costo agregado es invisible. Nadie suma cuánto gastó el Estado argentino en implementar login. Si alguien lo hiciera, el número sería incómodo.

Dependencia de proveedores. Sin capacidad técnica interna, el organismo no puede evaluar lo que compra, no puede mantener lo que le entregaron y queda atado al que lo construyó. Es el fenómeno clásico de captura por proveedor, y es la razón por la que sistemas críticos terminan siendo cajas negras que nadie adentro entiende.

Todo esto es real. La pregunta es qué forma de centralización lo resuelve.

---

2. El modelo existe: unidades digitales de gobierno

No hay que imaginarlo. Se hizo, hay una década de resultados y hay literatura sobre por qué funcionó donde funcionó.

Reino Unido — GDS

El Government Digital Service se creó en 2011 y es el caso fundacional. Consolidó miles de sitios gubernamentales dispersos en GOV.UK, publicó el Service Manual y el GOV.UK Design System, y estableció un estándar de servicio digital que cada equipo tenía que cumplir para poder publicar.

La pieza que casi nunca se menciona y que explica su éxito: GDS tenía poder de veto sobre el gasto en IT de los ministerios. Cualquier contratación por encima de cierto monto tenía que pasar por su aprobación. Sin esa palanca presupuestaria, habría sido un equipo de consultoría interna con lindas recomendaciones que nadie estaba obligado a seguir.

También vale mirar su declive: hacia 2018-2020 GDS perdió gente masivamente y buena parte de su influencia. Volvemos a eso en la sección de riesgos.

Estados Unidos — USDS y 18F

Nacieron después del fracaso del lanzamiento de healthcare.gov, que fue lo bastante público como para generar voluntad política. USDS operaba como equipo de intervención en proyectos críticos; 18F funcionaba más como consultora interna que cobraba a otros organismos por sus servicios.

Aportaron algo valioso: los Digital Services Playbooks y los estándares de contratación ágil, que atacan el problema desde la compra y no solo desde el desarrollo.

Estonia — X-Road

Es el caso más citado y también el peor entendido. Estonia no centralizó el desarrollo: centralizó la interoperabilidad.

X-Road es una capa de intercambio de datos que permite que los sistemas de distintos organismos se consulten entre sí de manera segura y auditada. Cada organismo sigue teniendo su sistema. Lo que se estandarizó fue el protocolo de conversación entre ellos.

De ahí sale el principio "once only": el Estado no te puede pedir dos veces el mismo dato. Si un organismo ya lo tiene, el otro lo consulta.

La lección es importante y va a contramano de la intuición centralizadora: el mayor salto de calidad no vino de unificar el desarrollo, sino de unificar la integración.

Singapur — GovTech

Modelo de agencia con capacidad técnica interna fuerte, presupuesto propio y mandato transversal. Desarrolla plataformas compartidas y también servicios verticales. Es probablemente el ejemplo más cercano a la idea de "organismo que programa" en sentido amplio, y funciona en un contexto de continuidad política y capacidad salarial estatal que no es replicable en todos lados.

Argentina — lo que ya existe

Conviene no plantearlo como si no hubiera nada.

Mi Argentina es un intento de identidad digital unificada con credenciales y acceso a trámites. TAD (Trámites a Distancia) es una plataforma transversal de expedientes. AFIP/ARCA tiene un ecosistema de servicios web con autenticación por certificado (WSAA) que, con todos sus defectos de documentación y ergonomía para el desarrollador, funciona a escala nacional hace años. Hubo sucesivas secretarías y subsecretarías de innovación pública con mandatos de este tipo.

O sea: la Argentina no carece del concepto. Carece de continuidad, de cobertura y de capacidad de exigir cumplimiento.

---

3. La distinción que decide todo: qué centralizar

Acá está el núcleo del asunto, y es donde la idea original necesita un ajuste.

"Centralizar la programación de todas las apps" puede significar dos cosas muy distintas:

(A) Un organismo que desarrolla todos los servicios del Estado.

(B) Un organismo que provee estándares, plataformas compartidas y control de calidad, mientras cada organismo desarrolla su servicio sobre esa base.

Los casos exitosos son abrumadoramente (B). Y (A) tiende a fallar por razones estructurales, no por falta de talento.

Por qué (A) falla

El conocimiento de dominio no es transferible barato. Entender de verdad cómo funciona una transferencia de dominio automotor, con sus excepciones, sus casos de vehículos con embargo, prendas, herencias y bajas mal registradas, lleva meses y vive en el organismo que lo opera. Un equipo central que atiende cuarenta organismos nunca alcanza esa profundidad en ninguno.

Se convierte en cuello de botella. Si todo pasa por un solo equipo, todo hace cola. El organismo que necesita un cambio menor espera seis meses porque hay tres proyectos más urgentes. El resultado predecible es que la gente empieza a construir por afuera, informalmente, y volvés a la fragmentación pero ahora también en las sombras.

Elimina el mecanismo de disciplina. Un proveedor malo se reemplaza. Un monopolio interno de desarrollo, no. Si el organismo central hace un producto mediocre, no hay alternativa ni presión para mejorarlo.

No escala con la demanda. El volumen de software que necesita un Estado es enorme y desigual en el tiempo. Un equipo central de tamaño fijo no absorbe picos.

Por qué (B) funciona

Porque centraliza exactamente aquello donde la repetición es pura pérdida, y deja distribuido aquello donde el contexto importa.

---

4. Las tres capas que sí conviene centralizar

Capa 1 — Estándares y design system

Un sistema de diseño gubernamental no es una paleta de colores. Es una biblioteca de componentes probados con usuarios reales, auditados en accesibilidad, con documentación de cuándo usar cada uno.

Lo que debería incluir en el caso argentino:

• Componentes de dominio local: input de CUIT/CUIL con validación y máscara, input de DNI, selector de jurisdicción, input de patente en ambos formatos, componente de domicilio con calle/altura/piso/depto según el estándar postal, selector de fecha que no asuma formato estadounidense.
• Patrones de formulario: una pregunta por pantalla para trámites complejos (patrón del GOV.UK Design System), guardado de progreso, manejo de errores con mensajes específicos y no genéricos, confirmación antes de acciones irreversibles.
• Tokens de diseño con contraste garantizado, tipografía legible en pantallas malas, tamaños de área táctil suficientes.
• Contenido: guía de lenguaje claro. Es de las intervenciones de mayor impacto y menor costo. Un formulario redactado en jerga administrativa genera errores de completado que después alguien tiene que corregir manualmente.

El design system se ofrece como paquete consumible (npm, componentes web framework-agnósticos) y se acompaña de kits para diseñadores. La clave es que sea más fácil usarlo que no usarlo. Si adoptarlo es un trámite, nadie lo adopta.

Capa 2 — Plataformas compartidas

Es la capa de mayor retorno económico y la que menos discusión genera.

• Identidad digital única: un solo login para todo el Estado, con niveles de aseguramiento diferenciados (no requiere lo mismo consultar el estado de un trámite que firmar una declaración jurada).
• Pasarela de pagos: una integración, no cuarenta.
• Notificaciones: correo, SMS, push, con trazabilidad de entrega, que es un requisito legal en trámites con efecto jurídico.
• Firma digital y validación de documentos.
• Capa de interoperabilidad tipo X-Road: el "once only" hecho realidad. Es probablemente la pieza de mayor impacto de todas.
• Almacenamiento de documentación con validación de tipo y tamaño, antivirus y OCR.
• API gateway con autenticación, rate limiting, logging y observabilidad estandarizados.

Cada una de estas piezas resuelta una vez ahorra decenas de implementaciones peores.

Capa 3 — Control de calidad con dientes

Es la capa que hace que las otras dos importen. Sin capacidad de exigir cumplimiento, un design system es una sugerencia.

Los mecanismos que funcionaron en otros lados:

• Estándar de servicio digital publicado, con criterios explícitos que todo servicio debe cumplir para salir a producción.
• Revisión obligatoria previa a publicación, con resultado público.
• Control de gasto: contrataciones de IT por encima de cierto monto requieren aprobación de la unidad central. Esta es la palanca del GDS y es la que más resistencia genera, por razones obvias.
• Métricas de servicio publicadas: tasa de finalización del trámite, tiempo promedio, tasa de error, volumen de consultas al canal presencial derivadas de fallas del canal digital. Publicar esto cambia el comportamiento de los equipos más que cualquier manual.

---

5. Sobre los criterios técnicos: qué medir y qué no confundir

La propuesta menciona Lighthouse, performance, accesibilidad y seguridad. Vale precisar cada uno, porque algunos son mejores criterios que otros.

Performance. Lighthouse y Core Web Vitals (LCP, INP, CLS) son buenos criterios de aceptación: son objetivos, automatizables en CI y se pueden exigir como condición de publicación. Un umbral razonable para servicios públicos es exigente, porque la población que más necesita el servicio digital suele tener los dispositivos más viejos y las conexiones peores. Testear en un gama baja con 3G no es pesimismo, es el caso de uso real.

Un matiz: el score de Lighthouse en laboratorio no equivale a la experiencia real. Conviene complementar con datos de campo (RUM), que muestran cómo se comporta el servicio en los dispositivos que efectivamente lo usan.

Accesibilidad. Acá hay que ser cuidadoso porque es donde más se confunde la métrica con el objetivo.

El score de accesibilidad de Lighthouse detecta aproximadamente entre un tercio y un 40% de los problemas reales. Encuentra bien contraste insuficiente, imágenes sin texto alternativo, labels faltantes, atributos ARIA mal formados. No detecta si el orden de foco tiene sentido, si un lector de pantalla puede completar el flujo de punta a punta, si los mensajes de error se anuncian, si la navegación por teclado permite salir de un modal, o si el lenguaje es comprensible.

El estándar correcto es WCAG 2.2 nivel AA, con auditoría manual y — esto es lo que más importa — testing con usuarios reales, incluidas personas con discapacidad. Ninguna herramienta automática sustituye a ver a alguien intentando completar el trámite con un lector de pantalla.

En Argentina hay además marco legal: la Ley 26.653 obliga a la accesibilidad web en sitios del Estado desde 2010. Existe. Se cumple parcialmente. Un organismo con capacidad de auditoría convertiría esa obligación en algo verificable.

Seguridad. Los criterios exigibles son bastante estándar: revisión de código, análisis estático y de dependencias en el pipeline, pruebas de penetración periódicas por terceros, gestión de secretos, cifrado en tránsito y en reposo, principio de mínimo privilegio, y un programa de divulgación responsable de vulnerabilidades — que es de las medidas más baratas y efectivas que existen, y que casi ningún Estado latinoamericano tiene formalizado.

Privacidad por diseño. Minimización de datos recolectados, plazos de retención definidos, y auditoría de accesos. Vale la pena hacerlo explícito porque es lo primero que se descarta bajo presión de plazos.

Código abierto por defecto. Con excepciones justificadas por seguridad. Tiene tres beneficios: escrutinio externo, reutilización entre organismos y jurisdicciones (una provincia puede tomar el componente en vez de contratar el suyo), y una forma de rendición de cuentas que sustituye parcialmente la disciplina que en el mercado ejerce la competencia.

---

6. Los modos de falla, que son bastante predecibles

Esta es la sección que más conviene tener presente, porque estos programas rara vez fracasan por incompetencia técnica.

Fuga de talento

Es el problema número uno y no tiene solución completa.

El sueldo estatal no compite con el privado, y en Argentina la brecha es especialmente brutal porque la alternativa no es solo el mercado local: es facturar en dólares a clientes del exterior desde tu casa. Un desarrollador senior argentino tiene opciones que un desarrollador senior británico no tenía en 2011.

Lo que funcionó parcialmente en otros lados: misión y propósito como factor de atracción real (funciona, pero se agota), contratos de plazo determinado bien remunerados para proyectos específicos, rotación deliberada con el sector privado, y — sobre todo — hacer que el trabajo sea técnicamente interesante y visible. Nadie se queda en el Estado por el sueldo; se queda si el problema es difícil y el impacto es grande.

El declive de GDS después de 2018 se explica en buena parte por esto: cuando la misión perdió épica y llegaron restricciones presupuestarias, la gente se fue.

Discontinuidad política

Una unidad digital necesita entre ocho y diez años para madurar: construir plataformas, ganar credibilidad, lograr adopción. Los ciclos políticos argentinos son de cuatro.

Cada cambio de gobierno trae reestructuración, cambio de mandato, cambio de prioridades y frecuentemente desarme del equipo. Es el riesgo argentino número uno y no tiene solución técnica. Las mitigaciones parciales son institucionales: crear la unidad por ley y no por decreto, presupuesto protegido, conducción técnica con mandato de duración fija que no coincida con el ciclo electoral, y — la más efectiva — construir plataformas de las que otros organismos dependan, porque lo que muchos usan es más difícil de desmantelar.

Captura por proveedores, con más pasos

Si la unidad central no tiene capacidad real de desarrollo interno, se convierte en una oficina de contrataciones sofisticada. Termina tercerizando lo mismo que venía a evitar, ahora con un intermediario adicional y una capa de burocracia extra.

El antídoto es tener masa crítica in-house genuina, aunque sea chica: un equipo que pueda construir, evaluar técnicamente lo que compra y mantener lo que recibe.

Concentración de riesgo

Un login único para todo el Estado es un objetivo de altísimo valor y un punto único de falla. Si cae, cae todo. Si se compromete, se compromete todo.

Es manejable con arquitectura adecuada, redundancia y segmentación, pero cambia el perfil de riesgo respecto de un ecosistema fragmentado. Vale reconocerlo en vez de tratarlo como detalle.

Cuello de botella y sombra

Si la unidad central se vuelve el único camino y es lenta, los organismos construyen por afuera sin decir nada. Se llega a lo peor de los dos mundos: la burocracia de la centralización más la fragmentación real, ahora invisible.

La prevención es de diseño de producto, no de gobernanza: hacer que las plataformas compartidas sean tan buenas y tan fáciles de integrar que usarlas sea el camino de menor resistencia.

Resistencia institucional

Quitar autonomía de contratación a un organismo es quitarle poder y presupuesto. La resistencia es garantizada y no es irracional desde la perspectiva del organismo. Cualquier plan que no incluya cómo gestionar esto políticamente es un plan incompleto.

---

7. El contraargumento serio

Vale ponerlo con su mejor forma, porque existe y no es trivial.

El mercado disciplina; el monopolio interno no. Un proveedor que entrega mal se reemplaza en la siguiente licitación. Un organismo estatal de desarrollo que entrega mal sigue siendo el único que puede entregar. No hay salida, no hay competencia, no hay presión.

El Estado es mal comprador y peor constructor de producto. Los incentivos internos premian cumplir el proceso, no que el usuario complete el trámite. Sin presión externa, la calidad tiende al mínimo que no genere escándalo.

Los costos de coordinación crecen no linealmente. Cuarenta organismos coordinando contra una plataforma común generan una carga de gestión que puede superar el ahorro de no duplicar el desarrollo.

Las respuestas habituales:

• Código abierto obligatorio y publicación de métricas de servicio: reemplaza parcialmente la disciplina competitiva por escrutinio público.
• Modelo mixto: la unidad central provee plataformas y estándares, pero los servicios verticales se construyen con proveedores privados que compiten, obligados a cumplir el estándar. Se conserva la competencia donde disciplina y se elimina la duplicación donde no aporta nada.
• Métricas públicas de cumplimiento por organismo, que generan comparación y presión reputacional.

Ninguna de estas respuestas es completa. El contraargumento sigue siendo válido en parte, y un post honesto debería decirlo.

---

8. Cómo se implementaría en Argentina

Un orden razonable, de mayor a menor retorno por unidad de esfuerzo:

Primero — interoperabilidad

Una capa tipo X-Road entre los sistemas que ya existen. No requiere reescribir nada; requiere que los sistemas actuales se hablen de manera estandarizada y auditada. Es la pieza de mayor impacto y la que habilita el principio de "once only".

Segundo — identidad digital consolidada

Sobre la base de lo que ya existe, con niveles de aseguramiento diferenciados y adopción obligatoria progresiva.

Tercero — design system y estándar de servicio

Publicados, con componentes consumibles y documentación seria. Adopción voluntaria al principio, obligatoria para desarrollos nuevos después de un plazo.

Cuarto — control de calidad y de gasto

Revisión obligatoria previa a publicación, y aprobación de contrataciones de IT por encima de un umbral. Es lo más resistido y lo que da poder real a todo lo anterior.

Quinto — plataformas compartidas restantes

Pagos, notificaciones, firma, almacenamiento.

Y transversalmente — capacidad interna

Un equipo chico y muy bueno vale más que uno grande y promedio. Con condiciones salariales excepcionales dentro del régimen público, contratos que permitan competir, y foco explícito en que el trabajo sea técnicamente interesante.

Lo que conviene no hacer:

• No intentar reescribir todo desde cero. Los grandes proyectos de reemplazo total fallan con regularidad estadística.
• No centralizar el desarrollo de servicios verticales.
• No crear la unidad sin palanca presupuestaria: sin eso es un blog de recomendaciones.
• No empezar por lo visible. La tentación política es rediseñar la home del portal; el valor está en la capa de interoperabilidad que nadie ve.

---

9. Lo que queda genuinamente en discusión

Cuánto desarrollo in-house versus contratado. Todo el espectro tiene defensores serios. El punto de equilibrio depende de la capacidad de atraer talento, que en Argentina es la restricción binding.

Si la unidad debe tener poder de veto presupuestario. Es lo que hizo funcionar a GDS y también lo que le generó los enemigos que contribuyeron a su declive.

Obligatoriedad versus adopción voluntaria del design system. Obligar garantiza cumplimiento formal y genera resentimiento; convencer es más lento y produce adopción genuina. La mayoría de las experiencias empezaron voluntarias y endurecieron después.

Alcance nacional versus federal. Un design system nacional que las provincias puedan adoptar libremente es más viable que uno impuesto, pero produce cobertura desigual. El federalismo argentino es una restricción real, la misma que aparece en tránsito, en peaje y en patentes.

Si el problema es de software o de proceso. Hay un argumento fuerte de que digitalizar un trámite mal diseñado produce un trámite malo más rápido. La rediscusión del proceso administrativo suele importar más que la interfaz, y es mucho más difícil.

---

Cierre

La intuición de centralizar es correcta en el diagnóstico y necesita precisión en la ejecución. El problema real — cuarenta organismos resolviendo mal el mismo login, sin interoperar, sin piso de calidad exigible — es caro y visible para cualquiera que use el Estado digital argentino.

Pero la centralización que funciona no es un organismo que programa todo. Es un organismo que provee las piezas comunes, define el estándar y tiene poder para exigir que se cumpla, mientras el conocimiento de dominio se queda donde vive.

Estonia no ganó por unificar el desarrollo. Ganó por unificar la conversación entre sistemas. Reino Unido no ganó por escribir el código de todos los ministerios. Ganó por publicar un estándar y tener la firma para bloquear el gasto de quien no lo cumplía.

Y la parte más difícil no es técnica. Un design system se construye en meses; una capa de interoperabilidad, en un par de años. Sostener el equipo y el mandato a través de tres cambios de gobierno es el problema que ningún país resolvió del todo, y el que en Argentina define si algo así sobrevive o queda como una buena idea más con un portal lindo y un equipo desarmado.