去年下半年，一家制造企业的信息部门负责人找到我们，说他最近被业务部门的人"投诉"了。投诉的原因不是系统出了 bug，也不是项目延期，而是他"不让用 AI"。

事情的起因是：业务部门的采购主管在手机上用豆包帮他分析了一份供应商报价，感觉效果不错，就想把公司内部的 ERP 数据接进去，让它直接生成补货建议。这个想法他在部门群里说了一下，下面的人立刻热情高涨。信息部门得知后，第一反应是叫停。采购主管觉得信息部门在阻碍创新，信息部门觉得自己是在保护数据安全。两边都觉得自己是对的。

这个场景在过去两年里反复出现。AI 没有成为 IT 和业务之间的润滑剂，反而制造了一个新的摩擦点。

业务部门看到了什么

站在业务侧，他们看到的景象确实很有说服力。

豆包、Kimi、DeepSeek——这些产品能写报告、总结会议纪要、分析竞品，而且免费或极低价格就能用到。其中不少产品已经支持上传文件、调用外部数据。用过 Claude 或 GPT-4 的人可能还见识过它能直接写 Python 脚本操作数据集，输出几十行 pandas 代码，还能解释每一步在做什么。对于从未编过程的业务人员，这种体验是颠覆性的。原来需要找 IT 排期、等上两周才能跑出来的数据分析，现在自己上传个 Excel，三分钟就能看到结果。

于是，顺理成章的想法出现了：如果我能把公司的系统数据也喂给它，会怎么样？这个想法的逻辑是通顺的，问题出在实现路径上。

IT 部门的担忧不是在装

信息部门叫停这类需求，通常被业务侧解读为"守旧"或"不配合"，但实际情况要复杂得多。

• 权限边界消失了。 一个普通业务员登录 ERP，他能看到的数据范围是经过权限配置的。但如果他把数据导出给 AI 工具，权限控制就断掉了。他能导出什么数据，完全取决于他有没有想到要导出——这是一个基于人的主观意识的控制，而不是系统级的控制。
• 没有审计记录。 企业出于合规和风险管理的需要，通常要求关键数据操作留有记录：谁在什么时间查了什么数据，做了什么操作。第三方 AI 工具的交互完全在企业系统之外，形成了一个审计盲区。
• 结果质量无法验证。 AI 生成的补货建议，依据是什么？用的是哪几个月的数据？有没有把下架商品过滤掉？如果这份建议直接驱动了采购决策，出了问题，谁来负责？

信息部门提出这些顾虑，是本职工作，不是故意制造障碍。

但"退回 Workflow"也不是完整答案

面对这种矛盾，业界常见的一个应对方式是：把 AI 嵌入预定义的工作流里，严格管控它能做什么、不能做什么。比如，给采购分析做一个固定流程：拉数据 → 调 LLM 分析 → 格式化输出，中间每一步都写死，AI 只在特定节点被调用，相当于一个带回调函数的处理步骤。这个方案确实能解决上面提到的大部分安全顾虑。数据不出边界，操作有日志，结果可验证。

但它带来了另一个问题：这种 AI 失去了自主性。

采购主管觉得 AI 有价值，很大程度上是因为他不需要提前告诉 AI 该怎么分析。AI 会自己判断要看哪些数据、用什么逻辑。一旦把这个过程固化成 Workflow，实际上是人替 AI 做了所有的推理，AI 只是执行最后一步。这对已知的、重复性的场景是够用的，但它不支持"我有一个新想法，能不能帮我验证一下"这类临时性需求。而业务部门最需要的，恰恰是处理这类他们自己都没想清楚的问题。于是矛盾退化成了另一种形式：要么安全但死板，要么灵活但危险。

矛盾的根源：AI 的行为对企业来说是不透明的

把这两方的冲突拆开看，核心问题不是"要不要用 AI"，而是企业对 AI 行为缺乏治理能力。

人类员工进入企业，有一套完整的治理体系：账号权限管理、操作日志、审批流程、职责边界。一个仓库管理员登录 WMS，系统知道他是谁，他只能操作授权范围内的数据，所有操作都有记录。那么，AI 以什么身份进入企业系统？它调用了哪些接口，用了哪些参数，返回了什么，有没有遵守业务规则——目前大多数方案对这些问题的回答是：不知道，或者不完整。

用一个例子来说明：假设 AI 在执行一个任务时，依次调用了接口 A 和接口 B。调用 A 成功了，但当前用户没有接口 B 的权限。这时候应该发生什么？在一个有治理能力的系统里，答案应该是记录这次越权尝试，终止流程，通知管理员。但如果 AI 直接调用外部服务或通过无约束的 API 操作业务系统，这整个环节会直接消失。要么调用失败报了一个模糊的错误，甚至自己假想了一份接口 B 返回的数据继续生成答案；要么试图绕过权限限制继续执行。业务部门看不到这个风险，因为他们只看到了最终结果；IT 部门能感受到这个风险，但没有好的工具来管理它，于是只能选择叫停。

这个矛盾的出路在哪里

矛盾之所以存在，是因为两边的诉求其实并不对立，只是缺少一个能同时满足两者的方案。

• 业务部门要的是 AI 能自主完成复杂任务，不用提前把每一步都写死。
• IT 部门要的是 AI 的每一步操作都在可控范围内，权限清晰，行为可审计。

这两个诉求不是非此即彼的。它们的矛盾是工程问题，不是原则问题。所以，解决思路应该是在 AI 和业务系统之间加一层结构化的语义约束，告诉 AI 这个系统里有哪些概念、可以做哪些操作、每个操作的边界是什么，同时在执行层复用企业现有的权限体系，让 AI 调用系统的方式和人类用户本质上是一样的。有权限就能做，没权限就被拦截，所有操作都留有记录。这不是在限制 AI 的能力，而是给 AI 的能力套上企业已有的治理框架。就像一个新员工入职，他的聪明程度是他自己的事，但他能接触哪些系统、能执行哪些操作，由公司的权限体系决定，而不是由他的聪明程度决定。

当然，这个思路在技术上如何落地，是另一个话题。但能不能走到这一步，有一个前提条件，那就是 IT 部门和业务部门首先得意识到，他们的目标并不冲突。信息部门叫停业务部门的 AI 尝试，有时候是对的，有时候其实是在用一个过时的反应框架应对一个新问题。业务部门推动 AI 落地，有时候是在创造真实价值，有时候只是在转移风险，把本来应该系统承担的管控责任甩给了个人的自律。两边都需要升级认知的框架，然后才能谈怎么合作。