AI 底层逻辑 / 经典论文
AI Regulatory Architecture：EU AI Act / NIST / ISO42001
一句话:
231 行ai-foundations/papers/95-ai-regulatory-architecture-eu-ai-act-nist-iso42001.md
AI Regulatory Architecture / EU AI Act / NIST AI RMF / ISO 42001 解读
面向对象: AI Product Architect / Enterprise Architect / Risk Product Lead / Senior BA / Financial Services PM。 核心问题: 高风险 AI 不能把监管合规当作上线前 checklist。监管要求、风险框架、管理体系、产品门禁、运行监控和审计证据必须被设计成 architecture capability。 学习目标: 用 EU AI Act、NIST AI RMF、ISO 42001 和监管变更雷达的思路, 建立可映射、可执行、可审计、可持续更新的 AI regulatory architecture。
Source Anchors
| Source | Link | 用途 |
|---|---|---|
| EU AI Act, Regulation (EU) 2024/1689 | https://eur-lex.europa.eu/eli/reg/2024/1689/oj | 参考 risk-based AI obligations、high-risk AI、provider/deployer responsibilities |
| NIST AI RMF | https://www.nist.gov/itl/ai-risk-management-framework | 用 Govern / Map / Measure / Manage 组织 AI 风险管理活动 |
| ISO/IEC 42001 | https://www.iso.org/standard/81230.html | 参考 AI management system、责任、控制、持续改进和管理评审 |
| OECD AI Principles | https://oecd.ai/en/ai-principles | 参考可信 AI 原则、透明度、人类监督、稳健性和责任 |
| W3C PROV | https://www.w3.org/TR/prov-overview/ | 为监管证据、来源和生成过程建立 provenance 思维 |
一句话:
AI Regulatory Architecture 是把法规义务、风险框架和管理体系翻译成 inventory、risk tier、controls、release gates、runtime monitors 和 evidence graph。
1. Regulatory Architecture 不是合规清单
低成熟度做法:
legal review near launch -> checklist -> approval email -> production
高风险 AI 的问题在于:
- 用例和风险等级会变化。
- 模型、prompt、RAG source、tool contract 会变化。
- 供应商模型可能更新。
- 用户可能把系统用于原设计之外的任务。
- 监管解释和行业预期会更新。
- 审计和监管问询需要 evidence, 不是口头说明。
所以 regulatory architecture 应该是:
regulatory radar
-> applicability decision
-> obligation taxonomy
-> control library
-> product / architecture gates
-> runtime telemetry
-> evidence binder
-> change management
2. Regulatory Obligation Taxonomy
| Obligation type | Architecture translation |
|---|---|
| AI inventory | material AI systems registry, model/use/system metadata |
| Risk classification | risk tier workflow, high-impact use detection |
| Data governance | source authority, data minimization, retention, lineage |
| Technical documentation | architecture package, ADR, system card, eval reports |
| Transparency | disclosure UX, explanation, user-facing boundary |
| Human oversight | HITL design, reviewer role, override, appeal |
| Accuracy / robustness | eval gates, monitoring, incident response |
| Security | threat model, red-team tests, prompt/tool protection |
| Logging | OpenTelemetry trace, audit events, retention |
| Post-market monitoring | drift, incident, complaint, control effectiveness |
| Provider/deployer responsibility | RACI, contractual obligations, evidence handoff |
The senior move is to turn each obligation into:
obligation -> control objective -> control activity -> test -> evidence -> owner -> review cadence
3. Risk Tiering for AI Products
| Risk tier | Example | Default architecture |
|---|---|---|
| Low internal productivity | meeting summary, internal drafting | lightweight disclosure, feedback, privacy controls |
| Medium decision support | analyst copilot, internal policy assistant | eval, source citation, reviewer workflow |
| High customer-facing | customer service RAG, credit explanation | strong eval, transparency, HITL, complaints monitoring |
| Material / high-impact | credit, employment, insurance, fraud action | independent validation, legal/risk signoff, strict controls |
| Prohibited / unacceptable | manipulative or disallowed use | stop / do not build |
Risk tier must influence:
- required views.
- eval coverage.
- human oversight.
- logging retention.
- release approval.
- vendor due diligence.
- incident severity.
- post-release review.
4. AI Inventory as Control Plane
Inventory fields:
| Field | Why it matters |
|---|---|
| use_case_id | stable traceability |
| business owner | accountability |
| user group | internal/customer/regulator impact |
| geography | applicable legal regimes |
| model/provider | vendor and model risk |
| data categories | privacy and confidentiality |
| decision role | assist/recommend/decide/act |
| tool actions | side effects |
| risk tier | governance routing |
| eval pack | quality evidence |
| controls | obligation mapping |
| release status | pilot/release/scale/retired |
| incidents | post-market monitoring |
An inventory is not a spreadsheet graveyard. It should power routing, gates, dashboards and evidence queries.
5. Product Lifecycle Gates
| Gate | Regulatory architecture evidence |
|---|---|
| Intake | AI applicability, risk tier, geography, role of AI |
| Discovery | data sources, user impact, prohibited-use screen |
| Architecture | control map, C4 views, tool/data boundaries |
| Build | logging, schema, eval harness, privacy controls |
| Pilot | baseline eval, limited users, HITL, incident path |
| Release | obligation-control-evidence map, signoffs, rollback |
| Scale | monitoring, complaints, drift, control effectiveness |
| Change | model/prompt/source/tool/vendor impact assessment |
| Retirement | data deletion, evidence retention, user communication |
6. Financial Retail Case: Customer-Facing Credit Explanation AI
Scenario: AI helps explain why a loan application is pending, declined, or needs additional documentation. It does not make the credit decision.
Obligation Mapping
| Concern | Control | Evidence |
|---|---|---|
| AI role clarity | disclose AI assistant and human decision boundary | UI copy, approval record |
| No adverse action decision by AI | decision boundary policy | policy logs, workflow config |
| Explanation accuracy | source-grounded eval | eval report |
| Fair treatment | segment eval and monitoring | fairness/segment dashboard |
| Human oversight | escalation and appeal path | HITL records |
| Logging | trace with prompt/source/model version | trace sample |
| Complaint monitoring | complaint taxonomy and triage | complaints dashboard |
Release Decision
Release only if:
unsupported claim = 0 on regulated explanation set
source citation correctness >= threshold
decision boundary bypass = 0
appeal path available
release bundle complete
7. Regulatory Change Radar
| Signal | Architecture response |
|---|---|
| New regulation / final rule | update obligation taxonomy |
| New supervisory expectation | update control library |
| Vendor model policy change | vendor impact assessment |
| Incident in peer institution | red-team/eval update |
| New use case pattern | update risk tier criteria |
| Internal audit finding | remediation and architecture debt |
8. Templates
Applicability Matrix
| Question | Answer |
|---|---|
| Is AI used to assist, recommend, decide or act | |
| Is it customer-facing | |
| Does it affect access to financial products | |
| Does it use personal/sensitive data | |
| Which jurisdictions apply | |
| Which obligations apply | |
| What risk tier is assigned |
Obligation-Control-Evidence Map
| Obligation | Control objective | Control activity | Test | Evidence | Owner |
|---|---|---|---|---|---|
| Human oversight | Human can intervene | HITL queue | bypass test | review record | Ops/Risk |
| Transparency | User knows AI boundary | UI disclosure | UX review | screenshot, copy approval | Product |
| Logging | Decisions traceable | telemetry schema | trace completeness | trace sample | Platform |
9. Common Failure Modes
| Failure mode | Fix |
|---|---|
| Legal review at the end | Move applicability and risk tier to intake |
| Obligations not mapped to systems | Control library and architecture gates |
| Evidence collected manually after launch | Evidence binder by default |
| Risk tier not updated after scope change | Change impact assessment |
| Vendor obligations not connected | Contract-control-evidence handoff |
10. 面试表达
30 秒版本:
我会把 AI 合规做成 regulatory architecture, 不是上线前 checklist。先建立 AI inventory 和 risk tier, 再把法规义务映射成 control objective、control activity、test、evidence、owner 和 review cadence, 最后嵌入 product lifecycle gates、runtime monitoring 和 evidence binder。
2 分钟版本:
以 customer-facing credit explanation AI 为例, 我会先判断适用法规、地域、AI 在决策中的角色和风险等级。然后设计透明披露、source-grounded eval、decision boundary policy、human escalation、complaint monitoring、trace logging 和 release evidence。任何 prompt、model、source、tool 或用户范围变化都触发 change impact assessment。这样监管不是一个签字步骤, 而是产品和架构的运行能力。