A hybrid cloud strategy runs some workloads on public cloud infrastructure and keeps others on private or on-premise systems, based on where data is allowed to live and how it needs to be handled. This article covers the four decisions that shape a privacy-first hybrid design, what secure hybrid cloud looks like in practice, and three deployment shapes we build for European organisations. It is written for technology leaders whose AI ambitions have collided with data residency requirements.
Every European organisation we work with wants the same two things at once: the capability of frontier AI models, and certainty about where their data physically sits. Public cloud alone rarely delivers both. Neither does a fully private estate, which struggles to keep pace with model releases and costs a great deal to run.
A hybrid cloud strategy is how those two requirements get reconciled. Done carelessly it produces two disconnected estates and twice the operational burden. Done well it puts each workload where its data constraints allow, with one operating model across both.
What is a hybrid cloud strategy?
A hybrid cloud strategy is a deliberate allocation of workloads between public cloud, private cloud and on-premise infrastructure, governed by a single set of rules for identity, data movement and observability. The strategy part sits in the rules rather than the mix of infrastructure.
This gets confused with enterprise cloud computing more broadly, which describes any use of cloud services at organisational scale. Hybrid is a specific architecture within that. Multi-cloud is a third thing again, describing the use of several public cloud providers, usually for resilience or commercial leverage rather than for privacy.
For AI workloads the distinction matters, because inference is where the sensitive data actually travels. A model hosted in a region you approve of, processing prompts assembled from records you cannot legally export, is still a data transfer problem.
Four decisions that shape a privacy-first design
Four decisions determine whether a hybrid design holds up under scrutiny, and they need answering in this order.
1. Data residency. Establish which categories of data can leave your jurisdiction and which cannot, before any architecture is drawn. Health records, legal documents, employee data and customer identifiers usually carry the tightest constraints. The EDPB guidance on international transfers is the reference point for what counts as a transfer.
2. Inference location. Decide where the model runs for each use case. The options are a public API, a model hosted in your own cloud tenancy, a model running in your data centre, or a model running on the device itself. Each moves the privacy boundary to a different place.
3. Identity and access. Use one identity provider across both estates. Two access models is how privacy-first designs quietly fail, because the private side inherits permissions nobody has reviewed since it was set up.
4. Observability. Instrument both sides with the same signals. If you cannot answer which data a given inference touched, the compliance position of the architecture is theoretical. The EU AI Act makes record-keeping a requirement for many higher-risk applications.
Secure hybrid cloud in practice
A secure hybrid cloud has three properties: encryption that you hold the keys to, network boundaries that fail closed, and audit trails that span both estates.
Key ownership is the one that gets negotiated away most often. If your provider can decrypt your data to service it, the residency guarantee is weaker than the diagram suggests. Customer-managed keys, held in your own infrastructure, change that position materially.
Network boundaries should default to denying egress. Private workloads that can reach the public internet by default will eventually do so, usually through a library update or a monitoring agent nobody scoped.
Audit trails are the third property and the one that takes longest to retrofit. A hybrid estate typically ends up with two logging regimes, one inherited from the cloud provider and one built in-house, which makes any question spanning both expensive to answer. We instrument both sides against the same schema from the start, so a single query can trace which records a given inference touched, which identity requested it and which estate processed it. Regulators, auditors and your own incident response team all ask versions of that question.
Enterprise cloud examples: three deployment shapes
Three shapes cover the large majority of privacy-first AI deployments we build, and the right one depends on how tightly the data is constrained.
| Deployment shape | Where inference runs | Data residency | Latency | Relative cost | Best fit |
|---|---|---|---|---|---|
| Public cloud with regional pinning | Provider region you select | Region-bound, provider-controlled | Low | Lowest | General workloads, no special category data |
| Private model in own tenancy | Your cloud account or data centre | Fully controlled | Low to medium | Medium to high | Regulated sectors, sensitive internal data |
| On-device or edge inference | Local hardware, no network required | Never leaves the device | Very low | Low per unit, higher to build | Disconnected environments, highest sensitivity |
The third shape sounds theoretical until you build one. We built the first offline AI prototype for Crisis Cognition, an assistant for crisis response teams working where connectivity is unreliable or absent.
The system runs entirely on Orange Pi 5 Max hardware, using the RK3588 processor and its integrated NPU for local inference. We ran Qwen2.5-3B-Instruct through the rkllm runtime, which we extended in our own repository, on Armbian OS. The device acts as its own Wi-Fi access point, and a captive portal sends any connected phone or laptop straight to an Open WebUI interface we adapted.
The prototype confirmed four things: language models run reliably on that NPU, offline inference is viable in crisis environments, a self-contained assistant can operate with no cloud services at all, and responses stay fast enough to be useful within those hardware limits. For any organisation weighing whether privacy-first AI means accepting weaker capability, that result is worth sitting with.
Key takeaways
- A hybrid cloud strategy allocates workloads between public, private and on-premise infrastructure according to data residency rules, governed by one operating model.
- Inference location is the decision that determines where sensitive data actually travels, and it should be made per use case rather than once for the whole estate.
- Customer-managed encryption keys and egress that fails closed are what turn a hybrid diagram into a secure hybrid cloud.
- One identity provider across both estates prevents the permission drift that undermines most privacy-first designs.
- On-device inference is a real option: our Crisis Cognition prototype runs a language model on low-power hardware with no cloud dependency at all.
Working out where your data is allowed to live?
We help European organisations design hybrid architectures that satisfy their residency requirements without giving up AI capability. If you are mapping that trade-off now, speak to our enterprise technology team.
