AI Sociotechnical Resilience Operating Model Playbook

定位：面向高级 AI PM / AI BA / Product Architect / Enterprise Architect / Operations Leader / Model Risk / Compliance，把 AI 系统从“模型功能”升级为由人、流程、模型、数据、工具、治理和反馈共同构成的 sociotechnical work system。

适用边界：本文面向金融零售中的 AML、客服、信贷、分行运营、财富顾问、运营中台、风险运营和员工 copilot 场景。重点不是基础 BA、流程图入门或单点 prompt 设计，而是训练高级角色如何设计 AI 工作系统的韧性、协作、交接、例外、负载、反馈和运营模型。

重要说明：本文是学习、作品集和内部方案训练材料，不构成法律意见、合规结论、模型验证报告、审计意见或监管解释。正式项目必须由 Legal、Compliance、Model Risk、Operational Risk、Privacy、Security、Business Owner、Operations Owner、Technology Owner 和 Internal Audit 结合机构类型、司法辖区、客户影响和内部政策确认。

---

Source Anchors

以下来源是本文的外部锚点。本文把它们转成产品、架构、运营、风险和组织设计语言，不把任何来源简化为单一检查项。访问日期按 2026-06-29 记录。

---

1. One-Sentence Positioning / 一句话定位

Sociotechnical AI 的核心不是“把模型嵌入流程”，而是：

Sociotechnical AI Operating Model =
把 AI 能力设计成一个可运行的工作系统，
其中人、流程、模型、数据、工具、治理、反馈和组织激励相互约束，
系统在正常、异常、过载、变化和事故中仍能保持可解释、可接管、可恢复、可学习。

对高级 AI PM / BA / Architect 来说，真正的问题不是：

模型准确率能不能到 90%？

而是：

真实工作发生时，谁依赖 AI，谁监督 AI，谁承接例外，
系统如何发现自己不知道，如何把负载交给合适的人，
如何从失败、纠错、投诉、人工覆盖和近失误中学习，
并且如何证明这种学习降低了客户、员工、运营和监管风险？

金融零售里的 AI 系统通常不是单一模型：

一句话作品集表达：

我不会把 AI 当成一个回答问题的模型。我会把它设计成一个金融零售工作系统：定义人机分工、交接、例外、负载、反馈、治理和韧性指标，并用运营证据证明它在真实工作中持续可控。

---

2. 从 Model-Centric 到 Work-System-Centric

2.1 Model-centric 思维的局限

很多 AI 项目失败不是因为模型完全不能用，而是因为模型能力和真实工作系统之间没有被设计。

高级判断：

AI 的生产风险通常出现在连接处：模型与数据的连接、AI 与工具的连接、员工与 AI 的连接、团队与团队的连接、正式流程与真实工作的连接、指标与激励的连接。

2.2 工作系统七层图

Business outcome
  -> customer / employee / regulator impact
  -> work practice and decision rights
  -> AI capability and automation boundary
  -> data / knowledge / tool substrate
  -> human oversight and exception handling
  -> operating model and governance cadence
  -> feedback, learning and resilience improvement

每一层都要有 owner、指标、证据和升级路径。

---

3. work-as-imagined vs work-as-done

3.1 定义

work-as-imagined 是管理层、产品、流程、合规和技术文档中认为工作应该如何发生。

work-as-done 是前线、运营、分析师、客户和主管在时间压力、系统限制、例外、信息缺口、KPI 和组织激励下实际如何完成工作。

在 AI 项目中，两者差距会被放大：

高级 AI worker 的任务不是指责真实工作“不合规”，而是识别真实工作中的适应性：

• 哪些 workaround 是风险源。
• 哪些 workaround 是系统保持运行的韧性来源。
• 哪些人工判断不能被模型替代，但可以被 AI 支持。
• 哪些负载由 AI 项目转移给了前线、QA、合规或模型风险。
• 哪些 KPI 会诱导 automation bias、低报问题或过度升级。

3.2 Work Gap Discovery Canvas

3.3 AI 设计中的五类 work gap

3.4 作品集表达

不要写：

我画了现状流程和未来流程。

要写：

我用 case trace、override review、exception diary 和 queue analysis 对比了 work-as-imagined 与 work-as-done，发现客服 AI 的主要风险不是 FAQ 准确率，而是投诉、困难援助和欺诈意图在三轮问答后才升级，导致客户重复叙述和人工接管上下文丢失。我的方案增加了 early exception classifier、warm handoff payload、handoff SLO 和 feedback-to-eval loop。

---

4. human-AI collaboration / 人机协作设计

4.1 协作不是“人在环”四个字

human-in-the-loop 经常被误用成风险装饰。真正的人机协作要明确：

4.2 六种协作模式

高影响金融场景不应把协作模式从 recommend 偷偷升级为 act。每次模式升级都必须经过 risk tier、human oversight、audit evidence 和 release gate。

4.3 Collaboration Contract

每个 AI use case 都应有一页协作契约。

4.4 Trust Calibration

信任不是越高越好。正确目标是 calibration：

---

5. handoff/exception/load/feedback

这一组能力决定 AI 是否能在真实运营中活下来。很多 AI 项目在 demo 中成功，在生产中失败，是因为没有设计交接、例外、负载和反馈。

5.1 Handoff / 交接

交接不是按钮，是一个可测的工作系统。

Warm handoff payload：

Handoff SLO：

5.2 Exception / 例外

例外不是系统的边缘；在金融零售里，例外往往是风险和价值的中心。

Exception design 要输出三件事：

5.3 Load / 负载

AI 常常不是减少负载，而是改变负载分布。

Load design 的高级原则：

• 不只优化 AHT，也要看返工、投诉、二次联系、人工复核、QA backlog 和员工疲劳。
• 不只看平均负载，也要看高峰、长尾、复杂 case 和关键角色瓶颈。
• 不把 AI 节省的前线时间转嫁给合规、QA、模型风险或知识 owner。
• 例外负载增加时，要明确是好事还是坏事：好事可能是 AI 识别了以前被漏掉的风险；坏事可能是阈值、路由或知识质量差。

5.4 Feedback / 反馈

反馈不是 thumbs up/down。生产级反馈要能驱动治理和系统学习。

Feedback taxonomy：

Feedback loop：

Frontline feedback / customer complaint / QA defect / override
  -> structured tag and severity
  -> owner routing
  -> triage SLA
  -> corrective action
  -> eval / knowledge / prompt / route / process / training update
  -> release gate or controlled rollout
  -> dashboard evidence
  -> monthly resilience review

反馈必须有 owner，否则就是情绪收集。

---

6. AI operating model

6.1 Operating Model 总览

AI operating model 要回答：

谁决定 AI 能做什么？
谁运营 AI 在真实流程中的行为？
谁维护数据、知识、模型、工具和反馈？
谁承担风险接受和客户影响？
谁在过载、异常、事故和供应商变更时指挥？

一个金融零售 AI operating model 至少包含九个控制面：

6.2 Decision Rights

6.3 Operating Cadence

6.4 Required Operating Artifacts

---

7. 金融零售案例

7.1 AML Alert Investigation Copilot

一句话场景：

AI 支持 AML analyst 汇总交易、检索 KYC / 政策、识别证据缺口、起草 investigation narrative，但不能替代可疑活动判断、SAR 决策或管理层审批。

设计红线：

• AI 不能独立关闭高风险 alert。
• AI 不能把相似案例结论直接迁移到当前客户。
• AI 不能在无证据情况下写“客户行为合理”或“无需进一步调查”。
• AI 不能隐藏来源冲突、KYC 过期或数据缺失。

作品集资产：

7.2 Customer Service AI Assistant

一句话场景：

AI 支持客户自助和 agent assist，处理低风险查询、生成客服建议、识别投诉和欺诈信号，并把高风险意图 warm handoff 给人工。

设计红线：

• 不用 AHT 单指标驱动客服 AI。
• 客户请求人工时不应被 AI 无限挽留。
• AI 不应在投诉、欺诈或困难援助场景插入销售推荐。
• 无权威来源时不应给出费用、资格、投诉权利或监管承诺。

作品集资产：

7.3 Credit Decision Support

一句话场景：

AI 支持信贷官解释政策、检查材料、生成审批备忘录、提示风险和缺失信息，但不替代正式 credit decision、adverse action reason、fair lending control 和审批责任。

设计红线：

• AI 不能生成与正式决策不一致的拒绝理由。
• AI 不能把受保护属性或代理变量作为解释依据。
• AI 不能让审批人只看到结论而看不到证据、冲突和缺失信息。
• AI 不能在未评估可解释性、公平性和模型风险的情况下进入高影响决策。

作品集资产：

7.4 Branch Operations / Wealth Advisor Copilot

一句话场景：

AI 支持分行员工和财富顾问做客户准备、产品知识查询、会议摘要、任务跟进和合规提示，但不替代适当性判断、投资建议责任或客户同意。

设计红线：

• AI 不能暗示收益保证或淡化风险。
• AI 不能把营销推荐伪装成适当性建议。
• AI 不能忽略客户约束、风险承受能力、脆弱客户状态和监管披露。
• AI 不能让顾问在未看来源的情况下复制投资解释。

作品集资产：

---

8. 韧性指标 / Resilience Metrics

韧性不是“永远不出错”，而是系统能在变化、压力、异常和失败中保持受控，并且能学习。

8.1 Resilience Metric Families

8.2 生产级指标表

8.3 Dashboard 组合

一个可展示的 resilience dashboard 不应只有 accuracy 和 adoption。

---

9. 组织设计

9.1 组织设计原则

Sociotechnical AI 的组织设计要避免两个极端：

推荐结构是 federated operating model：

Enterprise AI Governance / Risk / Platform
  -> provides standards, platform, control library, evidence model, review gates

Business AI Product Squads
  -> own workflow outcomes, adoption, exceptions, customer impact

Embedded Operations and Frontline Champions
  -> surface work-as-done, workload, feedback, training and resilience signals

Model Risk / Compliance / Audit
  -> challenge assumptions, validate controls, review evidence, monitor residual risk

9.2 核心角色

9.3 Governance Forums

9.4 激励设计

AI 韧性会被 KPI 破坏。常见冲突：

组织设计要把“发现问题”当成系统韧性的贡献，而不是把 feedback、override、near miss 视为个人失败。

---

10. 反模式

---

11. 30 天训练计划

目标：30 天内完成一个金融零售 AI sociotechnical resilience capstone。建议选择 AML、客服、信贷或分行 / 财富顾问中的一个主场景，同时用另外三个场景做横向对比。

30 天结束时，最低交付标准：

---

12. 面试答案

12.1 什么是 Sociotechnical AI？为什么对金融零售重要？

30 秒版本：

Sociotechnical AI 是把 AI 看成人、流程、模型、数据、工具、治理和反馈共同构成的工作系统，而不是单个模型功能。金融零售里 AI 会影响客户权益、员工判断、合规流程和运营负载，所以只看模型准确率不够，必须设计交接、例外、人工监督、反馈闭环和韧性指标。

2 分钟版本：

我会先定义 AI 所在的真实工作系统：谁使用、谁受影响、AI 依赖哪些数据和工具、哪些动作可逆、哪些场景必须人工接管。然后用 work-as-imagined vs work-as-done 找出正式流程和真实工作差距，再设计 human-AI collaboration contract、handoff、exception router、load model、feedback taxonomy 和 operating model。最后用 resilience dashboard 监控系统是否能 anticipate、monitor、respond、recover、learn and adapt。这样 AI 不是 demo，而是可运营、可审计、可恢复的能力。

12.2 work-as-imagined vs work-as-done 在 AI 项目中怎么用？

30 秒版本：

work-as-imagined 是流程和文档里认为工作如何发生，work-as-done 是前线在时间压力、系统限制和例外情况下实际如何完成工作。AI 设计必须基于 work-as-done，否则会自动化错误假设。

2 分钟版本：

我会用 case trace、shadowing、override review、exception diary 和 queue analysis 找真实工作证据。例如客服流程图说复杂问题转人工，但真实情况可能是客户在三轮 AI 问答后才被识别为投诉，人工接管时没有上下文。这个 gap 的解决方案不是再优化回答，而是 early exception classifier、warm handoff payload、handoff SLO 和 feedback-to-eval loop。

12.3 如何设计 human-AI collaboration，而不是空泛地说有人在环？

30 秒版本：

我会定义 AI 和人的协作契约：AI 能做什么、不能做什么；人什么时候介入；人看到什么证据；人能 approve、edit、reject、override 还是 rollback；人的反馈如何进入 eval 和知识更新。

2 分钟版本：

不同风险层级对应不同协作模式。低风险可以 search 或 draft，高风险信贷、AML、财富适当性更适合 critique 和 recommend，涉及客户账户、退款、case closure 的动作必须 act with approval。关键是人要有足够上下文、时间、权限和激励去监督，否则 human-in-the-loop 只是形式控制。

12.4 如何为 AI 客服设计 handoff？

30 秒版本：

Handoff 不是转人工按钮，而是上下文、责任和 SLA 的交接。客服 AI 必须把客户诉求、已确认事实、AI 已回答内容、失败原因、风险标签和建议下一步传给接收者。

2 分钟版本：

我会区分 cold、warm、hot handoff。普通 FAQ 可以 cold handoff；投诉、欺诈、困难援助、费用争议需要 warm handoff；账户风险或客户伤害需要 hot handoff。指标不只看转人工率，还要看 handoff completeness、wrong queue rate、handoff latency 和客户重复叙述率。

12.5 AI 上线后如何衡量韧性？

30 秒版本：

韧性指标要覆盖 anticipate、monitor、respond、recover、learn、adapt。除了准确率，还要看交接质量、例外控制、过载预警、人工覆盖质量、反馈关闭时间、回滚时间、近失误捕获和同类错误复发率。

2 分钟版本：

我会做 resilience dashboard，把 value、quality、collaboration、exception、load、risk、resilience、cost 放在一起。比如 AML copilot 不只看 narrative 草稿节省时间，还要看高风险 alert 是否升级、manager rework、evidence gap、QA defect、near miss、knowledge freshness 和 incident corrective action aging。

12.6 如何避免 AI 把负载转嫁给下游团队？

30 秒版本：

我会建立 workload displacement index，评估 AI 对前线、QA、合规、知识 owner、模型运营和客户的负载变化，避免只看局部效率。

2 分钟版本：

AI 可能降低客服平均处理时长，但让人工队列剩下更复杂 case；也可能让知识 owner 维护压力上升，让 QA 复核量上升。我会在试点期监控 queue depth、review backlog、knowledge SLA、employee workload survey、customer repeat contact 和 exception mix。如果负载转移不可接受，就要调整自动化边界、staffing、抽样策略或知识治理。

12.7 如何设计 AI operating model？

30 秒版本：

AI operating model 要明确 use case、工作系统、产品边界、架构平台、数据知识、EvalOps、风险治理、运营韧性和 adoption learning 九个控制面，并配套 RACI、cadence、dashboard 和 incident loop。

2 分钟版本：

我会先定义 decision rights：谁能批准自动化等级、谁能发布 prompt / model / retriever、谁接受残余风险、谁负责生产事件。然后建立 daily operations huddle、weekly quality review、monthly resilience review、quarterly executive portfolio review。这样 AI 不靠项目团队热情维持，而是成为可运营能力。

12.8 AML copilot 最重要的设计边界是什么？

30 秒版本：

AML copilot 可以汇总、检索、提示证据缺口和起草 narrative，但不能独立关闭高风险 alert、决定 SAR 或替代 analyst judgment。

2 分钟版本：

AML 的关键风险是证据链和责任边界。AI 必须显示交易模式、KYC、历史 case、政策来源和未解决疑点。制裁、PEP、高风险地区、身份冲突、来源冲突要强制升级。analyst 编辑和拒绝 AI narrative 的原因要进入 eval 和知识治理。指标要看 high-risk miss、manager rework、narrative defect、handoff completeness，而不只是处理时长。

12.9 为什么 AI pilot 成功后 scale 失败？

30 秒版本：

因为 pilot 常常只证明模型能回答和少数用户愿意试用，没有证明知识维护、交接、例外、负载、反馈、风险接受、incident 和供应商变更能长期运营。

2 分钟版本：

scale 前必须有 operating evidence：work-as-done evidence、collaboration contract、handoff SLO、exception router、load model、feedback closure、resilience dashboard、release gate、rollback plan 和 RACI。如果这些不存在，规模化会把小问题放大成客户伤害、员工不信任、合规缺口或运营过载。

12.10 如何向高管解释 Sociotechnical Resilience 的商业价值？

30 秒版本：

它让 AI 不只是降本工具，而是可持续运营能力。它降低客户伤害、返工、投诉、事故、审计缺口和员工抵触，同时让有价值的 AI 用例可以安全规模化。

2 分钟版本：

我会用 value-risk-resilience 三个维度汇报：value 看业务结果和单位经济性；risk 看客户、合规、隐私、模型和供应商风险；resilience 看异常、过载、交接、恢复和学习能力。高管真正需要的是知道哪些 AI 可以 scale，哪些要 pause，哪些需要补控制，哪些组织能力成为瓶颈。

---

13. 作品集交付物

一个高级作品集不应展示“我做了一个 AI chatbot”。建议做成 Financial Retail AI Sociotechnical Resilience Capstone。

13.1 核心交付物清单

13.2 Capstone 结构建议

Slide 1: Problem framing
Slide 2: Why model-centric AI is insufficient
Slide 3: Sociotechnical system map
Slide 4: Work-as-imagined vs work-as-done findings
Slide 5: Human-AI collaboration contract
Slide 6: Handoff / exception / load / feedback design
Slide 7: AI operating model and RACI
Slide 8: Resilience dashboard
Slide 9: Financial retail case comparison
Slide 10: Scale decision and residual risk
Appendix: metrics, payload schema, taxonomy, tabletop, interview answers

13.3 面试故事线

3 分钟版本：

我选择了一个金融零售 AI 场景，不把它做成单纯 chatbot。
第一步，我用 sociotechnical system map 定义人、流程、模型、数据、工具、治理和反馈。
第二步，我对比 work-as-imagined 与 work-as-done，找出真实工作中的 workaround、例外和负载转移。
第三步，我设计 human-AI collaboration contract，明确 AI 可以 search / draft / critique / recommend，但哪些动作必须人工审批。
第四步，我把 handoff、exception、load、feedback 做成 operating pack，保证异常能接管、负载能看见、反馈能闭环。
第五步，我设计 AI operating model、RACI、governance cadence 和 resilience dashboard。
最后，我用 AML、客服、信贷、分行 / 财富顾问四个案例说明这套方法可以迁移到不同金融零售场景。

高级收尾：

我的差异化不是会写 AI 需求，而是能把 AI 从 demo 带到真实金融零售运营：看见工作系统、设计人机协作、控制风险、管理例外、监控韧性，并把反馈转成组织学习。

---

14. 自检清单