Five Signs Your Production Data Isn't Ready for AI — And What a Real Foundation Looks Like

A while back we argued that your Power BI dashboards aren’t the problem — the data foundation under them is. The most common reply was a fair one: fine, but how do I know whether mine is ready?

The question has teeth now, for a specific reason. Reporting has always tolerated a shaky foundation, because a person reads the chart and applies judgment — “that number looks off, let me check.” Point an agent at the same data and you remove the person and add confidence. The foundation stops being a quality issue and becomes an operational one.

So here are five signs, drawn from the systems a mid-market producer actually runs — whether you call it a plant, a fab or a site. None is about your dashboards. Each is about the estate underneath — and each behaves very differently once software, rather than a person, does the reading.

Five signs your production data isn’t ready

1. Every new project starts by re-extracting the same data

Quality wants a report. IT writes an extract from the ERP. Two months later Operations wants something adjacent, and someone writes a second extract from the same tables, into a different place, shaped a different way. Nobody is doing anything wrong — there is simply no shared place to put it, so every project pays the integration cost from scratch.

With an agent: an agent needs somewhere to read from continuously, not a one-off extract someone refreshes when they remember. With no landing place, every agent you build is its own integration project and the cost never amortizes — which is exactly why the second and third use cases quietly never get funded.

2. The same part carries three different identifiers

The ERP knows it as a part number. The MES knows it by a machine code. The supplier’s certificate of analysis uses their own SKU. Somewhere there is a lookup spreadsheet one person maintains, and everyone else reconciles it in their head. It works, because humans are good at knowing that 4051-A and 4051A are the same thing.

With an agent: software joins on the string. It finds no match, returns nothing, and reports zero defects for a part that had eleven. This is the most dangerous item on the list, because the failure is silent — and silence reads as good news.

3. You can’t reproduce last quarter’s number

Finance revises what counts as scrap — or yield loss — in March. Someone asks how last year looks under the new definition, and nobody can say: the tables were updated in place, and last quarter now exists only as a PDF in a shared folder. The number can be quoted but not rebuilt.

With an agent: the follow-up to any AI answer is “why did that change?” Without versioned history you can’t audit the answer or re-run the question under the definition that applied at the time. In medtech, or anywhere near a regulated customer, that isn’t an inconvenience — it’s an audit finding in waiting.

4. Machine data has never met business data

The historian holds cycle times, temperatures and downtime second by second. The ERP holds orders, costs and customers. Both are well run. They have never been joined, because joining them was always phase two of a project that ended at phase one.

With an agent: the questions worth paying for are precisely the joins. Which machine settings correlate with scrap on this customer’s part? needs both sides. Keep them apart and you’ve capped AI at the questions you could already answer without it — the most common reason a pilot demos well and then quietly stops mattering.

5. Access is all-or-nothing, and nobody can trace where a number came from

Getting data means either full access to a system or a spreadsheet someone emails weekly. There is no middle setting. And when a figure is challenged, tracing it back is archaeology: which extract, which refresh, whose filter.

With an agent: an agent inherits whatever access you give it and answers with the same confidence either way. Without column- and row-level control you can’t scope what it sees; without lineage you can’t explain where its answer came from. Both questions arrive the day someone senior asks it something sensitive.

The same five gaps you already live with — and what each becomes when software does the reading.

	Today it’s an annoyance	With an agent it’s a liability
No landing place	Every project budgets its own extract	Every agent is a fresh integration — the cost never amortizes
Three IDs, one part	Someone reconciles it by hand	The join returns nothing, and silence reads as good news
No reproducible history	You argue about last quarter in meetings	You can’t audit the answer or re-run it under a new definition
Machine data stranded	The best questions stay unasked	AI is capped at what you could already answer without it
No lineage, coarse access	Reports get emailed around	You can’t scope what it sees or explain where an answer came from

What it costs to leave it

This is not a niche condition. In a Gartner survey of data management leaders, 63% of organizations either don’t have the data management practices AI requires, or aren’t sure whether they do. The second half of that sentence is the more telling one: most teams cannot answer the readiness question about themselves.

The cost arrives as a tax rather than a line item, which is why it rarely gets challenged. Every use case re-pays for the same extracts, the same reconciliation, the same argument about whose number is right. The first pilot absorbs it as “setup.” The second pays it again. By the third, AI has acquired a reputation for costing a lot and shipping slowly — and the conclusion drawn is that the technology disappointed, when the same groundwork was funded three times and finished none.

You might not need a foundation yet

Here is the part most vendors leave out: not every AI use case needs one, and building one you don’t need is its own kind of failure. Plenty of valuable work runs on documents rather than on your data estate. An agent that reads supplier invoices, checks them against the contract and routes them for approval works on the documents themselves — we’ve built exactly that, and it needed no lakehouse and no platform program. If your first use case looks like that, start there and get a win on the board.

“Yes” to either of the last two and you’re not looking at an AI project — you’re looking at a data foundation with an AI use case on top of it. That’s a better problem to have, because it’s a solved one: the shape is well understood, it can be built in stages, and the first stage is smaller than most people expect. We walk through it component by component in our reference architecture piece.

The uncomfortable part of this list isn’t any single sign. It’s that most teams recognise three or four immediately, and have been working around all of them for years. That isn’t a failure of anyone’s engineering — it’s what happens when systems get bought one at a time to solve one problem each. What changed is that the workaround used to be free.