Data Feasibility as a Hard Gate
Why AI Wave 1 Fails When Data Readiness Is Assumed
Most AI programmes do not discover their data problem. They discover it six months in — after the use case is committed, the sprint plan is running, and the budget is spent.
The data issue surfaces the same way almost every time. A data engineer is finally given access to the dataset that underpins the Wave 1 flagship use case. They run a profiling job. The results come back: 38% null values in the primary feature field. Three different date formats across historical records from two system migrations. A subset of customer records that includes personal data under DPDP consent requirements that were not flagged at selection stage.
None of this was a secret. The data was always like this. What was secret — because nobody looked — was the scale of the problem and the cost of fixing it inside an already-committed programme timeline.
The business unit owner, when told the data is not ready, does not accept this as new information. They say the data has been there for years. They are correct. What they mean by 'the data is there' and what an ML model requires from the data are two entirely different things — and the gap between them is where Wave 1 programmes go to stall.
EXECUTIVE SUMMARY
Four compounding failures that make data readiness the leading cause of AI Wave 1 collapse:
- Data readiness is treated as a business assertion, not a technical assessment — 'the data exists' enters the record unchallenged.
- Compliance obligations — DPDP, GDPR, sector-specific — are discovered mid-build, after training data has already been processed.
- Data preparation work is absorbed into delivery sprints, consuming the capacity budgeted for model development.
- Wave 1 cannot be restructured without visible programme failure — because no formal gate existed to catch the problem before commitment.
'The Data Exists' Is Not a Data Readiness Assessment
The phrase 'the data exists' is one of the most dangerous phrases in enterprise AI programme planning. It is technically defensible and practically meaningless.
Data that exists somewhere in an organisation's estate is not the same as data that is ready for AI use. The distance between those two states is where the majority of AI programme delays originate — and it is a distance that remains invisible for as long as the programme relies on business unit assertions rather than technical assessments.
What 'Data Exists' Actually Tells You
When a business unit owner says the data exists, they are typically confirming that historical records are held in a system they have access to, that the data has been used for reporting or analytics previously, and that they see no obvious reason it cannot be used for AI.
None of these confirmations address the questions that determine AI data readiness. They do not address null rates in the specific feature fields the model requires. They do not address whether historical labels are consistent across system migrations, time periods, or data entry practices. They do not address whether the volume of usable records, after quality filtering, is sufficient for the target model architecture. And they do not address whether any of the data can legally be used for AI training.
REALITY CHECK
Data that has served perfectly well for monthly management reporting will frequently be completely inadequate as AI training data. Reporting tolerates gaps, inconsistencies, and manual overrides. Model training does not.
The Assessment That Actually Answers the Question
A data readiness assessment for AI purposes requires a data engineer — not the business unit owner, and not the programme manager — to run a structured profiling exercise on the actual dataset. The output must cover four things: completeness (null rates and missing value patterns across all key feature fields), consistency (schema alignment, format standardisation, and label integrity across time periods and source systems), volume (whether the number of clean, usable records is sufficient for the target model approach), and compliance (whether the data can legally be used for AI training, inference, and output generation under applicable regulations).
That assessment does not take six weeks. A first-pass profiling exercise on a well-structured dataset takes one to two days. On a complex, multi-source dataset it may take a week. Either way, it is a fraction of the cost of discovering the same problems at Sprint 4 of a Wave 1 build.
How Data Assumptions Compound Into Programme Failure
The pattern of data assumption to programme failure is not a single event. It is a sequence — and each step in the sequence makes the next one more expensive.
The Data Assumption Failure Timeline
Illustrative timeline — composite of common enterprise AI programme patterns. Source: AI Use Case Prioritisation Framework — viksya.com
The timeline above is not a single organisation's experience. It is a composite of the pattern that plays out when data readiness is assumed rather than assessed — and the reason each stage is more expensive than the previous one is that commitment has accumulated. By Month 5, changing the use case is not a simple rescoping. It is a programme restructure that requires explaining to a steering committee why the flagship use case is being demoted.
The cost of a data readiness assessment before selection is one data engineer for one to five days. The cost of discovering data unreadiness at Sprint 4 is measured in months, not days — and in steering committee credibility, not just programme budget.
Why Compliance Is the Hardest Data Readiness Gap to Recover From
Most data quality problems — null rates, inconsistent labelling, insufficient volume — are remediable with time and engineering resource. They are expensive to discover late, but they are solvable.
Compliance problems are different. A dataset that cannot legally be used for AI training because of unfulfilled consent requirements, jurisdictional data residency constraints, or unresolved intellectual property issues does not become usable by adding data engineering sprints. It requires legal resolution, which operates on a different timeline from programme delivery — and which may not resolve in time for the Wave 1 schedule at all.
The Regulatory Dimensions Most Programmes Miss
Three regulatory dimensions are most commonly missed in AI data readiness assessments.
- Data protection and consent: Under India's Digital Personal Data Protection Act (DPDP) and the EU's GDPR, personal data used for AI training requires a lawful basis — typically consent or legitimate interest, with specific requirements depending on data category. Many enterprise AI programmes discover mid-build that their historical customer data was collected under consent language that does not cover AI training or inference use.
- Data residency and transfer restrictions: Some jurisdictions restrict the transfer or processing of certain data types outside the country of origin. For enterprise AI programmes using cloud-based training infrastructure, this creates compliance obligations that are not always visible in the data itself — only in the regulatory framework that governs it.
- Sector-specific obligations: Healthcare, financial services, and public sector AI programmes face additional data use restrictions that go beyond general data protection frameworks. The specific obligations vary significantly by jurisdiction and sector — and 'we've used this data for analytics before' does not constitute a compliance clearance for AI training use.
COMPLIANCE GATE
A compliance review is not an IT security review. It requires input from legal, privacy, and where applicable, the DPO — and it should be initiated before use case selection is finalised, not after build has started.
The Hard Gate: What It Is and Why It Cannot Be Overridden
The term 'hard gate' has a specific meaning in the context of AI use case prioritisation. It is not a strong preference or a high-weighted scoring criterion. It is an absolute rule that overrides composite scoring regardless of performance on every other dimension.
The rule is this: any use case with a Data Feasibility score below 2.0 cannot enter Wave 1. It is automatically assigned to Wave 2, or parked for foundational data work, regardless of its Business Value score, its Technical Complexity profile, its executive sponsor, or its composite ranking.
Why a Composite Score Cannot Compensate for Data Unreadiness
The logic behind an absolute gate — rather than simply a high-weight dimension — is straightforward. Data unreadiness does not just reduce a use case's chance of succeeding. It creates a compounding drag on every other use case in Wave 1 by consuming data engineering resource, delaying sprint starts, and occupying programme management attention that was budgeted elsewhere.
A use case with exceptional Business Value that is data-unready does not deliver that Business Value in Wave 1. It delivers Wave 1 delay while its data issues are resolved. The Programme Manager who allowed it into Wave 1 on the strength of its composite score is not accelerating value delivery. They are front-loading programme risk.
What Happens to a Parked Use Case
Parking a use case is not a rejection. It is a structured deferral with a defined remediation path. A use case that scores 1 on Data Feasibility is redirected to a data preparation workstream — typically a parallel track that runs alongside Wave 1 delivery, focused on profiling, cleaning, labelling, and compliance clearance.
When the data preparation workstream produces evidence that the dataset now meets the minimum readiness threshold — documented profiling results, compliance sign-off, a data engineer's assessment — the use case is eligible for re-scoring and potential promotion to Wave 2.
The gate is a delay, not a disqualification. But the delay must be acknowledged explicitly, planned for, and resourced — not absorbed silently into the Wave 1 sprint capacity.
The Five Evidence Questions That Replace Assumption
A data readiness assessment for AI use case prioritisation is not a lengthy process. It is five targeted questions, directed at the right people, requiring actual evidence rather than stakeholder assertions. The questions below are the core evidence prompts from the Data Feasibility scoring dimension in a structured AI use case prioritisation process.
Data Feasibility Evidence Assessment — Five Questions Before Any Use Case Enters Wave 1
Source: AI Use Case Prioritisation Framework — viksya.com. D2 — Data Feasibility evidence prompts.
The critical discipline in applying these questions is direction: they must be answered by the person with direct technical knowledge of the data, with reference to specific artefacts — profiling reports, compliance assessments, data dictionaries. Not by the business unit owner. Not by the programme manager. Not by an estimate.
DISCIPLINE
A business unit owner who answers 'yes' to all five questions is not providing a data readiness assessment. They are providing a business assertion. Assessments require evidence. Assertions require challenge.
The Data Feasibility Scoring Reference
The five evidence questions above map directly to the five score states in the Data Feasibility dimension of a structured AI use case prioritisation framework. Each score level reflects a specific evidential state — not a qualitative judgement about how data-ready the team feels.
D2 — Data Feasibility Scoring Reference (Weight: 25% of Composite Score)
Source: AI Use Case Prioritisation Framework — viksya.com. Any score below 2.0 triggers automatic Wave 2 assignment regardless of composite rank.
The scoring convention is worth noting: a score of 3 — 'Work Required' — does not automatically disqualify a use case from Wave 1. It flags that a conditional Wave 1 path is possible only if the data preparation work is planned as an explicit Sprint 1 deliverable, with dedicated resource and a defined done criterion. What it does not allow is the assumption that data preparation will 'happen in the background' while model development proceeds simultaneously.
What Honest Scoring on D2 Looks Like in Practice
The most common D2 scoring error is aspirational scoring: entering a 3 or 4 because data preparation is planned, rather than because evidence of readiness exists today.
Aspirational scoring is not dishonesty. It is a natural response to the incentive structure of a prioritisation session — scoring low means your use case gets demoted, and that is uncomfortable when you are the business unit owner who has been advocating for it. The structural fix is to separate the scorer from the use case owner: data feasibility scores should be entered by the data engineer, not the business unit, and challenged against actual profiling evidence rather than stakeholder enthusiasm.
Three Conversations That Produce Aspirational D2 Scores
- 'Sprint 1 is data preparation, so by the time we actually build the model the data will be ready.' This justifies a score of 3 or 4 when the current state warrants a 2. The score should reflect the current state. If Sprint 1 is data preparation, the current score is 2. The Sprint 1 plan is the remediation path, not the score justification.
- 'We've used this data for analytics for three years — it's well-understood.' Analytics and model training have different data quality requirements. The fact that data has served an analytics purpose does not evidence its suitability for AI training. Score the training readiness, not the analytics history.
- 'We can't score lower than a 3 or the use case will be blocked.' This is the HIPPO effect applied to data readiness. The scoring framework exists precisely to make this pressure transparent and resistible. The data engineer's profiling output is the evidence. It is not negotiable.
The programme team's role in D2 scoring is to ensure the evidence prompt is answered by the right person, with reference to a real artefact, before the score is entered. That is not obstructionism. It is the only version of data readiness assessment that protects the programme.
The Gate Exists to Protect the Programme, Not to Block Use Cases
The Data Feasibility hard gate is not a mechanism for saying no. It is a mechanism for saying not yet — with a clear, actionable path to when the use case will be ready.
Every use case that is parked or demoted by the D2 gate is a programme that has been protected from a predictable failure. The data problem that was surfaced by honest scoring at selection was always there. The gate moved the discovery to the cheapest possible point — before commitment — rather than the most expensive one — inside a running Wave 1 sprint.
Enterprise AI programmes that build this discipline into their use case selection process spend less time managing data crises mid-delivery. They spend more time in production. The two outcomes are not unrelated.
Data readiness is not a detail that gets resolved during build. It is a gate condition that must be met before build starts. The programmes that treat it as the former spend months recovering. The programmes that treat it as the latter spend months delivering.
AI Use Case Prioritisation Framework — viksya.com
The Data Feasibility hard gate described in this article is built into the AI Use Case Prioritisation Framework. Score up to 12 candidate use cases across five dimensions — including Data Feasibility as a hard Wave 1 gate — and receive an automatically ranked shortlist with wave assignments, portfolio balance checks, and priority flags. No data engineering assessment can be bypassed by a high score elsewhere.
Built for Programme Managers, CIOs, Strategy Leads, and Management Consultants. Excel-based. No code. Instant download.
→ Download the AI Use Case Prioritisation Framework
Frequently Asked Questions
What is AI data readiness?
AI data readiness is the state in which a dataset meets the minimum quality, completeness, accessibility, and compliance requirements for use in training or operating an AI model. It is distinct from data availability — data that exists in an organisation's systems may not be ready for AI use due to quality issues, format inconsistencies, insufficient labelled records, or unresolved regulatory compliance obligations. Assessing AI data readiness requires a structured technical evaluation by a data engineer, not a business unit assertion. For how to run that evaluation at the programme level, before any individual use case reaches this gate, see How to Assess Data Readiness Before an AI Programme.
What does a data feasibility hard gate mean in AI use case prioritisation?
A data feasibility hard gate in AI use case prioritisation is a rule that prevents any use case with insufficient data readiness from entering Wave 1 delivery, regardless of its score on other prioritisation dimensions such as business value or technical complexity. In the AI Use Case Prioritisation Framework from Viksya, any use case scoring below 2.0 on the Data Feasibility dimension is automatically assigned to Wave 2 or parked for foundational data preparation work. The gate cannot be overridden by composite score, executive sponsorship, or programme schedule pressure.
Why does data quality cause AI project failure?
Data quality causes AI project failure primarily because quality problems that are invisible before model development become blocking problems during it. Null values in key feature fields, inconsistent historical labels, insufficient clean record volume, and unresolved compliance constraints all directly prevent model training from proceeding on schedule. Discovering these problems at Sprint 4 of a Wave 1 build — after programme commitments and timelines have been set — is categorically more expensive than discovering them at selection, because the cost of recovery now includes timeline restructure, stakeholder communication, and in some cases, use case demotion.
How does the DPDP Act affect AI data readiness in India?
India's Digital Personal Data Protection Act (DPDP) creates specific obligations around the use of personal data for AI purposes. Data collected from Indian residents for one purpose cannot automatically be repurposed for AI training without a valid lawful basis — typically consent or legitimate interest, with requirements varying by data category. Enterprise AI programmes that use historical customer, employee, or operational data containing personal information must complete a compliance review before using that data for AI training or inference. This review should be initiated before use case selection is finalised, not during model development.
Can a use case with a low data feasibility score still be included in an AI programme?
Yes — but not in Wave 1. A use case scoring 1 or 2 on data feasibility should be parked or assigned to Wave 2 with an explicit data preparation workstream running in parallel to Wave 1 delivery. When the data preparation workstream produces documented evidence that readiness requirements are met — profiling results, compliance sign-off, a data engineer's assessment — the use case is eligible for re-scoring and promotion to the next delivery wave. The gate is a structured deferral, not a permanent rejection.