[[RYAN_JUEJIN_IMAGE_01]]
据 11 月 3 日的媒体报道，字节跳动计划从 11 月起限制Claude、Codex等外部AI工具访问L4级代码仓库和飞书文档。
员工自购的账号也在报道所述的限制范围内。报道提到部分Seed使用场景例外。目前尚未找到字节公开发布的通知原件。
值得企业关注的是，报道把限制落到了具体资料上。一名员工有权限打开内部文件，通常是因为他需要用这份资料完成工作。把文件交给外部AI服务处理，多了一次数据传递，也多了一个处理方。哪怕用的是公司购买的账号，这次传递也需要有明确的授权。
资料交给AI之后，风险会走到哪儿？
在聊天框里粘贴一段合同，员工至少能看到自己交出去的内容。用了能读文档或代码的插件，实际送给模型的内容还可能包括工具自动带上的上下文。员工界面上只看到一句提问，公司却要知道请求里究竟包含了什么。
源文件从对话界面删掉以后，服务商侧是否仍有日志或其他副本，得看实际配置和服务条款。等出了问题才翻合同，往往连该找谁核对都要重新查。
还有一种暴露发生在公司内部。知识库如果用同一个高权限账号取资料，检索时又没按提问者的权限过滤，AI就可能把对方原本打不开的文件概括出来。员工甚至不用看到原件，只看答案就能拿到其中的敏感内容。
资料即使始终在公司允许的范围内流转，AI的答案也可能出错。比如同一项业务前后用过两版制度，模型读到了旧版，给出的解释仍然可以写得很顺。留在个人草稿里的错误，改一遍就行。
要是这段解释被当成审批依据，后面的经办人看到的可能只有结论，已经看不到它用的是哪一版制度。到这时，复核要追回当时引用的材料，才能判断哪些决定受到了影响。
再往前一步，AI开始替人操作系统。邮件附件里的一段文字，本来只是它要读的内容，却可能被模型误当成操作指令。如果工具已经拿到邮件发送权限，模型的判断就有机会变成一次真实外发。
能不能挡住这一步，取决于发送接口有没有独立检查接收人和附件范围。只在提示词里提醒它「注意保密」，接口本身仍然可能照常放行。
风险最难处理的时候，通常已经到了事后。员工用过个人账号，部门又各自接了工具，公司未必能从现有记录还原资料是在哪一步传出去的。管理员关掉一个登录账号，也得再看原先给插件的接口授权有没有失效。已经排队的任务如果还在执行，光看后台的停用状态，容易以为问题已经止住了。
企业该把管控放在哪一步？
我的判断是，先给员工一个日常用得上的企业入口，再把边界写进数据传输和系统执行的地方。安全团队可以统一选工具，具体资料能不能交给工具，还得由清楚资料用途的人定。对业务来说，规则越能在上传文件时看懂，就越少需要临时问人。
数据分级可以从现有权限开始。拿内部知识库来说，原来只能由某个部门查阅的文档，接进AI搜索后仍按原权限返回结果。涉及高敏资料时，数据负责人还要判断能不能交给外部服务。能只给必要的字段，就别把整份原件送过去。需要保留在受控环境里的资料，由企业提供可用的处理入口。
采购核对也要跟上这条线，查清实际发送给服务商的内容，再确认对方会留存多久。服务变更或合作结束时，企业才知道从哪里收回授权、怎么核实数据处理结果。
输出的使用边界要跟业务原来的复核规则对齐。查制度时，可以要求AI标出来源和版本，方便经办人回原文看。到了要修改业务记录这一步，再由系统按动作检查权限。
需要人工确认时，页面应该把这次准备执行的操作摆清楚，让负责人知道确认之后哪条记录会变。执行端只放行刚才确认的动作，范围有变就重新核对。这样即使模型读错了内容，业务系统还有机会在最后一步拦住。
授权还会随着用途变化。一个只帮员工起草邮件的工具，接上自动发送以后，出错的后果已经不同。新增权限应由邮件系统的负责人重新审核，具体到能发给哪些人。原先通过的采购审批只覆盖当时的用途。接入范围变了，原有的验收结果也要跟着复核。
规则有没有落到系统里，可以在上线前试出来。用测试账号访问原本无权读取的资料，看看请求在哪里被拒绝。接着让管理员撤掉连接授权，确认下一次调用确实跑不起来。
为便于事后回查，保留能关联到这次操作的记录即可，敏感正文没必要在日志里再复制一遍。停用之后，也要有人接回未完成的业务，免得安全问题处理完了，原来的工作却断在那里。
随着AI从回答问题走到参与业务，数据安全会越来越重要。过去，企业主要关心一份资料会被谁看到。现在，这份资料还可能影响系统接下来做什么。
企业能管清数据的去向，并让系统按授权执行，才有条件把更多工作交给AI。
