Proofs of concept are usually set up to succeed. They have a small, restricted scope and curated data going in. The point is to test whether the functionality works and whether the thing is doable. After a proof of concept is successful, most organisations try to get to production by taking that same restricted scope and applying it more broadly, with messier data and less oversight. That is where we see the common pitfall.

Vikrant Bhusari leads the data and analytics function at Investa, one of Australia’s largest commercial office owners. He is not an outside observer. He is accountable for making these decisions inside a major Australian enterprise, and his read on why AI use cases stall matches what we see from the outside.

Ownership is not the same as sponsorship

A system needs a business owner to reach production. Sponsorship from a senior stakeholder gets a project started, but ownership gets it into production and keeps it there. When there is no named business owner at the point a proof of concept is approved, it almost never reaches production without one being appointed later. Usually after something has gone wrong.

The question to ask before you approve the next stage: who is accountable for this in twelve months, when the build team has moved on?

Scope is set too wide before the build starts

The second pattern is a brief that is too broad. Automate the process. Make reports intelligent. Transform how the team works. That hands a technical team a problem that cannot be shipped.

“Be iterative,” Vikrant said. “In that way, I’ve seen AI systems move to production much faster and there is a huge success rate.”

The question of what the smallest useful version looks like is a leadership call, not a technical one. The technical team will build whatever they are asked to build.

Governance that sits on top of everything stops experimentation

The instinct is to apply the same process to every AI use case. The same committee, the same approvals, whether it is a low-stakes summarisation tool or an automated decision with real consequences. That slows everything down without actually managing risk.

Vikrant’s alternative was guardrails that scale with the stakes. A safe environment for experimentation, with more rigour added as a use case moves toward production. “The rigor associated with the risk should scale as well,” he said.

It is a practical distinction. Low-risk experimentation should be easy to start. High-stakes production systems should earn more scrutiny. Treating them the same way serves neither.

The Omnia Collective works with financial services and enterprise clients across Australia as a certified Microsoft and Snowflake partner, helping organisations get AI initiatives from proof of concept into production. See our AI and automation services or get in touch.

This post is adapted from Episode 19 of Nap Stack, Monica’s podcast on AI, data, and building a business. Listen on Spotify or Apple Podcasts.