Key facts
| Deployment | Sovereign, VPC, on-prem and air-gapped options for in-country processing |
| Data residency | Region selection and sovereign deployment choices |
| Access control | Scoped API keys with rotation; enterprise SSO and RBAC options |
| Auditability | Request, model and response logging for public accountability |
| Data grounding | Embeddings and RAG are live for legislation, policy and service content |
| Models | 30+ models behind one OpenAI-compatible API |
| Pricing model | Flat monthly self-serve plans; no per-token billing on self-serve |
| Endpoint roadmap | Audio, images, moderation, batch and fine-tuning are coming soon |
TL;DR
- Classify data first; sovereignty requirements differ by class and agency.
- Prefer sovereign, on-prem or air-gapped deployment for sensitive workloads.
- Scope access by role and keep named accountability for every workflow.
- Log interactions to support public accountability and audit requests.
- Apply statutory retention and disclosure rules to prompts, outputs and logs.
How it works, step by step
- Classify data by sensitivity and map the residency and handling requirements for each class.
- Decide the deployment per class: region-selected cloud, sovereign, on-prem or air-gapped.
- Complete vendor assurance: architecture, data flow, security documentation and SLA review.
- Scope keys and console access by role, with rotation and a central inventory.
- Ground answers in current legislation and policy, requiring citations per response.
- Define retention and disclosure rules for prompts, outputs and logs, and apply them technically.
- Publish an internal accountability map: who owns each workflow and who reviews outputs.
Try it yourself
Open the sovereign AI readiness score →
Sovereignty and procurement
Public-sector buyers need evidence, not assurances. Prepare the package once: an architecture diagram, a data-flow map for each service, security and retention documentation, and the service agreement terms. Plugsky supports region selection plus sovereign, on-prem and air-gapped deployment, and the OpenAI-compatible API means a proof-of-concept built on public content transfers to the production environment without code changes.
See the procurement checklist for the questions to formalize early.
Identity, access and insider risk
Government systems carry insider and accountability risks as much as external ones. Issue keys per application and environment, keep them in a secrets manager, and separate build, approval and operate roles so no single person can change a production workflow unchallenged. Enterprise SSO and RBAC options align console permissions with personnel records and revocation processes. Quarterly access reviews keep the map current as agencies reorganize.
Auditability and records retention
Every automated interaction that informs a public decision should be reconstructable: request ID, model and version, retrieved sources, output and the responsible officer. Apply statutory retention schedules to those records, and make deletion technically enforced rather than aspirational. Where disclosure rules apply, the log structure should make redaction practical without losing the audit trail.
Public communication and accountability
Citizens deserve to know when AI is involved in a service and what they can do about an error. Publish a plain-language description per service: what the system does, what data it uses, who reviews outputs, and how to appeal. Internally, name an accountable owner for each workflow and review a sample of interactions regularly so quality and fairness issues surface before they become public.
Honest comparison
| Control area | Plugsky capability | Common gap | Owner |
|---|---|---|---|
| Sovereignty | Sovereign, VPC, on-prem and air-gapped deployment options | Data processed outside the jurisdiction | Program office |
| Vendor assurance | Architecture, data-flow and SLA documentation | No evidence pack prepared | Procurement |
| Access | Scoped keys, rotation, enterprise SSO and RBAC options | Shared credentials across agencies | Security |
| Auditability | Request, source and officer-decision logging | Decisions not traceable | Audit and records |
| Retention | Configurable logging under statutory schedules | Deletion not enforced | Records management |
| Transparency | Citations and structured output for review | AI involvement undisclosed | Communications |
Frequently asked questions
Can processing stay inside the country?
Yes for supported regions, and by construction with sovereign, on-prem or air-gapped deployment. Confirm the specific region and data flow in writing during procurement.
What evidence do we need for procurement?
Architecture and data-flow diagrams, security and retention documentation, SLA terms and an access-control model. Prepare it once and reuse it across services.
How do we make decisions auditable?
Log request ID, model and version, retrieved sources, output and the responsible officer. Retain per statute and restrict access to authorized staff.
Is Arabic supported for citizen services?
Multilingual chat and embedding models are in the 30+ model catalogue. Evaluate on real service questions and local dialects before enabling a channel.
What about appeals when the AI is wrong?
Design an appeal path per service, name an accountable owner, and keep the interaction log available so the case can be reviewed against the same evidence.
Which endpoints are live today?
Chat, streaming, JSON mode, function calling, embeddings, RAG and agents are live. Audio, images, moderation, files, batch, assistants, responses and fine-tuning are coming soon.
Where should a pilot start?
Use public legislation and service content on the free plan, validate citations and logging, then move sensitive services into a sovereign or private deployment.