AI Traceability Requirements / Eval / Control Graph Playbook

面向对象: 高级 AI PM / AI BA / Product Architect / Solutions Architect / Enterprise Architect / EvalOps Lead / AI Governance / Model Risk / Internal Audit / 金融零售 AI 转型负责人。

目的: 把传统 BA 的 requirements traceability 升级为 AI 系统的 requirement -> eval -> control -> architecture decision -> implementation/config -> telemetry -> incident -> evidence graph, 用于产品设计, 架构治理, 上线门禁, 审计证据和作品集展示。

核心观点: AI traceability 不是把 PRD 条目连到测试用例, 而是证明一个 AI 能力在特定业务结果, 风险边界, 系统版本和运行证据下可被测量, 控制, 追责和持续治理。

使用方式: 每个高影响 AI use case 至少维护一张 Traceability Graph Table, 一张 Coverage Matrix, 一组 Evidence Queries, 一份 Release Decision Memo, 一组 Audit Q&A 和一份 Portfolio Evidence Pack。

重要说明: 本文是学习, 作品集和治理设计材料, 不是法律意见, 审计意见, 模型验证结论或监管解释。正式项目必须由 Legal, Compliance, Risk, Model Risk, Internal Audit, Security, Privacy, Data Owner 和业务管理层按适用司法辖区确认。

---

1. Source Anchors

以下官方来源作为 traceability graph 的方法锚点。本文把它们转成金融零售 AI 项目的需求工程, 评测门禁, 控制证据, 架构治理和审计问询资产。访问日期按 2026-06-29 记录。

Standards-to-artifacts:

---

2. One-Sentence Positioning

AI Traceability Graph = 把业务目标, AI 需求, 评测契约, 控制活动, 架构决策, 配置版本, 生产遥测, 事故复盘和审计证据连接成一张可查询, 可复核, 可治理的证据图。

最小链路:

Business outcome
-> stakeholder concern
-> AI requirement
-> eval question
-> eval case / metric / threshold
-> control objective / control activity
-> ADR
-> implementation / prompt / RAG / tool / policy config
-> telemetry signal
-> incident / exception / change
-> evidence artifact
-> release or assurance decision

高级 BA 的差异化不在于“能不能画 traceability matrix”, 而在于能否回答:

1. 这个 AI 需求为什么服务某个业务结果和风险结果。
2. 这个需求如何被 eval contract 证明, 而不是靠 demo 证明。
3. 哪些控制降低了 AI 的误用, 幻觉, 越权, 泄露, 偏差和过度依赖风险。
4. 哪个 ADR 解释了模型, RAG, tool, logging, fallback 和 human oversight 的关键选择。
5. 哪些配置版本在生产中真实运行。
6. 哪些 telemetry 可以证明 AI 行为仍在边界内。
7. 哪个 incident 或 exception 影响哪些需求, eval, 控制和证据。
8. 审计或监管问询时, 如何从问题追到证据路径。

---

3. 为什么 AI 需求不能只停在 User Story

User story 适合表达用户目标和交互意图, 但 AI 系统的真实风险通常不在 story 文案里, 而在概率行为, 数据来源, 工具权限, 模型版本, 人工控制, 运行漂移和证据缺口里。

3.1 User story 的失效点

User story 可以保留, 但只能作为 graph 的一个节点。AI requirement 必须进一步转成:

User story
-> decision boundary
-> data and knowledge boundary
-> behavior requirement
-> risk requirement
-> eval requirement
-> control requirement
-> telemetry requirement
-> evidence requirement

3.2 弱需求与强需求

3.3 从 CBAP Traceability 到 AI Traceability

本文不重复 CBAP 需求生命周期基础。升级点如下:

一句面试表达:

传统 traceability 证明“需求被实现和测试”。AI traceability 还要证明“行为在风险边界内被评测, 控制, 监控, 复核, 变更和审计”。这就是 CBAP 能力在 AI 系统里的升级。

---

4. Traceability Graph Nodes

Traceability graph 的节点不是越多越好, 而是每个节点都必须回答一个治理问题。下面 taxonomy 适合金融零售 AI 项目。

4.1 Node metadata standard

每个高价值节点至少包含:

4.2 W3C PROV 映射

用 PROV 思路可以避免证据链混乱:

一句话:

Evidence is credible when the graph can show which activity generated it, which entity it used, which agent approved it, and which decision it supported.

---

5. Traceability Graph Edges

Edges 是图谱的治理价值。节点只是对象清单, edge 才回答“为什么相关”。

5.1 Edge cardinality rules

5.2 Edge anti-patterns

---

6. End-to-End Chain: Outcome to Evidence

下面链路是本文的核心模板。它把需求工程, 评测, 控制, 架构, 生产运行和证据治理放在同一张图里。

Business outcome
-> Requirement
-> Eval
-> Control
-> ADR
-> Implementation / Config
-> Telemetry
-> Incident / Exception
-> Evidence

6.1 Release gate view

6.2 Audit view

---

7. Graph Architecture and Operating Model

Traceability graph 不一定一开始就是图数据库。高级做法是先把 ID, edge, owner, evidence 和 query discipline 建起来, 再决定工具形态。

7.1 Maturity levels

7.2 最小可行 schema

7.3 OpenTelemetry instrumentation discipline

生产 telemetry 必须能回连 graph, 否则运行证据会断链。

建议核心 attributes:

7.4 RACI

---

8. Financial Retail Case: Customer Service AI Policy Copilot

8.1 Use case boundary

8.2 Traceability graph sample

8.3 Coverage matrix

8.4 Release decision interpretation

---

9. Financial Retail Case: AML Investigation Agent

9.1 Case graph

9.2 Audit-ready Q&A path

---

10. Financial Retail Case: Credit Memo Copilot

10.1 Boundary

10.2 Traceability example

10.3 Senior interview point

In credit, I would treat AI as a memo and control assistant, not a decision engine, unless the institution has explicitly approved that automation boundary. My traceability graph would make this visible: every credit-impacting requirement links to eval slices, fair-lending controls, decision-system permissions, reviewer evidence and production telemetry.

---

11. Templates

这些模板使用“字段 + 合格样例”的方式, 避免空表格。正式项目可以把样例替换为机构内真实 ID 和证据编号。

11.1 Traceability Graph Table

11.2 Coverage Matrix

11.3 Evidence Query Examples

Evidence queries 可以先用 SQL, graph query, spreadsheet filter 或 GRC 报表表达。关键是查询语义清楚。

Query A: high-risk requirements without eval coverage

SELECT r.node_id, r.title, r.owner
FROM trace_nodes r
LEFT JOIN trace_edges e
  ON e.source_node_id = r.node_id
 AND e.edge_type = 'verifies'
WHERE r.node_type = 'requirement'
  AND r.risk_tier IN ('high', 'critical')
  AND e.target_node_id IS NULL;

Decision use: release readiness review。结果非空时, 高风险需求不得进入 production release。

Query B: evidence supporting a release claim

SELECT c.node_id AS claim_id,
       ctrl.node_id AS control_id,
       ev.evidence_id,
       ev.artifact_type,
       ev.version,
       ev.reviewed_by,
       ev.quality_score
FROM trace_nodes c
JOIN trace_edges e1 ON e1.source_node_id = c.node_id AND e1.edge_type = 'mitigated_by'
JOIN trace_nodes ctrl ON ctrl.node_id = e1.target_node_id
JOIN trace_edges e2 ON e2.source_node_id = ctrl.node_id AND e2.edge_type = 'supports'
JOIN trace_evidence ev ON ev.evidence_id = e2.target_node_id
WHERE c.node_id = 'CLAIM-CS-DECISION-BOUNDARY';

Decision use: audit response。输出用于证明 AI 不做最终客户影响决定。

Query C: change impact from prompt version

SELECT impacted.target_node_id,
       impacted.edge_type,
       n.node_type,
       n.title,
       n.owner
FROM trace_edges changed
JOIN trace_edges impacted
  ON impacted.source_node_id = changed.target_node_id
JOIN trace_nodes n
  ON n.node_id = impacted.target_node_id
WHERE changed.source_node_id = 'CFG-PROMPT-CS-P12'
  AND changed.edge_type = 'impacted_by';

Decision use: change advisory board。prompt 变更必须列出受影响需求, eval, controls, telemetry 和 evidence。

Query D: production incidents not yet in regression set

SELECT i.node_id, i.title, i.owner
FROM trace_nodes i
LEFT JOIN trace_edges e
  ON e.source_node_id = i.node_id
 AND e.edge_type = 'observed_in'
WHERE i.node_type = 'incident'
  AND i.risk_tier IN ('high', 'critical')
  AND e.target_node_id IS NULL;

Decision use: monitoring gate。高风险线上失败必须进入 regression dataset 或有正式风险接受记录。

11.4 Release Decision Memo

# Release Decision Memo: Retail Service AI Policy Copilot r18

## Scope
- Use case: Customer service policy copilot for credit card fee, dispute and account-service questions.
- Release stage: Limited release to 10% trained agents.
- AI role: retrieve, summarize, draft, cite, classify high-risk intents.
- Excluded actions: direct customer send, fee waiver commitment, credit approval, legal conclusion.
- Version set: model `gpt-4.1-prod`, prompt `cs-p12`, knowledge base `retail-policy-2026-06`, tool schema `read-only-v3`.

## Traceability Summary
| Area | Result |
|---|---|
| Requirements | 14 active high-risk requirements, all mapped to eval and controls. |
| Eval | 6 eval suites passed; critical unauthorized commitment count = 0. |
| Controls | 9 required controls active; citation audit and escalation queue are release blockers. |
| Architecture | ADR-CS-007 and ADR-CS-010 approved by architecture and compliance reviewers. |
| Telemetry | Required OpenTelemetry attributes present in 99.8% of pilot traces. |
| Evidence | 18 evidence artifacts indexed with owner, version, reviewer and retention. |

## Decision
Limited go for 10% trained agents for 30 calendar days.

## Conditions
- Customer self-service channel remains disabled.
- Weekly citation audit covers fee, dispute and complaint slices.
- Any confirmed unauthorized commitment triggers immediate stop rule.
- Prompt, knowledge base, tool schema or escalation policy change triggers regression eval.

## Residual Risk
Agents may over-trust fluent drafts. Mitigation: UI boundary disclosure, mandatory agent final action, edit-diff logging, QA sampling and targeted training.

## Approvals
Business Owner, Compliance Reviewer, Model Risk Reviewer, AI Product Owner, Chief Architect delegate and Operations Owner approved this limited release decision on 2026-06-20.

11.5 Audit Q&A

11.6 Portfolio Evidence Pack

---

12. Review Checklist

12.1 Requirement traceability

• 每个 high-risk AI requirement 是否连接 business outcome 和 stakeholder concern。
• 每个 requirement 是否写清 allowed behavior, forbidden behavior, decision boundary 和 risk tier。
• 每个 behavior requirement 是否有 eval question, dataset slice, metric 和 threshold。
• 每个 critical failure 是否独立作为 release blocker, 不被平均分抵消。
• 每个 requirement 是否连接 control objective 和 control activity。
• 每个 requirement 是否有 telemetry signal 支持生产监控。

12.2 Architecture traceability

• 每个关键 ADR 是否说明影响哪些 requirement, control, telemetry 和 evidence。
• 模型, prompt, RAG index, tool schema, policy source 和 guardrail 是否分别有版本。
• tool action 是否有 allowlist, permission, approval 和 rollback path。
• logging 是否能重建版本, 来源, 用户动作和人工复核。
• fallback 和 stop rule 是否有生产演练或测试证据。

12.3 Evidence traceability

• 每个 release claim 是否至少有一份直接 evidence 支撑。
• 每份 evidence 是否有 owner, version, generated_at, reviewer, retention 和 quality score。
• evidence 是否能追到生成活动和审批 agent。
• evidence 是否覆盖当前生产版本, 而不是旧模型或旧 prompt。
• incident closure 是否包含 root cause, remediation, regression result 和 monitoring confirmation。

12.4 Operating model traceability

• 业务 owner 是否负责 outcome 和 residual risk narrative。
• control owner 是否负责控制活动和运行频率。
• evidence owner 是否负责证据质量和刷新。
• EvalOps 是否负责 failed case 回流和 regression dataset。
• Model Risk, Compliance, Internal Audit 是否能通过 graph 查询同一口径材料。

---

13. Common Failure Modes

---

14. Interview Expressions

Q1: 你如何把传统需求追踪升级成 AI traceability?

30 秒回答:

我会把 traceability 从 “requirement 到 test case” 扩展成 “business outcome 到 evidence”。对 AI 系统, 每个高风险需求都要追到 eval contract, 控制目标, ADR, 版本配置, 生产 telemetry, incident loop 和审计证据。这样不只是证明功能做了, 还证明 AI 行为在风险边界内被测量, 控制和持续治理。

2 分钟回答:

传统 traceability matrix 通常回答需求是否被设计和测试。AI 系统还需要回答概率行为, 数据来源, 模型版本, 工具权限, 人工复核和上线后漂移。因此我会先定义 business outcome 和 stakeholder concern, 再写 AI requirement 的 allowed / forbidden behavior 和 decision boundary。随后把需求映射到 eval question, dataset slice, metric, threshold 和 critical failure。每个风险再映射到 control objective, control activity 和 test evidence。架构上用 ADR 记录模型, RAG, tool, logging 和 fallback 决策; 生产上用 OpenTelemetry attributes 把 trace 连接到 requirement, model version, prompt version, kb version 和 incident。最后审计问询可以从问题追到 claim, control 和 evidence path。

Q2: 为什么 user story 不足以管理 AI 需求?

30 秒回答:

User story 只能表达用户意图, 不能表达 AI 的评测样本, 失败严重度, 控制活动, 版本边界, telemetry 和审计证据。AI 需求必须变成行为契约和证据链。

2 分钟回答:

例如 “作为客服坐席, 我希望 AI 回答政策问题” 是一个有用入口, 但它不能告诉我们政策来源是否有效, 是否允许承诺费用减免, 哪些投诉必须升级, 错误回答如何被发现, 哪个版本在生产, 事故后如何回归测试。我的做法是把 story 作为图谱节点之一, 再扩展出 decision boundary, data/knowledge boundary, eval contract, control objective, ADR, telemetry 和 evidence。这样需求可以上线, 也可以被审计。

Q3: 你如何设计 AI release gate 的 traceability?

30 秒回答:

我会让 release gate 基于 graph query, 而不是会议印象。它必须证明 high-risk requirements 有 eval coverage, critical failures 为 0 或已限制范围, 控制证据有效, telemetry 就绪, residual risk 有 owner 和期限。

2 分钟回答:

Release gate 的输入包括 requirement coverage matrix, eval run report, failed case list, control evidence, ADR approval, telemetry readiness, incident response plan 和 residual risk acceptance。比如客服 AI 如果有 unauthorized commitment, 即使平均准确率很高也 no-go。如果 citation 支持率在高风险切片达标, 日志完整率达标, 人工复核真实运行, 那可以 limited go。关键是每个结论都能追到图谱路径, 例如 requirement -> eval case -> metric -> control -> ADR -> trace sample -> evidence -> decision。

Q4: 如何把 OpenTelemetry 用到 AI governance?

30 秒回答:

我会把 OpenTelemetry 当作 AI evidence graph 的生产连接层。每次 AI 调用都带 use_case_id, requirement_id, eval_contract_id, model_version, prompt_version, kb_version, tool decision, citation status 和 escalation result。

2 分钟回答:

很多 AI 项目上线后无法回答“错误来自哪个版本, 哪个政策, 哪个工具调用, 哪个用户动作”。所以可观测性不能只看 latency 和 cost。对金融零售 AI, trace attributes 必须能支持审计复盘和控制验证。例如 RAG 回答要记录 kb_version, policy_version, citation_status; Agent 工具调用要记录 tool_name, tool_decision, approval result; 人工复核要记录 review outcome 和 edit diff hash。这样 incident 可以从 production trace 回连 requirement, eval, control 和 evidence。

Q5: 面对监管或内审, traceability graph 的价值是什么?

30 秒回答:

它让团队不再临时找材料, 而是从监管问题直接追到 claim, requirement, control, test, evidence, owner 和 decision record, 并且能说明证据适用于哪个版本和时间窗口。

2 分钟回答:

监管或内审通常不会只问“有没有测试报告”, 而会问 AI 是否会做最终决策, 如何证明数据权限没有扩大, 政策回答是否当前有效, 事故如何整改, 谁接受剩余风险。Traceability graph 可以把这些问题转成路径。例如 “AI 不做最终信贷决定” 连接到 decision boundary requirement, tool permission control, ADR, RBAC test, workflow log 和 release memo。这个结构比共享盘文件夹更稳, 因为每份证据都有 owner, version, reviewer, retention 和支持的 claim。

Q6: 你如何把这套能力做成作品集?

30 秒回答:

我会选一个金融零售 AI 用例, 例如客服 policy copilot 或 AML investigation agent, 做一套 outcome-to-evidence case pack: traceability graph, coverage matrix, eval contract excerpt, ADR, telemetry spec, audit Q&A 和 release decision memo。

2 分钟回答:

作品集不要只放 PRD。高级 AI PM/BA/Architect 的价值在于能跨业务, 需求, 架构, 风险和审计。我会展示一个完整链路: 先用一页 executive narrative 说明业务目标和风险边界; 然后用 traceability graph 说明每个高风险需求如何被 eval, control, ADR, telemetry 和 evidence 覆盖; 再用 release decision memo 说明为什么是 limited go 而不是 full release; 最后用 audit Q&A 模拟监管问询。这样面试官能看到我不是只懂需求文档, 而是能把 AI 系统推到可治理上线。

---

15. Final Memory Card

最重要的一句话:

AI traceability 的目标不是证明团队写过需求, 而是证明组织知道这个 AI 为什么存在, 如何被评测, 被哪些控制约束, 以什么版本运行, 发生问题如何复盘, 以及用什么证据接受上线和持续运营。