Where does my organisation's AI context actually live?

What the Inventory Usually Looks like

Start with the RAG pipeline. The context it works from is the document corpus you've indexed — policies, product documentation, support articles. That lives in your vector database, which you control. So far, so good.

Now the Copilot deployment. The context Microsoft 365 Copilot builds about how your organisation works — the patterns it learns from your emails, meetings, and documents — lives in Microsoft's infrastructure, governed by Microsoft's terms, and not available for export in any meaningful form. You can turn it off. You can't take it with you.

The agent frameworks are more varied. Some store context in databases you control. Some accumulate it in provider-hosted memory systems. Some build a model of your organisation's patterns implicitly, through usage, in ways that are not inspectable and not documented anywhere. Each framework has a different answer to "what does it know about us?" — and most of those answers are incomplete.

Then there are the fine-tuned models, if you have them. The organisational knowledge baked into a fine-tuned model during training is, structurally, inside the model weights. It is not a record you can retrieve, update, or audit. It is a static artefact of a training process that happened at a point in time.

The Control Question Nobody is Asking Clearly Enough

The fragmentation itself is manageable. Different tools for different purposes is normal. The problem is that nobody has asked, coherently, what the aggregate of all this context is, whether it is accurate, whether it is current, and what happens to it when a tool is replaced.

When a vendor changes their pricing and you evaluate alternatives, one of the real costs of switching is the context that has accumulated inside the incumbent tool. That cost is rarely calculated because the context was never inventoried. It existed implicitly, built up through use, and its value only becomes visible at the moment you try to leave.

This is the provider capture problem stated plainly: organisations are building organisational intelligence inside tools they rent, under terms that give the provider structural advantage at renewal time. Not because anyone decided this was acceptable — because nobody asked the question clearly enough when the tools were adopted.

What the Auditability Gap means in Practice

There is a related problem that shows up before any switching decision arises.

If an agent makes a decision that needs explaining, one of the questions that needs answering is what context it was working from. For most organisations, that question is harder to answer than it should be — because the context is distributed, partially implicit, and not designed for inspection. The RAG pipeline has retrieval logs. The Copilot deployment does not produce a readable record of what organisational context it drew on. The agent framework has whatever its logging configuration captures.

The answer to "what did our agent know?" becomes a forensic exercise across multiple systems, each with different logging granularity, rather than a straightforward retrieval from a coherent record. The governance gap isn't always in the agent — it's often in the architecture around it.

What Coherent Ownership Requires

The question "where does our AI context live?" is answerable in a short sentence if the context was designed to be owned. It requires a forensic exercise if it wasn't. The difference between those two outcomes is a design decision made — or not made — at the point of tool adoption, usually before the cost of fragmentation was visible.

That decision is: to treat organisational context as something that belongs to the organisation, lives in infrastructure the organisation controls, and is maintained as a deliberate record rather than accumulated as a byproduct of tool usage.

Some fragmentation is deliberate and functional — different tools for different purposes is a reasonable architecture. The issue isn't fragmentation itself. It's that the context which accumulates in the gaps between tools, inside provider-hosted runtimes, and through implicit learning during use is neither deliberate nor inspectable. The parts you chose to fragment, you can reassemble. The parts that were never yours to begin with, you can't.

Most organisations haven't made that decision yet. They've adopted tools, built context implicitly, and will discover the fragmentation at the point where it starts to cost them — at renewal, at departure, or when something goes wrong and the audit trail doesn't exist.