Moving AI from pilot to production: Salesforce’s Paul O’Sullivan on avoiding FOMO investment

For Paul O’Sullivan, CTO of Salesforce UK and Ireland, the story of how organisations responded to generative AI comes in two stages: wonder, then panic. Senior execs looked sideways at competitors and decided they had to move — not because there was a clear problem to solve, but because standing still felt dangerous. “Lots of organisations and lots of senior execs immediately went, well, they’re doing it. I’ve got to do it.”

The result, in Paul’s words, was investment for the sake of it. “FOMO will get you to a pilot, but having real intention around your transformation… is going to drive real business results. When you’ve applied strategic thinking to what you’re trying to actually unlock within your business, it will see you beyond the pilot phase.”

---

Where it stalls: data

For most, data is where it stalls. Fragmented systems, silos, a technology estate that built up over time but never got connected, no single view of the customer. Paul has had customers tell him they’ve spent ten years and three major programmes trying to crack their data — and still haven’t.

His advice is to stop trying to solve all of it. Start with what the first use case actually needs. “Your volume of data is all of this, right? It’s huge. But what do you really need that’s going to drive value in that one particular use case? And what you’ll find is it’s probably a small subset of data.”

---

The organisation’s duty of care to its people

The people who use the technology need to be ready too — and Paul is clear that’s the organisation’s responsibility, not something individuals work out on their own.

Security literacy comes first. Someone using a public LLM is in a different position from someone behind an enterprise gateway, but the basics apply either way: what can go into a prompt, what can’t, what compliance rules apply. “Safety and security is where I would say start. Just understand and have bite-sized learning that says, I’m not going to give a publicly available LLM corporate information or information about my organisation. That’s kind of 101.”

Workforce anxiety runs alongside it. Paul doesn’t believe AI takes jobs — it elevates the people doing them, freeing up cognitive capacity for the strategic thinking organisations need but can’t get because everyone is buried in day-to-day operations. “There is a duty of care and responsibility to your employees to be able to educate and support them in their learning journey around how do you adopt AI safely and securely in your enterprise.”

His advice is to take it in small chunks: a 12-month plan, something meaningful every month, with the goal of making the organisation AI native over time.

Across aibl’s conversations with mid-market leaders, almost every AI discussion starts with internal productivity. Paul sees organisations already looking outward — exploring how agentic AI can drive growth through marketing, outreach, and lead nurturing.

---

From pilots to production, one use case at a time

Agentic AI at scale is still new territory. Paul puts it at roughly 18 months since the first enterprise agentic solutions came to market. ChatGPT was the fastest-adopted technology on record. His concern isn’t speed — it’s depth. “I still think, and I worry on the adoption curve being very much proof of concept, pilot orientated.”

His advice: pick one use case and take it to production, rather than running disconnected experiments in parallel. Three or four data objects, one workflow, one measurable outcome. “You’ve got to, in that first 90 days, really be intentional. You have to say, this is one use case, and I’m going to take it all the way.” That’s the discipline that separates the organisations getting measurable AI ROI from those still running disconnected experiments in parallel.

Organisations that go wide early end up unpicking a proliferation of things never connected to each other or to a business outcome. Customers that do get a focused use case to production are seeing resolution rates as high as 80% or more. Salesforce itself is at 84%, with $100 million in annualised savings.

At Salesforce’s AI Centre, they ran a version of the Turing test: a human and an AI agent held the same conversation in parallel with a customer, who had to tell which was which. One person interacted with both chat interfaces for five minutes in front of an audience of around 20 customers. When asked to identify the AI, they couldn’t agree. Paul’s point isn’t that the AI passed. It’s that the closer it gets, the more customers will engage with it and come back. “I would encourage people to go and get not just your employees to test it and get user feedback and usability feedback, but get your customers, do small pilots, but get it out there.”

---

Don’t DIY your AI, and don’t wait to use it

LLMs are improving faster than most organisations can track. For Paul, whatever name is on them, they’re commodities. What matters is what you connect them to. That raises a practical question: does a given use case need the most powerful model available, or would a smaller one do the job at lower cost and lower energy consumption? “The LLMs are changing, you need the freedom to swap in and out an LLM as it improves.”

That pace is also why, in Paul’s view, most mid-market firms underestimate how much a partner matters. The right one carries development work that would otherwise slow everything down. Their direction of travel — and whether they can sustain the pace the market is moving at — matters as much as what they can do today. “Don’t plan to DIY your AI, because you’re going to lose time to value.”

The technology question and the leadership question are separate. On leadership: “There is nothing quite like a leader who turns around and says, look at what I did, whether it’s over the weekend, whether it was on a Wednesday afternoon, look at how I’m using the technology. Set the tone and example for your organisation because others will follow.” It doesn’t need to be complex. Summarising a meeting, drafting a follow-up email, using the technology visibly and letting people see it work. That’s what drives momentum — and in Paul’s view, the time to build it is now.

---

Frequently asked questions

Why do AI pilots so rarely make it to production?

Usually because they were started for the wrong reason. Paul O’Sullivan argues that FOMO-driven investment gets organisations to a proof of concept but rarely beyond it. Without a specific business outcome and strategic intent behind the use case, there’s nothing to pull the project through the hard part — data preparation, change management, and getting a workflow into production.

Where do most AI projects actually get stuck?

Data, not technology. Fragmented systems, disconnected silos, no single view of the customer. Paul’s advice is not to try to fix all of it before starting — but to identify the small subset of data your first use case actually needs and start there.

How quickly should a mid-market business expect to take an AI use case to production?

Paul O’Sullivan’s benchmark is 90 days. One use case, three or four data objects, one workflow, one measurable outcome — taken all the way to production rather than left as a parallel experiment. Organisations that spread attention across multiple use cases early tend to end up with a proliferation of pilots that never connect to a business result.

Should mid-market businesses build their own AI or use a partner?

Use a partner. Paul’s argument is that LLMs are improving faster than most organisations can track, making in-house builds a poor use of time and resource. A good partner absorbs development work that would otherwise slow you down, and their capacity to keep pace with the market matters as much as their current capability.

What results are organisations seeing once AI reaches production?

Focused, production-ready use cases are delivering resolution rates of 80% or higher in customer-facing applications. Salesforce reports 84% with $100 million in annualised savings — the product of intentional, single-use-case deployment rather than broad parallel experimentation.