How to check whether your company data can support a specific AI workflow, before you connect a model to it.
In short
AI readiness is a property of one task, not of a whole company. Your data is ready for a given AI workflow when an owner can name the authoritative sources, terms mean the same thing across systems, inputs are fresh enough, permissions survive the whole chain, and you can test the output against expected answers. Check those five things before connecting a model.
Many employees already use AI tools on their own. Connecting AI to company processes raises harder questions: which record is current, who may see it, and what "customer" or "order" means across systems. A model cannot settle those for you. This guide from Devies, a Gothenburg-based product and engineering consultancy, gives CTOs and data leaders a practical way to assess data readiness for one chosen workflow, so that AI implementation starts with evidence rather than optimism.
What does AI readiness mean?
AI readiness is the degree to which a defined AI workflow can obtain relevant, sufficiently reliable data, respect access rules and produce output that someone can evaluate. A company can be ready for an internal document assistant and unprepared for automated cash forecasting at the same time, because the two tasks depend on different data.
The term is often mixed up with neighbouring ideas. Keeping them apart helps you ask the right question:
Term
What it is
The question it answers
AI readiness
What it is
Fitness of specific data and processes for one AI task
The question it answers
Can this workflow work safely with the data we have?
Data maturity
What it is
The general level of data management across the organisation
The question it answers
How well do we manage data overall?
AI strategy
What it is
The choice of where AI should create value and in what order
The question it answers
Which AI uses are worth doing first?
Model performance
What it is
How well a model answers on a test set
The question it answers
Is the model good enough for this task?
High data maturity makes readiness easier, but it is not a prerequisite. A small, well-owned document collection can support a useful pilot in a company whose wider data estate is messy. The reverse also holds: a mature data platform does not make an unclear task ready.
Seven steps to check whether your data is ready for AI
Check readiness by tracing one real task from question to source and testing each link in the chain. The steps below take a few working sessions with the people who own the data, not a months-long audit.
- Pick one task and write it down narrowly. "Answer account managers' questions about approved product specifications" is testable. "Make our knowledge available to AI" is not.
- Trace typical questions back to their sources. For each question, find where the answer lives, who maintains it and how it would reach the AI application. Repeat for an exception, such as a product with an amended specification.
- Name an owner for each source. Someone must decide which version is authoritative, settle disagreements and approve corrections. Without an owner, two "final" documents on a shared drive stay that way.
- Agree the definitions the task depends on. Sales may count a signed contract as a customer while finance counts an invoiced legal entity. Both are reasonable, but the output must state which one it uses. A short register of identifiers, status values, timestamps and calculation rules is enough.
- Set an acceptable age for each input. An overnight update may be fine for yesterday's sales and useless for stock that changes during the day. Check the whole route, because a current source does not guarantee a current search index.
- Test permissions end to end. Being able to read a database technically is different from being allowed to show its contents to every user. Test with an ordinary account that has deliberately limited access, and include conversation logs in the review.
- Build a small evaluation set before rollout. Collect representative questions with expected answers, including questions where no approved answer exists. Without it, you cannot tell whether a change to data or model made things better or worse.
How good does the data have to be?
Data has to be good enough for the consequence of a mistake, not perfect. The required quality depends on the decision the output supports and on whether a person reviews the result before it matters.
For a knowledge assistant, check that documents are current, readable and clearly tied to a topic. For a predictive model, you may need consistent history and labels. Measure the problems that block the task: a missing product identifier may stop retrieval, while a missing optional description may not. Record how often each blocking problem occurs and who can fix it. "Our data quality is poor" gives a delivery team nothing to act on; "12 percent of active products lack a supplier code, owned by purchasing" does.
Microsoft describes retrieval-augmented generation in Azure AI Search as a way to give a language model relevant information from your own content. Retrieval helps, but it does not decide on its own which documents are suitable for every employee. That decision still rests on steps 3 to 6.
What do regulation and risk frameworks expect from your data?
For most business AI, no law sets a data quality threshold, but the EU AI Act does for high-risk systems, and voluntary frameworks give a useful structure for everyone else.
Article 10 of the EU AI Act requires training, validation and testing data for high-risk AI systems to be subject to data governance and management practices suited to the intended purpose. As of October 2026, the European Commission's AI Act page states that, after the Digital Omnibus on AI entered into force on 27 July 2026, high-risk rules for Annex III uses such as recruitment and credit apply from 2 December 2027, and for AI in regulated products from 2 August 2028.
Outside the high-risk categories, the NIST AI Risk Management Framework, released in January 2023, is a voluntary reference organised around four functions: govern, map, measure and manage. Its emphasis on knowing your context and measuring outcomes matches the seven steps above. Use it to structure your AI strategy and risk discussion, not as a certificate.
An example: an assistant for internal product questions
A worked example shows how readiness problems usually turn out to be data and ownership problems rather than model problems. This is a hypothetical case, not a Devies customer.
A distributor wants an assistant that answers its sales team's questions about one product family. A product owner removes obsolete versions and confirms which specifications are authoritative. The team writes thirty questions with expected answers, including five where no approved answer exists.
The first trial shows that documents use two different product code formats, so the assistant misses half the relevant files. Fixing that mapping improves results more than switching models would. A restricted-user test then reveals that supplier agreements were indexed alongside public specifications. Those documents are removed until someone decides who may see them. Only then does the pilot widen to a second product family.
Devies
Want a second opinion?
Devies, a Gothenburg-based product and engineering consultancy, works on questions like this with Nordic product and IT teams. Tell us where you are and we will suggest a sensible first step.
Frequently asked questions
Do we need to clean all our data before using AI?
No. Start with the inputs one defined workflow needs, fix the problems that affect its results, and widen coverage when there is a reason. A company-wide clean-up has no natural stopping point and delays learning. Readiness for one task is measurable within weeks, while a general data quality programme can run for years without showing whether AI works for you.
How do we measure AI readiness?
Measure it per task with five checks: is there a named owner for each source, are the key terms defined, is the data fresh enough for the decision, do permissions hold from source to answer, and is there an evaluation set with expected answers. Record evidence for each check. A task that passes all five is ready for a pilot; gaps become a concrete to-do list.
Does retrieval-augmented generation stop AI from giving wrong answers?
Retrieval reduces the risk by giving the model relevant source material, but it does not remove it. Answers can still be wrong if the sources are outdated, contradictory or poorly retrieved, or if the model misreads them. You still need source citations, an evaluation set, handling of questions without an approved answer, and permission checks on what is retrieved.
Is a successful prototype proof that our data is ready?
Not on its own. A prototype shows that some tasks worked under the conditions tested, often with friendly users and clean examples. Before scaling, repeat the tests with realistic users and access rights, exceptions, changing data and questions that should be refused. Readiness is proven when the evaluation set passes under production-like conditions, not when a demo impresses.
Sources
- Microsoft Learn: Retrieval Augmented Generation (RAG) in Azure AI Search
- Regulation (EU) 2024/1689 (AI Act), EUR-Lex
- European Commission: AI Act, regulatory framework on AI (timeline after the AI Omnibus)
- NIST: AI Risk Management Framework
- Devies: Data and AI Use Case Discovery Workshop
- Devies: Data Foundation Platform
- Devies: AI Ã la carte







