AI Architecture Review Gate Checklists

定位: 面向 AI Solutions Architect / Enterprise Architect / AI PM / AI BA 的架构评审门禁手册。 目标: 把 AI 项目从“能 demo”评审到“能上线、能监控、能回滚、能审计、能证明价值”。 用法: 每个 AI use case 在 discovery、pilot、release、scale 四个阶段都过一次 gate。不要用单张架构图替代评审证据。

---

Source Anchors

这些来源只作为学习和评审框架锚点, 不构成法律、合规、采购或审计意见。

---

1. 为什么 AI 架构评审必须分 gate

传统系统评审常关注:

• 服务边界。
• 数据库。
• API。
• 安全。
• 部署。
• 可用性。

AI 系统还必须评审:

• 业务问题是否真的适合 AI。
• 输出错误的业务代价是什么。
• 模型是否引用正确证据。
• 检索是否按权限过滤。
• 工具调用是否可能越权。
• Eval 是否覆盖真实失败模式。
• Prompt/model/knowledge 更新是否有回归测试。
• 高风险输出是否进入人工复核。
• 用户是否真的改变工作方式。
• 上线后谁维护知识库、eval、policy、incident。

如果不分 gate, 团队常在 demo 后才发现:

• 数据不能用。
• 法务/合规不接受。
• 业务没有 owner。
• 模型质量没有评测方法。
• 架构无法审计。
• 成本或延迟超出 workflow。
• 用户不信任或不采用。

Gate 的作用是把风险前移。

Idea -> Discovery Gate -> Architecture Gate -> Pilot Gate -> Release Gate -> Scale Gate -> Quarterly Review

---

2. Gate 总览

---

3. G0 Intake Gate

评审目标

判断一个 AI 想法是否值得投入 discovery, 而不是一听“AI”就进入方案设计。

必备问题

• 谁提出需求?
• 当前业务痛点是什么?
• 影响的用户是谁?
• 是否有 baseline metric?
• 为什么不是规则、流程、报表、培训或系统修复?
• 是否涉及客户权益、信贷、合规、隐私或高风险决策?
• 是否有明确 owner?

必备证据

• 1-page use case brief。
• 初步价值假设。
• 初步风险等级。
• 初步 no-AI alternative。
• Sponsor / process owner。

Red Flags

• “领导想做 AI”但没有业务问题。
• “先做 demo 再说”但涉及高风险流程。
• 没有流程 owner。
• 只描述技术方案, 没描述用户工作。
• 成功标准是“模型能回答”。

Gate Decision

---

4. G1 Business Fit Gate

评审目标

确认业务问题、流程、用户、价值和 AI fit 足够清楚。

Checklist

• 是否有 AI Opportunity Canvas?
• 是否有 AS-IS BPMN 或 workflow map?
• 是否标出 pain metrics: cycle time、touch time、error rate、rework、backlog、cost?
• 是否识别用户角色和 stakeholder?
• 是否区分 AI fit 与 no-AI boundary?
• 是否定义 first workflow insertion point?
• 是否识别高风险 decision boundary?
• 是否有 business owner 和 operational owner?

关键追问

1. 这个流程如果不用 AI, 最小改进是什么?
2. AI 介入点是在 read、summarize、recommend、draft、decide 还是 act?
3. 哪些输出对客户、合规、财务或风险有直接影响?
4. 用户如何知道 AI 输出可信?
5. 如果用户拒绝采用, 业务价值是否消失?

金融零售例子

AML Copilot:

• 好的 AI fit: evidence aggregation, red-flag checklist, case narrative draft。
• 不好的 AI fit: automatic SAR filing decision。

Customer Service RAG:

• 好的 AI fit: approved knowledge retrieval, answer draft, citation。
• 不好的 AI fit: unauthorized fee waiver commitment。

Lending Assistant:

• 好的 AI fit: memo drafting, policy citation, missing document checklist。
• 不好的 AI fit: LLM-owned credit decision。

---

5. G2 Data and Knowledge Gate

评审目标

确认 AI 能否获得正确、合法、可追溯、按权限可见的数据和知识。

Checklist

• 是否列出 source of truth?
• 是否标出数据分类: public/internal/confidential/PII/financial/special category?
• 是否定义 data owner 和 knowledge owner?
• 是否有 data lineage?
• 是否有 policy/document versioning?
• 是否有 access control 和 entitlement filter?
• 是否有 retention policy?
• 是否有 embedding/index 的治理策略?
• 是否有 stale knowledge detection?
• 是否定义哪些数据不能进入 prompt/log?

必备资产

• Data Readiness Pack。
• Knowledge Source Inventory。
• Permission Model。
• Document Versioning Plan。
• Data Flow Diagram。

Red Flags

• 把向量库当 source of truth。
• 不知道文档版本和 effective date。
• 不知道 prompt 和日志会保存什么。
• 没有权限过滤就做企业 RAG。
• 历史标签包含偏见, 但没有评估。
• 供应商会使用客户数据训练, 但合同和配置不清。

Gate Decision

---

6. G3 AI Pattern Gate

评审目标

选择合适的 AI pattern, 避免所有需求都用 chatbot、RAG 或 agent。

Pattern Decision Matrix

Required ADRs

• RAG vs long-context vs fine-tuning。
• Workflow vs agent。
• Buy vs build vs hybrid。
• Model/provider choice。
• Tool access boundary。
• Human review boundary。
• Eval strategy。

Red Flags

• “做一个 agent”但没有 action allowlist。
• “微调模型记住政策”但政策频繁变化。
• “RAG 能解决所有幻觉”。
• “让模型自己判断是否高风险”但没有外部 gate。
• 没有 rejected options。

---

7. G4 Architecture Gate

评审目标

确认系统架构可落地、可观测、可治理、可回滚。

必画图

至少 4 张:

• C4 Context。
• C4 Container。
• Data Flow。
• Sequence Diagram。

高风险或 agent 场景再加:

• Agent Tool Loop。
• Risk / Control Architecture。
• Eval Architecture。
• Deployment Topology。
• Cost / Latency Model。

Checklist

• UI 是否只通过 backend/orchestrator 调用模型和工具?
• 是否有 AuthN/AuthZ 和 entitlement check?
• 是否有 model gateway?
• 是否有 retrieval service 和 metadata filter?
• 是否有 tool gateway 和 action policy?
• 是否有 policy/guardrail service?
• 是否有 audit writer?
• 是否有 eval runner 或 online quality checks?
• 是否有 telemetry: latency, cost, route, retrieval, tool, output quality?
• 是否定义 fallback/rollback?
• 是否区分 sync path 和 async path?
• 是否说明 vendor boundary?

Architecture Quality Bar

一张合格 AI C4 Container 图必须能回答:

• 数据从哪里来?
• 证据如何进入 prompt?
• 模型如何被调用?
• 工具如何被授权?
• 输出如何被验证?
• 高风险如何升级?
• 日志和审计证据在哪里?
• 线上如何监控?
• 谁能回滚?

Red Flags

• UI 直接调用 LLM API。
• 没有 tool permission。
• 没有 audit log。
• 没有 eval / monitoring。
• 所有错误都靠 prompt 防止。
• 没有成本和延迟预算。

---

8. G5 Eval and Risk Gate

评审目标

确认需求可测、风险可控、上线门禁明确。

Checklist

• 是否有 Requirements-to-Eval Matrix?
• 每条关键需求是否有 eval method?
• 是否有 golden dataset?
• 是否覆盖 common, edge, adversarial, missing-data, high-risk cases?
• 是否区分 deterministic checks、LLM-as-Judge、expert review?
• 是否有 severity levels?
• 是否有 release thresholds?
• 是否有 red-team backlog?
• 是否映射 OWASP LLM Top 10?
• 是否映射业务/合规风险?
• 是否有 human oversight design?
• 是否有 incident response path?

Risk-Tiered Gate

Minimum Release Gate

Red Flags

• “准确率 90%”但不知道是什么样本。
• 只用通用 benchmark。
• 没有失败样本库。
• LLM judge 没有人类校准。
• 没有上线后监控。
• 高风险场景没有人工复核。

---

9. G6 Pilot Gate

评审目标

确认可以小范围试点, 且试点可学习、可停止、可回滚。

Checklist

• Pilot scope 是否明确?
• 是否限定用户、流程、数据、风险等级?
• 是否有 success metrics?
• 是否有 stop rules?
• 是否有 rollback plan?
• 是否有 user training?
• 是否有 support channel?
• 是否有 daily/weekly review cadence?
• 是否有 incident escalation?
• 是否有 feedback capture?

Pilot Success Criteria

至少覆盖:

• Quality: answer/evidence/action quality。
• Safety: critical violation。
• Workflow: cycle time, handoff, rework。
• Adoption: activation, repeat use, override, trust。
• Cost: cost per task。
• Risk: incidents, escalations。

Red Flags

• Pilot 目标是“看用户喜不喜欢”。
• 没有 stop rule。
• 没有 baseline。
• 试点范围太大。
• 试点输出直接影响客户权益。

---

10. G7 Release Gate

评审目标

确认系统可以进入生产或受限生产。

Required Evidence Pack

• Final architecture diagrams。
• ADR set。
• Data readiness sign-off。
• Eval report。
• Risk/control pack。
• Security/privacy review。
• Operating model / RACI。
• Incident runbook。
• Release notes。
• User training material。
• Monitoring dashboard。
• Rollback plan。

Release Decision Options

Final Questions

1. 如果模型今天出错, 谁第一个知道?
2. 如果供应商明天更新模型, 谁跑回归?
3. 如果知识库过期, 谁负责修?
4. 如果用户绕过流程, 谁处理?
5. 如果输出导致客户投诉, 证据链在哪里?
6. 如果成本翻倍, 谁有权降级模型或关停功能?

---

11. G8 Scale Gate

评审目标

确认是否值得从 pilot 扩展到更多用户、产品线、区域或风险等级。

Checklist

• Pilot 是否达到 business metric?
• 是否达到 quality metric?
• 是否无 critical incident?
• 是否有 stable adoption?
• 是否用户 trust 上升?
• 是否 manager / QA / risk 接受 operating model?
• 是否有 capacity plan?
• 是否有 cost forecast?
• 是否评估新区域/产品的政策差异?
• 是否有 scale rollout plan?

Scale Risks

• 一个团队有效, 另一个团队不采用。
• 一个产品知识准确, 多产品冲突。
• 一个地区合规可接受, 另一个地区不接受。
• 高峰并发导致延迟恶化。
• Vendor pricing 随规模失控。
• Eval dataset 没覆盖新增场景。

---

12. G9 Quarterly AI Review

评审目标

上线不是结束。每季度判断这个 AI capability 是否仍然有效、合规、经济、被采用。

Quarterly Review Questions

• Use case 是否仍有业务价值?
• 用户是否继续使用?
• 是否出现质量漂移?
• 知识库是否过期?
• 供应商模型是否变化?
• 成本是否符合预算?
• 是否发生 incident?
• Eval set 是否更新?
• 风险控制是否仍有效?
• 是否应该扩大、缩小、重构或 retire?

Quarterly Evidence

• Quality trend。
• Adoption trend。
• Cost trend。
• Incident review。
• Knowledge freshness report。
• Eval regression report。
• Vendor change report。
• User feedback。
• Business outcome。

---

13. Financial Retail Gate Profiles

AML Copilot

Gate emphasis:

• Human oversight。
• Evidence citation。
• Audit trail。
• No autonomous SAR decision。
• Typology coverage。
• Prompt injection from adverse media。

Required diagrams:

• BPMN alert investigation。
• C4 container。
• RAG pipeline。
• Eval architecture。
• Risk/control architecture。

No-go triggers:

• Unsupported claims in narrative。
• Model suggests final filing decision。
• Missing audit log。
• Analyst cannot see evidence。

KYC Remediation

Gate emphasis:

• Data quality。
• Customer communication。
• Jurisdiction policy。
• Source-of-truth update。
• Customer privacy。

No-go triggers:

• AI requests unauthorized documents。
• Golden source updated without approval。
• Customer message misstates legal requirement。

Customer Service RAG

Gate emphasis:

• Knowledge version。
• Citation。
• No unauthorized promise。
• Escalation。
• Adoption and QA feedback。

No-go triggers:

• Answers without sources。
• Uses outdated fee/policy。
• Commits fee waiver or legal advice。

Payments Exception Agent

Gate emphasis:

• Tool permission。
• Idempotency。
• Approval before action。
• Ledger reconciliation。
• Customer impact。

No-go triggers:

• Agent can execute payment repair without approval。
• Tool action not audited。
• Duplicate or irreversible action risk。

Lending Assistant

Gate emphasis:

• Deterministic calculations。
• Fair lending。
• Reason codes。
• Human decision owner。
• Adverse action control。

No-go triggers:

• LLM owns credit decision。
• Protected/proxy variables unreviewed。
• Unsupported denial explanation。

---

14. Architecture Review Board Pack

Before review, prepare:

1. Executive summary.
2. Use case scope and no-AI option.
3. AS-IS / TO-BE BPMN.
4. C4 Context / Container.
5. Data Flow.
6. AI pattern ADR.
7. Requirements-to-Eval Matrix.
8. Data Readiness Pack.
9. AI Control Pack.
10. Threat Model.
11. Cost / Latency Model.
12. Operating Model / RACI.
13. Pilot / Release Plan.
14. Open risks and requested decisions.

Review meeting agenda:

---

15. Interview Talking Points

Question: How do you review an AI architecture?

30-second answer:

I review AI architecture through gates, not just diagrams. I start with business fit and workflow, then data and knowledge readiness, then AI pattern selection, then C4/data/tool architecture, then eval and risk controls, then pilot/release/scale readiness. For financial services, I require evidence citation, human oversight, audit trail, risk-tiered release gates, and operating ownership.

2-minute answer:

A model demo is not architecture approval. My review starts by asking whether the use case is worth AI and where it enters the workflow. Then I review data readiness: source of truth, permissions, metadata, retention and knowledge freshness. Next I review the AI pattern: RAG, workflow, agent, rules, fine-tuning or vendor product. The architecture gate requires C4, data flow, sequence, model gateway, retrieval, tool gateway, policy, audit and observability. The eval gate converts requirements into golden datasets, deterministic checks, LLM judge, expert review and risk-tiered release thresholds. Finally, release requires RACI, runbook, monitoring, rollback and adoption dashboard. In AML or lending, I would block release if the model can make final high-risk decisions without human approval and audit evidence.

Question: What makes an AI architecture review different from regular architecture review?

Answer:

Regular architecture review asks whether services, data, security and operations are sound. AI architecture review also asks whether model behavior is measurable, whether knowledge is grounded and current, whether tool use is bounded, whether high-risk outputs are controlled, whether eval covers failures, whether model/prompt/index changes are governed, and whether users adopt the workflow safely.

Question: What would make you stop an AI project?

Answer:

I would stop or park a project when the business problem is unclear, there is no owner, source data cannot be used, high-risk decisions are being delegated to the model, eval cannot measure critical failures, or the operating model cannot support incidents and change control. Stopping early is good architecture governance, not failure.

---

16. Practice Drills

Drill 1: Review an AML Copilot

Create a review pack with:

• AS-IS BPMN。
• RAG architecture。
• Requirements-to-Eval Matrix。
• Control pack。
• Release gate。

Then answer:

• What would you approve?
• What would you block?
• What evidence is missing?

Drill 2: Review a Customer Service RAG

Focus on:

• Knowledge ownership。
• Citation。
• Policy version。
• No-answer behavior。
• QA feedback。
• Adoption dashboard。

Drill 3: Review a Payments Agent

Focus on:

• Tool gateway。
• Action allowlist。
• Idempotency。
• Human approval。
• Audit。
• Rollback。

Drill 4: Review a Lending Assistant

Focus on:

• High-risk classification。
• Deterministic calculations。
• Policy RAG。
• Fair lending review。
• Reason-code eval。
• Human decision owner。

Drill 5: Build a Gate Decision Memo

Write a one-page decision:

Decision requested:
Gate:
Use case:
Evidence reviewed:
Approve / conditional / no-go:
Top 3 risks:
Required changes:
Next review date:
Owner:

---

17. Connection To Existing Assets

---

18. Minimum Definition of Ready and Done

Ready for Discovery

• Business owner exists.
• Pain point has initial evidence.
• Risk tier is roughly known.
• No-AI option considered.

Ready for Architecture

• AS-IS workflow documented.
• Data/knowledge sources identified.
• AI behavior boundaries defined.
• Initial eval ideas exist.

Ready for Pilot

• Architecture diagrams approved.
• Data readiness acceptable.
• Eval matrix and control pack drafted.
• Pilot scope and stop rules defined.
• RACI drafted.

Ready for Production

• Eval gate passed.
• Critical risks controlled.
• Incident runbook tested.
• Monitoring dashboard live.
• Rollback plan ready.
• Owners assigned.
• Users trained.

Ready for Scale

• Pilot value proven.
• Quality stable.
• Adoption real.
• Cost understood.
• Risk accepted.
• New scope evaluated.

---

19. Final Principle

AI architecture review is not a paperwork exercise. It is the discipline of proving that a probabilistic capability can be inserted into a business workflow without losing control of quality, risk, cost, accountability and user trust.

The strongest AI architect is not the person who draws the most complex diagram, but the person who can say:

This is the business decision.
This is the system boundary.
This is the evidence.
This is how we evaluate it.
This is how we control it.
This is who owns it.
This is how we stop it if it fails.