然而，AI引入了一个新变量，正迫使哪怕是最坚定的企业软件客户也不得不重新审视自己的选择，AI是一个贯穿于你的数据、流程和决策之上的架构层，这一层在哪里运行、由谁控制，是一个架构问题，但大多数企业界目前仍将其视为一个采购问题。
厂商嵌入式AI的吸引力是显而易见的：自动化运营决策、更智能的供应商与商品企划选择，以及内置于企业现有依赖系统中的无摩擦工作流，但问题在于，这些功能几乎普遍依赖于你的数据留存在厂商的云环境中，而对大多数大型企业而言，数据要么存在于本地，要么存在于它们自己管理的超大规模云基础设施中，抑或存在于私有数据中心内。你的数据所在地与厂商AI所假设的数据所在地之间的这一差距，制造了一条根本性的战略分叉路口。
“构建还是购买”是一个分类错误
我一直听到的说法是“构建还是购买你的AI战略”，这暗含着有些企业正在从头开始训练基础模型，没有哪个严肃的机构会这样做。真正的选择横跨三种不同的路径，将它们混为一谈会导致错误的决策：
购买嵌入式：直接使用厂商在其平台内原生提供的AI功能：比如嵌入在你的ERP、CRM或HCM套件中的助手，其集成成本最低、见效最快、与应用数据的契合度也最高。
购买平台：采用厂商的AI基础设施层，并在其上构建自己的助手和智能体，这种方式更具灵活性，但你仍受限于厂商的架构边界，并受制于其治理模型。
组合构建：将第三方模型(如Claude、GPT、Gemini，或在自身环境中运行的开源权重模型)直接连接到你现有的IT景观中，这能带来最大的控制权，但集成负担也最大，同时你必须对最终输出的结果负全部责任。
这些并不是价格不同但功能等效的选项，它们对你的数据存放在哪里、由谁治理AI，以及为了实现目标需要消化多少架构变更，做出了截然不同的假设。厂商的营销说辞有时会故意模糊这种区别，但企业领导者承担不起这种模糊的代价。
厂商AI技术栈内置了一个假设
每一种嵌入式AI功能都自带一个未明说的架构前提：你的数据必须位于AI能看到的地方，符合它预期的形态，并在厂商强制执行的治理之下。
对于拥有干净、现代云资产的企业来说，这通常是一个合理的权衡，但对于那些在私有或混合基础设施上运行着高度定制化环境的大量长尾大型企业而言，这种权衡就变成了一个先决条件——一个在开启AI对话之前必须满足的条件。满足这一条件是否有意义，取决于你的起步状态、你所在行业的监管态势，以及你对迁移风险的承受能力，这些因素在不同组织之间绝非千篇一律。
这正是厂商主题演讲中被粉饰过去的部分，舞台上的AI演示假设了一个观众尚未真正实现的终点架构，如今的大型企业客户正承受着异常沉重的技术负担。许多企业在面临迁移到厂商管理的云基础设施的压力同时，还在同步推进已开展十多年的平台现代化项目，而凌驾于这两者之上的，是来自董事会层面要求快速看到切实AI进展的指令。厂商的AI路径与董事会的AI路径可能会产生巨大分歧，企业需要有选择性地做出战略决策，确定优先在哪里采用AI，以实现价值最大化并最小化风险。
主权不是口号，而是架构约束
关于主权的讨论已经被对立的双方绑架了，一方将每一次SaaS的采用都视为对主权的侵犯，另一方则将每一次对主权的担忧贬低为卢德主义式的盲目抗拒，这两种观点都毫无益处。
在真正的客户对话中——尤其是在德语区、公共部门和金融服务领域——发生的情况要具体得多。企业正在将“在厂商的云中运行应用”(这大体上没问题，容易理解，且有数十年的先例)与“在厂商的AI模型中丰富自身的数据和流程”(这缺乏先例，更难逆转，且对竞争地位有着实质性影响)明确区分开来。
在厂商的AI模型中丰富你的数据，是一个真正意义上的新问题，而将此问题与现有云态势混为一谈的企业，往往会守错防线。
尽管迪士尼每年在亚马逊上的支出约为1亿美元，但它依然构建了自己的内部AI系统来承载其企业智能，而不是依赖超大规模云厂商的AI产品，这一决策最终归结为控制权。当你的数据代表着数十年的创意和商业知识产权时，你会非常仔细地考虑它存放在哪里，以及谁能从中进行学习。随着时间的推移，迪士尼对SaaS变得更加开放，但AI主权问题是一个独立于SaaS辩论的课题，将两者混淆会导致组织得出错误的结论。
在光谱的另一端，处于严格监管环境中的企业将数据主权视为绝对不可谈判的底线。任何AI模型都必须在其受控的环境内运行，尤其是在敏感数据绝不能触碰公共互联网的情况下。GDPR义务进一步强化了整个欧洲市场的这一本能，要求组织对个人数据在AI系统(包括厂商管理的系统)内部如何被处理保持清晰的问责制。
经过AI丰富的数据——意味着已经学习了你的业务流程形态、供应商谈判以及客户行为的模型——与底层的运营数据相比，具有不同的半衰期和不同的战略价值，这值得拥有其独立的架构决策，并与你更广泛的云战略区分开来。
这在实践中意味着什么
大多数大型企业的IT资产最终会融合这三种路径，而你在哪里划定界限，比你整体的宏观姿态更为重要。
对于应用内的生产力提升，嵌入式AI功能是正确的答案：比如ERP工作流中的助手，或者采购及人力资源套件中的智能体，这正是厂商嵌入真正大放异彩的地方，试图自己去组合构建一个同等功能的系统通常是对工程资源的无谓浪费。
组合构建则属于其他领域：跨应用编排、针对运营和可观测性数据的自定义助手，以及需要跨越多个厂商系统和基础设施层的智能体——而这是任何单一厂商技术栈都永远无法原生支持的。麦肯锡的研究表明，企业AI带来的最显着的近期生产力提升将恰恰来自这些跨系统的工作流，而非来自单个应用内部。未来18个月里最令人兴奋的企业AI工作正存在于此，而且它不需要你先等待迁移完成。
当然，组合构建的道路并非免费，诚实面对成本至关重要。幻觉输出的治理、审计追踪和问责归属将成为你自己的问题，而不是厂商的问题。提示词漂移和评估纪律是真正的工程成本，它们绝不会出现在概念验证中，这些成本会随着你IT景观的复杂性以及智能体所触达的系统数量而呈规模化增长。请在部署前为其做好预算，而不是在发生第一起生产环境事故之后。这一切都不是避开这条路径的理由，而是要求我们必须为此诚实地配置人员。
真正的问题
“构建还是购买”的框架之所以能延续至今，是因为它为高管们在一个熟悉的维度上提供了一个二选一的选项，然而，AI所处的维度完全不同。
在你下一次架构审查中，真正值得提上台面的问题其实更简单：
我们希望厂商的AI做出哪些决策，又希望将哪些决策保留在我们自己的边界之内?
回答了这个问题，最适合的构建/购买/组合构建的融合方案就会水到渠成。倘若跳过这个问题，你最终得到的只会是厂商所偏好的架构——而这未必是你的业务所需要的架构。
