You ran the assessment. You sat down with your team, worked through the questions honestly, and found something you did not expect to find. Maybe it was the data, years of records with no labelling, no outcome signal, nothing a model can learn from. Maybe it was the use case, three people in the room describing three different problems the AI is supposed to solve. Maybe it was the infrastructure, cloud in place, but none of the logging or monitoring layers that keep a production ML system alive.
Whatever you found, you are not alone in finding it. These gaps appear in almost every pre-implementation assessment. The teams that succeed are not the ones that did not have them. They are the ones that found them early enough to close them deliberately rather than stumbling into them mid-build.
This article names the eight most common gaps, explains why they happen, tells you how long each one takes to close, and gives you a response framework for each one.
Why the gap is almost always bigger than expected
The gap between “we have approved the AI budget” and “we are ready to build AI that works in production” is almost always larger than the business case predicted. This is not a failure of ambition. It is a structural property of how AI projects are scoped.
Business cases for AI are written by people who are excited about the outcome. They account for model training costs, engineering time, and tooling. They almost never account for data labelling, which can take longer than the model training itself. They do not account for the infrastructure layers that keep a model alive after deployment. And they rarely account for the organisational work needed to get a business team to actually act on what the model produces.
According to McKinsey’s 2024 State of AI report, which tracks enterprise AI adoption across industries globally and identifies the primary barriers to realising value from AI investments, the most commonly cited barrier to AI value realisation is not technical capability, it is data quality and organisational readiness. The technology is available. The internal conditions to use it well are not.
The assessment is not a step that slows the project down. It is the step that prevents the project from being rebuilt from scratch six months after launch.
The 8 gaps companies consistently discover
These eight gaps appear so consistently across industries, company sizes, and team structures that they can almost be treated as default assumptions for any first AI project. The specific form they take varies. The gaps themselves are predictable.
Gap 1 - Data is collected but never labelled
This is the most common gap and the most expensive to close. Most companies have been storing data for years. Transaction logs, user behaviour events, support ticket histories, CRM records. The data exists. What almost never exists is the labelled version of that data, the version where each record is tagged with the outcome the model needs to learn from.
A churn prediction model cannot learn from a database of customer events. It needs a database of customer events where each record is tagged with whether that customer churned or did not churn within a defined period. That tag does not exist automatically. Someone has to create it deliberately, according to an agreed definition, at sufficient scale.
The fix is a labelling sprint – four to eight weeks of structured effort to define the labelling criteria, tag a representative sample, and validate the quality. The output is a training dataset. The prerequisite is agreement on what the label means, and that agreement is usually the part that takes the longest.
Gap 2 - No specific use case is defined
“We want to use AI to improve customer experience” is not a use case. It is an intention. It tells the engineering team nothing about what to build, how to evaluate it, or what success looks like.
A specific use case looks like this: “Predict which accounts are likely to churn in the 30 days before their renewal date, with a precision of at least 70%, so the customer success team can reach out to at-risk accounts before the renewal conversation.” That sentence contains the prediction target, the time window, the performance floor, and the business action. Everything the team needs to start building.
The fix is a problem definition workshop – a structured half-day session where the business, product, and engineering leads align on the target, the metric, and the action. The output is one sentence. The time investment is half a day. Teams that skip this spend months building something nobody can evaluate.
Gap 3 - The infrastructure is not wired for ML
Most SaaS companies have cloud infrastructure. AWS, GCP, Azure, some combination. They have databases, APIs, deployment pipelines. What almost none of them have, unless they have shipped a production ML system before, is the additional layer that production ML requires.
That layer includes: prediction logging (every model output stored with its input, timestamp, and model version), a model registry (versioned storage of model artefacts with the ability to roll back), and drift monitoring (automated alerts when the model’s input distribution or output distribution shifts beyond a threshold). These are not part of standard cloud infrastructure. They are addons that need to be designed and built as part of the AI project.
The fix is to treat these three components as required infrastructure, not optional enhancements. They should appear in the technical design before engineering begins. Teams that treat them as post-launch additions almost always regret it.
Gap 4 - Nobody owns the AI initiative
The engineering team is responsible for building the model. The data team is responsible for preparing the data. The product team is responsible for defining the use case. The business team is responsible for acting on the outputs. And nobody is responsible for making sure all four of those things happen in the right order, with the right dependencies, toward the same outcome.
This is the organisational gap. It produces a specific failure mode – each team does their part correctly, and the project fails anyway because the parts never connected. The data team prepares a dataset the engineering team trained on incorrectly. The engineering team builds a model the product team specified imprecisely. The product team ships a feature the business team never actually uses.
The fix is a single named initiative owner before any technical work begins. This person is responsible for the problem definition, the success metric, the cross-team dependencies, and the commitment to act on outputs. They do not need to be an ML expert. They need to be a product owner who takes accountability.
Gap 5 - The real cost is significantly underestimated
A typical AI project business case accounts for – cloud compute during training, engineering time for model development, and licensing costs for any tooling. It does not account for data labelling (which can cost as much as the model training itself), infrastructure additions (logging, registry, monitoring), ongoing retraining cycles (the model will need to be retrained periodically), and the engineering time required to maintain a production ML system over its lifetime.
According to Stanford University’s AI Index 2024, which tracks AI investment patterns and deployment cost trends across global enterprises, the total cost of ownership for a production AI system is typically two to four times the initial training and deployment cost when measured over a 12-month period. Teams that do not account for this in their business case run out of budget after the first deployment and have no capacity to maintain what they built.
The fix is a revised budget model that includes data preparation, infrastructure additions, and a 12-month maintenance estimate, not just the initial build.
Gap 6 - Compliance and regulatory review is skipped
For companies in fintech, healthtech, insurance, HR technology, or any sector where AI decisions affect people’s access to services or opportunities, compliance is not a post-launch consideration. It is a design constraint.
The compliance requirements for AI systems in regulated sectors include auditability (the ability to explain any model decision to a regulator), bias review (evidence that the model does not discriminate on protected characteristics), and data governance (documentation of where training data came from and how it was processed). These requirements do not get easier to satisfy after the model is built. In many cases they require architectural decisions, explainable model selection, audit logging at the data pipeline level, that are expensive to retrofit.
The fix is a compliance and regulatory review at the scoping stage, not the pre-launch stage. Bring legal and compliance teams into the design conversation before any data pipeline work begins.
Gap 7 - Training-serving skew is not anticipated
Training-serving skew is the gap between the data the model was trained on and the data it receives in production. It is one of the most common causes of AI feature underperformance, and it is almost entirely preventable.
It happens when the features used during training are computed differently than the features computed in the production pipeline. The model was trained on a 30-day rolling average of user logins, calculated offline. In production, the average is calculated on a slightly different time window because the pipeline runs at a different cadence. The difference is small. The degradation it causes compounds over time.
The fix is a data contract or feature store – a formal definition of how each feature is computed, shared between the training pipeline and the production pipeline, enforced by validation before any inference happens. This is a two to three week engineering effort that prevents months of debugging.
Gap 8 - Leadership commitment ends at budget approval
The model is built. The endpoint is deployed. The churn score is produced for every account, every week. And the customer success team is not using it because nobody told them to, nobody explained what it means, and nobody committed to a process for acting on it.
This is the gap that produces the most expensive outcome – a fully functional AI system that delivers zero business value because the business behaviour it was designed to change did not change.
The fix is explicit pre-launch commitment from the leadership team to one specific action that will be taken when the model fires. Not “we will use the outputs to inform our approach.” Something specific – “when the churn score exceeds 0.7, a customer success manager will reach out within 48 hours.” That commitment needs to be documented before the model is built, not after.
How long each gap takes to close
The most reassuring thing about these gaps is that most of them are closeable in weeks, not months. The longest gap to close is unlabelled data, typically eight to twelve weeks for a labelling sprint. Three of the eight gaps can be closed in a week or less: appointing an initiative owner, committing to a use case definition, and getting explicit leadership commitment.
The gap that teams underestimate most consistently is data labelling. Teams hear “we have the data” and assume the data is usable. The labelling sprint is the step between having the data and having training data. It is as important as the model training itself and needs to be planned as its own project.
Where each gap originates
Most of these gaps have a clear origin in one team’s work, even though they affect the whole project. Business teams are responsible for use case specificity, leadership commitment, and budget accuracy. Product teams are responsible for labelling criteria, failure mode documentation, and monitoring ownership. Engineering teams are responsible for infrastructure readiness, training-serving skew, and retraining triggers.
Knowing where a gap originates tells you who needs to close it. Asking engineering to fix a use case specificity problem is asking the wrong team. Asking the business to retrofit prediction logging is equally misplaced.
What to do when you discover a gap
Not all gaps require the same response. The three categories above, stop and fix first, pause and plan, continue with monitoring, give a decision framework for how to respond based on criticality.
Stop and fix first means do not start building until this is resolved. An unlabelled dataset, an undefined use case, and a missing initiative owner are all blockers. Starting the build before these are resolved guarantees rework.
Pause and plan means acknowledge the gap, assign an owner, set a resolution timeline, and continue with work that does not depend on this gap being closed. Infrastructure gaps and budget reforecasting can happen in parallel with early-stage design work.
Continue with monitoring means the gap is real but can be managed post-launch if it is explicitly owned and has a documented plan. Training-serving skew risk and incomplete leadership commitment fall into this category, they should not stop the build, but they should be tracked as open risks with named owners.
If your team has just completed a readiness assessment and found one or more of these gaps, connect with our experts to understand how to close them efficiently and prepare your AI initiative for production success.
Your queries, our answers
Yes, and finding them is the point of the assessment. Most organisations running their first AI project will find between three and five of these gaps. Finding them before the build begins is significantly cheaper than finding them during or after. The assessment is not a grading exercise it is a gap identification exercise.
A use case is specific enough when it answers four questions - what is the model predicting, in what time window, to what performance standard, and what will the business do with the output. If any of these four answers is missing or vague, the use case is not specific enough to build from.
Training-serving skew is the difference between how features are calculated during model training and how the same features are calculated in the production inference pipeline. Even small differences, different time windows, different aggregation logic, different null handling, cause the model to behave differently in production than it did in testing. The gap is almost always preventable with a data contract defined before the build begins.
For most of the gaps, yes. Use case definition, initiative ownership, leadership commitment, and labelling criteria are business and product problems, not ML problems. Infrastructure gaps and training-serving skew require engineering expertise, but they are well-understood engineering problems with documented solutions. The hardest gap for a small team to close independently is data labelling at scale, that typically requires either a labelling tool, an external labelling service, or a dedicated sprint by people who know the domain.
What happens after you fill-up the form?
Request a consultation
By completely filling out the form, you'll be able to book a meeting at a time that suits you. After booking the meeting, you'll receive two emails - a booking confirmation email and an email from the member of our team you'll be meeting that will help you prepare for the call.
Speak with our experts
During the consultation, we will listen to your questions and challenges, and provide personalised guidance and actionable recommendations to address your specific needs.
