“We want to implement AI, but our data isn’t ready.”
This concern comes up repeatedly in conversations about AI adoption. It is legitimate, because an effective AI data strategy cannot ignore data quality. Incomplete, inconsistent or poorly governed data can weaken an AI system and amplify existing errors. But waiting until every dataset is perfectly cleaned, centralized and standardized creates another risk. The organization may spend years preparing its data without ever delivering a first useful result.
The objective is not to lower quality standards or build artificial intelligence on unreliable information. It is to define the level of data quality required for a specific business problem. A customer service assistant, a demand forecasting model and a knowledge system using RAG do not require the same data, the same level of freshness or the same controls.
A practical data strategy for AI therefore begins with the business outcome, not with a cleaning programme covering the entire company. From a CTO’s perspective, the real question is not whether the organization possesses perfect data. It is whether it can identify a Minimum Viable Dataset. This means information that is sufficiently representative, accessible, traceable and governed to test a business hypothesis safely.
This approach allows the company to start with a focused use case, measure the value created and improve its data as the solution evolves.
The Business Cost of Waiting for Perfect Data
Data cleaning remains essential when errors affect reliability, security, compliance or the quality of a business decision. The problem begins when an organization treats the complete cleaning of all its data as a mandatory condition before any AI initiative can start.
In companies with years of accumulated systems and information, correcting every inconsistency, removing every duplicate and standardizing every format can become an endless programme. The work continues, but the connection with the original business problem gradually disappears.
The first risk is that the use case loses relevance. Business priorities change, customer expectations evolve and new constraints emerge. By the time the data programme is complete, the question that initiated it may no longer be the question the organization needs to answer.
The second risk is investment fatigue. When teams consume time and budget without delivering a result that stakeholders can evaluate, confidence decreases. Artificial intelligence begins to be perceived as another costly technology initiative rather than a practical way to solve a business problem.
The third risk is analysis paralysis. The organization becomes focused on improving the structure of its data instead of determining which information is actually necessary to create value.
Perfect data is not the prerequisite for starting with AI. The real prerequisite is data that is sufficiently reliable for the specific decision, process or use case the organization wants to improve.
The Minimum Viable Dataset (MVD) Framework
To escape the cycle of endless preparation, an organization must determine what information is actually necessary for the use case it wants to test. We use the concept of a Minimum Viable Dataset, or MVD, to define that foundation.
A Minimum Viable Dataset is not an excuse to work with poor quality information. It is the smallest body of data that is sufficiently relevant, reliable, accessible and governed to evaluate a specific AI use case. Its purpose is to establish whether the idea can create value before the organization commits to a broader data transformation.
A useful MVD should be assessed through four essential criteria.
Operational relevance. The data must represent the current process, behaviour or decision the organization wants to improve. More historical information does not automatically produce a better result. The appropriate period depends on the business context, the stability of the process and the objective of the model.
Context and meaning. Artificial intelligence can work with documents, emails, transcripts and other forms of unstructured information, but access alone is not enough. The origin, purpose, structure and permissions associated with that information must remain understandable. A document without its context can produce an answer that appears convincing while being operationally wrong.
Integrity of critical information. Not every field has the same importance. The organization must identify which elements directly influence the expected result and verify their completeness and consistency. Secondary information can be improved later, but the data supporting the central decision must be trustworthy from the beginning.
Accessibility and governance. Useful data must be available to the system through controlled processes or interfaces. Ownership, permissions, freshness and traceability must be defined before the information is used by an AI solution. This governance work is also part of building trustworthy AI systems, as reflected in the NIST AI Risk Management Framework.
The MVD is not the final dataset. It is a controlled starting point that allows the organization to test an assumption, measure the result and identify the data improvements that are genuinely necessary before scaling.
From Business Question to Proof of Concept
Once the Minimum Viable Dataset has been identified, the next step is not a complete deployment. It is a focused Proof of Concept, or PoC, built around a specific business question.
Many AI initiatives begin with a model or a technology and only later search for a problem to solve. The order should be reversed. The organization must first define what it wants to understand, predict or improve.
Can we identify customers who are likely to leave? Can we reduce product returns by identifying the conditions that make a return more likely? Can we help a support team find the right technical information more quickly? A precise question gives the project a clear direction and makes its result measurable.
A useful Proof of Concept follows four steps.
1. Define the business question. The objective must describe a real operational problem and the improvement the organization expects to observe.
2. Select the relevant data. The team should use the information connected to that question instead of waiting for every dataset in the company to be cleaned.
3. Build the simplest meaningful test. The purpose is not to demonstrate every possible capability of artificial intelligence. It is to determine whether the proposed approach can answer the question with an acceptable level of reliability.
4. Measure and learn. The result must be evaluated against the original business objective. The organization should identify what worked, what failed and which data limitations affected the outcome.
A Proof of Concept is valuable even when it does not lead immediately to a complete solution. It can reveal that the available data is insufficient, that the use case requires a different approach or that the expected value does not justify a larger investment.
The principle is simple: start small, prove value, then scale. This allows the organization to make its next decision using evidence rather than enthusiasm alone.
Building Data Quality into an AI Data Strategy
Once the Proof of Concept has confirmed that the use case deserves further investment, data quality can be improved around that objective. The organization does not need to clean every source at the same time. It needs to strengthen the information that directly supports the process or decision being improved.
Prepare the relevant data first. If the objective is to improve technical support, the priority should be incidents, product manuals and previous resolutions. Information from unrelated departments can remain outside the initial scope. This keeps the work connected to the expected business result.
Use automation, but keep human control. Rules, scripts and artificial intelligence can help identify duplicates, inconsistent formats, missing values and unusual records. These tools can accelerate curation, but their corrections should not be accepted without validation. Automation can identify a potential problem. It cannot always understand its operational meaning.
Involve domain experts. The people who understand the process must review representative samples of the data and the results produced by the system. Their knowledge helps distinguish a genuine anomaly from a legitimate exception. This validation is essential because technical consistency does not always mean business accuracy.
Create a continuous feedback process. Corrections identified during the project should improve both the dataset and the way new information is captured. Data quality therefore evolves with the solution instead of remaining a separate programme that must be completed before value can be created.
An AI initiative often becomes a mirror for the organization. It reveals where information is missing, where definitions are inconsistent and where responsibilities are unclear. When those weaknesses begin to affect a visible business result, data governance stops being an abstract technical concern and becomes an operational priority.
Leadership Through Technological Pragmatism
Waiting for perfect data can appear to be the responsible decision. In practice, it can also become the safest way to avoid making a decision at all.
The role of technology leadership is not to choose between reckless speed and endless preparation. It is to define the conditions under which the organization can learn without compromising reliability, security or business continuity. This requires a clear problem, a Minimum Viable Dataset, a focused Proof of Concept and a governance process that grows with the solution.
Some projects will reveal that the available data is not yet sufficient. Others will demonstrate that a limited but carefully selected dataset can already produce a useful result. Both outcomes have value when they are discovered before the organization makes a major commitment.
The companies that make progress with artificial intelligence will not necessarily be those with the largest datasets or the most advanced models. They will be those that understand which information matters, why it matters and how its quality must evolve as the system becomes part of the business.
At Intech Heritage, we treat AI data strategy as an engineering and business decision, not as a technological spectacle. The objective is not to deploy artificial intelligence everywhere. It is to use it where it can solve a real problem, measure the result and build from evidence.
The question is no longer, “When will our data be ready?” The more useful question is: “What value are we failing to explore while we wait?”