When the Data Cannot Leave the Building

There is a moment in a lot of enterprise AI conversations where someone from security asks where the data goes, and the project quietly dies.

It is a fair question and the honest answer is usually uncomfortable. Most AI architectures assume that documents, records and conversations can be sent to an external API. For a hospital holding patient records, a lender holding financial histories or a legal team holding a contract estate, that assumption is not a detail to be negotiated. It is the end of it.

For several years the trade-off was real: keeping data inside your boundary meant giving up most of the capability. That is no longer true, and a lot of security postures have not caught up with the change.

What on-premise actually means

The phrase gets used loosely, so it is worth being precise. A deployment where data stays inside your infrastructure means the whole path stays inside it: the documents, the retrieval index, the embeddings, the model weights, the inference, and the logs.

That last one catches people out. A system can run inference locally and still send prompts to a hosted observability service, at which point the sensitive text has left anyway — just through a door nobody was watching. Anything carrying user content is in scope, including the tooling you added to debug it.

We have run this properly: a full agentic stack — retrieval, models and governance — operating entirely on a hospital network's own GPUs, with no patient data transmitted to any external service. That deployment reduced specialist misrouting by 59%, which is the part worth noticing. The constraint did not cost the outcome.

Open weights made this practical

The reason this changed is that open-weight models became good enough.

Two or three years ago, choosing a self-hosted model meant accepting a substantial capability gap against the frontier. Today, for the tasks most enterprise systems actually perform — retrieval-grounded answering, extraction, classification, summarisation, routing — that gap has narrowed to the point where it rarely decides the architecture.

This matters because most enterprise AI is not asking a model to be brilliant in the abstract. It is asking it to read the right document and answer accurately from it. That workload is far more sensitive to retrieval quality than to raw model capability, which is fortunate, because retrieval quality is entirely within your control.

Design for the boundary before the architecture

The expensive mistake is treating the data boundary as a compliance review at the end. By then the architecture assumes external calls in a dozen places and the remediation is a rewrite.

Where data may live is a first-class input, settled before anything is designed. It determines model selection, hosting, how observability works, whether a managed vector database is available, and what can be used for evaluation. Deciding it first costs a conversation. Discovering it in a security review costs a quarter.

Prompt injection is an access control problem

Once a system retrieves documents and takes actions, the threat model changes in a way traditional application security does not cover.

Any text the system reads — an uploaded document, a web page, an email in a queue — may contain instructions aimed at the model rather than information about the subject. The mitigation is not primarily a cleverer prompt. It is that retrieved content is treated as data and never as instruction, and that the model's permissions are narrow enough that following a malicious instruction achieves nothing useful.

If an agent can only read what the current user is entitled to read and can only take actions that user could take, injection degrades from a breach to a nuisance. That is an access control design, and it should be the first line rather than the last.

Prove the boundary rather than asserting it

A claim that data stays inside the network is testable, and it should be tested rather than trusted.

Egress monitoring on the deployment, an inventory of every outbound call the stack can make, and a check in the build that fails if a new dependency introduces one. Vendors change defaults, a library adds telemetry in a minor version, and a well-meaning developer adds a hosted error tracker. None of that is malicious and all of it breaches the same guarantee.

The organisations that get this right treat the boundary as an invariant with a test attached, not as a statement in an architecture document.

---

iLeaf builds AI that runs inside your infrastructure where it has to — see Healthcare, Legal & Contract Intelligence and AgentOps & MLOps.