Key facts
| Bank fit | Boundary chosen per workload; one API across all deployments |
| Private access | Private endpoints; traffic stays in the deployment you select |
| Residency | Region-locked planes: EU (Frankfurt), GCC (UAE), APAC (Singapore), US (Virginia) |
| Identity | Scoped API keys, RBAC and SSO/SCIM |
| Retention | Configurable prompt retention; confirm your terms in the DPA |
| Audit | Inference, key and admin events exportable to SIEM |
| Pricing | Flat monthly self-serve plans; no per-token billing |
| Free plan | plugsky-micro and plugsky-lite, no card; 14-day full-access trial |
TL;DR
- Decide the data boundary per workload before choosing models or vendors.
- Keep one OpenAI-compatible API so boundary changes never become rewrites.
- Scope keys per service and environment; give people SSO and RBAC instead.
- Agree retention terms in the DPA and set the shortest workable period.
- Export auth, key and inference events to the SIEM for supervisory review.
How it works, step by step
- Classify candidate workloads and record the permitted boundary for each: region-locked plane, bank VPC, on-prem or air-gapped.
- Deploy a pilot workload behind the bank's gateway with egress rules limiting which destinations it can reach.
- Issue scoped keys per service and environment from the bank's secret store, and federate operator access through SSO with SCIM and RBAC.
- Minimise data before prompting — redact identifiers the task does not need and keep mappings inside bank systems.
- Set prompt retention per workload to the shortest period policy allows, and confirm the terms in the DPA review.
- Export authentication, key lifecycle, admin and inference events to the SIEM, and test incident response against the pilot.
- Keep customer-facing decisions behind human approval gates and your own entitlements rather than in the model layer.
Try it yourself
Open the private LLM deployment estimator →
Private means a boundary, not a promise
For a bank, private AI is an architectural property: you can point to where prompts, embeddings and logs live, who can reach them, and what leaves the boundary. Plugsky supports that with deployment variants rather than a single take-it-or-leave-it cloud. A region-locked plane keeps processing in a chosen jurisdiction; VPC deployment keeps it in the bank's cloud tenancy; on-prem and air-gapped keep it inside the bank's own network or an isolated enclave.
Because all variants expose the same OpenAI-compatible API, the boundary becomes a per-workload decision that platform engineering can change without application teams rewriting prompts or SDK code.
The controls that make it defensible
Boundary is necessary but not sufficient. Banks need identity, least privilege, retention control and evidence, all of which should be designed into the pilot rather than added before an audit.
- Identity: scoped keys per service and environment; SSO with SCIM and RBAC for people.
- Least privilege: read-only keys for summarisation, action-capable keys only where function calling is required.
- Retention: configurable per workload; documented in the DPA and internal records schedule.
- Evidence: authentication, key lifecycle, admin and inference events to the SIEM.
Governance and honest limits
Private deployment does not transfer responsibility. The bank still owns data classification, model risk assessment, customer consent decisions and regulatory reporting. Plugsky provides the API, the deployment options, scoped authentication and audit events; it does not make credit, KYC or suitability decisions, and it does not replace the bank's policy engine.
Be precise about capability too: chat, streaming, JSON mode, function calling and embeddings are live in every deployment, while audio, images, files, batch, moderation, fine-tuning and assistants are labelled coming soon. For plan and enterprise scoping details, see the live pricing page.
Honest comparison
| Concern | Plugsky private AI | Consumer AI tools | Self-hosted open models |
|---|---|---|---|
| Data path | Region, VPC, on-prem or air-gapped at your choice | Vendor cloud on vendor terms | Inside bank infrastructure |
| Retention | Configurable; confirmed in the DPA | Often used to improve products | Bank defines everything |
| Identity | Scoped keys, RBAC, SSO/SCIM | Personal accounts | Custom-built |
| Models | 30+ models, one OpenAI-compatible API | Single-vendor models | Only what the bank can serve |
| Effort | Days to integrate a pilot | Minutes, low control | Months of MLOps |
Frequently asked questions
What makes Plugsky private AI different from a standard cloud API?
You choose the deployment boundary — region-locked plane, VPC, on-prem or air-gapped — and every variant keeps the same OpenAI-compatible API, so privacy is an architecture decision rather than a vendor promise.
Where is data processed?
Wherever you place the deployment. Region-locked planes cover EU (Frankfurt), GCC (UAE), APAC (Singapore) and US (Virginia), while VPC, on-prem and air-gapped options keep processing inside the bank.
How long are prompts retained?
Retention is configurable per workload. Set the shortest period your policy allows and confirm the specifics in the DPA before production traffic.
How do we control who can use it?
Scoped keys per service and environment, SSO with SCIM for staff, and RBAC for administrative actions. Least privilege should be enforced at your gateway.
Can the model execute banking transactions?
No. Use function calling for approved internal APIs under bank policy, and keep payments, credit decisions and customer communications behind human approval gates.
What audit evidence is available?
Authentication, key lifecycle, administrative and inference events can be exported to your SIEM, giving a joined view of access and model activity.
How do we start?
Pick one low-risk workload on a free workspace with plugsky-micro and plugsky-lite and synthetic data, then scale through a paid plan or enterprise scoping.