十月的最后一周，一家年营收六十亿的服装集团签了一份 FDE 合同。签约桌上，法务问了一句，这支队伍进来，能看到哪些数据。供应商的回答很干脆，为了跑通场景，需要业务数据的读取权限，越全越好。会议室安静了几秒，董事长把笔放下了。
这个停顿不多余。前沿部署工程师这套做法最早出自 Palantir，这家公司近二十年前把工程师直接派到客户现场，早年的客户是美国国防部和情报部门。两人一组的编制至今没变，一个代号 Echo，负责弄清客户到底要什么，另一个代号 Delta，负责把它做出来。今天 FDE 已经占到 Palantir 员工总数将近一半。OpenAI 今年年初组建了自己的 FDE 团队，年底扩到约五十人，Anthropic 把包含 FDE 在内的应用 AI 团队扩了五倍。这套模式能成立，前提是工程师能摸到客户真实的数据和真实的流程。摸不到，他就只能做演示。
数据这件事，问法不该是给不给。真问题是给到哪一层，谁能批，人走了怎么收回。
可以分三层。第一层是汇总层，只给指标和趋势，工程师能看到哪个环节慢、哪个环节贵，看不到具体是谁。第二层是明细层，脱敏之后的单据和记录，人名换成编号，金额保留比例。第三层是原始层，工程师能进实际运行环境动东西。多数服装企业的第一个场景，第二层就够了。把活干出来靠的是判断哪一步多余，跟看到客户身份证号没关系。
做错的样子见过两种。一种是一次性把权限全打开，项目跑得飞快，半年后出问题，审计追不到是谁把数据导出去的。另一种是层层报批，法务、信息、业务三道签字走了两个月，工程师进场只能画图，三个月过去，业务方说没感觉到变化。两边都输，输的地方一样，没人提前把层级和责任人写清楚。
还有一条容易被忽略。合同里写了权限，没写留存。项目结束，工程师带走的模型、脚本、样本，哪些能用在新客户身上，哪些必须销毁，这条不写，第二家客户就会在别处看到你的业务细节。Palantir 当年能在情报系统里站住脚，靠的就是这条边界守得住。
脱敏这件事，难点不在技术，在谁定字段。多数公司交给信息部定，信息部按经验删掉姓名和身份证，留下手机号后四位、地址、邮编、订单时间。这几项拼起来，外部的人能还原出是谁。可行的做法是让业务部门自己列一遍，哪些字段组合起来能认出一个人，列完再删。业务的人比技术的人更清楚哪些信息是敏感的。
还有一个反例。有家企业为了赶进度，让工程师直接用管理员账号登进系统查数据，查完忘了改密码。三个月后这名工程师离职去了同行，账号还开着。这种事发生一次，后面所有的数据合作都谈不下去。 希纪在给服装企业做增长诊断时，会先看一眼这份合同的数据条款。写得含糊的，项目多半会在第四个月卡住，因为业务部门开始防着工程师，工程师开始绕开业务部门，两边都在做小动作。
可以带走的是一张三列表。左栏写数据层级，分汇总、明细、原始三行。中栏写审批人，汇总层业务负责人签，明细层信息负责人加业务负责人双签，原始层必须董事长或总经理签。右栏写期限，项目结束三十天内回收权限，样本和数据副本一律销毁，销毁要有记录。
再加一条，项目组里指定一个人管这件事，名字写进合同附件。没有具体的人，边界就是一句口号。
回到那张签约桌。董事长最后让法务加了一条，前两个月只开汇总层和明细层，第三个月评审过再谈原始层。供应商不太高兴，说这样会慢。董事长回了一句，慢两个月，比半年后停项目便宜。
这个处理不漂亮，但它把风险放在了能看见的地方。数据给出去容易，收回来难。
一个马上能做的检验，把合同翻到权限那一条，看看有没有写三层，有没有写审批人名字，有没有写回收期限。三条缺一条，就先别签。
希纪 · 服装产业观察