AI 采购入口 / 供应商评估沙盒 / Build-Buy 决策架构解读 (AI Procurement Intake / Vendor Evaluation Sandbox / Build-Buy Decision Architecture)

Date: 2026-06-30
Status: evergreen
Audience: experienced CBAP / financial retail PM / solution architect / enterprise architect moving into AI product and AI architecture
Output: 一份可放入作品集的 AI procurement intake, vendor sandbox, benchmark, build-buy-partner decision 和 production promotion gate 架构笔记

---

Why Procurement Intake Is An Architecture Control Point

AI 采购入口不是行政流程, 而是企业 AI 架构的第一道控制点。它决定一个 AI idea 会不会被错误地推入 vendor demo、PoC、采购谈判或生产集成。成熟机构不会先问"哪家供应商最好", 而是先问:

上游 procurement intake 的核心价值:

1. 把 AI idea 变成可测量的业务和风险假设。
2. 把 vendor comparison 变成 architecture comparison。
3. 把 PoC 变成受控 sandbox, 不让试点自然漂移成 shadow production。
4. 把 build-buy 选择从偏好讨论升级为 evidence-based decision。
5. 把后续合同、退出、投资叙事和生产上线建立在证据之上。

边界说明: 本文聚焦 procurement lifecycle 上游的 intake, triage, sandbox, benchmark 和 build-buy decision。合同条款、退出迁移和董事会投资 narrative 属于下游材料, 这里只定义它们需要的输入证据。

---

Concept Diagram

flowchart LR
  A[AI idea / vendor pitch / business pain] --> B[Intake funnel]
  B --> C{Use-case triage}
  C -->|No AI fit| C1[Process / rules / data fix]
  C -->|Low value or high risk| C2[Stop or defer]
  C -->|Candidate| D[Decision architecture]
  D --> D1[Build]
  D --> D2[Buy]
  D --> D3[Partner]
  D --> D4[Hybrid]
  D --> E[Sandbox charter]
  E --> F[Vendor and internal option benchmark]
  F --> G[Evidence pack]
  G --> H{Architecture review board}
  H -->|No-go| H1[Reject / redesign]
  H -->|Limited pilot| H2[Controlled pilot with constraints]
  H -->|Production candidate| I[Production promotion gate]
  I --> J[Contract, security, privacy, risk, model validation, operating model]

一条实用原则:

Intake owns the question "should this enter the AI option space"; sandbox owns "which option works under controlled evidence"; architecture gate owns "can this be operated safely at production scale".

---

Intake-To-Sandbox-To-Decision Architecture

1. Intake Funnel

AI intake 要求每个 idea 先提交最小证据, 而不是直接预约 vendor demo。

2. Triage Gate

把用例分成四类:

3. Sandbox Charter

Sandbox charter 必须在供应商测试前冻结:

4. Decision Board

Decision board 不应只由 procurement 或 product 决定。最小构成:

---

Build / Buy / Partner Decision Model

Build-buy-partner 不是三选一口号, 而是一组架构边界决策。

Decision Axes

Component-Level Decision

不要为整个用例做一个笼统决定。把 AI system 拆到组件层:

Practical Decision Rule

---

Vendor Sandbox And Benchmark Design

Sandbox Design Principles

1. 同一任务, 同一数据, 同一 rubric, 同一 cost and latency measurement。
2. 至少比较 vendor option, internal baseline, no-AI baseline。
3. 测试 positive cases, negative cases, edge cases, abuse cases, stale-source cases, restricted-data cases。
4. 输出必须可追踪到 prompt, model, source, tool call, reviewer, decision。
5. sandbox 只能使用批准数据, 不能连接生产写动作。
6. benchmark 结论必须包含 architecture fit, not just accuracy。

Benchmark Plan

Sandbox Evidence Pack

每个 vendor 或 internal option 都要产出:

---

Financial Retail Scenarios

1. GenAI Contact Center Copilot

Hard failures:

• AI promises fee reversal outside policy。
• AI misses complaint language or vulnerable customer marker。
• AI cites stale product terms。
• AI outputs account data to unauthorized role。

2. KYC Document Intelligence

Hard failures:

• Wrong identity attribute without confidence flag。
• Document retention exceeds approved period。
• Evidence cannot be exported for audit or regulator inquiry。
• Model cannot handle jurisdiction-specific document rules。

3. AML Investigation Workbench

Hard failures:

• AI omits material suspicious activity。
• AI invents transaction rationale。
• AI suggests final SAR decision as authoritative。
• Case trace cannot reconstruct evidence used。

4. Credit Decision Support

Hard failures:

• AI uses protected-class proxy or unsupported inference。
• AI drafts adverse action reason not supported by system of record。
• Human reviewers over-rely without challenge。
• Vendor cannot provide versioned evidence for model/prompt changes。

5. Payments Fraud Intervention

Hard failures:

• AI triggers payment action without authorization。
• AI misses urgent scam indicators。
• Latency breaks real-time intervention window。
• Tool call cannot be replayed or reversed。

---

Metrics / Control / Evidence Model

Use a three-layer evidence model: metric proves behavior, control constrains risk, evidence proves the control operated.

Control mapping:

---

Anti-Patterns And Failure Modes

---

Architecture Mapping To RAG / Agent / Copilot / Eval / Governance

---

ADR Draft

ADR: AI Procurement Intake And Vendor Sandbox Decision Architecture

Status: Proposed
Date: 2026-06-30

Context:
Financial retail AI initiatives are entering the portfolio through business ideas, vendor pitches,
executive pressure and local productivity experiments. Without a common intake and sandbox
architecture, teams may select vendors before defining outcomes, data boundaries, eval contracts,
architecture fit, risk tier and production evidence gates.

Decision:
Create an upstream AI procurement intake and vendor evaluation sandbox architecture. Every AI
candidate must pass intake completeness, use-case triage, sandbox charter, controlled benchmark,
build-buy-partner decision record and production promotion gate before procurement contracting
or production integration.

Options Considered:
1. Let procurement run standard vendor questionnaires first.
2. Let product teams run ad hoc PoCs and bring winners to architecture review.
3. Establish a common intake-to-sandbox-to-decision architecture across product, risk, procurement and architecture.

Decision Rationale:
Option 3 keeps AI vendor selection evidence-based and architecture-aware. It prevents demo bias,
shadow production, uncontrolled data exposure and premature lock-in. It also gives downstream
contracting, third-party risk, model validation and executive funding a stronger evidence base.

Consequences:
- Teams must define outcome, workflow, AI role, data boundary, no-AI baseline and eval contract before vendor testing.
- Vendors must be compared against the same sandbox tasks, rubric, cost, latency, risk and architecture-fit criteria.
- Production promotion requires traceable evidence, not product enthusiasm.
- The organization must maintain reusable templates, datasets, scorecards and gate records.

Reversal Triggers:
- Intake gate blocks too many low-risk experiments without learning value.
- Sandbox cycle time becomes disproportionate to risk tier.
- Platform-level approved patterns make some repeated sandbox steps redundant.
- Regulatory, legal or internal policy changes require a stronger or different gate.

---

Interview Answer

30 秒版本

我会把 AI procurement intake 当成架构控制点, 而不是采购表单。先用 outcome、workflow、AI role、data boundary、risk tier 和 no-AI baseline 做 triage, 再用受控 sandbox 对 build、buy、partner、hybrid 方案做同一数据、同一 rubric、同一成本和延迟基准测试。最后用 evidence pack 支撑 ADR、risk acceptance 和 production gate, 防止 vendor demo 直接变成生产系统。

2 分钟版本

在金融零售里, 例如 AML investigation workbench 或 KYC document intelligence, 我不会先问哪家供应商 demo 最好。我会先建立 intake funnel: 业务 outcome 是什么, AI 在流程中是检索、摘要、建议还是执行, 哪些数据会进入 prompt、embedding、日志和供应商, 哪些行为必须人工审批, no-AI baseline 是什么。通过 triage 后, 我会设计 sandbox charter, 用同一批脱敏或合成数据、golden set、red-team cases 和业务 rubric 比较供应商方案、内部方案和流程方案。评估不只看 accuracy, 还看 critical failure、grounding、权限过滤、成本、p95 延迟、trace 完整性、审计导出、模型变更、工具权限和架构适配。决策不是简单买或不买, 而是组件级 build-buy-partner: 例如可以买 OCR 或 copilot UI, 但内部保留 model gateway、RAG source registry、eval contract、tool gateway 和 audit evidence。只有 evidence pack 能支撑 risk、privacy、security、model validation 和 production promotion gate 时, 才进入受控 pilot 或采购合同阶段。

CTO 版本

I would institutionalize AI procurement intake as a control-plane pattern. The control plane has five artifacts: intake card, sandbox charter, benchmark evidence, build-buy-partner ADR and production promotion packet. It prevents premature vendor coupling by forcing every option through the same workflow, data, risk, evaluation, cost, latency and architecture-fit tests. At component level, I would usually buy commodity capability, build policy and evidence control points, and partner only where domain transfer is required. For regulated financial use cases, the winning option is not the one with the best demo; it is the option that can be integrated through our identity, data, RAG, tool, eval, observability, incident and audit architecture while keeping concentration risk and exit constraints explicit.

---

7-Day Practice Plan

---

Source Anchors