10.5 伦理、问责制与公共利益

概述与动机

软件不再是隐藏在人类决策背后的中立工具。它越来越多地就是决策本身。它决定谁能获得贷款、招聘人员会看到哪份简历、一笔福利申请要花多久处理、一个欺诈标记是否会冻结一个账户，以及什么信息会送达数百万人。当软件做出或塑造影响人们权利、财产、安全和尊严的决策时，构建它的工程师和组织所承担的责任，就超出了正确性和性能的范畴。本章正是关于这些责任：职业道德、对系统行为的问责、把无障碍性和公平当作义务而非特性、算法透明度、可持续性，以及以公平和尊严对待人们的责任。

对大型组织而言，规模和权力放大了风险。一个企业或政府系统影响的不是一个人，而是数百万人。一个单一的设计选择（一个有偏见的训练集、一份无法访问的表单、一次不透明的自动拒绝）会在每一个人身上重复发生。政府承担着更重的责任，因为它们的系统不是可选的。公民无法为自己的税务机关或福利机构另选一家竞争对手。国家在某些服务上的垄断地位意味着，一个建得糟糕的系统可能会剥夺人们本无其他途径行使的权利。伴随这种影响力而来的，是相应的公平、透明和问责的责任。

软件中的伦理问题常常被当作一个软性话题，在最后才被追加进来，或者被丢给一份法律合规清单去处理。本章持相反的立场。伦理考量是工程需求。问责必须被设计进系统，而不是事后再声称拥有。而以尊严对待人们，既是一种道德责任，长期来看也是大型组织所依赖的信任的根基。

关键原则

软件在做决策，因此其创造者要承担责任。 你要为你的系统对人们做了什么负责，而不仅仅是它是否符合规格说明。
无障碍性和公平是义务，不是增值功能。 把人排除在外是一个缺陷，而且常常是法律和道德上的失职。
有重大后果的自动化决策需要问责。 受自动化决策影响的人理应获得解释、救济途径和人工复核。
透明是默认状态，保密才是例外。 尤其是在公共部门，人们有权理解关于自己的决策是如何做出的。
公平性必须被检验，而不能想当然地假设。 系统会继承并放大其数据和设计中的偏见，除非你刻意去检查。
尊严是一项设计要求。 把每一位用户，包括弱势群体和非典型用户，当作一个值得尊重的人来对待。
可持续性和社会影响很重要。 软件的能源、资源消耗及其社会影响，都是其真实成本的一部分。

建议

采纳并践行职业道德

让组织立足于一套公认的职业行为准则，并使其真实存在，而非装饰门面。工程师应当理解，他们对公众负有责任，而不仅仅是对雇主。当一个系统伤害了人们时，“我只是照着规格说明做的”不能成为辩护理由。创建真正的渠道来提出伦理方面的担忧：一种能说出“我们不应该构建这个，或者不应该以这种方式构建它”而不需要以断送职业生涯为代价的勇气的方式。给团队提供衡量后果的词汇和立场。用把伦理异议当作有价值信号、而非阻碍的领导层来支撑这一切。伦理培训只有在组织切实按照所教的内容行事时，才会有帮助。

把无障碍性和公平当作义务

从一开始就为全体人类能力和处境的范围而构建。事后补上无障碍性的成本要高得多，效果通常也更差。遵循既有的无障碍标准（例如 WCAG，即网页内容无障碍指南），并在许多司法辖区满足对公共服务强制要求这些标准的法律规定。用辅助技术测试，更重要的是要与真正有残障的真实用户一起测试。把公平的范围从残障问题延伸到你所服务的全体人群：带宽较低的人、使用老旧设备的人、数字素养有限的人、使用少数语言的人，以及处于艰难生活境遇中的人。对于人们无法选择退出的服务（尤其是政府服务），只为那些自信、联网良好、典型的用户而设计，是一种服务上的失职，而不是一种合理的默认做法。

构建算法问责制和公共透明度

对任何做出或实质性塑造关于人们的重大决策的系统，要把问责设计进去。对于高风险决策，要让人类有意义地保持在环（in the loop），而不是盲目服从自动化输出。要能够用受影响者能够理解的方式，解释一项决策为何做出。提供一条真正能够质疑它并联系到人工的途径。在部署前和部署期间，针对受保护群体和弱势群体测试系统的偏见和差异化影响，并持续监测其随时间的漂移。在公共部门，通过诸如算法登记册这样的机制，公开算法系统的工作方式（其目的、数据和在适当层面上的逻辑），使公民和监督机构能够审视它们。记录预期用途和已知局限，以免系统被应用于不该应用的场合。

为公平、尊严和救济而设计

审视你的系统，找出它们可能不公平或不尊重地对待人们的方式。仔细审查训练数据和规则中隐含的偏见。要记住，一个纯粹为效率而优化的系统可能是残酷的：一个为了将漏判率降到最低而调优的欺诈过滤器，可能会冻结数千名无辜者的账户，而每一个都是一个正身处困境的真实的人。从受影响者的角度出发，为失败情形而设计。当系统出错时会发生什么？他们能多容易地联系到人工、获得解释和得到补救？以尊重和克制的方式处理个人数据：只收集所需的内容，并诚实地说明其用途。把错误、延迟和拒绝，不当作边缘情形，而当作尊严最受威胁的时刻来对待。

考量可持续性和社会责任

要认识到软件有物理和社会成本。数据中心、训练运行和低效的系统会消耗真实的能源。效率既是一种环境美德，也是一种财务美德。考虑你所构建的东西更广泛的影响（对劳动力、对公共话语、对弱势群体），并愿意在危害超过益处时拒绝或重塑某项工作。对于那些其系统在大规模上塑造社会的大型组织而言，社会责任不是业务之外的慈善行为。它是负责任地构建的一部分，并且越来越成为监管和公众期望的事项。

权衡取舍：利与弊

张力	一方	另一方
自动化 vs. 人类判断	规模、一致性、速度、更低成本	问责、细致入微、宽容、救济途径
透明度 vs. 保护	公众监督、信任、监督机制	被利用的风险、安全性、数据隐私
无障碍投入 vs. 速度	服务所有人；符合法律和道德要求	初期交付更慢；需要更多设计投入
效率 vs. 公平	优化的结果；更低成本	对尾部个体造成残酷对待的风险
数据驱动的个性化 vs. 隐私	更好的服务；量身定制的体验	监控风险；尊严和同意方面的顾虑
创新速度 vs. 审慎	更快创造价值；竞争优势	未经审视的危害被大规模部署

最艰难的权衡是规模与个体正义之间的取舍。自动化在数百万人身上带来一致性和效率。但它的错误也会以同样的规模被交付，一个为整体聚合结果而优化的系统，可能对其尾部的个体悄然施以残酷对待。答案不是放弃自动化。而是要为个体失败情形而设计：在高风险之处保持人类在环、保证解释和救济途径，并衡量系统对服务最差群体的影响，而不仅仅是对平均水平的影响。透明度同样存在真实的张力，因为完全的公开可能助长钻空子的行为，并暴露私密数据。但在公共服务中，答案强烈倾向于默认披露，只对那些真正必须保护的内容予以豁免，而不是把不透明当作安全的默认选项。

与团队讨论的问题

你们哪些系统做出或实质性塑造了关于人们的重大决策？今天，它们中的每一个是否都提供了解释、人工复核和救济途径？ 软件越来越就是决策本身：谁能获得贷款、哪份简历被看到、一个账户是否被冻结、一笔申请要花多久处理。对于每一个这样的系统，受影响的人理应获得一份他们能理解的解释、一条真正能质疑它的途径，以及一个能够介入的人，而在企业或政府的规模下，一个设计缺陷会在数百万人身上重复出现。带上证据：盘点你们所有有重大后果的自动化决策，并针对每一个检查，一个被错误对待的人是否真的能联系到人工并获得通俗易懂的理由。如果答案是否定的，那是一个需要修复的缺陷，而不是一个可以以后再加的功能。对于人们无法选择退出的服务，尤其是政府服务而言，这是一项义务，而不是锦上添花之举。
你们是否把无障碍性当作一项以真实残障用户测试、能阻断发布的硬性要求？你们目前正在辜负哪些人？ 无障碍性和公平是义务，把人排除在外是一个缺陷，常常是法律和道德上的失职，然而事后补上无障碍性可靠地会比从第一个界面就设计进去更慢、更贵、效果也更差。遵循 WCAG，并超越自动化检查，与辅助技术和真正有残障的真实用户一起测试，同时也要测试带宽较低者、使用老旧设备者、使用少数语言者，以及数字素养有限者。带上证据：用屏幕阅读器和在受限网速下走一遍你最重要的流程，看看哪里出了问题。这个答案应该决定无障碍性是一道会阻断发布的关卡，还是一项永远排不上优先级的待办事项，而对于人们无法选择退出的服务而言，只有前者才站得住脚。只为那些自信、联网良好、典型的用户而设计，是一种服务上的失职。
在部署前和部署期间，你们测试重大决策系统是否存在偏见和差异化影响的常规流程是什么？ 系统会继承并放大其数据和设计中的偏见，除非你刻意去检查，而仅仅因为没有人有意造成不公平就假设系统是公平的，本身就是一种疏忽造成的偏见。一个纯粹为将漏判率最小化而调优的欺诈过滤器，可能会冻结数千个无辜账户，每一个都是一个正身处困境的真实的人，因此在不顾公平性的情况下优化效率，可能是悄然残酷的。带上证据：对每一个影响人们的模型，展示其在受保护群体和弱势群体中的差异化影响测试结果、已记录的数据和已知局限，以及随人群变化而重新测试的漂移监测机制。这个答案应当让偏见测试成为常规且持续的工作，而不是发布前一次性打勾的检查项，并且应当改变你的优化目标，使其权衡对个体的伤害，而不仅仅是聚合准确率。要从受影响者的角度出发，为失败情形而设计。
当一位工程师认为你们不应该构建某样东西，或不应该以这种方式构建它时，这个异议实际上会发生什么？ 只有当“我们不应该发布这个”是一个人可以说出口而不因此断送职业生涯的句子时，伦理才会变得真实，而在规模化场景下，最接近某项危害的人往往是房间里最资浅的人。与之相竞争的压力是交付进度：提出的异议会拖慢路线图，而在截止日期压力下的领导者可能把它当作阻碍而非有价值的信号。带上证据：说出工程师实际会使用的确切渠道、清点过去一年提出了多少担忧，并追溯由此改变了什么，因为一个从未阻止或重塑过任何工作的渠道只是摆设。对企业或政府机构而言，把这个渠道与一位指定的负责人和一份记录在案的评审绑定，因为一个没有人有义务倾听的异议，就是一个没有人愿意冒险提出的异议，而随后危害首先会以公开丑闻的形式浮现。
你们是否清楚自己所运行的东西的环境和社会成本？如果某项工作的危害超过其益处，你们是否愿意重塑或拒绝它？ 软件有物理和社会成本：数据中心、训练运行和低效系统消耗真实的能源，而对劳动力、公共话语和弱势群体的次生影响，是一个系统真实成本的一部分。这里的张力在于，衡量和削减这些成本与功能开发速度相竞争，而拒绝有害的工作则意味着放弃某个人要为之负责的收入。带上证据：你们最大系统的能耗或算力足迹、一份关于谁承担下游影响的坦诚判断，以及至少一个你们基于这些理由重塑或拒绝了某项工作的具体案例。在企业或政府规模上，当你们的系统在塑造社会时，把这当作负责任地构建的一部分，并且越来越成为监管和公众期望的事项，而不是附加在业务旁边的慈善行为。
一个外部人士实际能了解到多少关于你们重大系统如何做出决策的信息？披露是你们的默认做法还是例外情形？ 透明度是公众信任赢得或失去的地方，因为人们有权理解关于自己的决策是如何做出的，而在公共部门，这项权利常常就是法律。真正的反向压力在于，完全的公开可能助长钻空子的行为并暴露私密数据，所以真正的问题不是是否披露，而是界限划在哪里。带上证据：对每一个重大系统，展示你们公开了什么（其目的、数据和在适当层面上的逻辑）、隐瞒了什么以及具体原因，以及是否在任何技术性描述旁边都配有一份通俗易懂的说明。对政府机构而言，权衡诸如算法登记册这样的机制与那些狭窄、站得住脚的豁免之间的关系，并检查你们的披露是否真正做到了解释，而不是技术上提供了信息却对受影响者什么都没说清楚。

行业视角

初创企业。 团队只有寥寥数人、跑道也短，你无法为一个伦理委员会配备人手，所以要把低成本、高杠杆的习惯直接嵌入产品本身：每一次自动拒绝都附上通俗易懂的理由、一条一键联系人工的途径，以及从第一个界面起就做到无障碍，因为之后再补上会更慢、效果也更差。找出你软件中做出关于某个人的重大决策的那一个环节，并在把危害规模化之前，就在那里把解释和救济途径做对。把公平和尊严当作发布的硬性要求，而不是之后才打磨的细节，现在成本很低，却能避免早期就承受不起的声誉损失。

小型企业。 你很可能没有无障碍性或公平性方面的专家，预算也很紧张，所以要依靠你所购买工具中内置的伦理保障：选择符合 WCAG 标准的供应商，让他们记录清楚自己的自动化功能是如何决策的，并让你能够保持人类在环。把你自己的责任定位为一个数据卫生和尊严问题：清楚你持有哪些个人数据、只收集你所需要的，并确保一个错误的自动化答复不会让客户陷入无法联系到你的困境。在签约之前，要求供应商展示他们在无障碍性和偏见方面的立场，而不是等到收到投诉后才发现这个缺口。

企业。 在规模化场景下，问题在于跨众多团队的治理：一套关于什么算作重大决策的共享标准、一致的无障碍性和偏见测试关卡，以及一条能证明解释、人工复核和救济途径在必要之处确实存在的审计轨迹。建立一个能阻断发布的伦理评审，而不是一个什么都改变不了的培训，为无障碍性和差异化影响方面的工作明确编列预算，并监测已部署模型的漂移，使公平性成为一项持续的工作，而不是一次性的检查项。把一个单一的设计缺陷当作会在数百万人身上重复出现的问题来对待，因为在你的影响力范围内，它确实会如此。

政府。 采购规则、透明度义务和公共问责制塑造着每一个选择，而公民无法通过转向竞争对手来选择退出你们的服务。通过诸如算法登记册这样的机制公开重大系统的工作方式，以合同形式要求供应商披露其数据实践和已知局限，并按照与残障用户、低带宽连接和少数语言使用者一起测试过的无障碍标准来构建每一项公共服务。为每一个重大自动化决策保证人工复核的权利和一份通俗易懂的解释，并把那些必须由负责任官员做出的最终裁定完全排除在全自动化之外。

示例

初创企业。 一家三人规模、正在构建自动化放贷功能的金融科技初创公司，决定把公平和尊严当作硬性要求，而不是之后再打磨的细节。在发布前，他们针对能够衡量到的各个群体测试模型的差异化影响，写下模型所使用的数据以及不应信赖它的场合，并确保每一位被拒的申请人都能获得一份通俗易懂的理由和一条一键联系创始人本人的途径。他们从第一个界面起就按照无障碍标准构建注册流程，因为之后再补上会更慢、效果也更差，他们还增设了一条快速的人工干预渠道，使一个被错误冻结的账户能在几分钟内解冻，而不是让一个真实的人陷入困境。

企业。 一家部署自动化信贷决策的银行，把公平当作一项工程要求来对待。在发布前，它针对受保护群体测试模型的差异化影响，记录数据及其局限，并构建了一套解释机制，使每一位被拒的申请人都能获得一个可理解的理由和一条清晰的人工复核途径。一个监测流程持续关注漂移，并随人群变化重新测试偏见。当欺诈检测系统开始冻结大量合法账户时，银行增设了一条快速的人工复核渠道，并改变了其优化目标，以权衡对客户的伤害。它把被错误标记的客户所承受的困扰，当作一项真实的成本来对待，而不是一个可以接受的统计数字。

政府。 一个市政府发布了一份算法登记册。它列出了该市在公共服务中使用的自动化系统，并描述了每个系统的目的、所依赖的数据，以及决策可以如何被质疑。该市的数字服务按照无障碍标准构建，并与残障用户、低带宽连接和少数语言使用者一起测试，其原则是：一项人们无法选择退出的服务，必须对所有人都行得通。每一个重大自动化决策都附带人工复核的权利和一份通俗易懂的解释，因此当国家的软件决定公民生活中的某件事时，公民既保有尊严，也保有救济途径。

商业理由：动机、投资回报率与总拥有成本

伦理和问责的商业理由建立在信任、风险和影响范围之上。信任是持久的资产。系统公平、透明地对待人们的组织，能赢得人们愿意使用它们的信心，而公共机构尤其依赖一种合法性，这种合法性可能因一个引起广泛关注的不公平系统而被瞬间摧毁。风险是近期的驱动因素。存在偏见、无法访问或不透明的系统，越来越多地伴随着监管处罚、诉讼和声誉损害，其代价可能远超负责任地构建系统的成本。而影响范围则放大了这两者。在企业或政府规模上，一次伦理上的失职会在数百万人身上重复发生，并成为头条新闻。

采纳这些做法的成本是实实在在的。无障碍性工作、偏见测试、解释和救济机制、人在环复核，以及考量后果所需的设计时间，都会增加工作量，尤其是在早期阶段。而不采纳这些做法的成本更大，且越来越不是可选项：歧视责任、把你有义务服务的一大部分人群排除在外、发布后再补上无障碍性和问责机制的开销，以及一旦失去就代价高昂、难以重建的信任侵蚀。当你向领导层说明理由时，要把伦理定位为风险管理和信任建设，而非利他主义。指出围绕算法问责制和无障碍性的监管环境正在收紧。强调总拥有成本：从一开始就负责任地构建，远比事后修复一个已经在大规模上伤害了人们的系统要便宜得多。对公共机构而言，加上最朴素的论据：公平地服务公民就是使命本身，而不是对使命的约束。

反模式与陷阱

把伦理当作打勾清单。 一次性的评审或培训，对系统实际的构建方式毫无改变。
事后补上无障碍性。 把无障碍性当作后期附加项，产出的结果比一开始就设计进去更差、成本更高。
不受问责的算法。 有重大后果的自动化决策，没有解释、没有人工复核，也没有质疑的途径。
优化出残酷。 纯粹为聚合效率而调优，直到系统悄然地残酷对待其尾部的人群。
疏忽造成的偏见。 仅仅因为没有人有意造成不公平就假设系统是公平的，从未对其进行过测试。
“电脑说不行。” 一线员工和用户即便看出一个自动化决策明显有误，也无力推翻或质疑它。
只为自信的用户设计。 只为典型、联网良好、有阅读能力的用户构建，把其他所有人排除在外，这对于人们无法选择退出的服务而言是站不住脚的。
透明度作秀。 发布让人看不懂的披露信息，技术上提供了信息，实际上什么都没有真正解释清楚。

成熟度模型

第 1 级：启动（Initiate）。 伦理问题无人问津，或只有在丑闻发生后才被动应对。无障碍性被忽视或做得极其有限。自动化决策不透明，没有解释，也没有救济途径。偏见从未被测试，可持续性和社会影响也未被考虑。

第 2 级：发展（Develop）。 存在一份行为准则，一些无障碍标准得到遵循，但往往为时已晚。备受关注的自动化决策得到一些人工监督，但大多数没有。偏见偶尔会被检查，可以通过一个薄弱的流程提出担忧，而各团队之间的实践差异很大。

第 3 级：标准化（Standardize）。 伦理评审是开发流程中有文档记录的一部分，并在整个组织中得到强制执行。无障碍性被设计进产品，并与真实用户一起测试。有重大后果的自动化决策默认附带解释、人工复核和救济途径。偏见测试和漂移监测是常规工作，公共部门系统公开其工作方式，可持续性按统一标准进行衡量。

第 4 级：管理（Manage）。 组织用数据对照基准来衡量和控制自身的伦理状况：无障碍性符合度得分、随时间追踪的受保护群体差异化影响指标、被质疑决策的救济率和触达人工的时间、附带公开文档的重大系统占比，以及主要系统的能耗或算力足迹。指标充当发布的关卡，超出阈值会触发调查，领导层按固定节奏审视这些数字，而不是想当然地认为相关实践正在被遵循。

第 5 级：协同（Orchestrate）。 责任被融入组织构建和适应的方式之中。无障碍性和公平是不容商榷的默认设置，并针对所服务的全体人群进行验证，算法问责制（透明度、公平性测试、救济途径、人工监督）是标准做法并被持续监测，伦理方面的担忧被视为有价值的信号，能够重塑甚至叫停工作。组织把信任、公平和尊严当作其使命的核心，把伦理与产品、风险和采购决策整合在一起，并随着期望和证据的演变而重新界定系统范围或将其退役。

讨论要点

哪些决策可以完全自动化，哪些必须保持人类有意义地在环，二者的界线在哪里？
多少程度的算法透明度才算足够？你如何在不助长钻空子、不侵犯隐私的前提下做出有意义的披露？
当一个自动化系统伤害了某人时，谁来负责：工程师、经理、组织，还是供应商？
你如何让提出伦理异议真正变得安全，而不是限制职业发展？
一个组织对那些它未曾为其设计的用户负有什么义务？公平应该延伸到多远？
计算的环境成本应该如何纳入架构和产品决策的考量？

关键要点

当软件对人们做出有重大后果的决策时，其创造者要为它的所作所为负责，而不仅仅是它是否符合规格说明。
无障碍性和公平是义务，缺失时就是缺陷，而不是可选的增值功能，对于人们无法选择退出的服务尤其如此。
有重大后果的自动化决策需要解释、人工复核、救济途径和持续的偏见测试；要把问责设计进系统，而不是事后再声称拥有。
在不顾公平性的情况下优化效率，可能是悄然残酷的；要为个体失败情形而设计，而不仅仅是为聚合结果。
在公共部门，关于算法系统如何运作的透明度应当是默认做法，保密只应是狭窄的例外。
商业理由在于信任与风险：从一开始就负责任地构建，远比事后大规模修复危害要便宜得多，而对公共机构而言，公平就是使命本身。

参考文献与延伸阅读

ACM/IEEE-CS, Software Engineering Code of Ethics and Professional Practice
ACM, Code of Ethics and Professional Conduct
Cathy O’Neil, Weapons of Math Destruction
Virginia Eubanks, Automating Inequality
Safiya Umoja Noble, Algorithms of Oppression
Ruha Benjamin, Race After Technology
Batya Friedman and David G. Hendry, Value Sensitive Design
World Wide Web Consortium (W3C), Web Content Accessibility Guidelines (WCAG)
NIST, AI Risk Management Framework
OECD, Principles on Artificial Intelligence
European Union, General Data Protection Regulation (GDPR) and the AI Act
UK Government, Data Ethics Framework and the Algorithmic Transparency Recording Standard