When does AI need tighter control over where it runs?

For most early-stage products, public cloud is the right default. It is faster to launch, easier to test, and usually simpler to support. If the workload is still being shaped, public cloud reduces the number of things you have to solve at once.

Tighter control becomes relevant when the business problem changes. That happens when the data is especially sensitive, the customer or regulator expects clear boundaries, or the application has to keep operating in constrained environments. Google Cloud’s October 2026 announcements point to exactly those cases: organisations with stringent sovereignty requirements, defence or critical infrastructure needs, or disconnected environments that cannot rely on sending sensitive data to public cloud.

• Use public cloud first when speed, experimentation and simplicity matter most.
• Use hybrid when some systems need control but others benefit from shared cloud services.
• Use tighter or sovereign deployment when the boundary itself is part of the requirement, not an optional extra.

1. 1

   Data residency is a hard requirement

   If customer data, prompts, documents or embeddings must stay inside a specific jurisdiction or organisational perimeter, the deployment choice stops being a convenience issue. It becomes a design constraint.

2. 2

   The workload must keep running with limited connectivity

   Air-gapped or disconnected environments matter when the application cannot depend on constant internet access or external API calls. That changes how search, AI inference, logging and updates are delivered.

3. 3

   You need clearer operational boundaries

   Some teams want to separate sensitive systems from general-purpose cloud services. That may be for governance, security review, internal audit or simpler risk management.

4. 4

   Your AI decisions need local accountability

   If prompts, responses and supporting documents must stay under local control, the architecture should support that from the start rather than trying to retrofit it later.

This is a planning table, not a rulebook. The right answer depends on the workload, not on a trend.

The main mistake is choosing a more controlled architecture before the problem is clear. That can create extra cost, slower delivery and more complex support than the business actually needs. The opposite mistake is assuming public cloud automatically solves governance. It does not. If you put sensitive data into a loosely managed setup, you still own the risk.

Google’s sovereign and air-gapped positioning is useful because it shows control is an architectural choice, not a slogan. Its managed search and AI setup for air-gapped environments keeps prompts, responses, uploaded documents and embeddings inside the local perimeter, with local keys, local IAM and local model execution. That is powerful, but it is not the right answer for every team.

• Do not overbuild controls for a pilot that still needs to prove value.
• Do not assume ‘cloud-native’ means ‘safe by default’.
• Do not treat sovereignty as a substitute for good access control, logging and data minimisation.
• Do not forget the operational cost of patching, monitoring and recovery in more controlled environments.

1. 1

   Map the data and the decision boundary

   List the data types involved, where they originate, who can see them and whether any of them must remain inside a fixed legal or operational boundary.

2. 2

   Separate the workload into tiers

   Not every part of a system needs the same control. A public-facing website, internal dashboard and sensitive AI assistant may belong in different tiers.

3. 3

   Choose the least complex option that still meets the constraint

   If your requirement is “keep customer documents local”, you may not need to rebuild the whole platform. You may need one controlled service, not an entirely isolated estate.

4. 4

   Design for handover and recovery

   Whatever model you choose, document ownership, access, deployment steps and rollback paths. If the system must be taken over by another team later, that needs to be true on day one.

5. 5

   Review after real usage

   Usage patterns often show whether control is truly needed everywhere or only in one part of the workflow. Let evidence refine the architecture.

0 of 5 complete

Specialist support is helpful when the architecture question affects more than one team, or when the wrong decision could be expensive to unwind later. That is often true for AI assistants, document workflows, system migrations and products that need both public-facing speed and tighter internal controls.

For organisations that need to modernise cloud architecture, define boundaries, or plan a migration with control in mind, this is where a structured design review is useful. The goal is not to push everything into a more complex setup. It is to avoid making a short-term choice that becomes a long-term constraint.