Develop low, run high

Working in a fully isolated environment can slow down development if the delivery model is not designed carefully. To reduce this risk, we apply the 'develop low, run high' principle. Teams build and test in an accessible sandbox environment. Only when an application is mature, validated, and ready for controlled deployment is it promoted through strict, automated pipelines to the highly secure air-gapped environment.

This approach reduces implementation risk by separating experimentation from controlled production operations. It allows teams to validate applications before they enter the air-gapped environment, making delivery more predictable, and lifecycle costs easier to manage.

The promotion process into the air gap is a key security control. Artifacts, images, libraries, configurations, documentation, and dependencies must be identified, scanned, approved, traceable, reproducible, and transferred through a controlled process. Each release must also include rollback procedures, approval records, compatibility evidence, and provenance information. Without this discipline, the air gap may block external access while still leaving internal software supply-chain risks.

This is especially relevant for AI workloads, where models often need to be built, trained, tested, and validated before they can be moved into a restricted production environment.

GDC AG is not for traditional IaaS

A common strategic pitfall is to view GDC Air-Gapped as a replacement landing zone for existing, traditional IT infrastructure. That is usually not where the value is.

GDC is an edge cloud platform built around containers, Kubernetes, and cloud self-service capabilities, designed to support data- and AI-driven workloads close to where sensitive data is created or processed.

The relevant selection criterion is not whether a workload can technically run on the platform. The question is whether the workload creates sufficient value to justify the cost and constraints of isolation.

These costs are justified only when the workload’s sensitivity, data gravity, latency requirements, mission-criticality, or regulatory context genuinely demands this degree of control. Selecting the right workloads upfront helps avoid unnecessary costs, complexity, and disappointment later.

Segregation of duties & process discipline

Within GDC AG, maintaining segregation of duties between operational roles is a strict requirement. The roles of Infrastructure Operator, Platform Administrator, and Application Operator must be clearly separated to prevent unintended access paths and to support auditability. This requires more than a technical design; it requires process discipline, clear ownership, and an operating model that can withstand time pressure.

The real test of segregation of duties takes place during an incident (not during a scheduled audit), when teams are under pressure to restore service and the temptation to bypass controls is greatest.

Emergency-access procedures, privileged identities, approval mechanisms, evidence trails, and break-glass scenarios must therefore be designed and rehearsed in advance. An operating model that depends on informal exceptions during a crisis is not genuinely secure, regardless of how carefully its roles have been documented.

This discipline also extends to engineering culture. In a disconnected environment, engineers cannot rely on internet searches, external forums, or ad-hoc vendor access during an incident. Procedures, runbooks, escalation paths, and documentation need to be available and maintained inside the air-gap. This reduces operational risk and makes incident response more predictable.

Day-2 Operations: updates & isolated monitoring

Getting the GDC platform live is only the beginning. The larger challenge is lifecycle management over a period of three to five years. Because updates cannot simply be pushed from the outside, organizations need controlled and repeatable routines to import patches, validate changes, and maintain the platform without compromising the air-gap.

In an airgapped environment, an update is a controlled software-supply-chain event. Each update may require acquisition, quarantine, malware scanning, integrity verification, compatibility testing, formal approval, controlled import, deployment validation, and a tested rollback path.

These procedures must cover not only the GDC platform, but also operating systems, firmware, Kubernetes components, container images, security signatures, application dependencies, AI models, and observability tooling. The overall operational burden can easily be underestimated during the initial business case.

Monitoring, logging, vulnerability management, backup, restore, and support processes all need to work without depending on external SaaS services or outbound telemetry. A successful deployment therefore requires an autonomous observability and operations model inside the air-gapped environment. These capabilities must be designed before implementation begins, rather than added after the platform has gone live.

Local domain expertise

When an air-gapped cloud environment needs to be secure and auditable, the requirements do not stop at the hardware or platform. Questions such as who manages the keys, who has physical access, who operates the environment, and how continuity is guaranteed become essential procurement and governance topics.

Itility is a fully Dutch privately owned organization with ISO 27001, ISO 9001, and ISAE 3402 Type II certifications. For air-gapped tracks, we work with local professionals on our own payroll. This supports continuity, background screening, and knowledge retention in environments where trust and operational stability are just as important as technical capability.

Focus on the long term

Implementing Google Distributed Cloud Air-Gapped is not a one-off IT project; it is the start of a long-term operating model. Across multiple GDC Air-Gapped implementations, we have seen that success depends on making the right choices early: which workloads belong in the air-gap, how responsibilities are split, and how the environment remains supportable over time.

The starting point should therefore not be the technology. It should be the business or risk requirement that makes isolation necessary. Organizations must determine what they are protecting against, which data and processes require isolation, which external dependencies must be eliminated, and whether they are prepared to operate the resulting environment autonomously.

If you are exploring air-gapped or sovereign edge cloud scenarios, Itility can help assess where this approach adds value, where it adds unnecessary complexity, and how to make the implementation manageable from day one.