How Do You Know If Your Data Is AI-Ready?
Most organisations answer "is our data AI-ready?" with a feeling rather than a fact. The platform is modern, the warehouse is populated, a governance programme exists — so it probably is.
It usually is not, and the gap only surfaces once a model is in production and its answers start contradicting things the business knows to be true.
These seven questions give you a straight answer. They are deliberately phrased so you can respond yes or no. If a question needs a qualified answer, treat that as a no.
1. Does every core business object have one meaning?
Not "do we have a definition of customer" — do you have exactly one, and does the whole business use it?
The tell is easy to find: ask sales, finance and operations for a customer count on the same date. If the three numbers differ, you have three definitions, and any model trained across them learns all three as though they were one.
This is the foundation. Everything below assumes it, and it is the single most common reason AI programmes stall. We wrote about it in AI-Ready Data Starts With Master Data.
2. Can you say what you deliberately left out?
The usual version of this question — "do you know which data is business-relevant?" — is impossible to answer honestly, because everything looks relevant in the abstract.
The testable version is the inverse. Can you name what you consciously decided not to bring in, and why?
If the answer is "we bring in everything", you have not made a relevance decision. You have deferred it, and it will be made later, repeatedly and inconsistently, by whoever happens to be building each use case. Selection is the work. Copying is the avoidance of it.
3. Can you protect sensitive data at the point of access?
AI changes the shape of this risk. A report is seen by the person who ran it; a model can surface an inference drawn from data the person asking was never entitled to see.
So the question is not whether you hold PII securely at rest. It is whether access control travels with the data into every downstream use — including the ones nobody has built yet.
If your protection depends on which tool someone uses to reach the data, it will not survive contact with AI.
4. Is bad data rejected on entry, or cleaned up later?
Almost every organisation has data quality work. Most of it happens downstream: extract, discover problems, correct them, load.
That model breaks under AI for a simple reason — it is a cleanup pass, and cleanup passes are only ever as good as the last one that ran. The upstream system keeps producing the same defect, and every consumer either fixes it again or does not notice.
The question is whether poor quality data is stopped at the door and corrected at source. If your answer is "we clean it in the pipeline", the defect still exists and you are paying for it repeatedly.
5. Does every element carry both kinds of context?
This is the one most organisations have not considered, and it has two halves.
Element-level context — what does this field actually mean in business terms? Not its data type or its source column name, but its meaning to someone who does not know the system it came from.
Enterprise-level context — how does this element relate to every other one? Which business object does it describe, which other elements does it sit alongside, what does a change in it imply elsewhere?
An AI system needs both. With only the first it can interpret a field but cannot answer anything spanning two domains. With only the second it knows the shape of your business and not what the numbers mean. Most catalogues supply the first and stop.
6. Can you trace any figure back to where it came from?
Pick a number from a board pack and follow it back to the source records that produced it. How long does that take, and can you do it at all?
For AI this is the difference between an answer you can defend and one you can only hope is correct. When a model produces a figure a regulator or a director questions, "the model said so" is not an answer. In several sectors it is not a legally acceptable one either.
See compliance risk from poor data lineage on where this becomes an exposure rather than an inconvenience.
7. Would replacing a source system cost you your history?
The last question is the one that separates a data asset from a collection of copies.
If you replaced your CRM tomorrow, would five years of customer history survive intact and continuous? Or would it sit in an archive, in the shape of the system that is being retired?
This matters specifically for AI in a way it does not for reporting. A break in continuity forces retraining. The model sees the same business fact represented one way before the switchover and another way after, and cannot treat them as the same thing. You pay for the migration, and then you pay again in model work — and you keep paying every time an application changes.
Where history is held independently of the applications that produced it, the switch is invisible to the model. We covered the underlying reason in AI-Ready Data Needs Transactions, Not Copies.
Scoring it honestly
Seven yeses — you are ready, and unusual.
Four to six — you can run AI pilots successfully and will struggle to put them into production. Pilots survive on a curated dataset and a knowledgeable human nearby; production has neither.
Three or fewer — AI is not your constraint and buying more of it will not help. The failures you get will look like model problems and will not be.
The most useful part of this exercise is noticing which questions you cannot answer at all. An unanswerable question is more informative than a "no" — a "no" means you know where you stand.
Where CryspIQ® sits against these
CryspIQ® was built around these requirements rather than retrofitted to them.
Master data has a single meaning because the enterprise data model is pre-defined and provides exactly one place for each business object — a constraint, not a policy. Relevance is a decision made at mapping time rather than deferred. Sensitive data protection is applied to the data itself, so it travels into every downstream use. Data quality is assessed as data loads, with an organisation-wide score and steward dashboards, rather than as a downstream cleanup. Semantic context supplies element-level meaning, and the model itself supplies the enterprise-level relationships.
And because transactional detail is stored against the model rather than in the shape of the system that supplied it, replacing an application does not break continuity — which means it does not trigger retraining.
That is the difference between being AI-ready and being told your data is.
Further reading