AI Management Information / Board Reporting Architecture 解读

配对阅读：本篇的操作手册版（模板/RACI/门禁/runbook）是 docs/AI_MANAGEMENT_INFORMATION_BOARD_REPORTING_PLAYBOOK.md。第一遍读本篇建立原理与架构判断；第二遍做案例时再用 playbook 查表落地，两者不需要重复精读。

Source Anchors

核心导读

AI Management Information / Board Reporting Architecture 不是把 AI 项目周报换成董事会格式，也不是堆更多图表。它要把 AI portfolio 的事实、价值、风险、控制有效性、客户伤害、事件、供应商集中度、采用质量和整改动作做成可追溯的信息产品，让管理层、董事会和审计委员会能监督、挑战、投资、暂停、扩张或要求整改。

成熟的 MI architecture 关注“董事会依赖的事实如何生成、校验、追溯和触发行动”。没有这层架构，board pack 很容易退化为 innovation showcase、项目状态报告或人工拼接的证据 collage：看起来完整，但无法回答数字从哪里来、定义是否稳定、阈值是否合理、谁负责行动、行动是否关闭。

可以把它理解为：

AI Board MI =
  metric contract
  + telemetry/evidence lineage
  + risk appetite threshold
  + management action
  + board decision use

1. 问题定义

董事会和审计委员会通常不缺 AI 叙事，缺的是可决策事实。关键问题包括：

What facts feed board oversight?
How is each metric defined?
Where did the number come from?
Which threshold makes it reportable?
Who owns remediation?
What decision can be made from it?

金融零售 AI 的管理信息难点不在“缺少数据”，而在“数据不能形成可决策事实”。模型网关有 token、latency、usage；客服系统有投诉和质检；风险系统有事件和控制测试；财务系统有成本和收益。但如果这些系统没有共同的定义、lineage、阈值和 action loop，董事会只能看到活动量，不能判断 value、risk、control effectiveness 和 customer harm 是否在风险偏好内。

治理材料回答“谁监督、监督什么、在哪个委员会决策”。MI architecture 回答“监督依赖的事实如何产生、质量如何保证、异常如何行动、报告如何被审计”。

2. 架构模型

AI MI 要以指标契约为中心，而不是以 PPT 页面为中心。每个 board-level metric 都必须有定义、来源、口径、阈值、负责人、更新频率、数据质量规则和行动含义。

AI systems and workflows
  -> model gateway / agent gateway telemetry
  -> RAG and knowledge source logs
  -> tool action and workflow event logs
  -> control tests, evals, red-team, QA samples
  -> incidents, complaints, customer harm, appeals
  -> cost, adoption, value, finance baseline
  -> vendor, model, dependency and inventory registry
  -> MI data product layer
       - metric contracts
       - lineage graph
       - quality rules
       - threshold and risk appetite rules
  -> management dashboards
  -> board / audit committee pack
  -> decision, action, attestation and evidence closure

Metric contract

MI lineage

business event
  -> AI trace
  -> control/eval result
  -> data quality rule
  -> metric calculation
  -> dashboard tile
  -> board statement
  -> management action

如果 board pack 写着“AI customer harm incidents decreased 20%”，机构应能展示 incident taxonomy version、source systems、de-duplication logic、severity rule、customer impact classification、query version、owner sign-off 和 action status。

SR 26-2 语境

SR 26-2 的价值在于把金融机构 MI 拉回 risk-based、materiality-driven、inventory、monitoring 和 governance 的思维，而不是把所有 GenAI/agentic AI 机械塞进同一套模型风险表。AI board MI 应分层呈现：

• 传统模型风险范围内的复杂定量模型和关键估计。
• 非生成式 AI 或自动化决策中可沿用模型风险原则的部分。
• GenAI、RAG 和 agentic AI 的 broader AI controls，包括 prompt、corpus、tool authority、human oversight、eval、incident、change 和 evidence。

董事会需要 consolidated AI value/risk view，同时也需要看清不同治理域的边界，避免 scope confusion。

3. 关键机制/生命周期

AI MI 的生命周期从 use case 入库开始，到指标退役或控制关闭结束。

define oversight decision
  -> create metric contract
  -> map source systems and lineage
  -> define data quality rules
  -> set thresholds and action triggers
  -> publish management dashboard
  -> produce board view
  -> challenge / decide / fund / hold / remediate
  -> track action closure
  -> attest and archive evidence
  -> review metric relevance

关键机制包括：

• Decision-first metric design：每个指标都要指向 scale、hold、stop、fund、remediate、accept residual risk 之一；否则只是观察性数据。
• Metric contract versioning：口径、分母、抽样方法、阈值、source system 改变时，要能解释趋势变化来自业务现实、定义变化还是数据质量。
• Risk appetite threshold：红黄绿不是美化，而是控制；阈值要连接已批准的 risk appetite、stop rule、escalation 和 exception。
• Action log closure：每个 amber/red signal 都必须连接 owner、due date、status、closure evidence 和 residual risk。
• Attestation and challenge：报告前需要 owner signoff、数据质量检查和可挑战记录；报告后需要记录董事会或管理层的 challenge 与决定。

一个轻量 lineage prototype 可以用结构化数据验证 MI 可行性：

Input entities:
  ai_trace(response_id, use_case_id, model_id, timestamp, source_doc_ids, ai_exposed)
  qa_review(response_id, supported_by_source, regulated_topic, reviewer_id, review_date)
  complaints(case_id, response_id, severity, ai_attributable, remediation_required)
  metric_contract(metric_id, numerator_rule, denominator_rule, threshold_green, threshold_red, owner)

Metric:
  unsupported_claim_rate =
    count(response_id where regulated_topic = true and supported_by_source = false)
    / count(response_id where regulated_topic = true and qa_review exists)

Lineage output:
  metric_id, reporting_period, source_tables, query_version,
  denominator_count, numerator_count, threshold_status, action_required

学习价值不在于 SQL 本身，而在于能解释董事会数字为何变化：真实业务变化、指标定义变化、数据质量变化、source-system 延迟，还是阈值更新。

4. 证据与控制

MI control 的核心是让报告数字可被重建、挑战和行动。它要求数据产品、治理流程和报告材料共享同一套事实基础。

Board-level MI 应覆盖 value、risk、control、harm、adoption、cost 和 concentration，避免单一维度叙事。

5. 金融零售/AI产品场景

Scenario: A retail bank runs six AI systems.

董事会监督议题应转成可追溯 MI：

一个 decision-useful board slice 应该类似这样：

Decision requested:
  approve limited scale of customer service RAG to two additional product lines.

Evidence:
  qualified value events 74%;
  unsupported claim rate 1.6%;
  source freshness SLA 99.4%;
  AI-attributable complaints flat to baseline;
  vendor concentration amber.

Management action:
  scale low-risk intents only;
  run cross-use-case regression before credit-card dispute policies;
  reduce model concentration before direct customer response.

这里的关键不是格式，而是每个数字都有 metric contract 和 lineage，每个异常都有 action owner，每个扩张决定都有边界条件。

6. 反模式

7. 最终心智模型

AI board reporting 的成熟度不在于页面多漂亮，而在于董事会看到的每个关键数字是否能被追溯、解释、挑战和行动。MI 是一个信息架构问题：把生产事实、控制测试、客户影响、价值结果、供应商依赖和整改动作转成 decision-useful evidence。

最终要形成一条稳定链路：

business event
  -> AI trace
  -> metric contract
  -> lineage and quality rule
  -> risk appetite threshold
  -> management dashboard
  -> board decision
  -> action closure evidence

董事会不需要更多 AI activity reporting。它需要证据证明 value、risk、control effectiveness、customer harm、concentration 和 adoption 在风险偏好内，或者已经被明确 owner 和行动计划接住。

---

SOTA 状态标注 (2026-07-01)

本篇属于第二、三遍深读池（参考架构/深读笔记），未列入 12 周主线必读。时效基线为写作时点；引用前请按 CLAUDE.md 全局时效性硬规则复查最新进展。模块级 SOTA 对照见 docs/AI_SYSTEMATIC_LEARNING_ROADMAP_2026.md 各周「2026 SOTA 对照」行与文末「SOTA 检查」。