AI data readiness decides whether AI delivers results in your organisation or stalls at a pilot nobody restarts. The core idea is simple: AI is only as good as the data you put into it. For an office of five to fifty employees, that means something different from what it means for an organisation with its own data platform and a team that trains models.
The big consultancies mainly write for that second group, with data architecture, master data management and programmes lasting months. An accounting firm or notary’s office rarely trains its own model and instead feeds documents, files or figures into ChatGPT or Claude assignment by assignment. The failure mode is different as well: you do not get a model that fails to converge, but an AI hallucination that reads convincingly and is wrong.
In that situation, readiness has two sides. Is your data good enough as input, and are you allowed to put this information in at all, given privacy and confidentiality? Offices that work with client data usually run into the second question first.
The good news is that you do not have to wait months. Data readiness becomes manageable as soon as you look at it process by process instead of across your whole archive, and that is exactly the order in which an AI implementation works for SMEs.
What is AI data readiness?
AI data readiness is the extent to which your data is usable, reliable and accessible enough to use AI meaningfully, and the extent to which you are actually allowed to process that data in the tool you use. Without that foundation, AI produces plausible but unreliable results.
The definition contains two axes that are often mixed up. Quality is about whether the data is correct, complete and findable at the moment someone needs it. Permissibility is about whether you may process this specific information in an external tool, given your contract, your professional rules and your agreements with clients.
Each axis on its own can decide whether AI is usable. Perfectly cleaned data that you are not allowed to enter gets you nowhere. Permitted data that is outdated or incomplete produces output nobody can use. An office that only manages the first axis will sooner or later get stuck on the second.
Only data that is correct and that you may process is ready for AI.
Readiness is also not a state your office either has or lacks. Your data can be more than adequate for drafting standard letters while falling short for file analysis, because one process works with templates and the other with documents from five different systems. So the question is never whether your office is ready, but which process is ready first.
Why do AI projects fail on data?
AI projects rarely fail on the technology and usually fail on poor data readiness. The models can handle the work a knowledge-intensive office gives them. The problem lies in fragmented, outdated or inaccessible information spread across separate systems, network folders and mailboxes, with different versions of the same truth.
Research by EY shows how widespread this is. According to its figures, 36 per cent of CIOs say their own data platform infrastructure is not sufficiently prepared for AI. That concerns large organisations, with more resources and more specialists than an office of thirty people has at its disposal.
With language models, this turns into a risk you do not see straight away. A model that receives messy or incomplete input does not return an error message but an answer. It fills the gaps with whatever is plausible, in the same fluent tone as an answer that is correct.
In my work as an SEO specialist with AI content, I see that link every week. The quality of the input directly determines the output, and half a briefing document produces half an article that looks complete. Data readiness is therefore not a technical side issue but the first condition for a reliable result.
What does data readiness mean if you do not train your own model?
Data readiness means something quite different when you use an existing AI tool than when you train a model yourself. If you build a model, you need large, structured and labelled datasets, plus an infrastructure to manage them. That is the scenario almost every article on this topic assumes.
An office of five to fifty employees is in the other scenario. There, a file, a set of annual accounts or a draft deed goes into the tool assignment by assignment, in the expectation that something usable comes out. The relevant question is not whether your entire mountain of data is in order, but whether the context you provide at that moment is correct, complete and the right version.
From both the user side and the developer side of language models, I notice that this distinction is consistently skipped. For most service providers, giving context to an LLM matters more than the size or structure of their data holdings, because the model only works with what is in the window at that moment.
That shift has a practical consequence. Readiness becomes something you arrange per process, not per system. To draft an advice letter, it has to be clear which template is the latest and which client details may be included; to summarise a file, it has to be clear which documents belong in it. Both are well-defined questions you can answer within a day, not a data migration.
Between separate chats and your own model there is an intermediate form that many offices skip. In a project environment or shared workspace, you set up the standard documents, templates and working agreements once, after which every chat draws on them without anyone uploading them again. Readiness then means that this knowledge base is current and cleaned up, because an outdated template that goes in once will come back in every answer from that moment on.
Which data can you enter into an AI tool?
Which data may go into an AI tool is the heavier half of data readiness for offices with client data. The compliance thinking from my years at major banks translates into three questions for every AI task: which data goes in, which claims do you base on the output, and who is responsible for the result. The first question is where readiness and confidentiality meet.
Account type and data processing agreement
The account type determines the terms under which your data is processed. A free consumer account comes with different terms from a business version with a data processing agreement, and with some account types the information you enter can be used to improve models. That difference is not a detail in the small print; it decides whether you may upload a file.
Check for each tool which account type your office actually uses, not which type you think you signed up for. In practice, employees often still work on a personal account from the time they were trying it out themselves.
Professional secrecy and client files
Professional secrecy sets a boundary that is separate from what the supplier technically allows. A notary, lawyer or accountant remains responsible for the confidentiality of client information, whatever tool was used and whatever terms that tool applies.
That only becomes workable once the boundary is set for each task instead of being left to each employee’s judgement. Anonymising names and amounts still makes many tasks possible, and for the tasks where that is not possible, there should be an explicit no. The rules for responsible AI use determine, situation by situation, which information you do and do not enter, and that choice should not rest with an individual employee at a busy moment.
How can you tell your data is not ready yet?
Data that is not yet ready for AI gives itself away through a handful of signals you can spot without an audit. Five of them come up most often in knowledge-intensive offices.
- Several versions of the same document are circulating and nobody is sure which is the latest.
- Knowledge about a client sits in mailboxes and people’s heads instead of in a file someone else can open.
- There is no agreement on which information the office does and does not hand over.
- Employees use tools that nobody ever approved, which amounts to shadow AI with company data in it.
- Data sources have no owner, so nobody is responsible for keeping them current and accurate.
Recognising two or more of these signals does not mean AI has to wait. It means you choose the process where the fewest of these signals apply and start there. An office that waits until all five are solved never starts.
How do you get your data ready for AI without a big data project?
To get your data ready for AI, you do not need to set up a data project lasting months. You do not need to build a data lake or complete an organisation-wide governance programme before anyone is allowed to work with a tool. The practical route runs the other way: from one well-defined process back to the data that process needs.
That route consists of three steps you go through for each use case. First, decide which data the process needs and which of it may be used, and record that in two lines of text. Next, clean up what that one process touches, meaning the template, the latest version and the source files, and leave your archive alone. Third, put a review point on the output before anything goes out.
What you deliberately do not do in this phase matters just as much. No migration to a new system, no inventory of every data source and no strategy that affects all departments at once. The approach I use is deliberately small: one to three processes as a starting point, after which the lessons from the first process make the second one faster. That way, AI implementation for SMEs starts with a specific process rather than with a plan that takes months of preparation.
Measuring whether it worked belongs to the same step. For the first process, record how much time it takes now and how often the output is changed before it goes out, and compare that after a month. If the number of corrections stays high, the problem usually lies not in the prompt but in the data going in, and then you know where the next clean-up needs to happen.
Where does AI data readiness fit in an AI implementation?
Data readiness is the first layer of an AI implementation, not a separate IT project that comes before it. Before a team starts working with AI, each process needs clarity on which data is needed, which of it may be used and where the review of the output takes place. Together, those three questions make the difference between an experiment and a way of working.
I translate the four-eyes principle from banking practice into review points on an SME scale: no output goes out without a second check. Not every task has the same risk profile, so an internal summary goes through a lighter process than an advice letter that falls under professional responsibility. You make that distinction in advance per task type, not afterwards per incident.
A short inventory maps, per tool and per process, what is possible and what is allowed, as a well-defined first step before a whole team starts working with AI.
If you want to tackle data readiness with your team, the AI Literacy Course covers which data you do and do not enter into an AI tool. The data question is not pushed back to a later phase, but forms the basis on which the rest of the way of working is built.
Frequently asked questions about AI data readiness
For offices that handle personal data, AI data readiness touches on the GDPR and the AI Act.
Do you need a DPIA before using AI with personal data?
A DPIA is mandatory if you process personal data with an AI tool and there is a high likelihood of a high privacy risk, for example with profiling or large-scale processing of special categories of personal data. According to Ondernemersplein, the Dutch government’s business information portal, the obligation also applies if your processing meets two or more criteria set by the European data protection authorities. In the DPIA, you describe which data you use and why, and how you mitigate the privacy risks.
Does the AI Act set requirements for the data you enter into an AI tool?
The AI Act mainly sets data requirements for high-risk AI systems. Their providers work with training, validation and test data that is relevant and sufficiently representative, and as free of errors and as complete as reasonably possible. If you deploy a high-risk system yourself, you make sure the input data you control is relevant and sufficiently representative for the intended purpose. For a general chatbot used for writing and summarising tasks, the AI Act does not set those data requirements.
