本节，我们会从3个真实的事故，看懂企业AI的第一道生死线

目标：先拆掉Demo幻觉，建立AI体系交付视角

一句话总结：如果一个AI系统只能在受控样例里回答正确问题，却不能解释依据约束动作、处理失败和明确责任边界，那么他仍旧是demo，不是生产系统

现实冲突

很多团队看见demo能跑，就默认后面只是工程化细节；但是，真实企业环境里一旦进入更新，权限，PII（个人可识别信息），工具动作，监管和责任追溯，系统面对的是完全不同的世界。

我们这节课要先问：

• 事故最先从哪一层开始？

• 为什么demo阶段就没有暴露？

• 如果你是架构师，第一反应应该补哪一层？

三个真实的案例

案例1

背景知识

• 这个公司做什么Air Canada 是加拿大的大型航空公司，官网不仅是营销入口，也是正式的旅客服务入口，涉及购票、退改签、会员权益和特殊票务政策。

• 出事的产品是什么出事的是官网上的客服聊天机器人。对普通旅客来说，它不是“实验工具”，而是和官网表单、帮助中心、人工客服并列的正式答疑入口。

• 事故是怎么发生的一位旅客因为家庭成员去世，去官网询问丧葬票政策和报销方式。聊天机器人给出了一套看起来完整、可执行的说明，告诉用户可以先按普通流程购票、事后再申请相关优惠或退款。用户相信这是官网正式答复，于是按照这个建议行动。等到他后续凭机器人答复去申请时，Air Canada 才表示真实政策并不是机器人说的那样，最终争议进入裁决阶段，企业也不能再把责任推给“只是机器人说错了”。溯源链接：Moffatt v. Air Canada, 2024 BCCRT 149。

事故分析

• 事故表面是什么旅客按照官网聊天机器人的说明行动，结果发现票务政策与真实规则不一致，企业最终要为错误信息承担责任。

• 详细分析这个事故的关键，不是模型随机胡说，而是企业把一个没有被严格证据约束的回答通道，放进了正式服务链路。用户并不会区分“官网知识库”“搜索结果”“AI 生成内容”之间的内部差异，他只会判断：这是你官网里的正式答复。于是，一次看似普通的 FAQ 错答，立刻升级成合同解释、赔付争议和企业责任问题。真正的危险，是企业把“回答能力”上线了，却没有把“证据、版本、责任边界”一起上线。

• 真正失控的是哪一层数据层先失控，随后检索层和证据约束缺失把风险放大了。

• 为什么 Demo 阶段没暴露Demo 一般只会验证“能否答出一个像样的政策说明”，不会压测高风险政策条款、例外条件、引用来源和后续赔付责任。

本案例暴露的第一缺口： 高风险政策问答缺少证据绑定与责任边界。

高风险回答必须来源受控、引用可追溯、必要时转人工。

案例2

背景知识

• 这个公司做什么MyCity 是纽约市面向小企业和市民提供公共服务信息的数字入口之一，背后承载的是政府服务、政策解释和办事引导。

• 出事的产品是什么出事的是 MyCity 集成的官方聊天机器人。用户会拿它当成政府办事助手，而不是普通搜索框。

• 事故是怎么发生的这起事故不是某一个用户偶然试出一个错误答案，而是媒体和研究者在它上线后持续拿真实业务问题去询问，例如租赁规定、最低工资、用工合规、商业限制等。结果发现，它会给出措辞很肯定、但与真实法规不一致，甚至可能把用户引向违法操作的回答。由于它嵌在官方服务体系里，这些错误回答天然带着“政府解释”的权威感，事故就从回答质量问题迅速升级成公共治理问题。溯源链接：Audit Report on the New York City Office of Technology and Innovation’s MyCity System。

事故分析

• 事故表面是什么官方聊天机器人给商户和市民提供了错误、甚至可能违法的政策建议。

• 详细分析MyCity 这个案例最值得讲的地方，是它说明了“权威场景”对 AI 的要求远高于“普通问答场景”。当系统在官方入口里承担政策解释角色时，错误回答不仅误导用户，还会破坏公共信任，甚至制造合规风险。这里的工程缺口不是“模型不够强”，而是没有把法规来源、证据绑定、拒答边界、人工接管和持续观测做成硬约束。系统上线了回答能力，却没有上线公共责任控制面。

• 真正失控的是哪一层检索层先失控，随后治理/观测层没有及时阻断高风险公共场景。

• 为什么 Demo 阶段没暴露Demo 往往只用低风险示例证明“能回答政策问题”，不会在真实法规变动、歧义案例、责任语境和媒体压力下持续压测。

本案例暴露的第一缺口： 官方高风险问答缺少法规来源约束、拒答边界和人工接管。

权威场景里的回答不能只追求“像正确”，必须先讲清证据、边界和升级路径。

案例3

背景知识

• 这个公司做什么DoNotPay 早期以帮助用户处理罚单、订阅取消和基础法律流程为卖点，后来逐步把自己包装成更广义的 AI 法律服务工具。

• 出事的产品是什么出事的不是单一聊天页面，而是整个“AI lawyer / 机器人律师”能力主张，以及围绕这一主张提供的法律建议与服务包装。

• 事故是怎么发生的这起事故不是因为某次回答被截屏嘲笑，而是因为 DoNotPay 长期把产品往“可以替代专业法律服务”的方向宣传。随着用户规模变大、监管关注提高，问题开始变成：它到底有没有证据证明自己能胜任这种高风险服务？有没有把高风险动作隔离出去？有没有向用户清楚说明边界？FTC 最终介入并下达命令，核心不是某个模型答错一句话，而是整套能力宣称、服务边界和监管责任之间长期错位。溯源链接：FTC Finalizes Order with DoNotPay That Prohibits Deceptive “AI Lawyer” Claims。

事故分析

• 事故表面是什么产品把 AI 能力包装成接近“机器人律师”的专业服务，最终引来 FTC 监管命令。

• 详细分析这个案例提醒你，企业 AI 翻车不一定先从生成层开始，也可能先从“能力宣称”开始。只要产品对外承诺超过了系统真实能力，且又缺少证据、评测、人工复核和责任边界，系统就会在发布层面先违规。换句话说，这不是“功能跑没跑通”的问题，而是“你到底向用户承诺了什么、有没有资格做这种承诺”的问题。

• 真正失控的是哪一层工具 / 动作层和治理 / 观测层共同失控，产品承诺越过了真实系统能力和监管边界。

• 为什么 Demo 阶段没暴露Demo 只能证明功能局部成立，证明不了产品有资格承担专业服务责任，更证明不了营销和上线口径是合规的。

本案例暴露的第一缺口： 产品能力主张越过了真实系统能力和监管边界。

上线前先划清“能辅助到哪、必须人工到哪、绝不能自动到哪”。

统一事故剖析框架

五层失控模型来拆解事故

• 数据层：输入数据，知识，版本，来源，权限边界

• 检索层：能否稳定召回正确证据，而非只召回像相关的内容

• 生成层：模型如何组织答案，何时拒绝答，不确定性是否被包装成确定性

• 工具/动作层：查数据，执行动作，调外部系统，动作硬边界

• 治理/观测层：评测，日志，HITL，回滚，用户通知，责任归属

如果事故发生了，逐层排查。我们以后遇到了AI事故，不先问参数，不先问换模型，而是先问：到底哪一层链路失控了？

为了让这套方法真正可用复盘，我会把动作固定为这个顺序：

• 先补充背景事实和责任语境

• 再看表面事故

• 再判断哪一层失控

• 再判断哪一层把伤害放大

• 最后再决定工程动作

为了解决这5层我们需要分别补充什么？

• 数据与输入：输入边界，数据契约，采集与湖仓（数据从哪里来，怎样稳定进系统？）

• 检索与证据层：语义层，混合检索，RAG，证据链（接得到，答得稳，引用的出来）

• 工具与动作层：Skill Pack+Tool Layer +HITL（系统能从答到办，边界线分在哪里？）

• 评测与观测层：评测，Tracing，观察与定位闭环（效果怎么量？问题怎么找？）

• 治理与发布层：治理，版本，成本，SLO，上线 Runbook（系统怎么稳，怎么发，怎么回？）

Demo vs 生产

	Demo	真实
数据	静态样例、手工准备、无版本差异	持续更新、口径漂移、权限和 PII
用户	提问者友好、上下文完整、不会故意试边界	问题歧义、行为分布极广、风险用户会直接撞边界
系统	单人掌控、单路径运行、失败可口头兜底	跨系统协作、高并发、失败需要系统级处理
治理	先做出来再说	评测、观测、责任边界、发布与回滚都必须前置

一旦你接受demo世界和生产世界不是同一个事件，下一步你就必须要问：企业AI想要从0到1，真正的走向上线，交付链上到底还要补充哪些环节？

企业AI从0到1的交付链

业务目标：

数据盘点->数据契约->采集与入湖->结构化非结构化处理->索引与检索->生成与工具->测评->可观测->版本与治理->上线与回滚

项目案例：客服知识库+工单联动

企业AI最容易失控的几个关键难点：

• 既要回答帮助中心、FAQ、Release Notes、API 文档里的规则性问题

• 也要理解工单、评论线程、状态字段等实时业务事实

• 还要在受控条件下完成工单查询、创建、更新等动作

• 并且全过程要具备证据引用、权限约束、审计字段、版本与回滚意识

牵连出的问题：

• 规则知识：产品说明、FAQ、操作文档、Release Notes 到底怎么解释

• 实时工单事实：当前用户的工单状态、历史处理记录、最新评论、升级节点是否一致

• 权限边界：当前提问者是否有权看到这条记录、这类指标、这类内部说明

• 动作边界：系统到底只能“建议”，还是可以真正“创建 / 更新 / 推进工单”

• 人工介入（HITL）：一旦遇到高风险、高不确定性或越权场景，系统应当在什么位置停下来并转人工

• 项目工程基线要先立住

• PII 分级与处理方式要先讲清

• 可执行 / 不可执行动作要先划线

• HITL 节点要先定义

• 风险边界文档要先写

• 《AI 系统落地蓝图》要先产出

业主流答案

• 评测要前置

• 观测要前置

• 风险边界要前置

• 能力主张要和证据绑定

会演示vs可上线

维度	会演示	可上线
数据	静态样例	有版本、更新和口径边界
检索	能召回一点内容	证据稳定、可解释、可追溯
输出	看起来像能答	有拒答、置信与风险边界
权限	默认无边界	用户、租户、PII 分层明确
工具	演示动作可跑	参数受控、动作可审计
评测	靠人工感觉	有指标、用例和回放
观测	不出错就算好	请求、证据、动作、失败可观测
回滚	出事再说	有降级、停机和回退路径
成本	不太关心	延迟、推理和资源成本可管理
责任边界	口头说明	owner、升级路径和治理边界清楚

缺失能力解释

• 数据版本：输入数据和知识是否有版本与更新边界

• 权限控制：请求上下文是否带权限与租户边界

• 证据引用：回答能否回到明确来源和依据

• 工具约束：工具调用是否有参数、动作和范围限制

• 评测机制：是否有质量评测与错误归因方式

• 观测能力：是否可追踪请求、证据、动作与失败

• 回滚机制：出错后是否有降级、回退与停止路径

• HITL：高风险场景是否有人类接管与审批

• 成本意识：是否考虑推理成本、缓存和资源预算

• 责任边界：是否明确系统 owner、运行 owner 与业务 owner

地图

• 数据 / 权限 / PII 缺口大 → 优先看 第2章

• 证据 / 检索 / 输出结构缺口大 → 优先看 第7-8章

• 工具 / 动作 / HITL 缺口大 → 优先看 第9-10章

• 评测 / Tracing / 回滚缺口大 → 优先看 第11-14章