零售AI治理：需要上下文控制平面

零售商正在进入AI应用的新阶段。

围绕生成式AI的早期讨论通常集中在实验上。我们应该尝试哪个模型？我们应该构建哪个聊天机器人？哪个团队应该运行第一个试点？AI能否改善搜索、总结文档、丰富产品内容或回答内部问题？

这些是重要的起点。许多零售商、杂货商、分销商和面向消费者的公司从这些早期努力中创造了实际价值。

2023年底，我们合作的一家大型分销商看到了结合传统机器学习和大型语言模型的机会，以改进产品目录操作。随着新产品进入目录，机器学习模型帮助分类和匹配项目，而大型语言模型生成更丰富的产品描述。

当时，这是开创性的。

该计划需要一个系统集成商、一个专注的攻坚团队，以及大约100天的冲刺来证明价值，而团队同时处理架构、数据访问、模型行为和业务流程的机制。这是一个非常成功的计划，节省了数百万美元，并证明了AI可以实质性改善关键业务流程。

但它也代表了一种常见的第一波模式：一个团队、一个用例、一个架构、一个专注的冲刺。

如今，同样类型的AI赋能工作流正在成为标配。对话正在从“我想知道AI能否解决这个问题”转向“AI必须帮助解决这个问题，我需要快速获得正确的数据，以免拖慢业务”。这种转变改变了企业挑战。

零售AI的下一个阶段不仅仅是拥有更好的模型。它关乎给每个AI体验正确的业务上下文。

上下文是让企业AI有用的关键

没有零售上下文的模型可能会给出一个通用答案。

具有正确上下文的模型可以帮助商家权衡品种风险，帮助门店领导者优先安排一天的工作，或帮助高管获得关于销售和利润的可信答案。对零售商而言，这种上下文涵盖了从库存、定价到决定谁能看到什么的权限和策略的一切。

这种上下文是让AI有用的关键。但上下文也是风险进入系统的地方。

AI应该看到哪些数据？它应该信任哪些业务定义？哪些用户被允许问哪些问题？代理可以调用哪些工具？哪个模型应该处理任务？那次交互应该花费多少？企业应该如何审计发生了什么？

这就是为什么零售AI需要一个上下文控制平面，一个单一层来管理每个AI体验可以使用哪些数据、模型和工具。

治理促进速度

治理有时被描述为拖慢团队速度的东西。对零售商来说，情况恰恰相反。

治理的目的是给更多团队更多安全使用AI的自由。

如果正确的控制到位，每个新的AI用例就不需要成为一次性的安全、采购和架构练习。整个零售企业的团队可以更快行动，因为模型访问、权限、日志记录、跟踪和成本控制已经内置在平台中。

这就是零售AI治理的“意义所在”。

它不是为治理而治理。它是为了让员工能够更有信心地使用AI，更好地服务客户，并基于可信数据做出更快的决策。

团队对嵌入工作流的AI越来越适应。他们需要被释放去探索、构建和交付成果。但释放团队并不意味着移除控制。它意味着给他们一种受治理的方式，以正确的数据、正确的模型、正确的权限和正确的成本控制已到位的情况下快速行动。

下一阶段是企业范围的AI采用

在与零售技术领导者的合作中，我看到对话经历了三个阶段。

1. 首先，团队询问从哪里开始使用生成式AI。
2. 然后他们构建了聚焦的用例，如产品匹配、目录丰富、搜索、总结、内部知识助手和内容生成。
3. 现在对话再次转变：我们如何在不造成分散治理、失控的模型支出或不一致的企业数据访问的情况下，将AI扩展到门店、总部团队和数字渠道？

这很重要，因为零售不是单用户、单工作流的行业。

大多数员工并不是坐在办公桌前选择AI工具。他们的AI体验是嵌入式的，在一个门店应用、一个仪表板、一个他们已经在使用的工作流中，它需要为每个角色回答不同的问题。每个职能部门需要不同的数据。每个职能部门有不同的权限。每个职能部门可能需要不同的模型。每个职能部门有不同的成本概况和风险概况。

这就是为什么零售AI不能由一个模型解决。

零售商需要一种受治理的方式来交付跨业务的许多AI体验，同时控制哪些用户可以访问哪些数据、他们可以使用哪些模型、花费多少，以及这些交互如何被监控。

难点在于在不失控的情况下扩展

随着AI在企业中扩散，零售商面临创建分散运营模式的风险。

一个团队直接使用Claude。另一个团队构建RAG应用。另一个使用Copilot。开发者使用Cursor。业务用户尝试Claude Cowork。数据团队建立自己的代理工作流。

每个工具可能有自己的模型访问、数据访问、日志、权限、成本和治理流程。

这在实验阶段可行。但不能作为企业AI的运营模式。

没有控制平面，零售商可能很快面临：

• 独立的模型供应商合同
• 独立的AI工具和代理框架
• 独立的提示和响应日志
• 独立的成本中心
• 独立的权限模型
• 业务逻辑所在的不同地方
• 对同一业务问题的不同答案

零售商多年来一直在努力减少数据和数据分析中的碎片化。AI不应以新的形式重新引入同样的问题。

零售商需要开放的AI控制框架，而不是封闭的AI死胡同

随着AI采用的扩大，另一个问题出现了："AI控制框架"AI控制框架"应该位于何处？"

有些控制框架是封闭的。用户获得打包好的AI体验、默认模型，并且对数据、工具、提示、成本和模型选择的管理方式控制有限。这可能对个人生产力有用，但当企业想要控制使用哪些模型、如何访问数据、如何管理成本以及如何审计AI交互时，它就变得有限了。

其他控制框架更加开放。它们允许企业为任务选择合适的模型，连接到受治理的数据和工具，通过中央网关路由模型调用，并在模型格局变化时保持灵活性。

这种区别很重要。

在最近的一次晚宴对话中，一家折扣零售商的CIO分享说，CIO同行小组正在积极讨论是否应该采购GPU以利用成本更低的开源模型。与此同时，团队已经在尝试不同的AI界面：开发人员使用Cursor和编码助手，业务团队探索Claude Cowork，企业团队评估类似Copilot的体验，数据团队构建定制代理和应用程序。

这是大多数零售商的现实。AI采用不会整齐地标准化为一个模型、一个助手或一个供应商。

当我们问CIO们他们认为哪个模型会胜出时，答案几乎总是某种版本的"我不知道"。这是一个理性的答案。模型格局变化太快，任何CIO都不能把企业AI战略押在今天首选工具中的默认模型上。

零售商需要模型灵活性，但不要模型混乱。

他们需要支持前沿模型，在质量和推理重要的地方。他们需要访问开源模型，在成本、控制或专业化重要的地方。他们需要支持编码助手、业务代理、员工应用程序和定制应用程序。但他们还需要一种通用的方式来治理访问、监控使用、控制支出、记录交互，并确保AI基于可信的企业上下文。

这就是AI控制平面的角色。

基准测试模型，同时保持可选性

模型格局变化太快，零售商无法围绕单一模型提供商或单一默认助手做出长期架构决策。

Databricks研究发现开源模型处理的任务越来越复杂，而这些任务在不久前还需要高级前沿模型。这对零售商很重要，尤其是杂货店和折扣零售商，因为这些行业的利润率很紧，高容量的AI使用可能很快变得昂贵。

但答案不是假设开源模型总是足够好。答案是进行基准测试。

产品内容工作流可能在成本较低或开源的模型上表现良好。复杂的商品分析可能需要更强的推理模型。商店员工助手可能需要低延迟、严格的权限和可预测的成本。编码助手或多步骤规划代理可能受益于前沿模型。正确的模型取决于任务、数据、准确性要求、延迟要求和成本概况。

这就是为什么零售商需要模型灵活性而不要模型混乱。问题不应该是"哪个模型会胜出？"更好的问题是"对于这个工作，在上下文中，以这个成本，以及这个治理要求，哪个模型最好？"

封闭的AI控制框架常常隐藏或限制这种选择。开放的AI控制平面让零售商能够随着市场变化进行基准测试、切换和优化模型。

零售AI上下文的控制平面

这就是控制平面在实践中的样子。四个Databricks能力协同交付：Unity Catalog、Unity AI Gateway、Foundation Model APIs和Genie。

• Unity Catalog治理业务上下文：数据、权限、沿袭、模型和可信定义。
• Unity AI Gateway治理模型访问：路由、使用可见性、日志记录、预算和速率限制。
• Foundation Model APIs提供对商业、开源和定制模型的集中访问。
• Genie让业务用户针对受治理的数据提出自然语言问题，因此答案始终基于可信的上下文。

这些能力共同帮助零售商从孤立的AI胜利转向企业范围的AI采用。

重点不是强迫每个用户使用一个AI应用程序。而是给企业一个统一的治理和模型访问策略，无论员工使用哪个应用程序、代理或界面，它都保持不变。

目标不是阻止团队使用他们喜欢的AI工具。目标是让团队更快地行动，同时让企业控制模型、数据、上下文、成本和风险。

这在零售团队中的体现

一家折扣零售商的CIO最近分享了一个有说服力的例子。他们的CEO希望AI基于更广泛的公司数据，以便对高层决策真正有用。

这个需求完美地抓住了企业AI的挑战。CEO不是要求一个更聪明的模型。她要求的是一个她可以信任来处理业务的模型。这个直觉是对的。当AI理解业务时，它变得更有价值。CEO们想要一个基于自己数据的答案，而不是泛泛的答案。

答案不是简单地对每个AI工具不加限制地访问所有原始数据集。答案是为每个用户提供正确的AI体验，基于正确的数据，具有正确的权限、沿袭、定义和可审计性。

避免另一个脱节的AI层

许多零售商已经在数据治理、湖仓现代化和可信分析方面投入巨资。随着AI采用的加速，风险在于创建一个在受治理数据资产之外运行的独立AI层。

这可能会带来实际问题。

• 业务逻辑可能在数据平台之外被重复复制。
• 权限可能需要在多个系统中重新创建。
• AI代理可能在没有一致血缘的情况下访问数据。
• 模型使用可能分散在不同提供商和合同中。
• 成本可见性可能因团队或应用而碎片化。
• 提示和响应日志可能与治理工作流程脱节。

零售商应避免重新制造多年来在数据和数据分析中努力消除的碎片化问题。

代理式零售的未来要求AI来到受治理的数据中，而不是将业务逻辑、权限和可信上下文移动到另一个脱节的层中。

对于已经在Unity Catalog上投资的零售商，下一步是治理在其上构建的AI系统。这样做，每个新的AI用例都会继承已有的相同权限、审计跟踪和成本控制，而不是从零开始。

业务成果：更多自由，更多控制

通过受治理的AI控制平面，零售商可以让团队在自由中更快行动，同时保持企业控制。每个职能部门都能获得根据其实际工作方式构建的AI，从门店到财务团队，无需等待一次性安全或采购审查即可实现。

同时，IT领导者可以保持对谁在使用哪些模型、访问了哪些数据、每个工作流的成本以及AI交互如何被治理的可见性。

这就是零售商需要的平衡。不是一个聊天机器人。不是一个模型。不是另一个脱节的AI平台。

一个用于上下文的控制平面。