AI Shadow AI：公民开发治理架构
Shadow AI governance architecture 是把“员工绕开正式路径使用 AI”转成可发现、可分级、可引导、可治理、可迁移和可审计的 enterprise control system。
AI Shadow AI / Citizen Development Governance Architecture 解读
配对阅读：本篇的操作手册版（模板/RACI/门禁/runbook）是
docs/AI_SHADOW_AI_CITIZEN_DEVELOPMENT_GOVERNANCE_PLAYBOOK.md。第一遍读本篇建立原理与架构判断；第二遍做案例时再用 playbook 查表落地，两者不需要重复精读。
Source Anchors
| Source | Link | 用途 |
|---|---|---|
| NIST AI RMF | https://www.nist.gov/itl/ai-risk-management-framework | 用 Govern / Map / Measure / Manage 组织 shadow AI 风险识别、测量、管理和治理反馈 |
| ISO/IEC 42001 | https://www.iso.org/standard/42001 | 用 AI management system 语言设计职责、运行控制、绩效评价、改进和管理评审 |
| FFIEC IT Examination Handbook Management booklet | https://ithandbook.ffiec.gov/it-booklets/management.aspx | 用金融机构 IT governance、risk management、board reporting、third-party 和 audit 视角组织治理证据 |
| OWASP Top 10 for LLM Applications | https://genai.owasp.org/llm-top-10/ | 用 LLM 风险分类识别 prompt injection、sensitive information disclosure、excessive agency、supply chain 等风险 |
| CISA Secure by Design | https://www.cisa.gov/securebydesign | 用 secure-by-default、secure-by-design 和减少下游用户安全负担的思想设计 sanctioned AI pathways |
核心导读： Shadow AI governance architecture 是把“员工绕开正式路径使用 AI”转成可发现、可分级、可引导、可治理、可迁移和可审计的 enterprise control system。
核心导读
Shadow AI 不是单纯违规行为，也是未被正式平台满足的业务需求信号。金融零售组织如果只靠禁令，会把使用行为推向个人账号、外部插件、无日志工具和不可控数据路径；如果完全放任，则会引入数据泄露、错误客户承诺、记录缺失、供应商风险和模型风险。成熟治理要把 shadow AI 发现、风险分级、批准路径、citizen development guardrails、DLP、运行监控、例外管理和 golden path migration 连接起来。
核心目标不是消灭所有自助创新，而是让员工有安全、快速、可审计的 AI 路径，同时让高风险用途进入正式控制面。
问题定义
Shadow AI 的典型来源：
- 客服主管用外部聊天工具总结投诉文本和客户情绪。
- 分行业务人员批量生成客户沟通草稿。
- 风控分析师用个人账号辅助撰写 suspicious activity narrative。
- 营销团队使用外部插件生成 campaign copy 和分群思路。
- 开发人员接入未批准代码助手、agent runner 或 no-code automation。
- 运营团队用 spreadsheet + LLM 处理争议、退款或库存异常。
这些行为背后通常是正式平台慢、审批路径不清、可用模板不足、工具体验差或业务 deadline 紧。但风险也很具体：
| 风险 | 表现 |
|---|---|
| Data leakage | PII、账户、交易、投诉、信用、商户、员工和合同数据外流 |
| Conduct risk | 对客户做出未经批准的承诺、建议、解释或销售话术 |
| Records risk | AI 生成内容进入业务流程但无记录、无保留、无法 eDiscovery |
| Third-party risk | 未审查供应商、个人账号、训练条款、插件和跨境处理 |
| Model risk | 输出被当成评分、分析或决策支持，但无验证和监控 |
| Security risk | prompt injection、tool abuse、excessive agency、凭证泄露 |
| Audit risk | 无 inventory、owner、approval、usage log、exception 和 evidence |
核心原理/方法
Shadow AI 治理要采用“discover -> classify -> channel -> control -> migrate”的方法：
| 阶段 | 目标 |
|---|---|
| Discover | 发现未批准 AI 工具、插件、API、浏览器扩展、数据上传和自动化脚本 |
| Classify | 按数据敏感度、客户影响、业务动作、供应商、区域和自动化程度分级 |
| Channel | 提供 sanctioned AI pathway，如企业聊天、内部 RAG、approved prompt library、no-code sandbox |
| Control | 对高风险用途执行审批、DLP、policy gate、记录、监控和人审 |
| Migrate | 将有价值的自发用例迁移到正式平台、产品 backlog 或受控 citizen dev 模式 |
风险分级应关注 use case，而不只是工具名称。同一个通用聊天工具，用于改写内部会议纪要可能低风险，用于生成客户投资建议就是高风险。
Citizen development 需要 guardrails：
| Guardrail | 内容 |
|---|---|
| Approved data zones | 哪些数据可用于自助 AI，哪些必须脱敏或禁止 |
| Approved connectors | 允许接入的系统、工具、MCP server、插件和 API |
| Prompt / workflow templates | 已审查模板、禁止指令、输出约束和 disclosure |
| Runtime logging | prompt、data category、output、tool action、owner、purpose 和版本 |
| Review gates | 客户可见、高影响、数据导出、自动执行、外部共享前的审批 |
| Promotion path | 从个人实验到团队工具、部门应用、企业平台的迁移标准 |
系统/架构模型
Discovery Signals
-> Shadow AI Inventory
-> Use Case Risk Classifier
-> Approved AI Marketplace / Golden Path
-> Citizen Development Sandbox
-> DLP & Data Policy Gateway
-> Review / Approval Gates
-> Runtime Monitoring & Evidence
-> Exception / Remediation Workflow
-> Migration to Managed Platform
关键组件：
| 组件 | 职责 |
|---|---|
| Discovery layer | 从 CASB、DLP、proxy、endpoint、SSO、expense、code repo 和 survey 捕获 AI 使用信号 |
| Shadow inventory | 记录工具、owner、数据类别、业务用途、用户群、供应商、region 和风险 tier |
| Risk classifier | 依据数据敏感度、客户影响、自动化动作、监管记录和供应商状态分级 |
| Approved marketplace | 提供已审查模型、模板、RAG、工具、数据连接器和示例 workflow |
| Citizen sandbox | 限制数据、权限、执行环境、外部共享和自动化动作 |
| Policy gateway | 执行 DLP、purpose、residency、tool permission、recording 和 output rules |
| Review gates | 对客户可见、高影响、外部发送和系统写入进行审批 |
| Evidence layer | 保存使用、审批、输出、数据类别、异常和迁移记录 |
| Migration workflow | 将重复高价值用例转为正式产品能力或平台组件 |
架构要把“禁止清单”变成“批准路径”。没有可用路径，shadow AI 会持续再生。
关键机制与取舍
| 机制 | 取舍 |
|---|---|
| 阻断 vs 引导 | 纯阻断降低短期风险但会压制需求信号；引导需要平台投入和清晰边界 |
| 中央审批 vs 自助 guardrails | 中央审批适合高风险；低风险场景应通过预批准模板和数据区提高速度 |
| 工具治理 vs 用例治理 | 工具清单必要但不足；同一工具在不同数据和业务动作下风险不同 |
| 发现透明度 vs 员工信任 | 监控要明确范围和目的，避免把治理设计成暗中惩罚 |
| Citizen development vs 工程化平台 | 自助工具适合探索和轻量流程；客户影响、系统写入和规模化必须迁移 |
| 数据可用性 vs DLP 严格性 | 过严会导致绕行；过松会泄露敏感信息。需要 approved data zones 和脱敏服务 |
Shadow AI 的治理成败取决于速度。正式路径如果比个人账号慢十倍，组织实际选择会偏向绕行。
证据与控制
治理证据要证明组织知道 shadow AI 在哪里、风险多大、如何处置：
| 证据对象 | 关键字段 |
|---|---|
| Discovery signal | 工具、用户群、流量、数据类别、上传类型、时间、来源 |
| Use case record | owner、purpose、业务流程、客户影响、数据 sensitivity、supplier、region |
| Risk tier decision | 分类规则、decision、required controls、approval path、review date |
| Approved pathway event | 使用的企业工具、模板、数据区、connector、policy decision |
| DLP / policy event | 拦截、脱敏、允许、拒绝、reason、evidence |
| Review gate record | 审批人、输出、数据类别、客户可见性、系统写入、批准条件 |
| Migration record | 从 shadow use case 到正式平台能力的 backlog、上线、owner 和关闭 |
关键指标包括：unknown AI tool usage、sensitive upload attempts、migration conversion、approved pathway adoption、repeat policy violation、unreviewed customer-facing output、citizen app aging、high-risk use case without owner。
金融零售/AI产品场景
投诉总结：员工把客户投诉复制到外部工具。正式路径应提供内部 complaint summarizer，自动脱敏、保留记录、引用原文片段，并禁止生成客户承诺。
分行客户沟通草稿：业务希望快速生成邮件。可提供 approved template + claim scanner + preference check + approval gate，避免个人工具产生不合规销售话术。
AML narrative 辅助：分析师使用未批准 LLM 撰写 narrative 风险极高。应提供受控工作台，允许总结证据但保留原始交易、typology、reviewer decision 和报送记录。
营销活动创意：外部插件可用于低风险创意发散，但涉及客户分群、优惠、费用、资格和发送前，必须进入 conduct、consent 和 records control。
反模式
- 发布全面禁令，但没有企业可用替代路径。
- 只登记工具名称，不记录 use case、数据类别和客户影响。
- 把 citizen development 当作“业务自己负责”，缺少平台 guardrails 和证据。
- 批准外部 AI 工具后不控制插件、训练条款、跨境处理和输出用途。
- 只监控输入泄露，不监控 AI 生成内容是否进入客户沟通或业务记录。
- 高价值 shadow use case 被反复豁免，没有迁移到正式平台。
- 治理以惩罚为主，导致员工隐藏使用行为。
最终心智模型
Shadow AI 是企业 AI 需求和治理缺口的暴露层。成熟组织不会只问“如何禁止员工使用外部 AI”，而会问“为什么正式平台没有满足这个需求，如何把需求引导到更安全、更快、更可审计的路径”。
最终目标是让创新走在可控道路上：低风险自助，高风险受控，重复需求产品化，越界行为可发现，客户影响可追踪，证据可复盘。
SOTA 状态标注 (2026-07-01)
本篇属于第二、三遍深读池（参考架构/深读笔记），未列入 12 周主线必读。时效基线为写作时点；引用前请按 CLAUDE.md 全局时效性硬规则复查最新进展。模块级 SOTA 对照见 docs/AI_SYSTEMATIC_LEARNING_ROADMAP_2026.md 各周「2026 SOTA 对照」行与文末「SOTA 检查」。