A managed alternative to self-hosted AI — and an honest look at what you give up

The searches are unambiguous: self-hosted AI agent, on-prem LLM, private AI deployment. Read them literally and they describe an infrastructure choice. Talk to the people typing them and it is almost never about the infrastructure. It is about what the infrastructure is standing in for.

Self-hosting became the default shorthand for a set of requirements because, for a long while, it was the only way to get them. If you wanted certainty that your customer records were not being used to train someone's model, running it yourself was the only certainty on offer. The requirement was trust. The server was just the mechanism people could point at.

So it is worth separating the two, because the mechanism carries a bill that the requirement does not.

Almost every self-hosting conversation we have seen decomposes into the same four things. Not five, not one — these four:

• Your data does not leak into someone else's model or someone else's tenant. No training on your content. No shared index where a neighbouring customer's query can surface your document. This is the requirement that produces the most self-hosting decisions, and it is fundamentally about isolation, not about location.
• Control over what the system is allowed to do. Reading your data is one risk; acting on your systems is another entirely. Anyone serious about running an agent against production wants a hard answer to "what can this thing actually change?" — and wants that answer enforced somewhere the model cannot reach.
• A predictable jurisdiction. Where the data physically sits, under whose law, with which sub-processors. Often this is a procurement or regulatory constraint arriving from outside the engineering team, and "somewhere in the cloud" does not survive the questionnaire.
• No lock-in. The ability to take your knowledge base, your data and your history and walk away without a migration project that costs more than the software did.

Notice that none of the four says "on my hardware". Hardware is one way to satisfy all four at once — an expensive, blunt, effective way. The interesting question is whether there is another.

We are not going to pretend self-hosting is a bad idea. Plenty of teams do it well, and for some of them it is unquestionably right. But the bill is bigger than the deployment, and it is worth putting on the table before you sign up for it:

• Operations, forever. Not the install — the Tuesday at 2am eleven months later. Uptime, capacity, GPU cost or inference latency, someone on call who knows what the vector store does when the disk fills.
• The model treadmill. Models improve on a cadence you do not control. Staying current means re-evaluating, re-benchmarking, re-tuning prompts and re-testing behaviour against your own data — a rolling engineering commitment, not a one-off upgrade.
• Security work that has nothing to do with AI. Patching, secret rotation, access reviews, dependency CVEs, network boundaries. The AI stack does not exempt you from any of it; it adds surface.
• The governance layer, which you still have to build. This is the cost people consistently forget. Self-hosting gives you an agent inside your perimeter — it does not give you a catalogue of allowed actions, role checks, approval thresholds, or an audit trail. The hard part of safe execution does not come in the box; you write it yourself. We break down what "it" actually consists of in AI agent guardrails.
• Retrieval quality, which is also yours to own. Getting an agent to answer correctly from your documents is real, ongoing work — chunking, indexing, evaluation, keeping the index in step with reality. See enterprise RAG for what that involves.

Add it up and the honest framing is this: self-hosting buys you the four requirements by handing you a product to run. If your team wants to run that product, that is a legitimate trade. If your team wants the four requirements and would rather spend its engineering time on your own business, you are paying a large price for a mechanism you did not actually want.

This is where our delivery model sits, and it is a deliberate choice rather than a limitation we are dressing up. ai.NEST runs as a dedicated, isolated instance, hosted in the EU and operated by us — on your own domain, with your own data sources connected. Against the four requirements:

• Isolation: your instance is yours. Your knowledge and your data are not pooled into a shared index and are not used to train models. Credentials are encrypted and scoped per tenant. We do not read your data, we do not analyse it, and we do not sell it.
• Control over actions: the agent never holds standing access to your database. It proposes; a policy engine checks role, allowed action and thresholds; a human approves where you decide a human must; the executor calls your API. That chain is the product, not an add-on.
• Jurisdiction: EU-hosted, on infrastructure we can point at. This is a fact about where things run — not a compliance certificate, and we will not pretend otherwise. What it does do is make the evidence for frameworks such as GDPR, DORA or the AI Act materially easier to produce, because location and audit trail are both answerable questions rather than shrugs.
• No lock-in: your knowledge base, your structured data and your full audit log are exportable in standard formats, at any time, without asking us nicely. Leaving should cost you a download, not a quarter.

You do not have to run it yourself to own what matters. Isolation, control, jurisdiction and exit are contract terms, not hardware.

And the operational bill from the previous section is ours. The model treadmill, the on-call, the retrieval tuning, the policy layer — that is the work we are in business to absorb.

Here is the part most vendor pages leave out. Some requirements cannot be reframed, and pretending otherwise wastes everyone's time.

• "It must run on our metal." Air-gapped environments, defence, certain public-sector and critical-infrastructure mandates where physical custody is non-negotiable. We are managed-only. That is a straight no, and it is the right answer.
• "We need the source code." We do not hand over the codebase. If your requirement is to own and modify the system yourself, we are the wrong shape of thing.
• "We want to run it ourselves because we enjoy it, and our team is good at it." Entirely fair. Take the four requirements, the cost list above and the guardrail checklist, and go build it well.

We would rather be clear about this early than discover it in month three. ai.NEST is in private beta, and being explicit about our edges is part of how we are choosing who to build with — you can read more about how we work on the about page.

If you are evaluating managed against self-hosted, the marketing on both sides will sound reassuring. These questions cut through it faster than a feature matrix, and you should aim them at us as readily as at anyone else:

• Is my instance isolated, or am I a row in a shared index? Say it precisely.
• Is my content used to train or improve any model, ever, including in aggregate?
• Where does it run, on whose infrastructure, and who are the sub-processors?
• What exactly can the agent do to my systems — and where is that list enforced?
• Who approves an action above a threshold, and what is written down when it runs?
• If I leave tomorrow, what do I get back, in what format, and how long does it take?

A vendor that answers all six plainly is offering you the substance of self-hosting. A vendor that gets vague on two of them is offering you the vibe of it, and you would be better off with the server.