AI Enterprise Reference Architecture Control Plane Playbook

定位: 面向高级 AI PM / AI Architect / Enterprise Architect / Platform PM / Model Risk / 金融零售数字化负责人, 把企业 AI 从单点项目方案升级为可复用、可治理、可观测、可审计的 reference architecture 与 control plane。 目标: 能讲清楚 AI application plane、model plane、data / knowledge plane、tool / action plane、policy / control plane、eval / observability plane、identity / security plane、governance / evidence plane 如何组合成企业级 AI 平台架构。 核心观点: 企业 AI 的难点不是把一个模型接进一个流程, 而是让所有 AI 用例在统一控制面下完成路由、权限、策略、评估、监控、证据、风险接受和持续改进。

---

Source Anchors

以下来源用于校准治理、控制、可观测和安全语言。本文是学习、作品集和架构设计训练材料, 不构成法律、合规、审计或认证意见。正式项目需要按机构类型、司法辖区、客户影响、数据类型、供应商合同和内部政策复核。

---

One-Sentence Positioning

Enterprise AI Reference Architecture = 把业务体验、流程编排、模型、数据知识、工具动作、安全身份、策略控制、评估观测和治理证据放进同一张企业架构蓝图, 让每个 AI 用例不是“单点上线”, 而是“在统一控制面中受控运行”。

更短的面试表达:

AI reference architecture 的核心是 control plane: 让模型可以创新, 但让访问、动作、风险、发布、监控和审计由平台规则管理。

---

1. 为什么企业 AI 需要 Reference Architecture, 而不是项目级方案图

项目级方案图通常只回答一个问题: “这个 use case 怎么跑通?” 企业级 reference architecture 要回答的是另一组问题:

1. 哪些 AI 能力可以跨业务线复用, 哪些必须隔离?
2. 哪些模型、数据、知识库、工具和 agent workflow 已被批准使用?
3. 一个请求经过了哪些模型、检索、工具、策略、审批和人工复核?
4. 高风险动作如何被阻断、降级、审批、双控或记录?
5. 模型、prompt、RAG、tool schema 或供应商变更后, 哪些用例受影响?
6. 上线前的 eval、上线后的 monitoring、事故后的 replay 是否形成闭环?
7. 管理层、审计、模型风险、安全和业务 owner 能否看到同一套证据?

项目级方案图在 PoC 阶段有价值, 但在金融零售企业里会很快失控:

企业 AI 架构师需要从“画应用图”提升到“设计可运行的组织控制系统”。对 CBAP / PM / BA 背景的人来说, 关键不是重新学习基础架构概念, 而是把业务能力、风险责任、流程门禁、平台组件和证据链映射到同一套企业架构。

1.1 Reference Architecture 的设计边界

本文定义的企业 AI reference architecture 覆盖四类场景:

不建议把所有 AI 场景都塞进同一个运行时。Reference architecture 是统一语言和控制模型, 不是单一技术栈。成熟架构允许不同 business unit 使用不同模型、编排框架、知识库和部署方式, 但必须共享核心控制面。

---

2. 八层架构: Enterprise AI Reference Architecture

2.1 总览

Experience / Application Layer
  -> Orchestration / Workflow Layer
  -> Model Layer
  -> Data / Knowledge Layer
  -> Tool / Action Layer
  -> Policy / Control Layer
  -> Eval / Observability Layer
  -> Governance / Evidence Layer

Identity / Security Fabric 横切所有层:
  identity, session, tenant, role, entitlement, purpose, secrets, DLP, network, egress, incident response

这八层不是严格线性调用顺序, 而是企业 AI 平台的责任分解。一次请求可能同时穿过多层: 用户在应用层发起请求, workflow 编排模型和检索, 模型提出工具调用, 工具动作经过 policy control, 全链路进入 observability, 上线和变更证据进入 governance plane。

2.2 Layer 1: Experience / Application

关键组件:

金融零售设计原则:

1. 客户可见 AI 不应该把概率性输出包装成确定性承诺。
2. 员工 copilot 必须让员工知道哪些内容来自政策、哪些来自模型推断。
3. 高风险建议应进入 draft / recommendation, 不应直接成为最终业务决定。
4. 审批界面必须展示 tool 参数、数据来源、风险等级、策略命中和差异影响。

2.3 Layer 2: Orchestration / Workflow

这一层负责把业务任务拆成 AI workflow, 但不拥有最终授权。

核心控制点:

2.4 Layer 3: Model

Model layer 不是“选一个最强模型”, 而是建立模型供应、路由、版本、成本、性能和风险治理。

模型选型要按任务和风险拆开:

2.5 Layer 4: Data / Knowledge

AI 系统的数据层不只是数据湖或向量库, 而是“知识可用性、权限、血缘、质量、时效和证据”的组合。

金融零售的 data / knowledge plane 必须处理:

2.6 Layer 5: Tool / Action

Tool / action plane 是 agentic AI 的风险集中区。模型可以提出动作, 但动作必须通过平台执行边界。

工具动作分层:

2.7 Layer 6: Policy / Control

Policy / control layer 是本文的核心。它把企业规则、风险偏好、安全控制、合规要求、人工复核和发布门禁变成可执行控制。

策略决策不是只有 allow / deny:

2.8 Layer 7: Eval / Observability

AI observability 不只是系统可用性, 还要回答“AI 是否仍然适合当前用途”。

建议的 AI trace schema:

2.9 Layer 8: Governance / Evidence

Governance / evidence layer 把架构、风险、合规、模型管理、安全、运营和审计连接起来。

证据不是事后补材料, 而是运行时副产品:

AI use case intake
  -> risk tier and impact assessment
  -> architecture review
  -> eval contract and eval run
  -> release gate memo
  -> production monitoring
  -> incident / exception / change record
  -> management review and improvement action

2.10 Identity / Security Fabric

Identity / security 不作为第九层, 而是横切所有层的安全织网:

---

3. Control Plane vs Data Plane

3.1 核心区别

一句话:

Data plane 让 AI 做事; control plane 决定 AI 在什么身份、什么目的、什么风险等级、什么证据要求下做事。

3.2 Control Plane 核心组件

3.3 一次受控 AI 请求的逻辑序列

sequenceDiagram
  participant U as User / Channel
  participant I as Identity and Session
  participant A as AI Application
  participant W as Orchestration / Workflow
  participant P as Policy Engine
  participant K as Data / Knowledge Plane
  participant M as Model Gateway
  participant T as Tool Gateway
  participant E as Eval / Observability
  participant G as Governance Evidence

  U->>I: Authenticate, role, tenant, purpose
  I->>A: Session context and entitlement
  A->>W: User task and case context
  W->>P: Check use case, risk tier, data access
  P->>K: Allowed retrieval scope
  K->>W: Evidence with labels and citations
  W->>M: Model request with prompt version and context labels
  M->>E: Log model route and token/cost metrics
  M->>W: Response or tool proposal
  W->>P: Check proposed action, data, purpose, risk
  alt tool allowed or approved
    P->>T: allow / approval requirement / dry run
    T->>E: Log tool request and result
    T->>W: Scoped tool result
  else denied
    P->>E: Log denial and policy rule
    P->>W: Safe refusal or escalation path
  end
  W->>A: Answer, draft, decision support, or escalation
  A->>E: Final output, feedback hook, quality signal
  E->>G: Evidence bundle, gate status, monitoring record

3.4 Risk Tier 设计

Risk tier 不是纯技术分级, 它应组合业务影响、客户影响、动作能力、数据敏感度、自动化程度、可逆性和监管敏感度。

Risk tier 应驱动 control requirements:

risk tier
  -> allowed model class
  -> allowed data class
  -> allowed tool action tier
  -> eval depth
  -> human oversight mode
  -> logging retention
  -> release authority
  -> monitoring cadence
  -> evidence binder depth

---

4. Reference Architecture Views

Reference architecture 不能只有一张大图。不同受众需要不同视图, 但这些视图必须指向同一套架构对象。

4.1 Capability View

Capability view 用于向 CTO、CDAO、COO、CRO、业务负责人解释“企业 AI 平台要建设哪些能力”。

Capability view 的输出不是技术选型, 而是平台建设路线:

Phase 1: inventory + model gateway + basic RAG + trace
Phase 2: policy engine + tool gateway + eval gate + risk tier
Phase 3: evidence binder + production eval + advanced workflow + management dashboard

4.2 C4 / Container View

C4 container view 用于向架构评审委员会说明系统边界、运行时组件和责任分配。

flowchart TB
  Channels[Channels: Web, Mobile, Contact Center, Ops Workbench] --> App[AI Application Services]
  App --> IAM[Identity and Entitlement Service]
  App --> Orchestrator[AI Orchestration Service]
  Orchestrator --> Prompt[Prompt and Context Service]
  Orchestrator --> ModelGW[Model Gateway]
  Orchestrator --> Retrieval[Knowledge Retrieval Service]
  Orchestrator --> ToolGW[Tool Gateway]
  Retrieval --> Knowledge[(Knowledge Index / Vector Store)]
  Retrieval --> DataLake[(Data Lake / Document Store)]
  ToolGW --> Policy[Policy Engine]
  ToolGW --> Connectors[Business Connectors]
  Connectors --> Core[Core Banking / CRM / Case / Payment / AML Systems]
  Policy --> ControlLib[(Control Library and Policy Store)]
  ModelGW --> ModelReg[(Model and Prompt Registry)]
  Orchestrator --> Trace[Trace and Event Collector]
  ModelGW --> Trace
  ToolGW --> Trace
  Policy --> Trace
  Trace --> Obs[(Observability Store)]
  Trace --> Eval[EvalOps Platform]
  Eval --> Evidence[(Evidence Binder)]
  ControlLib --> Evidence
  ModelReg --> Evidence

Container 责任边界:

4.3 Sequence View

Sequence view 用于说明关键场景的动态行为, 尤其是控制点出现在哪里。

建议至少为每个 high-risk AI use case 画四类序列:

示例: 客服 AI 生成退款处理草稿:

Customer complaint
  -> agent desktop loads case
  -> identity service confirms agent role and customer scope
  -> retrieval service fetches refund policy and transaction history with entitlement filter
  -> model gateway generates refund rationale and proposed action
  -> tool gateway classifies refund as customer-impacting action
  -> policy engine requires supervisor approval above threshold
  -> supervisor sees approval packet: reason, policy citation, amount, customer impact, prior refunds
  -> approved action executed through payment / case system
  -> trace, approval, tool result and final customer message stored in evidence binder

4.4 Control View

Control view 把架构组件映射到控制目标、风险、控制、证据和 owner。它是金融零售架构评审最有价值的视图。

4.5 Operating View

Operating view 说明组织如何运行这套 reference architecture。

RACI 示例:

---

5. Financial Retail Case: AML / Credit / Customer Service AI Platform Reference Architecture

5.1 案例背景

一家区域性银行希望建设统一 AI 平台, 支撑三类优先用例:

关键架构选择:

1. 不为三个业务线分别搭三套 AI 平台。
2. 建立统一 model gateway、knowledge ingestion、policy engine、tool gateway、eval gate、trace schema 和 evidence binder。
3. 允许每个业务域拥有自己的知识库、工作流、eval dataset、审批规则和风险阈值。

5.2 Capability Mapping

5.3 AML Reference Architecture

AML case workbench
  -> identity confirms analyst role, unit, case assignment
  -> orchestration loads alert, customer profile, transaction pattern, prior case links
  -> knowledge plane retrieves AML policy, typology, case procedures, entity graph evidence
  -> model gateway generates case summary and suspicious pattern explanation
  -> policy engine blocks auto-disposition of high-risk alerts
  -> tool gateway allows draft case note, not final SAR submission
  -> analyst reviews, edits, attaches evidence, decides disposition
  -> trace and decision package enter evidence binder

AML 关键控制:

5.4 Credit Reference Architecture

Loan origination system
  -> applicant documents and bureau data loaded under purpose binding
  -> AI summarizes application and checks required documents
  -> credit policy retrieval returns applicable rules and exceptions
  -> model drafts underwriting memo and reason code candidates
  -> policy engine classifies as regulated decision support
  -> human underwriter confirms facts, edits memo, makes decision in LOS
  -> model output, human edits, override and final decision evidence are linked

Credit 关键控制:

5.5 Customer Service Reference Architecture

Contact center console
  -> agent handles authenticated customer session
  -> AI retrieves product policy, customer case history and current complaint context
  -> model generates answer draft with citations and escalation flag
  -> policy engine checks complaint, vulnerability, refund, legal phrase and customer impact
  -> low-risk answer can be sent by agent after review
  -> refund or commitment language enters approval queue
  -> final response and approval trace are stored for QA and complaint monitoring

Customer Service 关键控制:

5.6 三个域共享的 Route-to-Release

Use case intake
  -> risk tier assignment
  -> architecture view package
  -> data / knowledge readiness review
  -> model and tool route approval
  -> eval contract
  -> offline eval and red-team
  -> pilot release with monitoring
  -> production gate
  -> ongoing review and evidence refresh

---

6. Artifact Templates

6.1 Reference Architecture Canvas

6.2 Control Plane Checklist

6.3 Architecture Decision Matrix

6.4 Route-to-Release Diagram

flowchart LR
  A[Use Case Intake] --> B[Risk Tier and Impact Assessment]
  B --> C[Reference Architecture Canvas]
  C --> D[Data / Knowledge Readiness]
  C --> E[Model and Tool Route Approval]
  D --> F[Eval Contract]
  E --> F
  F --> G[Offline Eval and Red-team]
  G --> H{Eval Gate}
  H -->|No-go| R[Remediation and Re-test]
  R --> G
  H -->|Limited go| P[Pilot with Monitoring]
  H -->|Go| P
  P --> I{Production Gate}
  I -->|Scale| S[Production Release]
  I -->|Restrict| L[Limited Scope Release]
  I -->|Rollback| RB[Rollback / Manual Process]
  S --> M[Ongoing Monitoring]
  L --> M
  M --> N[Trace Mining and Incident Review]
  N --> O[Dataset / Policy / Control Update]
  O --> F
  M --> V[Evidence Binder and Management Review]

Release memo 最小字段:

---

7. Interview Answers

7.1 30 秒版本

企业 AI 不能只画项目级方案图, 因为真正的风险来自跨用例的模型、数据、工具、权限、评估和审计不可控。我会用 enterprise AI reference architecture 把 experience、workflow、model、data / knowledge、tool / action、policy / control、eval / observability、governance / evidence 八层串起来, 再用 model gateway、tool gateway、policy engine、eval gate、trace 和 risk tier 组成 control plane。这样每个 AI 用例都能在统一边界内做模型路由、数据权限、动作审批、上线门禁、生产监控和证据沉淀。

7.2 2 分钟版本

我会先区分 data plane 和 control plane。Data plane 负责业务请求实际执行, 比如检索知识、调用模型、生成回复、提出工具动作。Control plane 负责决定这些动作是否被允许、是否需要审批、如何评估、如何记录和如何停用。

在架构上, 我会拆成八层。第一层是 experience / application, 处理客户、员工、运营和审批体验。第二层是 orchestration / workflow, 管 workflow state、agent step、fallback 和人工升级。第三层是 model plane, 通过 model gateway 管模型路由、版本、供应商边界和成本。第四层是 data / knowledge plane, 管数据分类、知识库、RAG、权限和证据引用。第五层是 tool / action plane, 通过 tool gateway 管业务系统动作、schema、幂等和执行日志。第六层是 policy / control plane, 用 policy engine、risk tier、approval、eval gate 和 kill switch 管风险。第七层是 eval / observability, 把 offline eval、online monitoring、trace、metrics、logs 和 replay 接起来。第八层是 governance / evidence, 形成 AI inventory、ADR、release memo、evidence binder 和 management review。

在金融零售落地时, AML、信贷和客服可以共享 model gateway、policy engine、tool gateway、EvalOps 和 trace schema, 但保留各自的知识库、评估集、审批规则和风险阈值。比如 AML 可以让 AI 生成 case summary 和 SAR narrative 草稿, 但 policy engine 禁止自动关闭高风险 case; 信贷 AI 可以生成审批备忘录, 但最终决定由 underwriter 负责; 客服 AI 可以生成回复草稿, 但退款或承诺类动作必须走审批。

7.3 Chief Architect / CTO 版本

我会把 enterprise AI reference architecture 定义为一套平台控制面, 而不是一套单一应用框架。CTO 需要关心的不是“哪个团队接了哪个模型”, 而是企业是否拥有统一的 AI route、control、observe、govern 能力。

我的目标架构有三个原则。

第一, runtime 解耦。Application、workflow、model、knowledge、tool 可以由不同团队和技术栈实现, 但必须通过 model gateway、knowledge entitlement、tool gateway 和 policy engine 接入统一控制。

第二, risk-based control。不同风险等级走不同模型、数据、工具、eval、审批、日志保留和发布权限。内部低风险知识问答不需要和自动化账户冻结同等治理, 但两者都要纳入 inventory、trace 和 evidence。

第三, evidence by design。所有关键请求都生成结构化 trace, 串联 identity、purpose、model、prompt、retrieval、tool、policy、approval、output 和 feedback。上线前的 eval gate、上线后的 monitoring、事故后的 replay 和管理层 review 都从同一条证据链派生。

对金融零售来说, 这套架构的价值是把创新速度和风险控制同时产品化。平台团队提供 reusable capabilities, 业务团队专注用例和价值, 风险与合规团队通过控制视图和 evidence binder 做有效挑战, 架构团队通过 reference architecture 保证扩展时不形成一堆不可治理的 AI 孤岛。

7.4 追问准备

---

8. 作品集表达方式

如果把本文转成作品集, 建议输出四件资产:

面试时不要从技术组件堆叠开始, 而要从企业问题开始:

我解决的是 AI 从 PoC 扩散到企业生产后出现的治理断裂: 模型难控、数据难控、工具动作难控、上线质量难控、生产风险难控、审计证据难控。因此我用 reference architecture 和 control plane 把业务价值、平台能力和风险治理统一起来。