The second question I get asked is always some version of the same thing.
The first question is what a business should be doing with AI at all. That one is easy to talk about, because everybody has read the same articles and everybody has an opinion. The second question is the one that decides whether anything actually happens: can you just plug it into our system?
Technically, yes. And that is precisely where the trouble starts.
In more than twenty-five years of implementing and supporting finance and operational systems for New Zealand businesses, I have never opened one that was designed to give its data up. Systems of record are built to record. They are optimised for putting information in reliably and getting a defined set of reports out. They are not built so that something else can read everything they hold and reason about it. That was never the requirement.
Which means the gap between "we have all this data" and "we can ask questions of it" is wider than almost every business expects. It is also where inexperienced projects lose their first three months.
The distinction that changes everything
Here is the most useful thing I can tell you, and it took a live engagement to make it obvious even to us.
Your system knows how something was coded. It does not know what actually happened.
Think about a supplier invoice. Your finance system records that $14,200 went to a supplier, against a general ledger code, in a period, approved by someone. All correct, all auditable, and almost useless for the question you actually want answered.
The invoice itself holds the answer. It has line items. It has unit rates. It has quantities, part numbers, freight charged separately, a fuel levy that appeared last quarter and nobody noticed. The rate that has quietly crept up eleven per cent over eighteen months lives on the document. The system only ever saw the total and the code.
I have seen the same pattern in job costing, in stock transfers, in subcontractor claims. The summary is in the system. The meaning is in the document, or in the head of the person who entered it, or in a spreadsheet on someone's desktop that has become load-bearing without anyone deciding it should.
So when a business tells me their data is in their ERP, what they usually mean is that the transactions are in their ERP. That is not the same thing, and the difference is most of the value.
Five things that break
When we go looking for usable data, the same five problems turn up in roughly the same order.
Table structures are not obvious. Mid-market systems have accumulated twenty years of schema decisions, most of them sensible at the time. The field you want is not called what you would call it. The relationship you need is implied rather than enforced. There is a table that looks exactly right and is actually a deprecated copy from a migration in 2014 that nobody dared delete.
Customisations change what fields mean. This one is specific to the mid-market and it is why generic data consultancies struggle here. Eighty to ninety per cent of the systems I have worked on have meaningful customisation running. A user-defined field that was repurposed six years ago now carries the only reliable record of something important, and there is no documentation, because the person who did it explained it verbally to someone who has since left.
The same concept is recorded three different ways. Depending on who entered it and when. One branch abbreviates. One salesperson puts the reference in the description field because the proper field was mandatory and they were in a hurry. A supplier is in the system four times because of a merger, a spelling variation, a trading name and a typo. Every one of those is a separate entity to a query and the same entity to your business.
Master data drifts. Not dramatically, just steadily. Codes get reused. Cost centres get restructured and history is not restated. A product is discontinued and the code is recycled for something unrelated. Any analysis that spans more than about three years has to account for this, and if it does not, it will produce a confident trend line describing something that never happened.
The system that matters most often has no usable interface. Frequently the highest-value data sits in the oldest or least-loved tool. A scheduling system, a bespoke database, a machine that writes to a shared drive. No API, no documentation, occasionally no vendor.
None of these are exotic. All five are ordinary. That is the point.
What "usable" actually means
Because "we need our data to be AI-ready" is the vaguest phrase in this industry, we use four tests. Data is usable when it is:
Complete enough for the question. Not complete in the abstract. Complete for the specific decision you want to improve. These are very different standards, and conflating them is how a data project becomes a two-year data project.
Verified rather than assumed. If a value was extracted, inferred or transformed by something, you need to know how confident to be in it. This one caught us out, and I will come back to it.
Linked back to the system of record. An extracted line item that cannot be traced to the transaction it came from is an orphan. It might be interesting. It cannot be acted on, because nobody can check it.
Current. A one-off extract decays from the moment it is taken. Any improvement built on a snapshot is a temporary improvement, and the business will quietly stop trusting it about four months in.
Miss any one of these and you can still build something that demos beautifully. You will not build something anyone relies on.
The example that changed how we scope
We ran a proof of concept for a high-volume distribution business. Several years of historical invoice extraction data, loaded into a segmented cloud environment, queryable in plain language. The purpose was to establish whether the analysis they wanted was possible.
Two findings came out of it. The first was the one we expected: yes, the analysis was possible, and it was more useful than anyone had assumed.
The second was not what anyone wanted to hear. The existing extracted data was not reliable enough to make decisions on. Duplicates. Fields that had been captured but never verified. Line items with no dependable link back to the coding and master data in the finance system. Individually small problems. Collectively, a foundation that would have produced confident answers nobody should have trusted.
So we rescoped. Rather than build the analysis layer on data we now knew was weak, the next phase went into establishing a verified foundation: re-reading the source documents with independent verification, linking every line back to the coding and master data, and keeping it current so the gains hold instead of decaying.
That conversation was not comfortable. It was considerably less uncomfortable than the alternative, which was a business making purchasing decisions on numbers that looked authoritative and were not.
The proof of concept cost a fraction of the build. It changed the plan. That is exactly what it was for.
The plumbing got easier. The problem did not move.
I want to be careful here, because there is a genuine advance worth acknowledging.
Connecting a model to a business system used to be a bespoke integration project every time. It is now much less so. The Model Context Protocol has become a common standard for exposing tools and data to a model, and the practical effect is real: the connection layer is no longer the hard part.
But the connection was never the hard part. What a model can reach is a plumbing question. What it can correctly understand is a data question, and no protocol solves that for you. Anthropic's own engineering team has written well on context engineering as a discipline, and the framing that has stuck with me is that context is a finite resource to be curated rather than a bucket to be filled. Give a capable model a poorly curated view of your business and it will answer fluently and wrongly. That is worse than not answering at all, because a fluent wrong answer gets acted on.
The line I keep coming back to, from a conference session last year, is that better models do not fix fractured context. Every model release since has made me more confident that is true. The reasoning keeps improving. The failures we see in production are almost never reasoning failures.
Where I would start
If you are looking at this in your own business, the order matters more than the tooling.
Pick the decision, not the dataset. Start from a decision somebody makes badly or slowly today, and work backwards to the data it needs. Starting from the data produces a warehouse and no answers.
Inventory before you integrate. Which systems hold what, what condition it is in, what is duplicated, what is missing. A day of this saves weeks. It is also useful independently of AI, which is why it is the one deliverable nobody regrets.
Test on the messy version. Whatever you build, build it on production data with all its inconsistencies. If your prototype only works on a cleaned extract, you have proved nothing about production.
Insist on the working being shown. Any output your people will act on needs to carry its reasoning and a confidence signal. Not for elegance. Because that is how a human knows where to check, and checking is what builds trust in the first six months.
Resist the urge to fix everything first. Data condition is a finding, not a prerequisite. Most businesses assume theirs is worse than it is and are wrong about which parts. You will discover the real state faster by attempting one specific thing than by commissioning an audit.
The unglamorous conclusion
New Zealand's adoption problem is not access to the technology. The AI Forum's review of adoption studies suggests somewhere between forty and eighty per cent of New Zealand organisations are using AI in some form, depending how you count, while only around 2.7 per cent of the workforce have it genuinely embedded in how they work. Xero's research found sixty-one per cent of NZ small and medium businesses using AI tools and, at the same time, a real lack of clarity about how to bring it into daily operations. MBIE's own assessment of barriers to AI uptake lands in a similar place.
That gap between using AI and getting value from it is not a model gap. It is the distance between a business's data as it exists and a business's data as something can reason about.
Closing that distance is unglamorous work. It is table structures and duplicate suppliers and a user-defined field that means something nobody wrote down. There is no keynote in it.
It is also, as far as I can tell, the whole job.
Vlad Kozak leads Ideation Partners, a data and AI consultancy in Auckland. The practice is backed by Verde Group, whose teams have implemented and supported the systems New Zealand businesses run on for more than twenty-five years.
If you are working out where the return is in your own business, we run a Discovery Workshop that maps exactly this. Or take a free hour and we will tell you honestly whether there is anything here worth doing.
