Key facts
| Architect fit | Boundary per workload; uniform API and identity model |
| 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 workload keys plus SSO with SCIM and RBAC |
| 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; enterprise scoping on the pricing page |
TL;DR
- Define the boundary per workload, then let the API and platform stay uniform.
- Control egress from the workload subnet and keep data flows diagrammable.
- Separate workforce and workload identity; scope keys and rotate centrally.
- Make retention a design parameter, documented per workload in the DPA.
- Provide one evidence path — auth, key and inference events in the SIEM — across topologies.
How it works, step by step
- Classify workloads and assign each a boundary: shared region, region-locked plane, VPC, on-prem or air-gapped.
- Document data flows for each boundary: what enters, what is logged, where embeddings live and what can egress.
- Standardise the integration pattern: OpenAI-compatible calls through one gateway with quota, model allow-lists and logging.
- Design identity: scoped workload keys from the corporate secret store, SSO with SCIM and RBAC for people, no shared credentials.
- Set retention per workload, record the rationale and confirm the terms in the DPA.
- Specify evidence and monitoring: auth, key, admin and inference events to the SIEM, plus usage and error metrics.
- Run an exit review after the pilot: boundary verified, evidence produced, then decide on expansion.
Try it yourself
Open the data residency checker →
Boundary architecture
Private AI is ultimately a data-flow question: where does processing happen, what is stored, who can reach it, and what leaves. Plugsky gives four placements — region-locked plane, VPC, on-prem and air-gapped — all behind the same OpenAI-compatible API. Architecture's job is to map workloads to placements using classification, latency and utilisation, then verify the map against reality.
Because the API and identity model are uniform, the boundary decision does not ripple into application code. That keeps the estate manageable: one integration pattern, many placements, one evaluation baseline.
Egress control, identity and retention
Three controls do most of the work in a private design. Egress control limits which destinations the workload subnet and the model deployment can reach, making data flows diagrammable and enforceable. Identity separates people from services: SSO with SCIM and RBAC for operators, scoped keys per workload and environment for services.
- Least privilege: read-only keys by default; action-capable keys only with function calling and an owner.
- Retention: configured per workload, aligned to records policy and confirmed in the DPA.
- Evidence: authentication, key lifecycle, admin and inference events exported to the SIEM from every placement.
- Monitoring: usage, errors and latency per key so utilisation reviews have real data.
Trade-offs and boundaries to state
Private placements trade flexibility for control. On-prem and air-gapped add capacity planning, patch windows and incident ownership; VPC reduces that load while keeping data in your tenancy; region-locked planes are the lightest private option. Compare total cost — including engineering time — against the flat monthly plans on the live pricing page.
State the platform's scope precisely in architecture documents: Plugsky provides the model API, deployment variants, scoped authentication, retention settings and audit events. It is not your data catalogue, consent system or policy engine, and endpoint coverage is the same everywhere — chat, streaming, JSON mode, function calling and embeddings are live, while audio, images, files and batch are labelled coming soon.
Honest comparison
| Concern | Region-locked plane | VPC deployment | On-prem or air-gapped |
|---|---|---|---|
| Data location | Chosen Plugsky region | Your cloud tenancy | Your network or enclave |
| Operational load | Vendor | Shared | Yours |
| Control strength | Moderate | High | Highest |
| Time to pilot | Days | Weeks | Weeks to months |
| Best fit | Cross-border products with residency rules | Regulated workloads allowed in cloud | Classified, latency-critical or high-utilisation workloads |
Frequently asked questions
Which boundary should we choose first?
Start with the lightest placement that satisfies the workload's classification and residency rules — usually a region-locked plane or VPC — and move to on-prem only when policy or utilisation justifies it.
How do we keep the estate consistent?
Standardise on the OpenAI-compatible API and one gateway pattern. Boundary placement then becomes configuration, not a new integration per workload.
What does egress control look like?
Restrict the workload subnet and deployment to approved destinations, document each flow, and verify with network monitoring rather than assuming configuration is sufficient.
How is identity split?
People use SSO with SCIM and RBAC roles; services use scoped keys per workload and environment from the corporate secret store.
How do we handle retention?
Set it per workload, align it with records policy, and confirm the contractual terms in the DPA. Document the decision alongside the data-flow diagram.
What evidence will auditors receive?
Authentication, key lifecycle, administrative and inference events exported to the SIEM, plus usage metrics that show who called which model and when.
Are all features available in every placement?
The core API is: chat, streaming, JSON mode, function calling and embeddings are live. Audio, images, files, batch, moderation, fine-tuning and assistants are labelled coming soon.