Enterprise AI Reference Architecture：控制平面
一句话:
Enterprise AI Reference Architecture / Control Plane 解读
面向对象: Enterprise Architect / AI Solution Architect / AI Platform PM / Senior BA / AI Product Lead / Risk Technology Lead。 核心问题: 企业 AI 如果每个 use case 都各自画一套方案, 会在模型接入、RAG、工具权限、日志、评估、风控、审计和运营上形成重复建设。参考架构的价值不是画一张漂亮图, 而是定义哪些能力必须共享、哪些边界必须一致、哪些变体允许业务线自己配置。 学习目标: 建立一套面向金融零售的 Enterprise AI Reference Architecture: application plane、orchestration plane、model plane、data/knowledge plane、tool/action plane、policy/control plane、eval/observability plane、governance/evidence plane。
Source Anchors
| Source | Link | 用途 |
|---|---|---|
| NIST AI RMF | https://www.nist.gov/itl/ai-risk-management-framework | 用 Govern / Map / Measure / Manage 定义风险治理、评估、监控和持续管理 |
| ISO/IEC 42001 | https://www.iso.org/standard/81230.html | 参考 AI management system、职责、运营、绩效评估和持续改进 |
| OpenTelemetry | https://opentelemetry.io/docs/ | 参考 trace、metric、log 的可观测性语言, 映射到 AI telemetry |
| NIST Cybersecurity Framework 2.0 | https://www.nist.gov/cyberframework | 将 AI 参考架构和 identify / protect / detect / respond / recover 的安全运营语言连接 |
一句话:
Enterprise AI Reference Architecture 是企业级 AI 系统的 shared mental model: 它把体验、编排、模型、数据、工具、策略、评估、可观测性和治理证据拆成可复用、可控制、可演进的架构平面。
1. 为什么需要参考架构
单个 AI use case 常常只画:
User -> App -> LLM -> Response
生产级企业 AI 实际上是:
User / Employee / System
-> Product experience
-> Workflow / agent orchestration
-> Context / retrieval / memory
-> Model gateway / routing
-> Tool gateway / business systems
-> Policy / control plane
-> Eval / observability / incident loop
-> Evidence / governance / audit
没有参考架构会出现:
- 每个团队自己接模型, 成本、隐私、日志和 vendor risk 不一致。
- 每个团队自己做 RAG, 知识源权限、版本、引用和 freshness 不一致。
- 每个团队自己做 tool calling, 权限、幂等、审批、回滚和审计不一致。
- 每个团队自己定义 eval, 质量门槛不可比较。
- 风险团队只能上线前人工审查, 无法持续监控。
- 平台团队变成接需求团队, 无法产品化横向能力。
参考架构的作用不是限制创新, 而是把重复且高风险的部分标准化, 让业务团队在明确 guardrails 内更快交付。
2. 八层参考架构
| Plane | 核心职责 | 典型组件 | 关键设计问题 |
|---|---|---|---|
| Experience / Application | 用户、员工、客户、API 的交互入口 | Web/mobile、agent UI、copilot、case screen、API | 用户知道 AI 边界吗, 如何反馈和转人工 |
| Orchestration / Workflow | 管理任务流、状态、工具调用和人工节点 | workflow engine、agent runtime、state machine、HITL queue | 何时自动、何时人工、何时补偿和回滚 |
| Model | 模型接入、路由、调用、版本和成本 | model gateway、router、cache、small/frontier model | 哪个任务用哪个模型, 如何隔离 vendor risk |
| Data / Knowledge | 业务数据、知识源、检索、特征和上下文 | RAG、knowledge graph、feature store、semantic layer | 哪些数据可用、可外发、可引用、可删除 |
| Tool / Action | AI 可调用的业务系统和外部动作 | tool gateway、API connectors、event bus、business services | 工具权限、幂等、审批、审计和副作用 |
| Policy / Control | 策略、权限、风险分层、控制和门禁 | policy engine、risk tiering、DLP、guardrails、kill switch | 哪些行为允许、拒绝、升级或暂停 |
| Eval / Observability | 上线前评估、线上监控、质量和成本 | eval harness、trace、metrics、logs、dashboard、alerts | 如何证明质量、成本、风险和体验可控 |
| Governance / Evidence | 证据、审计、管理评审和持续改进 | AI inventory、ADR、model/system card、evidence binder | 如何回答审计、监管、管理层和事故复盘 |
高级架构师的重点是识别每层的 owner 和接口:
- 哪些能力属于平台团队。
- 哪些能力由业务产品团队配置。
- 哪些能力由风险/安全/数据 owner 审批。
- 哪些能力必须统一观测和留证。
3. Control Plane vs Data Plane
AI reference architecture 需要明确 control plane 和 data plane。
Data plane
Data plane 处理实际请求、上下文、模型输出和工具动作:
request -> context -> model -> tool/action -> response
Control plane
Control plane 决定请求能不能走、走哪条路径、需要什么证据:
risk tier
-> policy decision
-> model route
-> tool permission
-> eval gate
-> monitoring threshold
-> evidence capture
| Control Plane Capability | 作用 | 例子 |
|---|---|---|
| Risk classifier | 按任务、用户、数据、动作影响分层 | 客服问答 low, 信贷解释 high |
| Policy engine | 决定 allow / deny / escalate / redact | PII 外发拦截、投资建议边界 |
| Model gateway | 统一接入、路由、记录、限流 | approved model allowlist |
| Tool gateway | 控制工具权限和副作用 | read-only、approval-required、write action |
| Eval gate | 上线前和变更前强制评估 | prompt/model/RAG release gate |
| Observability | 记录 trace、latency、cost、quality、risk | request span、retrieval span、tool span |
| Evidence capture | 将决策、版本和审批沉淀为证据 | ADR、eval report、audit log |
如果没有 control plane, 每个 AI application 都会变成自己的治理孤岛。
4. Reference Architecture Views
一张大图不够, 至少需要五种视图。
| View | 回答的问题 | 典型产物 |
|---|---|---|
| Capability view | 企业需要哪些 AI 能力 | capability map、platform service catalog |
| C4 / container view | 系统组件如何部署和集成 | context/container/component diagram |
| Sequence view | 一次请求如何穿过策略、检索、模型、工具和日志 | sequence diagram、trace design |
| Control view | 哪些风险由哪些控制处理 | risk-control matrix、policy flow |
| Operating view | 谁负责运营、变更、事故、复盘和改进 | RACI、runbook、review cadence |
对 BA/PM 来说, capability view 和 sequence view 最重要, 因为它们把业务动作和架构责任连起来。 对架构师来说, control view 和 operating view 最容易暴露生产风险。
5. Financial Retail Case: Shared AI Case Assist Platform
场景:
- AML alert triage。
- 信贷运营 case summary。
- 客服投诉摘要。
- KYC 文档检查。
如果四个团队各自做, 会重复建设:
- 文档抽取。
- case summary。
- policy RAG。
- human review queue。
- audit log。
- eval harness。
- model gateway。
参考架构做法:
Business apps
-> shared case-assist workflow
-> shared knowledge/RAG services
-> shared model/tool gateways
-> shared eval/observability
-> domain-specific policies and templates
| Shared Capability | 可复用部分 | 业务线可变部分 |
|---|---|---|
| Case summarization | summary schema、citation requirement、eval rubric | 字段、政策、话术 |
| Document extraction | OCR/extraction pipeline、confidence threshold | 文档类型、验证规则 |
| Policy RAG | source registry、permission filter、citation | policy corpus、jurisdiction |
| HITL queue | review workflow、override reason、SLA | reviewer role、priority rules |
| EvalOps | golden set tooling、judge calibration、report | scenario set、threshold |
| Audit evidence | trace id、version capture、approval log | retention, report format |
这个参考架构既支持共享平台, 也保留业务线差异。
6. ADR Draft
| 项目 | 内容 |
|---|---|
| 决策 | 采用 enterprise AI reference architecture, 将 model gateway、tool gateway、eval/observability、policy/control 和 evidence capture 作为共享平台能力 |
| 背景 | 多个金融零售 AI use case 需要相似的 RAG、模型接入、工具控制、评估和审计能力 |
| 替代方案 | 每个业务线自建 AI stack; 全部集中由 CoE 交付; 只使用单一 vendor 平台 |
| 选择理由 | 共享 control plane 降低风险和重复建设, 业务线可在 guardrails 内配置体验、知识源和流程 |
| 影响 | 需要平台产品 owner、service catalog、SLO、funding model、adoption telemetry 和 governance cadence |
| 反转条件 | 若共享平台阻碍高差异业务场景, 需要拆分为 federated platform capabilities 而不是回到完全自建 |
7. 面试表达
30 秒版本
企业 AI 参考架构的核心是把 AI 系统拆成多个平面: 体验、编排、模型、数据/知识、工具、策略控制、评估可观测性和治理证据。这样做的价值是让 model gateway、tool gateway、policy engine、eval gate、observability 和 audit evidence 变成共享能力, 避免每个 use case 重复建设和风险不一致。
2 分钟版本
我会先把业务 AI 场景映射到 capability view, 看哪些能力应该平台化, 哪些允许业务线配置。然后用 C4 和 sequence view 设计请求如何经过 risk tiering、policy engine、RAG、model gateway、tool gateway、HITL、logging 和 evidence capture。高风险金融场景不能只画应用架构, 必须画 control view 和 operating view: 哪些动作被允许, 哪些要转人工, 哪些指标触发暂停, 谁负责 incident 和复盘。 例如 AML、信贷、客服和 KYC 都需要 case summary、policy RAG、人工复核、审计 trace 和 eval。与其四个团队各做一套, 不如把这些做成共享平台能力, 业务线只配置知识源、流程、阈值和话术。
Chief Architect / CTO 版本
我会把 Enterprise AI Reference Architecture 看成 AI transformation 的 backbone。CTO 需要看到技术复用和 SLO, CISO/CRO 需要看到 control plane, CPO 需要看到业务团队如何在 guardrails 内创新。成熟的架构不是一个 AI app, 而是一套能支撑多条业务线持续交付、监控、审计和演进的 AI platform operating model。