我花了两周，才搞明白“禁止上传文件到 AI 平台“这件事

/* MD / 富文本中的 .toc（含博客园搬家等嵌套结构）；.toc-box 在侧栏，不受影响 */
#content_views .toc,
/* 编辑器常在目录前后插入空 p（:empty 仍占 20px），一并去掉避免顶空隙 */
#content_views.markdown_views > p:empty:has(+ .toc),
#content_views.markdown_views > .toc + p:empty,
/* 富文本旧版目录标记 */
#content_views.htmledit_views #main-toc,
#content_views.htmledit_views #hr-toc,
#content_views.htmledit_views p[id*=\”-toc\”] {
display: none !important;
}
/* 目录去掉后，紧跟的首个标题不再多出一块上边距 */
#content_views.markdown_views > .toc + h1,
#content_views.markdown_views > .toc + h2,
#content_views.markdown_views > .toc + h3,
#content_views.markdown_views > .toc + h4,
#content_views.markdown_views > .toc + p:empty + h1,
#content_views.markdown_views > .toc + p:empty + h2,
#content_views.markdown_views > .toc + p:empty + h3,
#content_views.markdown_views > .toc + p:empty + h4 {
margin-top: 0 !important;
}

先碎念一句：这个项目我原本以为三天就能上线。

结果折腾了两周，中间还出了一次"看起来防住了、实际啥也没防住"的事故。写出来给同行避坑。

一、需求其实很朴素

客户是一家做 IC 设计的公司，200 多人。安全负责人找到我，需求就一句话：

"别让工程师把设计文档传到那些 AI 平台上去。"

背景也很清楚：这两年大模型工具火，工程师写 Verilog、写脚本、查报错，习惯性地往对话框里贴代码。有人贴的是模块接口，有人贴的是完整的 RTL，甚至有人把客户给的 PDK 说明文档整份传上去了。

法务那边提了两次风险：一是违反客户 NDA，二是设计资产可能进了训练数据。

需求明确，我觉得简单——封几个域名不就完了？

二、第一版：我以为封域名就够了

我的第一版方案，思路很"网络管理员"：

• 在上网行为管理设备上，把几个主流 AI 平台的域名加进黑名单；
• 顺带封一下相关的 API 域名；
• 测试了一下，浏览器访问确实打不开了。

我挺满意，跟客户说"上线了"。

错在哪？ 我默认了一个前提：员工传文件，只能通过浏览器访问那几个网站。

这个前提，是错的。

三、诡异的现象：日志干净得反常

上线一周后，客户安全负责人找我，语气有点怪：

"你们这个方案，好像没起作用啊。"

我第一反应是不服。打开管理后台给他看：拦截日志一片空白，一周内零拦截记录。

我说："你看，没人尝试访问，说明大家自觉。"

他不说话，给我看了一份内部抽查记录——某工程师的电脑里，有一份完整的模块设计文档，最近修改时间就在上周。而这份文档的副本，出现在了他个人网盘的"AI 工具临时上传"目录里。

日志是零，但文件确实出去了。

这是我做安全这么多年，第一次遇到"拦截系统完全没报警，但泄密已经发生"的情况。那种感觉不是生气，是后背发凉。

四、排查走了三天弯路

我一开始怀疑是日志模块坏了。

弯路一：查日志链路。 花了半天，确认日志采集正常，其他类型的上网记录都在正常上报。说明不是日志问题，是真的没触发规则。

弯路二：怀疑域名清单不全。 我花了一天时间，把国内外能想到的 AI 平台域名列了 80 多个，全部加进黑名单。测试还是拦不住。

弯路三：怀疑是加密流量。 我以为员工用了什么代理工具绕过。抓包分析后发现，流量走的就是正常的 HTTPS，没有代理。

那问题到底出在哪？

五、顿悟：我封错了"地方"

转折点来自一个很细节的现象。

我让测试同事复现操作，他打开的不是浏览器，而是一个桌面客户端。上传文件的时候，进度条走的是客户端自己的界面，地址栏压根没出现任何 AI 平台的域名。

我又试了另一种方式：把文件先传到个人网盘，再在网盘里"分享给 AI 助手"。全程也没碰我封的那些域名。

那一刻我才想明白：

我封的是"网站入口"，但文件外流的入口根本不是网站。

真实的上传路径至少有这四条：

更关键的是，这些路径有个共同点：它们都是"合法"的正常业务流量。网盘是公司允许的，IDE 是开发必需的，客户端更新是日常行为。

我试图用"封域名"这个网络层的手段，去解决一个"文件从终端流出"的问题。层级搞错了。

六、想通之后，方案就换了

第二版方案，我不再纠结"封哪些域名"，而是回到问题本身：文件在离开这台电脑的那一刻，我能不能管住？

思路变成三层：

第一层：按文件属性管控，而不是按目标地址管控。

不再问"你要传到哪个网站"，而是问"你要传的是什么文件"。设计文档、RTL 源码、PDK 相关文件，一旦识别为敏感类型，任何外发通道都触发管控。

这一步的关键词是内容识别，不是地址识别。

第二层：通道全覆盖，而不是只盯浏览器。

浏览器、桌面客户端、网盘同步、即时通讯、U 盘、打印——所有能离开终端的通道，统一纳入策略。哪个通道没管住，哪个就是突破口。

第三层：留痕和溯源兜底。

对于确实需要外发的场景（比如给代工厂发文件），走审批流；对于无法完全阻断的场景，靠水印和日志做事后溯源。

七、上线后的验证方式，也变了

第一版我测试的方法是"访问一下网站，看能不能打开"。

第二版我换了个思路：让测试同事用尽一切办法，把一份标记为敏感的文档弄出这台电脑。

• 用客户端上传 → 拦住了
• 传到个人网盘 → 拦住了
• 通过即时工具发送 → 拦住了
• 改成压缩包、改后缀名 → 依然识别并拦住
• 正常业务文件（比如给客户的报价单）→ 正常通行，无误拦截

最后一条很重要。第一版方案最大的隐患不是"防不住"，而是"要么全防住但业务瘫痪，要么为了业务不瘫痪而全放开"。第二版按文件属性区分，才真正做到了"该管的管住，不该管的别添乱"。

八、这次踩坑，我以后会记住的三件事

第一，别用网络层的手段解决终端层的问题。

封域名是网络管理员的本能反应，但"文件外流"这件事，发生的位置在终端，不在网络边界。层级错了，后面怎么优化都是徒劳。

第二，"零拦截日志"不等于安全，可能等于失效。

这是我这次最大的教训。日志一片空白，我第一反应是"大家很自觉"，而不是"我的规则可能没生效"。没有告警，有时候比有告警更危险。

第三，测试方案时，要站在攻击者的角度，而不是管理员的角度。

我第一版的测试是"我封的域名，访问不了"。这是管理员视角。真正的测试应该是"想尽一切办法，把这份文件弄出去"。这是攻击者视角。

九、给同行的建议

如果你也要做"禁止上传文件到 AI 平台"这类项目，建议先回答三个问题：

最后说一句：这两年"防 AI 泄密"的需求越来越多，但很多企业的思路还停留在"封网站"。

大模型只是新的出口，文件外流是老问题。 用老办法解决新问题，翻车是迟早的事。

我这次花了两周，希望你看这篇文章，两天就够了。

责编：璇玑