Key facts
| Legal fit | Matter-scoped keys and retrieval namespaces on firm infrastructure |
| Deployment | Same OpenAI-compatible API in your VPC, on-prem or air-gapped |
| Data path | Client documents, prompts and logs stay on firm-controlled systems |
| Live endpoints | Chat, streaming, function calling, JSON mode and embeddings |
| Identity | SSO with SCIM for staff; scoped keys per matter and service |
| Retention | Configurable prompt retention; review the DPA for your terms |
| Audit | Key lifecycle and inference events exportable to SIEM |
| Pricing | Flat monthly self-serve plans; enterprise deployment scoped on the pricing page |
TL;DR
- Keep client documents and prompts on firm-controlled infrastructure.
- Issue scoped keys per matter and namespace retrieval so walls hold technically.
- Let staff sign in with SSO and SCIM; services never borrow a person's account.
- Set retention per workload and document it in the DPA and engagement terms.
- Reconstruct access matter by matter from SIEM-exported key and inference events.
How it works, step by step
- Map the target workflow to a matter or practice group and define the isolation boundary before any deployment decision.
- Design the network zone and determine whether on-prem, air-gapped or a VPC deployment satisfies client confidentiality commitments.
- Create a key naming standard tied to engagement codes, and issue scoped keys per matter, system and environment into the firm's secrets manager.
- Namespace embeddings and retrieval per matter, and enforce wall checks in the gateway before any model call.
- Federate staff identity with SSO and SCIM, and keep client consent and delegation in the firm's authorization layer.
- Set prompt retention to the shortest period the engagement and records policy allow, and confirm the terms in the DPA.
- Export key lifecycle, admin and inference events to the SIEM, and rehearse wall segregation in an internal audit test.
Try it yourself
Open the private LLM deployment estimator →
Why firms move inference in-house
Client confidentiality commitments are often stricter than a general cloud contract. When a client agreement or firm policy says documents cannot leave firm-controlled systems, on-prem deployment resolves the question at the architecture level: the model runs inside the firm's network, and prompts, embeddings and logs stay there.
The API stays OpenAI-compatible, so matter assistants, contract analysers and discovery summarisers built during a cloud pilot keep working. What changes is where the work happens and who operates the capacity.
Enforcing ethical walls on firm hardware
Walls are an access-control and data-separation problem, and on-prem makes the boundary explicit. Give each matter its own scoped keys, its own retrieval namespace and its own logging tag; then make the gateway refuse any request whose session does not match the key's matter.
- Key hygiene: one key per matter, system and environment; revoke on closure.
- Retrieval: no shared namespaces across matters, ever.
- Staff access: SSO with SCIM, role-based and reviewed.
- Evidence: key lifecycle and inference events reconstructable per matter.
Deployment choice should follow the confidentiality tier: cloud or VPC for non-sensitive training and firm operations, on-prem for privileged matters, air-gapped where a client mandates it.
Retention, cost and precise boundaries
Set retention per workload — short for research and drafting, longer only where the engagement requires it — and record the decision. On-prem shifts capacity, patching and monitoring to the firm, so compare the total cost against VPC and flat monthly plans on the live pricing page rather than assuming self-hosting is cheaper at small volumes.
State boundaries clearly in client conversations: Plugsky provides the model API, scoped keys, retention settings and audit events. It is not the firm's conflicts system, consent manager or records policy owner. Endpoint status is the same across deployments: chat, streaming, JSON mode, function calling and embeddings are live, while audio, images, files and batch are labelled coming soon.
Honest comparison
| Concern | Plugsky on-prem | Shared cloud API | Firm-built stack |
|---|---|---|---|
| Client data location | Firm network only | Leaves the network | Firm network, custom built |
| Matter isolation | Keys and namespaces per matter | Application-level only | Whatever the firm builds |
| Application change | None: OpenAI-compatible API | None | Custom client and serving |
| Retention | Configurable per workload | Vendor-configured | Firm-defined |
| Effort | Deployment plus firm operations | Lowest | Highest |
Frequently asked questions
How do ethical walls work technically?
Each matter gets its own scoped keys and retrieval namespace, and the gateway refuses requests that cross walls. Walls are enforced in firm-controlled systems, not by the model provider.
Can lawyers share keys to simplify administration?
No. Shared keys destroy attributability and make wall enforcement impossible. Issue keys per matter and system, and revoke them at closure.
What happens to prompts and documents?
They stay on firm-controlled infrastructure in on-prem deployments. Configure retention per workload and confirm the specifics in the DPA.
Which tasks suit on-prem deployment?
Privileged drafting, contract analysis and discovery summarisation where client agreements restrict external processing. Firm operations with lower sensitivity can stay on cloud or VPC.
How do we evidence confidentiality to a client?
Export key lifecycle, admin and inference events to the SIEM, and reconstruct access by matter. Combined with the deployment description, that is a concrete control narrative.
Who operates the platform?
The firm, on its own infrastructure: capacity, patching, monitoring and incident response, with vendor support and releases under the licensing agreement.
Can we pilot first?
Yes. Prototype on the free plan with plugsky-micro and plugsky-lite using non-privileged data, then move the workload on-prem when policy requires it.