这篇解决的问题是：驻场工程师每天接触客户最敏感的数据，但多数团队没有一张能落地的红线清单。
最值得拿走的是把合规拆成六个可控层面：分级与最小化、内网与私有化约束、跨境与跨域流动、权限与留痕、模型与提示词泄露面、事后响应。最容易出现误用的地方，是把合规当成法务的文档工作——真正的失效点都在日常动作里：一次本地图标拷贝、一段贴进提示词的真实客户名、一个没回收的临时权限。
增量在于站内已有进场前自查清单与三原则 FAQ，本文补上私有化环境、跨境远程协作与模型时代特有泄露面这三块，并强调出事之后的响应顺序比反应速度更重要——能解释的事故伤不到客户关系，解释不了的才伤，这是国内语境下常被忽略的判断。
读完建议做一件事：把你当前客户现场的红线逐条写进启动文档，进场前再对照站内自查清单过一遍，缺哪条补哪条。
—— FDEChina编辑部 · 架构师视角
Forward Deployed Engineer（FDE，前置部署工程师）与传统驻场角色最大的差别，不在技术栈，而在数据接触面：FDE 要让模型在客户业务里真正跑起来，就必须碰业务数据、业务逻辑和业务人员，而这三样恰恰是客户安全体系里防护最严的部分。多数交付团队对合规的理解停留在「签了保密协议」的层面，但真实风险发生在日常动作里——把一份样本数据拷到本地调试、把一段含真实客户名的日志贴进第三方工具、一个项目结束没回收的临时权限。合规一旦出事，代价不是某个工程师的绩效，而是整条客户关系，甚至整个公司在该行业的交付资格。这篇按六个层面把红线说清楚：数据分级与最小化、内网与私有化部署约束、跨境与跨域数据流动、权限与审计留痕、模型与提示词中的敏感信息、出事之后的响应。每一条都指向同一个原则：合规不是文档，是交付物的一部分。
先划边界：你在客户安全体系里是什么角色
进场第一件事不是写代码，是把角色边界写下来。FDE 的尴尬在于三重身份错位：技术上像内部员工——有内网账号、能进业务部门会议、被拉进核心工作群；合同上是供应商人员——受保密协议和数据处理条款约束；责任上是外部数据接触者——出问题时客户的合规体系会按外部人员处置你。很多麻烦源于客户和你自己都按「半个自己人」行事，权限边界靠习惯而非制度维持。
务实的做法是在启动阶段用一页纸固定三件事：你能访问哪些数据、到什么粒度、用什么设备与网络；你的产出物归谁、存在哪里、谁有权带走；出了问题走谁的流程、谁是第一联系人。这三件事应当在项目启动文档里就有位置，具体模板可以对照 FDE 项目启动文档模板。如果客户自己的合规部门说不清这些，那不是可以混过去的灰色地带，而是要在排期里主动补上的前置工作——对客户来说，你把边界问清楚本身就是专业度的证明。
数据分级与最小化：先问「非看不可吗」
数据分级的口径以客户为准，但 FDE 心里要有一张通用地图：公开信息、内部信息、敏感个人信息与业务敏感数据、核心生产数据。这张地图的用途不是背诵，而是让你在每一个具体动作前有能力自问一句：我手上这条数据是哪一级、我接下来要把它带到哪一级环境去。多数事故不是有人越级偷看核心数据库，而是「顺手」——为了调一个格式问题，把生产表的前几百行导到本机；为了给客户演示，把真实交易记录贴进在线工具做示例。
最小化原则落到执行层是三个递进的问题。第一，这个场景能不能用脱敏或仿真样本？绝大多数格式、性能、流程问题不需要真实数据。第二，能不能用聚合结果替代明细？给模型做验收评测时，分布统计往往比原始记录更稳、也更不敏感。第三，能不能让数据留在客户环境、只把代码和配置带出去？这是最理想的结构：代码回流总部沉淀为组件，数据永远不出授权边界。站内 客户现场数据与合规自查清单 把这套问题拆成了进场前可逐项打勾的自查项，建议每次新项目都过一遍——清单的价值不在读完，而在进场前那一小时里逼你把含糊的假设变成问出口的问题。
内网与私有化部署约束：硬件到位不等于安全到位
国内企业级大模型交付中，私有化部署长期是主流形态之一，相关市场规模被多家机构持续追踪（站内 国内大模型私有化交付样本复盘 汇总了公开报道的口径）。私有化对 FDE 意味着一套与公有云完全不同的工作约束：模型和推理服务在客户内网，没有外网或仅有限出口；代码提交走客户内网仓库或经审批摆渡；终端有 U 口与外设管控；开发网与生产网物理或逻辑隔离；任何变更要走审批流，窗口期固定。这些约束会让习惯云端快速迭代的工程师非常不适应，但正确的反应不是绕开约束，而是把约束转化为交付设计。
具体来说：依赖无法随取随用，就要在进场早期做好离线依赖包与版本清单；变更窗口稀缺，就要把部署做成幂等、可重复的脚本而不是手工操作序列；审批链长，就要把一周后需要的权限和数据在今天申请。安全约束与交付效率并非天然对立——私有化环境里最常见的效率损耗，恰恰来自前期没有把约束摸清、后期反复补审批的返工。还要注意一点：私有化不等于天然安全。内网环境的日志体系、访问审计、漏洞管理往往比成熟的云平台弱，硬件到位只是开始，安全基线与业务逻辑一样，都需要驻场的人一寸一寸铺进去。
跨境与跨域数据流动：远程协作是最高频的触碰点
跨境是 FDE 交付里法律复杂度最高、日常摩擦却最容易被低估的部分。三个错位叠加：模型的推理端点可能在境外，你所在团队的支持人员可能分布在多个法域，日常协作工具可能托管在第三地。结果是一个技术上的普通动作——远程连一次环境、同步一段报错日志、让总部同事复现一个问题——在合规视角下可能是数据出境。FDE 不需要成为跨境合规律师，但必须能在动手前识别「这个动作有没有可能让客户数据离开其授权边界」，识别出来之后把判断交给客户合规与法务，最终口径以他们的意见为准。
实操层面有三条纪律。第一，进场时问清三件事：客户数据的任何部分是否允许在境外被处理；模型服务方的日志留存政策是什么、归谁所有；依赖的第三方工具各自的数据驻留区域在哪里。第二，跨境协作改为「移动的是任务，不是数据」——总部同事需要复现问题时，带走的是脱敏样本或仿真数据，由现场人员在自己的环境里执行。第三，跨域流动同样适用于客户内网与你公司云环境之间：把代码带出去、把数据留下来，这条不对称纪律越早养成越省心。反过来也有对等义务——你公司产品侧的代码、密钥与内部文档，同样不应随意流入客户环境，方向不同，纪律相同。
权限与审计留痕：让每一次接触都可回溯
权限管理的原则一句话就能说完：按任务申请、限时授予、定期回收、绝不共享账号。难的是在项目压力下守住它。合理的节奏是：拿到明确任务再申请权限，而不是「先把权限要齐免得来回跑」；申请粒度对齐任务需要的最小集合，读脱敏库能解决的就不申请生产库；设置到期时间，让权限自动失效而不是靠人记得回收；项目里程碑后主动做一次权限盘点，把不再需要的交回去。主动交回权限在客户安全团队眼里是高价值信号——它证明你的存在是可管理的。
留痕是同一枚硬币的另一面。客户环境里的操作日志、数据导出的审批记录、生产变更的工单、重要口头决定的邮件确认，这些留痕平时像官僚主义，出事时是你唯一的保护。一个朴素的判断标准：如果明天有人问「你在某月某日对这份数据做了什么、谁批准的」，你能不能在三分钟内给出有出处的回答。留痕也直接服务交接——站内 FDE 交接清单 把离场时的权限回收、环境清理、文档归还列成了收尾动作，建议把交接清单当成合规动作而非行政手续来执行。离场不清权限、不清数据副本，等于把你自己做过的事悬在无人负责的状态里。
模型与提示词里的敏感信息：最容易被忽略的泄露面
大模型交付带来了传统驻场不存在的泄露面，而它的特点是每一处都长得像正常工作。第一处是提示词：为了让模型输出正确的业务口径，工程师会在提示词模板里嵌示例，最顺手的示例就是真实客户记录——真实姓名、真实账号、真实交易，从此随着每一次调用流向推理端点。第二处是评测集：为了让验收有说服力，用生产数据直接构造评测集，敏感样本从此躺在评测脚本和它的版本历史里。第三处是日志：调用日志、对话记录、报错信息由谁留存、存多久、能否用于训练，这些问题在合同里往往只有一句模糊条款，而现场已经每天在产生数据。
对应的红线同样具体。提示词里的示例一律用脱敏生成的仿真数据，格式与真实数据对齐、内容与真实数据无关；任何想嵌入真实记录的冲动，先过一遍「这条数据是哪一级」的自问。评测集与生产数据同源但不同集：从同样的分布里取，但不直接复用生产明细，且评测集本身按客户数据分级管理。模型调用日志的留存与归属在启动阶段就写进文档，而不是等法务在验收时才发现口径不一致。这些做法会增加一点前期工作量，但相比把真实数据嵌进提示词之后再逐环境清理，成本几乎可以忽略——模型时代的敏感信息一旦进入调用链路，你甚至说不清它流经过哪里。
出事之后：响应顺序比反应速度更重要
再完善的红线也只能压低概率，不能降为零。真正拉开差距的是出事之后的动作顺序。第一动作不是自己先查——而是按客户报告流程上报。工程师的本能是先弄清楚发生了什么再汇报，但在合规事件里，这个本能会毁掉你的信誉：客户安全团队需要的是第一时间进入处置流程，影响面他们的工具比你查得快。第二，固定现场：不删除任何东西，包括你以为是错误的东西——删除动作本身会破坏审计链。第三，如实、完整地陈述自己知道的部分，包括不确定的部分；在事件调查里，后来被发现的隐瞒比事件本身更致命。第四，对外口径完全交给客户，你不接受任何外部询问、不在任何渠道讨论事件——包括匿名的、以为不会被识别的渠道。
这些顺序应当在出事之前就写进启动文档：谁是第一联系人、走什么渠道、多快内上报、哪些信息必须包含。事后还有两件事。一是配合复盘，把根因归到流程而不是人——一次成功的复盘应该产出「哪条红线缺了或没被看见」，而不是「哪个员工粗心」。二是更新自己的清单，把这次事件变成下一份启动文档里的一个检查项。合规设计的目标从来不是零事故——那是做不到的——而是让每一次事故都可解释、可追责、可改进。能解释的事故伤不到客户关系，解释不了的事故才伤。
小结与下一步
把六个层面收拢成一句话版本：进场先划角色边界；数据分级在心、能不动就不动；私有化约束转化为交付设计；跨境跨域只移任务不移数据；权限限时回收、动作全程留痕；提示词与评测集零真实数据；出事先报告、不删改、口径交客户。这些红线的共同特征是：遵守它们成本低，违反它们代价高且不可逆。
下一步建议按顺序做三件事。第一，进场前对照 数据与合规自查清单 逐项过一遍，把答案写进项目文档而不是留在脑子里。第二，把本篇的红线清单按你的客户现场裁剪成一份一页纸版本，在启动会上与客户安全团队当面确认——三原则「权限最小化、数据不出授权边界、全程留痕可审计」的完整展开见 FDE 驻场的安全与数据合规怎么管。第三，把红线写进 项目启动文档，让它成为团队可复用的默认配置。合规做得好的驻场工程师，客户未必立刻夸奖；但做得不好的，客户一定记得。在 FDE 这个靠信任吃饭的岗位上，这就是全部理由。