第六章 数据安全质询
6.1 数据边界与数据流向
承前：第 4 章 demo 内循环里，我们用"AI 模拟客户走查"提前暴露了坏案例，第 5 章的 PoC 汇报刚刚结束，青禾优选的增长副总裁对 demo 效果很满意，项目眼看要进入正式交付。但就在这时候，一位平日不怎么露面的人物登场了——IT 负责人带着信息安全部门的人找到你，说："演示我们看了，效果不错。但你们要先回答三个问题，否则这个项目今天就得停。"这一章，我们就来面对 AI 项目里最容易被技术团队轻视、却最能一票否决项目的问题：数据安全。会员数据凭什么给大模型？这是每一个 FDE 在 To B 项目里迟早要回答的问题。
6.1.1 为什么数据边界问题能"一票否决"项目
在讲技术方案之前，先理解一件事：在很多企业里，数据安全不是一个"技术问题"，而是一个"生存问题"。
一家连锁零售企业掌握着什么？几十万会员的手机号、住址、消费记录、家庭结构，甚至支付信息。这些数据一旦泄露，后果是三重的：监管处罚（个人信息保护法的罚款上限可达上一年度营业额的百分之五）、客户信任崩塌（会员制超市的命根子就是信任）、以及高管个人责任。所以信息安全部门的人看你的 AI 项目，视角和业务部门完全不同——业务方看到的是"复购率提升的想象空间"，安全部门看到的是"一条把会员数据送出公司边界的新管道"。
打个比方：业务团队想给房子开一扇新的落地窗，采光更好；安全团队是消防验收员，他不管窗子多漂亮，只问两个问题——"这扇窗能不能被撬开？""窗外的风景里有没有人能看到你家的保险柜？"
数据边界（Data Boundary）就是先回答第二个问题：在把任何数据交给大模型之前，先划清楚一条线——哪些数据允许离开客户环境，哪些必须留在客户环境里，哪些根本不该进入这条链路。
判断这条线画在哪，依据三个东西：
- 法规：法律怎么规定的。比如个人信息出境要满足的条件、金融医疗行业的特殊规定。
- 合同：客户和它的客户、供应商签的合同怎么约定的。很多零售企业的会员协议里有"数据不出境、不转让给第三方"的条款——你的 Agent 服务商身份，可能就落在"第三方"的定义里。
- 客户安全策略：企业内部的规章制度。很多公司有内部红线，比如"会员手机号和消费明细严禁进入任何外部系统"，这甚至比法规更严格。法规是底线，企业策略是自我加压的更高标准。
这三层依据，一层比一层可能更紧。FDE 的基本功是：别拿"我们合规"当挡箭牌——法规只是三层里最宽松的那一层。
6.1.2 模型调用链：数据到底流向了哪里
要回答"数据有没有离开客户环境"，得先把调用链画出来。很多争议的根源在于：业务方以为"我们只是调了个 API"，而安全部门看到的是数据穿过了一连串系统。
一个典型的 Agent 调用链是这样的：
模型调用链与数据流向
┌──────────┐ ①请求 ┌──────────┐ ②转发 ┌──────────────┐
│ 客户端 │ ─────────→ │ 网关/ │ ───────→ │ 模型服务 │
│ (运营后台 │ │ Agent底座 │ │ (云端API或 │
│ /门店App)│ ←───────── │ (会话/工具/ │ ←─────── │ 私有化集群) │
└──────────┘ ⑥响应 │ 日志/trace)│ ⑤生成 └──────┬───────┘
└─────┬────┘ 结果 ③上游依赖
│ │
④工具执行 ┌─────▼────────┐
│ │ 第三方API/ │
┌───────▼───────┐ │ 模型上游 │
│ 客户内部系统 │ │ (可能跨国) │
│ (CRM/ERP/数仓) │ └──────────────┘
└───────────────┘逐段看一遍数据去了哪：
① 客户端 → 网关。 运营在后台输入的查询、门店店长上传的表格，先进入 Agent 底座的网关。这一段通常还在客户环境内（如果底座部署在客户侧）或者已经出去了（如果底座是 SaaS）。这是第一个要澄清的点：Agent 底座本身部署在哪，决定了边界的第一道关卡在哪。
② 网关 → 模型服务。 组装好的 prompt 发给模型。如果调的是云端 API，会员数据（哪怕只是会员昵称和消费摘要）就从这里物理上离开了客户机房，落在模型服务商的服务器上——服务器在哪国、日志保留多久、会不会被用于训练，都是安全部门要逐条核对的。
③ 模型服务的上游。 一些云端模型服务还有自己的依赖——安全审查模块、区域路由。数据可能在你不知情的情况下跨了国境。对于数据出境有严格要求的企业，这一段是最隐蔽的风险。
④ 工具执行。 Agent 调用工具去查 CRM、ERP——注意，这一段不是"数据离开"，而是数据在客户内部系统间流动。但安全部门同样关心：Agent 的工具权限有多大？它能不能拿着查询会员详情的权限去查别人的数据？
⑤⑥ 返回。 模型生成的响应里可能包含从客户数据中提取的内容，回流给终端用户。反向通道同样要管：响应里如果带出了不该带出的字段（比如完整手机号），前向脱敏就白做了。
把这张图画出来，和安全部门逐段过一遍，"数据到底流向了哪里"这个模糊的问题就变成了一组可以逐项处理的检查清单。
6.1.3 沙盘：IT 负责人的合规三连问
回到本章开头的场景。会议室里坐着信息安全部的负责人和 IT 负责人。他们的三个问题，几乎是所有 To B AI 项目都会遇到的标配，我们逐个拆解怎么接。
第一问："你们把我们的数据发到哪个国家去了？"
这是问数据出境。不能含糊地答"云端处理"，要答到具体：调用的哪个模型服务、服务商数据中心在哪个区域、是否支持指定区域部署。如果调用境外 API，就涉及出境评估问题——处理一百万人以上个人信息的数据处理者向境外提供个人信息，按规定要申报数据出境安全评估（具体规则我们会在 6.5 节展开）。即便数据量不到门槛，把会员数据送出国境在沟通上的成本也极高。务实的第一反应通常是：能不能切换到境内模型服务或私有化部署，把这一问从根上消掉。
第二问："模型厂商会不会拿我们的数据训练模型？"
这是问数据用途。要拿事实回答：主流厂商的 API 条款（如 OpenAI 官方声明 API 输入输出默认不用于模型训练，Anthropic 同样默认不用 API 数据训练），以及保留期政策（如 API 输入输出通常保留约 30 天用于滥用监测，需更强保证时企业级客户可申请零数据保留安排）。关键是别口头承诺——把厂商条款原文和双方合同里的数据处理协议（DPA）拿给法务看。你的承诺不值钱，白纸黑字的条款才值钱。
第三问："出了数据泄露，责任怎么算？"
这是问责任划分。安全部门真正想听的是：泄露场景下谁取证、谁担责、有没有保险。答案在合同里——SOW 和数据处理协议要写清数据安全事件的响应时限、通知义务、违约责任。FDE 在这里的角色是推动双方法务提前谈，而不是在事故发生后现场扯皮。
三连问拆完，你会发现：这三个问题分别在问流向、用途、责任——正好对应上面调用链图里的三段。这就是为什么我们坚持先把数据流向图画出来：图在，问题就落在具体段落上；图不在，讨论就永远悬浮在"你们到底安不安全"的情绪层面。
6.1.4 沙盘后续：项目差点被叫停，怎么救回来的
三连问只是开始。信息安全部门随后提交了一份意见："在数据流向和脱敏方案未经评审前，建议暂停该项目。" 项目第一次面临被叫停。
这时候最容易犯的错有两种：一是技术团队觉得安全部门"不懂 AI、故意刁难"，走对抗路线——在 To B 环境里，跟安全部门对抗的项目几乎必死；二是无原则退让，"你们说什么我们都改"——这会把交付节奏拖垮，还会在客户内部留下"FDE 不专业"的印象。
我们的做法是第三条路：把安全问题工程化。一周内提交了三份材料：
- 数据流向图 + 分级标注：把调用链图上每一段标注数据等级（会员手机号 = 高敏，会员等级 = 低敏），让安全部门一眼看到高危数据出现在哪几段。
- 数据分级清单：从客户数据字典出发，列出 Agent 链路涉及的每个字段，标注"可用/脱敏后可用/禁用"三级，并给出禁用字段的替代方案（比如用会员 ID 哈希替代手机号做个体识别）。
- 控制措施映射：每个高风险点对应一个具体控制——脱敏（6.2 节）、字段级权限（6.3 节）、效果验证（6.4 节）。
评审会上，安全负责人翻完清单说了一句："这是我们见过的第一个把数据问题拆到字段级的 AI 项目。"叫停撤销，改为"方案评审通过后进入受控试点"。项目保住了，而且多了一层保护：后续任何人想给 Agent 加新数据源，都要走这张清单——安全不是交付的对立面，把它做成流程，反而成了项目的护栏。
这个沙盘给我们的通用启示：安全质询的本质不是"信任测试"，而是"工程问题求解"。客户不要你的保证，要的是可核验的证据链。
6.1.5 画好你的数据流向图：一个可复用的检查框架
把沙盘经验抽象成通用方法。画数据流向图时，建议每段回答四个问题，形成"流向四问"：
| 检查项 | 要回答什么 | 常见证据 |
|---|---|---|
| 数据在哪 | 这段链路数据物理/逻辑上经过哪些系统 | 架构图、部署说明 |
| 是什么数据 | 经过字段级分级后的敏感等级 | 数据分级清单 |
| 谁能碰 | 该段上谁能访问、权限多大 | 权限矩阵、厂商条款 |
| 出事怎么办 | 泄露时如何发现、止损、追责 | 审计日志、DPA 条款 |
常见误区一：只画正向流，不画反向流。 响应回流带出敏感信息是真实风险——模型把查询结果里的手机号原文复述出来了，等于前向脱敏全部失效。流向图必须画双向。
常见误区二：只考虑静态架构，不考虑日志链路。 Agent 底座会记录会话日志和 trace——如果日志里原样存了会员手机号，那么"数据没发给模型"的安全声明就名不副实。日志链路是数据流向图上最容易被漏画的一条支线，也是很多真实泄露事件的源头。
常见误区三：把"厂商说不训练"当成"数据没离开"。 数据用途和数据流向是两个独立维度：不训练 ≠ 不保留，不保留 ≠ 不出境。三者要分别核实，分别落到证据上。
6.1.5b 边界判定的实操顺序：一次把三层依据走完
四个误区讲完，再补一个正向的操作序列——进场后第一次做数据边界判定时，按什么顺序走三层依据（法规/合同/客户策略）？顺序错了会白做很多功。
先要合同和内部策略，再查法规。 很多工程师的直觉是先查法律条文，但法规是三层里最宽松的底线——花一周研究出境评估细则，最后发现客户合同里一句"会员数据不得传输至任何第三方系统"就把问题判死了，这一周就白费了。正确顺序是反过来：先向客户要两类文件——与会员签的用户协议（数据授权范围）、与上下游供应商的合同（数据共享约束），再要信息安全部门的内部红线清单。这三份文件通常半天能拿齐，且直接给出最紧的约束。
法规检索只补空白。 客户文件管不到的地方才需要查法规：比如"脱敏后的哈希 ID 还算不算个人信息"这类边角问题。查的时候认官方源（网信办、标准全文），不要拿博客文章当依据写进方案。
把三层结论合成为一张分级表。 每个字段标注：三层的约束分别是什么、取最严格者作为落地策略。这张表就是 6.2、6.3 节所有工作的输入。沙盘里这张表最终演变成了后来所有新数据源的准入流程——字段不过表，不进链路。
这个顺序背后的工作哲学贯穿全书：先拿客户自己的约束，再用外部知识补缺。FDE 的价值在于把客户的现实约束翻译成工程方案，而不是把外部最佳实践硬套到客户头上。
6.1.6 要点总结
- 数据边界问题的判定依据有三层：法规、合同、客户安全策略，客户内部策略往往比法规更严，别拿"合规"当挡箭牌。
- 画出完整调用链（客户端→网关→模型服务→第三方 API，含工具执行与日志支线），把"安不安全"的争论变成逐段可核验的清单。
- IT 负责人合规三连问——流向（出境了吗）、用途（训练吗）、责任（泄露了谁担）——分别对应调用链的不同段落，要有具体证据支撑。
- 面对叫停风险，正确姿势是把安全问题工程化：流向图、字段级分级清单、控制措施映射三份材料，而不是口头保证或对抗。
- 日志链路是数据流向图上最常被漏掉的支线，画双向流，别只画正向。
参考资料
- OWASP GenAI Security Project — OWASP 官方 GenAI 安全项目，LLM 应用数据安全风险与缓解措施的权威社区参考
- 数据出境安全评估办法（国家网信办，2022 年 9 月 1 日施行） — 网信办官网相关法规页，数据出境制度的法定依据
- OpenAI 官方数据使用政策（Enterprise Privacy） — OpenAI 官方关于企业数据不用于默认训练与保留期的说明
- Microsoft Presidio（GitHub） — 微软开源的 PII 识别与匿名化框架，脱敏工程的基础工具之一