AI Incident Disclosure / Liability / Insurance / Risk Transfer Architecture Playbook

配对阅读：本手册的原理/架构解读版是 docs/ai-foundations/papers/126-ai-incident-disclosure-liability-risk-transfer-architecture.md。先读 paper 建立机制与取舍，再用本手册落地为模板、RACI 与门禁，两者不需要重复精读。

核心导读: AI incident disclosure / liability / risk transfer 不是基础 incident response, 而是把 AI 事故从“技术故障”升级为事实保全、客户影响界定、披露支持、责任边界、保险权利保留、供应商追偿和 board-ready 证据架构。

学习主线: 从 incident taxonomy、materiality triage、notification workflow、liability boundary、vendor/insurance mapping、loss quantification、evidence pack、tabletop exercise 到 operating model, 建立一条可复盘、可审查、可追偿的 AI incident 决策链。

系统边界: 本文不自动判断是否披露、是否承保、是否赔付或是否通知客户；它定义支持 Legal、Risk、Compliance、Security、Insurance、Vendor Management、Board 和审计流程的事实、证据、控制和治理结构。

核心判断:

AI incident management is not complete when the model is fixed. It is complete when facts are preserved, affected customers are understood, disclosure decisions are supported, liability boundaries are mapped, insurance rights are preserved, vendor recovery is evaluated, and evidence is ready for counsel, regulators, auditors and executives.

---

0. Disclaimer

本文是系统学习和架构训练材料, 不构成法律意见、证券披露意见、保险覆盖意见、监管意见、合规结论、审计结论、理赔建议或客户通知建议。

正式项目必须由 Legal、Securities Counsel、Disclosure Committee、Compliance、Privacy、Cyber、Operational Risk、Model Risk、Third-Party Risk、Insurance/Risk Management、Finance、Communications、Business Owner、Internal Audit、Insurance Broker、Coverage Counsel 和必要的外部顾问共同判断。

适用性取决于 entity type、public-company status、jurisdiction、product/customer segment、incident facts、customer impact、cyber/privacy impact、regulated workflow impact、vendor contract、insurance policy terms、notice timing、exclusions、sublimits、retentions、endorsements、board/counsel/regulator/insurer views。

本文避免给出“必须披露”“一定覆盖”“必然赔付”之类结论。它提供的是 decision support architecture。

---

1. Executive Framing

金融零售 AI incident 会跨越多个传统边界:

• Technology incident。
• Cyber/privacy incident。
• Customer harm incident。
• Misleading claim / marketing content incident。
• Conduct risk / fair lending / suitability incident。
• Third-party vendor incident。
• Board governance incident。
• Insurance notice and claim preservation event。
• Legal hold and evidence preservation event。

传统 IT incident 关注 restore service。AI incident 还要关注:

What did the AI say or do?
Who saw it?
Which business decision was influenced?
Which customer population may be harmed?
Was a regulated claim or disclosure affected?
Which facts are confirmed, unknown or disputed?
Which vendor or internal control boundary failed?
Which notification, disclosure or insurance notice pathways may be implicated?
What evidence is required before anyone can responsibly conclude anything?

成熟的 AI incident operating model 不应替代律师、证券披露委员会、保险 broker 或理赔团队。系统设计要把以下能力前置:

• 把 incident facts 结构化。
• 把 AI runtime evidence 保全。
• 把客户影响和业务影响量化。
• 把 vendor and insurance boundary 映射清楚。
• 把 board / regulator / customer / insurer 所需 evidence 提前准备。
• 把补救、恢复、risk transfer 和 CAPA 放进同一个 operating model。

Executive principle:

The institution cannot transfer AI risk it cannot evidence,
cannot disclose risk it cannot measure,
and cannot defend AI conduct it cannot replay.

---

2. Source Anchors

Source nuance:

• SEC cyber rule 不是所有 AI incident 的通用披露规则；prompt log exposure、tool token compromise、unauthorized access 或 cyber business disruption 才可能进入该路径分析。
• FTC AI claims 不只影响广告；金融产品中的 AI-generated benefit、approval、risk、fee、speed、accuracy claim 都需要 substantiation thinking。
• NAIC bulletin 面向 insurer AI use；银行、lender、broker 或 fintech 不能机械套用, 但 third-party AI governance 和 consumer outcome 思维可复用。
• NIST AI RMF 和 ISO/IEC 42001 是 structured governance language, 不是单一法律答案。

---

3. AI Incident Taxonomy

AI incident taxonomy 要按 business consequence, not only technical symptom。

Severity dimensions:

AI-specific incident objects:

---

4. Materiality Triage

Materiality triage is decision support, not automated legal conclusion。

Triage principles:

• Separate confirmed facts from assumptions。
• Keep quantitative and qualitative factors together。
• Preserve uncertainty explicitly。
• Record who made each decision and under what privilege or governance process。
• Do not let product, engineering or comms create final disclosure conclusions outside authorized process。
• Re-run triage when facts change。

Workflow:

incident intake
  -> preservation and privilege gate
  -> preliminary classification
  -> affected population estimate
  -> financial impact estimate
  -> qualitative impact assessment
  -> disclosure / notification pathway screen
  -> counsel / disclosure committee / risk committee review
  -> decision log and reassessment cadence

Decision support matrix:

Public company cyber nuance:

• A cyber-adjacent AI incident may require disclosure committee process if facts indicate material cybersecurity impact。
• Architecture should provide timeline、cyber nexus support、affected systems/data、financial estimate、qualitative impact、control state、known/unknown facts。
• Architecture should not state “material,” “not material,” “no disclosure,” or “covered by insurance.”

Qualitative factors:

---

5. Notification Workflow

Notification workflow must coordinate customer, regulator, board, vendor and insurer channels without allowing inconsistent narratives。

detection
  -> incident command starts
  -> legal / privilege / preservation gate
  -> initial fact ledger
  -> notification pathway screen
      -> customer communication
      -> regulator / examiner communication
      -> board / committee notification
      -> vendor notice / demand
      -> insurer notice
  -> approved message control
  -> evidence and decision log
  -> updates and corrections

Customer notification decision support:

Regulator / examiner binder:

Board brief should cover: what happened, known/unknown facts, customers and operations affected, cyber/privacy/disclosure/litigation/insurance/vendor exposure under assessment, decisions already made, decisions needed, residual risk, next update cadence, CAPA and risk transfer strategy。

Insurance notice workflow:

---

6. Liability Boundary Mapping

Liability boundary mapping asks who controlled which risk and which evidence supports that boundary。

Causation and contribution map:

Boundary diagram:

customer impact
  <- final communication / business action
  <- human approval or automation rule
  <- AI output / recommendation / tool plan
  <- prompt and policy bundle
  <- RAG source and data quality
  <- model route and vendor behavior
  <- governance and release controls

The strongest liability boundary evidence is not a narrative. It is a replayable chain。

---

7. Vendor Indemnity / SLA / Insurance Mapping

Vendor risk transfer is only useful if contract metadata and runtime evidence are connected before the incident。

Vendor types:

Contract-to-evidence link:

contract obligation
  -> control requirement
  -> runtime telemetry
  -> incident evidence
  -> notice / tender / SLA claim
  -> recovery or dispute

Example:

---

8. Risk Transfer Options

Risk transfer is a portfolio of mechanisms. None substitutes for control design。

Risks often retained despite transfer language:

• Product claim accuracy。
• Board and management oversight。
• Primary regulator relationship。
• Customer remediation before recovery。
• Evidence gaps。
• Vendor concentration。
• Systemic control weakness。

Design principle:

Transfer follows evidence.
If the institution cannot prove vendor route, failed obligation, affected output,
loss amount and mitigation actions, transfer mechanisms become negotiation,
not architecture.

---

9. Cyber vs E&O vs Tech / Professional Liability Mapping

Insurance mapping should be done with broker and coverage counsel. The architecture role is to supply clean facts and loss categories。

Coverage-adjacent fields:

Notice pack:

---

10. Loss Quantification

Loss quantification supports materiality, reserves, insurance notice, vendor recovery and remediation planning。

Model:

gross_loss =
  customer_remediation
  + response_cost
  + legal_professional_cost
  + regulatory_response_cost
  + defense_settlement_estimate
  + business_interruption_estimate
  + control_remediation_cost

net_loss_range =
  gross_loss
  - expected_vendor_recovery
  - expected_insurance_recovery_after_retention
  +/- uncertainty_adjustment

Minimum affected population query dimensions:

• model version。
• prompt version。
• source document version。
• approved claim id。
• tool action type。
• customer segment。
• product。
• jurisdiction。
• channel。
• employee role。
• time window。
• final customer message status。
• remediation status。

Loss evidence:

---

11. Evidence Pack

Evidence pack should support counsel, regulator, insurer, vendor recovery, audit and internal learning。

Evidence principles:

• Preserve before cleanup。
• Capture raw evidence and curated explanation separately。
• Keep chain-of-custody。
• Maintain privilege where directed by counsel。
• Preserve final customer-visible content, not only drafts。
• Preserve tool side effects and human approvals。
• Avoid overwriting model, prompt or RAG source versions。
• Track evidence gaps explicitly。

Minimum evidence fields:

Fact ledger states:

Replay package:

customer context allowed at time
prompt and policy bundle
retrieved source IDs and source hashes
model/provider/version
AI output
claim scan or policy decision
human edit and approval
tool action and side effect
final customer communication
complaint or remediation record
incident containment and correction

---

12. Tabletop Exercises

Exercises should test decision rights, evidence, communication and risk transfer, not only technical recovery。

Scenario 1: Misleading AI Product Claim

An AI-generated credit card landing page variant says customers are "guaranteed approval"
after a soft-check prequalification flow. The variant ran for 18 hours in two states.
Complaints mention annual fee confusion and approval denial after application.

Expected actions: freeze campaign, preserve content object/prompt/approval/audience/applications, build affected cohort, route to claim substantiation and remediation review, screen customer/regulator/board/insurer/vendor pathways。 Evidence: final pages, claim library entry, campaign approvals, customer exposure list, application outcomes, complaints, model/prompt/version, correction message。

Scenario 2: Prompt Trace Data Exposure

A vendor support portal exposes AI prompt traces containing account context and complaint notes.
The exposure window is uncertain. Vendor states no evidence of misuse.

Expected actions: activate cyber/privacy and AI incident bridge, legal hold, determine data fields and affected population, evaluate notification pathways, provide cyber/E&O notice support as appropriate, review vendor breach/data/subprocessor obligations。 Evidence: vendor notice, access logs, trace samples, data field inventory, customer mapping, DPA and contract terms, insurer notice record, remediation plan。

Scenario 3: Lending AI Decision Support Error

A lending policy assistant summarized an exception policy incorrectly for three weeks.
Underwriters used the summaries in decline rationale drafts.

Expected actions: stop affected route, preserve AI runs/edits/final notices, query affected applicants, review fair lending/adverse action/remediation implications, map AI contribution vs human approval vs source issue, quantify customer remediation and defense cost。 Evidence: prompt/source manifests, approval packets, final notice versions, applicant cohort, policy effective date, QA findings, remediation decisions。

Scenario 4: Vendor Model Change

The model provider silently changes safety and summarization behavior.
Complaint response drafts become more definitive and omit conditional language.

Expected actions: freeze route, compare output drift and employee copy behavior, preserve vendor release notes/model route logs, check contract model change notice/audit rights, analyze exposure and correction need。 Evidence: model route IDs, output samples, employee edit deltas, final sent emails, vendor communications, contract clauses, complaint links。

Scenario 5: Evidence Export Failure

During a customer-facing AI incident, the observability vendor cannot export traces
for high-risk workflows. Application logs are partial but final channel messages exist.

Expected actions: enable local evidence ledger, move Tier 1 workflows to draft-only or safe-stop, preserve final channel records, escalate vendor audit/export rights, assess defensibility gap, capture insurance and vendor recovery implications。 Evidence: failed export logs, local ledger, final messages, missing trace report, vendor SLA/ticket, recovery gate record。

---

13. Operating Model

Decision rights:

RACI:

Governance cadence:

---

14. Metrics and KRIs

Incident metrics:

KRIs:

Dashboard views: incident class trend, use case heatmap, customer impact, remediation status, vendor contribution, SLA status, insurance notice and claim status, loss estimate range, evidence completeness, CAPA aging, repeat control failures。

---

15. 30-Day Lab

目标: 30 天内完成一个 AI Incident Disclosure / Liability / Insurance / Risk Transfer system evidence pack。推荐选择 credit card AI marketing claim、lending AI decision support、complaint response agent、insurance underwriting AI 或 prompt trace exposure。

---

16. Decision Narrative

Disclosure Support Architecture

核心判断:

AI incident disclosure architecture 不让系统自动决定是否披露。它把事故事实、客户影响、业务影响、控制状态、vendor dependency、insurance notice 和证据链组织成 decision-ready pack, 支持 legal、disclosure committee、risk、board、regulator 和 insurer-facing workflow。架构边界是提供证据和结构, 不做法律或覆盖结论。

系统推演:

每个 incident record 要连接 ai_run_id、source manifest、model route、tool action、approval packet、final channel event、affected population query、loss estimate、vendor contract reference 和 insurance notice assessment。决策者看到的不是“模型坏了”这一句, 而是 confirmed facts、unknowns、customer exposure、control weakness、timeline、open decisions 和 evidence gaps。

Cyber Disclosure Boundary

核心判断:

是否进入 cybersecurity disclosure analysis 取决于事实是否存在 cyber nexus, 例如 unauthorized access、data exposure、system compromise、tool token abuse 或 cyber business disruption。SEC cyber disclosure anchor 面向 registrants 的 material cybersecurity incidents, 不是所有 AI incident。

系统推演:

AI incident intake 要把 cyber/privacy facts 与一般 model quality issue 分离: access path、data exposure、credential/token status、system compromise、business disruption、financial impact、qualitative impact、control status 和 uncertainty 都要进入 materiality support pack, 由 securities counsel 和 disclosure process 判断。

AI Claims Incident Control

核心判断:

AI 功能 claim、收益 claim、approval claim、accuracy claim、risk claim 都需要 substantiation。内容系统不能只生成流畅文案, 还要管理 approved claim library、forbidden claim、evidence source、pre-use review、final-channel capture 和 correction workflow。

系统推演:

Marketing、product page、chatbot、advisor script 和 customer email 都应连接 claim ID、supporting evidence、approval status、publication channel、audience、expiry 和 correction owner。事故发生时, 系统能定位谁看到了哪个 claim、依据是什么、是否过期、如何下架或更正。

Liability Boundary Reconstruction

核心判断:

Liability boundary 从客户影响往回追: final customer communication or business action、human approval、AI output、prompt/policy bundle、RAG source、tool action、model route、vendor dependency 和 governance controls。责任分析需要区分 AI-caused、AI-contributed、human override、vendor-caused、data-caused 和 control-caused。

系统推演:

Evidence pack 不只保存 output, 还要保存 source version、retrieval reason、tool payload、approval evidence、policy decision、vendor SLA state、exception approval 和 final customer artifact。这样才能把客户损害、系统行为、人类决策和第三方边界连接起来。

Insurance Mapping Discipline

核心判断:

Insurance mapping 的第一原则是不先下“赔不赔”结论。事实应被映射到可能相关的 policy lines: cyber、E&O、tech E&O、media、D&O、crime 等, 再准备 notice trigger、date discovered、claim/circumstance、loss category、evidence、consent requirements 和 uncertainty。

系统推演:

Coverage conclusion 由 broker、coverage counsel 和 insurer process 确认。架构要确保 notice support pack 可以在时限内产出: facts, timeline, affected systems, loss categories, mitigation steps, vendor contribution, known/unknown distinction, preservation status and communication approvals。

Vendor Recovery And Insurance Rights

核心判断:

Vendor indemnity 和 insurance 是不同 risk transfer channels。Vendor indemnity 依赖合同义务、breach、notice、cap 和 evidence；insurance 依赖 policy wording、facts、notice、exclusions 和 retention。成熟架构同时保留 vendor recovery 和 insurance notice 权利, 但不假设任何一方自动补偿全部损失。

系统推演:

Vendor contract matrix 要记录 SLA、audit right、subprocessor、indemnity、limitation of liability、notice path、required evidence、insurance requirement 和 cooperation obligation。Insurance map 要记录 policy line、notice window、loss bucket、consent-to-settle or remediation constraints, 并与 incident timeline 对齐。

Evidence Gap As Incident

核心判断:

Evidence gap 本身就是 AI incident。无法复原 prompt、source、model、tool、approval 和 final customer message 时, 机构无法证明发生了什么、客户是否受影响、谁应负责、是否需要通知、保险或 vendor recovery 是否成立。

系统推演:

Evidence export failure、missing source IDs、vendor portal unavailable、retention mismatch、trace ID discontinuity 和 final-channel capture gap 都应进入 incident taxonomy。它们会削弱 disclosure support、defense、regulator response、claim recovery 和 CAPA prioritization。

Risk Transfer Value

核心判断:

AI 风险不能只靠买保险转移。治理层需要知道哪些风险由 product controls 降低, 哪些由合同转移给 vendor, 哪些通过 insurance notice 保留, 哪些必须自留并准备 reserves。

系统推演:

Risk transfer architecture 的价值是把证据、合同、保单、损失和治理放到同一张图上。它让 incident response 不只恢复服务, 还同步完成 fact preservation、loss quantification、recovery option preservation、communication control 和 corrective action prioritization。

---

17. System Evidence Pack

System narrative:

The AI incident risk transfer architecture preserves facts before conclusions,
quantifies customer and financial impact before communication,
maps liability before recovery actions,
and keeps disclosure, vendor, insurance and board workflows tied to the same evidence base.

---

18. Design Review Questions

---

19. Self-Assessment Checklist

---

20. Final Operating Principle

AI incident maturity can be tested with one question:

If a serious AI incident happens today, can the institution preserve evidence,
bound customer harm, support disclosure decisions, notify the right parties,
map liability, preserve insurance rights, pursue vendor recovery,
quantify loss, communicate consistently, and prove every step later?

如果答案不清楚, 问题不是少一个 incident form。问题是 AI product architecture、third-party risk、insurance, legal, compliance, board governance and evidence engineering 还没有被真正连接起来。