AI 扩展计划 / Playbooks

AI Regulatory Architecture / EU AI Act / NIST / ISO 42001 Playbook

本文的目标不是把 EU AI Act、NIST AI RMF、ISO/IEC 42001 和 OECD AI Principles 改写成清单，而是把它们组合成一套企业级 AI regulatory architecture:

642 行AI_REGULATORY_ARCHITECTURE_EU_AI_ACT_NIST_ISO42001_PLAYBOOK.md

AI Regulatory Architecture Playbook: EU AI Act x NIST AI RMF x ISO/IEC 42001 x OECD AI Principles

定位: 面向高级 AI PM / AI BA / CBAP / Product Governance / Enterprise Architect / Solution Architect / Model Risk / Compliance Partner 的 AI regulatory architecture 实战手册。

重要说明: 本文是学习、作品集和企业治理设计材料，不构成法律意见、合规结论、审计意见、认证结论或监管解释。正式项目必须由 Legal、Compliance、Risk、Model Risk、Privacy、Security、Internal Audit、Business Owner、Data Owner、Technology Owner 和管理层结合机构类型、司法辖区、产品范围、客户影响和内部政策确认。

1. 目的 / 适用对象 / 核心观点

1.1 目的

本文的目标不是把 EU AI Act、NIST AI RMF、ISO/IEC 42001 和 OECD AI Principles 改写成清单，而是把它们组合成一套企业级 AI regulatory architecture:

Regulatory signal
-> applicability judgment
-> AI inventory
-> risk tiering
-> obligations-to-controls mapping
-> product lifecycle gates
-> evidence architecture
-> monitoring and change radar
-> regulator / audit response
-> management review and continuous improvement

对金融零售 AI 项目来说，监管架构的价值在于让产品创新、客户保护、模型风险、数据治理、安全、供应商管理和企业架构使用同一套语言工作。它把“某个法规要求什么”转成“哪个产品、哪个流程、哪个系统、哪个模型、哪个数据集、哪个人工角色、哪个控制、哪份证据、哪个上线门禁负责证明风险被管理”。

1.2 适用对象

角色	应该用本文回答的问题
AI Product Manager	这个 AI use case 是否值得做，客户价值与监管风险如何共同进入 roadmap、release gate 和 success metrics。
CBAP / Business Analyst	法规、政策、流程、角色、数据、例外、人工复核、解释义务和证据要求如何进入需求模型。
Enterprise Architect	AI governance 如何进入企业能力地图、应用组合、数据架构、集成架构、控制平面和技术标准。
Solution Architect	单个 AI 系统如何设计 logging、human oversight、eval、monitoring、access control、fallback、rollback 和 evidence capture。
Compliance / Legal Partner	如何从产品和架构材料中高效判断适用性、义务、残余风险和需要正式确认的问题。
Model Risk / Internal Audit	如何看到模型、数据、流程、控制、测试、审批和生产监控之间的可追溯证据链。

1.3 核心观点

Regulatory architecture 是企业 AI 的控制平面，不是项目末尾的一张合规确认表。
EU AI Act 提供风险分层和义务触发框架，NIST AI RMF 提供风险管理运行语言，ISO/IEC 42001 提供 AI management system，OECD AI Principles 提供跨司法辖区的价值锚点。
高级 PM / BA / Architect 的工作不是背条文，而是把 regulatory applicability、risk tier、control objective、evidence requirement 和 release decision 嵌入产品生命周期。
金融零售 AI 的监管复杂度来自叠加效应: AI law、consumer protection、credit regulation、AML/KYC、privacy、cybersecurity、outsourcing、model risk、record retention 和 operational resilience 同时作用。
一个可监管、可审计、可规模化的 AI 系统，必须能回答: 谁使用 AI、AI 做什么、影响谁、依据什么数据、自动化到什么程度、谁监督、如何解释、如何监控、如何停用、证据在哪里。

2. Source Anchors

以下官方来源是本文的锚点。使用方式是把官方来源转成产品治理、企业架构、控制设计和证据架构，不把任何公开框架直接等同于完整合规结论。访问日期: 2026-06-30。

Anchor	Official link	本文使用方式
EU AI Act: Regulation (EU) 2024/1689	https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng	作为 AI regulatory obligations 的主锚点: AI literacy、prohibited practices、high-risk classification、requirements for high-risk AI systems、provider / deployer obligations、transparency obligations、GPAI obligations、post-market monitoring、serious incident reporting。
NIST AI Risk Management Framework	https://www.nist.gov/itl/ai-risk-management-framework	作为风险管理操作语言: Govern / Map / Measure / Manage，以及 trustworthy AI characteristics。
NIST AI RMF 1.0 publication	https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-ai-rmf-10	作为 AI RMF 正式出版物锚点，用于把风险治理、上下文映射、测量和管理嵌入生命周期。
ISO/IEC 42001:2023 official ISO page	https://www.iso.org/standard/42001	作为 AI Management System, AIMS 的管理体系锚点: 建立、实施、维护和持续改进组织级 AI 管理系统。
OECD AI Principles	https://www.oecd.org/en/topics/sub-issues/ai-principles.html	作为价值和跨司法辖区互操作锚点: inclusive growth、human rights and democratic values including fairness and privacy、transparency and explainability、robustness / security / safety、accountability。
OECD Recommendation on Artificial Intelligence	https://legalinstruments.oecd.org/en/instruments/oecd-legal-0449	作为正式 OECD legal instrument 锚点，用于连接 AI principles、policy recommendations 和 AI lifecycle thinking。

使用纪律:

监管来源进入 Regulatory Change Radar，不是复制进产品 PRD 后静态保存。
法律适用性由 Legal / Compliance 判断，产品与架构负责提供完整事实、边界、数据流、角色、控制和证据。
框架不是互相替代关系。EU AI Act 更像义务触发器，NIST AI RMF 更像风险管理语言，ISO/IEC 42001 更像管理系统，OECD Principles 更像价值基线。
每个高影响 AI use case 都要能从 source anchor 追到 internal policy、control objective、release gate 和 evidence。

3. Regulatory Architecture 不是合规清单

3.1 Checklist 思维的局限

Checklist 可以帮助团队不遗漏常见问题，但不能证明 AI 系统在特定业务上下文、版本边界、客户影响和监管义务下是可接受的。金融零售场景中，简单清单通常有五个失败点:

失败点	表面状态	实际风险
无上下文	“已完成 AI risk assessment”	不知道 AI 在信贷、AML、客服、营销或运营流程中的具体决策权。
无角色判断	“参考 EU AI Act”	没有判断本机构在该 use case 中是 provider、deployer、importer、distributor、product manufacturer、creditor 还是 vendor user。
无控制强度	“有人类复核”	没有定义复核比例、复核能力、override 权限、审计日志和异常升级。
无证据链	“测试通过”	不知道测试集、阈值、失败样本、版本、批准人和生产监控是否可追溯。
无变更机制	“上线时合规”	模型、prompt、retriever、policy source、vendor terms、客户群和法规变化后没有触发重评估。

3.2 Regulatory Architecture 的架构视图

Regulatory architecture 应该被设计成企业 AI 控制平面，至少包含九层:

Layer	核心问题	关键产物
Regulatory signal layer	外部法规、监管口径、标准和行业事件如何进入组织	Source anchors、regulatory radar、impact memo
Applicability layer	哪些 use case、实体、角色、地区、客户和产品触发要求	Applicability matrix、legal questions、scope decision
AI asset layer	企业在哪里使用 AI，谁拥有，影响什么流程	AI inventory、model registry、vendor registry、data lineage
Risk taxonomy layer	风险如何分级，分级如何驱动门禁和控制	Risk tier taxonomy、risk appetite、exception register
Control library layer	义务和风险如何转成控制目标与控制活动	Obligation-control map、control catalog、policy-as-code
Product lifecycle layer	控制何时进入 discovery、design、build、release、operate	Lifecycle gates、RACI、approval workflow
Evidence layer	如何证明控制设计并运行过	Evidence graph、audit binder、retention rules、traceability
Monitoring layer	生产风险、漂移、投诉、事故和供应商变化如何被发现	KPI / KRI dashboard、alerts、incident workflow、change trigger
Governance layer	谁接受残余风险，谁决定暂停、扩展、整改或退役	AI governance council、architecture review、management review

3.3 高级表达

I do not treat AI regulation as a terminal compliance checklist. I treat it as a control-plane architecture. The architecture connects regulatory applicability, AI inventory, risk tiering, lifecycle gates, control objectives, evidence capture, monitoring, and governance decisions. That is how a regulated financial institution can scale AI without losing auditability, accountability, or customer protection.

4. Risk Tier Taxonomy

Risk tier taxonomy 的目标是把法规分类、内部风险偏好、产品影响和架构控制强度连接起来。它不是法律结论，但必须为 Legal / Compliance 提供可判断的事实基础。

4.1 外部监管分类视角

Regulatory category	EU AI Act anchor	架构含义
Prohibited / unacceptable practices	Article 5	产品入口必须有 hard stop。若 use case 接近禁止实践，默认 reject 或 redesign，并记录 decision rationale。
High-risk AI systems	Article 6, Annex I, Annex III	进入强化治理: risk management、data governance、technical documentation、logging、transparency、human oversight、accuracy、robustness、cybersecurity、post-market monitoring。
Transparency-specific AI systems	Article 50	当用户与 AI 交互、内容生成、deep fake 或情绪 / 生物识别相关透明度触发时，需要 disclosure、UX copy、logging 和用户理解证据。
General-purpose AI models	Chapter V, including Article 53 and Article 55	若机构是 GPAI provider，进入模型层义务；若机构是 deployer / integrator，也要把供应商文档、模型能力限制、版本变化和下游控制纳入第三方治理。
Minimal or lower-risk AI	Risk-based structure	不免除治理。仍需 inventory、数据边界、使用政策、security、monitoring 和变更控制，只是控制强度较低。

4.2 企业内部四级分层

Tier	定义	金融零售例子	默认治理动作
Tier 0: Not allowed	违反法律、内部政策、客户保护原则或风险偏好，或无法设计有效控制	欺骗性操纵客户、未经授权推断敏感属性并用于差别待遇、无人复核自动生成监管提交结论	Reject、redesign、legal escalation
Tier 1: Regulatory significant / high impact	影响客户权益、金融决策、合规义务、重要运营或基本权利；可能落入 high-risk 或金融监管重点区域	信贷审批 / 额度建议、adverse action reason support、AML alert prioritization、账户冻结建议、保险定价辅助	Mandatory legal / compliance / model risk review、complete evidence pack、senior risk acceptance
Tier 2: Controlled business use	影响业务流程和员工判断，但不直接自动决定客户权益；可通过人工复核、范围限制和监控降低风险	客服回复草稿、KYC 文档缺失检查、投诉分类、财富顾问资料摘要、支付异常分流	Standard AI review、eval gate、human oversight、production monitoring
Tier 3: Low-risk productivity	内部效率工具，不使用敏感客户数据，不影响客户权益或监管结论	公开资料摘要、内部会议纪要、非客户数据培训助手、通用文档润色	Lightweight inventory、usage policy、data boundary、security review

4.3 分级维度

Dimension	Low signal	Medium signal	High signal
Decision impact	不影响客户、员工或第三方权益	影响流程建议或员工判断	影响信贷、账户、费用、交易、KYC / AML、投诉、保险、就业或访问权
Automation level	Read / summarize	Recommend / draft / classify	Decide / act / trigger external consequence
Human oversight	AI 输出仅供参考	人工复核但工作量大	人工复核不足、默认采纳、难以 override
Data sensitivity	公开或低敏数据	内部业务数据	PII、金融交易、信用报告、身份、AML、特殊类别、未成年人数据
Explainability need	无正式解释需求	需要业务解释	需要具体、准确、可复核、可申诉解释
Vendor dependency	可替换工具	重要服务供应商	关键活动、黑箱模型、不可控更新、跨境数据或集中依赖
Harm profile	轻微效率损失	客户不便、运营损失、品牌风险	客户损害、歧视、监管违规、资金损失、系统性操作风险
Monitoring maturity	有日志、指标、owner、回滚	监控部分覆盖	无版本日志、无 drift 监控、无事故路径、无停用机制

4.4 分级决策规则

If prohibited-practice signal exists:
  Tier 0 unless Legal confirms the design is outside scope and controls are accepted.

If AI affects credit, AML/KYC, account access, insurance, customer redress, pricing, fraud blocking, or regulatory reporting:
  Tier 1 by default until downgraded through documented governance decision.

If AI drafts customer-facing or employee-actionable outputs using customer data:
  Tier 2 by default, with escalation to Tier 1 when output can materially affect customer rights or regulatory obligations.

If AI is internal, low-data-sensitivity, non-decisioning, and reversible:
  Tier 3, still registered in inventory.

5. AI Inventory

AI inventory 是 regulatory architecture 的事实底座。没有 inventory，企业无法判断法规适用性、供应商暴露、客户影响、生产监控范围、证据缺口或监管问询边界。

5.1 Inventory 不只是模型清单

成熟的 AI inventory 应覆盖 use case、系统、模型、数据、供应商、流程、控制和证据:

AI Use Case
-> Business Process
-> AI System
-> Model / GPAI / Vendor
-> Data Sources
-> User Groups and Impacted Persons
-> Automation Level
-> Risk Tier
-> Applicable Obligations
-> Controls
-> Evidence
-> Monitoring
-> Owners and Approvals

5.2 必填字段

Field	说明	示例
AI asset ID	稳定唯一标识	AI-CREDIT-LIMIT-001
Use case name	业务可读名称	Credit limit increase recommendation assistant
Business capability	企业能力地图中的能力	Consumer credit decisioning
Product / journey	影响的产品和旅程	Credit card limit increase, mobile app and contact center
Jurisdiction	涉及客户、实体、服务和数据地区	EU customers served by EU branch
Organization role	provider / deployer / vendor user / creditor 等	Deployer and creditor; vendor user for external LLM
Intended purpose	设计目的和允许使用边界	Recommend limit increase eligibility and draft rationale for underwriter review
AI capability	预测、分类、生成、RAG、agent、optimization 等	ML score + RAG policy assistant + generated rationale draft
Automation level	read、summarize、recommend、draft、decide、act	Recommend and draft; no autonomous decision
Impacted persons	客户、员工、申请人、商户、供应商	Existing credit card customers
Decision owner	最终业务决策角色	Credit underwriter
Human oversight	复核角色、override、抽样、升级	100% underwriter approval before customer impact
Data sources	输入数据、特征、知识库、日志	Transaction history, repayment behavior, policy repository, credit bureau attributes
Sensitive data class	PII、金融、信用、特殊类别等	PII, financial transaction data, credit data
Model / vendor	内部模型、GPAI、供应商、版本	Internal risk score v4.2; external LLM API pinned model version
Risk tier	企业内部 tier 和理由	Tier 1 due to credit decision support and customer rights impact
EU AI Act screening	Article / Annex screening hypothesis	Potential high-risk signal for creditworthiness evaluation; Legal confirmation required
NIST AI RMF mapping	Govern / Map / Measure / Manage 覆盖状态	Governed, mapped, measured, managed with open residual risk item
ISO/IEC 42001 process	AIMS 流程关联	AI impact assessment, operational control, performance evaluation
OECD principles	价值原则关联	Fairness, transparency, robustness, accountability
Controls	关键控制 ID	CTRL-HO-001, CTRL-LOG-003, CTRL-FAIR-002
Evidence location	审计证据索引	Evidence binder: EB-AI-CREDIT-LIMIT-001
Monitoring	KPI / KRI / drift / complaint / override 指标	Approval override rate, adverse action reason quality, subgroup performance
Release status	idea、pilot、production、restricted、retired	Controlled pilot
Review cadence	周期性复核	Monthly Tier 1 monitoring; quarterly governance review
Owners	business、product、tech、risk、data、vendor	Named owner roles and accountable executive

5.3 Inventory 质量规则

Rule	解释
No orphan AI	没有 business owner、technology owner、risk owner 的 AI asset 不允许进入 pilot。
No silent AI	所有 customer-facing、employee-actionable、model-assisted decisioning 和 vendor-embedded AI 都必须登记。
No model-only view	单个模型若被多个产品流程使用，需要记录每个 use case 的不同上下文、风险和控制。
No static inventory	material change、供应商更新、数据源变化、用途变化、地域变化、客户群变化都会触发 inventory 更新。
No untraceable evidence	Tier 1 和 Tier 2 asset 的 inventory 记录必须能跳转到控制、评估、审批、监控和事故证据。

6. Obligations-to-Controls Mapping

Obligations-to-controls mapping 的目标是把外部义务和内部风险要求转成可执行控制。一个成熟映射至少包含四层:

External obligation / principle
-> Internal control objective
-> Control activity
-> Evidence and monitoring

6.1 EU AI Act 到控制域

EU AI Act anchor	Control objective	Control activity	Evidence
Article 4 AI literacy	相关人员具备理解 AI 能力、限制、风险和使用责任的能力	Role-based AI literacy training for PM, BA, engineer, underwriter, customer agent, risk reviewer	Training curriculum, attendance, assessment score, annual attestation
Article 5 prohibited practices	阻止禁止或不可接受 use case 进入产品组合	Intake hard-stop questions, prohibited-use escalation, legal review before continuation	Intake record, legal decision memo, rejected / redesigned use case log
Article 6 and Annex III high-risk classification	识别可能 high-risk 的系统并触发强化治理	Applicability matrix, high-risk screening, role analysis, legal confirmation	Screening worksheet, legal sign-off, risk tier decision
Article 9 risk management system	在生命周期内识别、分析、处置和监控风险	AI risk register, threat model, failure mode analysis, residual risk acceptance	Risk assessment, control plan, residual risk statement, monitoring dashboard
Article 10 data and data governance	确保训练、验证、测试和运行数据治理充分	Data lineage, data quality checks, representativeness assessment, bias review, data minimization	Data sheet, lineage diagram, quality report, fairness analysis
Article 11 technical documentation	系统设计、目的、能力、限制、评估和控制可说明	Technical file, architecture decision records, model card, system card, API and data flow documentation	Versioned technical documentation, ADR log, architecture review minutes
Article 12 record-keeping / logging	关键事件、输入、输出、版本和操作可追溯	Immutable logs, prompt / response capture where appropriate, model version logging, human action audit trail	Log schema, sample logs, retention policy, access review
Article 13 transparency and instructions	用户和 deployer 能理解系统用途、能力、限制和使用条件	Instructions for use, UI disclosure, operator guidance, limitation warnings	IFU document, UX copy approval, training material, user communication record
Article 14 human oversight	人工能有效理解、监督、干预、override 或停用系统	HITL design, escalation matrix, override workflow, kill switch, reviewer competency	Oversight procedure, override logs, reviewer training, incident drills
Article 15 accuracy, robustness, cybersecurity	系统性能、韧性和安全达到预期用途要求	Eval suite, adversarial testing, security review, prompt injection testing, fallback design	Eval report, red team report, penetration test, resilience test
Article 16 provider obligations	若作为 provider，确保系统满足要求并保留责任证据	Provider RACI, QMS alignment, conformity preparation, documentation and monitoring process	Provider control matrix, quality records, declaration workflow
Article 26 deployer obligations	若作为 deployer，按说明使用、监督、保留日志并监控风险	Deployer operating procedure, user training, input data governance, monitoring and reporting	Operating logs, user attestation, monitoring record, escalation ticket
Article 27 fundamental rights impact assessment	对特定 high-risk deployer use case 评估基本权利影响	FRIA workflow integrated with product gate and legal review	FRIA report, stakeholder impact analysis, mitigation plan
Article 50 transparency obligations	对 AI 交互、生成内容等进行适当透明度处理	AI interaction disclosure, generated content labeling, customer explanation UX	Disclosure copy, UI evidence, content provenance controls
Article 53 GPAI provider obligations	若作为 GPAI model provider，建立模型层文档和信息提供机制	Model documentation, downstream information, copyright policy summary where applicable	GPAI technical documentation, downstream package, policy records
Article 55 GPAI systemic risk obligations	若提供具系统性风险的 GPAI，进行更高强度评估与缓解	Systemic risk eval, adversarial testing, incident tracking, cybersecurity controls	Evaluation report, incident records, mitigation evidence
Article 72 post-market monitoring	生产后持续收集、分析和处置性能与风险信息	Production monitoring plan, issue triage, periodic review, customer complaint integration	Monitoring dashboard, review minutes, corrective action log
Article 73 serious incident reporting	重大事故进入升级、调查和报告流程	AI incident taxonomy, reporting workflow, legal / compliance escalation	Incident report, timeline, root cause analysis, regulator response pack

6.2 NIST AI RMF 到控制域

NIST function	Regulatory architecture 用法	典型控制
Govern	建立政策、角色、问责、风险偏好、培训和监督	AI policy, RACI, governance forums, control library, training, exception management
Map	理解 use case、上下文、利益相关方、流程、数据和影响	AI inventory, impact assessment, process map, data map, stakeholder analysis
Measure	测量可信 AI 特征、模型表现、安全、隐私、公平性和用户体验风险	Eval contract, fairness test, robustness test, security test, explainability review
Manage	风险处置、接受、监控、沟通、事故响应和持续改进	Release decision, residual risk acceptance, monitoring, incident workflow, corrective action

6.3 ISO/IEC 42001 到管理体系

AIMS theme	企业架构含义	控制落点
Context	组织 AI 范围、内外部要求、相关方和目标	AIMS scope, source anchors, stakeholder register
Leadership	管理层承诺、policy、roles and responsibilities	AI policy, executive accountability, governance council
Planning	风险、机会、目标和变更计划	AI portfolio plan, risk appetite, regulatory roadmap
Support	人员能力、沟通、资源和文档	AI literacy, knowledge base, evidence repository
Operation	AI 生命周期过程和运行控制	Intake, design review, eval gate, release gate, monitoring
Performance evaluation	监控、测量、内部审核和管理评审	KPI / KRI, internal audit, management review pack
Improvement	事故、缺陷、纠正措施和持续改进	Incident postmortem, control enhancement, policy refresh

6.4 OECD Principles 到产品治理

OECD principle	产品治理问题	架构控制
Inclusive growth, sustainable development and well-being	AI 是否扩大服务可得性、改善客户结果，并避免把成本转嫁给弱势群体	Outcome metrics, accessibility review, vulnerable customer analysis
Human rights and democratic values including fairness and privacy	AI 是否尊重客户权益、公平、隐私、申诉和人类自主性	Fairness testing, privacy impact assessment, contestability workflow
Transparency and explainability	客户、员工和监管者是否能理解 AI 的使用、限制和影响	Disclosure, explanation design, model / system cards
Robustness, security and safety	AI 是否在正常和异常条件下稳定、安全、可恢复	Robustness eval, cyber testing, fallback, kill switch
Accountability	是否有人对 AI 的设计、上线、运行、事故和整改负责	RACI, approval log, evidence graph, management review

7. Product Lifecycle Gates

Regulatory architecture 必须进入产品生命周期，而不是在上线前补材料。下面的 gate 适合金融零售 AI 项目。

7.1 Gate 0: Idea Intake

项目	内容
Objective	判断 use case 是否允许探索，是否存在 prohibited-practice signal 或明显超出风险偏好。
Required artifacts	Use case one-pager、intended purpose、customer / employee impact、data sensitivity、automation level、vendor hypothesis。
Decision	reject、redesign、allow discovery、escalate to Legal / Compliance。
Evidence	Intake record、hard-stop question responses、initial owner assignment。

7.2 Gate 1: Applicability and Risk Tiering

项目	内容
Objective	判断法规适用性假设、组织角色、司法辖区、risk tier 和 review path。
Required artifacts	Regulatory applicability matrix、AI inventory draft、role analysis、risk tier worksheet、legal questions。
Decision	Tier 0 reject、Tier 1 enhanced path、Tier 2 standard path、Tier 3 lightweight path。
Evidence	Legal / Compliance review note、risk tier approval、inventory record。

7.3 Gate 2: Product and Process Design

项目	内容
Objective	把 AI 控制嵌入业务流程，而不是只控制模型。
Required artifacts	BPMN / service blueprint、decision rights model、human oversight design、customer disclosure design、exception workflow、operating model。
Decision	design accepted、control gaps to close、scope reduction、manual-only fallback。
Evidence	Process map、RACI、UX copy approval、oversight procedure。

7.4 Gate 3: Architecture and Data Design

项目	内容
Objective	证明系统边界、数据流、日志、权限、供应商、模型版本、fallback 和 evidence capture 可以支撑义务。
Required artifacts	C4 / data flow diagram、data lineage、security architecture、logging schema、model / vendor architecture、ADR。
Decision	architecture approved、security / privacy conditions、vendor conditions、no-go。
Evidence	Architecture review minutes、ADR、data protection review、vendor assessment。

7.5 Gate 4: Evaluation and Control Testing

项目	内容
Objective	测量系统是否满足 intended purpose、risk tier 和 control objectives。
Required artifacts	Eval contract、test datasets、fairness analysis、robustness tests、security tests、human oversight simulation、failure mode test。
Decision	pass、conditional pass、retest、redesign。
Evidence	Eval report、failed-case disposition、threshold rationale、red team report。

7.6 Gate 5: Release and Risk Acceptance

项目	内容
Objective	对残余风险、上线范围、客户影响、监控和事故路径做正式决策。
Required artifacts	Obligation-control-evidence map、residual risk statement、monitoring plan、incident plan、rollback plan、training completion。
Decision	release、limited pilot、defer、reject、management risk acceptance。
Evidence	Release gate record、approvals、training attestation、production readiness checklist。

7.7 Gate 6: Production Monitoring

项目	内容
Objective	发现 drift、客户损害、偏差、越权使用、供应商变化、投诉和事故。
Required artifacts	KPI / KRI dashboard、model performance monitoring、override analytics、complaint tagging、incident workflow。
Decision	continue、tighten controls、pause expansion、rollback、incident escalation。
Evidence	Monitoring dashboard、review minutes、issue tickets、corrective action log。

7.8 Gate 7: Material Change and Retirement

项目	内容
Objective	对用途、数据、模型、供应商、地区、客户群、自动化程度或法规变化触发重评估。
Required artifacts	Change impact assessment、regression eval、updated inventory、updated control map、retirement plan。
Decision	approve change、require revalidation、freeze、retire。
Evidence	Change record、version diff、regression report、retirement evidence、data retention disposition。

8. Evidence Architecture

Evidence architecture 是把“我们有治理”变成“我们能证明治理有效”的能力。它不是共享盘目录，而是可追溯的 evidence graph。

8.1 Evidence Graph

Regulatory anchor
-> internal policy
-> obligation / principle
-> control objective
-> control activity
-> test method
-> evidence artifact
-> owner
-> version
-> release decision
-> production monitoring
-> incident / change record

8.2 Evidence 元数据

Metadata	说明
Evidence ID	稳定编号，例如 EB-AI-CREDIT-001-EVAL-2026Q2。
AI asset ID	关联 inventory 中的 AI asset。
Control ID	关联控制库中的 control objective 和 activity。
Obligation anchor	关联法规、标准、内部政策或 principle。
Version boundary	适用的模型、prompt、retriever、policy source、数据集、API、UI 版本。
Time boundary	证据产生日期、有效期、复核周期。
Owner	证据 owner、审批人、复核人。
Evidence type	policy、design、test、log、approval、training、monitoring、incident、vendor。
Integrity	存储位置、访问控制、不可篡改要求、保留期限。
Decision link	该证据支持哪个 gate decision 或 risk acceptance。

8.3 Evidence 类型

Evidence type	示例	证明的问题
Governance evidence	AI policy、RACI、committee minutes、risk appetite	谁负责，谁批准，风险边界是什么。
Applicability evidence	regulatory applicability matrix、legal review note	为什么认为某义务适用或不适用。
Design evidence	PRD、BPMN、C4、ADR、data flow、human oversight design	系统和流程如何被设计以管理风险。
Data evidence	data lineage、quality report、data sheet、bias analysis	数据是否适合 intended purpose。
Model evidence	model card、eval report、validation report、threshold rationale	模型是否满足性能、稳健性、公平性和解释要求。
GenAI evidence	prompt registry、RAG source list、groundedness eval、toxicity / safety test	生成式 AI 是否受控、可追溯、可约束。
Security evidence	threat model、pen test、prompt injection test、access review	系统是否具备安全、韧性和越权防护。
Human oversight evidence	training record、review logs、override logs、escalation records	人工监督是否真实可用。
Release evidence	gate approval、risk acceptance、rollback plan	为什么允许上线，残余风险由谁接受。
Production evidence	monitoring dashboard、incident tickets、complaint analytics、post-market review	上线后风险是否持续受管。
Vendor evidence	due diligence、contract terms、model update notice、exit plan	第三方依赖是否被治理。

8.4 Evidence 质量标准

Standard	高质量证据表现
Traceable	能从 evidence 追到 control、obligation、AI asset、release decision。
Versioned	明确适用的模型、数据、prompt、代码、知识库和 UI 版本。
Reproducible	测试方法、样本、阈值和结果足以让独立复核者理解。
Operational	不只证明设计存在，也证明控制在生产中运行。
Decision-useful	能支持 pass / fail / risk acceptance / remediation 的治理决策。
Retained	满足内部记录保留、审计和监管响应要求。

9. Financial Retail Case: AI-Assisted Credit Limit Increase Governance

9.1 场景

一家在欧盟提供信用卡产品的金融机构计划上线一个 AI-assisted credit limit increase capability:

内部风险模型预测客户是否适合提高额度。
RAG 助手检索授信政策、例外规则和近期监管政策摘要。
LLM 为 underwriter 生成“建议理由”和客户沟通草稿。
最终额度调整由人工 underwriter 批准。
系统不允许自动向客户发出额度变更、拒绝、费用调整或不利行动通知。

9.2 Applicability 假设

判断点	假设	治理动作
AI system	存在预测、检索、生成和推荐能力	进入 AI inventory。
EU AI Act role	机构作为 deployer 和 creditor；部分内部组件可能使机构承担 provider-like 责任	Legal 确认角色边界和供应商合同。
High-risk signal	涉及自然人 creditworthiness / credit access 的评估或辅助	Tier 1，按 high-impact path 运行。
Customer impact	影响额度、客户权益、解释和投诉	强制 human oversight、explanation quality 和 complaint monitoring。
Data sensitivity	PII、交易、还款、信用属性	强化 data governance、privacy review 和 access control。
GPAI dependency	调用外部 LLM 生成 rationale draft	第三方 AI due diligence、model version control、data-use terms、no-training configuration。

9.3 目标架构

Mobile / Contact Center Request
-> Credit Workflow Orchestrator
-> Eligibility Rules and Policy Constraints
-> Internal Credit Risk Model
-> RAG Policy Assistant
     -> Approved Policy Repository
     -> Retrieval Permission Filter
     -> Citation and Effective-Date Check
-> LLM Rationale Draft Service
     -> Prompt Registry
     -> Output Guardrails
     -> Sensitive Data Controls
-> Underwriter Workbench
     -> Evidence View
     -> Override / Approve / Decline
     -> Reason Code Selection
-> Customer Communication Review
-> Decision Logging and Evidence Binder
-> Monitoring and Complaint Analytics

9.4 核心控制

Risk	Control	Evidence
AI 过度影响授信判断	Underwriter 必须看到模型信号、政策引用、限制说明和可选 reason code，且必须主动确认最终决定	Underwriter decision logs、screen evidence、override analytics
生成理由不准确	RAG 只允许检索 approved policy source，LLM 输出必须引用 source ID，并由 underwriter 选择正式 reason code	Groundedness eval、citation audit、reason-code mapping test
对受保护群体产生不利影响	分群性能、approval rate、override rate 和 adverse outcome 差异进入月度监控	Fairness report、model validation、monitoring dashboard
供应商模型变化影响输出	External LLM version pinned，供应商变更触发 regression eval 和 release review	Vendor notice、version log、regression report
日志无法支持客户申诉或监管问询	记录输入特征摘要、模型版本、policy source、LLM draft、human edit diff、final decision、reason code	Immutable audit logs、evidence graph links
员工默认采纳 AI	培训强调 AI limits，UI 要求显示 uncertainty / limitation，抽样复核默认采纳率	Training attestation、UX review、quality assurance sampling

9.5 Release decision

Decision area	可接受上线条件
Scope	仅限现有信用卡客户额度调整建议；不覆盖新客户自动审批。
Automation	AI 不直接决定额度；所有客户影响动作由 underwriter 批准。
Data	仅使用已批准数据源；敏感数据访问通过 purpose-based access control。
Explainability	客户沟通使用受控 reason code 和人工审核文案，不直接发送 LLM raw output。
Monitoring	每月监控 drift、override、complaint、subgroup performance、reason quality。
Incident	错误拒绝、错误提升额度、越权数据暴露、系统性偏差触发 incident workflow。
Expansion	扩展到自动决策、新客、其他地区或新供应商模型前必须重新过 Gate 1 到 Gate 5。

10. Templates

10.1 Regulatory Applicability Matrix

使用场景: Gate 1 判断某 AI use case 的法规适用性、角色、风险分级和需要正式确认的问题。

Field	Filled example
AI asset ID	AI-CREDIT-LIMIT-001
Use case	AI-assisted credit limit increase recommendation
Jurisdiction	EU customers, EU branch operations, external LLM hosted in approved region
Business owner	Head of Consumer Credit
Product owner	Credit Card Growth PM
Technology owner	Credit Decisioning Platform Lead
Organization role	Deployer and creditor; vendor user for external LLM
AI capability	Predictive score, RAG policy assistant, generated rationale draft
Customer impact	Credit access and customer communication may be affected after human approval
Automation level	Recommend and draft; no autonomous customer-impacting action
EU AI Act screening	High-risk signal due to creditworthiness / credit access support; Legal confirmation required
NIST AI RMF mapping	Govern: owner and policy; Map: process and data; Measure: eval and fairness; Manage: monitoring and risk acceptance
ISO/IEC 42001 mapping	AIMS scope, operational control, performance evaluation, improvement process
OECD principle impact	Fairness, transparency, privacy, robustness, accountability
Initial tier	Tier 1: Regulatory significant / high impact
Required reviews	Legal, Compliance, Model Risk, Privacy, Security, Architecture, Vendor Risk, Business Owner
Decision	Proceed to controlled design with enhanced gate path
Decision rationale	Business value is material, but customer rights and credit regulation require strong controls and evidence

10.2 Obligation-Control-Evidence Map

使用场景: Gate 5 前证明外部义务、内部控制和证据之间存在可追溯关系。

Obligation / principle	Control objective	Control activity	Evidence	Owner	Cadence
EU AI Act Article 14 human oversight	人工监督必须有效，而不是形式化点击	Underwriter reviews AI recommendation, cited policy, key drivers, warning flags, and final reason code before any customer impact	Underwriter review logs, override records, training assessment	Credit Operations Owner	Monthly QA and quarterly governance
EU AI Act Article 12 logging	关键决策链路可追溯	Log model version, input summary, retrieval source ID, LLM draft, human edit, final reason code, approval user, timestamp	Immutable audit log sample, retention policy, access review	Platform Owner	Continuous logging and monthly sampling
NIST Measure	可信 AI 特征被测量	Evaluate accuracy, subgroup performance, robustness, groundedness, security, and explanation quality	Eval report, fairness report, red team report	Model Risk Lead	Before release and after material change
ISO/IEC 42001 performance evaluation	AIMS 运行有效性被复核	Management review receives KPI / KRI, incidents, exceptions, audit findings, corrective actions	Quarterly AIMS review pack	AI Governance Owner	Quarterly
OECD accountability	决策责任清楚且可问责	RACI defines business, model, data, technology, risk and vendor accountability	Approved RACI, committee minutes	Executive Sponsor	Annual review and material change

10.3 Risk-Tiered Release Gate

使用场景: 不同 risk tier 对应不同上线条件，避免低风险过度治理和高风险治理不足。

Gate requirement	Tier 3 low-risk productivity	Tier 2 controlled business use	Tier 1 regulatory significant	Tier 0 not allowed
Inventory	Required with owner and data boundary	Required with process, model, data and vendor fields	Required with full traceability and evidence binder	Record rejected / redesigned use case
Legal / Compliance	Policy attestation	Review for customer, privacy or regulatory impact	Mandatory formal review	Mandatory escalation
Model / AI evaluation	Basic output quality check	Eval contract and failure mode testing	Full validation, fairness, robustness, explainability and security testing	Design cannot proceed
Human oversight	User responsibility statement	Defined review and escalation	Tested oversight, override, kill switch and competency evidence	Not applicable after rejection
Evidence	Lightweight record	Control evidence pack	Complete obligation-control-evidence map	Rejection rationale and governance record
Approval	Product and technology owner	Product, technology, risk partner	Executive business owner, Legal / Compliance, Model Risk, Architecture, Security, Privacy	Legal / Compliance decision
Monitoring	Usage and incident channel	KPI / KRI dashboard	Production monitoring, complaint integration, periodic governance review	Monitoring not needed unless redesigned

10.4 Regulatory Change Radar

使用场景: 把法规、标准、监管口径、供应商变化和行业事件转成 impact assessment。

Field	Filled example
Radar ID	RADAR-2026-Q3-001
Source	EUR-Lex Regulation (EU) 2024/1689 official text
Source date / access date	Official Journal 2024-07-12; accessed 2026-06-30
Change signal	Internal policy update required for high-risk AI system monitoring and incident escalation
Affected assets	AI-CREDIT-LIMIT-001, AI-AML-TRIAGE-002, AI-KYC-DOC-003
Affected controls	CTRL-RISK-001, CTRL-LOG-003, CTRL-INC-004, CTRL-MON-002
Business impact	Tier 1 assets require stronger post-release review cadence and incident playbook alignment
Required action	Update control library, refresh release gate evidence, run gap assessment on Tier 1 assets
Owner	AI Governance Owner with Legal and Enterprise Architecture
Due date	2026-08-15
Decision status	Accepted for action by AI Governance Council
Evidence	Council minutes, updated control catalog, gap assessment report

10.5 Exam Q&A

Examiner question	Strong answer
How do you know where AI is used in the enterprise?	We maintain an AI inventory that covers use case, business process, system, model, vendor, data, automation level, impacted persons, jurisdiction, risk tier, controls, evidence, owners, release status and monitoring. Inventory updates are triggered by material changes in purpose, data, model, vendor, geography, customer group or automation level.
How do you convert EU AI Act obligations into engineering work?	We do not hand engineering a legal text. We map obligations to control objectives, then to control activities, test methods and evidence. For example, logging becomes a versioned audit-log schema and retention rule; human oversight becomes underwriter workflow, override rights, training and sampled QA; robustness becomes eval suites, adversarial tests and fallback design.
How do NIST AI RMF and ISO/IEC 42001 work together?	NIST AI RMF gives the operational language of Govern, Map, Measure and Manage. ISO/IEC 42001 gives the management system structure for policy, leadership, planning, support, operation, performance evaluation and improvement. Together they let us run AI governance as a repeatable operating system rather than one-off project reviews.
How do you prove human oversight is effective?	We define who reviews what, at which step, with what authority, and how override is recorded. We then test the workflow, train reviewers, monitor default acceptance, sample decision quality, and keep logs showing AI output, human edits, final decision, user, timestamp and escalation where relevant.
How would you respond to a regulator asking why an AI credit recommendation was used?	I would show the intended purpose, applicability decision, risk tier, model validation, data lineage, fairness analysis, human oversight procedure, specific decision audit trail, reason-code control, customer communication record, monitoring history, and the governance approval that accepted residual risk within the approved scope.

11. 面试表达

11.1 30 秒版本

AI regulatory architecture 不是把法规做成清单，而是把法规、标准和原则转成企业 AI 控制平面。我会先建立 AI inventory 和 applicability judgment，再用 risk tier 决定控制强度；然后把 EU AI Act 的义务、NIST AI RMF 的 Govern / Map / Measure / Manage、ISO/IEC 42001 的 AIMS 管理体系和 OECD principles 映射到 lifecycle gates、control library、evidence graph 和 production monitoring。这样产品上线时不仅能说明“我们看过法规”，还能证明哪个风险由哪个控制、哪份证据和哪个治理决策管理。

11.2 2 分钟版本

在金融零售企业里，AI 监管架构必须从产品和企业架构同时设计。我的方法是四步。

第一步是事实底座: 建 AI inventory，记录 use case、系统、模型、数据、供应商、自动化程度、影响对象、司法辖区、owner 和 release status。没有 inventory，就无法判断适用性和风险。

第二步是适用性和分级: 对 EU AI Act 这类法规，我会识别组织角色、可能 high-risk 的场景、透明度义务、GPAI 依赖和 deployer / provider 责任；同时用内部 Tier 0 到 Tier 3 把客户影响、自动化程度、数据敏感性、解释需求和供应商关键性转成治理路径。

第三步是把义务转成控制: 例如 human oversight 不是一句“人工复核”，而是 underwriter workbench、override 权限、培训、日志、抽样 QA 和升级机制；logging 不是技术日志，而是能追溯模型版本、输入摘要、检索来源、生成草稿、人工编辑和最终决定的证据链。

第四步是生命周期化: 在 idea、applicability、design、architecture、eval、release、monitoring、material change 和 retirement 每个 gate 设置输入、决策和证据。生产后监控 drift、偏差、投诉、事故和供应商变化，并进入 management review。

这套方法让 PM 能管理价值和风险，BA 能把义务转成需求和流程，Architect 能把控制做进系统边界、数据流、日志、权限和可观测性，Compliance 和 Audit 能看到完整证据链。

11.3 英文面试版本

I would not implement AI regulation as a checklist at the end of delivery. I would build it as a regulatory control plane. The control plane starts with an AI inventory and applicability assessment, then uses risk tiering to determine lifecycle gates, control strength, evidence depth and approval authority. EU AI Act helps identify risk categories and obligations; NIST AI RMF gives the Govern, Map, Measure and Manage operating language; ISO/IEC 42001 gives the AI management system; and OECD AI Principles provide the values baseline for fairness, transparency, robustness and accountability. In a financial retail context, this architecture must connect product requirements, process design, model validation, data lineage, vendor risk, human oversight, audit logging, monitoring and management review. The result is not just compliance language. It is a traceable system of controls and evidence that can support release decisions, audits, incidents and regulator questions.

11.4 高阶追问回答

Follow-up	Answer
What makes this enterprise architecture rather than compliance operations?	Enterprise architecture defines stable capabilities, ownership boundaries, information flows, integration patterns and governance mechanisms across products. Regulatory architecture places AI inventory, control library, evidence graph, lifecycle gates and monitoring into that enterprise capability model. Compliance reviews are one consumer of the architecture, not the architecture itself.
How do you avoid slowing down innovation?	Use risk-tiered gates. Tier 3 internal productivity AI gets lightweight inventory and data boundary controls. Tier 2 gets standard eval, oversight and monitoring. Tier 1 gets enhanced legal, model risk, privacy, security and evidence review. This allocates governance effort by harm potential instead of forcing every AI idea through the same process.
What is the BA contribution?	The BA translates abstract obligations into process, decision rights, exceptions, roles, business rules, data requirements, explanation needs and evidence requirements. A strong BA makes hidden automation visible and ensures AI does not silently replace human accountability.
What is the architect contribution?	The architect turns controls into system design: logging schema, model versioning, RAG source governance, permission boundaries, data lineage, observability, fallback, kill switch, vendor integration, retention and evidence capture. Without architecture, controls remain policy statements.
What would you put in a portfolio artifact?	A one-page regulatory architecture diagram, one completed applicability matrix, one obligation-control-evidence map, one risk-tiered release gate, one financial retail case study and a short regulator exam Q&A pack.

12. 自检清单

Check	Result
Only creates the requested playbook file	This document is scoped to `docs/AI_REGULATORY_ARCHITECTURE_EU_AI_ACT_NIST_ISO42001_PLAYBOOK.md`.
Uses official anchors	EUR-Lex Regulation (EU) 2024/1689, NIST AI RMF, ISO/IEC 42001 and OECD AI Principles are cited as source anchors.
Covers requested structure	Purpose, audience, source anchors, regulatory architecture framing, risk tier taxonomy, AI inventory, obligations-to-controls mapping, lifecycle gates, evidence architecture, financial retail case, templates and interview language are included.
Advanced financial retail angle	Credit limit increase case connects AI governance, product governance, model risk, customer impact, evidence and enterprise architecture.
No index modification required	This playbook stands alone and does not require index updates.
Encoding expectation	Markdown text intended for UTF-8 without BOM.