AI data readiness: build a spike before you fix the data
AI data readiness rarely comes first. A spike on imperfect invoice data showed one dealership group its real data gaps and the model to use.
"We did everything wrong in this project. We could not say what each stage should deliver, yet we went ahead anyway, and now we have something." Automotive dealership and service group manager
That manager's systems were not ready for an AI agent when the project began. AI data readiness is rarely something a company reaches before it starts. It finds out what "ready" means for its own systems by building something small on the data it has, with a named owner and an agreed point at which to stop.
This is the second article in our series on where AI adoption gets stuck. The first, AI process discovery: start with the data you already have, showed how to choose a workflow from the records it leaves. Our Process mapping for agentic AI: a step-by-step guide sets out all nine steps.
AI data readiness rarely arrives before the project does #
Companies usually handle unready data, from data silos to missing connections, in one of three ways. They launch a clean-up or data integration program first, they commission a readiness assessment, or they wait for the next ERP upgrade instead of integrating the legacy systems they already have. Each delays the first build, and none tells them which data the eventual system will actually need.
The risk they are guarding against is real, and it is not limited to enterprise AI programs. Gartner predicts that through 2026, organizations will abandon 60% of AI projects that are not supported by AI-ready data, and in its survey 63% of organizations either lacked or were unsure they had the right data practices for AI (Gartner, February 2025). An earlier Gartner prediction put at least 30% of generative AI projects on course to be abandoned after proof of concept by the end of 2025, with poor data quality among the causes (Gartner, July 2024).
We agree with the risk and disagree with the usual order of work. Planning still comes first, as Antoni Kozelski argued in The real cost of skipping transformation consulting. But a program that manages data before anything uses it has to guess which fields, documents and parts of the data flow matter. A small build replaces the guess with evidence, because an AI system shows which data it cannot use.
A spike answers one question with the data you have today #
Software teams have a name for this kind of build. A spike is a time-boxed piece of work that answers one question and may be thrown away afterward. It is meant for cases of real uncertainty, and overusing spikes delays value (Mike Cohn, Mountain Goat Software).
"We call it reconnaissance. You engage with the unknown to learn what you are dealing with before you commit all your resources." Bart Gonczarek, Co-founder and Chief Transformation Officer, Vstorm
AI prototyping tools now make a first version cheap to build, so the time box has to come from the team. A spike is a different thing from a proof of concept or a Proof of Value, and confusing them is how pilots end up in limbo. The table sets the three side by side.
| Spike | Proof of concept | Proof of Value | |
|---|---|---|---|
| Question it answers | What do we not know yet: is the data usable, can the systems be reached? | Can an agent do this task at all? | Does the agent meet the agreed metric on real work? |
| Time box | Short and fixed before it starts | Short, often open-ended | Set by the agreed test period |
| Data used | Whatever exists today, imperfect | A prepared sample | Real data and real users |
| What survives | The answer, sometimes the code | A demo and the lessons from it | The system, if it passes |
| Who decides the next step | The business owner, against an exit criterion set in advance | Usually the sponsor, often on impressions | The business owner, against the metric |
A proof of concept shows that something can work once; a production system has to keep working, a gap our AI tech lead Wojciech Achtelik describes in AI proof of concept vs production-grade agent. A spike sits earlier than both. Its job is to make the next decision possible, so an AI prototype built as a spike is judged by what it reveals about the data and the systems.
What a build on partial data showed an automotive dealership group #
The client is an automotive dealership and service group in Central Europe. Before the project, its accountants handled every incoming cost invoice by hand: they assigned it to a workflow type, matched it to the right contract, and wrote the analytical description the books require.
Our discovery work produced several candidate use cases, and the client chose three to start with. The systems behind them were not ready. The back-end systems did not offer the structured data access an agent would need, so any legacy system integration would have to be designed before it could be built. We built anyway, on the invoices and contract records that were available.
The build exposed the real gaps. The contract register stored annexes as separate contracts, and a single upload was sometimes split into several entries, so one agreement could appear as several contracts. Nobody had listed this as a problem, because nobody had tried to use the register this way before.
It also changed the minds of the people involved. Once the accounting team saw the system working on their own invoices, the question of what AI could do for them stopped being abstract.
"Until they saw it working on their own data, they did not know what they were dealing with. After that it was no longer magic. It was a system that gives good outputs when it gets good inputs." Bart Gonczarek
The results also settled questions we could not have answered on paper. For sorting invoices by workflow type, we compared two kinds of AI model: a large language model, and a random forest, a classic machine-learning model trained on features from the client's own rules. The language model reached a macro-F1 score of 0.63 on the test set; the random forest reached 0.93. Macro-F1 weighs every invoice category equally, so a model cannot score well by getting only the common ones right. The random forest has run in production since September 2026, scoring 0.95 from mid-September, and the language model's answer appears beside it only as a second opinion.
Matching invoices to contracts proved harder. When there is one candidate contract, the system picks the right one 94% of the time. When there are several, it ranks the right one first 64% to 72% of the time, and has it in its top two about 95% of the time. So it was designed to show a shortlist of likely contracts and let an accountant confirm, instead of matching on its own.
The spike costs more than a perfect plan and less than standing still #
The client's own verdict is the fairest summary. Had they known at the start what they know now, the project would have used fewer resources. But they could not have known it without building, and the alternative was not moving at all. What the company learned about its own data is an advantage that a later start could not have bought.
"Your organization is never going to be ready. What you build first will not be perfect, and that is fine as long as you improve it as you go." Bart Gonczarek
This approach has a limit, and we say so to clients. When the systems are ready and the process is well understood, a spike is wasted effort: go straight to a Proof of Value against an agreed metric. A spike earns its cost only where the uncertainty is real, and a team that runs one spike after another is postponing a decision.
A working system can still stall when its owner was not in the room #
The contract-matching system has run on the production servers since September 7, 2026. The accounting workflow does not call it. Nobody agreed who should trigger it, or at which point in the invoice process.
The cause sits outside the code. The manager responsible for that part of accounting was not involved while the system was built. When the team first saw it, they saw automation they had not asked for, and some of them worried about what it meant for their jobs. A system that works and is owned by nobody in the business is a cost with no return. It is also a risk to business continuity: if nobody owns it, nobody notices when it breaks.
The lesson we take from it: before a spike begins, name the business owner for the area it touches, and have that person sign the exit criterion.
How we scope a discovery build #
At Vstorm, a discovery build for an AI-powered workflow sits at the start of the Build stage of TriStorm, our delivery method. It feeds a Proof of Value, which then grows into a Minimum Viable Workflow and a full deployment. Our agentic AI consulting page describes the Proof of Value gate, where the project either meets its metric or stops.
We agree six things before the first line of code, and the answers shape how we design system integrations later:
- The one question the build must answer.
- The time box, fixed in advance.
- The data that exists today and will be used as it is.
- The named business owner for the area the build touches.
- The exit criterion that decides what happens next.
- What gets thrown away when the build ends.
If you are waiting for your data to be ready, write down the one question you would ask of it first. That question is the scope of your first build.
Next in this series #
The third article follows systems like this one past the build, into the teams that have to adopt them. It will appear on the Vstorm blog, and we will link it here. To be notified once it is online, subscribe to the Vstorm AI newsletter.
Sources #
- Gartner, Lack of AI-ready data puts AI projects at risk (60% of AI projects without AI-ready data abandoned through 2026; 63% of organizations lack or are unsure of AI-ready data practices), February 26, 2025
- Gartner, Gartner predicts 30% of generative AI projects will be abandoned after proof of concept by end of 2025 (abandonment after proof of concept, data quality among the causes), July 29, 2024
- Mike Cohn, Mountain Goat Software, Spikes (definition of a spike and the cost of overusing them)
