Business Strategy & Growth
August 11, 2026
10 min read
AI projects often begin with questions about models, vendors, architecture, and use cases:
Those questions matter but they may come too early. Before deciding how to build an AI solution, there is a more fundamental question to answer: Can your data safely and reliably support it?
Many problems that appear later as “AI issues” are actually data issues that existed long before the AI project started. Poor data quality, fragmented systems, unclear ownership, weak permissions, privacy restrictions, historical bias, and outdated documentation can all become significantly more expensive once a model, integrations, and production workflows are built around them.
That is why AI readiness should start with a data risk review. The objective is not to make your data perfect. It is to identify the weaknesses that could make the planned AI solution unreliable, unsafe, non-compliant, unexpectedly expensive, or difficult to operate before development begins.
The first risk is also the most basic: data quality. An AI system can only work with the information available to it. If that information is inaccurate, incomplete, duplicated, inconsistent, or outdated, the AI may reproduce those problems at scale.
Typical warning signs include:
For traditional software, bad data may cause an incorrect dashboard or an incomplete report.
With AI, the problem can be harder to detect because the output may still sound convincing.
A customer-support assistant, for example, may generate a perfectly written answer based on an obsolete policy document. A forecasting model may work technically while relying on inconsistent historical records. An AI sales assistant may recommend the wrong next action because CRM fields are incomplete.
The pre-build question is therefore not simply: Do we have data? It is: Is the data sufficiently accurate, complete, current, and consistent for this particular use case?
Organizations frequently discover that the required information exists, but is distributed across many systems.
A single AI use case may depend on information from:
That creates a hidden scope risk. What initially looks like an AI-development project can quickly become a data-integration project involving APIs, migrations, transformations, identity management, data pipelines, and legacy-system constraints. This is particularly common with enterprise AI assistants.
A company may say: “We want an AI assistant that understands all of our customer information.”
The next question should be: Where does that information actually live, and can it be connected reliably?
If customer contracts are in one system, pricing in another, support history in a third, and account status in manually maintained spreadsheets, the integration effort may become more significant than the model implementation itself.
Before building, map the data sources, dependencies, owners, update frequency, and access requirements. That exercise can materially change the architecture, timeline, and business case.
Another common mistake is assuming that having a lot of historical data automatically makes a company AI-ready.
Volume and representativeness are not the same thing.
A dataset can contain millions of records while poorly representing:
This matters because an AI system learns from the reality represented in the data, not necessarily the reality in which it will eventually operate. Imagine an AI support system trained mostly on English-language conversations. Its overall performance may look strong during evaluation, while its performance for Dutch- or French-speaking customers is significantly worse.
The same issue applies to predictive systems. A model can achieve high average accuracy but perform poorly for a commercially important customer segment or unusual operational scenario.
Before development, ask: Does our data represent the customers, situations, languages, and environments the AI will actually encounter?
And do not look only at average model performance. Important differences can disappear inside a single headline accuracy number.
Historical business data is often treated as objective truth. Data contains the results of previous business processes, decisions, incentives, policies, and human judgments.
If those processes contained bias or inconsistency, an AI system may learn and scale them.
Consider labels such as:
They may look like factual categories in a database, but they often reflect human decisions or previous business rules.
The question is therefore not only whether the dataset is technically clean.
It is: Which historical patterns do we actually want the AI to reproduce?
There is also the risk of proxy variables. Removing an obvious sensitive attribute does not automatically remove bias if other variables indirectly correlate with it. Location, education, employment history, income indicators, or purchasing behavior may unintentionally recreate distinctions that the organization did not intend the model to make. Bias assessment should therefore happen during data preparation, not only after a model has been trained.
AI projects often involve personal or sensitive information. Customer conversations, employee records, support tickets, behavioral data, documents, financial information, and transaction histories can all contain personal data. For European organizations, this creates immediate GDPR considerations.
Before connecting that data to an AI system, organizations need to establish:
This is where a technically simple AI idea can become a compliance problem. For example, a business may already have thousands of customer conversations available in its support platform. That does not automatically mean those conversations can be reused for every possible AI-training or analytics purpose.
The useful pre-build question is: Are we technically able to use this data, and are we actually permitted to use it in this way?
Those are different questions. The EU AI Act adds another layer for certain AI use cases, particularly where systems fall into higher-risk categories. Depending on the application, requirements around governance, documentation, transparency, and data quality may directly influence how the system should be designed. Compliance therefore needs to be considered before architecture decisions become difficult to reverse.
Security is another area where AI projects can expose risks that already existed in the underlying data environment.
Consider an internal AI assistant connected to company documents. The initial requirement may sound straightforward: “Let employees search our internal knowledge using natural language.”
But it creates a more important question: Should every employee be able to search every document?
If HR, Finance, Legal, Sales, and management documents are placed into one retrieval system without preserving existing authorization rules, the AI can effectively flatten security boundaries that were previously enforced by separate applications.
A safer architecture looks conceptually like: User → identity → authorization → permitted data → retrieval → model → answer
rather than: User → AI → entire company knowledge base
The same principle applies to AI agents that can take actions. If an AI system can update CRM records, send messages, query internal databases, approve workflows, or trigger APIs, access controls become even more important.
Before development, determine:
The core principle should be least privilege: Give the AI only the access it actually needs.
Data provenance and lineage become increasingly important as AI architectures become more complex. An AI system may depend on information that has passed through several steps: source application → data pipeline → transformation → warehouse → embedding → retrieval system → model
If the final answer is wrong, can you trace the problem backwards?
Can you determine:
Without that traceability, debugging AI outputs becomes much harder. It can also create compliance and governance problems, particularly when third-party datasets or external information sources are involved. The ability to answer “Where did this information come from?” should therefore be designed into the system rather than added later.
Passing the initial data review does not mean the risk disappears. Business data changes. Customers behave differently. Products evolve. Policies are replaced. New regions are added. Data pipelines change. Documents become outdated.
That can lead to data drift or a growing gap between the information used during development and the environment in which the system currently operates. A model that performed well at launch can become less reliable even if the model itself has not changed.
For production AI, organizations therefore need processes for:
Deployment is not the end of data governance. It is the beginning of another phase.
A pre-build data review does not need to become a six-month governance programme.
Its purpose is much simpler: identify the data issues that could materially change the feasibility, risk, cost, architecture, or expected outcome of the AI project before significant development money is committed.
A practical review can be structured around six questions:
Is it sufficiently accurate, complete, current, and consistent?
Can the necessary sources actually be connected without unexpected integration or infrastructure work?
Does the data cover the users, scenarios, languages, and edge cases the AI will encounter?
Are privacy, security, contractual, regulatory, and access requirements understood?
Are ownership, definitions, provenance, metadata, and authoritative sources clear?
Can the organization monitor quality, update information, manage access, and correct errors after deployment?
The outcome should not always be “go.”
Sometimes the right next step will be: AI development → proceed
But sometimes the sequence should instead be: data cleanup → integration → governance → AI
And sometimes the review may reveal that the use case itself needs to change. That is not a failure of the AI initiative. It is exactly what risk assessment is supposed to uncover.
AI creates pressure to move quickly. A prototype can often be built in days or weeks, which makes it tempting to start with the model and deal with data problems later. But a working prototype does not prove that a system can operate reliably at scale.
The larger risk is committing to a model, architecture, vendor, budget, and delivery plan before understanding whether the underlying data can actually support them. Before asking “Which AI should we build?”, ask: “What would have to be true about our data for this AI to work safely and reliably?”
That question may expose work that needs to happen first. And discovering it before the build is almost always cheaper than discovering it after.
AI data readiness is the process of assessing whether your data is accurate, accessible, secure, well-governed, and suitable for the intended AI use case before development begins.
Poor data quality for AI can lead to unreliable outputs, hidden bias, weak predictions, and costly rework. AI systems depend on the quality and relevance of the data they use.
Common data risks in AI include poor data quality, fragmented systems, unclear ownership, privacy issues, security gaps, bias, weak documentation, and outdated or unrepresentative data.
An AI data readiness assessment should review data quality, availability, integration needs, privacy, security, access controls, bias, governance, documentation, and ongoing data maintenance.
Strong AI data governance helps define who owns the data, which sources are authoritative, who can access them, and how data quality, privacy, and compliance are managed over time.
Businesses can reduce AI data risk by reviewing the required datasets before the build, identifying critical gaps, validating compliance and security requirements, and deciding whether data remediation is needed before AI development starts.
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.webp)
.webp)
