Fujitsu convierte a Horizon en una prueba de prevención de transferencia de costes y rendición de cuentas

Resumen

• El rol de Fujitsu en Horizon debe entenderse como un caso de prevención de transferencia de costes: los resultados del software se trataron como evidencia de déficits en las sucursales, y esos resultados ayudaron a trasladar la carga financiera, legal y reputacional a los subdirectores de correos individuales.
• El registro público incluye la sentencia del caso Bates v Post Office Horizon Issues, el informe final volumen 1 de la Investigación del Horizon IT de Post Office, la declaración de Fujitsu de 2024, datos de compensación de GOV.UK, escrutinio parlamentario, lecciones de compensación de la NAO, y reportajes actuales sobre compensación y reemplazo.
• La pregunta de control no es simplemente si el software tenía errores. Es si Post Office, Fujitsu, el gobierno, los abogados, los auditores y los fiscales disponían de pruebas fiables suficientes antes de tratar los resultados del sistema como prueba contra las personas.
• La responsabilidad está distribuida. Fujitsu suministró y dio soporte a Horizon. Post Office lo operó, confió en él y litigó en torno a él. El gobierno era propietario y supervisó el entorno de políticas públicas. Los actores procesales y legales tenían deberes de divulgación. Los demandantes soportaron costes transferidos devastadores.
• La lección duradera es que no se debe permitir que los sistemas digitales conviertan la incertidumbre operativa en deuda personal, sospecha penal o compensación tardía, a menos que el estándar de la prueba sea explícito e impugnable de forma independiente.

La cuestión es la transferencia de costes, no solo el fallo del software

El escándalo de Horizon se describe a menudo con la frase "errores de software". Esa frase es precisa pero demasiado limitada. Los errores, fallos y defectos importaban porque los resultados de Horizon se utilizaban para identificar supuestos déficits en las sucursales y para respaldar demandas, acciones disciplinarias, procedimientos civiles y procesamientos. Por tanto, la cuestión de la responsabilidad no es solo si el software era defectuoso. Es si se permitió que resultados de software defectuosos o insuficientemente explicados transfirieran costes a personas que no podían ver ni impugnar el sistema subyacente.

La sentencia de 2019Bates v Post Office Horizon Issueses la fuente jurídica central para este artículo porque examinó en detalle la fiabilidad de Horizon, los errores, los defectos, el acceso remoto y las afirmaciones probatorias. ElInforme Final Volumen 1de la Investigación del Horizon IT de Post Office situó entonces el impacto humano del escándalo y el contexto de compensación en un registro público más amplio. Estos documentos muestran por qué una explicación de ingeniería limitada es inadecuada.

La transferencia de costes puede ocurrir silenciosamente. La cuenta de una sucursal muestra un déficit. Se le dice al operador que lo reponga. La institución trata el resultado del sistema como autoritativo. El individuo se enfrenta a presión, deuda, suspensión, procesamiento, quiebra, estigma o prisión. Si el sistema es incorrecto, incierto, alterable remotamente, mal divulgado o mal entendido, el error institucional se convierte en una carga personal. Esa es la clase de fallo.

El rol de Fujitsu pertenece a esa clase porque suministró y dio soporte al sistema cuyos resultados tenían peso probatorio. El rol de Post Office pertenece ahí porque operaba la relación con los subdirectores de correos y confiaba en los resultados. El rol del gobierno pertenece ahí porque la propiedad y supervisión públicas moldearon el entorno de rendición de cuentas. Los actores legales pertenecen ahí porque los deberes de divulgación y de prueba deciden si los acusados pueden impugnar las afirmaciones técnicas. Ningún actor único explica completamente el escándalo, pero cada actor tenía una superficie de control.

La pregunta de prevención es simple: antes de que un sistema digital traslade una pérdida a una persona, ¿qué pruebas se requieren? ¿Quién verifica el sistema? ¿Quién documenta los defectos? ¿Quién revela la incertidumbre? ¿Quién puede impugnar el resultado? ¿Quién paga cuando el resultado es incorrecto? Horizon importa porque esas preguntas se respondieron demasiado tarde.

El rol de proveedor de Fujitsu incluía obligaciones probatorias

Ladeclaración oficialde Fujitsu de 2024 se disculpó ante los subdirectores de correos y sus familias y reconoció la gravedad del asunto. Esa declaración es importante, pero la responsabilidad del proveedor no puede basarse solo en una disculpa. Un proveedor cuyo sistema se utiliza como evidencia en disputas y procesamientos tiene obligaciones en cuanto a registros de fiabilidad, divulgación de defectos, comunicaciones de soporte, pruebas periciales, transparencia del acceso remoto y pistas de auditoría.

El proveedor puede no decidir procesar. Puede no ser propietario de la relación con el cliente. Puede no establecer cada estrategia legal. Pero puede saber cosas sobre el sistema que otros no saben. Puede conocer el historial de defectos, los patrones de soporte, las capacidades de acceso remoto, los modos de error conocidos y los límites de diagnóstico. Cuando los resultados del sistema se tratan como evidencia, ese conocimiento se convierte en evidencia de interés público, no meramente en conocimiento interno del producto.

La guía de ingeniería de seguridad de sistemas del NIST,SP 800-160 volumen 1 revisión 1, no es específica para Horizon, pero ayuda a nombrar un principio general: los sistemas fiables requieren ingeniería, aseguramiento y evidencia del ciclo de vida. En el contexto de Horizon, la evidencia fiable no se refería solo a la resistencia a ciberataques. Se trataba de si se podía confiar en los resultados contables para acusar a un ser humano de deber dinero o de cometer irregularidades.

El paquete de evidencia del proveedor debería haber incluido respuestas claras. ¿Qué defectos se conocían? ¿Qué versiones se vieron afectadas? ¿Qué defectos podían crear o alterar déficits? ¿Qué sucursales se vieron afectadas? ¿Qué acceso remoto era posible? ¿Se podían insertar, alterar o corregir transacciones sin que el operador lo viera? ¿Qué pistas de auditoría existían? ¿Cuáles eran sus límites? ¿Qué afirmaciones periciales eran seguras de hacer? ¿Cuáles no?

Esas preguntas importan porque los subdirectores de correos no tenían igual acceso a los detalles internos de Horizon. Una persona acusada sobre la base de datos del sistema no puede verificar de forma independiente un sistema propietario sin divulgación. Por tanto, la opacidad del proveedor crea asimetría probatoria. Cuanto más grave es la consecuencia para el individuo, mayor es el deber del proveedor de hacer visible la incertidumbre.

La responsabilidad del proveedor también se extiende a la sustitución y la transición. El reportaje de Computer Weekly de 2026 sobre laexclusión de Fujitsu de importantes acuerdos de sustitución de Horizonmuestra que las consecuencias de la contratación continuaron en el registro público actual. Sin embargo, la sustitución no es lo mismo que la reparación. Un nuevo camino de proveedor no responde por sí mismo a lo que les sucedió a las personas perjudicadas por el antiguo sistema probatorio.

La evidencia de software necesita visibilidad contradictoria

El expediente Horizon revela una regla general para la evidencia de software: si un resultado del sistema se utiliza contra una persona, esta debe poder impugnar la fiabilidad del sistema, la ruta de los datos y las explicaciones alternativas. Esa impugnación no puede ser significativa si la institución controla todo el conocimiento técnico y trata el resultado como presuntamente cierto.

La página pública del Servicio de Fiscalía de la Corona sobredivulgaciónes una fuente general, no un hallazgo específico de Horizon. Es relevante porque los procesos penales dependen de la divulgación de material que pueda socavar el caso de la acusación o ayudar a la defensa. En un caso de evidencia de software, los registros de defectos, los tickets de soporte, los errores conocidos, los registros de acceso remoto, las limitaciones de auditoría y la incertidumbre pericial pueden ser material de divulgación. Si esos registros no se identifican y comparten, el acusado no puede poner a prueba la evidencia.

El comentario del Colegio de Abogados sobreBates contra Post Officeayuda a enmarcar por qué el litigio se convirtió en un hito. Pero el punto más profundo va más allá de un caso. Los sistemas digitales generan ahora evidencia en prestaciones, banca, empleo, impuestos, sanidad, comercio minorista, policía y gobernanza de plataformas. La lección de Horizon es que la evidencia del sistema no debe tratarse como neutral solo por ser digital.

La visibilidad contradictoria requiere varios controles. Primero, un registro de defectos lo suficientemente completo como para mostrar los modos de error conocidos. Segundo, pistas de auditoría que identifiquen acciones humanas, automatizadas y remotas. Tercero, pruebas periciales que indiquen los límites, no solo la confianza. Cuarto, preservación de los registros del sistema antes del litigio. Quinto, revisión independiente cuando la misma institución que se beneficia del resultado controla la evidencia. Sexto, una regla de carga de la prueba que no se desplace silenciosamente hacia el individuo.

El marco de la transferencia de costes ayuda a aclarar lo que está en juego. Si el déficit de una sucursal es real y atribuible a un operador, la institución puede tener una reclamación. Si el déficit se debe a un defecto del sistema, una corrección remota, un error de sincronización o un proceso contable inexplicado, la institución no debería transferir el coste. El estándar de la prueba decide qué camino se toma.

Horizon muestra lo que sucede cuando la confianza institucional supera la humildad probatoria. Un sistema puede ser operativo en general y aun así producir resultados controvertidos en casos particulares. Un proveedor puede corregir defectos y aun así dejar en entredicho los resultados pasados. Un tribunal puede recibir pruebas periciales y aun así considerar que las suposiciones previas no eran seguras. La evidencia de software necesita un canal para esas incertidumbres antes de que se dañen vidas.

La compensación es prueba de una rendición de cuentas retrasada

Los regímenes de compensación a veces se tratan como una fase administrativa separada tras el escándalo. En el caso Horizon, la compensación es parte de la evidencia de rendición de cuentas. La escala, complejidad, retraso, costes legales y carga para los demandantes de la reparación revelan lo difícil que es reparar una transferencia de costes una vez que las instituciones han tratado los resultados del sistema como autoritativos durante años.

Losdatos actuales de reparación financiera y costes legales de Post Office Horizon para 2026de GOV.UK convierten la compensación en un registro público vivo. El informe de la Biblioteca de la Cámara de los Lores sobre elprogreso de la compensaciónresume los regímenes y el contexto político continuo. El informe de la Oficina Nacional de Auditoría sobre laslecciones aprendidas de los regímenes de compensación gubernamentaleses relevante porque la propia administración de la compensación puede reproducir el daño si es lenta, compleja o genera desconfianza.

La reparación tardía es otra forma de transferencia de costes. Las personas que fueron acusadas injustamente o presionadas pueden esperar años para una reparación financiera mientras cargan con las consecuencias de la quiebra, costes legales, daños a la salud, pérdidas familiares, estigma reputacional y oportunidades de negocio perdidas. La compensación no puede restaurar completamente esas pérdidas, pero el retraso empeora la brecha. Cuanto más tardan las instituciones en reparar, más sigue el individuo financiando el fracaso de la institución.

El reportaje de The Guardian de 2026 sobre losplazos de los regímenes de compensaciónmuestra que la presión por la reparación seguía siendo un problema actual. Esa actualidad importa. Horizon no es solo un fallo tecnológico histórico. A fecha de 2026, la compensación, la rendición de cuentas, la sustitución y el aprendizaje institucional siguen formando parte del registro público.

Por tanto, los sistemas de compensación deberían juzgarse por su facilidad de uso para los demandantes. ¿Están claras las normas de elegibilidad? ¿Es justa la carga de la prueba? ¿Hay pagos provisionales disponibles? ¿Se cubren los costes legales? ¿Se apoya a los demandantes traumatizados? ¿Se atiende a las familias de los demandantes fallecidos? ¿Son puntuales las decisiones? ¿Son accesibles las apelaciones? ¿Se publican estadísticas? ¿Aprenden los diseñadores de los regímenes de los demandantes? Estas preguntas no son sutilezas administrativas. Deciden si el Estado y las instituciones dejan de transferir costes a las víctimas.

La lección de prevención es aún más contundente. Si la reparación es tan difícil, el umbral probatorio antes de la transferencia de costes original debería haber sido más alto. Es mucho más barato y más justo prevenir acusaciones inseguras que compensar después de un daño injusto.

El escrutinio público debía mantenerse actualizado

El registro público de Horizon sigue evolucionando. La Comisión de Empresa y Comercio del Parlamento del Reino Unido programó unasesión de pruebas oralesen 2026 relacionada con la justicia y la rendición de cuentas de Horizon. La explicación del Parlamento de 2024 sobre lajusticia para los subdirectores de correosmuestra cómo el escándalo se convirtió en una preocupación institucional nacional. El escrutinio público importa porque los sistemas complejos de rendición de cuentas pueden desviarse cuando la atención se desvanece.

El escrutinio actual debería centrarse en la prevención, no solo en la culpa. ¿Qué impedirá que otro sistema genere deudas personales o sospechas penales sin una impugnación adecuada? ¿Cómo divulgarán los proveedores los defectos? ¿Cómo mantendrán los organismos públicos conocimientos técnicos independientes? ¿Cómo manejarán los fiscales las pruebas de software propietario? ¿Cómo evitarán los regímenes de compensación volver a traumatizar a los demandantes? ¿Cómo evitarán los sistemas de sustitución heredar los mismos supuestos probatorios?

El reportaje de Computer Weekly de 2025 sobre la reacción de la dirección de Fujitsu al informe de la investigación y los vínculos conel impacto humano de Horizoncapta la continua tensión de rendición de cuentas en torno a la respuesta institucional. Los reportajes secundarios no deben reemplazar las conclusiones de la investigación, pero ayudan a mostrar que la rendición de cuentas depende no solo de los documentos formales, sino también de cómo las organizaciones interiorizan esos documentos.

El escrutinio público también debe abarcar la propiedad gubernamental. La posición de Post Office y su rol en las políticas públicas significan que esto no fue solo una disputa privada entre proveedor y cliente. El gobierno tenía deberes de supervisión, deberes de financiación, deberes de compensación y credibilidad institucional en juego. Si una red de servicios públicos depende de sistemas de evidencia propietarios, el gobierno debe asegurarse de que puede entenderlos e impugnarlos. Externalizar la operación técnica no puede significar externalizar la rendición de cuentas pública.

La misma regla se aplica más allá de Horizon. Los sistemas de prestaciones, los sistemas fiscales, los sistemas de inmigración, los sistemas de salud, los sistemas judiciales y los mercados regulados dependen cada vez más de los resultados del software. Si esos resultados mueven dinero, estatus, libertad o reputación, las instituciones públicas necesitan alfabetización técnica y normas de divulgación antes de que se produzca el daño.

El acceso remoto debería haber sido una cuestión probatoria de primer orden

El acceso remoto es uno de los conceptos técnicos más importantes en el expediente Horizon porque afecta a quién podía alterar, corregir o influir en los datos de las sucursales y a lo que el operador de la sucursal podía saber razonablemente. Si un actor central puede acceder o cambiar los registros, la historia probatoria no es simplemente "el sistema de la sucursal registró un déficit". La historia debe incluir quién más podía tocar los datos, cuándo, bajo qué controles y con qué pista de auditoría.

Elsitio weboficial de la Investigación del Horizon IT de Post Office es valioso porque ofrece al público una vía de acceso a un largo expediente probatorio. La sentencia Bates sigue siendo la fuente más directa para el análisis del acceso remoto y de los errores/defectos utilizado aquí, pero el expediente de la investigación demuestra por qué las capacidades técnicas debían considerarse junto con la gobernanza, la cultura, el proceso legal y la compensación.

El acceso remoto no significa automáticamente irregularidad. Muchos sistemas necesitan acceso de soporte para reparar fallos, mantener el servicio y ayudar a los usuarios. El problema de rendición de cuentas aparece cuando el acceso remoto existe pero se niega, se malinterpreta, se divulga mal, se registra débilmente o se trata como irrelevante para las acusaciones contra los usuarios. En una disputa contable, la posibilidad de alteración remota no es una cuestión secundaria. Es una explicación alternativa que puede cambiar la carga, la evidencia y la equidad.

La regla de prevención debería ser explícita. Si una institución se basa en el resultado de un sistema para acusar a un usuario, debe revelar si el acceso remoto podría afectar a los datos relevantes. Debe preservar los registros que muestren las acciones remotas. Debe explicar quién tenía acceso, qué controles lo regían y si se produjo alguna acción remota en el período relevante. Si los registros están incompletos, la incertidumbre debería contar en contra de la confianza institucional, no en contra del individuo acusado.

Esta regla es especialmente importante en los sistemas distribuidos de servicio público. Los operadores de sucursales, los agentes locales, los franquiciados, los contratistas y las pequeñas empresas a menudo operan en el borde de una plataforma central. La institución central tiene poder técnico. El operador local tiene una responsabilidad de cara al público. Cuando los registros no coinciden, no se debería permitir que la institución central asuma que el operador periférico causó la discrepancia sin abrir el sistema central a impugnación.

Por tanto, la transparencia del acceso remoto debería integrarse en el diseño del sistema. El usuario debería recibir avisos o registros de las acciones de soporte cuando corresponda. Las pistas de auditoría deberían ser resistentes a la manipulación. Los testigos periciales deberían entender y revelar las capacidades remotas. Los contratos deberían indicar cómo afecta el acceso de soporte a la evidencia. Los tribunales y los reguladores deberían preguntar al respecto antes de aceptar el resultado del sistema como decisivo.

La prueba pericial debe incluir límites, no solo conclusiones

Horizon también muestra por qué la prueba pericial sobre sistemas de software debe incluir límites. Un perito puede decir que un sistema funcionaba en general. Esa afirmación puede ser cierta y aun así no probar que un déficit concreto fue causado por una persona concreta. Los sistemas de software pueden ser generalmente fiables y fallar en condiciones particulares. Pueden procesar millones de transacciones y aun así producir errores que importan profundamente para un acusado.

Por tanto, la prueba pericial debería ser específica para la acusación. ¿Qué sucursal? ¿Qué fechas? ¿Qué versión de software? ¿Qué historial de defectos? ¿Qué tickets de soporte? ¿Qué acciones remotas? ¿Qué proceso de conciliación? ¿Qué migraciones de datos? ¿Qué errores conocidos? ¿Qué pistas de auditoría? ¿Qué explicaciones alternativas? Una afirmación general de fiabilidad no puede sustituir a un análisis específico del caso.

Lasentencia de 2024 del Tribunal Supremo del Reino Unido en un contexto legal/de compensación relacionado con Post Officeno es una sentencia técnica sobre Horizon y no debería estirarse como tal. Pertenece aquí solo como recordatorio de que las secuelas legales continuaron a través de múltiples vías procesales. El principio más importante es general: los sistemas legales necesitan pruebas técnicas que sean lo suficientemente precisas para ser contrastadas.

Los peritos también deberían revelar la incertidumbre en lenguaje corriente. Si un defecto pudiera crear una discrepancia, dígalo. Si el perito no puede descartar una acción remota porque faltan registros, dígalo. Si la arquitectura del sistema crea límites a lo que se puede inferir, dígalo. Los tribunales y los acusados pueden manejar mejor la incertidumbre que el exceso de confianza que luego se derrumba.

Los empleados de proveedores que testifican se enfrentan a un riesgo particular. Pueden conocer el sistema en profundidad, pero su empleador puede tener intereses comerciales, reputacionales o contractuales. Eso no hace que su testimonio sea falso. Significa que los tribunales y las instituciones deberían exigir independencia, revelación de conflictos, acceso a registros completos de defectos y una clara separación entre el análisis técnico y la defensa institucional.

El control de prevención es una lista de verificación de pruebas periciales para las acusaciones generadas por software. Fiabilidad general, historial de defectos relevante, capacidad de acceso remoto, prueba del linaje de los datos, integridad de los registros de auditoría, comportamiento específico de la versión, contexto de los tickets de soporte e incertidumbre residual. Si no se puede completar la lista de verificación, la institución no debería tratar el resultado del software como prueba decisiva contra el individuo.

La sustitución no borra la deuda probatoria

Sustituir Horizon o excluir a Fujitsu de futuras contrataciones puede ser necesario, pero la sustitución no borra la deuda probatoria. Hubo personas perjudicadas bajo el antiguo sistema. Las condenas, los reembolsos, las quiebras, los negocios perdidos, los traumas familiares y el daño reputacional no pueden repararse diciendo que un nuevo sistema será mejor. El antiguo expediente probatorio debe seguir siendo auditado, explicado y compensado.

La sustitución puede incluso crear un riesgo de cierre prematuro. Las organizaciones pueden preferir hablar de transformación, modernización, nuevos proveedores y resiliencia futura porque esos temas parecen constructivos. Las víctimas y los demandantes pueden seguir esperando una reparación. El sistema que produjo el daño puede ser desmantelado mientras las consecuencias siguen vivas. La rendición de cuentas debe tener en cuenta ambos horizontes temporales: la sustitución futura del sistema y la reparación del daño pasado.

La transición del proveedor debería incluir la preservación del conocimiento. Los historiales de defectos, los tickets de soporte, los informes periciales, los diccionarios de datos, los registros de transacciones, los registros de acceso remoto y los materiales de auditoría no deberían desaparecer durante la sustitución. Si futuros demandantes o investigadores necesitan entender el comportamiento de Horizon, esos registros deben permanecer disponibles. Un sistema desmantelado puede seguir siendo una prueba.

La sustitución también debería preguntarse si el nuevo sistema cambia la regla de transferencia de costes. ¿Recibirán los operadores de las sucursales registros de auditoría más claros? ¿Serán visibles las acciones de soporte remoto? ¿Tendrán las impugnaciones de discrepancias una vía independiente? ¿Se comunicarán los avisos de defectos a los usuarios afectados? ¿Se basarán alguna vez los procesamientos o las reclamaciones civiles en los resultados del sistema sin impugnación técnica? Una nueva interfaz sin nuevas reglas probatorias no es suficiente.

La contratación pública debería incorporar estas lecciones. A los proveedores que liciten para sistemas que generen pruebas contra individuos se les debería exigir que proporcionen mecanismos de divulgación de defectos, pistas de auditoría, registros de soporte visibles para el usuario, protocolos de pruebas periciales, derechos de revisión independiente y compromisos de preservación de datos. La prueba de contratación no solo debería preguntar si el sistema funciona; debería preguntar si el sistema puede ser impugnado de manera justa.

La historia de la sustitución de Horizon es, por tanto, parte de la prevención, no solo de las operaciones. Un organismo público que compra un nuevo sistema sin incorporar derechos de impugnación ha aprendido muy poco.

La carga para los demandantes forma parte del daño institucional

El proceso de reparación no debería obligar a los demandantes a demostrar de nuevo lo que el escándalo ya demostró estructuralmente: que la dependencia institucional de Horizon causó una grave injusticia. Las reclamaciones individuales siempre requerirán pruebas, pero el diseño de esa carga probatoria importa. Si los demandantes se ven obligados a reconstruir pérdidas de décadas de antigüedad con documentos que la institución debería haber conservado, el coste se traslada de nuevo a la persona perjudicada.

Los regímenes de compensación deberían comenzar con un diseño que tenga en cuenta el trauma. Algunos demandantes pueden desconfiar de Post Office, del gobierno, de los abogados o de los proveedores porque esas instituciones les fallaron anteriormente. Algunos pueden carecer de registros porque los negocios quebraron, las familias se mudaron, la salud se deterioró o pasaron años. Algunos pueden haber fallecido, dejando a las familias navegar por el proceso. El régimen debería reducir la fricción cuando la institución ya conoce el contexto amplio del fallo.

El retraso administrativo no es neutral. Cada mes de retraso puede significar una tensión financiera continua, patrimonios sin resolver, incertidumbre jurídica, estrés y frustración pública. Por tanto, las estadísticas de reparación deberían informar no solo de los pagos totales, sino también de los tiempos de espera, los casos pendientes, los motivos del retraso, los resultados de las apelaciones, el apoyo a los demandantes y la carga de los costes legales. La transparencia convierte el retraso en un hecho gobernable.

Las lecciones de la NAO sobre los regímenes de compensación importan porque la reparación es un sistema de prestación. Un régimen mal diseñado puede recrear el desequilibrio institucional incluso con la intención de reparar. Los formularios complejos, las reglas probatorias restrictivas, las ofertas inconsistentes y la comunicación lenta pueden convertirse en un daño secundario. La misma humildad probatoria requerida antes del procesamiento debería aparecer en la compensación.

La responsabilidad de Fujitsu se cruza con la carga de los demandantes incluso cuando el gobierno y Post Office administran los regímenes. Si las pruebas del proveedor contribuyeron a la transferencia de costes original, la cooperación del proveedor debería ayudar a reducir la carga del demandante ahora. Los registros técnicos, los historiales de defectos y las explicaciones del sistema deberían estar disponibles para la reparación cuando sean relevantes. El demandante no debería tener que redescubrir un sistema que el proveedor construyó.

La prueba moral es si la reparación invierte la dirección de la carga. Durante el escándalo, se obligó a los individuos a cargar con la certeza institucional. Durante la compensación, las instituciones deberían cargar con el peso de la reparación. Cualquier cosa menos deja intacta la lógica de la transferencia de costes.

Una regla de prevención debería aplicarse más allá de Post Office

La lección de Horizon debería redactarse como una regla institucional general: ningún resultado de un sistema automatizado, semiautomatizado o propietario debería utilizarse para imponer deudas, medidas disciplinarias, procesamientos, exclusiones o daños reputacionales graves a menos que la persona afectada pueda impugnar el sistema de manera significativa. Esa regla pertenece a la administración pública, a los servicios regulados y a las plataformas privadas donde la evidencia del sistema rige los resultados humanos.

La impugnación significativa tiene elementos mínimos. La persona debe conocer los datos utilizados. Debe conocer la versión del sistema y las reglas pertinentes. Debe tener acceso a la información sobre defectos que pueda afectar al caso. Se le debe informar si seres humanos o sistemas remotos podían alterar el registro. Debe poder obtener registros o una revisión técnica independiente. No se le debe obligar a demostrar que un sistema oculto es incorrecto sin acceso al sistema.

Este principio no es antitecnológico. Los sistemas fiables pueden proteger a las personas, detectar fraudes, reducir errores y mejorar el servicio. La cuestión es que el poder institucional crece cuando los sistemas se convierten en evidencia. Ese poder necesita salvaguardias procesales. Horizon fracasó no porque se utilizara la tecnología, sino porque la tecnología se trató como más autoritativa de lo que la evidencia justificaba y se dejó a las personas fuera del circuito de la prueba.

Por tanto, los consejos de administración deberían hacer una pregunta sencilla sobre cualquier sistema de alto riesgo: ¿puede una persona impugnar este resultado de manera justa? Si la respuesta es no, el sistema no debería utilizarse para transferencias de costes de alto riesgo. Si la respuesta es sí, el consejo debería pedir pruebas: pistas de auditoría, divulgación de defectos, vías de apelación, revisión independiente, avisos a los usuarios y normas de conservación.

Los proveedores deberían acoger esta regla si quieren mercados fiables. Un sistema que puede ser impugnado de manera justa es más duradero que uno defendido mediante la opacidad. Los derechos de impugnación exponen los defectos antes, reducen los litigios catastróficos y hacen que los clientes sean menos propensos a tratar al proveedor como un adversario oculto. El software fiable no es aquel que nadie puede cuestionar. Es aquel que sobrevive al cuestionamiento.

La lección pública más amplia es que la evidencia digital se está volviendo habitual. Esa habitualidad hace que Horizon sea más, no menos, importante. El próximo escándalo de transferencia de costes puede surgir del software de prestaciones, la analítica fiscal, la automatización de nóminas, la policía predictiva, la facturación hospitalaria, la moderación de plataformas o la medición de energía. La regla de prevención debería estar vigente antes de que al próximo grupo de individuos se le diga que el sistema tiene que estar en lo cierto.

Las pistas de auditoría deberían diseñarse para la persona acusada

Muchos sistemas de auditoría están diseñados para administradores, proveedores o equipos internos de aseguramiento. Horizon muestra por qué las pistas de auditoría de alto riesgo también deberían diseñarse para la persona afectada por el resultado. Si un sistema dice que a una sucursal le falta dinero, el operador de la sucursal debería poder ver lo suficiente de la ruta de la transacción, la ruta de corrección, la ruta de soporte y la ruta de excepción como para entender la acusación. Una pista de auditoría que solo la institución puede interpretar es una protección débil.

La auditoría orientada a la persona no significa exponer todos los detalles sensibles del sistema. Significa dar a la persona afectada un registro coherente: las transacciones en cuestión, las marcas de tiempo, los pasos de conciliación, cualquier cambio iniciado centralmente, los incidentes conocidos que afecten a la sucursal o al período, los defectos relevantes y una vía para solicitar una revisión independiente. El registro debería ser exportable y duradero. No debería depender de la discreción de un gerente local.

Las pistas de auditoría también deberían mostrar la ausencia cuando la ausencia importa. Si no se produjo ningún acceso remoto, el sistema debería poder mostrarlo. Si se produjo un acceso remoto pero no afectó a los datos en disputa, el sistema debería mostrar el límite. Si los registros están incompletos, el expediente debería decirlo. El silencio no debería interpretarse automáticamente en contra del individuo.

La regla de diseño es que la auditoría debe seguir a la consecuencia. Cuanto más grave sea la posible consecuencia, más transparente y revisable de forma independiente debe ser la pista de auditoría. Una pequeña excepción de conciliación interna puede necesitar un nivel de evidencia. Una exigencia de que un individuo devuelva miles de libras, pierda su medio de vida o se enfrente a sospechas penales requiere mucho más.

Esta regla también mejoraría los incentivos de los proveedores. Si las pistas de auditoría deben ser utilizables por las personas acusadas, los proveedores tienen que construir sistemas que se expliquen por sí mismos. Eso puede añadir coste, pero evita un coste social mucho mayor. Los sistemas que no pueden generar pistas de auditoría justas no deberían utilizarse para imponer responsabilidades personales de alto riesgo.

La recuperación civil y el procesamiento no deben compartir supuestos inseguros

Horizon también advierte contra la posibilidad de que la recuperación civil y el procesamiento se refuercen mutuamente a través del mismo supuesto no probado. Si el resultado de un sistema se trata como fiable en una demanda civil, esa confianza puede trasladarse a medidas disciplinarias o sospechas penales. Si un procesamiento trata los registros del sistema como autoritativos, esa postura puede reforzar la recuperación civil. La misma premisa técnica débil puede viajar a través de diferentes vías legales.

El control de prevención consiste en exigir una revisión técnica independiente antes de la escalada. Un déficit impugnado no debería pasar de una consulta contable a una demanda de deuda y a un procesamiento sin preguntarse si un defecto del sistema, una acción remota, una intervención de soporte o un error de conciliación es una explicación plausible. Cada escalada debería requerir una base probatoria más sólida que la anterior.

La recuperación civil también debería incluir comprobaciones de equidad. ¿Tenía el operador acceso a los registros necesarios para impugnar el déficit? ¿Se informó al operador de los defectos conocidos? ¿Se investigaron las explicaciones alternativas? ¿Se revisaron las correcciones iniciadas centralmente? ¿Se basó la cantidad exigida en pérdidas verificadas en lugar de en la confianza del sistema? Estas comprobaciones deberían realizarse antes de que se aplique presión, no después de que comience el litigio.

El procesamiento eleva aún más el umbral. Están en juego la libertad, la reputación y los antecedentes penales. La divulgación debe ser proactiva. La prueba pericial debe ser cautelosa. No se debería permitir que la institución que presenta o apoya el caso se escude en la complejidad del sistema propietario. Si el sistema es demasiado complejo para ser divulgado y probado, es demasiado complejo para ser utilizado como prueba penal decisiva.

La misma idea se aplica a las medidas disciplinarias internas y a la rescisión de contratos. Un subdirector de correos o un contratista puede arruinarse incluso sin una condena si la institución rescinde una relación, retiene el pago o hace pública una sospecha basada en datos poco fiables del sistema. Las decisiones administrativas de alto riesgo necesitan su propio proceso de impugnación técnica.

Horizon se volvió catastrófico en parte porque diferentes canales de rendición de cuentas repitieron la misma confianza. Los sistemas futuros deberían hacer lo contrario: cada escalada debería reabrir la cuestión técnica con un escrutinio más riguroso.

La custodia de la evidencia debe sobrevivir a los cambios de liderazgo

Los escándalos prolongados sobreviven a ejecutivos, ministros, gerentes de proveedores, abogados y equipos de TI. Por tanto, la custodia de la evidencia debe sobrevivir a los cambios de liderazgo. Los registros de defectos, los tickets de soporte, los registros de auditoría, los documentos del consejo, los informes periciales y las comunicaciones con los demandantes deben conservarse bajo un plan de retención legal y ético, no dejarse a la costumbre departamental.

Esto importa porque la rendición de cuentas retrasada a menudo depende de registros antiguos. Un demandante puede necesitar pruebas años después. Un tribunal puede revisar una condena. Una investigación puede preguntar quién sabía qué y cuándo. Un programa de sustitución puede necesitar saber qué defectos perjudicaron a los usuarios. Si los registros desaparecen, el retraso beneficia de nuevo a la institución que controlaba la evidencia.

Los contratos con los proveedores deberían incluir deberes de evidencia posteriores a la terminación. Cuando se sustituye a un proveedor, este debería seguir conservando y proporcionando los registros pertinentes para reclamaciones, investigaciones y revisiones legales. Los organismos públicos no deberían perder el acceso a la evidencia porque finalice una relación comercial. Tampoco deberían poder los proveedores considerar irrelevante el conocimiento histórico de los defectos una vez que el contrato sigue adelante.

La custodia de la evidencia también requiere metadatos: quién creó el registro, cuándo, a qué versión del sistema se refiere, a qué sucursal o demandante afecta y si ha sido revisado. Un montón de documentos no es lo mismo que evidencia utilizable. Las personas perjudicadas por Horizon necesitaban evidencia utilizable, no archivos institucionales que solo los iniciados podían descodificar.

Por eso la prevención y la reparación se encuentran en el diseño de los registros. Un sistema que registra bien los defectos puede prevenir acusaciones inseguras. Si la prevención falla, los mismos registros pueden respaldar una compensación más rápida. Los registros deficientes fallan dos veces: primero cuando se produce el daño, y de nuevo cuando se retrasa la reparación.

La rendición de cuentas debería integrarse en el próximo sistema

La última lección de Fujitsu es que la rendición de cuentas no puede añadirse a posteriori a un sistema de sustitución cuando regrese la ira pública. Los derechos de impugnación, la visibilidad de la auditoría, la divulgación de defectos, los registros de acceso remoto, los estándares de pruebas periciales y la preservación de la evidencia de compensación deberían ser requisitos de diseño desde el principio. Una nueva plataforma que repita la antigua asimetría probatoria modernizaría la interfaz pero conservaría el riesgo de transferencia de costes.

La prueba de rendición de cuentas es la prevención antes que la reparación

La pregunta responsable después de Horizon no es solo cuánta reparación se paga o qué ejecutivos se disculpan. Es si las instituciones tienen ahora una regla de prevención: no utilizar un sistema digital para transferir costes, sospechas o cargas legales a individuos a menos que la fiabilidad del sistema, sus defectos, sus vías de acceso y sus limitaciones de auditoría puedan ser impugnadas de forma independiente.

El registro público no reduce la responsabilidad a Fujitsu en solitario. Post Office, el gobierno, los abogados, los auditores, los fiscales y los administradores de compensaciones tuvieron o tienen funciones. El papel de Fujitsu sigue siendo importante porque los proveedores pueden poseer conocimientos técnicos que determinan si la evidencia del sistema es segura. Cuando ese conocimiento no se hace utilizable, las personas ajenas al sistema cargan con el riesgo.

Para Fujitsu y otros proveedores, la lección es tratar los sistemas probatorios como sistemas de interés público cuando pueden perjudicar a las personas. Los registros de defectos, las pistas de auditoría, los registros de acceso remoto, las declaraciones periciales y el lenguaje de incertidumbre deben regirse como parte del historial de seguridad del producto. Un sistema utilizado para acusaciones no es una herramienta administrativa ordinaria.

Para las instituciones públicas, la lección es incorporar la impugnación técnica independiente en los procesos. No permitan que los sistemas propietarios se conviertan en testigos incuestionables. No asuman que los resultados digitales son neutrales. No permitan que el diseño de la compensación traslade de nuevo la carga de la prueba a los que ya han sido perjudicados. No esperen a un drama televisivo o a años de litigios para hacer visibles los defectos del sistema.

Para las personas afectadas por sistemas automatizados o semiautomatizados, la lección es dura pero importante: exijan los registros, el historial de defectos, el registro de acceso, la explicación alternativa y la regla de la carga de la prueba. El resultado de un sistema es una prueba solo cuando puede ser contrastado.

Horizon debe ser recordado como un escándalo de transferencia de costes porque eso es lo que hizo que el fallo técnico fuera tan destructivo. La incertidumbre del software se convirtió en deuda personal, sospecha penal y reparación retrasada. El futuro responsable no es simplemente un mejor software. Es una regla que exige que las instituciones demuestren el sistema antes de hacer pagar a la persona.