目录
AI Regulatory Response Playbook
定位: 面向 AI PM / AI BA / Solution Architect / Enterprise Architect 的监管响应学习与落地框架。
重要说明: 本文不是法律意见、合规结论或监管解释，不能替代 legal / compliance / risk 的正式判断。本文的用途是帮助产品、业务分析和架构角色把法规、监管预期和行业框架转化为可执行 artifact、流程、控制和证据。
1. 为什么 AI Regulatory Response 是产品和架构能力
企业 AI 不只是模型上线。它会改变客户权益、员工决策、流程控制、供应商依赖、数据使用和审计证据。监管响应能力的核心不是背诵法规条文，而是能在业务和技术之间建立一条可追溯链路:
Regulatory signal
-> applicability judgment
-> use case risk tiering
-> AI inventory
-> control mapping
-> evidence pack
-> release/change gate
-> incident and regulator response
-> board/management reporting
PM 要回答: 这个 AI use case 是否值得做，影响谁，风险边界在哪里，上线后如何证明业务价值和客户保护。
BA 要回答: 哪些法规、政策、流程、角色、数据、例外和证据需要进入需求，哪些人工决策点不能被 AI 隐性替代。
Architect 要回答: 系统边界、数据流、模型调用、日志、权限、监控、回滚、供应商集成和证据保全如何设计，才能支撑审计和监管沟通。
成熟的 AI 监管响应不是临时写 memo，而是每个高影响 use case 都有清单、分级、控制、证据、责任人、变更记录和问答包。
2. Reference Anchors
以下官方来源作为学习锚点。所有时间线和义务描述均按“截至 2026-06-29 需复核”处理，正式项目必须由 legal / compliance 结合适用司法辖区、实体类型、产品范围和监管关系确认。
使用原则:
不把 anchor 当作完整法律清单。
不在产品文档中直接下法律结论。
把官方来源转成问题清单、artifact 模板和 evidence requirement。
每次监管响应都记录 version、access date、owner 和 legal sign-off。
3. Regulatory Radar
Regulatory radar 的目标是持续识别外部变化，并把变化转成内部行动。它不是新闻收藏夹，而是一个带 owner、影响判断和截止日期的工作机制。
3.1 Radar 监控范围
Radar lane 关注内容 金融零售 AI 例子 Owner AI-specific law AI Act、州级 AI 法、行业 AI 指引、GPAI 规则 EU 客户服务 chatbot 透明度、信贷评分高风险判断 Legal / Compliance Financial regulation consumer protection、ECOA、UDAAP、AML/BSA、model risk、outsourcing AI 信贷拒绝原因、AML case narrative、客服误导 Compliance / Risk Third-party risk vendor due diligence、SLA、critical activity、subcontractor LLM provider、KYC vendor、fraud model vendor Vendor Owner / TPRM Data and privacy consent、purpose limitation、PII、retention、cross-border transfer RAG 知识库、客户录音摘要、交易行为分析 Data Owner / Privacy Security prompt injection、data exfiltration、tool misuse、access control 客服 agent 越权查账户、支付工具调用 Security / Architect Supervisory signals exams、enforcement actions、speeches、FAQs、consultations 监管关注黑箱模型、投诉、第三方依赖 Compliance / Risk Industry standards NIST AI RMF、ISO/IEC 42001、OWASP LLM Top 10 风险分类、控制矩阵、评测门禁 Architect / AI Governance
3.2 Radar 工作节奏
Cadence 输入 输出 决策 Weekly scan 官方更新、监管新闻、供应商通知 Regulatory change log 是否需要 impact screening Monthly review 变更清单、use case inventory、incident trend Regulatory radar brief 哪些 use case 需要重分级或补控制 Quarterly governance 风险 dashboard、证据抽样、外部审计发现 Board / management AI risk update 接受风险、增加预算、暂停或重构能力 Event-driven 新法规、监管问询、重大 incident、vendor model change Regulatory impact memo 启动 response timeline 和 war room
3.3 Radar 记录字段
Field 说明 Source 官方链接、发布时间、access date Jurisdiction EU、US federal、state、UK、APAC 或内部政策 Affected business 信贷、AML、客服、财富、支付、营销、HR、供应链 Affected AI assets inventory 中的 system ID、model ID、vendor ID Trigger 新义务、解释变更、监管问询、事故、供应商变更 Impact hypothesis 可能影响的风险等级、控制、证据、合同、流程 Action owner legal、compliance、risk、PM、BA、architect、vendor owner Due date 决策和整改截止时间 Status new、screening、in review、actioned、accepted、closed
4. Applicability Judgment
适用性判断的目标是回答: 这个 use case 是否落入某个法规、框架、监管预期或内部政策范围。PM/BA/Architect 不做最终法律结论，但要把问题问完整，让 legal / compliance 能高效判断。
4.1 Applicability 判断问题
Question 解释 是否是 AI system? 是否基于模型推断、生成、分类、评分、推荐或自动化工具调用，而不只是普通规则引擎。 角色是什么? 我方是 provider、deployer、importer、distributor、product manufacturer、creditor、service provider 还是 vendor user。 地理范围是什么? 用户、客户、员工、数据主体、实体注册地、服务提供地是否触发 EU、US 或其他地区要求。 是否影响客户权益? 是否影响信贷、账户访问、费用、交易、投诉处理、财富建议、欺诈冻结、KYC/AML 结论。 是否涉及高风险领域? 信贷评分、就业、教育、关键基础设施、身份识别、执法协助等需要特别标注。 是否有自动化决策? AI 是 read、summarize、recommend、draft、decide 还是 act。越靠近 decide / act，控制越强。 是否使用 GPAI / foundation model? 是否调用通用模型、微调模型、RAG、agent framework 或第三方模型 API。 是否使用第三方或外包? 是否涉及 vendor due diligence、合同、subprocessor、SLA、model update 通知和退出计划。 是否处理敏感数据? PII、金融交易、信用报告、健康、未成年人、特殊类别数据、商业机密。 是否需要解释或通知? 信贷 adverse action、客户通知、AI interaction disclosure、投诉回应、审计说明。 是否有人工监督? 谁 review、何时 review、override 如何记录、人工是否真正有能力介入。 是否有证据链? 日志、输入、输出、prompt、model version、retrieval context、approval、test results 是否可复现。
4.2 Regulatory Impact Memo
每个中高风险 use case 都应有一页 Regulatory Impact Memo。它不是法律意见，而是监管影响的共同工作底稿。
Section 内容 Use case summary 业务目标、用户、流程插入点、AI 行为边界 Jurisdiction and entity 涉及地区、法人、客户类型、监管主体 Role analysis provider / deployer / creditor / vendor user / service provider 等角色假设 Trigger analysis 可能触发的 AI、金融、隐私、第三方、消费者保护要求 Risk tier hypothesis PM/BA/Architect 初步分级和理由 Legal questions 需要 legal / compliance 确认的问题清单 Control implications 需要的 disclosure、human oversight、logging、eval、monitoring、vendor controls Evidence implications 需要保留的审批、测试、日志、通知、解释、合同和培训证据 Decision requested proceed、proceed with controls、pause、reject、seek external counsel Sign-off record legal、compliance、risk、business owner、architect、date、version
5. Use Case Risk Tiering
Risk tiering 用来决定控制强度、审批层级、证据厚度和上线门禁。它不等于法律分类，但应与法规分类和内部 risk appetite 对齐。
5.1 四级分层
Tier 定义 金融零售例子 默认决策 Tier 0: Prohibited / Not allowed 违反法律、内部政策或 risk appetite，或缺少可接受控制 欺骗性操纵客户、未经授权生成身份材料、自动决定 SAR 是否提交且无人复核 Reject 或 redesign Tier 1: High impact / Regulatory significant 影响客户权益、金融决策、合规义务、重要运营或可能被监管重点关注 信贷 underwriting 决策辅助、adverse action reason generation、AML case recommendation、账户冻结建议 强制 legal/risk review、human oversight、完整 evidence pack Tier 2: Controlled business use 影响业务流程但不直接决定客户权益，可通过人工复核和限制范围控制 客服回复草稿、KYC 文档缺失检查、财富顾问资料摘要、支付 exception 分流 标准 risk review、eval gate、监控、抽样复核 Tier 3: Low risk productivity 内部效率工具，不处理敏感数据，不影响客户权益 内部会议纪要、公开资料摘要、非客户数据培训助手 轻量登记、数据边界、使用政策确认
5.2 分级维度
Dimension Low Medium High Decision impact 不影响客户或员工权益 影响流程建议或员工判断 影响信贷、账户、费用、交易、合规结论 Automation level read / summarize recommend / draft decide / act Data sensitivity 公开或低敏数据 内部业务数据 PII、金融、信用、AML、身份、受限数据 Explainability need 无正式解释义务 需要业务解释 需要具体、准确、可审计解释 Vendor criticality 可替代工具 支持重要流程 支持 critical activity 或核心控制 Failure harm 可快速纠正 造成客户不便或运营损失 造成客户损害、歧视、监管违规、资金风险 Monitoring maturity 已有指标和抽检 部分指标 无日志、无 owner、无回滚
5.3 Risk Classification Worksheet
Field 填写要求 Use case ID 与 AI inventory 一致 Business capability 信贷、AML、客服、财富、支付等 AI behavior read、summarize、recommend、draft、decide、act Impacted parties 客户、员工、商户、监管、第三方 Data categories 数据来源、敏感度、retention、cross-border Model / vendor model name、version、provider、deployment pattern Regulatory triggers AI Act、ECOA、AML/BSA、third-party、privacy、internal policy Initial tier Tier 0/1/2/3 Required controls human oversight、eval、logging、disclosure、access、vendor controls Residual risk 低、中、高和理由 Approvals PM、BA、Architect、Risk、Compliance、Legal、Data、Security
6. AI Inventory
AI inventory 是监管响应的基础。如果无法列出 AI 系统、模型、数据、owner、供应商和使用场景，就无法证明治理存在。
6.1 Inventory 最小字段
Field 说明 System ID 唯一编号，例如 AI-CRD-001 Name 系统或能力名称 Business owner 对业务结果负责的人 Product owner 对 scope、roadmap、release 负责的人 Technical owner 对架构、运行、回滚负责的人 Risk owner 对风险接受、控制和审查负责的人 Use case description 业务目的和流程插入点 User group 客户、客服、分析师、信贷官、AML investigator、财富顾问 AI pattern RAG、classification、scoring、summarization、agent、workflow automation Model source internal、vendor API、open-source、fine-tuned、GPAI Model version 模型、prompt、embedding、retriever、tool versions Data sources 知识库、交易、CRM、KYC、credit bureau、case history Data classification PII、confidential、restricted、public Jurisdiction 涉及地区和客户群 Risk tier Tier 0/1/2/3 和最近复核日期 Controls control matrix 链接或编号 Evidence binder 证据包位置和版本 Vendor dependency vendor、contract、SLA、subprocessor、exit plan Launch status discovery、pilot、limited release、production、retired Last change 最近模型、prompt、数据、流程或供应商变更 Monitoring 质量、风险、投诉、人工 override、incident 指标
6.2 Inventory 维护规则
没有 inventory ID 的 AI use case 不进入 pilot。
Tier 1 / Tier 2 每次 release 前必须复核 inventory。
Prompt、model、RAG index、tool permission、vendor model update 都是 inventory 变更。
Retired 系统保留 evidence binder 和日志 retention 记录，不直接删除。
Inventory 与 CMDB、model registry、data catalog、vendor registry、risk register 建立引用关系。
7. Control Mapping
Control mapping 是把法规、框架和内部政策转成可验证控制。好的 control matrix 能让审计人员从每个要求追到系统设计、测试结果、运行日志和责任人。
7.1 Control Matrix 模板
Obligation / expectation Risk addressed Control Control owner Evidence Frequency Human oversight AI 错误导致客户权益受损 高风险输出进入人工 queue，人工可查看证据、修改、拒绝、升级 Business Process Owner review log、override reason、training record Continuous + monthly sample Logging and traceability 无法复现 AI 输出 保存 request、prompt version、model version、retrieved documents、tool calls、output、review result Architect / Platform Owner immutable log、trace ID、retention policy Continuous Data quality 偏差、过期或不完整数据导致错误 source validation、freshness check、data quality rules、lineage Data Owner data quality report、lineage diagram Per release + monthly Specific adverse action reasons 信贷拒绝原因不准确或不可解释 决策模型和 reason code 映射经验证，生成式文本只能起草且需人工/规则校验 Credit Risk / Compliance reason code test、sample notices、approval Per release + sample review Vendor risk management 第三方模型变更或中断影响关键流程 due diligence、contract clauses、SLA、change notification、exit plan Vendor Owner / TPRM questionnaire、SOC report、contract extract、review minutes Onboarding + annual + event-driven Transparency / disclosure 用户不知道在与 AI 交互 在 chatbot、生成内容或员工辅助场景中按适用要求提示 AI 使用 PM / Compliance UX screenshot、copy approval、A/B release record Per release Robustness and cybersecurity prompt injection、越权工具调用、数据泄露 red-team、tool allowlist、least privilege、input/output filtering、DLP Security / Architect test report、threat model、access review Per release + quarterly Change management 未评估变更导致控制失效 model/prompt/index/tool/vendor 变更触发 impact assessment 和 regression eval PM / Architect / EvalOps change ticket、eval result、approval Every material change
7.2 控制强度随 tier 调整
Control area Tier 1 Tier 2 Tier 3 Risk approval Legal + Compliance + Risk + Business + Architecture Risk/Compliance review 或 delegated approval Policy acknowledgement Eval golden set、red-team、bias/fairness where relevant、regression gate task eval、safety eval、regression sample lightweight sample Human oversight 强制复核、override 记录、抽样质量复审 关键输出复核或抽样复核 用户自行判断 Logging 完整 trace 和 retention request/output/version log basic usage log Vendor review enhanced due diligence、criticality assessment、exit plan standard due diligence approved tool list Evidence pack 完整 binder，支持 exam/audit 标准 binder 使用登记和政策确认
8. Evidence Pack
Evidence pack 的目标是让团队能在内部审计、外部审计、监管问询、事故复盘和管理层汇报中快速证明: 我们知道 AI 在哪里、风险是什么、控制是什么、证据在哪里、谁批准了上线。
8.1 Evidence Binder 目录
Folder 内容 01-intake opportunity brief、business case、owner map、no-AI alternative 02-regulatory-impact regulatory impact memo、legal questions、sign-off record 03-risk-classification risk worksheet、tier rationale、risk acceptance 04-architecture C4、data flow、sequence diagram、threat model、ADR 05-data data source inventory、classification、lineage、quality report、retention 06-model model card、provider docs、version、limitations、evaluation notes 07-vendor due diligence、contract controls、SLA、subprocessor、exit plan 08-controls control matrix、RACI、human oversight design、access review 09-eval golden set、rubric、test results、red-team report、release gate 10-change change tickets、impact assessments、regression runs、approvals 11-monitoring dashboards、incident logs、complaints、override samples、drift/cost 12-training AI literacy、role training、user guidance、attendance records 13-communications customer disclosure、internal comms、board memo、regulator response drafts 14-postmortem incident report、root cause、corrective actions、control improvements
8.2 Evidence 质量标准
可追溯: 每个 evidence item 都能追到 use case ID、version、owner、date。
可复现: 能复现关键输出的输入、prompt、model、retrieval context、tool calls。
可解释: 能说明控制为什么足够，不能只说“通过测试”。
可抽样: 审计可以随机抽 10 个样本看到一致记录。
可保留: retention 与 legal hold、privacy、security 要求一致。
可防篡改: 关键日志和审批记录避免随意修改。
9. Model and Vendor Due Diligence
AI vendor due diligence 不能只看价格和模型能力。金融零售场景要看供应商是否能支撑监管、审计、稳定性、数据保护和退出。
9.1 Due diligence 维度
Dimension 核心问题 Evidence Business criticality 是否支持 critical activity、客户权益或核心控制 criticality assessment Model transparency 模型能力、限制、训练数据概览、更新策略是否足够透明 model card、provider docs Data protection 输入是否用于训练、数据驻留、加密、retention、deletion DPA、security whitepaper、privacy review Security IAM、network、logging、incident notification、vulnerability management SOC 2、ISO report、penetration summary Compliance support 是否支持审计、监管问询、日志导出、解释和文档 audit clause、support SLA Change notification 模型、API、policy、subprocessor 改变是否提前通知 contract clause、release note process Performance and resilience availability、latency、rate limit、fallback、DR SLA、BCP/DR evidence Subcontractor risk cloud、data processor、annotation、model providers subprocessor list Bias and safety 有无 fairness testing、red-team、安全策略 safety report、eval summary Exit plan 如何迁移模型、数据、prompt、logs、evaluations exit plan、data return/deletion evidence
9.2 Vendor lifecycle
Intake
-> criticality assessment
-> due diligence
-> contract controls
-> pilot controls
-> production monitoring
-> annual/event-driven review
-> incident coordination
-> exit or renewal
9.3 AI-specific contract controls
数据使用限制: 明确客户数据、prompt、output 是否可用于训练或产品改进。
审计和监管支持: 在合理范围内提供文档、日志、控制说明和问询支持。
变更通知: material model change、API behavior change、subprocessor change、security incident 需要通知。
数据保留和删除: 定义 retention、deletion SLA、legal hold 支持。
业务连续性: availability、DR、fallback、rate limit、support hours。
安全控制: encryption、access control、segregation、vulnerability disclosure。
退出权利: 数据导出、模型替换、知识库迁移、日志保留。
10. Change Management
AI 系统的变更不是只有代码发布。模型、prompt、retriever、知识库、工具权限、阈值、人工流程、供应商策略都会改变风险。
10.1 Material change triggers
Change type 风险 Gate Model upgrade 输出行为、解释、偏差、成本、延迟变化 regression eval + risk review Prompt change 政策语气、拒答、工具调用边界变化 prompt diff + eval RAG index update 引用错误、过期政策、权限污染 knowledge owner approval + retrieval eval Tool permission change agent 越权执行交易、查账户、改客户资料 security review + approval workflow Data source change 数据质量、授权、跨境、偏差变化 data owner review + lineage update Risk tier change 控制强度和审批层级不匹配 legal/risk review Vendor change SLA、数据处理、模型行为、subprocessor 变化 TPRM event review Workflow change 人工监督失效或责任转移 BA process review + training update Regulatory change 现有控制不足 regulatory impact memo refresh
10.2 Change ticket 必填字段
Field 内容 Change summary 变更内容和业务原因 Affected inventory IDs 影响的系统、模型、数据、vendor Risk impact tier 是否变化，客户权益是否变化 Eval impact 需要重跑的 golden set、red-team、regression Control impact control matrix 是否需要更新 Evidence impact binder 哪些目录需要新增版本 Rollback plan 触发条件、回滚步骤、责任人 Approval PM、Architect、EvalOps、Risk、Compliance、Data、Security
11. Incident and Regulator Response
AI incident 不只包括系统宕机，也包括错误输出、幻觉、歧视性结果、客户误导、数据泄露、越权工具调用、供应商模型变更导致质量下降、无法解释的信贷拒绝原因等。
11.1 Severity 分类
Severity 定义 示例 Sev 1 客户重大损害、监管义务触发、数据泄露、资金损失、广泛错误决策 AI 支付工具错误发起退款、信贷拒绝原因批量错误、客户 PII 泄露 Sev 2 有限客户影响、重要流程中断、合规风险需要快速控制 客服 chatbot 持续给出错误费用政策、AML narrative 漏掉关键证据 Sev 3 内部流程或小范围质量问题，可通过修复和抽样控制 财富顾问摘要漏掉非关键字段、KYC 文档分类误判 Sev 4 低影响缺陷或用户体验问题 格式错误、语气不一致、轻微延迟
11.2 Regulatory Response Timeline
Time window Action Owner Evidence 0-2 hours 识别、记录 incident ID、初步 severity、冻结相关日志 Ops / Platform / Security incident ticket、trace IDs 2-4 hours Containment: 暂停功能、切换 fallback、关闭工具权限、人工接管 PM / Architect / Ops containment decision、rollback log 4-24 hours Impact assessment: 受影响客户、交易、决策、数据、地域、供应商 BA / Data / Risk / Vendor Owner impact worksheet 24-48 hours Legal / Compliance 判断是否触发通知、监管沟通、客户补救 Legal / Compliance / Risk legal assessment record 48-72 hours Root cause: model、prompt、data、tool、process、vendor、training Architect / EvalOps / Security RCA draft、sample evidence 3-10 days Corrective actions: 控制修复、回归测试、客户补救、培训 PM / BA / Architect / Ops CAPA plan、eval report 10-30 days Postmortem: 管理层汇报、风险接受或追加投资、evidence binder 更新 Business Owner / Risk postmortem、board update
具体法定通知时限和监管沟通方式必须由 legal / compliance 根据适用规则确认。
11.3 Regulator response pack
监管问询或 examination 前，准备一个可读、可验证、前后一致的 response pack:
Executive summary: 发生什么、影响范围、当前状态、补救动作。
Inventory extract: 涉及 AI systems、models、vendors、data sources。
Timeline: discovery、triage、containment、assessment、decision、remediation。
Control description: 事故前已有控制、事故中控制、事故后增强控制。
Evidence sample: 日志、审批、eval、人工复核、客户沟通、vendor 通知。
Root cause and CAPA: 根因、纠正措施、预防措施、owner、due date。
Governance record: 谁批准、谁接受 residual risk、何时复核。
12. Board and Management Reporting
董事会和管理层不需要看所有 prompt 和技术细节，但必须理解 AI 风险暴露、控制成熟度、事故趋势、监管变化和需要决策的事项。
12.1 Management dashboard
Metric 含义 AI inventory count by tier Tier 1/2/3 数量、增长趋势、未分级数量 Regulatory change exposure 新监管变化影响多少 use case Control coverage 每个高风险 use case 是否有 control matrix 和 evidence binder Eval gate pass rate 发布前通过率、失败原因、重复失败项 Human override rate 人工修改、拒绝、升级 AI 输出的比例和原因 Incidents by severity 事故数量、根因、修复时效 Vendor concentration 关键供应商依赖、单点风险、替代方案 Customer impact 投诉、补救、错误通知、客户损害 Training completion AI literacy 和角色培训覆盖率 Residual risk decisions 需要管理层接受或追加资源的风险
12.2 Board memo 结构
AI portfolio snapshot: 生产、试点、暂停、退役数量。
Top risks: 客户权益、信贷解释、数据保护、第三方依赖、安全攻击、监管变化。
Control maturity: inventory、tiering、evidence、eval、incident、vendor lifecycle。
Incidents and lessons: 只讲事实、影响、根因、整改、剩余风险。
Regulatory radar: 近期变化和需要决策的窗口。
Decisions requested: 预算、人员、风险接受、暂停上线、vendor strategy。
表达原则:
不说“模型很安全”，说“哪些控制降低哪些风险，证据在哪里”。
不说“我们符合所有法规”，说“基于当前 legal/compliance 判断，哪些要求已映射，哪些仍在复核”。
不把 AI 风险包装成技术风险，明确客户、运营、合规和声誉影响。
13. PM / BA / Architect 分工与协作
13.1 Core responsibilities
Activity PM BA Architect Use case intake 定义业务价值、范围、优先级、no-AI alternative 记录流程、角色、规则、例外和证据 判断可行架构和关键风险 Applicability support 提供产品范围、用户、地域、客户影响 整理监管问题和流程触发点 提供系统边界、数据流、模型和供应商信息 Risk tiering 说明业务影响和客户损害 填写 worksheet、组织 review 评估技术、数据、安全、可观测风险 Inventory 确保 use case 登记和 owner 清晰 维护流程和证据字段 维护 model、version、integration、logs Control mapping 确认可接受的 UX、人工复核和 release gate 把政策转成需求和控制检查项 把控制落到架构、权限、日志、监控 Evidence pack 确保产品决策、沟通、审批留痕 整理流程、样本、问答和审计证据 提供技术设计、eval、日志、变更证据 Vendor due diligence 说明 vendor 对 roadmap 和客户体验的影响 整理业务依赖和服务流程 评估 API、数据、SLA、安全、退出方案 Change management 决定 release、rollout、rollback 评估流程和培训变化 评估模型、prompt、RAG、工具和系统影响 Incident response 负责业务优先级、客户影响和决策 组织影响分析、事实记录、客户流程 负责 containment、RCA、修复和监控 Reporting 向管理层讲价值、风险和决策请求 准备 narrative、Q&A、证据摘要 解释控制、架构限制和技术路线
13.2 与 Legal / Compliance / Risk / Data / Security / Vendor Owner 协作
Partner 需要他们决定 PM/BA/Architect 提供 Legal 法规适用性、合同条款、通知义务、法律风险 regulatory impact memo、事实清单、地理和客户范围 Compliance 政策要求、监管预期、测试和监控标准 流程图、控制矩阵、样本、客户沟通 Risk risk appetite、tier、residual risk acceptance risk worksheet、impact analysis、control maturity Data Owner 数据授权、质量、血缘、retention、access data source inventory、use purpose、quality needs Security threat model、IAM、DLP、incident handling architecture diagram、tool permissions、logs Vendor Owner / TPRM due diligence、contract、SLA、exit plan vendor use case、criticality、integration and fallback Operations 人工复核、培训、SOP、日常监控 workflow design、user guidance、exception path Internal Audit 控制有效性、证据质量、独立验证 evidence binder、control matrix、sampling plan
14. Artifact Templates
14.1 Regulatory Impact Memo
# Regulatory Impact Memo: AI Customer Service RAG
Use case ID: AI-CS-001
Business owner: Head of Customer Operations
Product owner: AI Service PM
Prepared by: AI BA with Solution Architect
Date and version: 2026-06-29, v1.0
## Business and workflow summary
- Business goal: reduce policy lookup time and improve first-contact resolution for card fee and dispute questions.
- User roles: retail banking customer, customer service agent, operations supervisor.
- AI behavior: read approved knowledge, summarize policy, draft response, escalate high-risk complaints.
- Customer or employee impact: customer receives faster response, but fee, complaint and dispute outcomes remain under human workflow control.
## Applicability facts
- Jurisdictions: United States retail banking customer service, with EU applicability screened separately for cross-border customers.
- Entity / product scope: card servicing and deposit account customer support.
- Data categories: account metadata, customer message, approved policy knowledge base, no credit bureau data.
- Model / vendor: hosted GPAI model through approved enterprise API, model version logged per request.
- Third-party dependencies: LLM API provider, cloud logging service, CRM integration.
## Regulatory trigger hypothesis
- AI-specific: customer-facing AI interaction disclosure and high-risk escalation considered.
- Financial regulation: consumer protection and complaint handling controls.
- Consumer protection: avoid misleading fee, refund, dispute or account access statements.
- Privacy / data: PII minimization, retention and access control required.
- Third-party risk: model provider and cloud services require TPRM review.
- Security: prompt injection, data leakage and unauthorized account lookup risks.
## Risk tier hypothesis
- Proposed tier: Tier 2 for approved FAQ and policy response; Tier 1 for fee waiver, complaint, dispute or account action paths.
- Rationale: AI drafts and retrieves information but does not make final customer-impacting decisions.
- Key harms: misleading response, missed complaint escalation, privacy leakage, over-automation of customer remedies.
## Required controls
- Human oversight: high-risk intents route to agent; supervisors sample responses weekly.
- Logging: request, response, model version, knowledge source, escalation flag and agent override retained.
- Eval: policy grounding, refusal, complaint detection and prompt injection regression set.
- Disclosure: customer-facing UI states AI assistance according to approved copy.
- Vendor controls: data use restriction, change notification, incident support and exit plan.
- Change management: prompt, knowledge base, model or escalation rule changes require ticket, eval run and approval.
## Decisions needed
- Legal questions: confirm disclosure wording and retention obligations for chat transcripts.
- Compliance questions: approve complaint identification and escalation criteria.
- Risk acceptance: accept Tier 2 launch for FAQ scope with Tier 1 controls on dispute and complaint paths.
- Launch recommendation: limited release to 10% of authenticated chat traffic after eval gate passes and runbook is approved.
14.2 AI System Inventory Row
Field Example System ID AI-AML-002 Name AML Case Narrative Copilot Business capability AML investigation AI behavior summarize + draft + recommend missing evidence Risk tier Tier 1 Model / vendor Vendor LLM API, model version recorded per request Data sources transaction history、case notes、KYC profile、watchlist hits Controls human approval before case closure, full trace logging, red-team Evidence binder evidence/AI-AML-002/v1.3 Last review 2026-06-29
14.3 Risk Classification Worksheet
Dimension Rating Rationale Evidence Customer impact High 可能影响是否升级可疑活动调查 process map Automation level Medium AI 起草和推荐，最终由 investigator 决定 workflow design Data sensitivity High 使用交易、KYC、case notes data classification Explainability need High 需要说明证据和结论关系 narrative rubric Vendor criticality Medium 可 fallback 到人工流程 BCP plan Monitoring maturity Medium 有日志和抽检，但上线前需扩大 golden set eval report Final tier Tier 1 合规和客户风险较高，需要强控制 approval record
14.4 Control Matrix
Requirement Control Test Evidence Owner AI 输出必须有证据支持 输出中每个关键结论引用 case evidence ID 抽样 100 个 case 检查 citation support eval result、sample review EvalOps / AML Ops 人工监督 Investigator 必须 approve narrative 才能进入 case closure 检查 workflow 不允许 AI 直接关闭 case access and workflow test Architect / Ops 变更管理 Prompt 和 model 变更必须跑 regression set Change ticket 中附 eval run ID change log、eval report PM / Architect
14.5 Evidence Binder
Evidence item Pass standard Architecture diagram 标出数据源、模型、vendor、logs、human review、fallback Eval report 包含样本范围、失败模式、阈值、结果、批准人 Human review log 能看到 reviewer、decision、override reason、timestamp Vendor pack 有 due diligence、contract controls、SLA、exit plan Incident runbook 有 severity、owner、timeline、legal/compliance escalation
14.6 Regulatory Response Timeline
Milestone Deliverable Day 0 Incident ticket、initial facts、containment decision Day 1 Impact assessment、affected systems/customers、legal assessment request Day 2 Draft regulator/customer response if required、RCA hypothesis Day 5 Corrective action plan、evidence samples、management update Day 10 RCA final、control enhancements、monitoring plan Day 30 Postmortem、board/risk committee summary、evidence binder closure
14.7 Exam / Audit Q&A
Question Good answer pattern 你们如何知道企业有哪些 AI 系统? 展示 AI inventory、owner、risk tier、last review、evidence binder。 这个 use case 为什么是 Tier 1? 展示 worksheet: 客户影响、自动化程度、数据敏感性、解释义务、failure harm。 你们如何防止 AI 直接做最终决策? 展示 workflow gate、权限设计、human review log、系统测试。 如果 vendor 改了模型怎么办? 展示 contract notification、change ticket、regression eval、rollback plan。 如何证明信贷拒绝原因准确? 展示 reason code mapping、model validation、sample adverse action notices、人工 review。 发生事故后如何响应? 展示 incident runbook、timeline、containment log、RCA、CAPA。
15. 金融零售案例
15.1 信贷: AI Credit Decisioning Assistant
Area Playbook Use case AI 帮助信贷官整理申请材料、提示风险因素、起草 credit memo 或 adverse action explanation。 Regulatory triggers consumer protection、ECOA / adverse action、fair lending、model risk、AI high-risk lens、third-party risk。 Risk tier Tier 1。如果 AI 参与 underwriting、定价、额度、拒绝原因或客户通知，默认高影响。 Key controls 人工信贷官最终决定；reason code 映射可验证；拒绝原因不能由黑箱文本自由生成；fairness / bias testing；完整日志；模型和规则版本留存。 Evidence credit policy mapping、model validation、adverse action sample testing、override log、approval record、customer notice review。 PM focus 明确 AI 只是 assistant 还是 decision engine，避免 UX 暗示系统自动批准或拒绝。 BA focus 把 credit policy、例外审批、adverse action reason、appeal / complaint 流程写进需求。 Architect focus 决策服务、reason service、LLM drafting service 分离；保证最终通知来源可审计。
15.2 AML: Case Investigation Copilot
Area Playbook Use case 汇总交易、KYC、历史 case、watchlist 信息，起草 narrative，提示缺失证据。 Regulatory triggers BSA/AML、SAR process、model risk、third-party risk、data protection、auditability。 Risk tier Tier 1。AI 影响 AML 调查质量和合规证据，但不应自动决定 SAR filing。 Key controls Investigator 必须审批；AI 输出引用 evidence ID；SAR filing decision 不由 AI 自动决定；case sampling；prompt injection 防护；敏感数据访问最小化。 Evidence case narrative rubric、citation support eval、human approval log、SAR decision separation、access review、incident runbook。 PM focus 衡量 evidence gathering time、narrative completeness、rework rate，而不是只看生成速度。 BA focus 画出 investigation workflow、escalation、quality check、SAR boundary。 Architect focus RAG 权限过滤、case-level trace、不可篡改日志、fallback 到人工 case management。
15.3 客服: AI Customer Service Chatbot / Agent Assist
Area Playbook Use case 面向客户的 chatbot 或坐席辅助，回答账户、费用、争议、产品政策问题。 Regulatory triggers transparency、consumer protection、UDAAP、complaints、privacy、records retention。 Risk tier Tier 2 到 Tier 1。只提供公开 FAQ 可为 Tier 2；涉及费用、投诉、争议、账户行动时提高到 Tier 1。 Key controls AI disclosure；高风险话题转人工；答案必须引用批准知识库；禁止承诺退款、批准、法律建议；投诉识别和升级；conversation log retention。 Evidence approved knowledge source、answer eval、handoff log、customer disclosure copy、complaint routing test。 PM focus 定义哪些 journey 可以自动化，哪些必须转人工，避免为了 deflection rate 牺牲客户权益。 BA focus 梳理 FAQ、policy exception、complaint definition、handoff script。 Architect focus RAG source allowlist、policy freshness、PII masking、channel logging、real-time guardrails。
15.4 财富: Advisor Copilot
Area Playbook Use case 为财富顾问汇总客户资料、市场信息、产品材料，起草 meeting prep 和 follow-up。 Regulatory triggers suitability / best interest、marketing review、recordkeeping、privacy、model/vendor risk。 Risk tier Tier 2 到 Tier 1。如果输出可能被客户视为个性化投资建议，按高影响控制。 Key controls AI 不直接向客户发送投资建议；顾问确认 suitability；产品材料来自批准来源；输出标明事实、假设和限制；客户沟通留档。 Evidence approved product library、advisor approval log、communication archive、suitability checklist、eval samples。 PM focus 把 AI 定位为 advisor productivity，而不是替代持牌顾问。 BA focus 记录 meeting prep、recommendation approval、disclosure 和 archive 流程。 Architect focus 客户数据访问控制、source citation、communication archive integration、model output policy filter。
15.5 支付: AI Payment Fraud and Exception Assistant
Area Playbook Use case 识别异常支付、解释失败原因、建议 dispute / chargeback / refund 处理路径。 Regulatory triggers payments regulation、consumer protection、operational resilience、fraud controls、third-party risk、data security。 Risk tier Tier 1 如果 AI 影响交易阻断、退款、冻结或争议结果；Tier 2 如果只做内部分流和摘要。 Key controls 高金额或客户不利动作人工审批；工具调用分级授权；资金动作双控；实时监控 false positive / false negative；fallback to rules/manual queue。 Evidence fraud model eval、payment action approval log、tool permission matrix、exception workflow test、customer remediation record。 PM focus 平衡 fraud loss、customer friction、resolution time 和错误阻断成本。 BA focus 定义 dispute、chargeback、refund、manual review、customer communication 的例外路径。 Architect focus payment tool isolation、idempotency、audit trail、rate limits、rollback and reconciliation。
16. 30/60/90 天执行计划
Days 1-30: 建立可见性和最小治理
Week Output 说明 Week 1 AI regulatory radar + source baseline 确认官方来源、内部政策、owner、review cadence。 Week 2 AI inventory v1 盘点生产和试点 AI use cases，标出 owner、model、data、vendor、status。 Week 3 Risk tiering workshop 对 Top 10 use cases 做 initial tier，识别 Tier 0/1。 Week 4 Artifact templates 发布 regulatory impact memo、risk worksheet、control matrix、evidence binder 模板。
验收标准:
100% 已知 AI use cases 有 inventory row。
Tier 1 use cases 有 business owner、technical owner、risk owner。
新 use case intake 不允许绕过 inventory 和初步分级。
Days 31-60: 建立控制和证据闭环
Week Output 说明 Week 5 Control mapping for Tier 1 把高风险 use cases 映射到 human oversight、logging、eval、vendor、change controls。 Week 6 Evidence binder for priority use cases 为信贷、AML、客服、支付等优先场景补齐证据目录。 Week 7 Vendor due diligence uplift 对关键 AI vendors 做 criticality、contract、SLA、data、exit plan review。 Week 8 Change management gate 建立 model/prompt/RAG/tool/vendor 变更触发机制和 regression gate。
验收标准:
Tier 1 use cases 100% 有 control matrix。
Top vendors 100% 有 due diligence 和 owner。
任何 material change 都有 ticket、eval、approval、rollback。
Days 61-90: 建立监管响应和管理层治理
Week Output 说明 Week 9 Incident/regulator response runbook 建立 severity、timeline、response pack、legal/compliance escalation。 Week 10 Exam/audit Q&A pack 为高风险 use cases 准备监管问答和 evidence samples。 Week 11 Board / management dashboard 建立 inventory by tier、incidents、control coverage、vendor concentration、regulatory radar。 Week 12 Tabletop exercise 模拟信贷拒绝原因错误、客服误导、vendor model change 或 AML narrative 漏证据。 Week 13 Improvement roadmap 基于演练和审计差距，形成 6 个月治理路线图。
验收标准:
Sev 1 / Sev 2 AI incident 能在 4 小时内完成 containment decision。
管理层每季度看到 AI portfolio risk，而不是单个项目 demo。
Internal audit 可抽样验证至少 3 个 Tier 1 evidence binders。
17. 面试表达
17.1 30 秒版本
AI regulatory response 不是法务单独写文件，而是 PM、BA、Architect 把监管要求转成产品边界、流程控制、系统设计和证据链。我的方法是先做 regulatory radar 和 applicability judgment，再对 use case 做 risk tiering，进入 AI inventory，然后建立 control matrix、evidence binder、vendor due diligence、change gate 和 incident response。这样管理层和监管问询时，我们能说明 AI 在哪里、风险是什么、控制是什么、证据在哪里、谁负责。
17.2 2 分钟版本
我会把 AI 监管响应拆成三层。第一层是识别: 建立 regulatory radar，持续跟踪 AI-specific law、金融监管、第三方风险、数据隐私和安全要求；每个 use case 用 regulatory impact memo 判断适用性。第二层是控制: 用 use case risk tiering 决定控制强度，把高影响场景纳入 AI inventory、control mapping、eval gate、human oversight、logging、vendor due diligence 和 change management。第三层是证据和响应: 每个 Tier 1 use case 都有 evidence binder，包含架构、数据、模型、供应商、控制、评测、审批、监控和 incident 记录；一旦发生问题，按 incident/regulator response timeline 做 containment、impact assessment、legal/compliance 判断、RCA、CAPA 和管理层汇报。
金融零售里我会特别关注信贷、AML、客服、财富和支付。比如信贷场景不能因为 complex algorithm 黑箱就无法提供 adverse action reasons；AML copilot 不能自动决定 SAR filing；客服 chatbot 要有 disclosure、知识库引用和高风险转人工；支付 AI agent 的工具调用必须有权限、双控和回滚。
17.3 深挖追问
Interview question Answer angle 如何判断 AI use case 风险等级? 看客户权益、自动化程度、数据敏感性、解释义务、失败伤害、供应商关键性和监控成熟度。 PM 在监管响应中做什么? 定义范围和边界，确保客户影响、人工监督、上线门槛、沟通和价值指标被产品化。 BA 的关键价值是什么? 把法规、政策、流程、例外、角色和证据转成需求、worksheet、control matrix 和 Q&A。 Architect 如何支持监管? 通过系统边界、数据流、日志、权限、eval pipeline、change gate、fallback 和 evidence design 支撑可审计。 如何处理 AI vendor 风险? 按第三方生命周期做 criticality、due diligence、contract controls、monitoring、incident coordination 和 exit plan。 监管问询来了先做什么? 冻结事实和日志，确认范围和 owner，启动 legal/compliance，形成 timeline、impact、controls、evidence、CAPA。
18. 常见误区
Mistake 为什么危险 正确做法 把监管响应当作上线后补文档 控制无法前置，证据不可复现 从 intake 开始建立 memo、tier、controls、evidence 只登记模型，不登记 AI system 忽略流程、数据、工具、供应商、人工监督 Inventory 记录 system、model、data、workflow、owner 以为 human-in-the-loop 自动降低风险 人工可能没有信息、时间或权限真正干预 设计可执行 oversight，记录 override 和 review quality 用 LLM 生成信贷拒绝原因 可能不准确、不对应实际评分因素 reason code 和解释逻辑必须可验证，LLM 只能在受控范围起草 只看 vendor 的安全证书 AI 风险还包括模型更新、数据使用、subprocessor、退出 做 AI-specific due diligence 和合同控制 没有 prompt / model / index 版本 出事后无法复现输出 每次请求记录版本、retrieval context、tool calls 只做一次 eval 模型、数据、政策、用户行为都会变化 建立 release gate、regression、production monitoring 管理层只看 ROI 忽略客户损害、监管、供应商集中和事故趋势 建立 board dashboard 和 residual risk decision 把法规摘要当作合规结论 PM/BA/Architect 不是 legal authority 输出事实和问题，由 legal/compliance sign-off 低风险工具完全不登记 Shadow AI 扩散，数据和 vendor 风险不可见 Tier 3 也轻量登记和政策确认
19. 学习与作品集练习
为了把本文转成可展示能力，建议选择一个金融零售场景完成一套 artifact:
选择 use case: 信贷 memo copilot、AML narrative copilot、客服 RAG、财富 advisor copilot、支付 exception assistant。
写一页 Regulatory Impact Memo。
建一行 AI System Inventory。
填 Risk Classification Worksheet。
写 8-12 条 Control Matrix。
设计 Evidence Binder 目录。
写 Regulatory Response Timeline，模拟一次 incident。
准备 10 个 Exam/Audit Q&A。
写一页董事会汇报摘要: 风险、控制、事故、决策请求。
优秀作品集的标准不是模板漂亮，而是每个 artifact 能相互追溯:
Use case -> risk tier -> controls -> evidence -> change gate -> incident response -> management decision
这正是 AI PM / BA / Architect 在监管环境中最稀缺的复合能力。