Self-hosting legal AI: what it actually means

Self-hosted has become one of those phrases that means less the more it gets used. Some vendors apply it to a product where your documents sit in their cloud but you get a dedicated database. Others mean an on-premises agent that phones home to their AI anyway. When the data in question is privileged client communication, the difference between those arrangements and actual self-hosting is not a nuance — it is the whole question.

So here is the concrete version, using EdgeLex as the example, of what self-hosting a legal platform actually covers — and, just as important, what a well-built managed cloud gives you when running your own infrastructure isn't the right call for your firm.

Two deployment models, both first-class

Start with the thing most self-hosting articles bury: EdgeLex runs both ways, and the firm picks. In EdgeLex-managed cloud, EdgeLex hosts and operates the stack for you — there is no infrastructure to run, no servers to patch, no on-call rotation to invent. Self-hosted, the same stack runs in your private cloud or on your own hardware, operated by your firm.

These are equals, not a headline product and an asterisk. The controls that matter — which AI models are allowed to run, who can use them, what actions require approval, where the audit trail lives, evidence-gated answers — apply identically in both. In either model the firm remains the authority layer over its identity, its data, its audit trail, and its AI policy. Self-hosting is not the price of admission for control; it is the option for firms that want sovereignty all the way down to the metal.

That framing matters because the honest trade-off is operational, not ethical. Managed cloud trades infrastructure work for operational simplicity while keeping firm control intact. Self-hosting trades operational simplicity for maximum sovereignty. Neither choice requires apology, and firms with different sizes, client bases, and IT capacity will reasonably land in different places.

What actually runs in a self-hosted deployment

When a firm self-hosts EdgeLex, it is not hosting a login page in front of someone else's platform. The entire operating system for the practice runs as one coordinated, container-based stack inside infrastructure the firm controls:

• The application itself — matters, tasks, billing and trust accounting, documents, calendars, intake.
• The AI runtime — the layer where Lex actually thinks, including its governance: model policy, evidence checks, and approval gates.
• The document system — every version of every document, in the firm's own storage, with its full audit history.
• The email stack — the firm's mailboxes and domains, with message bodies and attachments in firm-controlled storage.
• Identity — the firm's own authentication realm, with its roles, sessions, and multi-factor policies.
• The database and monitoring — the record itself, and the telemetry that watches over it.

One item on that list deserves emphasis because it is the one vendors most often quietly exclude: the AI itself. In many products marketed as private, your documents may stay put, but every AI request still travels to the vendor's model in the vendor's cloud. In a self-hosted EdgeLex deployment, the AI runtime — the governance layer, the evidence checking, the audit logging, and, if the firm chooses local models, the model inference itself — runs inside the firm's perimeter.

Models on your own hardware — including your own model

Model choice is where self-hosting stops being an infrastructure preference and becomes a practice decision. EdgeLex lets the firm choose across a full spectrum: frontier models through the firm's own API keys, local open-source models running on the firm's own hardware, or — through the Lex Training Center — the firm's own model, fine-tuned on its own curated work product, in its own infrastructure.

A local model changes the confidentiality math completely. A prompt that contains privileged material is processed on a machine your firm owns, and the response is generated there too. Nothing about that request ever exists outside your walls. It also changes the cost math: local inference has zero marginal token cost, which makes high-volume AI work — triaging every inbound email, summarizing every document that lands on a matter — economically boring instead of a metered anxiety.

The Training Center extends this to the model itself. Feedback from real work is captured as signal only — nothing auto-trains, and a thumbs-down never silently rewires anything. When the firm deliberately curates a dataset, it can fine-tune a local open-source model on its own examples, with curation gates that fail closed and holdout evaluation to keep the measurement honest. The dataset and the resulting weights never leave the deployment. The model belongs to the firm — and it still runs under exactly the same governance as any frontier model, because a firm-tuned model is still just a model under policy.

In many products marketed as private, your documents stay put — but every AI request still travels to the vendor's model in the vendor's cloud.

What leaves your infrastructure, and what never does

The cleanest way to evaluate any deployment claim is to trace the data. In a self-hosted EdgeLex deployment running local models, the answer is stark: client documents, email, messages, meeting recordings, matter data, billing records, and audit logs all live and stay in firm-controlled infrastructure. AI processing happens inside the perimeter. Even citation verification is designed for zero egress — a national authority ledger built from the Free Law Project's CourtListener corpus lives inside the deployment, so essentially every published US caselaw citation verifies locally, without the query leaving your infrastructure.

If the firm chooses to use frontier models for some work, that is a deliberate, governed choice: the firm brings its own keys, credentials are stored encrypted, and the firm's model policy decides which tasks may use which models — with a default-deny posture, so no model runs unless the firm has allowed it. The point is not that external models are forbidden. The point is that data egress happens only where the firm decided it should, on a per-model, per-task basis, with every decision logged.

In the managed cloud, the same discipline applies with one substitution: EdgeLex operates the infrastructure, but the firm still owns the policy. Which models run, who can use them, what gets approved, what the audit trail shows — those levers stay in the firm's hands. There is no mandatory third-party access to case data in either model.

Why this matters more for law firms than for almost anyone else

Most businesses protect data because breaches are expensive. Law firms protect data because confidentiality is constitutive of the job — privilege exists only as long as the communication stays protected, and a firm's duty of confidentiality does not come with an exception for convenient infrastructure. Every third party added to the path of privileged data is a new set of access policies, retention defaults, subpoena surfaces, and breach possibilities the firm does not control.

Self-hosting is the maximal answer to that concern: the shortest possible list of parties who can touch the data — your firm, full stop. The managed cloud is the pragmatic answer for firms without the IT capacity to run their own stack: one operator, under a governance architecture where the firm keeps the authority. What neither model asks you to accept is the industry default — privileged matters flowing through models you cannot see, under policies you cannot set, producing decisions you cannot audit.

Questions to ask any vendor claiming self-hosting

Whether or not you evaluate EdgeLex, these questions will sort real sovereignty from branding in about ten minutes:

• Does the AI inference itself run in my infrastructure, or do prompts containing client data travel to your cloud?
• Does email — bodies and attachments, not just headers — live in storage I control?
• Can I run local or fine-tuned models, and who owns the weights if I train one?
• What is the complete list of data that leaves my infrastructure in normal operation, and can I turn each flow off?
• Do I lose governance features — model policy, approval gates, audit — if I choose your managed cloud instead?

That last question cuts both ways, and it is the one most firms forget to ask. A vendor whose managed offering strips out the controls is telling you the controls were never architectural. The right answer is the boring one: same platform, same governance, same firm authority — the only variable is who racks the servers.