AI Policy-as-Code Decision Automation Playbook

受众: AI Product Architect / AI Platform PM / Enterprise Architect / Risk & Compliance Technology Lead / 高阶 BA。 核心问题: 如何把金融零售 AI 产品中的“政策、权限、决策、审批、解释和审计”从 prompt 中外置出来, 变成可测试、可版本化、可审批、可回滚的 decision automation 架构。 学习目标: 能设计一个以 DMN、Policy-as-Code、OPA/Rego、Cedar、Zanzibar/ReBAC、PDP/PEP、decision service、simulation 和 audit evidence 为核心的 AI 决策自动化方案, 并能用信贷、KYC、支付争议、客户建议边界和 Agent 工具授权案例讲清楚。

---

Source Anchors

这些来源是本文的术语和架构锚点, 不构成法律、合规或审计意见。正式项目必须由 legal / compliance / risk 结合司法辖区、产品、客户类型、模型用途和内部政策确认。

---

1. 核心定位: AI 决策不能藏在 Prompt 里

金融零售 AI 产品里, 很多高风险边界看起来像“回答风格”或“模型指令”, 实际上是决策和控制问题:

能不能读取这个客户?
能不能使用这份 KYC 文件?
能不能建议退款?
能不能输出个性化金融建议?
能不能调用账户冻结工具?
能不能把拒贷原因展示给客户?
能不能绕过人工审批?

这些问题不能靠 prompt 解决。Prompt 可以表达偏好和任务说明, 但它不是授权系统、规则引擎、审批系统、审计系统或监管证据。成熟的 AI 产品架构应该把 guardrails 分层:

一句话:

The model may propose.
The decision service decides.
The policy engine authorizes.
The workflow approves.
The audit system remembers.

中文表达:

模型负责生成建议, 决策服务负责规则判断, 策略引擎负责授权, 工作流负责审批, 审计系统负责留证。

---

2. Decision Automation Framework

高阶 AI 产品架构不要先问“用哪个模型”, 而要先问“哪些决策正在被自动化、辅助或影响”。本文建议用 8 层框架:

Decision inventory
-> Decision classification
-> Decision model
-> Policy architecture
-> Runtime PDP/PEP design
-> Test and simulation
-> Release governance
-> Audit, monitoring and rollback

2.1 Decision Inventory

把 AI 产品里所有“判断点”登记出来, 包括模型判断、规则判断、人工判断和系统授权。重点不是画流程图, 而是识别每个判断点的后果、证据和控制。

2.2 Decision Classification

对每个决策做风险分类。金融零售里, 分类至少看五个维度:

输出不是一个标签, 而是控制强度:

2.3 Decision Model

不同决策适合不同表达方式。

设计原则:

• DMN 管“业务决策逻辑”。
• OPA / Cedar 管“能不能做”。
• ReBAC 管“这个人和这个资源有什么关系”。
• Workflow 管“谁批准、何时批准、批准什么版本”。
• LLM 管“提取、解释、起草、建议”, 但不单独成为最终 authority。

2.4 Policy Architecture

Policy-as-Code 的核心不是“把所有规则写成代码”, 而是让政策拥有工程化生命周期:

policy authoring
-> review
-> test
-> simulation
-> approval
-> versioned release
-> runtime decision
-> audit
-> monitoring
-> rollback

成熟策略资产应具备:

2.5 PDP / PEP Runtime

PDP 是 Policy Decision Point, 负责做策略判断。PEP 是 Policy Enforcement Point, 负责在系统路径上执行 allow、deny、redact、require_approval、dry_run、route_to_human 等动作。

关键判断:

PDP 没有接入执行路径, 只是咨询。
PEP 没有可靠执行策略, 只是装饰。
PDP + PEP + audit trace 同时存在, 才是可治理的决策自动化。

---

3. Reference Architecture

3.1 AI Decision Automation 架构图

flowchart TB
  User[Customer / Employee / Workflow] --> Channel[Channel or Workbench]
  Channel --> Identity[Identity, Role, Tenant, Purpose]
  Channel --> Orchestrator[AI Orchestrator]
  Orchestrator --> ContextGW[Prompt and Context Gateway]
  ContextGW --> Retrieval[RAG Retrieval with Entitlement Filter]
  Retrieval --> ReBAC[Relationship Graph / ReBAC]
  ContextGW --> Model[Model Gateway]
  Model --> Orchestrator
  Orchestrator --> Intent[Intent, Evidence, Proposed Action]
  Intent --> DecisionSvc[Decision Service: DMN / Rules]
  Intent --> PolicyPDP[Policy Decision Point: OPA / Cedar]
  ReBAC --> PolicyPDP
  DecisionSvc --> PolicyPDP
  PolicyPDP --> PEP[Policy Enforcement Point]
  PEP --> Approval[Human Approval / Dual Control]
  PEP --> ToolGW[Tool Gateway]
  ToolGW --> Core[Core Banking / CRM / KYC / Payments / Credit / Case Systems]
  PEP --> ResponseGuard[Response Boundary and Explanation Service]
  ResponseGuard --> Channel
  PolicyPDP --> Audit[Decision and Policy Audit Log]
  DecisionSvc --> Audit
  Approval --> Audit
  ToolGW --> Audit
  ResponseGuard --> Audit
  Audit --> Eval[Policy Tests / Simulation / Replay]
  Eval --> ReleaseGate[Release Gate and Rollback]

3.2 运行时序列

sequenceDiagram
  participant U as User / Agent User
  participant O as AI Orchestrator
  participant R as Retrieval + ReBAC Filter
  participant M as Model Gateway
  participant D as Decision Service
  participant P as PDP
  participant E as PEP / Tool Gateway
  participant H as Human Approval
  participant A as Audit Log
  participant S as System of Record

  U->>O: request + identity + purpose
  O->>R: retrieve entitled context
  R->>O: evidence with source and permission labels
  O->>M: ask model to extract intent and propose action
  M->>O: intent, evidence summary, proposed decision or tool call
  O->>D: evaluate business decision facts
  D->>P: decision outcome + reason code + policy facts
  O->>P: authorize proposed action with user/resource/context
  P->>E: allow / deny / require_approval / dry_run / redact
  alt approval required
    E->>H: approval packet with policy version and evidence
    H->>A: approve / reject / modify
    H->>E: approval decision
  end
  alt allowed
    E->>S: execute scoped action
    S->>E: result
  else denied
    E->>O: blocked with safe reason
  end
  E->>A: tool/action trace
  P->>A: policy decision trace
  D->>A: decision service trace
  O->>U: response, escalation or explanation

3.3 Product Capability Map

把 policy-as-code 做成平台能力, 而不是每个 AI use case 自建一套。

---

4. AI Guardrails 外置化模式

4.1 从 Prompt Guardrail 到 Externalized Policy

4.2 Recommended Split

---

5. Financial Retail Cases

5.1 信贷资格与 Adverse Action 边界

场景

AI Credit Assistant 帮信贷官整理申请材料、检测政策缺口、解释资格判断、起草客户通知。高风险边界是: AI 不能自由决定批准/拒绝, 不能自由生成 adverse action reasons, 不能把受保护特征或代理变量作为理由。

决策拆分

控制重点

Portfolio Artifact

Credit Decision Boundary Pack
- Decision inventory: credit eligibility, completeness, reason code, notice send
- DMN table: completeness and eligibility pre-check
- Reason code mapping: approved reason -> evidence -> customer wording
- PDP/PEP map: who can view, decide, approve, send
- Simulation: historical applications old vs new policy impact
- Release gate: zero unauthorized final decision, zero unsupported adverse reason
- Audit evidence: application facts, policy version, reason code, approver, notice version

5.2 KYC 文档决策

场景

AI KYC Copilot 读取客户上传文件、OCR 结果、客户资料和 jurisdiction/product policy, 判断文档是否满足身份、地址、收入、企业注册、UBO 或 sanctions screening 前置要求。

决策拆分

DMN 决策片段

控制重点

5.3 支付争议规则

场景

AI Payment Dispute Assistant 帮运营人员解释交易、网络规则、时限、证据和下一步动作。高风险边界是: AI 不能直接决定争议结果、不能未经授权发起退款或 provisional credit, 不能绕过双控。

决策拆分

控制重点

5.4 面向客户 AI 建议边界

场景

客户问 AI: “我应该买这个基金吗?”、“我该不该提前还贷?”、“我这个收入能申请多少额度?”、“帮我选最适合的信用卡”。这些问题既可能是产品信息, 也可能越过个性化金融建议、信贷推荐或 suitability 边界。

决策拆分

Advice Boundary Matrix

5.5 Agent 工具授权

场景

企业 AI Agent 可以查询客户、读取 KYC、创建 case、起草邮件、提交争议、触发退款、冻结账户、外发供应商工单。工具越多, prompt injection、confused deputy、越权、外泄和审批绕过风险越高。

工具风险分层

OPA/Rego 示例

以下示例表达“Agent 可以提出动作, 但工具网关按身份、目的、case、风险、审批和注入信号决策”。生产实现还需要接入 IAM、case system、policy registry、DLP 和 audit。

package ai.agent.authz

import rego.v1

default decision := {
  "effect": "deny",
  "reason": "No matching policy",
  "rule_id": "DEFAULT-DENY"
}

decision := {
  "effect": "allow",
  "reason": "KYC analyst may read an open KYC case for review",
  "rule_id": "KYC-READ-001"
} if {
  input.action == "read_kyc_case"
  input.user.role == "kyc_analyst"
  input.purpose == "kyc_review"
  input.case.status == "open"
  input.user.tenant == input.case.tenant
}

decision := {
  "effect": "require_approval",
  "reason": "Customer-impacting payment action requires supervisor approval",
  "rule_id": "PAY-ACT-004",
  "approval_role": "payments_supervisor"
} if {
  input.action == "issue_provisional_credit"
  input.tool.risk_tier == "T4"
  input.amount_usd > 100
}

decision := {
  "effect": "deny",
  "reason": "Prompt injection risk blocks write actions",
  "rule_id": "AI-INJECT-010"
} if {
  input.action_type == "write"
  input.security.prompt_injection_risk == "high"
}

Cedar 示例

Cedar 的 principal/action/resource/context 模型适合应用内授权和工具授权。

permit(
  principal in Role::"KycAnalyst",
  action == Action::"ViewKycCase",
  resource
)
when {
  resource.tenant == principal.tenant &&
  resource.status == "open" &&
  context.purpose == "kyc_review"
};

permit(
  principal in Role::"PaymentsSupervisor",
  action == Action::"ApproveProvisionalCredit",
  resource
)
when {
  resource.amount_usd <= 500 &&
  context.case_status == "open" &&
  context.dual_control_required == false
};

forbid(
  principal,
  action in [Action::"SendExternalMessage", Action::"IssueRefund"],
  resource
)
when {
  context.prompt_injection_risk == "high" ||
  context.dlp_result == "blocked"
};

Zanzibar / ReBAC 关系授权示例

关系授权解决的是“谁和哪个资源有什么关系”, 例如:

customer:123#relationship_manager@user:alice
account:456#owner@customer:123
case:KYC-789#subject@customer:123
case:KYC-789#viewer@team:kyc-us
team:kyc-us#member@user:bob
document:DOC-222#attached_to@case:KYC-789
tool:read_kyc_case#invoker@team:kyc-us

当 Agent 请求读取 document:DOC-222 时, PDP 不只看 role, 还看:

• 用户是否属于可访问该 case 的 team。
• 文档是否附属于该 case。
• case 是否属于当前 tenant。
• purpose 是否与 case workflow 匹配。
• 工具是否允许该 team 调用。
• 是否存在临时授权、冲突隔离或 legal hold。

---

6. Artifact Pack

6.1 Decision Inventory

6.2 Policy Architecture Template

6.3 PDP / PEP Map

6.4 DMN Decision Table Example

Use case: payment dispute evidence requirement.

Decision service output contract:

{
  "decision_id": "DEC-PAY-DISPUTE-EVIDENCE",
  "policy_version": "payments-dispute-2026.06.2",
  "decision": "require_supervisor_review",
  "reason_code": "DIS-HIGH-AMT",
  "required_evidence": ["case packet", "supervisor review"],
  "explanation": "High amount disputes require supervisor review before provisional credit or customer commitment.",
  "trace_id": "trace-20260629-001"
}

6.5 Policy Test Suite

6.6 Simulation Report

6.7 Release Gate

6.8 Audit Evidence

6.9 Incident Rollback Runbook

---

7. Operating Model

7.1 RACI

7.2 Policy Lifecycle

1. Intake
   Register decision, owner, source policy, risk tier and automation boundary.

2. Author
   Encode policy as DMN table, Rego, Cedar, relationship schema or rules service.

3. Review
   Business validates intent; risk/compliance validates boundary; architect validates enforceability.

4. Test
   Run unit, scenario, edge, conflict, red-team and regression tests.

5. Simulate
   Replay historical cases and synthetic edge cases; quantify decision deltas.

6. Approve
   Bind sign-off to exact policy bundle, test run and simulation report.

7. Release
   Deploy with feature flag, monitoring, audit and rollback path.

8. Monitor
   Track decision volume, deny rate, approval workload, override rate, complaints and incidents.

9. Improve
   Turn incidents, overrides, policy changes and regulator feedback into versioned changes.

7.3 Metrics

---

8. 30-Day Portfolio Lab

选择一个场景: 信贷资格边界、KYC 文档决策、支付争议规则、客户 AI 建议边界或 Agent 工具授权。30 天产出一套可展示 artifact。

Week 1: Decision Discovery and Architecture

Week 2: Policy Modeling

Week 3: Test, Simulation and Release

Week 4: Portfolio Packaging and Interview Story

30 天完成标准

---

9. Interview Answers

Q1: 你如何解释 Policy-as-Code 在 AI 产品里的价值?

30 秒版本:

Policy-as-Code 的价值是把 AI 产品里的授权、审批、业务边界和上线门禁从 prompt 和文档中外置出来, 变成可测试、可版本化、可审计、可回滚的控制面。模型可以提出建议或 tool call, 但 OPA/Cedar/decision service 根据身份、资源、purpose、risk tier、policy version 和审批状态决定 allow、deny、require approval 或 route to human。

2 分钟版本:

我会把 AI 产品分成生成层、决策层、策略层、执行层和审计层。生成层负责理解意图、提取证据、起草说明; 决策层用 DMN 或规则服务处理资格、文件有效性、争议证据、reason code 等业务逻辑; 策略层用 OPA、Cedar 或 ReBAC 处理谁能对什么资源做什么动作; 执行层通过 PEP 放在 tool gateway、API gateway、workflow 和 response renderer 上; 审计层记录 facts、policy version、decision、approver 和 trace。这样做的核心收益是: AI 的高风险边界不依赖 prompt 服从性, 而由外部系统强制执行。

Q2: DMN、OPA、Cedar、Zanzibar 分别适合什么?

DMN 适合业务可读的决策表和决策需求图, 比如 KYC 文件是否有效、争议证据是否完整、某类资格预检查。OPA/Rego 适合通用 policy decision, 比如工具授权、审批条件、release gate 和环境限制。Cedar 适合应用级授权, 用 principal/action/resource/context 表达 permit 和 forbid。Zanzibar/ReBAC 适合复杂关系授权, 比如用户、团队、客户、账户、case、文档之间的 viewer、owner、approver、subject 关系。金融 AI 架构里通常不会四选一, 而是 DMN 管业务决策, OPA/Cedar 管授权策略, ReBAC 提供关系事实。

Q3: 如何把 AI guardrails 从 prompt 外置出来?

我会先识别 prompt 里哪些句子其实是业务政策、权限、合规边界、审批条件或输出约束。然后分别落到外部控制: 业务政策进入 DMN/decision service; 权限进入 OPA/Cedar/ReBAC; 高风险工具进入 tool gateway PEP; 客户建议边界进入 response policy; 审批进入 workflow; 解释进入 reason service; 版本和测试进入 release gate。Prompt 只保留任务说明和输出格式, 不承担授权和合规责任。

Q4: 如何设计 PDP/PEP?

PDP 负责判断, PEP 负责执行。一个常见错误是只做 PDP API, 但业务系统仍然允许绕过。我的设计会把 PEP 放在真正的执行路径上: retriever filter 控制 RAG 文档, tool gateway 控制 Agent 工具, workflow engine 控制状态迁移, response renderer 控制客户输出, CI/CD 控制 policy release。每次 PDP 返回 effect、reason、rule id、policy version 和 trace id, PEP 按 allow、deny、require approval、redact、dry run 或 route_to_human 执行, 同时写入 audit log。

Q5: 如何证明决策自动化可审计?

关键是运行时证据链。每个高风险决策要能复盘: 谁发起、为什么目的、访问了什么资源、输入 facts 是什么、模型输出了什么、哪个 decision table 或 policy bundle 被执行、返回什么 decision 和 reason、谁审批、哪个 PEP 执行或阻断、最终输出给客户什么。审计证据不能只有自然语言解释, 还要有 rule id、policy version、input facts hash、approval packet、tool trace 和 release test run。

Q6: 如何处理 policy versioning 和审批?

我会把 policy bundle 当成可发布 artifact。每次 DMN 表、Rego/Cedar policy、ReBAC schema、reason mapping、approval rule 或 tool permission 变化, 都需要 changelog、owner、test run、simulation report 和 sign-off。高风险 bundle 的审批绑定 exact version 和 test result, 不是泛泛批准。上线后通过 feature flag 或 config registry 控制 rollout, 出问题可以回滚到前一个批准版本。

Q7: 如何做 policy simulation?

Simulation 不是跑几个单元测试, 而是比较新旧 policy 对真实业务的影响。我会用历史案例、合成边界案例和 red-team 样本做 replay, 看 decision change rate、false allow、false deny、manual review volume、approval queue load、客户影响和合规风险。比如支付争议规则更新后, 要知道多少 case 从自动处理变成主管复核, 是否消除了高金额错误通过, 是否造成运营 SLA 压力。

Q8: 在信贷 adverse action 场景, LLM 能做什么、不能做什么?

LLM 可以整理材料、解释政策、起草 memo 和把批准的 reason code 改写成客户可读语言。它不应该自由生成最终拒贷原因, 更不能替代信贷决策。Adverse action reason 应来自可验证的 reason service 或规则映射, 并绑定实际决策因素、policy version、证据和人工审批。客户通知发送前, PEP 检查 reason 是否被批准、是否对应实际 facts、是否完成 required review。

Q9: Agent tool authorization 为什么需要 ReBAC?

RBAC 只能说明某人是什么角色, 但金融场景还需要知道这个人和具体客户、账户、case、文档、团队、租户之间的关系。ReBAC 可以表达“Bob 是 KYC-US team 成员, 该 team 可以查看 case KYC-789, 文档 DOC-222 附属于这个 case, case 属于同一 tenant”。Agent 读取或操作资源时, PDP 同时看 role、relationship、purpose、resource status 和 risk tier, 可以避免普通角色权限过宽。

Q10: 如果策略错误上线导致客户影响, 你如何响应?

先按影响范围启用 kill switch 或回滚 policy bundle, 阻断受影响工具、workflow、tenant 或客户输出路径。然后冻结证据: policy version、decision trace、model/prompt version、approval packet、tool log、客户输出。接着用 incident facts 识别失败控制, 例如 DMN 规则错误、PEP 未接入、approval 条件缺失或 ReBAC 关系错误。修复后必须把事故样本加入 regression suite, replay 历史和合成案例, 由 risk/compliance/business 重新批准后分阶段恢复。

---

10. 常见误区

---

11. 最终记忆句

AI decision automation is not prompt engineering.
It is a governed control architecture:
explicit decisions, externalized policies, enforced PDP/PEP, tested versions, simulated impact, approved releases, auditable traces, and reversible operations.

中文记忆:

AI 决策自动化的关键, 是把“模型说可以”改成“策略证明可以、系统强制执行、证据能够复盘”。