几乎每一场关于企业级AI的讨论，似乎都是从同一个问题开始的：我们应该用哪个模型?

我很理解这是为什么，模型是显而易见的，它们有名字、基准测试报告、更新日志、价格页面和令人印象深刻的演示。在领导层会议上，它们很容易被用来做对比。有的模型承诺具备更强的推理能力;有的模型提供更大的上下文窗口;还有的模型看起来更快、更便宜或更专业。

但在围绕企业级平台、集成层、云迁移、中间件、生产运维和关键业务系统工作了多年之后，我对AI的讨论有了不同的看法。

模型固然重要，但它并不是大多数企业下一步面临的真正瓶颈。

AI的下一个瓶颈，是模型背后的基础设施。

我所指的不仅仅是GPU、云端算力或数据存储，而是指能够让AI在现实世界中安全运行的整个企业级操作系统层：数据管道、身份验证、API、消息传递、可观测性、安全控制、部署自动化、成本治理、可审计性、支持归属以及恢复设计。

这一层决定了AI究竟是仅仅停留在令人兴奋的实验阶段，还是能够转化为可信赖的企业能力。

试点掩盖了最艰难的部分

大多数企业都能做出令人印象深刻的AI试点项目，一个小团队就可以将模型与数据集连接起来，创建一套工作流，并在受控环境中展示出一个效果良好的应用场景。

然而，当试点项目转向真正的生产流程时，艰难的部分才真正开始。

这时，各种实际问题随之浮现：谁来负责数据质量?AI可以访问哪些系统?我们该如何追溯是哪个提示词、策略或检索流程生成了特定的回答?当API变慢、队列积压或下游系统不可用时，该怎么办?

在我看来，这些不是模型的问题，而是基础设施的问题。

这也是许多企业目前正在迈向的方向，AI的第一阶段是探索试验，下一阶段则是业务落地，而这恰恰是真正差距显现的地方。

麦肯锡在关于自主式AI的研究中也提出了类似的观点，指出下一阶段的价值获取，不再那么依赖于孤立的工具，而是更多地取决于围绕智能体重新设计工作流、运营模式和企业执行力。

AI试点可以靠热情支撑，但生产级AI需要架构垫底。

AI正演变为一个集成难题

我越观察企业级AI，就越觉得它像是一个系统集成难题。

在大规模组织中，我曾亲眼目睹消息平台、集成网关、部署管道、监控工具和云基础设施如何决定一个数字能力的成败，AI也不会例外，如果其周围的数据、中间件、身份层和运维控制非常薄弱，即使是最强大的模型也难有用武之地。

AI无法孤立运行，它需要来自核心记录系统的上下文、来自不同业务领域的干净数据、对API的安全访问、事件流、工作流、知识库、监控工具以及遗留系统。

这就是为什么CIO关心的核心问题正在发生改变。

问题不再仅仅是：“我们应该购买哪款AI工具?”

而是逐渐演变成：“我们能否在全公司范围内安全地将智能化落地?”

这正是智能体AI的意义所在，只有当周围的架构能够确保其行为安全、可追溯且有效时，自主AI才能创造真正的价值。

模型可以生成答案，但基础设施决定了该答案是否安全、及时、可解释、合规并能连接到正确的工作流中。

例如，一个用于总结客户或订单信息的AI助手，表面上看是一个模型应用场景;但在底层，它依赖于访问控制、实时数据、可靠的API、日志记录、加密、监控和策略执行。

如果回答错了，人们可能会归咎于模型，但真正的故障根源，可能始于过时的数据、脆弱的集成、糟糕的访问设计、缺失的可观测性或不可靠的下游系统。

因此，CIO不应仅凭模型能力来评估AI，模型周围的企业级系统同样重要。

延迟将演变为信任问题

在传统的技术运维中，延迟通常被视为一项性能指标，但在赋能AI的工作流中，延迟会演变成信任问题。

当员工向AI助手寻求帮助而响应时间过长时，员工就会停止使用它;当面向客户的工作流变慢时，客户就会放弃它;当AI智能体等待多个后端调用时，整个业务流程都会显得不可靠。

随着企业从简单的聊天界面转向智能体工作流，这一点变得尤为重要。单个由AI驱动的操作可能包含身份检查、上下文检索、策略验证、模型推理、API调用、业务规则执行、日志记录和人工审批。

每一个步骤都会增加延迟，每一个依赖项都会增加一个潜在的故障点。

一个模型在基准测试中可能很快，但在企业流程内部却可能很慢，这种差异至关重要。

这就是平台工程变得不可或缺的原因，企业需要针对AI工作负载的可复用模式：经过批准的连接器、安全的检索方法、基于队列的解耦、缓存策略、部署管道、监控仪表盘和标准的回滚程序。

没有这些模式，每一个AI项目都会变成定制化开发。定制化开发可能适用于试点项目，但无法在大规模企业中进行扩展。

可观测性必须拓展

传统的监控只能告诉我们基础设施是否健康：服务器是否正常?CPU利用率是否过高?内存是否耗尽?应用程序是否报错?

AI不仅需要这些，还需要更多。

我们需要知道检索了哪些数据、使用了哪个模型、当前生效的是哪个提示词版本、是哪个用户发起的请求、应用了哪项策略、每个步骤耗时多久，以及输出是否通过了校验。

我们还需要检测新型风险：异常的使用模式、重复失败的工具调用、意料之外的成本激增、敏感数据泄露、检索结果不佳，或者AI工作流试图执行超出其既定边界的操作。

在生产级AI中，可观测性不仅关乎系统可用性，更关乎信心。

如果业务领导者、审计员、监管机构或安全团队询问某个AI系统为什么做出某项建议，答案绝不能是“模型就是这么说的”。企业需要可追溯性，需要证据，需要工程师、风险团队和业务所有者都能理解的运维上下文。

这是我在AI战略中看到的最大短板之一，许多企业正在投资模型和应用场景，但在管理它们所需的控制层上投入不足。

数据准备度仍被低估

AI揭露了一个令人尴尬的事实：许多企业的数据准备程度远没有他们想象的那么高。

数据往往重复分散在各个平台中，每个团队对其描述不一，治理方式缺乏一致性，且更新频率各异。访问规则在一个系统中可能很明确，在另一个系统中却模棱两可。甚至连基础的业务定义，在不同部门之间也可能存在差异。

AI不会自动解决这些问题，在很多情况下，它只会让问题暴露得更加明显。

一份糟糕的报告可能会受到质疑;但一个糟糕的AI回答，听起来却可能足够自信，甚至令人信服。

这才是真正的风险。

针对AI做好数据准备，绝不仅是连接一个向量数据库或给文档做索引那么简单，它需要明确的所有权、数据血缘、分类、质量检查、保留规则、访问边界，以及对“哪些数据应用于何种用途”达成共识。

同样的原则也适用于具备弹性的云原生设计，在我的IEEE TechRxiv论文《Enabling Fault-Tolerant Multicast in Cloud-Native Architectures》中，我曾探讨过当关键工作负载跨越混合云和多云环境时，可靠性、可观测性和容错能力如何成为根本性的要求。

CIO们其实早就明白这一点，因为他们经历过ERP项目、云迁移、集成现代化改造、网络安全转型和数据分析项目的洗礼。经验教训屡见不鲜：技术永远无法彻底脱离数据纪律而野蛮生长。

安全防护绝不能事后补救

随着AI从“回答问题”演变为“采取行动”，安全性变得愈发重要。

一个仅用于总结信息的助手所带来的风险是一回事，而一个能够创建工单、更新记录、触发工作流、批准申请或联系客户的智能体，所带来的风险则是完全不同的另一回事。

AI能做的事情越多，身份识别、授权、最小权限原则、职责分离和人工审批就越发重要。

企业切忌为了加快试点进度而授予AI过大的访问权限，这在开发阶段看似无害，但一旦规模化扩展，就可能演变成巨大的安全隐患。

对AI访问权限的管理，应该像对待企业中任何其他特权功能一样：受限、留痕、受审，且易于撤销。

NIST AI Risk Management Framework(美国国家标准与技术研究院AI风险管理框架)在这里是一个很有价值的参考，因为它将AI风险界定为企业必须持续治理、映射、测量和管理的事项，而非仅在部署末期才去处理的收尾工作。

安全团队应该尽早介入，而不是最后才被通知。目的不是为了拖慢创新速度，而是为了构建一个能够让“安全创新”可持续复用的平台。

CIO必须明确运营模式

AI正在从各个方向带来压力，董事会想要生产力，业务团队想要自动化，员工想要更好的工具，供应商在推销新功能，安全团队在盯紧风险，财务团队在把控成本，而客户则期待更快、更聪明的体验。

CIO恰恰处于所有这些交汇点的核心位置。

这就是为什么CIO的角色不能止步于选择工具或批准试点，CIO必须明确定义AI究竟如何在整个企业中落地运营。

这意味着要回答一系列实际问题：哪些架构得到了批准?哪些数据源值得信赖?AI工作流如何进行部署、监控、支持和治理?成本如何控制?团队如何复用通用模式，而不是每次都从零开始重复造轮子?

这项工作或许不像模型演示那样令人兴奋，但它才是区分“可持续AI”与“短期尝试”的分水岭。

最终胜出的企业，绝不会是拥有最多试点项目的企业，而是拥有最强AI运营层的企业。

他们将构建可复用的平台模式，强化数据治理，设计合理的访问权限，端到端监控AI行为，并以业务成效(而非仅凭模型性能)来衡量成功。

模型依然重要，但模型背后的企业级支撑更为重要。

构建在脆弱基础设施上的强大模型，最终会让业务部门失望;而运行在强大基础设施上的合格模型，却能带来真正的价值，因为它可信、安全、可扩展且能不断迭代。

这正是CIO需要引领的转型。

AI的下一个瓶颈不在于模型本身，而在于模型背后的企业是否真正准备就绪。

企业网D1net(www.d1net.com)：

国内头部to B IT门户，旗下运营国内头部的甲方CIO专家库和智力输出及社交平台-信众智(www.cioall.com)。旗下运营19个IT行业公众号(微信搜索D1net即可关注)。

版权声明：本文为企业网D1Net编译，转载需在文章开头注明出处为：企业网D1Net，如果不注明出处，企业网D1Net将保留追究其法律责任的权利。