Your AI pilot works. That's the problem.

What breaks when you scale it won't be the model. It'll be your data.

By Andy Hastie

I've watched a lot of AI pilots go well. A handful of documents, a clear question, an answer that makes the room sit up. Then someone says the obvious thing: let's point it at everything. That's where it comes apart, and not because the model got worse. It's now reading material nobody ever organised for a machine to make sense of.

Near-identical drafts compete with approved documents, the summaries it writes become hard to tell apart from what they summarised, and permissions that lived in a folder don't follow the file into the database. The snake starts eating its own tail, voraciously, which is what makes it dangerous. None of that is a problem with the model, and almost all of it is decided before the model sees a thing.

The folder everyone has You know the one. Six files with almost the same name, modified within a fortnight of each other, and no reliable way to tell which counts. You find the right version by asking someone who remembers, or by opening all six. That's manageable because the person looking brings context the folder doesn't have: who sent what, which meeting settled it, what the initials mean. The authority was never in the document. It lived in an email thread, a Teams message or someone's memory, and the file has no idea it's been superseded.

An agent has none of that. It knows nothing about the meeting unless someone captured it and attached it to the document, and because it sees passages that are semantically almost identical, it'll happily hand you the version abandoned four months ago. If you're building organisational memory, particularly where you must show which version was agreed and when, that's the first thing to solve.

What happens on the way in

The tempting move, usually via Copilot, is to point an agent at the shared drive and let it get on with it. These assistants are useful, and for plenty of questions they answer perfectly well, but it's worth knowing what they do with your data. Most use retrieval-augmented generation, or RAG: documents are split into chunks, each chunk becomes a string of numbers representing its meaning (a step called vectorisation), and your question gets the same treatment, so the system finds material by looking for whatever sits closest. Keyword search, metadata filters and reranking all improve on that, but none can reconstruct authority nobody captured. Similarity just isn't the same as validity.

Near-identical files are often where you see the problems. Chunked up, they produce passages the model can't tell apart, because the signals a human would use sit elsewhere: the filename, the location, the covering email. If those never reach the system as context, the passages compete on relevance alone, and nothing tells the retrieval layer to prefer the approved document to the abandoned draft. Do that across a shared drive and you get semantic soup, and answers that are fluent, specific and apparently well sourced while resting on material that stopped being authoritative a year ago.

There's a lot of it about. IDC put enterprise data generated in 2023 at 84,876 exabytes, of which 75,469 were unstructured[1], close to nine bytes in every ten. Most of what people expect an agent to use sits outside the rows and columns conventional data strategies were built for. The system isn't short of information; it just can't tell which still counts.

Telling the machine what things are

This why we decide, before or during ingestion, what each document actually is, based on how the organisation uses it. File type and folder location alone won't get you there. What matters is what the material relates to: the therapy area, product, market and decision it was created to support, which in regulated industries usually exists already and simply hasn't been attached consistently. A second set of attributes captures status rather than subject: when it was valid, what it replaced, who owns it and who can see it.

Define those categories, attach them and use them consistently, and you have an ontology: an explicit map of the concepts your organisation works with and how they relate. It's what makes domain-specific agents possible, because you can point one at material that belongs to an area rather than everything that resembles it.

None of this looks like model work, which is why pilots skip it, and you can't buy it ready-made: it has to reflect how your organisation thinks, so the only way to build it is with the people who hold that knowledge. They're your human in the loop, and they matter rather more than the platform.

Three kinds of data, not one

There are three overlapping tiers here: what the organisation already holds, what its agents create, and live data whose truth depends on when you asked. Most AI strategies work hard on the first and leave the rest implicit.

The second matters because it feeds itself. An agent summarises a document; the summary informs a comparison across twelve more; the comparison is cited in a recommendation; the recommendation goes back into the knowledge base. Somewhere in that chain, the difference between what an approved document said and what the system inferred quietly disappears. Preventing that needs an intelligence layer where everything generated carries its own history: which documents it drew on, when, and whether a human has checked it. Which raises a question worth settling early: which outputs may become canonical, meaning treated as the official version the organisation will stand behind, and who decides? Answer it and the system grows more valuable; duck it and it grows harder to trust.

The third tier is the awkward one. CRM, sales and campaign data may be beautifully structured and well governed, but it's only true at a particular moment, and AI-generated answers are very good at hiding that. Ask how a product is performing in a region and you'll get an answer; ask a fortnight later and you may get a different one, with no explanation of what changed. Undated, neither tells a later reviewer what the system was looking at when the decision was made. So every insight drawn from changing data needs an “as of” date, and the layer above it needs to know how fast each source goes stale: field activity may change daily, prescribing data lag by weeks, market data arrive quarterly. Memory means knowing what was believed true then, not only what's true now, and it can't be bolted on afterwards.

Permissions don't travel on their own

Every organisation has rules about who sees what, and in pharma some are regulatory obligations rather than preferences: commercial and medical functions kept appropriately separate, sales data restricted by territory. Ingestion needn't erase them, since good classification workflows can reapply those controls through security and metadata policies. Make sensitivity an attribute of the material and it travels into every fragment derived from it; leave it out and the system guesses at query time, which is where a mistake costs most. Restrictions carried through the pipeline are controls; restrictions guessed at query time are hopes.

The instinct is to police all this through a review board, but that’s a fool’s errand: a system in use produces more in a week than a committee reads in a quarter, so any review that can't keep pace gets bypassed. Review belongs in the pipeline rather than in a meeting, and the job is narrower than people expect: right sources and versions, restricted material handled properly, confidence matching the evidence.

Five questions worth asking

None of this argues against investing in an AI platform, only that the platform is a far smaller part of the decision than it feels like. Five questions matter more, in this order.

1. Can you say what this document is about?

   Not its file type or folder, but its therapy area, product, market and the decision it supported. If the answer is “you'd have to open it”, the context is already lost.

   
   

2. Where did this insight come from?

   Which sources and versions, how many steps from an approved document, and did a person review it? Provenance buried in a technical log won't stay visible to the people who need it.

   
   

3. When was it true?

   Anything drawing on changing data needs its “as of” date, or it can't be audited, defended or compared with last quarter's answer.

   
   

4. Who may see it?

   And does that permission still hold once the source has been chopped up, summarised and combined with other material?

   
   

5. Who owns it when it's wrong?

   Including the one promoted two years ago, built on documents since superseded, that nobody has revisited because nobody was made responsible.

   
   

Most organisations answer the first imperfectly and the rest only partly, which is no single person’s fault: these requirements didn't exist when the files were created. Putting it right means agreeing your ontology and the rules for how data is ingested and managed. It looks like administration. It's the difference between a search tool and an organisational memory.

Where we come in

This is the work we do at 11 Minds. We sit with the people who create, approve and use an organisation's information, work out the concepts the business relies on, then build the ontologies, schemas and rules around them. What comes out isn't a better way to search documents but a knowledge base people can trust, because they can see where an answer came from, when it was true and who may use it. If those five questions are hard to answer where you work, that's the conversation worth having.

Please get in touch - max.lee@11-london.com

[1] Adam Wright, Worldwide Global DataSphere Structured and Unstructured Data Forecast, 2024–2028, IDC, September 2024, report US52554824e, Table 4.