Picking a use case, proving value, and expanding is the standard advice for getting started with AI. For the early stages of AI deployment, this advice is still sound. But at NVIDIA GTC, Cameron Davies, Chief Data Officer of Yum Brands, made the case that scaling AI in a large enterprise requires companies to think differently—and he had the results to back it up.
Yum Brands is one of the world’s largest restaurant companies with 63,000 locations, processing more than 100 million transactions per day, across 155 countries through 1,500 franchisees. Davies didn’t come to GTC to talk about a pilot. He came to talk about what happens after the pilot, when the real complexity begins.
His session, “Scaling AI Agents Globally Across Brands, Use Cases, and Restaurants,” wasn’t a product pitch. It was a framework. And it resets the conversation about what it actually takes to put AI into production at scale.
Stop Thinking in Use Cases. Start Thinking in Skills.
Over the past two years, enterprises have been plagued by failed AI proofs of concept. The firms that demonstrated returns from AI started with a fairly straightforward approach: identify a use case, build a proof of concept, demonstrate ROI, and expand. Davies challenged that model directly, not because it’s wrong in principle, but because it doesn’t scale.
“Doing AI in a lab, it’s easy. We’ve all done it before. In fact, the models aren’t the problem anymore… Getting it to work in the lab, getting it to work with a phone call, that wasn’t the hard part. Getting it to scale in a messy, imprecise world, that’s hard.”
At Yum’s scale, a use-case-first approach produces monolithic agents that are good at one thing in one context and fall apart everywhere else. The company operates over 500 different point-of-sale systems globally. Its menus differ not just across brands but across regions within the same brand. An AI that works perfectly at a Taco Bell in California may not transfer cleanly to a KFC in the UK or a Pizza Hut in India.
Davies reframed the question. Instead of asking “what use case should we build?”, his team asks “what skills do we need, and how do we make those skills reusable?”
He described it using a sports analogy: “I could ask you to build me a baseball pitching robot… That’s very different from me saying to my team, I need a throwing machine. This machine doesn’t care what’s in its hand, and it doesn’t care what the target is. It’s just really good at throwing things.”
The practical implication: Yum built customer-facing agent skills and team productivity agent skills that can be deployed across brands, markets, and use cases — rather than building discrete agents for each problem. The same voice-ordering capability that operates a drive-through in one country can surface in a customer service context in another, because the underlying skill is real-time voice processing, transcription, and translation.
Scaling AI requires a meaningful shift for large enterprises. It requires more architectural thinking upfront and more coordination between IT and business teams before a single POC is built. But the payoff is a reusable capability layer rather than a growing inventory of one-off AI deployments that each require their own maintenance, integration, and governance.
You Can’t Scale AI Without a Governance Strategy.
Davies was unambiguous on this point, and it is worth quoting him directly.
“If you’re going to do AI, people often ask me, what’s the first thing you do? … It’s governance, because there is no intelligence without governance.”
He used a vivid example from a colleague, Manoj Saxena, chair of the Responsible AI Institute: “You are all excited about these (AI) agents and what they’re going to do, but you don’t have the right governance in place, so what you’re doing is you’re all building these little Chuckies (from the movie)… in one hand’s a knife and the other hand’s a credit card, and you’re sending him loose into the system and he’s stabbing and swiping, and you don’t know what he’s doing, because you have no agent registries. You have no control.”
At 100 million transactions per day, the risk profile of an ungoverned AI agent is not theoretical. A bad decision made at machine speed — the wrong menu item, a mishandled order, a brand-damaging interaction — can propagate across thousands of restaurants before anyone catches it. Davies is explicit that governance is not a post-deployment concern. It is the foundation.
For most enterprise organizations, this is the piece that gets deprioritized. Governance feels like overhead when the pressure is to demonstrate AI value quickly. Davies’ experience suggests the opposite: organizations that skip governance in pursuit of speed end up constrained later, when the complexity of managing ungoverned agents becomes a bigger obstacle than moving slowly would have been.
The practical starting point is an agent registry that tracks which agents are running, which tools they have access to, what decisions they are authorized to make, and how their outputs are monitored. That discipline doesn’t require a mature AI platform. It requires a decision to treat governance as infrastructure rather than an afterthought.
The Practical Caveat: This Requires Knowing What You’re Trying to Accomplish
Davies’ framework works because Yum entered this process with a clear understanding of what they were trying to do and what outcomes they needed to achieve. They have a dedicated data science team. They worked hard to create clean data, expand data sources, and define a platform strategy, and were supported by an executive mandate.
That context matters. Smaller organizations, or those earlier in their AI journey, should not interpret “don’t think in use cases” as “don’t focus on defining a specific business value.” The opposite is true. Yum’s skill-based approach requires a sophisticated understanding of what capabilities the business needs, how those capabilities connect to customer or operational outcomes, and how the underlying architecture will support reuse.
Davies described decomposing something as simple as a taco order into a set of discrete tool calls — finding a product, applying a modification, adding it to the cart, and submitting the order. Each of those is a separate decision point, a separate skill. Getting that decomposition right required deep knowledge of Yum’s systems, menus, and the ways customers actually interact with them.
If you are selecting a specific use case to prove value, that is still sound advice — especially if you are still building organizational confidence in AI or don’t yet have the infrastructure to support a platform approach. The piece of Davies’ advice that applies universally is this: whatever you build, know the outcome you are trying to achieve before you start. The goal and the measurement need to come before the tool selection.
Davies put it succinctly in his closing guidance: “Build in your measurement from day one. Build it into your systems from day one. Continually measure it and continually talk about the measurement.”
How Yum Solved the Scaling Problem
None of this is easy to replicate. Yum has resources, a mature data organization, and an executive mandate that made this approach possible. But the framework Davies laid out is worth capturing — not to copy it, but to understand the decisions behind it.
Start with governance, not a pilot. Define what agents are allowed to do, how they are registered, and how their behavior is monitored before deploying anything at scale. Governance is infrastructure.
Build an AI platform, not a collection of POCs. Yum invested in its proprietary platform — Byte — as the connective tissue for its AI work. Davies was direct: “Platforms, not pilots.” The platform enables skills to be reused. Without it, every deployment starts from scratch.
Design for reusable skills, not one-time use cases. Break capabilities into discrete, transferable components. Each skill should be able to operate in multiple contexts without modification. This requires decomposing workflows into specific decision points and building and training against them rather than against an end-to-end scenario.
Use synthetic data to address data gaps. Yum worked with NVIDIA’s Nemo tools to generate over 20,000 training records from limited production data. This allowed them to train small, domain-specific models on the kinds of decisions that matter in their environment — without waiting for years of production data to accumulate.
Measure continuously and own your data. Davies was emphatic on two points that are easy to underestimate. First, always measure, always share measurements, and never stop. Second, do not give up your data or your orchestration layer to a vendor partner. “No matter who you partner with, don’t give them up. That’s your intellectual property. That’s what matters most.”
The results Yum reported: a three-times improvement in tool call accuracy over a base model after fine-tuning, 100% function match for complex multi-step orders, and a 20-times reduction in inference cost compared to general-purpose closed models. Those numbers reflect what happens when the architecture, the training approach, and the measurement discipline are all aligned.
Scaling AI is not just a technology problem. It is a business strategy, architecture, and governance problem that technology enables. The lesson for other organizations is not necessarily to copy Yum’s specific approach — it is to ask the same questions Davies asked before assuming a POC is a strategy.
Define what your business outcome looks like. Start with governance. Build a platform. Design for reuse. Measure everything.
A version of this article was originally posted in my AI Decoded with Maribel Lopez newsletter. Subscribe to my LinkedIn Newsletter here.
Subscribe to my podcast here.
Lopez Research 