AI Safety Engineering / STPA：控制结构
STPA 用于 AI 安全时, 关注点不是“模型是否足够准”, 而是整个业务控制结构是否会在目标、权限、反馈、时序和人机分工失配时产生不可接受损失。对 agentic AI 来说, 真正危险的不是一次回答错误, 而是错误回答被放进工作流后触发工具调用、客户状态变更、人工误信、审计缺口和事故延迟发现。
AI Safety Engineering / STPA / Control Structure 解读
Source Anchors
| Source | Link | 用途 |
|---|---|---|
| STPA Handbook | https://psas.scripts.mit.edu/home/get_file.php?name=STPA_handbook.pdf | 参考 loss、hazard、unsafe control action、control structure、causal scenario、constraint 的系统安全分析 |
| NIST AI Risk Management Framework | https://www.nist.gov/itl/ai-risk-management-framework | 将 AI safety 分析连接到 Govern / Map / Measure / Manage |
| NIST GenAI Profile | https://www.nist.gov/itl/ai-risk-management-framework/generative-artificial-intelligence-profile | 参考生成式 AI 特有风险, 如 confabulation、prompt injection、information integrity、overreliance |
| OWASP Top 10 for LLM Applications | https://owasp.org/www-project-top-10-for-large-language-model-applications/ | 参考 prompt injection、sensitive information disclosure、excessive agency 等 LLM 应用安全风险 |
核心导读
STPA 用于 AI 安全时, 关注点不是“模型是否足够准”, 而是整个业务控制结构是否会在目标、权限、反馈、时序和人机分工失配时产生不可接受损失。对 agentic AI 来说, 真正危险的不是一次回答错误, 而是错误回答被放进工作流后触发工具调用、客户状态变更、人工误信、审计缺口和事故延迟发现。
这篇的核心判断是: AI 安全工程要把模型评测、权限控制、人工复核、运行监控和风险接受统一到一张控制结构图里。只有这样, 才能判断哪些动作允许自动化, 哪些动作只能辅助, 哪些动作需要升级、熔断或回滚。
问题定义
当 AI 从内容生成进入“读取、判断、调用、写入、协调”阶段, 风险形态发生变化:
| 能力阶段 | 主要风险 | 系统性问题 |
|---|---|---|
| Draft | 错误内容、幻觉、语气不当 | 输出质量问题仍可由人工吸收 |
| Recommend | 错误建议、证据缺失、过度信任 | 人类把 AI 摘要当成完整事实 |
| Decide | 决策边界不清、理由不一致、偏差 | 客户权益受到影响, 但责任链不清 |
| Act | 工具误调用、权限过大、重复执行 | 资金、账户、案件状态被真实改变 |
| Coordinate | 多 agent 目标冲突、反馈丢失 | 一个局部最优动作破坏端到端控制 |
传统 checklist 容易漏掉这些问题, 因为 checklist 往往假设“组件失败导致事故”。STPA 的假设更适合复杂 AI 系统: 即使组件都按设计运行, 不安全控制动作仍可能因为上下文、时机、反馈和目标模型错误而发生。
核心原理/方法
STPA 在 AI 系统中的概念映射如下:
| STPA 概念 | AI 系统解释 |
|---|---|
| Loss | 组织不可接受的损失: 客户伤害、资金损失、合规违规、隐私泄露、运营中断、声誉损害 |
| Hazard | 在某种系统状态下会导致 loss 的危险条件 |
| Safety Constraint | 系统必须满足的约束, 用来防止 hazard |
| Control Structure | 控制者、被控过程、控制动作、反馈和 controller 的 process model |
| Unsafe Control Action | 控制动作在错误上下文、错误时机、缺失或持续过久时导致 hazard |
| Causal Scenario | 解释 unsafe control action 为什么会发生的因果路径 |
| Process Model | 控制者对系统状态的内部理解, 在 AI 中包括用户意图、权限、证据、政策版本、工具结果和风险状态 |
分析顺序不应从模型开始, 而应从业务损失开始:
- 定义不可接受损失。
- 找出会导致损失的危险系统状态。
- 建模控制结构, 明确控制动作和反馈。
- 对关键动作识别 unsafe control actions。
- 推导 safety constraints。
- 分析 causal scenarios。
- 把约束落到产品、架构、运行控制和证据链。
这个顺序能避免把安全问题缩小成“加一个 guardrail”或“提高准确率”。
系统/架构模型
金融零售 AI agent 的控制结构可以抽象为:
Enterprise Risk Appetite / Regulation
-> Product Policy and Operating Procedure
-> AI Orchestrator / Agent Runtime
-> Model Gateway
-> Retrieval / Knowledge Service
-> Tool Gateway
-> Core Banking API
-> CRM
-> Case Management
-> Payment / Refund Service
-> Policy Engine
-> Audit and Evidence Store
-> Human Reviewer / Operator
-> Monitoring / Incident Response
-> Customer / Analyst / Advisor
关键反馈不能只包括模型输出, 还必须包括:
- 工具执行结果和副作用。
- 客户身份、账户、交易和案件状态。
- 风险分层、授权额度和例外标记。
- 政策版本、知识源版本和引用片段。
- 人工复核、拒绝、覆盖和原因。
- 投诉、申诉、损失事件和事故信号。
- 线上质量、漂移、异常分布和成本。
如果反馈不足, AI 和人类都会基于错误 process model 做控制动作。很多 AI 事故不是“没有规则”, 而是控制者没有看见足够状态, 或者看见的是过期、片面、被总结过度的信息。
关键机制与取舍
以退款 agent 的 Issue Refund 动作为例, STPA 会问四类问题:
| UCA 类型 | 退款场景 | 风险 |
|---|---|---|
| 未提供必要控制 | 合法退款未发起或未升级 | 客户权益受损、投诉、SLA 违约 |
| 提供了不该提供的控制 | 身份未确认、交易未结算、疑似欺诈时退款 | 资金损失、欺诈扩大 |
| 时机错误 | 证据收集前退款, 或超过承诺时限才升级 | 错误补偿或客户信任受损 |
| 持续时间错误 | 部分流程中断, 或重复执行退款 | 账务不一致、重复补偿 |
由此推导约束:
| Safety Constraint | 架构落点 |
|---|---|
| 身份、交易状态、退款资格缺一不可时不得执行 | tool gateway 前置 context validation |
| 超额、监管投诉、欺诈疑似、VIP 例外必须人工复核 | workflow queue + policy engine |
| 退款动作必须绑定 evidence bundle 和 policy citation | evidence store + immutable log |
| 建议与执行动作必须隔离 | UI state、API scope、separate permissions |
| 执行动作必须可审计、可补偿或可回滚 | idempotency key、compensation workflow |
真实取舍在于:
- 自动化越深, 对 policy engine、tool gateway、审计和补偿流程要求越高。
- 人工复核不是免费控制, 会引入队列、延迟、疲劳和过度依赖。
- 只限制工具权限不够, 因为同一工具在不同上下文下可能安全也可能危险。
- 只做离线评测不够, 因为线上输入分布、政策版本和操作人员行为会变化。
证据与控制
AI safety control 应覆盖设计时、上线时和运行时:
| 控制 | 目的 | 证据 |
|---|---|---|
| Loss / hazard register | 对齐不可接受损失和危险状态 | 风险登记、决策记录 |
| Control structure review | 确认控制者、动作、反馈和责任链 | 控制结构图、RACI、接口说明 |
| Unsafe control action matrix | 系统化识别关键动作的危险方式 | UCA 表、safety constraint set |
| Tool allowlist and scopes | 限定 agent 可调用能力和副作用范围 | tool policy、权限配置、审批记录 |
| Runtime policy engine | 在 tool call 前做上下文校验 | policy decision log |
| Evidence bundle | 让建议和动作可追溯 | 输入、检索片段、模型版本、政策版本 |
| HITL gate | 高风险动作由具备资格的人确认 | review record、override reason |
| Circuit breaker | 异常分布、投诉或 KRI 触发暂停 | alert、incident ticket、stop decision |
| Safety eval and red-team | 上线前验证约束和失败模式 | eval report、failure taxonomy |
成熟做法不是把这些控制堆在流程末端, 而是把约束嵌入系统执行路径。控制只有在运行时能阻止、降级、升级或留证, 才能称为安全工程。
AI产品/金融零售场景
AML investigation copilot
核心风险不是摘要不流畅, 而是 analyst 被摘要诱导过早关闭 alert。系统约束应包括: AI 只能生成证据导向的 draft rationale, 关闭建议必须显示支持证据、反证和 missing evidence, 高风险 typology 必须二线复核。监控要看 missed escalation proxy、QA fail rate 和 analyst overreliance signal。
信贷运营助手
风险不是“解释不够详细”, 而是 adverse action reason 与真实决策逻辑不一致, 或边界客户在缺失数据下被错误拒绝。约束应包括: 数据缺失时不得给出确定性拒绝建议, 禁止变量和代理变量检查, 边界 case 升级人工, reason code 与 DMN/模型输入保持 traceability。
客服退款 agent
可自动化的不是“退款判断”这个整体, 而是低金额、低争议、身份和交易状态明确、政策规则清楚且可补偿的子场景。高金额、欺诈疑似、监管投诉、重复退款和弱势客户场景必须转人工或降级为建议模式。
反模式
| 反模式 | 表现 | 后果 |
|---|---|---|
| Accuracy-only safety | 用模型准确率替代系统安全分析 | 忽略权限、时序、反馈和人工误信 |
| Permission-only control | 只问 agent 能不能调用工具 | 无法处理错误上下文下的合法工具调用 |
| HITL theater | 写了人工复核, 但没有证据、SLA、容量和 override 记录 | 人工成为背锅点, 不是控制点 |
| Guardrail at text layer | 只检查文本输出, 不检查 tool call 和副作用 | 执行动作绕过安全约束 |
| No feedback loop | 上线后只看成功率和使用量 | 漂移、投诉、异常分布发现太晚 |
| Risk acceptance without expiry | 例外长期存在 | 临时风险变成永久架构 |
最终心智模型
AI safety engineering 的核心不是让模型“更听话”, 而是让 AI 工作系统在任何关键动作前都能回答五个问题:
这个动作在当前状态下是否允许?
证据是否足够且可追溯?
谁对 residual risk 负责?
失败时如何发现、停止、补偿或升级?
这次动作会留下什么证据供审计和学习?
STPA 的价值是把这些问题从事后审查提前到系统设计。对金融零售 AI 来说, 安全不是一个附加控件, 而是由控制结构、反馈路径、权限边界、人工协作、运行监控和风险接受共同组成的产品与架构能力。
SOTA 状态标注 (2026-07-01)
本篇属于第二、三遍深读池（参考架构/深读笔记），未列入 12 周主线必读。时效基线为写作时点；引用前请按 CLAUDE.md 全局时效性硬规则复查最新进展。模块级 SOTA 对照见 docs/AI_SYSTEMATIC_LEARNING_ROADMAP_2026.md 各周「2026 SOTA 对照」行与文末「SOTA 检查」。