Government Sovereign AI Platform: What to Demand in the Tender, and How to Keep It Accredited
Sovereignty is decided twice — once when the tender is written, and again every time the platform changes. This guide sets out the requirements, the evidence to request from bidders and the accreditation lifecycle for an agentic AI platform that stays under government control.
What is a government sovereign AI platform?
A government sovereign AI platform is an agentic AI platform in which the government — not the vendor — controls where data lives, where models run, who holds the keys, who can operate the system and how changes reach it. Data, prompts, outputs, embeddings, memory and logs stay in-country; inference runs on privately hosted models; operator access is granted by the agency and logged in its own audit store. Officials keep every determination, and agents work only under approval gates the agency configures.
Plenty of products describe themselves as sovereign. The test is whether a procuring authority can verify the claim before award and keep it true after go-live. That makes sovereignty a procurement and accreditation discipline as much as an architecture: requirements precise enough to score, evidence concrete enough to inspect, and a lifecycle that re-checks the platform whenever a model, connector or version changes.
This page is written for the people who draft tenders, sit on evaluation committees and run accreditation. For the platform-wide security model, see secure agentic AI for government; for the policy question of why sovereignty matters, see sovereign AI for government.
Why procurement is where sovereignty is won or lost
Six reasons the tender document matters more than the vendor brochure.
Vague requirements score vague answers
A clause that asks whether data is 'kept secure' invites every bidder to say yes. A clause that lists the six artifacts that must stay in-country, and the evidence required for each, separates platforms that comply from platforms that intend to.
Model inference is the usual blind spot
Many offerings keep stored data in-country while sending prompts to a model hosted elsewhere. Tenders need an explicit requirement on where inference runs and which models may process which data classes.
Keys and operators define real control
If the vendor holds encryption keys or has standing administrative access, sovereignty is contractual rather than technical. Key custody and operator-access rules belong in the mandatory criteria.
Updates are a supply chain
Every upgrade introduces code and possibly new model weights. Requiring signed artifacts, staged promotion and agency-controlled timing keeps the accredited system the system that is actually running.
Accreditation must survive change
An agentic platform evolves — new agents, new connectors, new models. The tender should require the evidence that lets accreditors re-assess changes without restarting from zero.
Exit is part of sovereignty
A platform that holds the agency's audit history in a proprietary format creates dependence. Exportable definitions, data and logs — and documented decommissioning — keep the decision to stay or leave with the government.
Eight platform capabilities a tender should require — and verify
Each is phrased as something a bidder must demonstrate, not merely assert.
Full-artifact residency
Data, prompts, outputs, embeddings, memory and logs all held in-country — shown per posture.
In-country inference
Private or locally hosted models, with routing rules that bind data classes to models.
Agency key custody
Encryption keys generated and held by the agency; no vendor-held master keys.
Controlled operator access
No standing vendor access; time-bound, purpose-bound, logged support sessions.
Signed update supply chain
Signed artifacts, staged promotion and agency-scheduled change windows.
Air-gap capability
Install, operate and upgrade with no outbound connectivity via controlled media.
Inspectable audit store
Step-level, replayable logs on agency storage, exportable in documented formats.
Documented exit
Export of agent definitions, approval matrices, knowledge and audit history.
Contractual assurances vs. sovereign-labelled cloud vs. a verifiable sovereign platform
How three common offers compare on the criteria an evaluation committee should score.
| Criterion | Contractual assurances only | Sovereign-labelled shared cloud | Verifiable sovereign platform |
|---|---|---|---|
| Stored data location | Promised in contract | In-country region | Agency infrastructure or sovereign cloud, shown in diagrams |
| Model inference | Often offshore | Varies by model | Private models in-country, bound by routing rules |
| Encryption keys | Vendor-held | Shared responsibility | Agency-held throughout |
| Operator access | Vendor staff, unspecified | Provider operations teams | Agency-granted, time-bound, logged locally |
| Update path | Vendor-pushed | Provider-paced | Signed artifacts, agency change windows |
| Air-gapped operation | Not available | Not available | Supported for install, run and upgrade |
| Audit evidence | Reports on request | Console views | Raw step-level logs, exportable |
| Exit | Data return clause | Region-bound services | Documented export of definitions, data and logs |
The accreditation lifecycle of a sovereign AI platform
Six stages, from tender drafting to periodic re-accreditation.
1. Specify in the tender
Security, residency and operator-access requirements written as mandatory criteria with named evidence for each.
2. Evaluate the evidence
The evaluation committee scores diagrams, egress lists, key designs and a live demo against published criteria, and decides the award.
3. Initial authority to operate
Accreditors review a staging deployment: component inventory, data flows, guardrail tests and audit samples.
4. Operate with continuous evidence
Audit logs, evaluation results and access records accumulate as accreditation evidence during normal operation.
5. Re-assess on change
New models, connectors or major versions trigger scoped re-assessment using the same evidence pack format.
6. Periodic re-accreditation
On the agency's schedule, the full evidence set is reviewed and authority to operate is renewed or conditioned.
Workloads that typically require a sovereign platform
Problem → agent action → outcome, with the official's decision point named.
Registry-linked eligibility files
Claims require extracts from several national registries → agents gather and reconcile registry data on sovereign infrastructure, list discrepancies and assemble a cited file in the case system → case officers make the eligibility determination. Data never leaves agency control.
Protectively marked correspondence
Sensitive correspondence cannot touch offshore services → agents classify, retrieve history from the records repository and draft replies using private models → officials edit and release every reply.
Tax document processing
Filings and supporting documents carry taxpayer data → agents extract and validate figures, cross-check against prior filings and flag anomalies → tax officers decide any assessment. Inference runs on agency GPUs.
Investigation file support
Evidence spans several case systems → agents collate documents, build timelines and link related records within the sovereign boundary → investigators draw every conclusion.
Procurement evaluation support
Bid documents are commercially sensitive → agents check submissions against published criteria and prepare scoring summaries on agency infrastructure → the evaluation committee scores and decides the award.
Border and trade document checks
Trade documents include personal and commercial data → agents verify consistency across declarations, certificates and registries and flag mismatches → officers decide clearance and any follow-up action.
Health-adjacent administration
Administrative files reference health information → agents assemble documentation and check completeness against requirements using private models → authorised officials make every decision.
Inter-agency information requests
Requests between agencies involve restricted records → agents locate permitted records, prepare a response pack and log the request → the releasing official approves what is shared.
Records review before transfer
Archives must be reviewed before transfer or disposal → agents classify records and apply categories from records-retention schedules → records managers confirm, and disposal requires explicit authorisation.
Deployment postures, weighted to the sovereign end
The same platform across three postures; sovereign procurement usually specifies the third.
In-country cloud or dedicated VPC
Suitable where accredited in-country regions are permitted and inference can be restricted to in-country or private models. Often used for pilots and non-sensitive workloads.
Managed control plane, agency data plane
Data, inference and execution inside agency infrastructure; Xyner operates upgrades and monitoring. Tenders should state whether this split satisfies operator-access requirements.
On-premise, sovereign cloud & air-gapped
Full installation on agency Kubernetes or sovereign cloud, optionally air-gapped, with agency-held keys and private models. See on-premise agentic AI for government and deployment & sovereignty.
Integration inside the sovereign boundary
Six system families reached without opening new external paths.
Service portals & CRM
Intake and status through internal interfaces; no new public exposure.
Case & workflow systems
Case records read and updated over the agency network.
ERP & finance
SAP, Oracle and finance platforms through scoped service accounts.
Document repositories & records
EDRMS and archives indexed locally; retrieval never calls out.
Email & correspondence
Official mailboxes and registers handled inside the boundary.
APIs & registries
National and sectoral registries over REST/SOAP with every call logged.
Tenders should ask bidders to list every outbound connection the platform makes in each deployment posture. In Xyner's fully on-premise and air-gapped postures, connector traffic stays on the agency network and the egress list for the platform itself is empty.
Security & governance controls to score
The control set accreditors will test, enforced by the platform rather than by procedure.
RBAC & identity
Agency identity provider integration; scoped roles for every user and agent.
Approval gates
Determinations and sensitive actions wait for named officials per the approval matrix.
Step-level audit
Every agent step, tool call and approval logged and replayable on agency storage.
Guardrails & budgets
Tool allowlists, input/output policies and action budgets per agent.
Residency enforcement
All six artifact types held in-country under the chosen posture.
Private LLMs
Routing rules that keep sensitive data classes on private models.
Certifications
Xyner is SOC 2 Type II and ISO 27001 certified — inputs to, not substitutes for, your accreditation.
Evaluation & drift
Eval suites gate changes; drift detection supports continuous accreditation evidence.
Background on control design: sovereign AI platform and platform security.
Ten steps from tender to accredited production
Procurement, accreditation and delivery checkpoints in one sequence.
1. Define the first workloads
Name the workflows and data classes the platform must handle first; they drive the requirements.
2. Data-residency review
Checkpoint: classify data and confirm which postures satisfy national data-protection and residency frameworks.
3. Write evidence-based criteria
For each sovereignty requirement, state the evidence bidders must supply and how it will be scored.
4. Publish and clarify
Run the tender under public-procurement rules; answer clarifications consistently for all bidders.
5. Evaluate and award
The evaluation committee scores evidence and demonstrations against published criteria and decides the award.
6. Install on sovereign infrastructure
Signed artifacts deployed to agency Kubernetes or sovereign cloud; keys generated by the agency.
7. Approval-matrix sign-off
Checkpoint: business owners confirm which steps execute automatically and which wait for an official.
8. Security accreditation
Checkpoint: inventory, data flows, egress list, guardrail tests and audit samples to the accreditor.
9. Production with continuous evidence
Go live behind approval gates; audit and evaluation output feeds ongoing accreditation.
10. Govern change
New models, connectors and versions pass staged evaluation and scoped re-assessment before promotion.
Supplier facts for your evaluation file
What Xyner can evidence — and nothing more
Xyner is SOC 2 Type II and ISO 27001 certified, supports SaaS, dedicated VPC, hybrid, on-premise Kubernetes, sovereign cloud and air-gapped deployment, and works with public-sector teams from New York (Global HQ), Chennai, Dubai, Riyadh, Singapore and Manama. Your own accreditation of the specific deployment remains the deciding evidence.
Frequently asked questions — Government Sovereign AI Platform
What procurement leads, evaluation committees and accreditors ask.
What is a government sovereign AI platform?
A government sovereign AI platform is an AI agent platform whose data, model inference, keys, logs and operations remain under the control of the government that uses it, inside national borders and under national jurisdiction. Xyner provides this through sovereign cloud, on-premise Kubernetes and air-gapped deployment, with private language models, agency-held keys and an audit store the agency can inspect directly.
What should a tender require from a sovereign AI platform?
At minimum: in-country residency for data, prompts, outputs, embeddings, memory and logs; in-country model inference with private model options; agency-held encryption keys; operator access controlled and logged by the agency; a signed, verifiable update supply chain; air-gap capability where needed; exportable audit evidence; and a documented exit path. Each requirement should name the evidence a bidder must supply, not only a yes/no answer.
How can an evaluation committee verify sovereignty claims rather than accept them?
Ask for architecture diagrams showing every component and where it runs, a list of outbound connections in each deployment posture, key-management design, sample audit records, and a live demonstration in a staging environment with network egress blocked. The evaluation committee scores the evidence against the published criteria and decides the award; vendors' assertions alone should not score.
What is the accreditation lifecycle for a sovereign AI platform?
Accreditation is not a single event. It typically runs from pre-tender security requirements, through evidence review during evaluation, initial authority to operate on a staging deployment, continuous monitoring in production, re-assessment when significant changes occur — such as new models or connectors — and periodic re-accreditation. The platform should generate the evidence each stage needs as a by-product of normal operation.
Does a sovereign platform mean no external AI models can ever be used?
Not necessarily. Sovereignty means the government decides. Xyner is model-agnostic across 12+ LLM families; in a sovereign posture, routing rules can restrict all processing to privately hosted models, or permit specific external models for specific non-sensitive data classes if policy allows. The rule is configured, enforced and logged, not assumed.
Who makes decisions when agents run on a sovereign platform?
Officials and case officers make every determination, eligibility decision, enforcement action and award. Agents prepare, assemble, verify, route and execute administrative steps under approval gates. Sovereignty governs where and under whose control the platform runs; it does not change who holds decision authority.
Can a sovereign AI platform run fully air-gapped?
Yes. Xyner supports air-gapped installation in which platform components, container images and model weights are delivered as signed artifacts through the agency's controlled transfer process, and the platform operates with no outbound connectivity. Upgrades follow the same offline path.
How should exit and portability be written into the contract?
Require that agent definitions, approval matrices, knowledge sources, connector configurations and the full audit history are exportable in documented formats, that the agency retains its data and logs on its own infrastructure, and that decommissioning steps are documented. A sovereign platform should never make the agency dependent on the vendor to read its own records.
What certifications does Xyner hold?
Xyner is SOC 2 Type II and ISO 27001 certified. These support, but do not replace, a government's own accreditation of a specific deployment, which assesses the installation in the agency's environment against the agency's requirements.
How is vendor operator access controlled in a sovereign deployment?
In fully on-premise and air-gapped postures, the agency operates the platform and vendor staff have no standing access. Where support access is needed, it is granted by the agency for a defined purpose and period, uses agency-issued credentials and is logged in the agency's own audit store.
Can one sovereign platform serve several agencies?
Yes. A central government technology function can operate one installation with separated workspaces per agency — distinct agents, credentials, knowledge stores, approval matrices and audit partitions — so shared infrastructure does not mean shared data or shared governance.
How long does it take to go from tender award to production?
After award, a focused first workflow typically reaches production in 6–12 weeks of delivery work: installation, integration, governance configuration, evaluation and user testing. Accreditation steps run alongside and are scheduled from the start, since their timing depends on the agency's own processes.
The government security & sovereignty cluster
Related pages for drafting requirements and planning deployment.
Specify a Government Sovereign AI Platform You Can Verify
Talk to Xyner about tender requirements, the evidence pack your evaluation committee and accreditors will need, and a sovereign deployment plan.
Request a Demo Discuss Your Government Use Case