Data for AI

For twenty years, getting the data ready meant the warehouse. You modelled your entities and built pipelines into them. Analytics ran on the clean thing at the end. That work still matters. It is not what an AI assistant runs on.

An assistant answers by finding things and reading them. It reaches into documents, mailboxes, team sites, the PDF somebody attached to a ticket in 2019. Nobody wrote a schema for that material. Most of it has no owner and no metadata beyond a filename.

So the question became harder. Can a machine find the right thing? Is it allowed to? Can it tell that what it found is still true? Almost every disappointing rollout I have seen fails on one of those. Very few fail on the model.

"Get your data ready for AI" gets said constantly and almost never defined. It sounds like a single job. It is four jobs. They fail in different ways. The fix for one does nothing for the others.

The useful part is that each failure has a signature. Your people are already describing them to you. "It doesn't know anything about our business" is a reach problem. "I can see the salary file" is a permission problem. "It gave me the old policy and sounded certain" is a truth problem. "It couldn't find it, and I wrote that document" is a retrieval problem. Sort the complaints and you have most of a diagnosis before anyone opens a tool.

The four, in the order they are usually worth asking:

• Reachable. Can the assistant see this material at all? The question is whether there is a route to it. It is not whether it exists somewhere in the company.
• Permissioned. Should it see this, for the particular person asking? Access that was too wide for years becomes visible the week an assistant starts answering.
• True. Is what it found still correct, or was it replaced two years ago and never removed?
• Retrievable. Can it find the right passage and actually read it? A scanned contract is present and unreadable at the same time.

Three of those four announce themselves. A missing source leaves an obvious hole. A permissions failure produces an incident and everybody hears about it. A retrieval failure returns nothing. That is irritating but honest.

The third one does not. Stale content produces a fluent, confident, wrong answer. It is handed to somebody who had no reason to doubt it. No error, no alert, no flag. They act on it. The cost turns up weeks later somewhere that looks unrelated.

And here is the part worth sitting with. Every control in the Microsoft stack governs who can see what. Sensitivity labels, access reviews, discovery controls and data loss prevention are all about access. None of them ask whether a document is still correct. A superseded file with immaculate permissions passes every check you own. Then it grounds a wrong answer with complete confidence.

That gap is where I do most of my useful work. Nobody has a product for it.

People talk about data readiness as one thing that scales. It is two different problems. Treating a small company like a scaled-down large one wastes most of the effort.

A large organisation has a governance problem. Too much is visible. There are years of sites with permissive sharing defaults and permissions nobody has audited. An assistant will faithfully surface anything a person already had access to and never noticed.

A smaller organisation usually has the opposite problem. Not too much visible, too little. The knowledge that actually runs the business sits where an assistant structurally cannot reach it. No amount of permission tidying will help.

The evidence for the second one is stronger than most people expect. Xero has about 1.32 million UK customers. There is no Microsoft-built Copilot connector for Xero, Sage or QuickBooks. The only finance connectors are capital-markets data providers. WhatsApp reaches around 90% of UK online adults. Copilot has no way to see it at all. Meanwhile smaller firms run more parallel platforms than large ones, not fewer.

Which one you are decides where the work starts. A large organisation starts by fencing. A smaller one starts by feeding. Same method, opposite first move. Getting it the wrong way round wastes the first month.

The failures are consistent enough to list. That is the good news. It means they are known problems, not mysteries.

• Permissions nobody has audited. The assistant is not overstepping. It is exercising access people already had, at a speed that makes it obvious.
• Controls that do less than people think. Labelling a SharePoint site Confidential does not encrypt or restrict the files inside it. Container labels are not inherited by items. Microsoft says so twice across two documentation pages.
• The wrong review. Entra access reviews cover group and role membership. A SharePoint site is not even a reviewable resource type there. Direct permissions on a site are exactly where oversharing lives.
• Reports mistaken for remediation. The access governance reports, the assessments and the posture dashboards all report. None of them act without a person. Deciding who should lose access is the actual project. No product does it for you.
• Discovery controls mistaken for access controls. Some of these hide content from search results without changing who can open it. Only one of them genuinely restricts access.
• Nothing checking whether content is true. Every control above governs access. None assesses whether a document is current, superseded or simply wrong. Correctly permissioned rubbish passes every check. It then grounds a confident answer.

The order matters more than the tooling. Do these in the wrong sequence and a programme spends a year and arrives back where it started.

• Find out what it can see. Run the access reports before changing anything. Look rather than ask. Expect the first tenant-wide permissions report to take up to five days, because Microsoft documents that it does.
• Fix access before widening capability. There is always pressure to do the reverse. This is the step that gets skipped, and the one that produces the incident.
• Establish which version is the live one. An owner and a review date recorded in the content, not in somebody’s head. Superseded material moved out of retrievable space rather than left for reference.
• Make the content readable. Scanned documents actually converted, tables extracted as tables. This one is measurable. Against clean ground truth, the best extraction pipelines still lose roughly seven points of retrieval accuracy. Table-heavy questions suffer far worse.
• Measure retrieval on your own questions. Use forty real questions with known correct answers, and run them regularly. It tells you whether the right document was found at all. That is a different question from whether the answer read nicely.

Once you know what is there and what state it is in, each source needs a decision. There are four options and no fifth. "We will look at that later" is how estates stay broken for years.

• Feed. Bring it in. There is a real gap, the content is worth having, and there is a route to it. This is the expensive one. It should be the smallest pile and a deliberate choice.
• Fence. Restrict or exclude it. Know which lever you are pulling. One control changes who can open a file. One only hides it from search. One stops it grounding an answer, but it can still show in citations.
• Fix. Clean it. Re-scan the contracts, merge the four versions, retype the table that only exists as a picture. It is unglamorous. It moves the numbers more than anything else on this list.
• Forget. Retire it. The 2019 handbook, the superseded price list, the folder from an office that closed.

This is the step that separates a result from a report. It is the one almost nobody does.

Before changing anything, write down thirty to fifty questions people genuinely ask. Skip the demo questions. Take the awkward ones, from the pilot and the helpdesk and the people who quietly stopped using it. For each one, somebody who knows the answer writes down what a good answer looks like. Then run them and score them. That first number is usually uncomfortable. It is the most valuable thing produced in the first fortnight.

Do the remediation. Run the same set again. Now the conversation is not about whether the estate feels tidier. It is thirty-four out of fifty, up from twelve. The sixteen still failing tell you precisely which source to attack next.

It is also the only honest way to price this work against an outcome. It is the only defence against the confident-wrong-answer problem too. A wrong answer next to a known-correct one is the only kind you can actually catch.

With Microsoft 365 Copilot you do not control the retrieval pipeline. Indexing is automatic and cannot be disabled. You have no control over chunking, embeddings or ranking. Anyone offering to tune how Copilot chunks your documents has misunderstood the product. Your entire surface is the state of the data and the permissions on it.

That changes completely if you build a custom pipeline. There you control everything and inherit responsibility for all of it. Knowing which of those two situations you are in is most of the decision.

I will also not tell you this takes three to six months. Microsoft publishes no end-to-end timeline for it. What is documented is component timing. Even that adds up to weeks of waiting before a person makes the first real decision.

I start by establishing what the assistant can see today. I look rather than ask. That usually produces the most uncomfortable meeting of the engagement. Better to have it with me than in front of a regulator.

Then access before capability, every time. I will push back when the pressure runs the other way. I will put the reason in terms your risk people already recognise.

After that it is unglamorous content work, prioritised by what people actually ask. There is no value in perfecting an archive nobody queries. I would rather make the two hundred documents behind the top fifty questions genuinely good.

Measurement goes in early, because without it every later argument is a matter of opinion. Your team ends up able to run the checks without me. That is the only version of this that survives my leaving.