导言

几个月前,一位首席信息官向我展示了他的Claude Enterprise仪表盘。该系统拥有2000个用户席位,在六周内完成部署,通过企业身份提供商实现单点登录,其使用政策已获法务部门批准,且每位员工在首次登录时均已确认知悉。随后,他滑动到了第二个标签页。. 每周活跃用户:14%。.

最常见的提示是:“总结这封邮件。”第二常见的提示是:“用更专业的语气重写这段内容。” 与ERP、data仓库或文档存储库均无任何连接. 生产部门连一个代理都没有。在我们楼下三层,应付账款团队正在逐一打开供应商发来的PDF文件,核对发票号、金额和成本中心,然后手动将这些信息录入财务系统——大约需要 每月一百张发票,大约需要一个人花一天半的时间来处理。.

我已经不再对此感到惊讶了。我现在认为,这正是企业采购人工智能时的默认结果,而我想直截了当地说明原因。.

我们一致决定将前沿模型视为软件来对待:购买许可证、分配用户席位、举办网络研讨会,然后继续推进。这种做法在电子邮件和客户关系管理(CRM)领域行之有效,因为这些工具的价值就蕴含在工具本身之中——收件箱就是产品,销售 pipeline 视图就是产品。. 前沿模型的价值并不在于模型本身,而在于该模型与某家特定公司的data、权限、习惯和流程之间的差距。:该模型能否查看上个季度的各SKU销售额,是否知道该公司中的“净收入”不包括贸易支出,以及销售总监是否曾有一次在当周需要解答的实际问题中使用过它。.

该组织中没有人是受雇来弥合这一差距的。. IT部门负责管理租户并衡量系统正常运行时间。业务部门负责管理用例,但不进行任何衡量。供应商负责制定路线图并统计用户数量。两者之间的空白地带归谁所有?而 那个空间正是价值所在.

在经历了一年时间,总是在“14%”的时机入场投资各家公司之后,我深信: 这一领域本身就是一门学科. 这既不是靠更精美的幻灯片来推进的变更管理,也不是通过新API实现的系统集成。这是工程、data、安全与推广工作在客户内部协同开展的成果,由那些同样参与实验室路线图制定、并对结果而非交付物负责的人员共同完成。 我称之为“部署层”,本文将阐述为何它比下一个模型版本的发布更为重要。.

为何企业人工智能在签署许可协议后陷入停滞

无论是在银行业、消费品行业、房地产行业还是电信行业,这种模式都如出一辙,且遵循着一个可识别的流程:试点项目取得成功——一个由市场营销或客户服务部门组成的小团队,一位支持该项目的赞助人,一个清晰的应用场景,以及一场让执行委员会成员们都屏息凝神的演示。 第二个试点在另一个职能部门取得成功。领导层批准了企业级推广,通常会设定诸如“第二季度前实现AI普惠”这样的目标。推广随之展开。. 由于新鲜感,采用率连续三周上升,随后在“更强大的搜索引擎”这一水平上趋于平稳, ,而本应随发布进程推进的代理程序仍停留在名为“第二阶段”的幻灯片上。”

通常的解释是错误的。.

  • 并不是说员工抵制变革;; 我遇到的人都迫切希望这个工具能帮助他们处理实际工作,却又因为它无法识别他们正在查看的电子表格而感到沮丧。.
  • 并不是说这些模型不够成熟;; 早在两代人之前,他们就已经能够做到其中大部分内容,而克劳德或GPT所能做到的与组织对他们的要求之间的差距,自那时以来只会越来越大。.
  • 而且这并不是因为缺乏用例。. 我主持的每场研讨会,上午就能收到八十条这样的反馈,其中一半都是“别再让我重新输入这个了”的各种变体。”

它会卡住,因为有三个问题没有负责人:

  • 模型对我们了解多少? 它能访问哪些系统——仓库系统、文档存储系统、票务系统还是人力资源平台?它是以谁的权限访问这些系统的:服务账户的,还是提出请求者的?当它返回一个编号时,是否有人能追溯到该编号对应的表或文档?
  • 各部门中,谁负责推广工作? 这并非为了统计许可证数量——而是为了培养一种习惯:在周一早晨,销售、财务、法务和运营等部门将该工具应用于实际工作。这些部门各自拥有不同的“data”指标、不同的术语体系,以及对“有用”这一概念的不同定义。”
  • 谁来开发这些代理程序?当顾问离开后,又由谁来维护它们? 是已经积压了十八个月的IT待办事项,还是签订了“工时和材料”合同的外部供应商,抑或是那些身处业务一线、了解正在实现自动化的流程的员工?

我尚未见过哪个项目在由指导委员会来回答这些问题的情况下取得成功。这些问题的答案是 由实际从事该工作的人员,在办公场所内,且拥有决策权。.

部署层:那项无人列入预算的能力

在模型与业务之间,存在一层既非纯粹的IT工作,也非纯粹的变更管理工作。我将其分为四个部分,并对每个部分都有自己强烈的看法。.

部署。. 该平台本身——包括Claude Enterprise、Claude Code和Cowork,或是ChatGPT Enterprise和Codex——已顺利上线。实际上,这意味着采用了一种根据角色、领域和职级分配席位的许可模式,而非先到先得;通过企业单点登录(SSO)进行身份认证,并支持基于群组的访问权限; 一套使用政策,以通俗易懂的语言明确规定哪些内容可以粘贴、哪些不可粘贴;一份最佳实践指南,说明何为良好使用范例;以及成本治理机制,从第一周起就能按部门显示谁在使用什么。. 这是大多数组织做得还算不错的部分,但仅就这一部分而言,其价值最低。. 一个配置完美但没有任何连接的租户,无异于一个极其昂贵的聊天窗口。.

地面。. 使模型能够根据公司自身的“真相”给出答案的上下文层。具体来说:一个 单个 MCP 服务器, ,该系统运行在客户自己的 cloud 租户中,通过一个受管控的入口,将结构化的 data (Fabric 或 Snowflake 中的销售表、预算表、KPI 数据集市)以及非结构化存储库(SharePoint 或 Drive 中的合同、政策、董事会演示文稿和流程)通过一个受管控的入口进行访问。 在此之上,还设有一层业务知识层:官方术语表、财务部门制定的KPI定义、业务规则(“季度结账日为25日”, “净销售额中不包含公司间交易”),以及每份文档的语义描述,从而使模型能够准确定位正确文件并完整读取内容,而非仅根据片段进行推测。访问权限与每位员工现有的权限设置完全一致,因此模型仅向您展示您本人原本即可访问的内容。. 而且每个答案都附有引用信息:表格、行过滤器、文档、页面。. 我认为,企业人工智能的成败就在于此,而这正是几乎所有人都会跳过的一环,因为它看起来就像是管道工程一样枯燥。没有它,模型就像一个才华横溢的陌生人;有了它,模型就成了一个通读一切且能证明这一点的同事。.

领养。. 按部门分批进行培训,, 在 data 生产环境中。. 我已经对那种充斥着范例邮件和虚构公司的千篇一律的“提示技巧大师班”产生了抵触情绪:它只会引发一周的好奇,随后便是沉寂。真正有效的培训环节则截然不同。销售部门会花两个半小时讨论上季度的一个真实问题。 财务部门核对一份真实的月末对账文件;人力资源部门重新编制一份真实的缺勤报告;法务部门对照公司内部操作手册,审查一份真实的保密协议。每位参与者离开时,都会带走一个包含本部门规则的“克劳德项目”,以及一份周一就能再次打开并投入使用的实际工作成果。. 区别不在于教学方法。而在于在对任何人进行培训之前,该模型是否已经过充分验证。.

构建。. 生产代理程序,由工程师与客户团队并肩协作,基于客户维护的框架,通过短周期迭代开发而成。 那些看似不起眼的工作——将供应商发票数据导入数据模型并标记未匹配的行项、根据 Teams 会议记录起草会议纪要和行动项、对照公司内部指南核查保密协议并总结责任与终止条款、从一堆 PDF 文件中提取数据填入承保模板——正是耗费大量时间的地方,, 而这正是大多数代理项目永远无法达到的境界,因为它们一开始就追求令人印象深刻的效果,而不是真正有用的东西。.

这四点构成一个体系,而不是一个菜单,而且我想进一步说明: 只做其中一项而忽略其他几项,往往比什么都不做还要糟糕。. 没有基础培训的训练会让人们认为工具会“产生幻觉”,而他们确实有道理。没有培训的部署则会建起一座无人问津的大教堂。缺乏平台的代理程序只会产生十几套彼此孤立、缺乏共同治理的自动化流程,而安全团队最终理所当然地会将其关闭。.

我反复思考的这套算术很简单:

价值 = 模型 × 部署层。.

该模型是一个非常大的数值。. 乘以零,结果就是零。. 实验室的每次发布都会使第一个因素变得更大,而第二个因素则变得更为关键。.

对于那些希望花钱解决问题的公司来说,这里有一个令人不快的事实:部署层无法作为软件购买。实验室出售的是模型和平台,而他们只做到这一步是正确的。 具体背景、权限设置、部门层面的工作习惯以及首批实施人员,都与每家公司的“data”架构及其内部政治密切相关——例如,对客户而言哪个系统是“权威数据源”,谁有权查看各产品的毛利率,以及财务团队实际如何完成月度结账工作。. 它们必须建在该大楼内, ,这需要由既了解该模型的路线图,又熟悉客户系统的人员来完成。这没有捷径可走,对于那些兜售捷径的人,我持怀疑态度。.

示例——谁来回答销售问题?

试想一下,一位商业总监在周一早上可能会提出这样一个简单的问题:“上个季度,Skala的业绩与去年同期相比表现如何?我们在哪些方面失去了市场份额?”

在 博拉·巴西, 由 Skala Brasil 和 Lola From Rio 合并而成的护发集团,这个问题过去总是辗转流转。从总监到分析师,从分析师到商业智能(BI)数据提取,从数据提取到电子表格,从电子表格到演示文稿,三天后又回到总监手中——而此时,后续问题已经发生了变化。 与此同时,已有十五位早期用户正在非正式地使用Claude,将其与自己的电子邮件、日历、Teams和文件连接起来,获得看似合理的答案——这些答案的来源无人能追溯,而且有时使用的“分享”定义在财务部门里根本无人认可。.

领导力的三个要求恰好就是上述的三个问题: 基于该组织自身data框架的解决方案、尊重现有权限的访问方式,以及受管控的环境 从而阻止敏感商业信息流向未经授权的工具。这就是从内部视角看“14%”时刻。.

这九周里发生变化的并非该模式本身。有三条主线并行推进:自下而上的采用主线、自上而下的路线图主线以及治理主线。.

  • 所完成的工程工作 基于 Azure 的上下文平台, ,该方案已获得该团队技术领导层的批准,通过单台 MCP 服务器公开了 Microsoft Fabric(销售、关键绩效指标、预算)和 SharePoint(合同、政策、演示文稿)中的数据。.
  • 业务知识层包含术语表、KPI 定义和业务规则,并为每份文档提供语义描述,以便 Claude 能够定位并阅读完整的文件。.
  • Access 会反映每位员工现有的权限,并且 每个图表都注明了其来源表格或文件.

与此同时,通过对商务、市场营销、创新与研发、运营、财务及人力资源部门负责人的访谈,共筛选出83个机会,根据商业价值和技术复杂度进行评分后,将范围缩小至24个,随后在一次领导力研讨会上,, 将第一年路线图的数量定为五项。.

随后——也只有到那时——才针对这一具体的销售问题展开培训。在长达150分钟的培训环节中,每位参与者都创建了一个包含业务规则的Claude项目,从SharePoint中提取了KPI定义,在向Fabric运行查询前进行了规划,构建了一个可共享的交互式销售仪表盘,并核对了每个数据的来源。 动作较快的学员甚至在培训结束前,就已将该仪表盘设置为 Cowork 中的每周定时任务。由 Claude 构建的培训师指南,则一步步追踪了每位参与者的进度。.

目前有62名员工在岗,未来将扩充至150人, ,许可证按角色和区域分配,设有中央人工智能办公室,每个业务领域都配备一名负责人。前三十名许可证持有者报告称 平均每周至少节省四小时; 七成员工每天节省三小时或更长时间。一次人力资源薪资系统data数据迁移 实际耗时90分钟,而非外部报价的40个顾问工时. 一份过去需要花费八小时人工核对的考勤报告,现在已按计划自动生成。.

我讲这个故事,并不是因为这些数字很大——这些数据尚处于初期阶段,且是自我报告的——而是因为 顺序就是教训. 先打好基础。在已打好基础的事物上进行训练。将这种习惯传授给留下来的人。如果顺序颠倒,就会变成一场网络研讨会。.

前沿部署行动模式

如果部署层是由人来构建的,而不是作为产品购买的,那么问题就变成了:由哪些人来构建,以及如何组织这些人。我的答案有意借鉴了实验室自身与最大客户合作的方式,而这正是大多数咨询公司——包括直到最近的我们公司——在组织架构上无法给出的答案: 小型团队、嵌入式运作、对结果负责 而不是一项交付成果。有三个动词可以描述它。.

嵌入

将一个 一名前沿部署的战略家与一名前沿部署的工程师 并将两者在整个项目期间都置于客户方,在条件允许的情况下应尽可能在物理上置于客户方。战略师负责业务成果和运营模式:确定哪些流程、哪些部门优先推进,八十个用例中哪些应纳入第一年路线图,AI办公室的人员配置方案,以及如何衡量价值并向执行委员会汇报。 工程师负责平台、上下文层和代理:MCP服务器及其连接器、权限模型、代理框架,以及与客户现有系统的集成。 在典型的一周中,战略师上午在财务总监的办公室工作,工程师下午则与客户的data团队进行配对协作,两人都会参加同一个站立会议。两人都不依赖幻灯片演示,也不允许将建议书作为交付成果留给客户。. 可交付成果就是能正常运行的东西。.

我深信,合作关系比资历更重要。战略师单打独斗,只会制定出一份等待IT部门落实的路线图;工程师单打独斗,只会打造出一个等待业务部门接手的平台。而当他们携手合作时,便会形成一种“周一早晨”的惯例。.

火车

系统采用分部门推进的方式,在正式运行的data系统上进行,且采用移交而非交付的方式。有三项职责确保其有效落实。.

  • AI 冠军 在每个业务领域,由出于好奇心而非职位而选出的成员,他们每周安排办公时间,收集大家无法通过工具解答的问题,并将后续的使用场景反馈给团队。.
  • 人工智能办公室 该中心设有四个职能部门:领导与治理部门,负责管理项目组合和许可证;负责开发的工作组;负责运维上下文层、安全及核心工具的平台团队;以及与人力资源部门协作、负责培训和变革推广的推广部门。.
  • 此外,对于工程团队来说,, 在 Claude Code 和 Codex 上的启用 — 黑客马拉松、办公时间、一个负责访问权限和成本的治理工作流 — 以每位开发者每天的参与次数为计量单位,而非按席位计算。.

我采用的检验标准很简单:如果前置部署团队明天突然消失,使用量还会继续上升吗?如果不会,那就说明该方案尚未被真正采用。.

构建

特工们抵达 为期两周的冲刺. 第一天将举办一场由流程负责人主持的“如何构建智能代理”实践工作坊,这样到午餐时间,应付账款专员就能看到发票如何被转换为结构化字段,并清楚了解智能代理能做什么、不能做什么。 冲刺期的剩余时间将用于基于真实文档进行开发、测试和迭代,并在最后一天向业务部门进行演示。.

每位代理离开时都会带走 一个可重用的框架 — 在微软的解决方案中,通常采用 Power Automate 流程来导入文档,并根据数据结构和参考资料调用 Claude API,最终生成一份结构化的文件供人工审核 — 此外还包括提示模板、短视频、指定的业务负责人、一名测试用户以及一名全程跟进该构建过程的维护人员。.

成功的标准并不在于我们发货的这四名代理。. 这是客户在没有我们参与的情况下随后开发的第20个项目。. 如果该数值为零,说明我们建立的是依赖关系,而不是能力。.

贯穿这三者的核心是与实验室的关系。我认为,只有当构建部署层的人员能够预见未来六个月的路线图,在连接器出现异常时能直接向实验室的解决方案团队上报问题,并且能让实验室的工程师与客户的高管及开发人员共处一室时,部署层才能真正发挥作用。 这种紧密联系绝非商业上的客套。正是它使得部署团队能够在MCP、Skills、Cowork或Codex发布当月就将其整合进来,而不是等到一年之后。.

没有它的话,会出什么问题呢?

试想一下,十八个月后,这位首席信息官已经续订了许可证,但跳过了部署层。许可证数量已增至三千个;; 活跃用户率没有变化. 那些渴望更多自主权的员工已悄然将实际工作转移到个人账户上,如今公司的合同草案、客户名单和明年的预测都存放在聊天记录中——这些记录既无人监管,也无人能删除。 三个部门各自采购了一套独立的点解决方案,每套系统都有自己的嵌入式模型、连接器和权限设置——一套用于合同审核,一套用于客户服务,一套用于采购——这些系统对“客户”或“利润率”的定义各不相同,如今每套系统都需要单独进行安全审查。.

有几位爱好者利用无代码工具,仅用一个周末就自行构建了代理程序。其中一些效果不错。但这些程序均无所有者、测试用户或日志记录,其中一个甚至一直在使用去年的银行账户信息向供应商发送付款提醒。 安全团队被紧急召来,面对着一个并非由他们设计的系统架构,只能采取唯一可行的应对措施:全面锁定系统。这导致这些爱好者只能退回个人账户,而整个组织也只能回到起点。.

该实验室的客户服务团队发现某位客户的使用量停滞不前,既没有可参考的案例,也没有可沟通的技术对接人,于是将有限的解决方案工程师资源分配给了其他客户。. 该组织已支付了“Frontier”的费用,并收到了一款聊天机器人。.

我想在此明确指责的对象,因为责任往往被归咎错了。这一切都不是技术上的失误,其中极少部分是员工的责任。. 这是将某种能力视为采购项目,且无人对“许可”与“习惯”之间的差距负责所导致的可预见结果。.

我们决定对此采取什么措施

最后,我想谈谈这一信念在实践中意味着什么,因为如果一种观点无法改变你的组织方式,那它也就只是空谈罢了。.

在 Artefact,我们不再将部署视为战略合作中的最后一个阶段,而是将其打造为一个拥有独立团队的专项领域。我们称之为 DeployCo:前线部署的工程师和战略专家,其唯一职责是负责部署层,与Anthropic和OpenAI合作,按实验室和地区划分,覆盖欧洲、中东和非洲,每个地区每个实验室均设有一名业务负责人和一名技术负责人。. 我们的目标是到2027年将数量增加到100个。. 这确实是一个赌注,而我敢公开这么说,是因为我认为另一种做法——只负责销售策略,而把基础工作留给别人——正是导致该行业陷入14%困境的原因。.

这一赌注基于我坚定不移的几个立场:

  • 那个 打好基础是训练的前提, ,始终如此,而如果培训课程中没有客户自己的“data”,那不过是场表演罢了。.
  • 那个 没有指定所有者的代理 而且,维护者无论多么聪明,都是一种负担,而非资产。.
  • 那就是 客户团队必须在一个季度内超越我们的建设进度, ,否则我们就失败了。.
  • 而且,从事这项工作的人员需要坐在离实验室足够近的地方,以便了解即将出现的新动向,这就是为什么我们会花时间与他们共处一室——仅在10月,我们在慕尼黑、 苏黎世和卡萨布兰卡,客户高管及其开发团队坐在一侧,Anthropic和OpenAI团队坐在另一侧,我们共同探讨实际部署方案,而不是听主题演讲。.

钱塞里门, ,这是一家位于伦敦的工业地产开发商和资产管理公司,拥有约700家租户以及一些 管理资产规模达12亿英镑, ,这是我手头最能证明第三种观点成立的证据。 春季研讨会揭露了后勤部门一如既往的低效:每月有上百张供应商发票需要手动重新录入,每次大型会议的纪要都需要花一个半小时来核验,保密协议(NDA)的审查中风险条款的覆盖范围不一致,承保模型则是通过从PDF文件中抄录数据构建而成的。.

在一篇 为期两周的冲刺 在他们的微软环境中,一个联合团队交付了四个 由Claude驱动的智能代理 针对的正是这四个问题:

  • 应付账款 (80% 每张发票处理时间减少,90% 以上的明细行已自动匹配),,
  • 《NDA》书评 (从三天缩短至不到两小时),,
  • 承保初始化 (25小时至不足3小时)
  • 和 会议纪要 (一个半小时到三十分钟)。.

每个代理都分配了一名所有者、一名测试用户和一名维护人员。此后,他们自己的团队——约有25名受过培训的人员,其中约10人每天使用这些代理——又开发了二十多个新的代理,每个代理的开发时间均不到半天,目前正在将AP代理直接接入NetSuite,并将NDA代理接入DocuSign。.

“Artefact团队表现非常出色,”他们的财务规划与分析(FP&A)负责人菲尔·普赖斯表示,“他们为我们奠定了良好的基础,让我们能够继续自主发展和扩张。”这句话的前半部分说得挺客气。. 关键在于下半场。.

边疆已不再是理想。它是理想与你周一早晨之间的距离。. 如果您持有Claude或ChatGPT的许可证,却仍无法回答本文中的三个问题——该模型对您的了解程度、各部门中谁负责推广应用,以及谁负责构建和维护您的智能代理——那么您目前还未具备人工智能能力。 你拥有的只是一份订阅服务。好消息是,只要有人决心将弥合这一差距作为自己的职责,这一差距可以在数周内而非数年内被弥合。.

我很乐意听听您在哪些方面持不同意见: remi.sabonnadiere@artefact.com