在别人的安全边界里干活

FDE 是有生产权限的客人。这个位置在软件行业里不常见：多数工程师有权限但没有客户关系，多数顾问有关系但没有 shell。由此产生的失败很少是恶意的——是笔记本上留着一份客户导出、是 API key 被粘进 notebook、是演示建立在周二还没问题、周五变成合同问题的数据上。

决定架构的四个问题

第一次会就要问，在画任何图之前。它们的答案对设计的影响，比任何框架选择都大。

1. 数据可以住在哪？ 你的云、他们的云、只能本地，或者某个指定区域。经常出现的情况是：同一场会里先说「我们是云优先」，然后答案是「只能本地」。
2. 谁是处理者，谁是控制者？ 按合同说，不按口头说。产品在处理数据，就有一份数据处理协议；FDE 的笔记本在处理数据，那就是一个等着发生的发现项。
3. 什么东西绝对不许出去？ 有些客户能立刻点名（客户档案、健康数据、原始单据），有些说「什么都不许」，然后在第三周说「除了那几个」。
4. 他们的安全团队要求什么审计痕迹？ 日志保留多久、访问怎么复核、他们要不要自己看日志。这件事搞错，是在几个月后的审计里被一个不是你的人发现的。

能活过这些答案的三种架构

多数情况落在三种形态里，顺序有意义，因为一个比一个贵。

把模型搬到数据旁边。 在客户环境里跑推理——他们的云账号、他们的 VPC、他们的本地集群。什么都不出去；你部署权重或者调私有端点。受监管客户的默认解，也是工作量最大的解，而且大部分工作量在管道，不在建模。

只送派生数据出去。 本地抽取、分类或摘要，只把小结果送出去。工程上的真问题是：这个派生结果算不算真正去标识化——这比「我们把名字去掉了」是一个强得多的主张。

带着合同送数据。 低敏感数据、加上真实存在的数据处理协议，是可以的。陷阱是范围蔓延：一个从匿名日志开始的部署，第四周多出了一个文档字段，而没有人重新打开过这个问题。

无论选哪种，把它写进设计说明，带上日期和批准人。安全决策会过期，而批准它的那个人，往往在你需要为自己辩护之前就已经换岗了。

上线之后还能站得住的三条习惯

客户导出永远不留在笔记本上。 工程师这么干的原因是速度：本地一份副本让迭代变得毫无摩擦。它在乎的原因是那份副本会比项目、比这台机器、常常比这家公司活得更久。确实需要样本，就给它命名、限制范围、写明删除日期——并在评审会上把那个日期说出口。

把凭据当成部署产物。 客户的凭据放在客户的密钥库里，带一个归属人、一个轮换日期、一份可读名单。仓库配置文件里的 API key 是部署后评审里最常见的发现项，而且永远不会被承认是永久的——它总是「临时的」。

把数据流写下来，一次，一页。 来源 → 变换 → 模型调用 → 存储 → 删除。如果安全评审的人一分钟看不明白，它要么是错的，要么是没写。

模型供应商这一问

有两件事改变了局面，现在都是标准面试题。第一，提示词和输出通常穿过第三方，所以「我们不外发」是一句关于你代码的话，不是关于你供应商的话——而客户会问供应商。第二，模型会在你脚下变：供应商下线一个版本，行为偏移，一个已经通过验收的系统，会悄悄改变它对个人数据做了什么。

实用的答案一点也不漂亮：锁版本、留一套小评测集（里面包含一项数据处理检查）、在运行手册里写一行回滚。模型变了会对线上部署造成什么，是交付风险，不是研究问题。

当答案是「不行」

安全团队说不，理由通常正确，偶尔过时。两个动作比争辩有用。

问一句「要变成可以，需要哪些条件成立」——某个具体控制、某个供应商认证、更窄的数据范围——并把答案写下来；有一半情况，那个要求比绕路更便宜。再给一个小一点的部署：只读接入、只碰样本记录、写明删除日期，往往在一个完整管道批不下来的地方批得下来。它就是第一周原型那种意义上的真部署，而且它能产出关于数据的证据，那是单靠一次安全评审永远拿不到的。

不该做的，是绕过那条边界。一份影子副本、一个没登记的供应商账号、一个号称「只在内网」但悄悄连上公网的工具——这是唯一一类能把职业生涯而不是项目结束掉的错误。日落条款里说的那份交接物，就是访问名单、保留期限和删除证明该待的地方。