Where Does Your AI's Context Actually Come From?

An employee in finance asks the company assistant a simple question: what did we agree with our logistics provider about late-delivery penalties, and has anyone raised this topic recently?

The answer arrives within seconds, and it’s a good one. To create it, the assistant assembled its context from five places: her prompt, the contract draft which happened to be open on her laptop, a search index built over the document libraries on the intranet, the ticket system (reached through a tool connection), where a colleague had logged a dispute last month, and a web search for the published terms of the provider.

So we have five sources for a single request. If you ask around in your company who can name all five, I guess in most cases nobody can. And the permission model, which we usually point to when someone asks about data governance, covers only one of them.

Why the Existing Model Does Not Fit

Enterprise governance has been built for data at rest. Data sits in a system and someone has access to it. This access is documented, reviewed and sometimes revoked. Integrations between systems are designed once, reviewed once, and then run the same way for years. This model has served us well, but it is based on three assumptions which aren’t true anymore when AI assistants come into play.

First, the assembly is decided per request. A classic integration is fixed: system A sends field X to system B every night. An assistant decides at runtime which sources it consults, and part of this decision is taken by the model itself. I experienced this myself recently: I gave an assistant some documents to work with, and the result contained the names of employees of the company the documents were about, although none of the documents mentioned them. It seems the assistant had searched the web for these people without being asked. So there’s no integration you can review once and trust afterwards.

Second, aggregation creates new sensitivity. Each of the five sources above is harmless on its own, as a contract draft, a dispute ticket and a public price list are three ordinary documents. Combined in one answer, they describe the negotiating position of the company. Classification is done per source, though. Nobody classifies the combination, as until recently the combination only existed in someone’s head.

Third, the boundary moves. We decide where data may be stored, and we have become quite good at this. But assembled context leaves the organization at inference time and not at storage time. So in addition to where the data lives, we need to ask where the context goes when the model is called.

I wouldn’t call this primarily a security problem or a tooling problem. What is missing is an architecture view. We maintain landscapes of applications, interfaces and data objects, but we have almost nothing which shows what flows into an AI assistant and where it goes afterwards.

Four Source Classes

When I draw such a view, I sort the sources into four classes. For each of them three questions matter: what flows, which part of it is private, and who decides.

From the User

This is the prompt and anything uploaded with it. It looks like the easy case, as the user chose to share it. In practice there’s a large gap between what people believe they are sharing and what is transmitted. People paste a whole spreadsheet to ask about one row, or they upload a document and forget about the appendix. So the user decides, but without seeing much of what is going on.

From the User’s Device

These are open files, screen content, a local search index and the clipboard. Assistants which are built into the operating system or the office suite read from here by design, as this is what makes them useful. Yet, the device doesn’t show up as a data source in any application landscape. We model servers and cloud applications, while the laptop is treated as an endpoint we need to secure, and not as a system which feeds data into another system.

From Internal Systems

These are retrieval indexes and tool calls into business applications. The most common failure happens here, and it’s a rather unspectacular one: the index flattens the permission model of the source system. A document library has fine-grained permissions. The search index which has been built over it for the assistant often has only one, which is the permission of the service account that crawled it. As a result, someone who could never open a document in the source system gets its content back as an answer, paraphrased and without a link. Nobody breached anything here. The architecture just did not carry the permissions over.

From External Servers

These are web search, third-party tool servers and public APIs. Tool connections are becoming more and more standardized (the Model Context Protocol, MCP, is the best-known example), which makes it very easy to add one.

Here data flows in two directions. The query, and often a good part of the assembled context, goes out to a server you don’t operate. And content you did not write comes in and is read by the model as input. I think the second direction deserves more attention than it gets. A web page or a tool response can contain text which the model treats as an instruction and not as information, and then the assistant acts on behalf of whoever wrote that page.

It’s the same lesson I described in Security by Design for Analytics Platforms: once you bring many sources together in one place, you change your own threat model.

The following diagram shows the four source classes and where the context goes:

Five Control Points

Once you see the flows, you also see where you can intervene. There are five control points, and each of them has its price.

At the source: you classify documents and exclude some of them from indexing completely. This is the most robust control, as what never enters the flow can’t leak from it. The price is that someone has to do the classification, and that every exclusion makes the assistant less useful.
At the index: you build retrieval which respects the permissions of the source system, per user and per query. This solves the most common failure described above. The price is that it is harder to build and slower to query, and that every source system models permissions in a different way.
At the connector layer: you decide from an allowlist which tool servers an assistant may use, and with which scopes. The price is a review process which slows down every new connection, and this in turn tempts people to work around it.
At the boundary: you control what leaves the organization at inference time, which means where the model is hosted, under which jurisdiction, and whether inputs may be used for training. I’ve written about the jurisdiction part in Digital Sovereignty for CIOs. The price is that you have fewer models to choose from, and sometimes a noticeably weaker one.
On the device: you define policies for what assistants may read locally, and which assistants may be installed at all. This control has the lowest price of the five, which is probably why it’s so popular.

In most organizations the device policy is the only one of the five controls in place. A device policy is useful, of course. But it covers one of four source classes at one of five control points, and it does not help with the index which flattens permissions or with the tool server nobody reviewed.

What This Means for Enterprise Architecture

The good news is that we don’t need a new discipline for this. Enterprise architecture already has the instruments: landscapes, data-flow views, classification schemes and review gates. They have just not been applied to context so far. I would start with three artifacts.

An Inventory of Context Flows per Assistant

For each assistant in use, document which sources it can reach, through which index or connector, and where the model runs. This belongs in the same repository as the application landscape and should be maintained the same way. An assistant is an application whose interfaces are decided at runtime, which is a reason to document it more carefully than other applications.

Classification of the Composite

Classify what an assistant can combine, and not only the individual sources. If an assistant can join contract data with the ticket history and the public web, the composite needs its own classification, which will usually be higher than the classification of any single source.

A Review Gate for New Connectors

Every new tool connection is an integration and deserves an integration review: what flows out, what comes in, and whose permissions apply. Keep it lightweight enough that people use it.

This is organizational work as much as architecture work. It belongs at the same shared table where security, legal and architecture already meet for data questions, as I described in Meet Once, Not Twice. I would expect a connector review which runs separately from data governance to drift away from it within a year.

Conclusion

Every CIO should be able to answer one question for every assistant in the organization: which sources feed it, whose permissions govern what it retrieves, and at which point does its data cross the boundary of the company?

If you can answer this, you have a basis for governing AI. If you can’t, I would start with the missing architecture view before talking about AI governance, and this is something enterprise architecture already knows how to create.