富士通令 Horizon 成为成本转移预防的问责测试

总结

• 富士通在 Horizon 中的角色应被理解为一个成本转移预防案例：软件输出被当作分支机构短款的证据，而这些输出帮助将财务、法律和声誉负担转嫁给个体邮局支局长。
• 公共记录包括 Bates v Post Office Horizon Issues 判决、邮局 Horizon IT 调查最终报告第一卷、富士通 2024 年的声明、GOV.UK 赔偿数据、议会审查、NAO 赔偿经验教训以及当前关于赔偿和替换的报道。
• 控制问题不仅仅是软件是否有缺陷。而是邮局、富士通、政府、律师、审计师和检察官在将系统输出作为针对个人的证据之前，是否有足够可靠的证据。
• 责任是分散的。富士通提供并支持了 Horizon。邮局运营、依赖并围绕它进行诉讼。政府拥有并监督公共政策环境。检察和法律行为者有披露义务。索赔者承担了毁灭性的转移成本。
• 持久的教训是，除非证据标准明确且可独立质疑，否则不应允许数字系统将运营不确定性转化为个人债务、刑事嫌疑或延迟赔偿。

核心问题是成本转移，而不仅仅是软件故障

Horizon 丑闻常被用“软件缺陷”来描述。这个说法准确但过于狭窄。缺陷、错误和漏洞之所以重要，是因为 Horizon 的输出被用来识别所谓的分支机构短款，并支持索偿、纪律处分、民事诉讼和刑事起诉。因此，问责问题不仅在于软件是否有缺陷，而在于有缺陷或解释不清的软件输出是否被允许将成本转移给无法看到或质疑底层系统的人。

2019 年的Bates v Post Office Horizon Issues 判决是本文的核心法律来源，因为它详细审查了 Horizon 的可靠性、缺陷、错误、漏洞、远程访问和证据主张。邮局 Horizon IT 调查的最终报告第一卷然后将其人员影响和赔偿背景纳入更广泛的公共记录。这些文件表明，狭隘的工程解释是不够的。

成本转移可能悄然发生。一个分支账户显示短款。经营者被要求补足。机构将系统输出视为权威。个人面临压力、债务、停职、起诉、破产、污名或监禁。如果系统错误、不确定、可远程更改、披露不充分或被误解，那么机构错误就成为个人负担。这就是故障类别。

富士通的角色属于这一类别，因为它提供并支持了其输出具有证据效力的系统。邮局的角色属于其中，因为它管理与邮局支局长的关系并依赖这些输出。政府的角色属于其中，因为公共所有权和监督塑造了问责环境。法律行为者属于其中，因为披露和证据义务决定了被告能否质疑技术主张。没有一个单一的行为者能完全解释这一丑闻，但每个行为者都有一个控制面。

预防问题很简单：在数字系统将损失转嫁给个人之前，需要什么证据？谁来验证系统？谁记录缺陷？谁披露不确定性？谁能质疑输出？当输出错误时，谁买单？Horizon 之所以重要，是因为这些问题回答得太晚了。

富士通的供应商角色包括证据义务

富士通 2024 年的官方声明向邮局支局长及其家人道歉，并承认事态的严重性。这一声明很重要，但供应商的问责不能仅靠道歉。其系统被用作纠纷和起诉证据的供应商，在可靠性记录、缺陷披露、支持沟通、专家证据、远程访问透明度和审计追踪方面负有义务。

供应商可能不决定起诉。它可能不拥有客户关系。它可能不确定每项法律策略。但它可能知道其他人不知道的系统情况。它可能知道缺陷历史、支持模式、远程访问能力、已知错误模式和诊断限制。当系统输出被视为证据时，这些知识就成为公共利益证据，而不仅仅是内部产品知识。

美国国家标准与技术研究院 (NIST) 的系统安全工程指南SP 800-160 第一卷修订版 1并非专门针对 Horizon，但它有助于阐明一个一般原则：可信系统需要工程、保证和生命周期证据。在 Horizon 的语境中，可信证据不仅涉及抵御网络攻击，还涉及能否依靠会计输出来指控一个人欠钱或从事不当行为。

供应商的证据包应该包括明确的答案。已知哪些缺陷？哪些版本受影响？哪些缺陷可能造成或改变短款？哪些分支机构受影响？哪些远程访问是可能的？能否在不被经营者看见的情况下插入、修改或纠正交易？存在哪些审计追踪？它们的局限性是什么？哪些专家声明是安全的？哪些不是？

这些问题很重要，因为邮局支局长没有平等访问 Horizon 内部的权利。基于系统数据被指控的人，未经披露无法独立验证一个专有系统。因此，供应商的不透明造成了证据不对称。对个人的后果越严重，供应商披露不确定性的义务就越高。

供应商的问责还延伸到替换和过渡。Computer Weekly 2026 年关于富士通被从主要的 Horizon 替换交易中剔除的报道显示，采购后果持续到了当前的公共记录。然而，替换并不等同于补救。一条新的供应商路径本身并不能回答被旧证据系统伤害的人遭遇了什么。

软件证据需要对抗性可见性

Horizon 记录揭示了一条关于软件证据的一般规则：如果系统输出被用于针对个人，个人必须能够质疑系统的可靠性、数据路径和替代解释。如果机构控制着所有技术知识并将输出视为假定真实，这种质疑就不可能有效。

皇家检察署关于披露的公开页面是一个一般性来源，并非 Horizon 特有的发现。它之所以相关，是因为刑事诉讼取决于披露可能削弱控方案情或帮助辩方的材料。在软件证据案件中，缺陷日志、支持工单、已知错误、远程访问记录、审计限制和专家不确定性可能成为披露材料。如果这些记录未被识别和分享，被告就无法检验证据。

律师协会对Bates v Post Office的评论有助于理解为什么该诉讼成为里程碑。但更深层的意义不止于一个案件。如今，数字系统在福利、银行、就业、税务、医疗、零售、警务和平台治理中生成证据。Horizon 的教训是，不应仅仅因为是数字化的，就将系统证据视为中立。

对抗性可见性需要若干控制措施。第一，足够完整的缺陷登记册，以显示已知的错误模式。第二，识别人工、自动和远程操作的审计追踪。第三，说明局限性而不仅是自信的专家证据。第四，在诉讼前保存系统日志。第五，当控制证据的机构同时受益于该输出时，应进行独立审查。第六，不悄悄转移给个人的举证责任规则。

成本转移框架有助于澄清利害关系。如果分支短款是真实的且可归因于经营者，机构可能有索赔权。如果短款是由系统缺陷、远程纠正、同步错误或未解释的会计流程造成的，机构不应转移成本。证据标准决定走哪条路。

Horizon 显示了当机构自信盖过证据谦逊时会发生什么。一个系统可以总体运行良好，但仍然在特定情况下产生有争议的输出。供应商可以修复缺陷，但仍然使过去的输出存疑。法院可以接受专家证据，但仍然发现先前的假设不安全。软件证据需要在生命被毁之前为这些不确定性提供一个渠道。

赔偿是延迟问责的证据

赔偿计划有时被视为丑闻之后的一个独立行政阶段。在 Horizon 案件中，赔偿是问责证据的一部分。补救措施的规模、复杂性、延迟、法律费用和索赔者负担揭示了，一旦机构多年来将系统输出视为权威，修复成本转移有多难。

GOV.UK 当前的2026 年邮局 Horizon 财务补救和法律费用数据使赔偿成为一条实时公共记录。上议院图书馆关于赔偿进展的简报总结了各项计划及持续的政策背景。英国国家审计署 (NAO) 关于政府赔偿计划经验教训的简报之所以相关，是因为赔偿管理本身如果缓慢、复杂或不被信任，也会造成二次伤害。

延迟补救是成本转移的另一种形式。被错误指控或施压的人可能要等待多年才能获得财务修复，同时承受破产后果、法律费用、健康损害、家庭破碎、声誉污名和失去的商业机会。赔偿无法完全恢复这些损失，但延迟扩大了鸿沟。机构修复花费的时间越长，个人继续为机构失败买单就越久。

《卫报》2026 年关于赔偿计划截止日期的报道显示，赔偿压力仍然是一个当前问题。这种当前性很重要。Horizon 不仅仅是一个历史性的技术失败。截至 2026 年，赔偿、问责、替换和机构学习仍然是公共记录的一部分。

因此，赔偿制度应以索赔者可用性来评判。资格规则是否清晰？证据负担是否公平？是否可用临时支付？法律费用是否覆盖？受创的索赔者是否得到支持？已故索赔者的家庭是否得到服务？决定是否及时？上诉是否可及？统计数据是否公布？计划设计者是否从索赔者中学习？这些问题不是行政细节。它们决定国家和机构是否停止向受害者转移成本。

预防教训更为深刻。如果补救如此艰难，那么在最初成本转移之前的证据门槛应该更高。预防不安全的指控比在错误伤害后进行赔偿要便宜得多，也公正得多。

公众监督必须保持当前性

Horizon 的公共记录仍在演变。英国议会商业与贸易委员会列出了 2026 年一次与 Horizon 正义和问责相关的口头证据会议。议会 2024 年关于为邮局支局长伸张正义的解释说明显示了该丑闻如何成为国家机构的关注点。公众监督很重要，因为复杂的问责制度在关注消退后可能偏离方向。

当前的监督应聚焦于预防，而不仅仅是追责。什么能阻止另一个系统在没有充分质疑的情况下制造个人债务或刑事嫌疑？供应商将如何披露缺陷？公共机构将如何保持独立的技术专业知识？检察官将如何处理专有软件证据？赔偿计划将如何避免再次创伤索赔者？替换系统将如何避免继承相同的证据假设？

Computer Weekly 2025 年关于富士通领导层对调查报告的反应以及指向Horizon 的人员影响的报道，捕捉了围绕机构反应的持续问责张力。二手报道不应取代调查结论，但它有助于表明问责不仅取决于正式文件，还取决于组织如何内化这些文件。

公众监督还必须涵盖政府所有权。邮局的地位和公共政策角色意味着，这不仅仅是一个私人供应商/客户纠纷。政府有监督职责、资金职责、赔偿职责，以及攸关的机构信誉。如果公共服务网络依赖专有证据系统，政府必须确保其能够理解和质疑它们。外包技术运营不能意味着外包公共问责。

同样的规则也适用于 Horizon 之外。福利系统、税务系统、移民系统、医疗系统、法院系统和受监管市场越来越依赖软件输出。如果这些输出影响金钱、身份、自由或声誉，公共机构需要在伤害发生前具备技术素养和披露规则。

远程访问本应是一级证据问题

远程访问是 Horizon 记录中最重要的技术概念之一，因为它影响到谁可以修改、纠正或影响分支数据，以及分支经营者能够合理地知道什么。如果中心行为者可以访问或更改记录，证据故事就不仅仅是“分支系统记录了一笔短款”。故事还必须包括还有谁可以接触数据、何时接触、在何种控制下、以及有何种审计追踪。

官方的邮局 Horizon IT 调查网站很有价值，因为它为公众提供了进入漫长证据记录的途径。Bates 判决仍然是本文使用的关于远程访问和缺陷/错误/漏洞分析的最直接来源，但调查记录表明，为什么技术能力必须与治理、文化、法律程序和赔偿一起被考虑。

远程访问并不自动意味着不当行为。许多系统需要支持访问来修复故障、维护服务和帮助用户。当远程访问存在但被否认、误解、披露不充分、记录薄弱或被视为与对用户的指控无关时，问责问题就出现了。在会计争议中，远程更改的可能性不是一个旁支问题。它是一种可能改变负担、证据和公平性的替代解释。

预防规则应该是明确的。如果一个机构依赖系统输出来指控用户，它必须披露远程访问是否可能影响相关数据。它必须保存显示远程操作的日志。它必须解释谁有访问权、受哪些控制管理，以及在相关期间是否发生了任何远程操作。如果日志不完整，不确定性应该不利于机构自信，而不是不利于被指控的个人。

这一规则在分布式公共服务系统中尤为重要。分支经营者、当地代理商、加盟商、承包商和小企业通常在中央平台的边缘运作。中央机构拥有技术权力。当地经营者承担面向公众的责任。当记录不一致时，中央机构不应被允许假设是边缘经营者造成了差异，而不开放中央系统接受质疑。

因此，远程访问透明度应被纳入系统设计。用户应在适当情况下收到支持操作的通知或日志。审计追踪应防止篡改。专家证人应了解并披露远程能力。合同应说明支持访问如何影响证据。法院和监管机构在接受系统输出为决定性证据之前应询问此事。

专家证据必须包含局限性，而不仅仅是结论

Horizon 还表明，关于软件系统的专家证据必须包含局限性。专家可以说一个系统总体运行良好。这一说法可能为真，但仍不能证明某一特定短款是由特定个人造成的。软件系统可以总体可靠，但在特定条件下会失败。它们可以处理数百万笔交易，但仍然产生对一个被告至关重要的缺陷。

因此，专家证据应针对指控具体化。哪个分支？哪个日期？哪个软件版本？哪个缺陷历史？哪些支持工单？哪些远程操作？哪个对账流程？哪些数据迁移？哪些已知错误？哪些审计追踪？哪些替代解释？一个宽泛的可靠性断言不能替代个案具体分析。

英国最高法院 2024 年在相关邮局赔偿/法律背景下的判决并非 Horizon 技术判决，不应将其延伸为技术判决。它在此仅提醒人们，法律后果在多个程序途径中持续。更重要的原则是普遍的：法律制度需要足够精确的技术证据以供检验。

专家还应以通俗语言披露不确定性。如果某个缺陷可能造成差异，应说明。如果因为日志缺失而无法排除远程操作，应说明。如果系统架构限制了什么可以推断，应说明。法院和被告人可以更好地处理不确定性，而不是后来崩溃的过度自信。

提供证据的供应商员工面临特殊风险。他们可能深入了解该系统，但其雇主可能有商业、声誉或合同利益。这并不意味着他们的证据是假的。这意味着法院和机构应要求独立性、披露利益冲突、获取完整的缺陷记录，并明确区分技术分析和机构主张。

预防控制是用于软件生成指控的专家证据清单：总体可靠性、相关缺陷历史、远程访问能力、数据血缘证明、审计日志完整性、版本特定行为、支持工单背景和残余不确定性。如果清单无法完成，机构不应将软件输出作为针对个人的决定性证据。

替换并不能消除证据债务

替换 Horizon 或将富士通从未来采购中移除可能是必要的，但替换并不能消除证据债务。人们在旧系统下受到伤害。定罪、还款、破产、企业倒闭、家庭创伤和声誉损害，无法通过说新系统会更好来修复。旧的证据记录仍必须被审计、解释和赔偿。

替换甚至可能带来过早关闭的风险。组织可能更喜欢谈论转型、现代化、新供应商和未来韧性，因为这些话题感觉有建设性。受害者和索赔者可能仍在等待补救。造成伤害的系统可能被退役，而后果依然存活。问责必须同时关注两条时间线：未来的系统替换和过去的伤害修复。

供应商过渡应包括知识保存。缺陷历史、支持工单、专家报告、数据字典、交易日志、远程访问记录和审计材料不应在替换期间消失。如果未来的索赔者或调查者需要了解 Horizon 的行为，这些记录必须保持可用。退役的系统仍然可以是证据。

替换还应问一问新系统是否改变了成本转移规则。分支经营者是否会收到更清晰的审计日志？远程支持操作是否可见？差异质疑是否有独立途径？缺陷通知是否会向受影响用户披露？起诉或民事追索是否会在没有技术质疑的情况下依赖系统输出？一个没有新证据规则的新界面是不够的。

公共采购应纳入这些教训。竞标生成针对个人证据的系统的供应商，应被要求提供缺陷披露机制、审计追踪、用户可见的支持日志、专家证据协议、独立审查权和数据保存承诺。采购测试不应只问系统是否工作，还应问系统能否被公平质疑。

因此，Horizon 替换故事是预防的一部分，而不仅仅是运营。一个采购新系统却不嵌入质疑权利的公共机构学到得太少了。

索赔者负担是机构伤害的一部分

补救过程不应让索赔者再次证明丑闻已经结构性证明的事情：机构对 Horizon 的依赖造成了严重的不公正。个别索赔总是需要证据，但证据负担的设计很重要。如果索赔者被迫用原本应由机构保存的文件重建几十年前的损失，那么成本就再次转移给了被伤害者。

赔偿计划应从创伤知情设计开始。一些索赔者可能不信任邮局、政府、律师或供应商，因为这些机构以前辜负了他们。一些可能缺乏记录，因为企业倒闭、家庭搬迁、健康恶化或多年过去。一些可能已经去世，留下家人来应对流程。计划应在机构已知总体失败背景的地方减少摩擦。

行政延迟并非中性。每延迟一个月，都可能意味着持续的财务压力、未解决的遗产问题、法律不确定性、压力和公众失望。因此，补救统计数据不仅应报告总付款额，还应报告等待时间、待解决问题、延迟原因、上诉结果、索赔者支持和法律费用负担。透明度将延迟转化为可治理的事实。

NAO 关于赔偿计划的经验教训之所以重要，是因为补救是一个交付系统。设计不当的计划即使在意图修复时也可能重新造成机构失衡。复杂的表格、狭窄的证据规则、不一致的补偿方案和缓慢的沟通可能成为二次伤害。起诉前所需的同样证据谦逊应出现在赔偿中。

即使在政府和邮局管理计划的地方，富士通的问责也与索赔者负担相交。如果供应商证据促成了最初的成本转移，供应商的合作应有助于现在减轻索赔者的负担。技术记录、缺陷历史和系统解释应在相关时提供给补救。索赔者不应不得不重新发现一个供应商建立的系统。

道德检验是，补救是否逆转了负担的方向。在丑闻中，个人被迫承担机构的确定性。在赔偿中，机构应承担修复的负担。任何少于这一点的做法都使成本转移逻辑完好无损。

预防规则应适用于邮局之外

Horizon 的教训应被写成一条一般机构规则：任何自动化、半自动化或专有系统输出都不应用于施加债务、纪律处分、起诉、排斥或严重的声誉损害，除非受影响的人能够有意义地质疑该系统。该规则适用于公共管理、受监管服务和私营平台，只要系统证据决定着人们的结果。

有意义质疑有最低要素。个人应知道所使用的数据。他们应知道系统版本和相关规则。他们应能获得可能影响案件的缺陷信息。他们应被告知人员或远程系统是否可以更改记录。他们应能获得日志或独立的技术审查。他们不应被迫在没有系统访问权的情况下证明隐藏的系统是错误的。

这一原则并不反对技术。可靠的系统可以保护人们、检测欺诈、减少错误和改善服务。关键在于，当系统成为证据时，机构权力增长了。这种权力需要程序保障。Horizon 失败不是因为使用了技术，而是因为技术被当作比证据论证更权威，而人们被留在了证据循环之外。

因此，董事会应对任何高利害系统提出一个简单问题：一个人能否公平地质疑这个输出？如果答案是否定的，该系统就不应用于高利害的成本转移。如果答案是肯定的，董事会应要求证据：审计追踪、缺陷披露、上诉途径、独立审查、用户通知和保存规则。

供应商如果想拥有可信的市场，应欢迎这一规则。一个能够被公平质疑的系统比一个靠不透明来防御的系统更持久。质疑权利能更早暴露缺陷，减少灾难性诉讼，并使客户不太可能将供应商视为隐藏的对手。可信软件不是没有人可以质疑的软件。它是经受得住质疑的软件。

更广泛的公共教训是，数字证据正在变得寻常。这种寻常使 Horizon 更加重要，而不是相反。下一个成本转移丑闻可能来自福利软件、税务分析、工资自动化、预测警务、医院计费、平台审核或能源计量。预防规则应在下一批个人被告知系统一定是正确的之前到位。

审计追踪应为被指控者设计

许多审计系统是为管理员、供应商或内部保证团队设计的。Horizon 显示了为什么高利害审计追踪也应为受到输出影响的人设计。如果系统说一个分支有短款，分支经营者应能够看到交易路径、纠正路径、支持路径和异常路径的足够信息，以理解指控。只有机构能够解释的审计追踪是薄弱的保护。

面向人的审计并不意味着暴露每一个敏感的系统细节。它意味着给受影响的人一个连贯的记录：有问题的交易、时间戳、对账步骤、任何由中央发起的更改、影响该分支或时段的已知事件、相关缺陷，以及请求独立审查的途径。该记录应可导出且持久。它不应取决于当地经理的自由裁量权。

审计追踪还应显示缺席，当缺席很重要的时候。如果没有远程访问发生，系统应能够显示这一点。如果远程访问发生了但没有影响有争议的数据，系统应显示边界。如果日志不完整，记录应说明情况。沉默不应被自动解读为对个人不利。

设计规则是，审计应跟随后果。可能的后果越严重，审计追踪就必须越透明、越可独立审查。一个较小的内部对账异常可能需要一级证据。而要求个人偿还数千英镑、失去生计或面临刑事嫌疑则需要更多。

这一规则还将改善供应商的激励。如果审计追踪必须可被指控者使用，供应商就必须构建能自我解释的系统。这可能增加成本，但它防止了更大的社会成本。不能生成公平审计追踪的系统，不应被用于施加高利害的个人责任。

民事追索和起诉不应共享不安全的假设

Horizon 还警告不要让民事追索和起诉通过相同未经检验的假设相互强化。如果系统输出在民事索偿中被视为可靠，这种自信可能转移到纪律处分或刑事嫌疑中。如果起诉将系统记录视为权威，这种姿态可以强化民事追索。同样薄弱的技术前提可以在不同法律途径之间传递。

预防控制是要求在升级前进行独立技术审查。一个有争议的短款不应在没有问及系统缺陷、远程操作、支持干预或对账错误是否是合理解释的情况下，从会计查询升级为债务索偿再到起诉。每一次升级都应要求比前一次更强的证据基础。

民事追索还应包括公平性核查。经营者是否有访问质疑短款所需记录的权利？经营者是否被告知了已知缺陷？是否调查了替代解释？是否审查了由中央发起的纠正？索偿金额是否基于核实的损失而非系统自信？这些核查应在施压之前进行，而不是在诉讼开始之后。

起诉则进一步提高门槛。自由、声誉和刑事记录置于风险之中。披露必须是主动的。专家证据必须谨慎。提起或支持案件的机构不应被允许以专有复杂性为盾牌。如果系统太复杂而无法披露和检验，它就太复杂而无法用作决定性刑事证据。

同样的想法也适用于内部纪律处分和合同终止。即使没有定罪，如果机构基于不可靠的系统数据终止关系、扣留薪酬或公开嫌疑，一个邮局支局长或承包商也可能被毁掉。高利害行政决策需要自己的技术质疑流程。

Horizon 变成灾难性的，部分原因是不同的问责渠道重复了相同的自信。未来的系统应该做相反的事：每次升级都应重新打开技术问题，并以更强的审查来对待。

证据管理应超越领导层更替

长期的丑闻比高管、部长、供应商经理、律师和 IT 团队更持久。因此，证据管理必须超越领导层更替。缺陷记录、支持工单、审计日志、董事会文件、专家报告和索赔者沟通应根据法律和伦理保留计划保存，而不是留给部门习惯。

这很重要，因为延迟的问责往往依赖于旧记录。索赔者可能在多年后需要证据。法院可能重新审查定罪。调查可能询问谁在何时知道了什么。替换项目可能需要知道哪些缺陷伤害了用户。如果记录消失，延迟再次有利于控制证据的机构。

供应商合同应包括终止后的证据义务。当供应商被替换时，它仍应保存并提供与索赔、调查和法律审查相关的记录。公共机构不应因为商业关系结束而失去对证据的访问权。供应商也不应在一份合同终止后就将历史缺陷知识视为无关。

证据管理还需要元数据：谁创建了记录、何时、涉及哪个系统版本、影响哪个分支或索赔者，以及是否已审查。一堆文件不等同于可用证据。受 Horizon 伤害的人需要可用证据，而不是只有内部人员才能解码的机构档案。

这就是为什么预防和补救在记录设计中交汇。一个良好记录缺陷的系统可以防止不安全的指控。如果预防失败，同样的记录可以支持更快的赔偿。糟糕的记录会失败两次：第一次是在伤害发生时，第二次是在修复延迟时。

问责应被设计进下一个系统

富士通的最后一个教训是，问责不能在公众怒火重燃后附加到替换系统上。质疑权利、审计可见性、缺陷披露、远程访问日志、专家证据标准和赔偿证据保存，应从一开始就成为设计要求。一个重复旧的证据不对称的新平台，将现代化界面同时保留成本转移风险。

问责检验是预防先于补救

Horizon 之后的问责问题不仅仅是支付了多少补救款项或哪些高管道歉了。而是机构现在是否有一条预防规则：除非系统的可靠性、缺陷、访问途径和审计限制能够被独立质疑，否则不要使用数字系统将成本、嫌疑或法律负担转移给个人。

公共记录并不将责任仅归于富士通。邮局、政府、律师、审计师、检察官和赔偿管理者都曾或仍具有角色。富士通的角色仍然重要，因为供应商可能掌握决定系统证据是否安全的技术知识。当这些知识不可用时，系统外的人承担风险。

对于富士通和其他供应商，教训是将证据系统视为公共利益系统，当它们可能伤害个人时。缺陷记录、审计追踪、远程访问日志、专家声明和不确定性语言应作为产品安全记录的一部分来治理。用于指控的系统不是一个普通的后台工具。

对于公共机构，教训是将独立的技术质疑纳入流程。不要让专有系统成为不可质疑的证人。不要假设数字输出是中立的。不要让赔偿设计将举证负担转回给已经受害的人。不要等待电视剧或多年的诉讼才让系统缺陷变得可见。

对于受自动化或半自动化系统影响的个人，教训是严酷但重要的：要求日志、缺陷历史、访问记录、替代解释和举证责任规则。系统输出只有当它可以被检验时才是证据。

Horizon 应被记住为一个成本转移丑闻，因为正是这一点使技术失败如此具有破坏性。软件不确定性变成了个人债务、刑事嫌疑和延迟修复。可问责的未来不仅仅是更好的软件。它是一条规则：机构必须先证明系统，然后才能让个人付出代价。