carrero.esIlustración generada con IA del Defensor del Pueblo y software público reutilizable en toda la administración
# Internet y sociedad

No es un buzón de 4 millones. Es el mismo software pagado diecisiete veces

Hace unos días me apareció en LinkedIn un post que se estaba compartiendo mucho: «4 millones de euros a Indra por el buzón de quejas del Defensor del Pueblo». Decía que un chaval recién salido de un ciclo de DAW te monta eso por 10.000 euros, y que era como pagar cinco millones por el buzón de correos de tu casa. Me hizo gracia, me indignó un poco y, sobre todo, me llamó la atención, despertando mi curiosidad. Así que hice lo que casi nadie hace con estos titulares: me descargué los pliegos. Todos.

Las claves en 30 segundos

  • El contrato del Defensor del Pueblo con Indra puede llegar a 4,4 millones de euros sin IVA hasta 2027, pero no es un buzón: el pliego tiene 295 requisitos y estima unas 71.000 horas de trabajo.
  • Por hora no sale caro. Lo caro es todo lo que se decidió comprar y los 529.400 euros al año que cuesta mantenerlo encendido.
  • El código es propiedad del Defensor del Pueblo, pero nadie más puede verlo, auditarlo ni reutilizarlo.
  • La justicia española funciona con nueve sistemas de gestión procesal distintos y la sanidad con diecisiete historias clínicas que dialogan mal entre sí.
  • Italia, Francia, Dinamarca, Estonia o Alemania ya han demostrado que un mismo software público puede instalarse muchas veces.

Lo que dicen los pliegos

El expediente es el 2021/C00009 y se licitó en febrero de 2021. El presupuesto base era de 3,22 millones de euros sin IVA, se presentaron ocho empresas y se adjudicó a Indra por 3.003.616 euros. La oferta más barata era de 2,8 millones y la más cara de 3,15. Todas en la misma franja.

Luego vinieron los cambios. En junio de 2023 un primer modificado amplió el plazo hasta septiembre de 2025 sin subir el precio. En julio de 2024 un segundo modificado añadió 336.569 euros más. Y el contrato prevé dos prórrogas de 529.400 euros cada una. Si se agotan, el total llega a 4.398.985 euros sin IVA, unos 5,3 millones con IVA, repartidos entre junio de 2021 y septiembre de 2027.

Hasta aquí, el titular de esa publicación es básicamente correcto. Lo que no cuenta es qué se compró.

No es un buzón

Portada del portal de quejas online del Defensor del Pueblo
El portal de quejas del Defensor del Pueblo. Lo visible es la parte pequeña del sistema.

El sistema que se quería sustituir se llama GEX. Lo desarrolló el propio Defensor del Pueblo en 2003 y 2004 en Java, con Oracle, un gestor de flujos de Tibco que ya no tiene soporte y el gestor documental Documentum. Guarda nueve millones de documentos, 2,7 terabytes, y lo usan a diario unas 170 personas. En 2025 la institución tramitó 38.762 expedientes.

El pliego técnico pide bastante más que un formulario. Los he contado (sí, con algo de ayuda de la IA): 295 requisitos. Hay atención al ciudadano por cualquier canal, registro electrónico con acuse sellado, espacio personal para seguir la queja, expedientes colectivos, reglas de asignación a las áreas, plantillas y escritos con código seguro de verificación, cita previa, campañas, boletines de email, escucha en redes sociales, un portal para ONG y parlamentarios autonómicos, integraciones con Cl@ve, @firma o el sistema de registros de las administraciones, y una aplicación móvil que funcione sin conexión para las visitas de inspección del Mecanismo Nacional de Prevención de la Tortura a cárceles y centros de internamiento.

Tabla del Anexo 7 del pliego con los primeros requisitos funcionales del sistema de quejas del Defensor del Pueblo
Primeras filas del Anexo 7 del pliego: 11 de los 295 requisitos que debían responder los licitadores. Fuente: Plataforma de Contratación del Sector Público.

Eso no lo hace un chaval en dos semanas. Y el contrato incluye además licencias, infraestructura, soporte y un año de mantenimiento.

El propio pliego estima el trabajo en 23,44 personas a tiempo completo durante 19 meses, más un equipo de mantenimiento. Unas 71.000 horas. Si divides lo presupuestado en servicios profesionales entre esas horas, sale a unos 32 euros la hora. Los salarios directos, a unos 25.

Indra no cobró caro por hora. Se compró muchísimo.

Donde de verdad está el dinero

Hay tres cosas en los documentos que me parecen bastante más relevantes que la cifra total.

La primera es el calendario. El plan del pliego era poner el sistema en producción a finales de 2022. A esas alturas ya se había facturado el 60 % del contrato. En mayo de 2023 fue la propia adjudicataria quien pidió el primer modificado por unas «innovaciones de índole técnico» y propuso «un nuevo planteamiento de plataforma técnica». En 2023 no se pagó nada. En julio de 2024, la resolución del segundo modificado describe el proyecto como «muy próximo a su puesta en producción». De 31 meses previstos a 76 posibles.

Gráfico con la cronología del contrato del Defensor del Pueblo con Indra: 31 meses previstos frente a hasta 76 posibles
Cronología del contrato 2021/C00009. Fuente: pliegos y resoluciones de los modificados 1 y 2.

La segunda es lo que cuesta tenerlo encendido. Las prórrogas ya no pagan desarrollo: solo licencias, infraestructura y servicio gestionado. 529.400 euros al año sin IVA. Con los expedientes de 2025, son unos 16,5 euros por expediente solo en plataforma.

La tercera es la que más me ha llamado la atención. El pliego obliga a usar productos concretos: el cuadro de mando «se implementa sobre Ms Power BI», la colaboración «a partir de Ms. Teams», la integración con Microsoft 365 y el acceso con el directorio activo de Microsoft. Cuando escribes el nombre del fabricante en el pliego, has decidido la mitad del proyecto antes de empezarlo.

Y el segundo modificado lo explica con una franqueza que no suele verse. Justifica no cambiar de empresa porque «el cambio de contratista no es posible por razones tanto económicas como técnicas»: un proveedor nuevo tendría que estudiar la aplicación y formarse. Es la definición exacta de dependencia de un proveedor, escrita en un documento oficial.

No hay nada ilegal en todo esto. El contrato pasó por licitación abierta y los modificados tienen informes favorables de la Asesoría Jurídica y de la Intervención. Mi crítica no va a las personas ni a la empresa. Va al modelo.

El código es nuestro, pero no lo podemos ver

Aquí está lo que de verdad me preocupa.

El pliego administrativo dice que el desarrollo lleva aparejada la cesión de la propiedad intelectual al Defensor del Pueblo. El técnico exige entregar el código fuente en su sistema de control de versiones. El código es público en el sentido de que lo hemos pagado todos y pertenece a una institución pública. Pero no lo puede ver nadie.

Nadie puede auditarlo. Nadie puede proponer una mejora ni avisar de un error. Y ninguna otra administración puede reutilizarlo, aunque la Ley 40/2015 obliga a ceder las aplicaciones a la administración que las pida, permite declararlas de fuentes abiertas y crea un directorio para compartirlas. Ese directorio, el Centro de Transferencia de Tecnología, tiene su forja pública en GitHub con unos cuarenta repositorios, casi todos de firma electrónica.

Y hay un matiz técnico importante. Si lo desarrollado vive dentro de una plataforma comercial licenciada, la cesión de la propiedad intelectual sirve de poco: puedes regalar tu código a otra institución, pero no podrá usarlo sin pagar las mismas licencias.

Mientras tanto, el Defensor del Pueblo de Navarra y el Gobierno foral firmaron en 2026 un convenio para desarrollar su propia plataforma de gestión de expedientes. Es el mismo problema, resuelto otra vez desde cero y con otro presupuesto.

Lo de poder auditar el código tampoco es teórico. El Tribunal Supremo reconoció en septiembre de 2025 el derecho de la Fundación Civio a acceder al código de BOSCO, la aplicación que decide quién recibe el bono social eléctrico. Ocho meses después seguían sin tenerlo.

¿Cuánto costaría hacerlo hoy?

En septiembre conté aquí cómo he vuelto a programar treinta años después gracias a Claude Code. Así que me he tomado el pliego en serio y lo he clasificado requisito a requisito: qué es el núcleo, qué es accesorio, qué solo puede hacerlo una administración y qué no es software sino servicio.

Mi estimación, con desarrollo asistido por agentes de IA y un perfil senior dirigiéndolo, está entre 2.000 y 4.000 horas para todo el código, frente a las 71.000 del pliego. Construirlo completo, con auditorías de seguridad y accesibilidad y la migración de datos, rondaría entre 200.000 y 400.000 euros. Y mantenerlo en una nube privada europea, con réplica entre dos centros de datos e incluso alguna copia de seguridad adicional en una tercera ubicación, entre 35.000 y 55.000 euros al año, frente a los 529.400 de la prórroga.

No son los 10.000 euros de esta publicación. Tampoco son cuatro millones.

Conviene ser honesto con lo que esa cifra no incluye. Integrarse con Cl@ve, @firma o el registro común solo puede hacerlo una administración. El Esquema Nacional de Seguridad se certifica sobre quien opera el sistema, no sobre el código. Y rediseñar los procesos con los tramitadores, que es la mitad del trabajo real en un proyecto público, no se acelera con ningún agente. Me gustaría intentar construir la primera parte y publicar las horas y el coste reales, no los estimados, aunque siendo realista no se si tendré tiempo para hacerlo.

Diecisiete veces el mismo problema

El caso del Defensor del Pueblo es pequeño. Lo interesante es lo que pasa cuando lo multiplicas.

La justicia española funciona con nueve sistemas de gestión procesal distintos. Minerva en los territorios del Ministerio, Adriano en Andalucía, Atlante en Canarias, Cicerone en la Comunidad Valenciana, el suyo propio en Madrid, en Cataluña, en el País Vasco… En 2020 el propio Ministerio planteaba el dilema en voz alta: interoperabilidad o integración en un único sistema. Se eligió la primera. En junio de 2022 se anunció que por fin los sistemas «hablaban» entre ellos. Es decir, se construyeron puentes entre nueve programas que hacen lo mismo.

Hay una excepción que merece conocerse. Avantius nació en Navarra y hoy lo comparten varias comunidades, entre ellas Navarra, Aragón y Cantabria. Ya se ha hecho aquí. Funciona.

Sanidad: diecisiete historias clínicas para un mismo paciente

En sanidad es todavía más evidente. Cada comunidad tiene su propio sistema de historia clínica, a veces uno para los centros de salud y otro distinto para los hospitales. Esta es la foto con la información pública que he podido reunir:

ComunidadAtención primariaHospitales
AndalucíaDirayaDiraya
AragónHistoria Clínica Única (sustituye a OMI-AP)Historia Clínica Única
AsturiasEstación clínica sobre OMI-APSistemas propios de cada hospital
Balearese-SIAPDiseñando un historial clínico único
CanariasDrago APDrago AE
CantabriaAP Cantabria (desde 2021)Integrado con los hospitales
Castilla-La ManchaTurrianoMambrino XXI
Castilla y LeónMedoraJimena
CataluñaECAPVarios sistemas, unidos por la HC3 compartida
Comunidad ValencianaAbucasisOrion Clinic
ExtremaduraJaraJara
GaliciaIANUSIANUS
La RiojaHistoria clínica electrónica regional (contrato prorrogado en 2026)La misma, fusionada entre hospitales
MadridAP-MadridVarios sistemas según el hospital
MurciaOMI-AP y Selene, unidos en una historia clínica común desde 2013Selene
NavarraAteneaSistemas propios
País VascoOsabideOsabide Global

Sistemas principales según fuentes públicas enlazadas al final. Dentro de cada comunidad puede haber variaciones por hospital y algunos están en plena sustitución.

Diecisiete comunidades y más de veinte programas distintos para hacer lo mismo: guardar la historia de un paciente, pedir una analítica, recetar y derivar al especialista. Cada uno con su contrato, su migración, su mantenimiento y su equipo. Solo el proyecto Jara de Extremadura arrancó en 2005 con 25,5 millones de euros en cuatro años. La Rioja acaba de prorrogar el suyo por 1,7 millones mientras prepara un contrato nuevo. Multiplica.

Y luego hay que hacer que hablen entre ellos. El proyecto de historia clínica digital del Sistema Nacional de Salud empezó en 2006. Quince años después seguía sin culminar, con comunidades que compartían solo el 11 % de los documentos pactados. Un estudio para la Comisión Europea calificó la interoperabilidad entre comunidades de «muy baja». Y en agosto de este año se seguía hablando de diecisiete sistemas que no dialogan eficientemente entre sí.

Hay un dato curioso escondido en esa tabla. En 2012, según un trabajo de la Universidad de Valladolid, nueve de las diecisiete comunidades usaban el mismo programa en atención primaria, OMI-AP. El mismo software instalado nueve veces ya existía. Lo que no existía era el código abierto, un presupuesto común ni una gobernanza compartida: nueve contratos con el mismo proveedor, nueve configuraciones distintas y nueve historias clínicas que seguían sin entenderse bien entre ellas.

Un núcleo común, diecisiete marcas

Ahora imagina lo contrario. Un único software de historia clínica, abierto, desarrollado una vez y desplegado diecisiete veces.

Cada comunidad lo usaría con su marca, sus colores, su nombre si quiere seguir llamándolo Diraya u Osabide, y su configuración: sus circuitos, sus catálogos de pruebas, sus centros. Pero por debajo sería el mismo programa, con el mismo modelo de datos y los mismos estándares, como FHIR para intercambiar información clínica. Un paciente de Ciudad Real atendido en Sevilla no necesitaría ningún puente: su historia se leería igual porque la escribió el mismo software.

Interoperable desde el primer día, no después de quince años de pasarelas.

Y con un único presupuesto de desarrollo. En lugar de diecisiete comunidades pagando diecisiete veces la receta electrónica, la integración con el laboratorio o la adaptación a la próxima norma europea, un consorcio con una cuota proporcional y una hoja de ruta común. Lo que cada comunidad quiera distinto, se lo paga como módulo propio, y si es útil, vuelve al núcleo para todos.

Y con el código en un repositorio público. Ahí está lo que más me ilusiona de la idea. Muchos profesionales podríamos aportar valor: abrir una incidencia cuando algo falla, proponer una mejora con un pull request, revisar el código de otros o auditar la seguridad por nuestra cuenta. Médicos que programan, enfermeras que detectan un flujo absurdo, ingenieros de hospital, universidades, empresas que dan soporte. Al final ese código lo hemos pagado todos con nuestros impuestos. Lo lógico es que todos podamos verlo, auditarlo y mejorarlo.

Los datos de los pacientes, evidentemente, no estarían en ningún repositorio. Se abre el programa, no la información.

Y lo mismo para todo lo demás

Lo mismo para los ayuntamientos, que son más de 8.000. Para las diputaciones. Para los gobiernos regionales. Para las defensorías autonómicas. Para el registro, los expedientes, las subvenciones, el padrón o la contabilidad. No hablo de las plataformas de participación ciudadana, que las hay libres y muy buenas. Hablo del corazón del software de la administración, el que tramita, registra y decide.

Cientos de ayuntamientos con el mismo software. Toda la sanidad con el mismo software. Todas las diputaciones con el mismo software.

Lo que cambia no es solo la factura. Cambia quién puede participar. Hoy un sistema así lo mantiene una empresa porque es la única que conoce el código. Con el código abierto, cualquier empresa puede ofrecer soporte, desarrollar una mejora o adaptarlo a un ayuntamiento concreto, incluida la pyme de informática de la capital de provincia que hoy no puede ni presentarse a estos concursos. Se compite por hacer mejor el trabajo, no por ser el dueño del código. Y habrá quien aporte sin que nadie le pague: universidades, funcionarios con ganas, desarrolladores que usan el servicio y ven un error. Pasa en todos los grandes proyectos de software libre.

Y con miles de ojos mirando el mismo código, auditar deja de ser un trámite que se encarga una vez y pasa a ser algo que ocurre todos los días.

Un matiz para no vender humo: un único sistema no significa un único proveedor ni un único centro de datos. Cada organismo lo opera donde quiera y con quien quiera. Lo que se comparte es el código, los estándares y la gobernanza. Sin gobernanza, un monocultivo también es un riesgo.

Ya se hace, y no es de ningún color

Lo mejor de todo esto es que no hay que inventar nada.

Italia lo tiene por ley. Los artículos 68 y 69 de su Código de la Administración Digital obligan a evaluar primero la reutilización y el software libre antes de comprar, y a publicar con licencia abierta el software encargado por la administración, en un catálogo común: Developers Italia. Y hizo algo todavía más ambicioso con el corazón del sistema: el 18 de enero de 2022 los 7.903 municipios italianos completaron su paso a un único padrón nacional, la ANPR, con 67 millones de residentes. Casi ocho mil padrones distintos convertidos en uno.

Francia lo resolvió en 2016 con la Loi pour une République numérique: el código fuente de la administración es un documento administrativo, se publica por defecto y se puede reutilizar.

Dinamarca es el ejemplo que más se parece a lo que propongo. En 2012 cinco ayuntamientos crearon OS2 para desarrollar juntos el software que todos necesitaban. Hoy son 82 municipios, el 84 % del país, con más de 400 instalaciones de productos compartidos y código abierto.

Estonia y Finlandia crearon en 2017 una fundación común, el NIIS, para mantener juntos X-Road, la capa de intercambio de datos sobre la que funciona buena parte de sus servicios públicos. Islandia se sumó después. Dos Estados compartiendo el corazón de su administración digital.

Alemania creó una agencia pública, ZenDiS, que publicó en 2024 openDesk, una alternativa abierta a Microsoft 365. Ya la usan el Ejército alemán, el Ministerio de Sanidad y la Corte Penal Internacional. Y el estado de Schleswig-Holstein está migrando 30.000 puestos de trabajo de Microsoft a software libre porque, según su jefe de la Cancillería, el software libre «debe convertirse en el estándar» de la administración.

Y la Unión Europea lo ha convertido en marco común. El Reglamento de Interoperabilidad Europea, aplicable desde julio de 2024, obliga a los organismos públicos a compartir sus soluciones de interoperabilidad, incluido el código fuente.

Gobiernos de izquierdas, de derechas, de coalición. Países grandes y pequeños. No es ideología. Es gestión.

Lo que pediría

No hace falta una revolución. Bastarían unas pocas reglas que otros ya aplican.

  1. Código abierto por defecto en todo desarrollo a medida pagado con dinero público, con excepciones motivadas y publicadas. Como en Italia o Francia. Y en un repositorio público de verdad, con incidencias y contribuciones abiertas, no en un ZIP que se entrega al final del contrato.
  2. Consulta obligatoria y real a lo que ya existe antes de licitar, y justificación pública si no se reutiliza.
  3. Pliegos sin marcas. Nada de «se implementa sobre» un producto concreto sin justificarlo, y el coste de salida incluido en la oferta.
  4. Coste total a cinco años como criterio de adjudicación: construir, licencias y operación. No solo lo que cuesta el primer año.
  5. Consorcios para lo común, como OS2: defensorías, ayuntamientos, justicia, sanidad.
  6. Hitos con penalizaciones en lugar de modificados que alargan plazos.

En abril escribí que la compra pública es la palanca más potente que tenemos y la estamos desperdiciando. Esto es exactamente eso, pero en pequeño y con nombres propios. No hace falta crear un campeón europeo para dejar de pagar diecisiete veces por lo mismo. Hace falta que el código que pagamos entre todos sea de todos.

La publicación de LinkedIn se equivocaba en el precio del buzón. Acertaba en lo que de verdad importa: que algo huele raro cuando nadie puede comprobar qué hemos comprado.

Preguntas frecuentes

¿Cuánto cuesta el sistema de quejas del Defensor del Pueblo?

El contrato se adjudicó a Indra en 2021 por 3.003.616 euros sin IVA. Con un modificado de 336.569 euros y dos prórrogas de 529.400 euros, el total puede llegar a 4.398.985 euros sin IVA (unos 5,3 millones con IVA) hasta septiembre de 2027.

¿Es solo un buzón de quejas?

No. El pliego incluye 295 requisitos: atención por todos los canales, registro electrónico, tramitación de expedientes, integración con servicios de la administración, cuadro de mando, migración de nueve millones de documentos y una aplicación móvil para las inspecciones del Mecanismo Nacional de Prevención de la Tortura.

¿El código es propiedad de la administración?

Sí. El pliego cede la propiedad intelectual al Defensor del Pueblo y exige entregar el código fuente. Pero no se ha publicado, así que no puede auditarse ni reutilizarse fuera de la institución.

¿Podrían todas las comunidades usar el mismo sistema de historia clínica?

Técnicamente, sí. Cada comunidad podría desplegar el mismo software abierto con su propia marca y configuración, compartiendo modelo de datos y estándares como FHIR. Así la interoperabilidad existiría desde el inicio y el desarrollo se pagaría una sola vez a través de un consorcio. El obstáculo es de gobernanza, no tecnológico.

¿Hay países que obliguen a publicar el software público?

Sí. Italia obliga a publicar con licencia abierta el software encargado por la administración, Francia considera el código fuente un documento administrativo desde 2016, y Dinamarca, Estonia, Finlandia y Alemania comparten software público entre administraciones.

Fuentes

en Internet y sociedad, Programación y software