摘要
- Fujitsu 在 Horizon 事件中的角色应被理解为成本转移预防案例：软件输出被用作分支短缺的证据，这些输出帮助将财务、法律和声誉负担转移给个别分局局长。
- 公共记录包括 Bates v Post Office Horizon Issues 判决、Post Office Horizon IT 调查最终报告第一卷、Fujitsu 的 2024 年声明、GOV.UK 的赔偿数据、议会审查、NAO 的赔偿经验教训，以及关于赔偿和替代的最新报道。
- 关键问题不仅仅在于软件是否有缺陷。而在于 Post Office、Fujitsu、政府、律师、审计师和检察官在将系统输出作为对人不利的证据之前，是否掌握了足够可靠的证据。
- 责任是分散的。Fujitsu 提供并支持 Horizon。Post Office 运营、依赖并围绕其提起诉讼。政府拥有并监督公共政策环境。检察和法律行为者负有披露义务。索赔人承受了毁灭性的转移成本。
- 持久的教训是，不允许数字系统将运营不确定性转化为个人债务、刑事嫌疑或延迟赔偿，除非证据标准明确且可独立质疑。
问题是成本转移，而不仅仅是软件故障
Horizon 丑闻常被描述为“软件缺陷”。这个说法准确但不够全面。缺陷、错误和问题之所以重要，是因为 Horizon 输出被用于识别所谓的分支短缺，并支持索赔、纪律处分、民事诉讼和起诉。因此，问责问题不仅仅在于软件是否有缺陷。而在于有缺陷或未充分解释的软件输出是否被允许将成本转移给那些无法查看或质疑底层系统的人。
2019 年的Bates v Post Office Horizon Issues 判决是本文的核心法律来源，因为它详细审查了 Horizon 的可靠性、缺陷、错误、问题、远程访问和证据主张。Post Office Horizon IT 调查的最终报告第一卷则将丑闻的人文影响和赔偿背景置于更广泛的公共记录中。这些文件表明，狭隘的工程解释是不够的。
成本转移可能悄然发生。分支账户显示短缺。操作员被告知要补足。机构将系统输出视为权威。个人面临压力、债务、停职、起诉、破产、耻辱或监禁。如果系统是错误的、不确定的、可远程更改的、未充分披露或误解的，那么机构错误就成了个人负担。这就是失败类别。
Fujitsu 的角色属于此类，因为它提供并支持了其输出具有证据价值的系统。Post Office 的角色属于此类，因为它管理与分局局长的关系并依赖输出。政府的角色属于此类，因为公共所有权和监督塑造了问责环境。法律行为者的角色属于此类，因为披露和证据义务决定了被告能否质疑技术主张。没有哪个单一行为者能完全解释丑闻，但每个行为者都有一个控制面。
预防问题很简单：在数字系统将损失转移到个人之前，需要什么证据？谁验证系统？谁记录缺陷？谁披露不确定性？谁能质疑输出？当输出错误时谁承担？Horizon 之所以重要，是因为这些问题回答得太晚了。
Fujitsu 的供应商角色包括证据义务
Fujitsu 2024 年的官方声明向分局局长及其家人道歉，并承认事态的严重性。该声明很重要，但供应商问责不能仅靠道歉。一个系统被用作争议和起诉中的证据的供应商，在可靠性记录、缺陷披露、支持沟通、专家证据、远程访问透明度和审计追踪方面负有义务。
供应商可能不决定是否起诉。它可能不拥有客户关系。它可能不制定每一项法律策略。但它可以知道关于系统的一些别人不知道的事情。它可能知道缺陷历史、支持模式、远程访问能力、已知错误模式和诊断限制。当系统输出被当作证据时，这些知识就成了公共利益证据，而不仅仅是内部产品知识。
NIST 的系统安全工程指南SP 800-160 第 1 卷修订版 1并非 Horizon 特有，但它有助于命名一个一般原则：可信系统需要工程、保证和生命周期证据。在 Horizon 的背景下，可信证据不仅仅关乎网络攻击抵抗。它关乎会计输出是否可以被信赖来指责一个人欠钱或犯错。
供应商的证据包应该包含明确的答案。已知哪些缺陷？哪些版本受影响？哪些缺陷可能制造或改变短缺？哪些分支受影响？哪些远程访问是可能的？交易是否可以在操作员不知情的情况下插入、更改或更正？存在哪些审计追踪？它们的限制是什么？哪些专家陈述是安全的？哪些不是？
这些问题之所以重要，是因为分局局长无法平等访问 Horizon 内部。一个基于系统数据被指控的人，如果没有披露，就无法独立验证专有系统。因此，供应商的不透明性造成了证据不对称。对个人的后果越严重，供应商让不确定性可视化的义务就越高。
供应商问责也延伸到替代和过渡。Computer Weekly 2026 年关于 Fujitsu 被移除出主要 Horizon 替代交易的报道显示，采购后果延续到了当前的公共记录。然而，替代并不等同于补救。一个新的供应商路径本身并不能回答那些被旧证据系统伤害的人发生了什么。
软件证据需要对抗性可见性
Horizon 记录揭示了一个关于软件证据的一般规则：如果一个系统输出被用来针对一个人，这个人必须能够质疑系统的可靠性、数据路径和替代解释。如果机构控制所有技术知识并将输出视为推定真实，那么这种质疑就无法有意义地进行。
皇家检控署关于披露的公开页面是一个一般来源，而非 Horizon 特有的发现。它之所以相关，是因为刑事诉讼依赖于披露可能削弱检控方或帮助辩方的材料。在软件证据案件中，缺陷日志、支持工单、已知缺陷、远程访问记录、审计限制和专家不确定性可能成为披露材料。如果这些记录未被识别和共享，被告就无法检验证据。
律师协会关于Bates v Post Office的评论有助于说明为什么该诉讼成为一个里程碑。但更深层的意义超越了一个案例。数字系统现在在福利、银行、就业、税务、医疗、零售、警务和平台治理中产生证据。Horizon 的教训是，仅仅因为是数字的，系统证据就不应被视为中立。
对抗性可见性需要几个控制措施。第一，一个足够完整的缺陷登记册，以显示已知错误模式。第二，识别人类、自动和远程操作的审计追踪。第三，陈述限制而非仅信心的专家证据。第四，诉讼前系统日志的保存。第五，当受益于输出的同一机构控制证据时进行独立审查。第六，不悄然转移到个人的举证责任规则。
成本转移框架有助于阐明利害关系。如果分支短缺是真实的且可归因于操作员，机构可能有权提出索赔。如果短缺是由系统缺陷、远程修正、同步错误或无法解释的会计过程造成的，机构不应转移成本。证据标准决定了走哪条路。
Horizon 展示了当机构信心超过证据谦逊时会发生什么。一个系统可以大致运作，但在特定情况下仍产生有争议的输出。供应商可以修复缺陷，但仍使过去的输出存疑。法院可以接收专家证据，但仍发现先前的假设不安全。在生活被毁之前，软件证据需要为这些不确定性留出渠道。
赔偿是延迟问责的证据
赔偿计划有时被视为丑闻后的单独行政阶段。在 Horizon 案例中，赔偿是问责证据的一部分。补救的规模、复杂性、延迟、法律成本和索赔人负担揭示了，一旦机构多年来将系统输出视为权威，修复成本转移有多难。
GOV.UK 当前的Post Office Horizon 财务补救和法律成本数据（2026 年）使赔偿成为活生生的公共记录。上议院图书馆关于赔偿进展的简报总结了各种计划和持续的政策背景。国家审计署关于政府赔偿计划经验教训的简报之所以相关，是因为如果赔偿管理缓慢、复杂或不受信任，其本身也可能重现伤害。
延迟补救是成本转移的另一种形式。被错误指控或施压的人可能等待数年才能获得财务修复，同时承受破产后果、法律费用、健康损害、家庭损失、声誉污名和失去的商业机会。赔偿无法完全恢复这些损失，但延迟使差距更糟。机构修复需要的时间越长，个人就越是继续为机构的失败买单。
《卫报》2026 年关于赔偿计划截止日期的报道显示，补救压力仍然是一个当前问题。这种当前性很重要。Horizon 不仅仅是一个历史性的技术失败。截至 2026 年，赔偿、问责、替代和机构学习仍然是公共记录的一部分。
因此，赔偿体系应根据索赔人的可用性来判断。资格规则是否清晰？证据负担是否公平？是否提供临时付款？法律费用是否涵盖？受创的索赔人是否得到支持？已故索赔人的家属是否得到服务？决定是否及时？上诉是否可及？数据是否公布？计划设计者是否从索赔人中学习？这些问题不是行政细节。它们决定了国家和机构是否停止向受害者转移成本。
预防的教训甚至更强。如果补救如此困难，那么原始成本转移之前的证据门槛本应更高。防止不安全的指控远比补偿错误伤害更便宜也更公正。
公众监督必须保持当前性
Horizon 公共记录仍在演变。英国议会商业和贸易委员会列出了一次 2026 年的口头证据会议，与 Horizon 正义和问责相关。议会 2024 年关于分局局长正义的解释显示丑闻如何成为国家关注的机构问题。公众监督之所以重要，是因为复杂的问责系统可能在注意力消退后漂移。
当前的监督应侧重于预防，而非仅追究责任。什么将阻止另一个系统在没有充分挑战的情况下产生个人债务或刑事嫌疑？供应商如何披露缺陷？公共机构如何保持独立技术专业知识？检察官如何处理专有软件证据？赔偿计划如何避免再次伤害索赔人？替代系统如何避免继承相同的证据假设？
Computer Weekly 2025 年关于 Fujitsu 领导层对调查报告反应以及Horizon 人文影响的报道，捕捉了围绕机构回应的持续问责紧张。二手报道不应取代调查结果，但它有助于表明问责不仅取决于正式文件；还取决于组织如何内化这些文件。
公众监督还必须涵盖政府所有权。Post Office 的地位和公共政策角色意味着这不仅仅是私人供应商与客户之间的争议。政府负有监督义务、资助义务、赔偿义务以及机构信誉的利害关系。如果公共服务网络依赖专有证据系统，政府必须确保能够理解和挑战它们。外包技术操作不能意味着外包公共问责。
同样的规则也适用于 Horizon 之外。福利系统、税务系统、移民系统、医疗系统、法院系统和受监管市场越来越依赖软件输出。如果这些输出影响金钱、地位、自由或声誉，公共机构需要技术素养和披露规则，以防止伤害发生。
远程访问本应成为首要证据问题
远程访问是 Horizon 记录中最重要的技术概念之一，因为它影响谁可以更改、修正或影响分支数据，以及分支操作员合理知道什么。如果中央行为者可以访问或更改记录，那么证据故事不仅仅是“分支系统记录了短缺”。故事必须包括谁还能触碰数据、何时、在何种控制下以及有哪些审计追踪。
官方 Post Office Horizon IT 调查网站很有价值，因为它为公众提供了进入漫长证据记录的途径。Bates 判决仍然是本文所用远程访问和缺陷/错误/问题分析最直接的来源，但调查记录表明，技术能力必须与治理、文化、法律程序和赔偿一起考虑。
远程访问并不自动意味着不当行为。许多系统需要支持访问来修复故障、维护服务和帮助用户。当远程访问存在但被否认、误解、未充分披露、日志记录不完善或被认为与针对用户的指控无关时，问责问题就出现了。在会计纠纷中，远程更改的可能性不是一个次要问题。它是一个可能改变负担、证据和公平性的替代解释。
预防规则应明确。如果机构依赖系统输出来指控用户，它必须披露远程访问是否可能影响相关数据。它必须保存显示远程操作的日志。它必须解释谁有访问权限、哪些控制措施管理它，以及是否在相关期间发生过任何远程操作。如果日志不完整，不确定性应算作不利于机构信心，而非被指控的个人。
这条规则在分布式公共服务系统中尤为重要。分支操作员、地方代理、特许经营者、承包商和小企业通常在一个中央平台的边缘运营。中央机构拥有技术力量。地方操作员面对公众的责任。当记录不一致时，中央机构不应被允许假设边缘操作员造成了差异，除非开放中央系统供质疑。
因此，远程访问透明度应内建于系统设计。用户在适当情况下应收到支持操作的通知或日志。审计追踪应防篡改。专家证人应理解并披露远程能力。合同应说明支持访问如何影响证据。法院和监管机构在接受系统输出作为决定性证据之前应就此提出询问。
专家证据必须包括限制，而不仅仅是结论
Horizon 还展示了为什么关于软件系统的专家证据必须包括限制。专家可以说系统大致运行正常。这个陈述可能为真，但仍不能证明特定短缺是由特定个人造成的。软件系统可能在普遍可靠的同时在特定条件下失败。它们可能处理数百万笔交易，同时仍产生对一个被告至关重要的缺陷。
因此，专家证据应具体针对指控。哪个分支？哪些日期？哪个软件版本？哪个缺陷历史？哪些支持工单？哪些远程操作？哪些对账过程？哪些数据迁移？哪些已知缺陷？哪些审计追踪？哪些替代解释？一个宽泛的可靠性断言不能替代个案分析。
英国最高法院 2024 年关于Post Office 赔偿/法律背景相关判决并非 Horizon 技术判决，不应被曲解为一。它在此仅作为提醒，即法律后果在多个程序路径上持续。更重要的原则是一般性的：法律系统需要足够精确的技术证据来检验。
专家还应用日常语言披露不确定性。如果缺陷可能导致差异，就说出来。如果专家无法排除远程操作因为日志缺失，就说出来。如果系统架构限制了什么可以推断，就说出来。法院和被指控的人能更好地处理不确定性，而不是后来崩溃的过度自信。
提供证据的供应商员工面临特定风险。他们可能深入了解系统，但他们的雇主可能有商业、声誉或合同利害关系。这并不意味着他们的证据不真实。这意味着法院和机构应要求独立性、披露利益冲突、访问完整的缺陷记录，以及技术分析与机构倡导之间的明确分离。
预防控制是一个用于软件生成的指控的专家证据检查表。一般可靠性、相关缺陷历史、远程访问能力、数据来源证明、审计日志完整性、版本特定行为、支持工单背景和剩余不确定性。如果检查表无法完成，机构不应将软件输出视为针对个人的决定性证据。
替代不能消除证据债务
替换 Horizon 或从未来采购中移除 Fujitsu 可能是必要的，但替代不能消除证据债务。人们在旧系统下受到伤害。定罪、还款、破产、失去生意、家庭创伤和声誉损失无法通过说新系统会更好来修复。旧的证据记录仍然需要审计、解释和赔偿。
替代甚至可能带来提前结束的风险。组织可能更愿意谈论转型、现代化、新供应商和未来韧性，因为这些话题让人感觉有建设性。受害者可能仍在等待补救。造成伤害的系统可能在后果仍然存在时退役。问责必须同时关注两个时间线：未来系统替换和过去伤害修复。
供应商过渡应包括知识保存。缺陷历史、支持工单、专家报告、数据字典、交易日志、远程访问记录和审计材料不应在替换过程中消失。如果未来的索赔人或调查者需要理解 Horizon 行为，这些记录必须保持可用。退役的系统仍可以是证据。
替代还应询问新系统是否改变了成本转移规则。分支操作员是否会收到更清晰的审计日志？远程支持操作是否可见？差异质疑是否有独立途径？缺陷通知是否向受影响用户披露？起诉或民事追偿是否会在没有技术挑战的情况下依赖系统输出？没有新证据规则的新界面是不够的。
公共采购应纳入这些教训。投标用于产生针对个人证据的系统的供应商，应被要求提供缺陷披露机制、审计追踪、用户可见的支持日志、专家证据协议、独立审查权和数据保存承诺。采购测试不应只问系统是否工作；还应问系统能否被公平地质疑。
因此，Horizon 替换故事是预防的一部分，而不仅仅是运营。一个购买了新系统却未嵌入质疑权的公共机构，学到的太少。
索赔人负担是机构伤害的一部分
补救过程不应让索赔人再次证明丑闻已经从结构上证明的东西：机构对 Horizon 的依赖导致了严重不公。个人索赔总是需要证据，但证据负担的设计很重要。如果索赔人被强迫用机构本应保存的文件重建数十年前的损失，成本就再次转移到了受害者身上。
赔偿计划应从创伤知情设计开始。一些索赔人可能不信任 Post Office、政府、律师或供应商，因为这些机构此前让他们失望。一些索赔人可能因为企业倒闭、家庭搬迁、健康恶化或岁月流逝而缺乏记录。一些索赔人可能已去世，留下家属来应对过程。计划应在机构已经知道广泛失败背景的地方减少摩擦。
行政延迟并非中立。每个月的延迟都可能意味着持续的经济压力、未解决的遗产、法律不确定性、压力和公众挫败感。因此，补救统计数据不仅应报告总支付额，还应报告等待时间、待处理案件、延迟原因、上诉结果、索赔人支持和法律费用负担。透明度将延迟转化为可治理的事实。
NAO 关于赔偿计划的经验教训之所以重要，是因为补救是一个交付系统。一个设计糟糕的计划，即使在意图修复时，也可能重新制造机构不平衡。复杂的表格、狭窄的证据规则、不一致的报价和缓慢的沟通可能成为二次伤害。在起诉之前所需的相同证据谦逊也应出现在赔偿中。
即使政府和 Post Office 管理计划，Fujitsu 的问责也与索赔人负担相交。如果供应商证据促成了原始成本转移，供应商合作现在应有助于减轻索赔人负担。技术记录、缺陷历史和系统解释应在相关情况下为补救提供。索赔人不应不得不重新发现供应商构建的系统。
道德测试是补救是否逆转了负担方向。在丑闻期间，个人被迫承担机构确定性。在赔偿期间，机构应承担修复负担。任何更少都会让成本转移逻辑保持不变。
预防规则应适用于 Post Office 之外
Horizon 教训应被写为一个一般机构规则：除非受影响的人可以有意义地质疑系统，否则不得使用自动化、半自动化或专有系统输出来施加债务、纪律、起诉、排除或严重声誉伤害。该规则属于公共行政、受监管服务以及系统证据决定人类结果的私人平台。
有意义质疑具有最低要素。个人应知道使用的数据。他们应知道系统版本和相关规则。他们应能访问可能影响案件的缺陷信息。他们应被告知人类或远程系统是否可以更改记录。他们应能获取日志或独立技术审查。他们不应在没有访问系统的情况下被要求证明一个隐藏系统错误。
这个原则并非反技术。可靠的系统可以保护人们、检测欺诈、减少错误和改善服务。关键在于，当系统成为证据时，机构力量会增长。这种力量需要程序保障。Horizon 失败不是因为使用了技术，而是因为技术被认为比证据证明的更权威，而人们被排除在证明循环之外。
因此，董事会应对任何高利害系统提出一个简单问题：一个人能公平地质疑这个输出吗？如果答案是否定的，该系统不应被用于高利害成本转移。如果答案是肯定的，董事会应要求证据：审计追踪、缺陷披露、上诉途径、独立审查、用户通知和保存规则。
如果供应商想要可信的市场，他们应欢迎这条规则。一个可以被公平质疑的系统比一个通过不透明性来捍卫的系统更持久。质疑权可以更早暴露缺陷，减少灾难性诉讼，并让客户更不可能将供应商视为隐藏的对手。可信的软件不是无人能质疑的软件。它是经得起质疑的软件。
更广泛的公众教训是，数字证据正变得日常化。这种日常性使 Horizon 变得更重要，而非更不重要。下一个成本转移丑闻可能来自福利软件、税务分析、薪资自动化、预测性警务、医院账单、平台监管或能源计量。预防规则应在下一组被告知系统一定是正确的人们之前到位。
审计追踪应为被指控的人设计
许多审计系统是为管理员、供应商或内部保证团队设计的。Horizon 表明，高利害审计追踪也应针对受输出影响的人设计。如果系统说一个分支短缺，分支操作员应能看到足够的交易路径、修正路径、支持路径和异常路径来理解指控。只有机构才能解读的审计追踪是薄弱的保护。
面向个人的审计并不意味着暴露每一个敏感系统细节。它意味着给受影响的人一个连贯的记录：有问题的交易、时间戳、对账步骤、任何中央发起的更改、影响分支或时期的已知事件、相关缺陷，以及要求独立审查的途径。记录应可导出且持久。它不应取决于地方管理人员的自由裁量权。
审计追踪还应在缺失重要时显示缺失。如果没有远程访问发生，系统应能显示这一点。如果远程访问发生了但未影响争议数据，系统应显示边界。如果日志不完整，记录应说明。沉默不应自动被解读为对个人不利。
设计规则是审计应追随后果。可能的后果越严重，审计追踪就必须更透明和可独立审查。一个小的内部对账例外可能需要一个级别的证据。要求个人偿还数千英镑、失去生计或面临刑事嫌疑则需要更多。
这条规则也会改善供应商的激励。如果审计追踪必须可供被指控的人使用，供应商必须构建能够解释自身的系统。这可能增加成本，但防止了更大的社会成本。无法生成公平审计追踪的系统不应被用于施加高利害个人责任。
民事追偿和起诉不应共享不安全假设
Horizon 还警告不要让民事追偿和起诉通过相同的未经验证假设相互加强。如果系统输出在民事要求中被视为可靠，这种信心可能迁移到纪律处分或刑事嫌疑。如果起诉将系统记录视为权威，这种姿态可以加强民事追偿。相同的脆弱技术前提可以跨越法律途径传播。
预防控制是在升级前要求独立技术审查。有争议的短缺不应从会计查询转到债务要求再到起诉，而不问系统缺陷、远程操作、支持干预或对账错误是否是一个合理解释。每次升级都需要比上一次更强的证据基础。
民事追偿还应包括公平性检查。操作员是否有权访问挑战短缺所需的记录？操作员是否被告知已知缺陷？是否调查了替代解释？是否审查了中央发起的修正？要求的金额是基于验证的损失而非系统信心？这些检查应在施加压力之前进行，而非在诉讼开始之后。
起诉进一步提高了门槛。自由、声誉和犯罪记录处于危险之中。披露必须主动。专家证据必须谨慎。提起或支持案件的机构不应被允许依赖专有复杂性作为盾牌。如果系统太复杂无法披露和测试，那么它也太复杂无法用作决定性的刑事证据。
同样的想法适用于内部纪律和合同终止。即使没有定罪，如果机构终止关系、扣留工资或基于不可靠的系统数据公开怀疑，分局局长或承包商也可能被毁。高利害行政决定需要自己的技术挑战过程。
Horizon 变得灾难性的部分原因是不同的问责渠道重复了相同的信心。未来的系统应该做相反的事：每次升级都应重新以更强的审查打开技术问题。
证据管理应在领导层变更后生存
长期丑闻会超越高管、部长、供应商经理、律师和 IT 团队。因此，证据管理必须在领导层变更后生存。缺陷记录、支持工单、审计日志、董事会文件、专家报告和索赔人通信应根据法律和道德保留计划进行保存，而不是留给部门习惯。
这一点很重要，因为延迟问责常常依赖于旧记录。索赔人可能多年后需要证据。法院可能重新审视定罪。调查可能问谁在什么时候知道什么。替代项目可能需要知道哪些缺陷伤害了用户。如果记录消失，延迟再次有利于控制证据的机构。
供应商合同应包括终止后的证据义务。当供应商被替换时，它仍应保存并提供与索赔、调查和法律审查相关的记录。公共机构不应因为商业关系结束而失去对证据的访问。供应商也不应能将历史缺陷知识视为无关，一旦合同转移。
证据管理还需要元数据：谁创建了记录、何时、涉及哪个系统版本、影响哪个分支或索赔人，以及是否经过审查。一堆文件不等于可用证据。被 Horizon 伤害的人们需要可用证据，而非只有内部人员才能解读的机构档案。
这就是为什么预防和补救在记录设计中相遇。一个记录缺陷良好的系统可以防止不安全的指控。如果预防失败，相同的记录可以支持更快的赔偿。糟糕的记录失败两次：第一次在伤害发生时，第二次在修复延迟时。
问责应被设计进下一个系统
Fujitsu 的最终教训是，问责不能在公众愤怒回来之后才被附加到替代系统上。质疑权、审计可见性、缺陷披露、远程访问日志、专家证据标准和赔偿证据保存应从一开始就作为设计要求。一个重复旧证据不对称的新平台将在现代化界面的同时保留成本转移风险。
问责测试是预防先于补救
Horizon 之后的问责问题不仅仅是支付了多少补救或哪些高管道歉了。而在于机构现在是否有一条预防规则：不要使用数字系统将成本、嫌疑或法律负担转移到个人身上，除非系统的可靠性、缺陷、访问路径和审计限制可以被独立质疑。
公共记录并未将责任仅归于 Fujitsu。Post Office、政府、律师、审计师、检察官和赔偿管理人都曾或正在扮演角色。Fujitsu 的角色仍然重要，因为供应商可能持有决定系统证据是否安全的技术知识。当这些知识不被使用时，系统之外的人承担风险。
对于 Fujitsu 和其他供应商，教训是将证据系统视为公共利益系统，当它们可能伤害个人时。缺陷记录、审计追踪、远程访问日志、专家陈述和不确定性语言应作为产品安全记录的一部分进行管理。用于指控的系统不是普通的后台工具。
对于公共机构，教训是将独立技术挑战内建于流程中。不要让专有系统成为不可质疑的证人。不要假设数字输出是中性的。不要让赔偿设计将证明负担转移回已受伤害的人。不要等到电视连续剧或多年的诉讼才让系统缺陷可见。
对于受自动化或半自动化系统影响的个人，教训是严酷但重要的：要求日志、缺陷历史、访问记录、替代解释和举证责任规则。系统输出只有在可以被检验时才是证据。
Horizon 应被记住为一个成本转移丑闻，因为正是这一点使得技术失败如此具有破坏性。软件不确定性变成了个人债务、刑事嫌疑和延迟修复。负责任的未来不仅仅是更好的软件。它是一个规则：机构必须证明系统，然后才能让人付出代价。