On this page · 11 sections
- What Google actually announced, in its own words
- What the regulations actually say
- The three-way comparison
- The controls that do the work on the managed path
- What to verify before signing either contract
- A decision path
- The security features announced alongside it
- India-specific considerations
- FAQ
- How eCorpIT can help
- References
Summary. At Google I/O Connect India on 14 July 2026, Google made Gemini available inside Indian data centres in two quite different shapes. The first runs Gemini on Google Distributed Cloud with, in Google's words, "prompts, model weights or outputs" never leaving the customer perimeter, and with "all supporting services" running "fully disconnected from the public internet" behind what Google calls a "physical airlock". The second makes Gemini 3.5 Flash available through the Gemini Enterprise Agent Platform and the Gemini Enterprise app with in-country machine-learning processing commitments — a regional cloud service, generally available for India with an allowlist since 30 June 2026, not a disconnected installation. These are not two tiers of the same product. They differ on cost, on model freshness, on operational burden, and on what they actually prove to a regulator. The Reserve Bank of India's directive on storage of payment system data (RBI/2017-18/153, DPSS.CO.OD No.2785/06.08.005/2017-2018) requires that "the entire data relating to payment systems operated by them are stored in a system only in India" — and the RBI's own clarification adds that "There is no bar on processing of payment transactions outside India if so desired by the PSOs. However, the data shall be stored only in India after the processing." India's Digital Personal Data Protection Rules were notified on 14 November 2025 with obligations on a phased schedule. Neither instrument requires an air gap for most workloads. Air-gapped Gemini solves a real problem for a narrow set of organisations. For everyone else it is a large bill for a control nobody asked for.
The published prices show the gap in what you can even evaluate. Gemini 3.5 Flash lists at $1.50 per 1M input tokens and $9.00 per 1M output tokens on the standard tier, halving to $0.75 and $4.50 on batch. Google has published no India pricing for the air-gapped Distributed Cloud deployment at all.
What Google actually announced, in its own words
The distinction is easy to blur because both announcements arrived on the same day. Google's India blog post separates them clearly.
On the air-gapped option: "Indian enterprises including regulated industries and the public sector can now run Gemini on Google Distributed Cloud from within Indian data centres. This allows enterprises and public sector organisations to deploy advanced generative AI without prompts, model weights or outputs leaving their perimeter… All supporting services will run fully disconnected from the public internet, providing a 'physical airlock' that will mitigate the risk of external data breaches."
On the managed option: "We also expanded our commitment to India's digital sovereignty by making Gemini 3.5 Flash available to Indian enterprises and startups via the Gemini Enterprise Agent Platform and the Gemini Enterprise app… this model will be available with strict in-country machine learning processing commitments."
TechRepublic's 21 July 2026 write-up is worth reading alongside it for two clarifications Google's post does not make. First, air-gapped Gemini is not new — Google made it generally available in August 2025, and "the July 2026 announcement extends the deployment option to Indian data centers." Second, and more usefully: the Gemini Enterprise path "is a regional cloud service, not the disconnected Google Distributed Cloud installation." Same brand, different architecture, different assurance.
What the regulations actually say
This is where most vendor comparisons stop being useful, because they conflate three separate things: data residency, processing location, and network isolation. Indian law treats them differently.
RBI, payment system data. The 2018 directive is specific and narrow. It applies to payment system operators, banks, non-bank prepaid instrument issuers and card networks, and it covers "Customer data (Name, Mobile Number, email, Aadhaar Number, PAN number, etc. as applicable); Payment sensitive data (customer and beneficiary account details); Payment Credentials (OTP, PIN, Passwords, etc.); and, Transaction data". The requirement is storage: that data must live in a system in India. The RBI's clarification explicitly permits offshore processing so long as the data is stored only in India afterwards. There is no isolation requirement in the text, and there is no requirement that the machine doing the inference be disconnected from the internet.
What the RBI does emphasise, in the same directive, is supervisory reach: "it is important to have unfettered supervisory access to data stored with these system providers as also with their service providers / intermediaries / third party vendors and other entities in the payment ecosystem." Read that carefully. The regulator's stated concern is access and auditability, not air gaps. An architecture that gives your supervisor clean audit access matters more than one that unplugs the network cable.
DPDP. India notified the Digital Personal Data Protection Rules on 14 November 2025, with major obligations taking effect on a phased schedule. DPDP obligations attach to consent, purpose limitation, retention, deletion, breach notification and the rights of data principals. Local hosting does not settle any of those. As TechRepublic puts it, "Local hosting does not settle requirements for consent, access, retention, deletion, or incident response." A team that buys an air gap and does not build a deletion pipeline has spent money on the wrong problem.
The practical conclusion for most organisations: your obligation is to know where the data rests, to control who can reach it, to prove both, and to be able to delete it. Isolation is one way to achieve some of that. It is rarely the cheapest.
The three-way comparison
| Dimension | Air-gapped Gemini on Google Distributed Cloud | In-country Gemini Enterprise (regional cloud) | Global multi-region Gemini API |
|---|---|---|---|
| Where prompts, weights and outputs sit | Inside the customer perimeter; Google states none of them leave it | In Google Cloud India regions, with in-country machine-learning processing commitments | Wherever the API routes, subject to your configuration |
| Network posture | Supporting services run fully disconnected from the public internet, with a controlled "physical airlock" transfer process | Connected regional cloud service; perimeter enforced with VPC Service Controls and IAM | Connected; residency controls only where offered |
| Model freshness | Updates arrive through the controlled transfer process, on your schedule | Google-managed; Gemini 3.5 Flash available for India on an allowlist since 30 June 2026 | Newest models first |
| Published pricing | None published for India as of August 2026 | Gemini 3.5 Flash at $1.50 / $9.00 per 1M tokens standard, $0.75 / $4.50 batch | Same public list pricing |
| Operational burden | Highest: hardware, update approvals, key custody, physical process | Moderate: cloud configuration, org policy constraints, key management | Lowest |
| Audit position | Strongest isolation story; independent assessments for India not yet detailed publicly | Google contractually grants audit, access and information rights to regulated entities and their supervisors; PCI DSS third-party audited at least annually; GCP empanelled by MeitY | Weakest for regulated payment data |
| Fits | Classified government workloads, defence-adjacent, organisations with an explicit no-internet mandate | Most BFSI, healthcare and public-sector generative AI work | Non-regulated workloads and internal tooling |
Two rows deserve expansion.
The pricing row is not a gap in this article — it is a gap in the market. TechRepublic's conclusion is blunt and correct: "Until Google details India-specific pricing, hardware, independent assessments, and production deployments, buyers cannot fully compare the offering's cost, controls, or operational maturity." If you are being asked to approve an air-gapped deployment, that sentence is your negotiating position. Ask for the number, the hardware bill of materials, and the name of an independent assessor before the architecture review, not after.
The audit row is where the managed path is stronger than teams expect. Google's own RBI data-localization whitepaper states that customers can configure services to store payment data in Mumbai (asia-south1) or Delhi (asia-south2), that "Google grants audit, access and information rights to regulated entities, their supervisory authorities and both their appointees", and that Google Cloud "aligns to RBI Guidelines on Managing Risks and Code of Conduct in Outsourcing of Financial Services by Banks". That is a documented, contractual answer to the RBI's supervisory-access concern. The air-gapped option's India-specific equivalent has not been published.
The controls that do the work on the managed path
If you take the in-country route, the residency claim is only as good as the configuration. Four controls from Google's own documentation carry most of the weight.
Organization Policy resource-location constraints limit where a new resource may be created, applied at organization, folder or project level. This is what stops an engineer in a hurry from spinning up a bucket in us-central1.
VPC Service Controls define a service perimeter — "the virtual boundaries from which a service can be accessed, preventing data from being moved outside those boundaries." Google positions this as context-based perimeter security that works independently of IAM and mitigates exfiltration through misconfigured access or compromised accounts. For a generative AI workload, this is the control that stops prompts and outputs leaving the perimeter, and it is the closest managed-cloud analogue to what the air gap achieves physically.
Cloud KMS customer-managed keys. Data at rest is encrypted with Google-managed keys by default; regulated entities handling financial information can hold their own keys instead. Whoever holds the key is a question your regulator will ask, and "Google" is a weaker answer than "we do".
IAM with fine-grained policies, which Google notes helps "prevent your employees from accidentally storing customer data in the wrong Google Cloud region."
None of these are new, and that is the point. A well-configured regional deployment is a known quantity with contractual audit rights, published pricing and years of third-party assessment behind it. An air gap is a stronger physical story with, for India specifically, less published evidence attached to it so far.
What to verify before signing either contract
TechRepublic's checklist for the air-gapped option is the right one and it applies, with adjustments, to both. Buyers "must still verify privileged access, encryption-key control, software-update procedures, and proof that data remains inside the approved environment."
| Question | Why it matters | What good looks like |
|---|---|---|
| Who holds the encryption keys, and can the vendor decrypt without you? | Determines whether residency is a technical control or a promise | Customer-managed keys with documented custody and rotation |
| Who has privileged access during a support incident? | Support access is the usual hole in an isolation story | Named roles, break-glass logged and reviewable, contractual limits |
| How do software and model updates enter the environment? | The transfer process is the only path in; it is also the only attack path in | Authenticated packages, staged testing, approval controls, rollback, change records |
| What evidence proves data stayed inside? | This is what your auditor will ask for | Network isolation evidence, in-country processing attestations, administrator access logs, retention and deletion records |
| What are the audit and supervisory access rights? | The RBI's stated concern is unfettered supervisory access | Contractual rights extending to the regulator and its appointees |
| What is the India price, and what hardware does it assume? | Not published for the air-gapped option as of August 2026 | A written quote with the hardware bill of materials |
| Which model versions, and on what update cadence? | Isolation costs you model freshness | A named model, a stated update path, and who decides when to take one |
The update question is the one teams under-weight. An air-gapped environment is, by construction, a place where new models arrive late and only when someone approves the transfer. If your use case depends on being current — coding assistance, agentic workflows, anything where capability moves quarterly — you are trading capability for isolation. That trade is correct for some workloads and wrong for most.
A decision path
Work through these in order. Stop at the first one that gives you a clear answer.
Do you have an explicit written mandate, from a regulator, a ministry or a customer contract, that the processing environment must be disconnected from the public internet? If yes, air-gapped Distributed Cloud is your candidate and the rest of this article is a checklist for buying it well. If no, keep going — because in our reading, RBI's payment-data directive and the DPDP Rules do not create that mandate.
Is the data in scope payment system data as the RBI defines it? If yes, your requirement is storage in India, and the RBI's clarification is explicit that processing may occur abroad provided storage afterwards is in India only. A configured India-region deployment with resource-location constraints and VPC Service Controls addresses that, with contractual audit rights on top.
Is the sensitivity in the data or in the inference? A model that summarises customer complaints is a different risk from a model that sees full payment credentials. If you can keep the regulated fields out of the prompt entirely — tokenise, redact, or retrieve by reference — you may find the residency question shrinks to something the managed path handles comfortably.
Can you carry the operational burden? An air-gapped platform is hardware, physical process, key custody, an update approval workflow and the staff to run all of it. Organisations that already operate isolated environments will absorb this. Organisations that have run entirely on managed cloud for a decade usually underestimate it by a factor of two.
The honest engineering judgement: most Indian BFSI and healthcare generative AI workloads are correctly served by the in-country managed path with the perimeter controls configured properly and the audit rights exercised. Air-gapped Gemini is the right answer for a genuinely narrow set of classified and critical-infrastructure workloads, and buying it for the others substitutes a purchase for a design.
The security features announced alongside it
Two other items from the same event affect this decision and are worth tracking rather than assuming.
CAPSEM is an open-source runtime designed to isolate AI agents inside virtual machines and keep raw credentials out of their reach. That addresses a real failure mode — agents granted human-level access without runtime monitoring — and it is relevant whether or not you air-gap.
Sec-Gemini v3 is being given to selected government and enterprise testers, Flipkart among them, for incident investigation, digital forensics and malware analysis. TechRepublic notes that these programmes "were announced separately and are not identified as standard components of every air-gapped deployment", which is the kind of distinction that gets lost between a launch blog and a procurement document.
Device Bound Session Credentials, aimed at making stolen session credentials harder to reuse on another device, remains a W3C First Public Working Draft rather than a finished standard. Plan accordingly.
India-specific considerations
Beyond the regulatory reading above, three practical points for teams in Gurugram, Mumbai, Bengaluru and Hyderabad.
Region choice is a decision, not a default. Google Cloud's India regions for payment data residency are Mumbai (asia-south1) and Delhi (asia-south2). Latency to end users, disaster-recovery pairing and the location of your existing data estate should all feed that choice, and the resource-location constraint should be set at the organisation level so it is not re-litigated per project.
Foreign banks and their Indian operations face the tightest version of the storage requirement, and the payment-data directive's scope covers service providers and third-party vendors in the payment ecosystem, not only the regulated entity itself. If your generative AI vendor touches payment data, the localisation question follows the data into their stack. Ask them the same seven questions in the table above.
For public-sector and government-adjacent work, MeitY empanelment matters procedurally, and Google Cloud states that GCP is empanelled by MeitY. That is a procurement fact worth confirming for the specific services in your architecture rather than for the platform in general.
FAQ
How eCorpIT can help
We help Indian BFSI, healthcare and public-sector teams answer this question with evidence rather than vendor framing: map the data actually entering the prompt, read the obligation against the specific directive that applies, and design the smallest architecture that satisfies it. eCorpIT is CMMI Level 5 and ISO 27001:2022 certified, we are a Google partner, and our senior engineering teams design deployments aligned with DPDP requirements. If an air-gapped proposal is on your desk and nobody has checked whether the regulation asks for it, talk to us.
Related reading: our data residency and DPDP cloud architecture service covers the design work behind this decision, the India sovereign AI and IndiaAI Mission analysis sets it in policy context, the DPDP engineering playbook is the pillar for this cluster, and the Gemini Enterprise governance and cost control guide covers running the managed path once you have chosen it.
References
Last updated: 5 August 2026.
