Enterprises are racing to experiment with AI, but moving from a promising prototype to a production system remains one of the biggest hurdles.
In our latest instalment of our ‘in conversation’ series, our VP of Applied AI, Paul Heathcote, shares why organisations often approach AI the wrong way, and why treating it like traditional software can lead to unrealistic expectations.
How do you advise enterprises balance chasing quick wins with building for long-term AI transformation?
Pilots vs production
Obviously, it absolutely makes sense to start with pilots. They allow you to test whether a use case is technically feasible and whether it can deliver value.
But once that feasibility has been identified, the focus has to shift. At that point you’re no longer building a prototype, you’re building something that needs to operate reliably in production.
That means thinking about how you’re going to architect it so that it’s scalable, secure, resilient, and meets all of your compliance considerations. And that often requires slowing down compared to how quickly you can produce a prototype that demonstrates the concept.
Once those foundations are in place, however, you can iterate very quickly. So the right approach is to experiment and prototype to validate the use case, but then take the time to understand what capabilities are required to run the system properly in production. Establish that foundation, and then build and iterate on top of it rapidly.
Set expectations early: AI isn’t deterministic like traditional software
One of the biggest mindset shifts organisations need to make is understanding that AI systems don’t behave like traditional software.
With traditional software the behaviour is deterministic. If you give the system the same inputs, you’ll always get the same outputs. There’s no variability. One plus one will always equal two.
AI systems are different. The kind of problems that AI is good at solving are things that are fuzzier and more probabilistic. You won’t always get the same answer for a given input.
That doesn’t mean the system isn’t valuable. But it does mean organisations need to set expectations differently.
What should we compare AI development to instead of software development?
In many ways, it can actually make more sense to compare AI to a business process outsourcing model (to humans) rather than a traditional software model.
When organisations outsource a business process, they expect a knowledge transfer period. They expect some mistakes early on as the partner learns the environment.
AI systems face similar challenges. Often they’re operating in environments where the information they’re given isn’t perfect, documentation may be incomplete, and the data may not fully capture every scenario.
To bring this to life, in one of my previous roles, I ran a very large technology function, and we used a partner to scale up resources in that team. And what was a pain to make everyone realise was that at first they’re going to make mistakes because they’re new to the environment. The information we were giving them about what to do and how to do it wasn’t perfect because the people who had been doing the job before hadn’t maintained it well, a lot they had to learn was undocumented, and so, at first, they made mistakes, right? And that is the environment we are often giving these AI capabilities.
Ask yourself, would humans make mistakes in this scenario?
Because of that, the key question becomes what level of error is acceptable?
If a system gets something wrong a very small percentage of the time, is that within an acceptable range? What is the cost of these errors, and does the business case still make sense?
As long as the cost of those mistakes sits within the envelope you planned for, the solution can still deliver significant value. The important thing is setting those expectations upfront so the capability isn’t unfairly judged as a failure.
And obviously, you’ll be constantly improving it, but it’s probably not going to be there at first, because you likely didn’t have all of the data you wanted in order to validate the system in the first place, and you will discover those things as you go. A person would make a mistake in that kind of scenario, so we should have the same kind of expectations around these capabilities.
Ultimately, successful AI adoption isn’t just about identifying promising use cases – it’s about understanding how these systems behave in the real world. Unlike traditional software, AI operates in probabilistic environments where inputs are messy and outcomes aren’t always perfectly predictable. Organisations that recognise this early, set realistic expectations, and build the right production foundations will be far better positioned to move beyond experimentation and turn AI into a capability that delivers sustained value.
In our next instalment of the series, our VP of Applied AI tackles questions around where enterprises should build their own AI capability, and where it makes more sense to partner with specialists.
