第 15 章 安全与合规：企业 AI 不可回避的问题
前面章节聚焦“如何让 AI 稳定产出”，但企业场景中还有一个前置约束：安全与合规。工作流即使在技术上表现稳定，若其数据处理、上下文来源、记忆、工具/连接器权限、输出或运行方式不符合组织制度、合同或适用要求，也不应进入相应用例范围。
本章提供用于内部控制设计的安全与合规框架，帮助团队在设计最小闭环时同步识别相关问题，而不是在事件发生后才补救。它不替代法律、隐私、信息安全、采购、合同或行业专业意见。
一、数据敏感度分级
在设计任何 AI 工作流之前，先对涉及的数据做敏感度分级。这一步决定了后续所有安全决策的基础。
| 级别 | 定义 | 典型数据 | 能否输入 AI | 处理要求 |
|---|---|---|---|---|
| L1 公开 | 已对外公开，或经确认无保密要求 | 产品手册、公开公告、新闻稿 | 视来源、许可和组织政策而定 | 确认使用范围；需要时保留来源与版本。 |
| L2 内部 | 仅限内部使用，非公开且影响相对有限 | 内部流程文档、团队周报、未发布产品计划 | 经评估后可在批准范围内处理 | 确认用途、访问、留存、工具/端点与数据流。 |
| L3 机密 | 泄露可能造成业务、合同或声誉损害 | 合同条款、定价策略、客户名单 | 需在受控条件下逐案判断 | 最小必要、脱敏/替代、批准环境、权限、留存和风险评估。 |
| L4 高敏感或高度受限 | 泄露可能造成重大法律、商业或个人影响 | 核心源代码、并购计划、未公开财务数据 | 默认不进入未获专门批准的外部处理环境 | 由适用安全、法务、隐私和业务角色决定是否可处理及所需控制。 |
分级操作步骤
- 列出数据清单：列出工作流涉及的每类输入数据
- 逐项标注级别：按组织数据分类制度并由适用的业务、安全、隐私或法务角色确认；无法判断时，暂按较高风险处理并缩小范围。
- 确定处理方式：根据级别决定能否使用、如何脱敏、用什么部署方式
- 记录留档：将分级结果写入工作流文档，作为安全审查依据
关键原则
- 不确定级别时，先按较高风险处理，或暂停该数据进入工作流。
- L3 数据进入 AI 工作流前，应依据具体数据、用途和环境落实最小必要、脱敏/替代、访问与留存控制；脱敏并不自动消除所有风险。
- L4 或同等高度受限数据是否可处理，应由适用角色依据实际环境、合同、权限和控制作出专门决定；“私有化部署”本身不等于自动获批。
- 同一工作流混合不同级别数据时，应以最高风险数据的控制要求为基线，并核验数据之间的关联风险。
二、PII（个人身份信息）处理
PII 常被用作个人信息或可识别信息的简称，但其法律定义和处理要求取决于适用地区、业务关系与数据类型。以下内容用于帮助团队识别常见字段和控制问题，不构成完整的法律分类或处理结论。
需要脱敏的常见 PII 字段
| 字段类型 | 脱敏方法 | 示例 |
|---|---|---|
| 姓名 | 替换为角色/编号 | 张三→用户 A/用户_001 |
| 手机号 | 保留前 3 后 4，中间掩码 | 13812345678→138****5678 |
| 身份证号 | 保留前 6 后 4，中间掩码 | 110101199001011234→110101********1234 |
| 邮箱 | 保留@后域名，前缀掩码 | zhangsan@company.com→z@company.com |
| 地址 | 模糊化到城市/区级 | 北京市朝阳区 XX 路 XX 号→北京市朝阳区 |
| 银行卡号 | 保留后 4 位，其余掩码 | 6222021234567890→ 7890 |
脱敏操作的两条原则
- 在处理链路进入模型或工具前完成保护。 不应仅依赖模型自行判断哪些信息需要保护；具体方法应由数据类型、业务目的和已批准环境决定。
- 区分可逆与不可逆处理。 只有在确有业务必要和适当授权时才保留映射关系；映射表、密钥和重识别能力应按组织分类、访问和留存规则单独保护。
常见误区
- 只脱敏姓名：忽略了手机号、地址、邮箱等同样可识别个人的字段
- 脱敏后不映射：输出中出现了“用户 A”但无法对应回真实用户，导致结果不可用
- 仅在提示词中写脱敏规则：模型可能遗漏或处理不一致。应优先在进入模型或工具前采用经批准的处理和审核机制。
三、模型与工具的数据处理条件
使用外部模型、API、托管平台、文件/状态化功能、第三方工具或连接器时，一个关键问题是：在这个具体版本、端点、项目配置、地区、合同和功能组合下，哪些数据会被传输、留存、用于服务运行或交由第三方处理？ 这类条件不能从模型名、产品版别或“API/私有部署”等标签直接推断。
三类处理安排的判断方式
| 处理安排 | 需要核验的内容 | 控制含义 |
|---|---|---|
| 未核验或条件不清 | 端点、功能、文件/状态数据、日志、训练使用、地区、子处理者和删除条件均未能确认 | 不应承载正式或敏感用例；先建立事实卡并缩小到可控范围。 |
| 有条件的数据控制 | 供应商政策、合同、项目配置或功能资格明确，但仅在特定范围内适用 | 将适用前提写入事实卡、风险初筛、AIA 和工作流合约；不得外推至其他功能或第三方集成。 |
| 组织可控的处理环境 | 组织对部署、存储、访问、日志、备份和删除有更强控制 | 仍需评估供应链、运维权限、模型/工具依赖、日志和人工误用；“自建/私有”不自动等于低风险。 |
检查清单
在正式使用任何模型、工具、端点或集成前，确认以下事项：
- [ ] 已在动态事实卡中记录官方数据处理资料、适用版本/端点/功能、核验日期和限制。
- [ ] 已核验实际项目配置、合同或批准范围，而不只查看公共产品页面。
- [ ] 已识别提示、上下文包、检索结果、工具返回、记忆、响应、文件、状态、日志、缓存、工具调用和第三方集成的相关数据流。
- [ ] 已确认数据留存、训练使用、地区、访问、删除和子处理者条件与组织制度相符。
- [ ] 已与适用的安全、法务、隐私或行业角色确认处理方式；不确定时按更高风险处理。
- [ ] 已记录所使用的模型、端点、工具和配置版本，并在变更时复核。
注意事项
- 个人界面、消费者产品、API、企业项目、托管云、文件功能、浏览器插件、远程工具和第三方集成可能适用不同的数据处理条件，应逐项核验。
- 模型、端点、功能、项目设置或合同变化时，已有数据处理结论可能失效；应更新事实卡并判断是否需要重新做风险初筛、AIA、回归和发布登记。
- 处理条件符合要求并不等于该用例自动获批；仍需满足业务边界、质量、权限、人工控制和回退要求。
四、法规合规要点
不同行业和地区有不同的法规要求，以下是企业 AI 使用中最常涉及的三类：
1. 数据保护法规
| 法规 | 适用范围 | 核心要求 | 对 AI 工作流的影响 |
|---|---|---|---|
| 中国个人信息保护相关要求 | 处理与中国相关的个人信息时可能适用 | 处理目的、合法基础、最小必要、告知、权利响应和安全义务等需结合具体情形判断 | 在设计数据流、留存、授权、跨境、委托处理和权利响应前，应取得适用专业意见。 |
| GDPR 及相关欧洲数据保护要求 | 处理与欧洲经济区相关的个人数据时可能适用 | 合法基础、透明度、数据主体权利、处理者安排、跨境和安全义务等需结合具体情形判断 | 数据生命周期、删除/更正请求、供应商安排和自动化决策影响应进入适用审查。 |
| 行业、合同与组织要求 | 金融、医疗、教育、公共服务或特定客户合同等场景可能适用 | 数据分类、保密、留存、审计、地点、人员资质或审批要求各不相同 | 不应以“行业数据”作统一技术处理结论；应按实际规则、合同和控制环境确定。 |
2. 输出合规
AI 生成的内容可能涉及以下合规风险：
| 风险类型 | 典型场景 | 防范方法 |
|---|---|---|
| 虚假宣传 | AI 生成的营销文案含不实承诺 | 人工审核后发布，禁止直接对外 |
| 版权、商标或其他知识产权问题 | 输出与既有作品、品牌、素材或受限内容存在相似、引用或使用边界问题 | 按组织内容、来源、许可与法务复核流程审查；保留必要的来源、版本和审核记录。 |
| 歧视性或不当差别影响 | 输出用于分类、推荐、筛选或判断时可能产生不公平结果 | 明确用途边界，进行适当的人工审查、样本测试和影响评估。 |
| 不当专业建议 | 输出可能被理解为医疗、法律、财务或其他专业意见 | 不将免责声明作为唯一控制；应限制用途、设置人工专业审核和适当的升级路径。 |
3. 上下文、工具与记忆的安全边界
Agent、检索和连接器会把外部内容带入模型上下文，也可能让模型提出或执行工具动作。企业不应把“来自内部系统”或“由工具返回”自动视为可信指令。文档、网页、邮件、工单、检索片段和工具返回都可能包含与任务无关、误导性或试图改变行为边界的内容；它们应被当作数据处理，而不是比系统规则、审批或状态机更高的指令。
| 风险面 | 典型问题 | 最低控制 |
|---|---|---|
| 不可信上下文与提示注入 | 外部文本诱导模型忽略规则、泄露资料或调用不应使用的工具 | 指令与数据分离；来源白名单；不将检索/工具返回当作可执行指令；异常内容停止或转人工 |
| 过量与越权加载 | 检索或工具返回整库、跨用户或超出任务范围的资料 | 上下文包、字段/返回量限制、过滤、最小权限和审计 |
| 持久记忆 | 将假设、敏感原文或跨用户信息写入长期状态 | 记忆合约、事实/假设标记、隔离、保留期、删除、纠错和回归 |
| 工具/连接器 | 参数越界、写入/外发、凭证滥用、恶意或异常返回影响后续步骤 | 工具控制卡、动作白名单、审批、超时/预算/熔断、沙箱和日志 |
4. 审计与追溯
企业正式使用的 AI 工作流应满足审计要求：
- [ ] 可追溯输入数据、上下文来源、检索/工具返回和记忆的来源、范围与版本
- [ ] 可追溯使用的 Prompt、上下文包、工具/连接器、模型与状态版本
- [ ] 可追溯输出结果、拟执行或已执行动作及是否被采用/批准
- [ ] 可追溯人工检查、接管、停止、回退和纠错记录
- [ ] 输出、审核、版本和相关记录的留存范围与期限已按组织政策、合同和适用要求确定
五、从数据分级到用例风险治理
数据分级回答“数据能否、如何被处理”，但企业还必须回答“该用例会影响谁、是否有写入或对外动作、出错后能否回退、现有控制是否足够”。因此，安全合规不应只在上线前做一次勾选，而应进入用例立项、工作流设计、变更、发布和运行复核的控制链。
1. 用例级风险初筛：先确定控制强度
在填写用例立项卡后，先使用附录 A 第34节完成风险初筛。初筛不以复杂打分代替判断，而是从七个问题判断控制强度：业务影响是否高、是否含敏感或不可信数据、是否面对外部或影响个人权益、上下文来源与记忆是否可控、是否读写系统或调用工具/连接器、是否提高自主性、是否具备可验证的人工接管和回退。
| 初始等级 | 适用方向 | 最低动作 |
|---|---|---|
| R1 基础 | 低影响内部辅助、人工最终采用、无写入/外发 | 明确边界、Owner、质量验证、版本与人工回退。 |
| R2 受控 | 外部草稿、跨系统读取、L2/L3 数据、固定多步骤工作流 | 影响评估、知识版本、Golden Set、回归、发布观察、最小权限和人工审核。 |
| R3 高影响 | 高敏感数据、写入/发送、重要权益或业务影响、复杂 Agent | 适用角色审查、严格权限与审批、异常/接管演练、审计证据与更严格发布门。 |
| R4 暂缓或转专项治理 | 目的、Owner、数据边界、回退或基础控制不清 | 暂停标准路径的设计/发布，先解决阻塞项或走组织专项流程。 |
等级应按最严重的影响因素确定；当数据、影响、权限或恢复能力存在不确定性时，应上调等级或缩小范围。附录 A 第 34 节给出了完整初筛表和风险—控制等级参考。
2. AI 影响评估：说明残余风险为何可接受
R2、R3 用例，以及范围、数据、模型、工具、权限、自主性或业务影响发生重大变化的用例，应使用附录 A 第 35 节完成 AI 影响评估（AIA）。它要求业务、流程、知识和技术责任人共同说明：受影响对象、数据流与知识来源、可能的不利影响、控制 Owner、所需证据、人工接管与恢复方式，以及发布后仍需承担的残余风险。
AIA 的目标不是追求“零风险”。它的目标是避免用“模型表现不错”替代业务判断：组织应清楚哪些风险被减少、哪些风险被保留、谁有权接受这些残余风险，以及何时必须重新评估。
3. 风险—控制—证据必须连在一起
一个控制如果没有 Owner、没有运行证据或无法在异常时被执行，就只是文字承诺。附录A第35节的风险—控制矩阵把数据、上下文/知识/记忆、输出、对外影响、工具/连接器权限、运营韧性和审计记录分别连接到控制和证据；附录A第37节的审计证据索引则让授权人员能够定位立项、评测、发布、例外、运行和回退记录。
建议采用以下最小路径：用例立项卡 → 风险初筛 →（需要时）AIA → 工作流/Agent 合约 + 上下文包/记忆合约/工具控制卡 → Golden Set 与回归 → 发布登记与观察期 → 健康卡与阶段复核。当任一环节发生重大变化或出现事件时，应回到风险初筛或 AIA，而不是仅修改提示词后继续运行。
4. 例外不是绕过治理
确有业务必要但暂时无法满足某项内部控制时，可使用附录 A 第 36 节提出有范围、有补偿控制、有到期日的例外申请。例外不应用于豁免法律、监管、安全基本要求或不可接受风险；无法通过缩小范围、人工审核、权限限制、监控与回退控制的情形，应暂停或转组织专项治理。任何例外都应进入发布登记、健康卡和证据索引，并在到期前关闭、补齐控制、续期或退役。
六、安全合规自检清单
在每个 AI 工作流正式上线前，使用此清单做一次安全合规检查：
数据敏感度分级
- [ ] 已列出相关输入数据并标注敏感度级别（L1–L4）
- [ ] 对 L3 及以上数据已落实与实际环境相称的最小必要、保护、访问、留存和审批控制
- [ ] 分级结果已由适用角色确认；无法确认时已缩小范围、暂停处理或按较高风险处理
用例风险与影响
- [ ] 已完成附录 A 第 34 节的用例风险初筛，并记录控制等级与理由
- [ ] R2/R3 或发生重大变化的用例已完成附录 A 第 35 节的 AI 影响评估
- [ ] 已明确业务影响、人工保留决定、写入/外发边界、停止与回退条件
- [ ] 如有例外，已限定范围、补偿控制和到期日；不以例外替代基础合规要求
PII 处理
- [ ] 已识别输入中相关的个人信息或可识别字段
- [ ] 在进入 AI 或相关工具前，已按批准方案完成最小必要、保护或替代处理
- [ ] 如保留映射表或重识别能力，已按组织规则单独保护
数据留存与 Agent 运行状态
- [ ] 已确认 AI 服务、上下文/检索、工具/连接器和持久记忆的数据留存策略
- [ ] 对 L3 及以上数据，留存、删除、访问、地点和处理环境已按批准条件配置并记录
- [ ] 模型版本、服务配置、上下文包、记忆和工具/连接器版本已记录
上下文、工具与行动边界
- [ ] 已定义允许来源、排除来源、来源优先级、返回量和信息不足/冲突时的停止或转人工条件
- [ ] 已对不可信文档、网页、邮件、检索片段和工具返回设置数据处理边界，不将其自动视为可执行指令
- [ ] 工具/MCP/连接器的动作、参数、读写范围、审批、超时、熔断、日志和退出方式已按风险确认
- [ ] 持久记忆（如使用）的写入、隔离、失效、删除与人工纠错方式已确认
输出合规
- [ ] 输出经人工审核后发布（不直接对外）
- [ ] 涉及专业领域（如医疗、法律、金融）的输出已按适用范围设置限制、审核与升级路径
- [ ] 输出留存策略已确定
审计追溯
- [ ] Prompt、上下文包、输入数据、来源/检索/工具返回和记忆版本可追溯
- [ ] 输出结果、拟执行/已执行动作及人工检查/审批记录可追溯
- [ ] 回归报告、发布登记、审批/例外、异常与回退记录可定位
- [ ] 已更新附录 A 第 37 节的审计证据索引，并按组织政策设置留存期限七、本章使用建议
- 在设计最小闭环时就识别数据、权限和输出边界，避免在后期返工或扩大后才发现基础限制。
- 不用“合规”作为笼统的停止或推进理由：先明确实际处理的数据、目的、环境、合同和控制条件，再决定是否继续、缩小或转专项审查。
- 与安全、隐私、法务和业务角色共同设计控制：尽早提供数据分级、数据流、脱敏/替代方案和用例边界，便于形成可执行结论。
- 定期复查：模型版本、法规、合同、工具配置或业务范围变化时，都应判断是否需要重新检查安全与合规条件。