How to Get AI Into Production When Your Data Is Not Ready
Here is the situation most technical teams find themselves in.
The business has approved an AI initiative. The use case is legitimate. The model has been selected. And then someone runs an honest assessment of the data that is supposed to feed it, and the picture is not great. Inconsistent formats across source systems. Missing values in critical fields. Historical records that were entered manually and contain errors nobody ever bothered to fix because the old system worked around them. Duplicate records that have been accumulating for years. Data that exists in three places with three different versions of the truth.
The instinct at this point is to pause the AI project and fix the data first. Clean everything up.
Standardise the formats. Resolve the duplicates. Build a proper data foundation and then come back to the AI.
That instinct is understandable. It is also frequently wrong.
Waiting for perfect data before deploying AI is a trap that keeps organisations in pilot mode indefinitely. The data is never fully clean. The remediation work always takes longer than planned. And by the time the foundation looks ready, the business has lost confidence in the initiative and moved on to the next priority.
The approach that actually works is different. It involves being honest about what the data can and cannot support right now, deploying AI against the use cases where the data is good enough, and building the data foundation in parallel rather than sequentially.
Here is how to do it.
Start With a Data Readiness Assessment, Not a Data Cleaning Project
The first move is not to start fixing the data. It is to understand which data problems actually affect the specific AI use case you are trying to deploy, and which ones do not.
This sounds obvious. In practice, most organisations either skip the assessment entirely and discover the problems in production, or they assess everything and end up with a remediation list so long that the AI project gets deprioritised while the data team works through it.
A useful data readiness assessment is scoped to the use case. If you are deploying an AI system to automate invoice processing, the relevant assessment covers the data fields that the invoice processing workflow depends on. The state of your customer records or your product catalogue is irrelevant to that deployment, even if those datasets have their own quality problems.
For each field the AI use case depends on, you need to know four things. What percentage of records have a value in this field? Of those values, what percentage are in a consistent, usable format? Of those, what percentage are accurate? And what is the business consequence if the AI encounters a record where this field is missing, malformed, or wrong?
The answer to that last question determines how much remediation is actually required before deployment. Fields where a missing or wrong value causes a serious operational or compliance problem need to be fixed before you go live. Fields where the consequence is a degraded output that gets reviewed by a human before action is taken are manageable in production. Fields that the model can work around or infer from other signals may not need remediation at all.
This scoped assessment typically takes a week or two. It gives you a clear picture of where the blockers actually are rather than a general sense that the data is not ready.
Fix the Blockers. Manage the Rest.
Once you know which data problems actually block the deployment, you can split your remediation work into two categories.
The first category is pre-deployment fixes. These are the issues that would cause the AI system to produce outputs that are wrong in ways that could not be caught by a downstream review process. Null values in fields that the model requires to function. Formatting inconsistencies so severe that the system cannot parse the data. Duplicate records that would cause the model to see the same entity multiple times and treat them as different things.
These need to be resolved before go-live. In practice, this list is almost always shorter than the initial assessment suggests. Most data quality problems are irritants rather than blockers. The exercise of separating the two is where most of the value comes from.
The second category is in-production management. These are the issues that will affect model performance but in ways that are tolerable given the specific deployment context. Higher error rates on records from a particular source system. Lower confidence scores on predictions involving data from a specific time period. Edge cases that the model handles less well because the training data underrepresented them.
These are not ignored. They are monitored, measured, and addressed over time as the model is in production rather than before it. This is important because some data quality problems are only fully visible once a model is running against real workloads. Trying to fix everything before deployment often means spending significant effort on problems that turn out not to matter, while missing problems that do matter but only become apparent under production conditions.
Build the Data Foundation in Parallel
Deploying AI against imperfect data does not mean accepting imperfect data permanently. It means decoupling the data remediation work from the AI deployment timeline so that both can progress simultaneously rather than sequentially.
In practice this means running two workstreams in parallel once the pre-deployment blockers are resolved. The first is the AI deployment itself, getting the system into production, establishing the monitoring infrastructure, and beginning to generate real-world performance data. The second is the ongoing data foundation work, cleaning and standardising the broader dataset, building the integration pipelines that will improve data freshness and completeness over time, and addressing the quality issues that in-production monitoring surfaces as genuinely impactful.
This parallel approach consistently produces better outcomes than the sequential approach for two reasons. First, the AI system in production generates real feedback about which data quality problems actually affect performance, which allows the data remediation work to be prioritised against evidence rather than assumption. Second, the business sees the AI working in production, which maintains confidence in the initiative and sustains the organisational will to do the foundational work that makes it better over time.
What Good Data Looks Like for AI, Specifically
One of the reasons data readiness assessments go wrong is that teams apply generic data quality standards rather than the specific quality characteristics that AI systems actually require.
AI models are more tolerant of some data quality problems than enterprise reporting systems and less tolerant of others. A reporting tool breaks completely when a required field is null. An AI model can often handle missing values through imputation or by down-weighting records with incomplete data. On the other hand, a reporting tool is indifferent to subtle biases in the data distribution. An AI model trained on biased data will produce systematically biased outputs in ways that are much harder to detect and correct.
The data quality characteristics that matter most for AI deployments are completeness for the fields the model depends on, consistency in how values are represented across records and over time, representativeness of the training data relative to the population the model will encounter in production, and freshness relative to the rate at which the underlying patterns the model is learning are changing.
These are different from the quality characteristics that matter for a data warehouse or a reporting environment. Assessing readiness against the wrong standard leads to either over-investing in remediation that does not improve model performance or under-investing in the areas that do.
Getting From Assessment to Production
The practical path from where most organisations are now to having AI running in production looks like this.
Run a scoped data readiness assessment against your specific use case. Two weeks. Identify the genuine blockers and separate them from the manageable issues. Address the blockers. Build the monitoring infrastructure that will surface in-production data quality issues. Deploy. Begin the parallel foundational work while the model is live and generating real performance data.
The organisations that get AI into production and keep improving it over time are not the ones with perfect data. They are the ones that made honest, specific judgments about what was good enough for their use case, deployed against that standard, and built the foundation while the system was running.
At Contivos, our AI practice takes this approach on every deployment. We run the scoped readiness assessment, separate the blockers from the manageable issues, and get systems into production while the data foundation work continues in parallel. The result is AI that is generating real operational value while the infrastructure that will make it better is being built around it.
If your AI initiative is stalled at the data readiness stage and you want to work through what is actually blocking deployment versus what can be managed in production, visit contivos.com to start that conversation.
Comments