简短回答
企业 AI 试点失败的原因在于基础设施而非智能：MIT 的《商业中的 AI 现状》研究发现，95% 的生成式 AI 试点没有产生可衡量的损益影响，而成功的 5% 都部署在自己掌控的基础设施上。在 ibl.ai 上，你拥有全部代码和数据，可以模型无关地运行任何 LLM，并按用量付费而非按席位付费。
差距不在于预算、模型质量或技术人才，而在于 AI 是作为组织拥有的基础设施来构建，还是作为可配置的功能来租用。
这 5% 的组织每投入一美元能赚回 3.70 美元，它们共享四个结构性特征：自有的基础设施、在 AI Agent 之前建成的统一数据层、像角色一样界定范围的 Agent，以及在架构层面而非审查环节落实的安全。
为什么 95% 的企业 AI 试点会失败？
企业 AI 试点按可预测的时间表失败，而这个时间表本身就是诊断结果。几乎所有失败的试点都遵循同样的轨迹：
- 第 1–2 周。 选择一个前沿模型，用干净的样本数据构建概念验证，做一场令人印象深刻的演示。
- 第 3–6 周。 连接生产数据。发现不一致性、访问限制，以及没人界定过的合规要求。
- 第 2–4 个月。 与安全审查、数据治理审批以及早于云计算时代的系统集成苦苦缠斗。
- 第 5 个月起。 试点被悄悄搁置，预算被重新分配，经验教训被“总结”进一份没人看的幻灯片。
注意这份清单里缺少了什么：模型从未表现不佳。第二周的演示早已证明智能是足够的。
之后每一步都败在基础设施上——无法关联的数据、无法表达权限、供应商无法满足的网络边界。
尽管全球已在企业 AI 上投入 300–400 亿美元，绝大多数项目恰恰因为这个原因没有产生可验证的商业价值。
另一个结构性失败是碎片化。大多数组织孤立地部署 AI——HR 一个聊天机器人，IT 服务台一个，客服又一个——每个都是独立系统，没有共享上下文，也无法跨系统执行操作。
什么都无法累积。十个互不连通的助手，价值还不如一个接入实际工作系统的 AI Agent。
那 5% 的组织做对了什么？
从 AI 中获得可衡量损益影响的组织共享四个结构性特征，其中没有一个是关于选择更好的模型。
| 特征 | 那 95% | 那 5% |
|---|---|---|
| 基础设施 | 租用供应商云上的 API 访问 | 自有云、VPC、本地部署或物理隔离 |
| 数据 | 文档上传和暂存环境中的副本 | 一个基于实时记录系统、按角色限定范围的统一接口 |
| AI Agent | 带系统提示词的通用助手 | 有指标和升级路径的界定角色 |
| 安全 | 项目结束时的审查关卡 | 架构中的身份、护栏与隔离 |
以上四项都是在项目启动时做出的架构决策，而非事后购买的能力。正因如此，它们极难事后补加——这也是为什么跳过这些环节的试点，即使到了第四个月换上更强的模型也无法挽救。
拥有基础设施层真的会改变结果吗？
拥有基础设施层会改变结果，因为它消解了上述四个失败点中的三个，而不是仅仅对它们进行管理。这是一个务实的决策，而非意识形态上的选择。
数据治理从政策变为架构。 当 PHI、PII、财务记录和专有数据从不离开你的边界时，合规就成了一种可以证明的网络配置——而不是你必须谈判然后选择信任的合同条款。
切换模型变成一次配置更改。 当你拥有编排层时，从一个 LLM 迁移到另一个只是一项设置，而非一次迁移，因此每一次降价和能力跃升，你都能在发布当周就用上。
成本与员工人数脱钩。 按席位计费会随采用率成倍增长，这意味着你的推广越成功，经济性就越差——向 CFO 描述这种激励结构时，它确实是一种反常的激励。
最后这一点是董事会最容易低估的，所以值得用真实数字来说明。
企业级 AI 按席位计费与自建基础设施相比，成本各是多少？
对于一家 10,000 名员工的公司，按席位计费的 AI 每年花费在 360 万至 720 万美元之间，而且在此之前没有人衡量过这些席位是否真的被使用。同样的工作负载跑在你自己运营的基础设施上，则是一次性部署加上实际消耗的 token 费用。
| 选项 | 每用户/每月 | 10,000 名员工/每年 | 随什么扩展 |
|---|---|---|---|
| ChatGPT Enterprise | 约 $60 | $7,200,000 | 员工人数 |
| Glean | 约 $40 | $4,800,000 | 员工人数 |
| Microsoft 365 Copilot | 约 $30 | $3,600,000 | 员工人数 |
| ibl.ai，自托管 | 约 $0.11 | $12,600 + 一次性部署 | 实际消耗的 token |
推理成本是算术计算，而非承诺，所以下面给出计算过程。假设 10,000 名员工每人每月进行 30 次对话，每次约 4,000 个 token：即每月 12 亿个 token，输入与输出大致按 75/25 分配。
按中档模型每百万输入 token $0.50、每百万输出 token $2.00 的费率计算，即每月 $1,050——每年约 $12,600，或每位员工每月约 11 美分。
在 ibl.ai 上的部署是一次性合作而非订阅：试点起步价为 $15K，完整集成与部署费用为 $25K–$80K，附带完整源代码交付的永久授权则是一笔六位数的一次性费用。
第一年总成本约为 $38K–$93K，而按席位计费则需 $3.6M 或更多。
即使你不认同我对 token 的假设，这个结构性观点依然成立。按席位计费是为员工收费；按用量计费是为工作收费。当用户数超过几百人后，这两条曲线就会分叉，且永远不会重新交汇。
为什么统一数据层必须先于 AI Agent 部署？
统一数据层必须先行，因为企业 AI 最常见的失败点不是模型本身——而是模型无法触及的数据。
企业数据分散在 SIS、CRM、HRIS、ERP、LMS 以及数十个几十年间逐步积累的专用系统中。这些系统在设计之初从未考虑过互操作性，更没有考虑过让 AI Agent 来查询。
那 5% 的企业会投资建设统一层——通常基于 Model Context Protocol 或同等标准构建——通过单一的角色权限范围接口暴露所有系统。无需 ETL 管道，无需重建数据仓库，也无需在预发布环境中存放生产数据的副本。
AI Agent 以其代理对象的完全相同权限查询实时系统。正是这一特性将演示与部署区分开来，因为安全审查真正检验的就是这一点。
这也是投资能够产生复利效应的原因。每个新的 AI Agent 都复用同一个受治理的层，因此第十个 Agent 的成本只是第一个的一小部分——这与催生了那 95% 失败案例的“十个互不连通的聊天机器人”模式恰恰相反。
企业应该如何界定一个 AI Agent 的范围？
界定 AI Agent 的范围要像界定一个招聘岗位那样，而不是像界定一个功能特性那样。功能特性对应的是工单、冲刺和上线；岗位对应的则是职责定义、绩效指标、升级处理流程和定期评审节奏。
这种区别并非修辞手法。一个通用的“公司助手”无法被评估，因为没有人事先就“什么算做得好”达成共识——这正是为什么如此多的试点最终没有得出任何结论。
相比之下，一个提供咨询建议的 Agent 并不是带系统提示词的聊天机器人。它是一个能够访问学生信息系统、了解学位要求，并在置信度较低时按明确定义的升级路径转接人工顾问的系统。
最后这一点比听起来更重要。价值最高的企业 Agent 并不取代人类判断；它们自动处理常规步骤，并将例外情况连同完整上下文转交给相关人员。
其结果是，这个 Agent 的绩效可以用与它所支持岗位相同的标准来衡量——这是唯一能让试点产出一个 CFO 愿意接受的数字的方法。
在企业 AI 部署中，安全应该处于什么位置？
安全应属于基础设施层，而不是项目收尾时才考虑的事项。大多数企业 AI 试点都死在安全审查环节，因为安全审查往往是第一次有人真正检验演示所依赖的那些假设。
那 5% 的企业通过三种方式将安全内嵌其中：
- 受治理的 Agent 身份。 每个 Agent 都拥有自己的身份，具备范围受限的权限、审计追踪和凭证轮换——与人类员工适用同样的治理，理由也相同。
- 输入与输出的防护栏。 每条提示词在到达模型之前都会经过筛查，每条响应在到达用户之前都会经过过滤。这是架构层面的要求，而非可选的后处理。
- 无外部依赖运行的选项。 对于医疗、金融服务、政府和国防领域，隔离部署是采购要求而非功能——无法在断网状态下运行的平台在评测开始之前就会被淘汰。
厂商托管的产品可以承诺这三点。但它无法证明这些承诺，因为证明需要向你展示边界——而边界在别人的网络上。
模型的选择是否不如架构重要？
模型的选择远不如架构重要，因为模型的变化速度比任何企业重新更换平台的速度都要快。仅 2026 年 4 月就在七天内产生了八个重要版本——其中包括 Gemma 4、Qwen 3.6 Plus、Llama 4、Mistral Small 4、gpt-oss 和 GLM-5。
开源权重模型正在缩小与闭源系统的差距，在编程等特定领域，一些模型如今已经超越了闭源系统。
与此同时，经济性也在不断变化：NVIDIA 报告称，在 GB200 NVL72 基础设施上运行 GPT-5.5 级别的工作负载，每百万 token 的成本降低了 35 倍。
被锁定在单一厂商模型上的组织，如果不重建其集成层，就无法获得这些收益。
运行模型无关平台的组织会将每个请求路由到在成本、延迟或能力上最优的模型，并在改进落地的当周就将其收入囊中。
同一时期还有一个部署方面的教训。当 NVIDIA 向工程、法务、市场、财务、人力资源和销售部门的 10,000 多名员工开放 Agent 工具时，它并没有进行试点——而是直接构建基础设施并部署到整个组织。
这就是那 5% 背后的模式：不是“先用小团队测试看看”，而是“先把架构做对，再大规模部署”。你选择的模型是暂时的，而你在其上构建的层不是。
企业应该首先构建什么？
构建其他一切都依赖的层，按以下顺序：
- 受治理的数据层，通过 MCP 或等效协议连接你的记录系统，并在任何 Agent 存在之前就解决好基于角色的权限。
- 面向特定领域的 Agent，为明确的工作流而设计——采购、入职、咨询、升级——每个 Agent 都有定义好的输入、输出和指标。
- 模型无关性，使切换或混合模型成为一次配置更改，而不是一个重新更换平台的项目。
- 架构层面的安全性 — Agent 身份、输入与输出防护机制，以及在监管机构要求时完全离线运行的能力。
这些都不是什么高级能力。它们是第一周就要做出的决定，而这些决定将决定第五个月你得到的是一个部署成果，还是一份幻灯片。
企业 AI 的悖论在于：组织希望借助 AI 实现差异化，却从同样的供应商、在同样的云平台上，租用与所有竞争对手相同的智能。同样的模型、同样的 API、同样的基础设施——因此毫无差异化可言。
那 5% 的组织做出了另一种选择。他们拥有自己的技术栈，掌控数据管道，在更好的模型出现时随时切换，并按照自己的条件进行部署。
前沿模型本身非常出色；真正的问题从来不是 AI 是否有效，而是你的组织是否具备相应的基础设施，让 AI 为你服务，而不是为你的供应商服务。
ibl.ai 是一个 Agentic AI 操作系统，组织可以将其部署在自己的基础设施上——你拥有全部代码和数据。它可以在任何云平台、本地环境或完全物理隔离的环境中运行任何 LLM，提供 160+ 个 Agent 模板，服务 400+ 个组织的 160 万+ 用户，其中包括 NVIDIA、MIT 和 Syracuse University。ibl.ai 是一家位于纽约州纽约市的家族企业。