AI 问责清单：来自 Timnit Gebru 的经验教训

在准备发布时，AI 问责为何重要

过去构建 AI 功能主要是个技术问题：我们能让模型工作吗？现在更难的问题是你是否应该部署它，以及需要设置哪些限制。

一旦真实用户依赖 AI 输出，小问题就会变成真实成本：错误决策、被误导的客户、隐私泄露或不公平对待。

AI 问责不是一种氛围或承诺。它是书面的文档加上明确的决策和负责人。如果你不能指出使用了哪些数据、系统做不到什么、以及失败时你会怎么做，你就没有问责，只有希望。

这点在发布前尤为重要，因为那时很容易把文档当成可选项。没有文档就发布会在之后制造昂贵的意外：无法回答的支持工单、愤怒的用户、产品回滚以及内部相互指责。

一个简单的问责清单能迫使团队给出具体答案：

• 该功能用了哪些数据，已知有哪些缺口？
• 意图用途是什么，明确不支持哪些场景？
• 可能会犯哪些错误，谁会因此受害？
• 有哪些保护措施（人工审核、回退、监控）？

目标不是理论上的讨论，而是把基础（数据、限制、风险）写下来，然后做出一个你以后能够为之辩护的决定，即使你需要快速推进。

Timnit Gebru 在一页内：她的工作带来了哪些变化

Timnit Gebru 是 AI 问责领域最被引用的声音之一，因为她推动了一个许多团队跳过的简单想法：问“我们能建吗？”不够，你还要问“我们应该部署吗？谁会受伤？我们怎么知道？”

这一转变的重要部分是让 AI 系统对其他人可读。不仅仅是对训练模型的工程师，而是对审阅者、产品经理、支持团队和用户。目的是把系统要做的事、塑造它的数据、它在哪里失败以及在真实环境中风险如何等写清楚。

两个实用的产物因此流行起来，因为它们让这种可读性变得具体：

• 数据集说明（通常称为 datasheets for datasets）：说明数据是什么、来源、谁被代表或缺失、以及不应把数据用于哪些场景。\n- 模型说明（通常称为 model cards）：说明模型的用途、如何测试、已知限制以及应该预期哪类错误。

对产品团队来说，这并不是为写而写的文案。文档是证据。当有人问“我们为什么发这个功能？”或“为什么你没发现这个失败模式？”时，你需要能指出：你测了什么、你选择不支持什么、你加了哪些保护。

一个具体例子：如果你在客服工具里加了一个 AI 摘要按钮，模型说明里应该写清它是否在敏感主题上经过测试、它如何处理不确定性以及人工复核步骤是什么。这样模糊的担忧就变成了可以辩护和改进的明确决策。

什么算 AI 功能以及可能出什么问题

AI 功能是指产品中任何模型输出可能改变人们看到的内容、能做的事或被如何对待的部分。如果输出会影响决策，即便影响很小，也要把它当作真正的功能来处理并意识到它的后果。

常见类型包括摘要、排序、推荐、内容审核和评分（风险、欺诈、质量、资格、优先级）。

当出问题时，影响可能超出点击按钮的那个人。可能受害的人包括最终用户、非用户（被提及或被画像的人）、支持人员与审核者、合同工和审阅者，以及其数据被用于训练或评估的相关数据主体。

把错误和伤害分开考虑很有帮助。错误是模型出错：糟糕的摘要、误报或不相关的推荐。伤害是该错误在现实世界中造成的后果：金钱损失、不公平的获取、名誉受损或安全风险。例如，客服助手虚构退款政策是一个错误。伤害是客户基于它作出购买决定却被拒绝，或支持人员因此处理大量愤怒的工单。

伤害往往在不同群体和情境中不均等。一个审核模型对大多数用户“运行良好”，但可能反复误判某个社区的俚语或方言，导致该社区的内容更多被删除。一个排序模型可能会掩盖小卖家，除非他们符合大型品牌常见的模式。

如果你通过像 Koder.ai 这样的聊天驱动构建器构建 AI 功能，速度是真的快，但问责工作保持不变。你仍然需要明确模型可能在哪里失败，以及失败时谁为此买单。

发布前你应该具备的最少文档

在你发布 AI 功能之前，需要一套小而完整的文档来回答一个问题：我们构建了什么，面向谁，会出什么问题？保持简短，但让每一点都可检验。

发布前应书面化的最小集合：

• 目的和用户：功能用途、谁会使用、谁不该使用。包括它帮助（或取代）的决策。\n- 数据和来源：训练或微调用了哪些数据、运行时读取哪些数据、以及你会存储哪些数据。注意敏感字段和同意假设。\n- 已知限制：它在哪里失败、不能知道的事以及常混淆的内容。附上几个你已见到的糟糕输出示例。\n- 用户伤害风险：现实中人们可能被误导、被排除或被暴露（隐私、偏见、不安全建议、过度信任）。\n- 监控与响应计划：发布后你将测量什么、谁会收到告警以及什么会触发回滚或功能锁定。

“已文档化”并不等于“被理解”。没人看的文档只是个文件。找一个不在构建团队内的人读并用朴素语言签署：“我理解这些限制和用户影响。”如果他们不能复述给你听，你还没准备好。

指定一个人负责保持文档更新（通常是该功能的产品负责人，而不是法务）。设定节奏（每次发布或每月更新），以及在任何事故后必须立即更新。

语气要诚实具体。避免使用“高准确率”这样的模糊表述，除非你说明了测试集、指标以及未修复的失败案例。

数据文档：记录什么以及需要多详细

好的数据说明有两个目的：帮助你在用户发现问题前预测失败，并给未来的团队成员一个清晰的理由去信任（或停止信任）系统。

把细节控制在“足以在 10 分钟内回答困难问题”的水平。你不是在写论文，而是在把某人在 bug 报告、隐私审查或客户抱怨时需要的事实写下来。

从一个简单的数据清单开始。对每个数据集（包括日志、反馈、第三方来源）记录来源与控制方、采集时间与更新频率、支持的产品行为、适用的同意与隐私边界，以及如何标注或清洗。

代表性（representativeness）需要单独一行说明。点名缺失的内容：地区、语言、设备、无障碍需求、用户类型或边缘情形。用直白的语言写，例如“主要是美国英语移动用户”或“来自小型企业的示例很少”。

如果使用人工标注，记录标注者背景（专家或众包）、他们看到的指引以及分歧发生在哪里。分歧不是要隐藏的缺陷，而是设计时需要注意的预警信号。

限制文档：把边界写清楚

限制文档是你从“在演示中工作”过渡到“这里是这个功能可以安全处理的范围”的地方。如果你只写顺利路径，用户就会替你去发现边界。

先用一句话说明模型的工作，然后写明它不适合做什么。“为常见问题起草简短回复”与“决定退款”或“检测欺诈”是完全不同的事情。这个界定会让后续决策（UI 文案、升级规则、支持培训）变得更容易。

以通俗语言捕捉已知的失败模式。一个好的限制部分通常涵盖：哪些输入会让它困惑（模糊请求、缺失上下文、混合语言）、它会误读的语气（讽刺、玩笑、愤怒）、在少数情况下做得不好的点（小众术语、罕见产品）以及能被蓄意破坏的方式（提示注入、诱导泄露私密数据）。

包括会影响用户体验和安全的运行约束。写下延迟目标、成本上限以及达到这些限制时会发生什么（超时、答案更短、重试次数减少）。注明上下文窗口限制（可能会忘记早先消息）以及依赖变化（更换 LLM 提供商或升级模型会改变表现）。

然后写出一条可复用的警告：

"AI 生成的回答可能不完整或错误。不要将其用于法律、医疗或财务决策。如果涉及计费、退款或账户访问，请联系客服。"

每次模型、提示或策略变更时都要更新这条说明。

用户伤害评估：把担忧变成书面的风险图谱

伤害评估不是抽象伦理辩论，而是一份简短的文档，说明：如果该功能出错，谁会受伤、如何受伤，以及我们在发布前后会做什么。

先用大类把范围盖住，避免漏项：安全、歧视、隐私、欺骗和可靠性。

然后把每种伤害写成真实的情景。每个类别写一到两个具体故事：谁是用户、他们问了什么、模型可能输出什么、用户可能根据输出做出什么行动。关键是行为链：错误答案令人恼火，但导致医疗决策、资金转移或政策改变的错误后果要严重得多。

为了优先排序，使用简单量表。对每个场景标注严重性（低、中、高）和可能性（低、中、高）。你不需要精确数字，只需要对哪些值得现在投入资源形成共同看法。

最后，指定负责人。没有负责人名字的缓解不是缓解。对每个场景写清发布前的缓解（护栏、UX 警示、屏蔽话题、日志记录）、发布后的缓解（支持手册、监控、回滚触发条件）以及谁负责。

步骤分解：如何把 AI 功能从原型关卡到发布

Gating（设置关卡）是把“我们能建”变成“我们应该发”的过程。把它当作一系列出口：在基础工作写清、审阅、测试前，你别通过下一关。

1. 写明意图和它会影响的决策。 指明谁使用、他们在做什么决定以及如果输出错误会发生什么。\n\n2. 及早起草数据与限制说明。 在 UI 美化之前完成，这时功能还容易改造。\n\n3. 在真实、边缘和敏感案例上测试。 用凌乱的文本、俚语、不同行为、长对话和歧义性请求。加入一些高风险案例（账单争议、账户访问、医疗或法律问题），即便功能本不面向这些场景，因为用户会尝试。\n\n4. 加入用户提示、回退和升级路径。 决定当模型拒绝、不确定或表现差时用户会看到什么。提供一个安全的默认（例如“请人工处理”），并让报告糟糕答案变得容易。\n\n5. 定义监控、事故与回滚流程。 选定将监控的信号（投诉、撤销率、被标记的输出），谁会收到告警，以及“停止该功能”看起来是怎样。\n\n如果任何一步让你感到困难，这种摩擦通常正指向风险所在。

团队在 AI 问责上常犯的错误

破坏信任的最快方式是把实验室中的高分当成在真实世界中安全的证明。基准测试有帮助，但不能展示人们会如何推动、误解或依赖一个功能在日常工作中。

另一个常见失败是掩盖不确定性。如果你的系统总是以同样的自信语气输出，用户就会认为它总是正确。哪怕是一个简单的“我不确定”路径或一条简短说明（该答案基于什么），也能避免人们把不稳固的输出当真。

团队还常常只用自己的习惯来测试。内部提示礼貌且可预测。真实用户疲惫、匆忙且富有创造性。他们会粘贴凌乱文本、追问或尝试让模型突破规则。

五种常见错误：

• 把基准或离线评估当成发布决策\n- 强制一个自信答案而非允许“我不知道”或“需要复核”\n- 仅用团队写的提示测试，跳过凌乱的真实用户输入\n- 发布后才写文档并且从不更新\n- 上线但没有回滚路径

一个实用的修正是把问责工作纳入构建流程。在规范里保留清单，并在发布前要求它被完成：你用了哪些数据、它会在哪些场景失败、谁可能受伤、以及出事时你会怎么做。

一个具体例子：如果你在一个应用构建器中部署 AI 助手，使用模糊请求（“做得像 Airbnb”）、冲突需求和敏感内容测试它。然后设定明确的回滚计划（快照、版本控制、快速停用开关），以便用户报告伤害时你能迅速行动。

可复制到规范中的快速清单

把下面内容粘到产品规范中并在发布前填好。保持简短，但让每个答案都具体，并为每个风险指名负责人。

### 1) Purpose and affected people
- Feature name:
- What decision or action does the AI support (one sentence):
- Who uses it:
- Who is affected even if they never use it (customers, employees, bystanders):
- What a “good” outcome looks like:

### 2) Data used (training, tuning, retrieval, logs)
- Data sources (where it came from and why it’s allowed):
- What you excluded (and why):
- Sensitive data involved (PII, health, finance, kids):
- Data retention period and deletion plan:
- Security and access controls:

### 3) Limits and “do not use” zones
- Known failure modes (give 3-5 concrete examples):
- Languages supported and not supported:
- Inputs it should refuse (or route to a human):
- Cases where it must not be used (legal, medical, hiring, etc.):

### 4) User harm assessment
- Top 5 harms (ranked):
- Mitigation for each harm:
- Who owns each mitigation (name + team):
- What you will tell users (warnings, confidence cues, citations):

### 5) Operations after launch
- Monitoring signals (quality, complaints, bias flags, cost spikes):
- Human review path (when and how escalation happens):
- Rollback trigger (exact threshold or condition):
- Snapshot/version you can revert to:

示例：如果该功能起草客户支持回复，列出像“自信但错误的退款政策”这样的伤害，并设定规则：低置信度草稿必须经人工批准后才发送。

示例：记录一款面向客户支持的 AI 助手

支持团队在客户聊天工具中添加了一个 AI 回复助手。助手起草回复、建议下一步并拉取当前工单的上下文。上线前，他们写了一份符合清单的短文档：系统能看到什么、可能出错的地方以及谁会受伤。

数据说明（它从哪些数据中学习 vs 现在能看到什么）

他们区分了两类来源。第一类是训练或微调数据（过去的支持工单、内部帮助文档、产品政策）。第二类是实时上下文（客户消息、账户计划、订单状态以及代理控制台中显示的任何备注）。

他们为每种来源写下隐私预期。旧工单可能包含地址或付款问题，所以他们定义了规则：训练前脱敏敏感字段、避免长时间存储完整聊天记录，并只记录调试错误所需的最少信息。

限制（把边界写清楚）

他们用明白的话列出薄弱点：模型可能虚构政策、镜像客户的愤怒语气、误判讽刺或在不常见语言中表现不佳。还决定如何展示不确定性，例如添加“草稿回复，需复核”标签，以免坐席把它当成事实。

他们还添加了一条规则：助手必须引用所使用的内部文档或政策片段，或者显示“我无法找到来源”。

他们映射了可能的伤害：客户可能被虚构的退款规则误导、私人信息可能泄露到回复中、偏见语言可能导致不公平对待。

缓解措施以具体闸门的形式写进规范：

• 明确标注回复为草稿并要求坐席批准后发送\n- 高风险话题（退款、法律、安全、医疗）需要人工复核\n- 阻止助手请求或重复敏感数据\n- 把人工编辑和投诉记录为反馈信号\n- 快速回滚计划（例如使用快照并在平台支持时回滚）

这把“我们应该部署吗？”变成团队可以在客户感受到伤害前测试的书面检查项。

后续步骤：把问责变成习惯，而非一次性任务

只有当问责改变了你在发布日的做法以及出事后的处理方式时，它才起作用。你的文档应该以明确决策结尾，而不是装满好意的文件夹。

把文档翻译成三种可能的结果之一：

• 发布（Ship）：功能达成目标、风险已被理解、控制措施有效。\n- 有条件发布（Ship with limits）：限制谁能使用、能做什么以及如何展示结果。\n- 暂不发布（Do not ship yet）：数据不足、失败代价过大或无法充分解释其行为。

为了可重复执行，设定一个轻量的审查仪式：一名产品负责人、一名工程师和一名能代表用户的人（支持、研究或运营）。他们应当针对相同的几项内容签字：数据来源说明、已知限制、可能的伤害以及模型出错时的应对措施。

发布后，把问责当成运维工作。选一个节奏（每周或每次发布），并把更新常态化。

• 做一次简短的失败演练，测试明显的坏输入并记录用户看到的内容。\n- 在自然出现的位置收集反馈（支持工单、赞踩、内部 QA 记录）。\n- 用通俗语言记录事件：发生了什么、谁受影响、你做了哪些改变。\n- 同时更新文档和产品，这样下一个团队成员就不会重复同样的错误。

如果你快速原型，也要保持相同的纪律。能快速移动的工具同样可以支持良好的闸门。例如，如果你在 Koder.ai (koder.ai) 中构建，使用 planning 模式提前定义边界，并把快照与回滚作为你的安全计划的一部分，而不仅仅是一个便利功能。