AI-ready data

What is AI-ready data?

AI-ready data is data that an AI system can work with on its own. It has to be clean and complete, which is what data quality has always asked of you, but it also has to explain itself. The meaning of a field, the rules around it and the permissions on it all need to be recorded somewhere that a machine can read.

The reason this became a term of its own is that assistants and agents took the human buffer away. When an analyst opened a table with a column called STAT_CD, they knew from experience that a 3 means cancelled and that anything from before 2019 still uses the old coding. When a model opens that same table, all it sees is a column name of a few letters, so it starts guessing. All the knowledge that used to live in people's heads now has to move into the data itself.

Here is a test you can actually run. Hand your data to a capable new colleague who is not allowed to ask anyone anything and who only has what is written down. Everything that person would get wrong, an assistant is going to get wrong too.

What a model needs that a person does not

Names that say what they mean. A person can live with a table called fct_sls_ln_v2. A model uses the name as its main clue about what is in the table, so a bad name is not just cosmetic. It is a source of wrong answers.

Descriptions and synonyms. Your company says turnover, the model sees NET_AMT, and your managing director says top line. Something has to tie those three together, and that something is metadata that you write down once.

Relationships that are written out. People work out how tables join from context. A model works it out from the relationships you have declared, or it invents them.

One definition per number. If revenue exists three times with slightly different filters, an assistant is going to pick one of them, and it will not always pick the same one.

Permissions that sit on the data layer. If you control access by deciding which report someone gets to open, that control disappears the moment a chat interface can reach the underlying table.

A refresh you can point to. An answer without a date behind it is a claim and not a fact. When the data was last loaded needs to be visible, because nobody thinks to ask a chat window that question.

What this looks like in practice

In the Microsoft stack the work is concrete. On a Power BI semantic model you get three levers, grouped together under "Prep data for AI" and saved on the model instead of on the report. An AI data schema marks which tables and fields matter. AI instructions are free text where you explain your business vocabulary and your rules. And verified answers tie a visual you trust to a question people ask often. Once the model is in shape, you mark it as approved for Copilot.

On a lakehouse or a warehouse the equivalent work is table descriptions, column descriptions, a small curated set of tables instead of everything you have, and pairs of an example question and its query on the agent that reads them.

For documents and other unstructured content, being AI-ready means something different again. You need a consistent structure and a sensible split into chunks. You also need metadata that carries the source, the date and the audience. The retrieval step can then filter on those, so a policy document from 2019 does not end up ranking above the current version.

The part that is not a technical job

Most of the work towards AI-ready data goes into agreeing on definitions, and that is an organisational job rather than a technical one. What counts as an active customer. Whether an intercompany invoice is revenue. Which date the business means when it says the date of an order.

Those questions existed long before AI, and companies have lived with the ambiguity for years by sorting it out in conversation. An assistant cannot take part in that conversation. It picks whichever reading best matches the metadata it can see, and it does that without telling you.

Here is a sequence that works. Start with the questions people already ask most often. Follow those back to the tables and fields they depend on. Fix the meaning and the permissions there first, and only expand once that narrow path gives you reliable answers. If you try to document your whole data estate first, you are starting a project that never finishes.

What to watch out for with AI readiness

Volume is not readiness. A large lake with no descriptions is worse for an assistant than a small, well documented model, because every extra ambiguous table is another chance for it to pick the wrong one.

Documentation falls behind. A description that you write once and never look at again stops being true the moment the field changes meaning. Treat descriptions as part of your change process and not as a one-off cleanup.

Readiness applies per use case. Data that is ready for a sales question is not automatically ready for a finance question. Keep the claim limited to the domain you actually prepared.

Rewriting the prompt does not fix the model. When the answers disappoint, the reflex is to go and tweak the instructions. Nine times out of ten the fault sits in an unnamed column, a missing relationship or a duplicated metric, and no amount of prompting is going to make up for that.