Key facts
| Legal fit | Boundary per confidentiality tier; matter-scoped keys and namespaces |
| Private access | Private endpoints; traffic stays in the deployment you select |
| Residency | Region-locked planes plus VPC, on-prem and air-gapped |
| Identity | SSO with SCIM for staff; scoped keys per matter and system |
| Retention | Configurable prompt retention; confirm your terms in the DPA |
| Audit | Inference, key and admin events exportable to SIEM |
| Models | 30+ models behind one OpenAI-compatible API |
| Pricing | Flat monthly self-serve plans; no per-token billing |
TL;DR
- Match the boundary to the matter's confidentiality tier, not to convenience.
- Isolate matters with scoped keys and non-overlapping retrieval namespaces.
- Keep staff on SSO and services on scoped keys; never share credentials.
- Set retention per workload and document the decision in the DPA and engagement terms.
- Export key and inference events so access can be reconstructed matter by matter.
How it works, step by step
- Assign each AI workflow a confidentiality tier and record the boundary it requires.
- Deploy the pilot inside the lightest boundary that satisfies the tier: region-locked plane, firm VPC or on-prem.
- Create a key standard tied to engagement codes, and issue scoped keys per matter, system and environment.
- Namespace retrieval per matter and enforce wall checks in the gateway before any model call.
- Run staff access through SSO with SCIM, and keep client consent and delegation in the firm's authorization layer.
- Set retention per workload to the shortest period the engagement and records policy allow; confirm it in the DPA.
- Export key lifecycle, admin and inference events to the SIEM, and rehearse a wall-segregation audit.
Try it yourself
Open the AI data residency checklist →
Boundaries and walls
Legal confidentiality has two layers. The outer layer is where data physically lives: region-locked plane, firm VPC or on-prem. The inner layer is who can see which matter: keys, namespaces and gateway checks. Plugsky supports the outer layer with deployment variants behind one OpenAI-compatible API; the firm owns the inner layer, because walls are a policy construct, not a model feature.
The practical standard is one scoped key set per matter and system, one retrieval namespace per matter, and a gateway that refuses any request crossing those lines. Closing a matter then means revoking its keys and freezing its namespace — a mechanical, auditable operation.
Retention, evidence and client commitments
Retention should be decided per workload and written down: short for exploratory research, longer only where the engagement requires it. Confirm the contractual terms in the DPA, then align internal records policy with the same numbers so there are no contradictions during review.
- Access evidence: key lifecycle, authentication and admin events per matter.
- Usage evidence: inference metadata — model, tokens, timestamps — tagged with the matter.
- Data map: what was processed, where it lived and what was deleted at closure.
- Reviews: periodic entitlement reviews against active matters.
Cost, operations and honest scope
Private placement has a cost: region-locked planes are lightest, VPC adds network work, and on-prem shifts capacity, patching and monitoring to the firm. Compare the total with flat monthly plans on the live pricing page before assuming self-hosting is cheaper at a firm's volume.
Be exact about what the platform provides: the model API, deployment variants, scoped authentication, retention settings and audit events. It is not the firm's conflicts system, consent manager or records policy owner. Endpoint coverage is consistent across placements — chat, streaming, JSON mode, function calling and embeddings are live, while audio, images, files and batch are labelled coming soon.
Honest comparison
| Concern | Plugsky private AI | Consumer AI assistants | Firm-built platform |
|---|---|---|---|
| Client data boundary | Region, VPC, on-prem or air-gapped | Vendor cloud on vendor terms | Firm-controlled |
| Matter isolation | Keys and namespaces per matter | Single shared context | Custom-built |
| Identity | SSO with SCIM plus scoped keys | Personal accounts | Firm IdP integration |
| Retention | Configurable per workload, DPA confirmed | Vendor-defined | Firm-defined |
| Effort | Days for plane or VPC, weeks for on-prem | Minutes | Months |
Frequently asked questions
How do we keep one matter's data out of another's work?
Give each matter its own scoped keys and retrieval namespace, and enforce wall checks in the gateway. Sharing keys or namespaces breaks the wall regardless of deployment boundary.
Which boundary should a firm choose?
Start with the lightest placement that satisfies the matter's confidentiality tier. Region-locked planes and VPC cover most commercial work; on-prem or air-gapped suit the strictest client commitments.
How long are prompts retained?
Retention is configurable per workload. Set the shortest period the engagement and records policy allow, and confirm the terms in the DPA.
What can we show a client about confidentiality?
The deployment description, the key and namespace model, retention settings and SIEM evidence of access and model activity per matter.
Who operates the deployment?
Depends on the boundary: the vendor operates shared planes, responsibility is shared for VPC, and the firm operates on-prem. Document the split in the engagement terms.
Can we trial before committing?
Yes. Prototype on the free plan with plugsky-micro and plugsky-lite using non-privileged data, then move the workload to the required boundary.
Are all features available privately?
The core is: chat, streaming, JSON mode, function calling and embeddings are live in every placement. Audio, images, files and batch are labelled coming soon.