Key facts
| Network posture | No external network dependency; runtime and models run inside the perimeter |
| Deployment tiers | On-prem and air-gapped alongside cloud and VPC for unclassified workloads |
| Models | Open-weight models suitable for offline operation, including Llama, Qwen, Mistral and Nemotron |
| API contract | OpenAI-compatible endpoint; no application rewrite between tiers |
| Updates | Controlled intake with verification on your cadence |
| Identity | SSO/SCIM for staff and scoped service keys inside the network |
| Records | Admin, key and inference events exportable to internal monitoring and records systems |
| Status | Live platform; enterprise deployment terms per engagement |
TL;DR
- Deploy on the isolated network; nothing crosses the boundary.
- Keep the API OpenAI-compatible so applications and training transfer.
- Run updates as a verified, versioned supply chain with rollback.
- Log for accountability: who asked, which model answered, who decided.
- Start with administrative workloads, not decisions about citizens.
How it works, step by step
- Define the network boundary and confirm which data classes may be processed inside it.
- Complete the accreditation path for the deployment, documenting models, runtime versions and update provenance.
- Size GPU capacity for the intended concurrency on each network segment.
- Install the runtime and verified open-weight models, and register them in an internal model inventory.
- Integrate SSO/SCIM for staff and scoped keys for services, with key administration separated from platform administration.
- Point existing applications at the internal OpenAI-compatible endpoint without changing their code.
- Stream admin, key and inference events to internal monitoring and records systems, then run a bounded pilot with human review.
Try it yourself
Open the sovereign AI readiness score →
Deployment on accredited networks
Government air-gapped deployments prioritise provability: which artefacts run, where data travels, and who can access the system. Plugsky runs inside the perimeter with open-weight models and no internet path, so inference, embeddings and logs stay within the accredited boundary. Platform artefacts are inventoried — model version, runtime version, provenance — so accreditation evidence reflects what is actually running.
The OpenAI-compatible endpoint matters beyond convenience: it lets applications, evaluation harnesses and developer skills transfer between unclassified cloud pilots and isolated networks without a rewrite, which shortens the path from prototype to accredited deployment.
Updates and supply-chain discipline
An isolated estate still needs patches and model refreshes. Run the intake process as a controlled supply chain: authenticated media, checksums, malware scanning, staging validation and a tested rollback. Keep a manifest so any node can be reconciled against the approved baseline, and schedule refreshes to match your change and accreditation cycles.
- Provenance: record where every artefact came from and who approved it.
- Staging: validate on a mirror of production before promotion.
- Rollback: keep the previous known-good bundle ready at all times.
Accountability and public trust
Public sector systems are accountable by design. Log identity, key lifecycle, administrative changes and per-run inference metadata so oversight can reconstruct who asked what, which model answered and which official decided. Where agents prepare material for citizens, publish a plain-language notice and provide a one-step path to a human.
Choose the first workload carefully: administrative search, document summarisation and correspondence drafting build confidence without touching entitlements. Evaluate on real query patterns with domain experts, and keep a named owner for every deployed model and agent.
Honest comparison
| Public sector concern | Plugsky air-gapped | Cloud AI service | DIY open-source stack |
|---|---|---|---|
| Network isolation | No external path | Public endpoints | Depends on your build |
| Accreditation evidence | Artefact inventory and controlled updates | Provider attestations | You assemble everything |
| API compatibility | OpenAI-compatible offline | Vendor API | You define it |
| Identity and audit | SSO/SCIM plus SIEM-exportable events | Vendor controls | Your implementation |
| Support | Defined per enterprise engagement | Standard support | Community and your team |
| Effort | Deployment and pipeline | Lowest | Highest |
Frequently asked questions
Can this run on classified networks?
Yes, where the deployment and accreditation requirements are met. The runtime and open-weight models operate with no internet path, and artefacts are inventoried for review. Specific terms are agreed per engagement.
How do updates reach an isolated network?
Through controlled intake: authenticated media, checksums, scanning, staging validation and rollback. You set the cadence to match change and accreditation cycles.
Do applications need rewriting?
No. The internal endpoint is OpenAI-compatible, so applications, SDKs and evaluation tooling carry over from pilot environments with only a base URL and model mapping change.
What is logged for oversight?
Identity and key lifecycle events, administrative changes, and inference metadata such as model version, token counts and timestamps, exportable to internal monitoring and records systems.
How do we protect citizen data?
Minimise identifiers before prompting, constrain tools to read-only where possible, and keep retention short. Air-gapped operation ensures data never leaves the perimeter.
Which workloads should come first?
Administrative search, summarisation and drafting, with human review. Entitlement decisions, enforcement and citizen-affecting actions stay with accountable officials.
How do we begin?
Start a bounded pilot on synthetic or public data while the accreditation and deployment path progresses, then promote the same code path into the isolated environment.