AI projects often start with discussions about model selection, RAG architecture, fine-tuning or AI agents. Yet one of the most important questions should be asked earlier: is the data the solution will depend on actually ready for AI?
And this is not only a data quality question. Data may be accurate, complete and well documented, yet still be unsuitable for a production AI system. It may be locked inside a single application, lack a clear owner, use conflicting business definitions across departments, become outdated too quickly or require manual preparation every time it is used.
Key takeaway: data readiness for AI is about more than data quality. An organisation must be able to deliver the right data to a specific AI system reliably, securely, at the required time and at a sustainable operating cost.
Before selecting a model, it is therefore worth answering 12 questions about data quality, ownership, lineage, historical coverage, integrations, pipelines, freshness, access control, testing and maintenance costs. The answers may reveal whether the next step should really be choosing an AI technology – or first fixing the data layer that will support it.
Data quality vs data readiness for AI: what is the difference?
Data quality primarily answers whether data is accurate and usable. Data readiness goes a step further: it asks whether the organisation can actually use that data in a specific AI solution and sustain the same process after moving from experimentation to production.
| Data quality | Data readiness for AI |
|---|---|
| Is the data accurate? | Is it appropriate for the specific AI use case? |
| Is the data complete? | Is it available when the AI system needs it? |
| Are values consistent? | Are business definitions consistent across systems? |
| Does the data meet defined quality rules? | Can we deliver and validate it automatically in production? |
| Is the dataset free from critical errors? | Do we understand its origin, ownership, permissions and operating cost? |
High-quality data can still be unready for AI. A financial report may contain perfectly accurate figures, but if the AI system receives them only once a month in a manually prepared spreadsheet, that does not yet constitute a production-ready data source for a system expected to operate every day.
For a broader assessment covering business readiness, architecture, governance, QA and delivery, see our AI Readiness for Enterprises checklist. In this guide, we focus specifically on the data layer.
Layer 1: is the data suitable for the specific AI use case?
A common mistake is evaluating data without considering the problem AI is expected to solve. The question “Do we have good data?” is too broad. The same dataset may be sufficient for one use case and unsuitable for another.
1. Do we have the data required to solve this specific problem?
Having a large volume of data does not automatically mean being ready for AI. First, the team needs to determine which information is actually required to make a decision, generate an answer, produce a prediction or trigger an action.
Red flag: the project starts with “Which model should we choose?” before the team can identify the data sources required to solve the business problem.
What to check technically: data sources, scope, granularity, formats, availability and how the data relates to the underlying business process.
2. Is the data sufficiently complete and representative?
Not every AI project requires a perfect dataset. It does, however, require data that is sufficiently good for the intended use and for the consequences of a potential error.
The quality threshold for an internal assistant helping employees find a document may be different from the threshold for a system supporting a high-value business decision.
Red flag: missing values, duplicates or exceptions are corrected manually only to make the demo work.
What to check technically: missing values, duplicates, coverage, data distribution, edge cases, systematic errors and how missing information is handled.
3. Are business definitions consistent?
Data problems do not always mean incorrect values. A more fundamental issue may be that different systems use different definitions for the same business concept.
An “active customer”, “revenue”, “closed complaint” or “available product” may be defined differently in the CRM, ERP, data warehouse and reporting platform. An AI system can technically access all of those values and still lack a reliable answer as to which definition should be used.
Red flag: two departments report different values for the same KPI and both consider their number correct.
What to check technically: business glossary, mappings between systems, transformation rules and the authoritative source for each critical definition.
4. Do we have enough historical data?
Historical coverage is particularly important for predictive AI, machine learning and use cases where the system needs to identify patterns that evolve over time.
The number of years alone is not enough. Teams need to know whether business processes, source systems, field definitions or data collection methods changed during that period.
Red flag: the organisation has five years of historical data, but changed its ERP system two years ago and no one can reliably compare records before and after the migration.
What to check technically: historical coverage, schema changes, migrations, missing periods, versioning and comparability over time.
Layer 2: do we know where the data comes from and who owns it?
5. Who owns the data?
Ownership should not stop at identifying the team that administers a database. Both business and technical accountability are needed.
Who can decide that a field definition should change? Who is responsible for quality? Who decides which value is authoritative? Who reacts when a source stops working?
Red flag: the Data team is said to “own the data”, but has no authority over business rules or how data is captured in the source application.
What to check: business owner, technical owner, responsibility for quality, definition changes, access and incident handling.
6. Do we understand data lineage?
If an AI system uses a particular piece of information, the organisation should be able to determine where that information came from and which transformations it went through.
Source system → transformation → dataset → AI system → output
Red flag: after an incorrect AI output, the team can identify the model version but cannot determine which version of the underlying data supplied the context.
What to check technically: lineage, metadata, dataset versioning, ETL/ELT transformations, source logging and dependencies between systems.
7. Are we allowed to use the data for this purpose?
Technical access to a dataset does not automatically mean that it should be used by an AI system.
Teams should review access rights, personal data, licensing conditions, contractual restrictions, retention requirements and whether the data can be transferred to the selected system or external AI provider.
Red flag: a PoC is built using an export of production data before the organisation has established how that data may be used or shared with external services.
What to check: access rights, data classification, permitted purposes and Security, Legal and Compliance requirements. The legal assessment of a specific use should be confirmed with the appropriate Legal or Compliance team.
If the project involves adapting AI to proprietary information, see our guide on working with company data in AI models.
Layer 3: can we deliver the data reliably in production?
This is often where the difference between a successful PoC and a maintainable production system becomes visible. A demo can run on a manually prepared file. Production needs a reliable and repeatable flow of data.
8. Where will the AI system get its data?
CRM, ERP, data warehouse, data lake, CMS, internal documentation, shared drives, legacy applications or external APIs – in an enterprise environment, the information required for a single AI use case may be distributed across many systems.
Red flag: “all the data is available”, but using it requires exports from five different systems and manual file consolidation.
What to check technically: source systems, APIs, batch processing, streaming, connectors, data formats, legacy constraints and integration dependencies.
9. Is the data pipeline repeatable?
Preparing a dataset once may be enough for an experiment. A production system requires a process that can run repeatedly without manual intervention and without introducing inconsistent results simply because the data was prepared differently.
Ingestion → validation → transformation → delivery → monitoring
Red flag: before every test, someone exports data to Excel, corrects records manually and uploads the file to the environment.
What to check technically: automated ingestion, orchestration, validation, retry mechanisms, error handling, CI/CD for data pipelines and flow monitoring.
10. How fresh does the data need to be?
Real-time data is not automatically the best solution. Freshness requirements should be driven by the business process and the way the AI system will be used.
In one process, information from the previous day may be perfectly adequate. In another, a result based on data that is only a few minutes old may already be unusable.
A better question than “Do we need real-time data?” is:
What is the maximum acceptable age of the data before the AI output is no longer useful for the business process?
Red flag: the system generates technically correct answers based on documentation, prices, customer records or statuses that are already outdated.
What to check technically: data SLAs, timestamps, ingestion frequency, caching, system synchronisation and freshness monitoring.
Layer 4: can we control and maintain the data layer?
11. Who can access the data – and under which rules?
An AI system should not automatically gain access to everything that happens to exist in a connected data source.
This is particularly important for RAG and agentic solutions. If two employees have different permissions in the source system, the organisation needs to determine whether the same restrictions are enforced when AI retrieves information and generates an answer.
Red flag: a user cannot open a document directly but the AI assistant is able to answer questions based on its contents.
What to check technically: RBAC/ABAC, permissions, service accounts, authentication, authorisation, document filtering, access tokens and how permissions are propagated into the AI layer.
12. How will we test data quality – and how much will it cost to maintain?
Data readiness does not end when the system goes live. Data sources evolve, new fields are introduced, schemas change, APIs begin returning different values and overall data quality may gradually deteriorate.
The organisation therefore needs both quality controls and an operating model. The cost of an AI solution is not limited to model fees or token consumption.
The data layer may generate costs related to:
- data ingestion and transfer,
- storage,
- transformations and compute,
- database and data platform queries,
- data quality validation,
- monitoring and alerting,
- pipeline maintenance,
- incident handling,
- Data Engineering and DevOps work.
Red flag: the business case includes the cost of the AI model API but assumes that data preparation and maintenance already exist and therefore carry no additional cost.
What to check technically: validation rules, data contracts, schema checks, alerting, freshness monitoring, anomaly detection, remediation ownership and the total cost of operating the pipeline.
How can you tell when the problem is the data, not the model?
Poor output quality, instability or scaling problems do not automatically mean that the model needs to be replaced. Sometimes another round of prompt engineering or switching to a larger model only hides a problem that sits earlier in the data pipeline.
| If you see… | The model may not be the problem | Check |
|---|---|---|
| Different answers to similar questions | Inconsistent or incomplete context | Definitions, sources, retrieval, data quality |
| Answers become outdated quickly | The data flow is too slow | Freshness, ingestion, cache, SLA |
| The PoC works but production stalls | Manual data flow | Integrations, pipelines, automation |
| AI exposes information outside the user’s permissions | Permissions are not propagated correctly | Access control, permissions, retrieval |
| The cause of an incorrect output cannot be identified | Insufficient traceability | Lineage, metadata, logs, versioning |
| Operating costs increase faster than usage | Inefficient data architecture | Storage, queries, transformations, architecture |
The same issue often becomes visible when moving from experimentation to a production environment. In a separate guide, we explain why AI projects stall between PoC and production and which elements beyond the model need to be addressed.
Data readiness scorecard: a quick assessment before model selection
Before discussing a specific model, answer “yes”, “no” or “we don’t know” to the following questions.
- Do we have the data required for the specific use case?
- Is the data sufficiently complete and representative?
- Are critical business definitions consistent?
- Do we have adequate historical coverage?
- Does every critical data domain have an owner?
- Do we understand the lineage of the data used by AI?
- Are we allowed to use the data for the intended purpose?
- Do we know all relevant source systems and how to access them?
- Is the data pipeline automated and repeatable?
- Have we defined the required level of freshness?
- Is access control propagated into the AI layer?
- Do we have a way to test, monitor and maintain data quality?
Mostly YESThe organisation can move to a more detailed architecture assessment and technology selection for the specific use case. | Many WE DON’T KNOW answersDiscovery and data mapping should come first. A lack of visibility into sources, ownership or data flows is itself a significant project risk. | Many NO answersModel selection is probably not the most important decision yet. The priority should be addressing the gaps that would prevent reliable production use. |
“We don’t know” is not a neutral answer. If the organisation cannot identify the owner of a dataset, the origin of a particular value or the way a dataset is updated, that is an important readiness signal in itself.
What should you do after assessing data readiness?
The objective is not to bring every dataset in the organisation to a perfect state. That would often be unnecessary, expensive and could delay the project without delivering proportional value.
A more practical approach is to start with the specific use case and identify which gaps genuinely prevent it from being implemented or scaled.
| Stage | Question | Outcome |
|---|---|---|
| 1. Use case | What problem should AI solve? | Required data scope. |
| 2. Inventory | Where does the data live? | Map of sources and dependencies. |
| 3. Assess | What are the gaps? | Quality, integration and organisational issues identified. |
| 4. Prioritise | Which gaps actually block the use case? | Remediation priorities. |
| 5. Engineer | How can we create a repeatable data flow? | Integrations and data pipelines. |
| 6. Validate | Does the solution maintain the required quality? | Tests, monitoring and quality criteria. |
| 7. Choose architecture | Which model and architecture best fit the available data? | A technology decision based on real constraints. |
The order matters:
use case → data → sources → ownership → pipeline → controls → only then model and architecture.
How can Edge One Solutions help prepare data for AI?
In Data & AI projects, we look beyond the model itself and consider the entire system required to make it work. That includes source systems, integrations, pipelines, architecture, data quality, access patterns and the connection between the AI layer and existing business applications and processes.
Data EngineeringData source integration, pipeline design and development, flow automation and preparation of data for analytics and AI systems. | Data & AnalyticsData analysis, information-layer development and using data to support business decisions. |
Artificial IntelligenceSolution architecture and integration of AI components with enterprise data, applications and processes. | Software Development & IntegrationsConnecting source systems, APIs, business applications and the AI layer into a production-ready solution. |
If you first need to assess the broader readiness of your organisation, see our AI Readiness for Enterprises checklist. If your project already has a working PoC but is struggling to scale, read our guide on moving AI from experimentation to production.
You have an AI use case – but is your data ready?
We can help analyse your data sources, integrations, pipelines and existing technology constraints, and identify which gaps should be addressed before moving to implementation.
Explore our Data Engineering capabilities
See also our Data & Analytics and Artificial Intelligence capabilities.
