Episode summary
Moving enterprise AI from pilot to production requires more than proving that the technology works. In this eSpeaks episode, Corey Noles speaks with Beth Williams of Dell Technologies about why AI projects often stall after successful pilots and what organizations need to put in place before those systems can scale.
Williams explains that pilot environments are often built around handpicked data, limited users, and whatever infrastructure is easiest to access. Production introduces a different set of requirements, including scalable infrastructure, trusted and governed data, security controls, clear ownership, ongoing monitoring, and a way to measure whether the AI system is still delivering business value.
The conversation also covers how Dell prioritized a small number of high-value AI use cases from hundreds of possibilities, how enterprises should think about workload placement and AI costs, and why organizational readiness can be a bigger challenge than the technology itself.
Key takeaways
- Moving enterprise AI from pilot to production requires scalable infrastructure, production-ready data, governance, security, monitoring, and clear ownership.
- A technically successful AI pilot should not automatically move into production; enterprises should define business KPIs and evaluate whether the use case is delivering enough value to scale.
- Data readiness should be evaluated against specific AI use cases, with attention to discoverability, permissions, lineage, ownership, governance, and lifecycle management.
- AI infrastructure should scale in stages and be placed according to workload requirements, including cost, latency, security, and data location.
- Production AI costs extend beyond token usage to compute, storage, networking, data movement, software, power, cooling, and cloud ingress or egress.
- AI governance requires clear accountability across users, business process owners, data owners, platform owners, model owners, security teams, and risk teams.
- Mature AI programs build for repeatability, reusing data products, infrastructure, governance, and deployment processes across use cases instead of rebuilding the foundation for every pilot.
Enterprise AI pilot-to-production requirements
Biggest barriers to scaling enterprise AI
The biggest barriers to scaling enterprise AI typically emerge when organizations move beyond controlled pilots. Common challenges include production-ready data, scalable infrastructure, workload placement, governance and security, clear ownership, ongoing monitoring, operating costs, and user adoption.
| Production challenge | Why it matters | What enterprises need |
|---|---|---|
| Data readiness | Pilot data may be manually curated and difficult to reproduce at scale. | Data that is discoverable, permissioned, traceable, governed, owned, and maintained over time. |
| Infrastructure | Pilot environments may not support persistent or growing usage. | Scalable infrastructure sized to the workload, with options to expand as demand grows. |
| Workload placement | Not every AI workload belongs in the same environment. | A hybrid strategy based on data location, security, latency, cost, and performance. |
| Governance and security | Production and agentic AI can access data and take actions across business systems. | Defined policies, permissions, controls, accountability, and risk oversight. |
| Ownership | A pilot can be run by an innovation team; a production system needs long-term operators. | Business sponsors, process owners, platform owners, data owners, and defined change authority. |
| Monitoring | Technical uptime alone does not show whether an AI system is succeeding. | Monitoring for infrastructure, model drift, data drift, security, adoption, ROI, and business KPIs. |
| Cost | Token costs are only one part of the operating expense. | End-to-end TCO that includes compute, storage, networking, software, data movement, power, cooling, and cloud costs. |
| Adoption | An AI system creates little value if employees do not use it. | Change management, training, adoption plans, and continued measurement of usage and value. |
FAQs
What does it take to move enterprise AI from pilot to production?
Moving enterprise AI from pilot to production requires scalable infrastructure, production-ready data, security, governance, monitoring, and clear ownership. Pilots often rely on curated data, limited users, and temporary infrastructure, while production systems need to operate reliably at scale and continue delivering measurable business value.
How can enterprises scale AI successfully beyond pilot projects?
Enterprises can scale AI by prioritizing high-value use cases, defining business KPIs during the pilot stage, preparing the required data, and building reusable infrastructure and governance underneath those projects. Dell’s own approach included narrowing more than 800 potential AI use cases to three or four priority areas before moving ahead.
How should companies govern AI as it moves into production?
Companies should clearly define who is responsible for how production AI systems are used, operated, changed, and monitored. Accountability should extend across end users, business process owners, data owners, platform owners, model owners, security teams, and risk teams.
What role do MLOps and LLMOps play in moving AI models into production?
MLOps and LLMOps support the repeatable operational processes needed to move AI into production, including deployment, monitoring, model and data drift management, governance, rollback, lifecycle management, and ongoing measurement of performance and business value. The interview does not use the terms MLOps or LLMOps directly, but it does describe many of these practices.
Full episode transcript
Corey Noles: Welcome to eSpeaks from eWeek. I’m Corey Noles.
At this point, most enterprises don’t need another demonstration that AI can do something interesting. The harder question is: What happens after the demo?
Moving from a successful pilot to AI that can operate reliably across a business introduces challenges around data, infrastructure, security, governance, cost, and even who is ultimately responsible when these systems make decisions or take action.
Joining me today to unpack that transition is Beth Williams from Dell Technologies. Beth, thank you for being here.
Beth Williams: Hi, Corey. Thanks very much for inviting me.
Corey: Excellent. Glad to have you.
We’ve kind of reached a point where AI pilots are everywhere. But why is moving from a promising pilot to a real production environment still something that’s really difficult for so many enterprises?
Beth: Yeah, I mean, we’re seeing this a lot with our customers: a lot of stalling pilots, people just staying in that phase. And I think there are lots of different reasons for it.
One of the main reasons we see is that when people are focusing on pilots or demos, they’re really just trying to get the technology to work, right? So they’ve possibly got their own little environment somewhere. Maybe they’ve got a nice little GB10 or something. It’s not a scalable environment.
They probably handpicked the data, right? So they’ve curated the data, found it all, put it all in to get this to technically work. And they probably also handpicked the users as well, if they are opening it up to limited users. In fact, we’re in that state now with one of our pilots where literally we have just chosen a subset of users to go and play with this stuff.
So all that’s fantastic for a pilot, but the minute you move to production, it’s a completely different game, right?
First of all, you’re probably going to need something more than a laptop to run it on. So the platform you’re going to run these things on is a big part of that, and many of the customers that we have have not actually established a platform yet for it to run on, other than maybe using public cloud.
And then part of that equation becomes the data. I’ve talked about the fact that in a lot of pilots, you kind of handpick the data and curate it and get it to work technically. But when you start to move into production, quite often what you’re looking for is really automated data, right? You want data to be available when you need it, and you want to trust it. And a lot of the data we’re seeing with customers is just not ready.
So it’s a combination of lots of different things. Then, if you add things like agentic AI, what we’re seeing right now is lots of people piloting agentic workflows because they’re so powerful and the autonomy is so appealing. The minute you get into that realm, then you’re into a really interesting security conversation. You’ve probably seen quite a lot of stuff in the media recently about agents getting a little bit crazy.
Corey: They have. Going a little crazy.
Beth: Getting on little forums and talking to each other about how to break out of sandboxes and all sorts of fun stuff. So then you’ve really got to start thinking about that, right? That can’t be something you think about after you push to production. You’ve got to build it in from the start. It’s all about things like policies, permissions, and security.
And then also, who’s going to support this down the line? Again, a lot of people are very focused on getting that technology to work. And then when you think about moving it to production, who’s going to own it? Who’s going to own whether or not it’s behaving right? How’s it going to be monitored? How are you going to be able to roll back, and so on?
All of these questions are quite difficult to solve unless you’ve done it before. Of course, we’ve done it before, which is why we can help, or unless you’ve already got a platform you can roll it onto, which is something like the AI Factory with NVIDIA, for example. It’s just a ready-made platform you can roll it onto. So, as I say, it’s multifactorial.
Corey: Makes sense. There’s been a lot of pressure on these companies as well to find more AI use cases, but maybe not every experiment needs to become a production system.
How do you think leaders should determine which pilots are actually worth scaling?
Beth: Yeah, I think a lot of people get into this mindset that, “If I’ve got a pilot that works technically, it should always go to production,” right? And piloting is about learning. Essentially, it’s about trying to learn whether or not something’s going to work for the user, whether something’s going to technically work. And with AI, it becomes very interesting, especially with the fact that you’re using models that might hallucinate.
Part of what I try and help customers and people internally understand is that when you do a pilot, you’ve really got to be emotionally unattached to where that pilot goes next. You’ve got to say, “Okay, what did we learn? Can we move this to production now? Or should we maybe pivot on what this is doing?”
Or maybe — and this is the fail-fast model — we just say, “This isn’t suitable for AI. We need something that’s 100% trustworthy, and this is not giving it to us.” So maybe we just stop and rethink it. A lot of it is about being very unemotional about where you get to with the pilots.
But it’s also a case of, when you’re running the pilot, what kind of KPIs are you looking at during the pilot itself? Again, one of the things that we do internally, and we also help our customers do, is go through what we call a proof of value for a pilot. Let’s decide what the important KPIs are. Let’s prove those things during the pilot — not just the technology, but is it giving you the business outcome that you’re looking for? Is that revenue? Is it cost savings? Is it more performance? What is it that you’re looking for? Let’s measure those during the pilot.
And also just be aware that when you move to production, you want to continue to measure those as well. Those aren’t just one-off measures. Is it continuing to give you all of those things?
One of the other things that we did within Dell — because, by the way, use cases aren’t the problem. Use cases are definitely not the problem. There are hundreds and hundreds of potential use cases out there. We actually had 800-plus use cases a few years ago when we were starting the journey, and everybody was going off doing little pilots. And it was like, “Guys, we need to really pare this down. We need to look at what’s going to move the needle for us.” What are the really important use cases?
We looked at what our business was. What do we do as Dell? And we landed on three or four use cases. That was it. Three or four use cases that we knew made Dell what it was. We agreed on all of the KPIs, and then we went through a whole data-readiness side of things as well.
Because it’s all very well saying, “These use cases will move the dial.” But if it takes ages to get the data ready for those use cases, again, it’s one of those decision points where you go, “Well, maybe this is not great for those first pilots.”
So again, we did that internally. We prioritized the use cases that we wanted to push to production, made sure that we understood what the data was that we needed to get ready for that as well, and we got ready for that production deployment. And then we continued to monitor those KPIs going forward.
Corey: Makes sense. I’m glad you mentioned data. We always hear about how AI strategy is ultimately data strategy. Once a company gets serious about production AI, what does data readiness actually mean in practical terms?
Beth: Yeah, nobody really wants to talk about it, right? Because it’s not the fun bit. It’s not, “I’ve just got this gigantic workload, I’m doing this and doing that, look at this, it’s amazing.” It’s kind of not fun unless you work in the field of data.
We actually have a data-readiness assessment that we do as part of our own work, and we do it for customers as well. The sorts of things that we look at are, first of all, we say: Don’t look at all your data. That’s just overwhelming.
When we talk about data readiness, talk about those prioritized use cases, and you will probably see it’s a limited amount of data sources that you need to pull in. So just focus on the readiness around there. Where is that data? Can you find it? Is it discoverable?
Secondly — and this is really important when you start getting into the agentic space — have you got the right permissions around it? Because you really need to be careful with autonomous agents accessing data they shouldn’t access.
And then, can we trace it? Can we take it back to where it came from? Is the lineage of the data clear? Have we created something like a data product? We talk a lot about that — data products, treating data like products.
But that’s essentially it. Have we got the right permissions for it? Can we trace the lineage for it? Is it for the right use case? Is it owned? Is it governed?
And really important as well: Does it have lifecycle management around it? When you move into a data-as-a-product world, you are really putting ownership onto those data product managers to make sure that not only are they providing data in a timely manner, but they also have the responsibility to make sure that data is right, correct, governed, permissioned, and policy-compliant. Until you get into that model, it becomes very difficult to scale because you get back into that curated-data-set world where it’s all manual and data pipelines aren’t doing it for you. So moving into that kind of data-product world is a really good game changer. We did that fairly early on at Dell to help us with a lot of the use cases that we’re rolling out now.
Corey: That’s awesome. I see a lot of organizations begin experimenting with AI just using whatever infrastructure was easiest for them to access — basically, what they already have. But when usage becomes persistent and starts scaling across an entire enterprise, how does that infrastructure conversation need to change?
Beth: Yeah, you’re right. A lot of the pilots that people do tend to be on whatever they can get their hands on. It might be their own — I mean, I’m guilty, I’ve done it on my laptop. It could be anything. It could be a borrowed resource. It could be anything. Their aim is to try and get it to work.
Once you’ve got to that point where you go, “Okay, now I need to move this to production,” the infrastructure it’s running on as a pilot is very unlikely to be good enough. It’s very unlikely to be able to scale. So you’ve got to start thinking about, “Okay, what am I doing for scalability from an infrastructure point of view?” There are a few different ways you can slice and dice that.
We started off saying, “Okay, everybody needs to buy a big AI factory,” but that was a very, very big investment for customers, especially if they’ve got one use case. When you get to multiple use cases, you can absolutely see that infrastructure story and that AI Factory story makes total sense at scale.
So what we’ve done at Dell is we’ve kind of pared it down a bit and said, “Well, actually, let’s take the learnings that we understand now from the industry, which is that people are tending to start small.”
All you may need to do is make sure you’ve got one good GPU AI server, for example, with the right software stack on it. That might be good enough to start with. You might just be doing some small-scale inferencing, and then you can scale up. You can add these modular infrastructure pieces in, so you can go maybe to enterprise inferencing and then even distributed inferencing by keeping adding in those layers, those modules, if you like.
So starting small is still really important. The gap between pilot infrastructure and a big distributed AI factory is large. Having stepping stones to get you there for the use cases that you’re running is a really important strategy.
The other thing to talk about as well is that it’s not necessarily always going to be on-prem for everything. You’re going to be looking at a kind of hybrid approach. Most customers are. If you look at it from an AI workload point of view, and especially when you talk about agents, you’re going to see different parts of those workflows potentially not needing to be on-prem. They could possibly be in the cloud. Maybe it’s got a different kind of scalability that it needs. And there are going to be certain things that you do want to keep on-prem because of the data, potentially, and the security.
So one of the things that we do is come up with what we call a workload placement strategy based on the use cases that we’re implementing with customers. Then we decide, based on workload placement, what we need in terms of platforms.
“This particular use case needs to stay on-prem. Okay, fine: AI Factory.”
“This particular part of the use case could potentially run on a public-cloud model. That’s fine.”
So it’s that kind of strategy. We talk about hybrid models, but it becomes an AI workload decision-making process as to what your infrastructure needs to look like, what you can use in public cloud, what you need to keep on-prem, and what will get you to the fastest outcome.
Corey: That makes sense. And that kind of leads us really well into the elephant in the room, which is cost. AI can seem really inexpensive when you’re running a small proof of concept. But at scale, when you’re talking about compute, storage, inference, networking, and data movement, it adds up fast and turns into big numbers.
How should enterprises think differently about the economics of AI once it becomes an operational workload?
Beth: Yeah, I think we’ve all heard the phrase “tokenomics.” It’s probably one of the most overused phrases right now. And when people think of tokenomics, they think, “Okay, it’s token burn or token costs,” which is just the model cost, if you like. And that’s only part of the equation.
You mentioned it. That’s just part of the equation around what it’s going to cost you to run this in production. If you are using some kind of token-based model, what that’s going to look like is one piece, but it’s just one part of it.
A kind of total-cost-of-ownership exercise needs to happen, which includes that hybrid approach. Maybe there is token-burn cost over here for this particular workload that’s running in the cloud, but let’s look at what the cost is of running stuff on-prem as well. That needs to be part of the equation.
So we look at things like compute, storage, and networking. We look at data movement. We look at ingress and egress costs. But we also look at software costs, power, and cooling. Every time you run a query on an on-prem model, it’s still taking power. That is part of the equation.
So we need to think of it in terms of a kind of unit cost for doing a piece of work — a valuable piece of work — end to end. What does that really look like depending on where it’s running?
It really is a complicated calculation, and it’s an ongoing calculation as well because these things tend to change. Not every model is going to have the same token cost going forward. So you need to have this ongoing — I’d say broader — tokenomics conversation, not just the token burn, but everything else around it.
You need to have that monitoring going forward so that you can adapt and change and move things to the most optimal place that they need to be, depending on whether or not they need to have high frequency, low latency, depending on what you’re trying to use the use case for. And having that kind of automated workload placement based on those kinds of cost prompts.
Corey: Yeah. That’s really sensible. And I think one thing people forget about sometimes is that the old costs are still there too. It’s not just tokens.
Beth: Exactly. Private cloud, public cloud — we’ve had that conversation for many years. So it’s basically an AI cloud, right? Very similar.
The TCO calculations are very similar up to a certain point, and then there’s that added nuance on top of, “Okay, now I’m using AI. So what else do I need to incur? What else do I need to factor in when I’m looking at that conversation around what’s my best economic strategy for running these AI workloads?”
But you’re right. There’s not a lot of difference between what we used to talk about with public-cloud/private-cloud comparisons and AI. There are just slight nuances.
Corey: That’s right. Once AI is in production, even the model itself is just one part of a much larger system. What needs to be monitored and managed across that lifecycle to ensure the application keeps performing the way the business wants it to?
Beth: Yeah. Like we just mentioned, there are parts of this solution, including the platform, that we already have pretty good solutions for in terms of monitoring. There’s a layer of logging and monitoring that customers at enterprise scale already do.
So first of all, make sure you have those things in place. That’s ground rules. Table stakes, if you like. Then you need to look at: What are the new things that we need to think about when you start talking about AI, especially when you start talking about agentic AI?
Then we need to start thinking about the model itself. Maybe drift around the model. We need to look at that and have some way of monitoring that. Also looking at the data. People often forget that, but data drift is really important. And also look at the adoption of the use-case solution we put out there. So many people are keen to push stuff to production, but they’re not really seeing whether or not people are using it and then getting the actual cost returns, or revenue, or whatever that KPI was in the pilot.
I mentioned before continuing to monitor that going forward. It’s not just about monitoring technically in terms of, “Okay, is my stack behaving? Is my AI behaving? Is my agent behaving? Am I making sure that I don’t have any attack vectors on my model?”
It’s also, “Am I actually achieving the goals I said I would around KPIs?” That’s a really big part of the monitoring equation as well that people often overlook. They’ll keep things running in production, but actually maybe they’re just not adding the value they need. Maybe the ROI is not what we need it to be.
So again, keeping that ongoing cost in mind and that ongoing ROI in mind, as well as the technical monitoring.
Corey: Production AI also changes the stakes around governance, I would say. When these systems start influencing decisions and interacting with company data or taking action through other agents, where does that accountability ultimately live?
Beth: Yeah. You can’t say, “Well, the model told me to do it,” right?
Corey: No, that doesn’t work.
Beth: Well, some people try. But that’s just not going to work.
It lands in a few different places. If you’re using AI to perform some action at work and you’re the final human in that loop, and you’re going to do something with that action in reality, that’s your responsibility. We drill that into ourselves all the time.
We have lots of great AI tools internally, and we say all the time, “Hey, listen, if you use this and you do this with it, you’re responsible for that last action.”
All of the build-up to that, it’s your decision. So one person in that loop is the user of it. But the other person in that loop, I’d say, especially if it’s more autonomous with agents, is the business process owner. The business process that’s being automated and made better with AI and agentic AI — they are the ones who are responsible for that business process, which includes all of the AI that it’s using.
Now, underneath that business process owner, you’ve got a number of different owners as well. We talked about data products. If you’re in that data-products world, the data product owner is going to be responsible for the data that makes up part of that solution.
You may have a platform owner, like an AI Factory with NVIDIA platform owner. They’re going to be responsible for making sure that platform is behaving. You may have a model owner if you’re training your own model.
Underneath that overarching business owner for the process are all of these key players as well that make sure their component pieces are all complying with the rules that we’ve set up and performing to the SLAs that we decided we needed from them.
So lots of different players. But ultimately, the user — if they’re the end person in that workflow — needs to make sure it’s right before they press go.
And then the business process owner, whose business process you’re actually automating with AI: Those are the two main accountability tiers, I’d say.
Corey: That’s a really good approach. Understanding that you have these humans and these key elements here who are like, “This part is you. This part is you. Just keep it working. Make sure it’s doing the thing. Make sure it’s not going crazy and going off and attacking websites or something.” You want that kind of focus.
How much of successfully putting AI into production winds up being a technology problem, and how much do you think is an organizational problem? And once you move beyond that isolated innovation team, who takes over and owns it?
Beth: Yeah, the way I would say it is the technology is the easy bit. It’s funny because it’s the bit we focus on all the time. We talk about it all the time. We talk about our pilots being technically capable and so on.
Honestly, the hardest bit really is the organizational change. It’s always been the same with any kind of transformation project. It’s not the technology transformation. It’s the people transformation. It’s the organizational shift that needs to come into play. That is the hardest constraint for you to get over in these use cases.
We’ve always seen that, but it’s slightly exacerbated now with the autonomy of AI as well because things shift quite dramatically in that space. Organizations are shifting much faster and much quicker than they used to before.
The sort of things that we talk about — and I’ve talked about it previously — are: You’ve got to have an owner. That’s the first thing. If you’re looking at moving things to production, organizational readiness needs to look at things like: Who’s going to be the owner? Who’s going to fund this when it’s running in production? Where’s the money coming from? Who’s going to approve changes? If I need something to change, who do I go to? Who’s approving that? Who measures the value ongoing and who says this is valuable or not?
Essentially, who is accountable when things start going off the rails?
All the things that we know for sure with software are now even more important with AI software. Operating model, business sponsor, product owner, data and platform ownership — we’ve talked about those before.
Security and risk need to be key players in all of that. You need proper governance in there.
You need to have an adoption plan and see what’s actually going on with the adoption as well. Organizational shift is not just about who is going to keep the lights on in the solution. It’s also about: How do I encourage people to use this solution? That’s a big one.
If you think about AI and some of the fear around AI, people are sometimes a little cautious about, “I’m going to start using this for my job, and maybe it’ll do my job for me.” So part of the organizational change is to help people understand AI is there to help them be faster, better, more efficient, and take all the boring stuff out.
We’ve had to do that internally as well. We’ve gone through a number of different programs to help us adopt AI internally. So not only are there teams of people making sure the solution itself is still blinking lights and performing well, there’s a whole team of people making sure that people are using it in the right way and actually using it to help them do their jobs. So lots of different areas. It’s very similar to most transformational change, but there’s some nuance again with AI, especially around adoption.
Corey: Yeah. So if we look ahead a few years, what do you think will distinguish companies that have truly operationalized AI from companies that are still running a collection of disconnected experiments?
Beth: What’s it going to look like? How am I going to tell if these guys are really there or not?
If we look to ourselves, I think we’re pretty much there. We’ve got quite a few good production-ready use cases, and we have a good process around it in terms of governance.
One of the things that we did early on was try and make sure that we had, for example, not just a set of AI pilots, but an AI portfolio. So let’s take a look at this as a set of services that we can either offer ourselves internally to be more efficient and more productive, or offer our customers. These are all services. These are all products now. Treat them as they are: services and products.
The other sign of maturity, as well as this being a portfolio and not a myriad of pilots running somewhere, is the reusability aspect. You can tell somebody’s operationalizing when they can take a pilot that’s proven all its KPIs and go, “Boop, now it’s in production,” because I’ve got all of this repeatable stuff underneath that I can reuse. I’ve got repeatable data products. Maybe I created a data product earlier on that a different use case was using. I can reuse that data product now for this particular use case.
The underlying factory itself — we call it the AI Factory with NVIDIA because it’s a factory. It’s meant to be that kind of “just turn it and it’ll come out.” So it’s really easy to deploy onto an existing platform that’s already secure and governed.
That’s another key part of it: the repeatability of it.
And again, the idea that you’re not just measuring deployment clicks. You’re measuring whether or not this thing is giving you the ROI it needs to give you going forward. Ongoing measurement around KPIs, performance characteristics, all of those things — that’s a highly functioning, operationalized AI environment.
Corey: It is. Well, Beth, thank you so much for joining us today.
Before we let you go, where can people learn more about what Dell Technologies is doing around enterprise AI?
Beth: There’s a tremendous amount of stuff available on Dell.com, which I definitely encourage people to go and have a look at. From there, you can jump off to lots of different points.
You can jump off to my area, which is the services part. You can see all the great services that we’ve got, like the governance services, the AI Factory services, the data services — all of those things are on there as well.
So start with Dell.com. There’s a fantastic amount of information about our products, our services, our approach, how we’ve done things, and that will take you wherever you’re interested in going.
Corey: Excellent. Beth, thank you very much for taking the time to speak with us today.
Beth: Thank you so much.
Corey: And for more conversations like this, visit eWeek.com. You can also like and subscribe wherever you’re watching, and follow eWeek on LinkedIn, Facebook, and X.
I’m Corey Noles. Thanks for watching. We’ll see you next time on eSpeaks.


