Enterprise + Sovereign AI

What should banks and governments require in AI procurement?

Bank and government AI procurements should require evidence in eight areas: regulatory mapping, data residency, security controls, identity and audit, service levels, exit and portability, incident and subprocessor terms, and a realistic plan for incomplete certifications. Score evidence quality — architecture diagrams, configuration exports, audit samples — rather than accepting assurance language in a proposal.

Key facts

Deployment modelsIn-region cloud, private endpoint in your VPC, on-prem, air-gapped
ResidencyRegion-locked planes: EU (Frankfurt), GCC (UAE), APAC (Singapore), US (Virginia)
Identity and accessSAML 2.0 / OIDC SSO, SCIM, workspace/role/resource RBAC on Enterprise
Audit and keysSIEM audit export; BYOK via AWS KMS, Azure Key Vault, HashiCorp Vault or HSM
DPAStandard DPA covering GDPR Article 28, SCCs, PDPL alignment, subprocessors and 72-hour breach notice
SLA99.9% uptime on paid plans; Enterprise 4-hour support SLA — see /legal/sla
Compliance postureSOC 2 Type II and ISO 27001 readiness in progress (not yet certified); GDPR and PDPL alignment
StatusLive OpenAI-compatible API with 30+ models and automatic failover

TL;DR

  • Require a named regulatory mapping per workload, not a generic compliance statement.
  • Score residency on architecture evidence: store maps, configuration exports, audit samples.
  • Put audit rights, breach notification, subprocessor consent and exit assistance in the contract.
  • Treat in-progress certifications as a tracked risk with milestones, not an automatic disqualifier.
  • Insist on a tested exit plan: data export formats, deletion evidence and workload portability.

How it works, step by step

  1. Map each intended AI use case to its regulator and data classification before writing requirements.
  2. Issue evidence-based requirements: residency maps, identity controls, audit export, encryption and key custody.
  3. Define service levels including uptime, support response and incident communication.
  4. Require DPA terms: subprocessor list and change notice, breach notification, audit rights, deletion and return.
  5. Assess operational resilience: failover design, region strategy and disaster-recovery testing.
  6. Score responses with a rubric; weight evidence over attestations.
  7. Negotiate exit assistance and run a pilot that includes a deletion test before full award.
1Map each intendedAI use case to itsregulator and data2Issueevidence-basedrequirements:3Define servicelevels includinguptime, support4Require DPA terms:subprocessor listand change notice,5Assess operationalresilience:failover design,6Score responseswith a rubric;weight evidence

Original data

SAML 2.0 / OIDIdentity and accesStandard DPA cDPA99.9% uptime oSLASOC 2 Type II Compliance postureLive OpenAI-coStatusSource: Plugsky facts table · updated 2026-09-25

Try it yourself

Open the sovereign AI readiness score →

Eight requirements that belong in the RFP

  • Regulatory mapping — which law applies to each workload, and how the vendor supports it.
  • Residency — where inference, storage, logs and backups live; failover behavior.
  • Security controls — encryption, key custody, vulnerability management, network isolation.
  • Identity and audit — SSO/SCIM, RBAC, exportable audit logs with attributable actors.
  • Service levels — uptime, support response, escalation and credits.
  • Data terms — DPA, subprocessors, breach notice, training prohibition, deletion.
  • Resilience — failover, DR testing and capacity commitments.
  • Exit — export formats, transition assistance and evidence of deletion.

Handling certifications honestly

Many capable AI platforms are earlier in their audit journey than legacy infrastructure vendors. Plugsky, for example, is progressing SOC 2 Type II and ISO 27001 readiness rather than presenting completed certificates. The right procurement response is a risk register entry with milestones, compensating controls (private deployment, BYOK, audit export, SSO), and contractual remedies if milestones slip — not a blanket rejection or a blind acceptance.

Contract clauses worth negotiating

  • Right to audit and to receive control evidence annually.
  • Notification and objection rights for new subprocessors.
  • Breach notification timelines and cooperation duties.
  • Data localization commitments that survive failover.
  • Model deprecation notice and transition support.
  • Exit assistance with defined formats and deletion certificates.
  • Service credits tied to measurable availability.

Running the pilot

Pilots should test the contract, not just the model. Use non-production data, verify region configuration and audit events, trigger the escalation path, and run a deletion test. Document results against the rubric and attach them to the award decision. A pilot that only measures answer quality leaves the hard procurement questions untested.

Honest comparison

CapabilityPlugskyHyperscaler AI platformBuilding in-house
Residency architectureRegion-locked planes with workspace selectionIn-country regions for many servicesYour own facilities
Security controlsSSO/SCIM, RBAC, audit export, BYOKMature enterprise control setYou build and staff
Deployment flexibilityCloud, VPC, on-prem, air-gappedShared cloud with dedicated optionsYou own the stack
Contractual termsPublished DPA; SLA at /legal/slaStandard enterprise agreementsYou draft everything
CertificationsSOC 2 / ISO 27001 readiness in progressCompleted audits in many regionsYour own audit programme
Support modelEnterprise named engineer and 4-hour SLATiered global supportYour own team

Frequently asked questions

Should incomplete certifications disqualify a vendor?

Not automatically. Evaluate compensating controls, the audit timeline and contractual remedies. Completed audits from hyperscalers are stronger, but private deployment, BYOK and audit export can mitigate risk for many workloads.

What residency evidence should we demand?

A store-by-store map, workspace configuration export, subprocessor list with locations, and sample audit events. Contract language alone is insufficient.

How do we handle cross-border failover?

Make permitted failover regions explicit in the contract and configuration, and test the behavior. If in-country processing must be absolute, plan capacity and secondary deployments inside the jurisdiction.

What audit rights should we ask for?

Annual evidence, on-cause audits, and direct access to control descriptions such as SOC 2 reports when available. Define scope and notice periods so the right is usable.

Can we require that our data is never used for training?

Yes — include it in the DPA and verify how training exclusion is implemented and audited. Plugsky's platform processes customer data to provide the service; confirm current terms with legal counsel.

How do we avoid lock-in?

Require standard interfaces — Plugsky is OpenAI-compatible — plus export formats for data, prompts and vectors, and transition assistance. Keep application code portable.

What support levels exist for public sector buyers?

Enterprise includes a named engineer and a 4-hour support SLA, with terms documented at /legal/sla. Government-specific requirements should be raised with the enterprise team.