Data infrastructure is why your AI pilot is failing

Most Australian mid-market AI pilots don't fail because the model is wrong. They fail because the data isn't ready. Here's what that means and how to fix it.

title: "Data infrastructure is why your AI pilot is failing" dek: "Most Australian mid-market AI pilots don't fail because the model is wrong. They fail because the data isn't ready. Here's what that means and how to fix it." category: "DATA" publishedAt: "2026-05-16" readTime: "9 min read" author: "EasiraAI editorial team" keywords:

data infrastructure for AI
AU mid-market data engineering
AI pilot failure data quality

The AI pilot is three weeks in and it is not working. The model is producing outputs that are occasionally useful and frequently wrong. The vendor is suggesting the model needs more fine-tuning. Your team is losing confidence in the whole initiative.

In most cases, the model is not the problem. The data is.

This is the pattern we see consistently across Australian mid-market AI engagements: a firm invests in an AI build — a RAG application, a document classifier, a prediction model — without first solving the data infrastructure questions that determine whether the AI can work at all. The result is a pilot that generates a lot of internal scepticism and very little business value.

What "data readiness" actually means

Data readiness for AI is not the same as having data. Most mid-market firms have plenty of data. The question is whether it is in a form that an AI system can use reliably.

There are four dimensions that matter:

Accessibility. Can the AI system reach the data it needs? In a surprising number of mid-market firms, the relevant data is locked in systems with no API, exported to spreadsheets on someone's desktop, or sitting in a legacy database that hasn't been connected to anything modern. If your AI has to query a 2012 SQL Server instance via a fragile ODBC connection, the pilot will have infrastructure problems before it has model problems.

Quality. Is the data complete, accurate, and consistent? Mid-market firms often have years of historical data that looks complete but contains systematic errors — fields that were optional until three years ago, free-text fields that were repurposed for different things over time, duplicate records from CRM migrations that were never cleaned. AI models are particularly sensitive to this kind of structural inconsistency.

Structure. Is the data in a form the model can use? A RAG application needs documents that are properly chunked, indexed, and retrievable. A prediction model needs structured features — not raw transactional data, but derived fields that represent the patterns the model needs to learn. A document classifier needs labelled training examples. Generating these inputs from raw data is data engineering work, and it typically takes 30–50% of the total project time.

Freshness. Does the data reflect current reality? An AI system trained or calibrated on six-month-old data in a fast-moving environment will make stale recommendations. The pipeline that keeps the data current — the ETL/ELT layer, the scheduled extractions, the monitoring that catches when an upstream source has changed format — is as important as the initial data load.

The majority of AI pilot failures in Australian mid-market trace to data quality and availability issues that were not surfaced before the AI build started. This is not a model problem. It is a data engineering problem, and it has a solution.

The specific failure modes

Failure mode 1: The RAG application that retrieves noise

Retrieval-augmented generation is the dominant architecture for internal knowledge assistants in 2026. The idea is straightforward: index your internal documents, and when a user asks a question, retrieve the relevant passages and have the model answer from them.

The problem is that "your internal documents" for most mid-market firms means: a SharePoint with inconsistent folder structures and files that haven't been reviewed since 2019, a mix of Word documents, scanned PDFs, and email threads, policies with multiple version numbers and no clear canonical version, and a significant proportion of content that is outdated or simply wrong.

If you index that corpus as-is, the RAG application will retrieve noise alongside signal. The model will produce answers that mix current policy with superseded policy, confident answers from unreliable sources, and — worst of all — confident-sounding hallucinations anchored to real but stale documents.

The fix is not a better retrieval algorithm. It is a document governance and preparation step before indexing: reviewing and culling the corpus, establishing canonical versions, chunking and tagging documents with meaningful metadata, and putting in place a process for keeping the index current. This is unglamorous work. It is also the difference between a RAG application that is useful and one that erodes trust in AI.

Failure mode 2: The prediction model with no features

A mid-market firm wants to build a churn prediction model. They have three years of customer data in their CRM and Xero. They commission a model build.

What they don't have is features — the engineered signals that the model needs to distinguish churning customers from retained ones. Raw transactional data is not features. A feature might be: "number of support tickets in the 60 days before renewal," "rate of change in usage over the last quarter," "payment days outstanding as a rolling average." Deriving these features requires joining data across multiple systems, handling missing values, and making deliberate choices about what signals matter.

Most mid-market firms have not done this feature engineering work because they have not needed to. Their CRM and finance systems have been used for operational purposes, not analytical ones. Getting from "we have three years of data in our CRM and Xero" to "we have a feature matrix we can train a model on" is typically four to six weeks of data engineering work — and it needs to happen before the model work starts.

Failure mode 3: The automation that breaks on exception

Workflow automation relies on consistent inputs. An invoice processing automation that works for 90% of invoices and breaks for 10% will generate a manual exception queue that is worse than the original process — because now you have a two-track system to maintain.

The cause is almost always data structure inconsistency at the source: vendors who change invoice formats, OCR errors in scanned documents, missing required fields for certain invoice types, or edge cases in the rule logic that were not identified in the design phase.

The solution requires both data quality work (cleaning and standardising the source data to the extent possible) and deliberate exception design (a structured, monitored queue for the cases the automation can't handle cleanly, with SLA on human review).

Failure mode 4: The cloud AI calling on-premises data

A firm adopts an Azure OpenAI deployment — correctly, because their data should not leave their own cloud environment — and tries to connect it to data that lives on-premises in a SQL Server 2016 instance with a VPN connection that has a 30-second timeout.

The AI application works in demo conditions and fails in production when the VPN drops, the query takes too long, or the on-premises database is down for maintenance. Solving this requires either moving the data to the cloud or building a proper synchronisation layer — both of which are data engineering projects that should have been in scope from the start.

What good data infrastructure looks like for an AI project

You do not need a data warehouse and a full modern data stack to run a successful AI pilot. You need:

A stable, accessible data source for the specific data the AI needs. This might be a read replica of your production database, an API from your core system, or a scheduled export to a cloud storage bucket. The key word is stable — the connection should not be fragile, and the format should not change without warning.

Documented data quality for the specific fields the AI will use. Not across your entire data estate — for the specific inputs to this specific AI application. What is the completeness rate? What are the known error types? What data goes missing and why?

A pipeline that keeps the data current. Depending on the use case, this might be a daily batch job or a near-real-time stream. It needs monitoring and alerting so you know when it stops working.

A vector store or feature store if the AI architecture requires one. These are not complex to set up, but they need to be set up correctly — the chunking strategy, the embedding model choice, and the retrieval evaluation are technical decisions that affect system quality.

A data card or lineage document that describes the provenance, quality, and known limitations of the data. This is a Privacy Act 2026 and GfAA Practice 3 requirement for AI systems that use personal information — but it is also just good practice.

The sprint approach

The AI-Readiness Data Infrastructure Sprint is designed for exactly this situation: a firm that has committed to an AI initiative and needs the data foundation in place before the build starts. It typically runs for three to six weeks and covers:

Data readiness assessment against the specific AI use case requirements
Cleaning, structuring, and pipeline work for the specific data inputs needed
Vector store or feature store setup if required
A go/no-go recommendation with residual risks documented

It is not a full data platform build. It is the targeted work needed to get the specific data ready for the specific AI application — no more, no less.

For firms where the data infrastructure issues are more fundamental — fragmented source systems, legacy databases, no current ETL layer — the Modern Data Stack Build addresses the full foundation, including the AI-readiness layer.

How to know if this applies to you

The indicators that data infrastructure is your current AI bottleneck:

Your pilot has been running for more than four weeks and the outputs are still inconsistent
The AI vendor's suggested fix is "more data" or "better prompts" but the fundamental output quality hasn't improved
You cannot answer "where does the data come from and how current is it?" for the specific inputs to your AI system
Your data lives in systems with no API, or in spreadsheets managed by specific people
You have done a CRM or ERP migration in the last three years and the data quality from the old system was not systematically reviewed

If any of these are true, the data infrastructure question needs to be answered before the AI build continues.

Want to understand whether data infrastructure is blocking your AI initiative?

The AI Readiness Audit includes a data readiness scorecard across your core data domains — a two-week, fixed-fee assessment that tells you what needs to be fixed before you build. Book a discovery call to talk through your situation.