Key facts
| Failure handling | Automatic failover routing when a model upstream fails; requests retry alternate upstreams |
| Deployment models | In-region cloud, private endpoint in your VPC, on-prem, air-gapped |
| Residency planes | EU (Frankfurt), GCC (UAE), APAC (Singapore), US (Virginia) region-locked planes |
| RTO / RPO | Targets defined per workload and captured in the enterprise agreement; see /legal/sla for uptime commitments |
| Data stores | Prompts, embeddings, logs and backups must be replicated or rebuilt according to policy |
| Identity and keys | SSO/SCIM and BYOK; key availability must be part of the DR plan |
| Observability | Status page, audit logs and SIEM export support incident response |
| Compliance posture | SOC 2 Type II and ISO 27001 readiness in progress (not yet certified) |
TL;DR
- Separate the problem: model availability failover, region failover, and data recovery are three different plans.
- Set RTO and RPO per workload tier — a chat assistant and a settlement system do not need the same targets.
- Check that failover does not silently move data outside your residency jurisdiction.
- Include key management and identity in the DR plan; both can become single points of failure.
- Drill at least annually: measure actual recovery time, not theoretical design.
How it works, step by step
- Classify workloads by business impact and assign RTO and RPO targets for each tier.
- Document the failover architecture for model upstreams, endpoints and regions.
- Map data replication against residency obligations; define what may and may not cross borders.
- Verify key availability: BYOK and HSM failover behavior must be tested, not assumed.
- Prepare runbooks for incident detection, failover, communication and failback.
- Run a game-day drill with application, security and vendor teams, and record actual timings.
- Review and update after every incident and after each new region or model is added.
Try it yourself
Open the sovereign AI readiness score →
Three layers of recovery
Layer one — model availability. Individual models can degrade or be retired. Automatic failover routes a request to a healthy upstream so applications keep working; Plugsky documents this routing and publishes component health on the status page. Layer two — region failover. If an entire region is impaired, traffic must move to another permitted region. Layer three — data recovery. Prompts, vectors, logs and configuration must be restorable to the selected point in time.
Each layer has a different owner, test method and cost. Treating them as one DR plan is the most common design error.
Residency is a DR constraint
If your regulator requires in-country processing, a cross-border failover can violate that requirement even when it restores service. Define permitted failover targets in advance, encode them in routing configuration, and record exceptions. Where no compliant secondary region exists, the honest answer may be higher RTO or an on-prem secondary deployment rather than a cross-border failover.
RTO, RPO and the model itself
Models introduce a dependency that classic DR plans miss: a specific model version may not be available after an incident. Mitigate with a documented fallback chain of same-profile models, pinned versions where the API supports it, and evaluations that confirm fallback quality is acceptable for each workload. The goal is not identical output after failover; it is output that remains fit for purpose.
Exercising the plan
- Quarterly: fail an upstream model and verify transparent recovery.
- Twice yearly: run an access-review and key-rotation exercise.
- Annually: regional failover and full data restore drill.
- After every real incident: update the runbook with observed timings.
- Keep evidence of each drill for auditors and customers.
Honest comparison
| Capability | Plugsky | Hyperscaler AI platform | Building in-house |
|---|---|---|---|
| Model failover | Automatic upstream failover documented | Service-dependent redundancy | You build routing logic |
| Region failover | Multiple region-locked planes | Broad region matrix with pairs | Your own secondary site |
| Residency-aware DR | Region selection at workspace level | Complex cross-border defaults | Your design |
| Key availability | BYOK with KMS or HSM | Cloud KMS in-region options | You operate key infrastructure |
| Drill support | Status page and audit evidence | Mature incident tooling | You create the process |
| Certifications | SOC 2 / ISO 27001 readiness in progress | Completed audits in many regions | Your own programme |
Frequently asked questions
What RTO should we target for AI workloads?
Set it per workload. Interactive assistants often need minutes, while batch and analytics workloads can tolerate hours. Capture agreed targets in the enterprise agreement and test against them.
Does Plugsky fail over automatically?
Yes — automatic failover routing moves requests to alternate upstreams when a model fails, and component health is published on /status. Region-level failover behavior should be defined with your account team.
Can failover break data residency?
It can if the secondary region is in another jurisdiction. Define permitted failover targets up front and verify routing during drills.
How do we recover vectors and embeddings?
Treat vector stores like any database: back them up, define restore procedures, and test a rebuild from source documents as a fallback.
What happens if a model is retired?
Maintain a documented fallback chain of same-profile models and validate quality with your own evaluations before you need it.
Should we run on-prem for disaster recovery?
Some regulated teams use on-prem as a compliant secondary. Weigh cost and operational burden against the risk profile of each workload.
Where are uptime commitments documented?
The SLA at /legal/sla covers uptime and credits; /status shows live component health during incidents.