很多企业正在建设正式的大模型平台：统一采购模型、接入知识库、配置权限、设计审批流程，再把人工智能纳入信息安全和数据管理体系。
但在正式系统上线之前，员工往往已经开始使用各种工具。
有人用大模型整理客户会议记录，有人让它分析表格，有人借助它修改合同、生成代码、回复邮件，还有人把一段复杂的内部政策复制进去，请模型解释“这件事到底应该怎么做”。
这些行为未必出于违规意图。更多时候，是员工需要解决一个具体问题，而企业的正式工具还没有准备好。
真正值得关注的，不是员工是否使用了大模型，而是组织是否知道他们正在如何使用，以及这些非正式使用方式正在怎样改变工作流程。
一、员工使用模型，通常不是因为想绕过制度
企业经常把非正式使用人工智能理解为风险行为，认为员工私自调用外部工具，是安全意识不足或不遵守规定。
这种判断有时成立，但并不完整。
员工选择某个外部工具，可能是因为内部系统申请周期太长，模型效果不理想，权限限制过多，或者正式流程只支持少数场景。一个销售人员急需把客户访谈整理成行动清单，一个工程师需要快速理解陌生代码，一个运营人员想把复杂资料改写成客户能看懂的语言，他们不会因为企业还在审批采购而停止工作。
如果正式系统没有提供足够方便的替代方案，员工自然会建立自己的工作路径。
因此，企业首先要理解的不是“员工为什么不听规定”，而是“正式流程为什么没有满足真实需求”。
很多影子人工智能的出现，本质上是组织效率和制度速度之间出现了空隙。
二、非正式工具会形成一套看不见的第二流程
在正式流程中，一项任务可能需要经过数据录入、审批、复核和归档。
但员工使用大模型后，往往会在流程之外增加几个步骤：先让模型整理材料，再让另一个工具检查表达，最后手动复制到正式系统中。久而久之，这些步骤变成了实际工作的一部分，却没有出现在任何流程文件里。
管理者看到的是最终交付物，未必知道它经过了哪些工具和判断。
这会产生一种隐性依赖：企业以为自己依靠的是内部系统，实际上某些关键工作已经依靠个人账号、个人提示词和个人积累的操作经验。
一旦员工离职，账号失效，工具收费变化，或者外部服务停止，组织才会发现，原本没有写入制度的那套流程，已经成为业务不可缺少的一部分。
这与传统的个人经验不同。个人经验通常可以通过口头传授逐渐扩散，而隐藏在外部工具、浏览器插件和私人模板中的工作方法，可能连同员工一起离开。
三、同一个岗位，可能正在出现不同的判断标准
当员工使用不同的大模型、不同的提示词和不同的资料来源时，同一项工作会产生不同的结果。
一名客服习惯使用模型生成更谨慎的回复，另一名客服则偏好更积极的表达；一个分析师要求模型优先关注成本，另一个分析师要求模型优先关注增长；一名程序员让模型生成大量注释，另一名程序员则更关注运行效率。
这些差异不一定意味着谁做错了，但如果组织没有明确的业务标准，模型会放大个人偏好。
最终，同一个客户可能从不同员工那里得到不同解释；同一种风险可能在不同团队中被赋予不同等级；同一份材料经过不同工具处理后，结论也可能相互矛盾。
企业以为自己拥有统一流程，实际上每个人都在背后运行一套不同的“私人系统”。
问题不是工具太多，而是组织没有定义哪些部分可以自由发挥，哪些部分必须保持一致。
四、最容易被忽略的是知识离开了企业
员工把资料输入外部模型时，企业关注的往往是数据泄露。
但还有一个更隐蔽的问题：知识处理过程离开了组织。
员工可能把一份客户反馈交给模型总结，再根据模型提炼出的内容形成判断，却没有把完整过程记录在企业知识库中。另一个团队遇到类似问题时，只能重新开始，因为真正有价值的分析过程没有沉淀下来。
久而久之，企业的知识会出现两种状态。
一种是正式系统中保存的文件，结构完整但更新缓慢；另一种是员工个人工具里不断形成的总结、分类和经验，更新很快但组织无法访问。
当这两部分越来越分离，企业就会出现“资料很多，却找不到真正有效经验”的问题。模型提高了个人处理信息的效率，却可能降低组织共享知识的能力。
真正需要管理的，不只是数据能不能被输入模型，还包括经过模型加工后的判断是否回到了组织之中。
五、禁止所有非正式使用，通常不会得到真实情况
面对影子人工智能，一些企业会直接发布禁令，要求员工不得使用未经批准的工具。
这在高风险数据和关键业务中有必要，但如果企业只采用全面禁止的方式，可能产生反效果。
员工不会因此停止需求，只会减少主动报告。管理者表面上看到的合规率提高了，实际使用情况却变得更加不可见。出现问题时，企业既不知道哪些工具被使用，也不知道哪些流程已经依赖这些工具。
比全面禁止更有效的方式，是建立分层规则。
对公开资料、普通写作和低风险头脑风暴，可以允许员工在明确边界内使用；对客户信息、内部财务、源代码和未公开战略资料，应当使用受控工具；对涉及合同承诺、人员评价、资金支付和安全判断的任务，则必须保留审批和人工复核。
规则越接近真实工作，员工越可能主动遵守。
六、企业需要管理“用途”，而不只是管理“工具”
很多人工智能政策会列出一长串禁止使用的软件名称，但工具变化很快，今天的平台可能明天就被替代。
更稳定的管理方式，是围绕用途、数据和后果制定规则。
同一个模型，用来润色公开文章和用来判断员工是否适合晋升，风险完全不同。即使使用同一个企业内部平台，把公开信息转成摘要和把客户敏感资料输入模型，也应有不同的权限与记录要求。
企业可以先建立使用场景清单，记录每种用途涉及的数据类型、影响对象、是否需要人工审核，以及模型输出是否会直接触发后续行动。
这样，即使底层工具发生变化，管理框架仍然有效。
七、把影子创新引回组织，而不是只把它当成问题
非正式使用中也可能包含真正有价值的创新。
员工往往最早知道哪些任务适合模型，哪些提示方式效果更好，哪些环节仍然需要人工判断。如果企业只把他们视为风险来源，就会错过一线形成的有效经验。
企业可以建立轻量的试验机制：允许员工提交正在使用的场景，提供脱敏数据和受控环境，要求记录目标、限制和结果。经过验证后，再把有价值的方法转化为正式模板、内部工具或标准流程。
这样，个人探索就有机会变成组织能力。
关键不是要求员工停止试验，而是让试验能够被看见、被评估、被改进，并在适合的时候回到企业能够管理的环境中。
八、正式系统不应只是更安全，还要更好用
如果员工始终觉得外部工具更快、更方便，影子使用就不会消失。
企业的正式平台至少要在几个方面接近真实需求：登录和授权不能过于复杂，常见任务应有现成模板，模型输出要能够直接进入现有工作流，遇到不确定内容时要有清晰的人工转接路径。
同时，系统还应允许员工反馈哪些功能不好用，哪些限制阻碍了工作，哪些场景需要增加支持。
安全和效率不应被设计成二选一。一个过于麻烦的安全系统，最终可能把员工推向更不可控的工具；一个只追求便利的系统，则会把风险隐藏在流程之外。
好的正式系统，是让合规路径也成为最方便的路径。
结语
大模型真正进入企业，往往不是从正式发布的项目开始，而是从员工某次临时尝试开始。
他们在工作中寻找更快的方法，建立个人模板，组合不同工具，再把这些方法逐渐嵌入日常流程。企业如果只关注已经批准的系统，就会低估人工智能对组织的真实影响。
最成熟的管理方式，不是幻想所有人工智能使用都能提前审批，也不是对所有非正式使用一律禁止，而是承认员工会探索，并为探索建立边界、记录和转化机制。
企业需要知道哪些工具正在被使用，哪些知识正在流出正式系统，哪些工作标准正在被悄悄改变，以及哪些个人方法值得变成组织能力。
大模型带来的最大变化，可能不是企业部署了多少个智能应用，而是每个员工都拥有了一个可以自行组合的工作系统。
当个人系统开始影响组织结果时，企业真正要做的，不是把它们全部消灭，而是让这些系统逐渐变得可见、可理解、可管理。
