Sociotechnical AI / Resilience：工作系统
Sociotechnical AI 把 AI 看成一个由人、模型、数据、流程、工具、政策、组织责任和反馈循环共同构成的工作系统。模型能力只是其中一个部件。AI 上线后, 工作会被重新分配, 信任会被重新校准, 例外会被放大或隐藏, 责任边界会被重新解释。真正的产品失败经常不是模型不会生成, 而是系统没有理解 work-as-done。
Sociotechnical AI / Resilience / Work-as-Done 解读
Source Anchors
| Source | Link | 用途 |
|---|---|---|
| NIST AI Risk Management Framework | https://www.nist.gov/itl/ai-risk-management-framework | 将 AI 系统放入组织治理、风险、测量和持续管理循环 |
| Microsoft Guidelines for Human-AI Interaction | https://www.microsoft.com/en-us/research/publication/guidelines-for-human-ai-interaction/ | 参考 AI 交互中的期望校准、反馈、错误处理、人工控制 |
| Google PAIR Guidebook | https://pair.withgoogle.com/guidebook/ | 参考以用户任务、数据、反馈和人机协作为中心的 AI 产品设计 |
| Team Topologies | https://teamtopologies.com/ | 借鉴 team boundaries、cognitive load、interaction modes 对组织架构和平台能力的影响 |
核心导读
Sociotechnical AI 把 AI 看成一个由人、模型、数据、流程、工具、政策、组织责任和反馈循环共同构成的工作系统。模型能力只是其中一个部件。AI 上线后, 工作会被重新分配, 信任会被重新校准, 例外会被放大或隐藏, 责任边界会被重新解释。真正的产品失败经常不是模型不会生成, 而是系统没有理解 work-as-done。
韧性工程提供了更成熟的判断标准: 复杂系统不可能永不出错, 关键是能否发现、吸收、恢复、学习和适应。对 AI 产品来说, 这意味着设计对象不只是功能路径, 还包括 handoff、exception、review load、incident response、feedback-to-eval、知识更新、模型版本和治理决策。
1. 问题定义
很多 AI 项目把系统边界画到模型、RAG、API 和 UI 为止。这个边界太小。真实成败取决于 AI 如何嵌入工作系统:
- 谁使用 AI, 谁审核, 谁承担责任。
- AI 改变了哪些 handoff、SLA、队列和岗位负载。
- 用户在压力下会如何采纳、忽略、绕过或过度信任 AI。
- 例外场景是否被看见, 还是被流畅输出掩盖。
- 反馈是否进入 eval、知识治理和产品改进, 还是只停在满意度按钮。
- 事故发生时能否降级、回滚、补救和复盘。
AI PRD 常描述 work-as-imagined:
用户提出问题 -> AI 给出建议 -> 用户确认 -> 系统执行 -> 流程完成
真实 work-as-done 往往是:
用户问题不完整
政策有例外
系统数据缺字段
客户情绪影响表达
一线员工有 SLA 压力
二线团队有 backlog
AI 引用看似正确但不适合这个客户
人工为了赶时间直接采纳
错误在下游投诉或审计中才暴露
如果只按理想流程设计, AI 会把判断压力转移给一线, 把复核负载推给二线, 让异常更难被发现, 并让组织误以为“人工确认”已经解决责任问题。
2. 核心原理 / 架构模型
2.1 AI 工作系统的组成
| 组成 | 关键问题 |
|---|---|
| Human Actors | 谁使用、审核、接管、补救, 谁拥有 override 权限 |
| AI Capability | AI 是检索、总结、分类、建议、决策还是执行 |
| Data / Knowledge | 数据来源是否权威、及时、可访问、可删除 |
| Workflow | AI 插入哪一步, 改变哪些 handoff 和等待 |
| Tools / APIs | AI 能读写哪些系统, 权限和限额是什么 |
| Policies | 合规、业务、风险、品牌、客户权益约束是什么 |
| Feedback | 用户如何纠错, 错误如何进入改进循环 |
| Monitoring | 谁看 dashboard, 什么信号触发行动 |
| Governance | 谁批准上线、扩展、暂停、下线 |
| Organization | 哪个团队拥有平台、知识、模型、运营、风险 |
设计 AI 产品时, 这些元素应被同时建模。只设计 UI 和模型调用, 等于把大量真实系统行为留给上线后碰运气。
2.2 Human-AI Collaboration Patterns
| 模式 | AI 角色 | 人类角色 | 适用场景 | 主要风险 |
|---|---|---|---|---|
| Drafting | 生成草稿 | 编辑、批准 | 客服回复、报告初稿 | 人工过度信任 |
| Retrieval | 找依据 | 判断适用性 | 政策、知识库查询 | 引用正确但上下文不适用 |
| Triage | 排序、分类 | 复核高风险 | AML alert、投诉队列 | 低估长尾风险 |
| Recommendation | 给建议 | 接受、拒绝、override | 财富建议、下一步动作 | 责任边界模糊 |
| Decision Support | 给评分和理由 | 做最终决策 | 信贷、欺诈调查 | 解释不足、偏差 |
| Execution Agent | 调用工具执行 | 批准、监控、接管 | 退款、case update | 过度自动化 |
| Coach | 引导用户学习 | 用户自我决策 | 理财教育、员工培训 | 用户误解为正式建议 |
每种协作模式需要不同的 UI、权限、eval、日志和运营模型。不能用同一套“生成建议 + 用户确认”覆盖所有风险等级。
2.3 Resilience Model
韧性不是“系统从不出错”, 而是系统具备五类能力:
| 韧性能力 | AI 系统中的含义 |
|---|---|
| Detect | 发现 unsafe output、drift、错误采纳、异常工具调用 |
| Absorb | 通过 fallback、人工队列、限流、降级吸收冲击 |
| Recover | 回滚模型或 prompt, 修复知识, 补救客户, 恢复服务 |
| Learn | 将事故、用户修改、抽检结果转成 eval 和流程改进 |
| Adapt | 面对新政策、新产品、新攻击和新工作流时快速调整 |
这个模型能避免把 AI 质量理解成单次回答质量, 而是扩展为持续运营质量。
3. 方法机制
3.1 Work-as-Done Discovery
理解真实工作不能只访谈管理层, 需要观察任务、例外、绕行路径和压力条件。重点问题包括:
- 哪些输入经常缺失、不一致或需要人工判断。
- 哪些政策有例外, 例外由谁解释。
- 用户何时会跳过复核或直接复制 AI 输出。
- 下游团队收到什么质量的 handoff。
- 哪些错误不会立即暴露, 只会在投诉、审计或损失中出现。
- 当前系统的隐性工作是什么, AI 会把它减少还是转移。
3.2 Handoff、Exception、Load
Handoff 不只是“转人工”。需要定义谁接手、接手时看到什么 evidence bundle、AI 的不确定性和失败原因是否可见、SLA 如何计算、客户是否知道状态变化、handoff 是否进入监控指标。
Exception 应是一等设计对象。典型异常包括数据缺失、政策冲突、客户身份异常、监管敏感话术、多系统记录不一致、请求超出授权范围、模型置信低但语气肯定。系统需要明确哪些异常由 AI 解释, 哪些必须升级, 哪些直接停止自动化。
Load 要看 total system load, 不能只看单点效率:
| 表面收益 | 隐藏负载 |
|---|---|
| 一线客服更快回复 | 二线复核增加 |
| AML 初筛更快 | 高风险 case 积压 |
| 自动生成报告 | 审核人员需要检查更多文本 |
| agent 自动更新 CRM | 数据治理团队处理更多异常 |
3.3 Operating Model
成熟的 AI operating model 需要覆盖真实动作:
| Capability | 核心职责 |
|---|---|
| Product Outcome | 业务结果、用户体验、优先级、pilot 决策 |
| Requirement & Eval Contract | acceptance、golden set、failure taxonomy、UAT |
| Architecture | pattern、integration、quality attributes、ADR |
| Model / Prompt / RAG | 模型、prompt、retrieval、版本管理 |
| Data / Knowledge | source authority、lineage、freshness、权限 |
| Risk & Compliance | policy、residual risk、review、evidence |
| Security & Privacy | threat model、DLP、access、logging |
| Operations | review workload、handoff、SOP、incident response |
| Monitoring | dashboard、alert、drift、rollback |
| Continuous Improvement | 错误复盘、eval 更新、策略调整 |
责任要落到具体决策: 谁能批准模型升级, 谁能修改知识库, 谁能放宽 guardrail, 谁能暂停 agent 写权限, 谁负责客户补救, 谁拥有 eval set 的代表性。
4. 证据与控制
韧性证据要覆盖 detect、absorb、recover、learn、adapt:
| 能力 | 指标 |
|---|---|
| Detect | incident detection time、unsafe output discovery rate、drift alert coverage |
| Absorb | fallback success rate、manual queue capacity、graceful degradation rate |
| Recover | MTTR、rollback time、customer remediation time |
| Learn | error-to-fix cycle time、eval set update rate、policy update propagation time |
| Adapt | new scenario onboarding time、workflow change lead time |
| Coordinate | handoff completion rate、ownership clarity、cross-team review SLA |
控制设计应把人机协作变成可审计系统:
- AI 输出区分事实、推断、建议和行动。
- 高风险场景提供 evidence bundle, 而不是只给结论。
- 人工 override、编辑、拒绝和升级都记录原因。
- 生产错误进入 failure taxonomy, 并转成 regression eval。
- 知识源有 owner、更新时间、权限边界和撤回机制。
- 模型、prompt、RAG index、tool schema 版本可重建。
- 事故有 severity、containment、rollback、customer remediation 和 postmortem。
这些控制不是额外文档负担, 而是防止 AI 系统在组织中变成不可解释的隐性自动化。
5. AI产品/金融零售场景
5.1 分行财富顾问 Copilot
理想流程是顾问输入客户情况, AI 生成资产配置建议, 顾问确认后与客户沟通。真实工作中, 客户信息分散在 CRM、交易、风险测评和线下沟通, 顾问有销售压力和合规责任, 客户可能把教育性解释理解成正式建议, 市场信息和产品适配性快速变化。系统设计应把 AI 限定在 education、preparation、explanation 等边界内, 高风险建议必须由顾问确认, 并显示资料缺口、不适用假设、disclosure 和 suitability evidence。
5.2 AML Analyst 工作系统
AI summary 可能让 analyst 更快, 也可能降低对原始交易的检查, 让二线复核只看 AI rationale。设计重点是 fact/inference/recommendation 分离、evidence trace、sampled review、high-risk mandatory escalation, 并把 analyst feedback 回流到 eval set。这里的目标不是让 AI 替代判断, 而是提高证据组织质量和复核一致性。
5.3 客服 Copilot
客服 copilot 的成功不是回答更长, 而是客服更快理解政策, 客户得到一致但不误导的答复, 异常和投诉及时升级, 错误输出能被发现并修复, 客服不会因为 AI 增加认知负担。需要同时监控处理时长、一次解决率、投诉、误导承诺、编辑距离、升级质量和 review load。
5.4 信贷运营
信贷资料补件、拒绝原因解释和人工 override 都是社会技术问题。AI 若只生成解释而没有政策引用、adverse action trace、fairness monitoring 和 appeal path, 会把透明度问题包装成更流畅的文本。更稳妥的设计是先把 AI 用于资料完整性检查、政策检索和解释草稿, 再逐步验证更高自动化边界。
6. 反模式
| 反模式 | 表现 | 后果 |
|---|---|---|
| Model-centric delivery | 只汇报模型指标 | 真实工作流问题被忽略 |
| Fake HITL | UI 上有人工确认, 但人没有时间和证据判断 | 责任转移而非风险控制 |
| Adoption theater | 只看使用次数和采纳率 | 过度信任被误当成功 |
| Hidden work shift | 一个团队效率提升, 另一个团队负载增加 | 系统总效率下降 |
| Exception blindness | 只优化 happy path | 事故集中在长尾场景 |
| No learning loop | 用户反馈没有进入 eval 和产品改进 | 同类错误重复发生 |
| Governance by meeting | 靠会议决定上线和放宽限制 | 缺少可追溯证据 |
| Tool permission creep | agent 工具权限逐步扩大但缺少复审 | 自动化爆炸半径扩大 |
7. 最终心智模型
Sociotechnical AI 的判断公式可以写成:
AI product effectiveness
= model capability
+ fit with work-as-done
+ calibrated human control
+ exception handling
+ total system load management
+ feedback-to-eval loop
+ resilience and governance
因此, 评估 AI 产品时不要只问“模型表现怎样”, 而要问“这个工作系统上线后如何运行”。谁被减负, 谁被加压; 哪些例外会浮现, 哪些会被隐藏; 人是否有能力接管; 错误是否能被发现和学习; 组织是否能在模型、知识、流程和风险变化时持续适应。能回答这些问题, AI 才从功能上线进入可运营的系统能力。
SOTA 状态标注 (2026-07-01)
本篇属于第二、三遍深读池（参考架构/深读笔记），未列入 12 周主线必读。时效基线为写作时点；引用前请按 CLAUDE.md 全局时效性硬规则复查最新进展。模块级 SOTA 对照见 docs/AI_SYSTEMATIC_LEARNING_ROADMAP_2026.md 各周「2026 SOTA 对照」行与文末「SOTA 检查」。