At a glance
- Strong data foundations are essential for successful AI.
- Trusted data builds confidence in AI outputs.
- Governance and ownership reduce risk and improve accountability.
- Production AI requires more than a successful pilot.
- Reusable data products make AI easier to scale.
Whether you are excited about AI or deeply skeptical of it, the same thing is true. If you are going to invest in it, the foundations will determine whether you get value or a very expensive distraction.
That matters because most senior leaders in New Zealand and Australia are not sitting around debating AI for the sake of it. They are dealing with margin pressure, rising costs, capacity constraints, customer expectations, and the constant push to improve productivity without burning out already stretched teams. AI shows up here as a lever – sometimes a powerful one, and sometimes just a distraction.
I am firmly in the camp that believes AI is worth doing. It is already delivering value in many businesses. But that does not mean the hype is helpful. A lot of organisations are getting pockets of value from a small number of use cases while still struggling to scale beyond early wins. This is normal and should not be considered a failure as this where and why foundations start to matter.
AI initiatives do not stall just because of data, whether there is not enough of it or the quality is really poor. Change management, product ownership, risk appetite, adoption, and operating model design all matter. In many organisations, early AI value shows up in pockets first, and that is normal. But from what I keep seeing, the most expensive and avoidable problems start to compound when the data and delivery foundations are weak, which is why I am focusing here.
A pilot proves feasibility, production proves readiness
The mistake is assuming that because a pilot worked, the organisation is ready.
A proof of concept can prove that a model can do something useful, but it cannot prove your organisation can run that use-case safely, reliably, and repeatedly in production, or whether teams can safely make changes without causing issues elsewhere. It also does not give you a clear picture of how the solution will hold up over time, or whether costs will stay manageable as usage grows and more people depend on it.
While PoCs prove feasibility, production is what proves readiness. That is why I think the most useful way for senior leaders to frame AI is not as a capability you buy, but as an operating model you build.
| → |
Yes, the model and the platforms matter, but the hard part is usually everything around it. That includes data reliability, clear ownership, the right controls, and the discipline to deliver properly, along with how risk is managed, how changes are made, how outputs are trusted, how value is measured, and how costs are kept under control as interest turns into real usage.
AI is a data supply chain
A simple way to think about this is as a data supply chain.
Senior leaders already understand supply chains. You care about quality, reliability, traceability, service levels, failure points, and accountability when something goes wrong. AI depends on the same things. If the data feeding a use case is inconsistent, late, duplicated, poorly defined, or impossible to trace, the output may still look impressive, but it will not be dependable as its inaccurate. And if it is not dependable, people stop trusting it.
The three foundations of AI readiness
This is where many organisations get stuck. Not because the AI itself is useless, but because the surrounding operating model was never designed to support it.
I would focus the foundations for AI around three things: trust, time-to-change, and cost-to-serve.
Trust
Trust comes first because without it, nothing else matters. Trust is not a vague statement about data quality. It is whether people can rely on the output enough to act. It includes clear definitions, lineage, access controls, and reproducibility. If a senior leader asks where a critical number came from, who changed it, and when, can your team answer quickly and confidently? If an issue is found, can you trace the impact and rerun from source data in a repeatable way? If not, your AI initiative may still produce outputs, but it is carrying risk.
Time-to-change
Time-to-change is the second foundation, and it is often the one that quietly kills momentum. Many teams can build a first version but far fewer can change it safely once the business learns something new. As requirements shift, policies change, and data sources evolve, any change that is slow, manual, or risky starts to drag things down, leading teams to protect workarounds instead of improving the product, which is how AI systems become brittle over time. This is why senior leaders should focus less on how quickly a prototype can be built and more on how long it takes to move a data or model related change safely into production.
Cost-to-serve
Cost-to-serve is the third foundation. This is where AI often looks cheap at the start and expensive later. Pilots get approved because the first run cost is manageable. Then adoption grows, workloads multiply, duplication creeps in, and no one has a clear view of what it costs to operate at scale. The goal is not to avoid spend but instead to make it visible and controllable.
Before moving beyond a pilot, an organisation should be able to clearly answer a few key questions:
- Can you predict the cost of running this use case at production scale?
- Can you isolate workloads so one team’s experiment does not disrupt another team’s delivery?
- Can you see where duplication is creeping in before it becomes normal?
If the answer to these questions is no, then the risk is not just technical, it is financial as well.
This is also where governance gets misunderstood.
Governance should feel like guardrails, not gates
Senior leaders do not need more gates. They need guardrails.
Bad governance feels like delay and ceremony. Good governance feels like speed with confidence. It standardises the repeatable parts so teams can move faster on the work that actually creates value. It gives you shared definitions, clear ownership, consistent access patterns, release discipline, auditability, and policy enforcement without reinventing the wheel every time.
In practical terms, good guardrails reduce incidents, reduce rework, make approvals faster, and make scaling safer. That is not bureaucracy. That is operational efficiency.
One trap worth calling out is use case first thinking being treated as the full strategy, because while use cases do matter and are necessary to connect AI work to real outcomes and force prioritisation, that approach on its own is incomplete if you cannot industrialise what works.
The problem with one-off AI success stories
If every pilot creates its own data definitions, ingestion logic, access model, and delivery approach, you are not building capability. You are building expensive one-offs.
A better approach is to choose use cases that force reusable foundations, such as Customer, risk, finance or operations, with areas where the outputs matter and the underlying data products can support more than one initiative over time. That way, even if one use case underdelivers, the foundation work still pays off.
It is also worth saying clearly that you do not need perfect data before doing anything with AI.
Some use cases can deliver value quickly on imperfect foundations. The real issue is not whether you can get a quick win, but whether you can repeat it, govern it properly, and scale it safely over time, which is where many organisations eventually run into trouble.
Five questions every leader should ask
So, what next, if you are a senior leader trying to make this practical?
|
Can we explain where a critical number comes from, who changed it and when? | |
|
How long does it take us to safely move a data change into production? | |
|
Can we enforce access, retention and sensitive data policies in one place? | |
|
If a defect is found, can we rerun from source data reliably and repeatedly? | |
|
Are we building reusable data products with clear owners and service expectations, or one-off pipelines? |
Then, build a 90-day plan that creates momentum without theatre. Pick one use case that matters. Assign clear ownership across business, data, platform, and risk. Agree the core definitions that cannot drift. Put in the minimum guardrails needed for trust and change control. Build the data product and delivery pattern so it can be reused. Measure value and operating cost together.
AI will scale whatever you already have
That is how you make AI real in lean teams and real-world constraints.
AI can be transformational. I believe that. But the organisations that get lasting value are rarely the ones chasing the loudest promises. They are the ones building foundations that let AI succeed in production, not just in presentations.
If your data cannot be trusted, AI will scale your mistakes faster.
If the foundations are sound, AI will scale your capability.
That is the difference.
And that is where senior leaders can have the biggest impact.
If you want, the next step from here is practical: determine what a foundation layer actually needs to do within your business, and what that looks like in practice when you are trying to make this work with lean teams, mixed legacy environments, and real delivery pressure.
