Gemini 3.5 Flash Has Left One Surface. Record the Address.

Google has made a narrow change with a broad control lesson. Gemini 3.5 Flash was removed from the global region in the Gemini Enterprise app on 4 August 2026, under a notice published on 21 July. That was never an announcement that every Gemini 3.5 Flash endpoint, region or workflow would stop working (Google Cloud release notes).

Google's separate Gemini API deprecation table still lists gemini-3.5-flash with no shutdown date announced (Google AI for Developers). That status is not a promise of permanent availability. It proves something more useful: product surface and region belong in your lifecycle record.

If your register says only “Google, Gemini 3.5 Flash”, it cannot tell you which workflow was inside the 4 August notice. The controlled object is the deployment address, not the model name. We have made the register case before, in every model you rely on has a retirement date; this change adds the layer a date alone cannot carry, because here the same model name is retired on one surface and undated on another.

What actually changed on 4 August?

Google published the removal notice on 21 July. It names the Gemini Enterprise app, the global region and Gemini 3.5 Flash. The same release note says Gemini 3.6 Flash became available in global, but administrators must turn on its feature toggle. Google does not say in that notice that 3.6 is an automatic replacement, that existing work would migrate without intervention or what the post-removal default is (Google Cloud release notes).

That distinction matters. A plausible successor is not a confirmed migration path. This is a different event from the one we covered in our earlier look at Gemini 3.5 Flash as an agent default: that was about where the model was switched on, this is about where it has been switched off.

Current web-app documentation says users can select models when the model selector is enabled. It describes generally available models such as Gemini 3.5 Flash as models an administrator cannot turn off, while Gemini 3.6 Flash in global requires the administrator to turn its toggle on (Google Cloud feature controls). Those instructions describe the documented configuration before the removal took effect. They do not answer every tenant-specific question about 4 August.

The word global also needs discipline. It is a product location code, not shorthand for every country, region and Google service. Google's current location page separately lists US and EU multi-regions and in-country locations in Canada, India, Japan, Singapore and the United Kingdom. It does not list an Australian in-country region (Google Cloud locations). Your user's desk location does not establish the configured product location.

Build a Retirement Scope Fence around the notice:

1. Confirmed affected: Gemini Enterprise app, global, Gemini 3.5 Flash, effective 4 August 2026.
2. Not named by the notice: the Gemini API, other Gemini Enterprise regions and any workflow whose model is selected through a different product surface.
3. Unknown: the replacement, new default, treatment of existing sessions and tenant-specific transition behaviour unless your contract or account team confirms it.
4. Evidence: the source URL, capture date, notice date and exact effective date.
5. Owner: the person responsible for resolving each unknown and approving the response.

“Not named” does not mean “unaffected”. It means the source does not establish an effect. That negative-scope evidence stops a narrow notice from becoming an organisation-wide migration based on assumption.

Why is the model name not enough?

The same displayed name can appear in a managed workplace app and an API catalogue without proving that both surfaces share an endpoint, release policy or retirement date. Google publishes a stable Gemini API identifier, gemini-3.5-flash, with a 19 May 2026 release date and no shutdown date announced. The Enterprise notice uses the displayed model name and does not publish an API identifier for the affected app surface (Google API deprecations).

One name, two surfaces, two lifecycle states:

Replace the model-name field with a Model Address:

[VENDOR] / [PRODUCTANDEDITION] / [TENANTORPROJECT] / [INTERFACE] / [REGION] / [MODELIDORLABEL] / [SELECTIONMETHOD]

Selection method matters. A pinned API ID, vendor alias, automatic selector, user choice and administrator toggle can each change on a different clock. If the vendor notice does not identify the mechanism, record VENDORCONFIRMATIONREQUIRED, an owner and a due date. Unknown is a governed value. A blank field is merely easy to ignore.

Use this prompt to turn a release notice into a bounded change record. A product owner must verify every field against the live tenant, and a risk specialist must review any regulatory interpretation.

Normalise [VENDOR_NOTICE] into one row per product, interface and region.

Return:
- vendor, product and edition
- tenant or project
- interface and region
- displayed model name
- exact model ID, only if expressly stated
- selection method: pinned ID, alias, automatic, user selection or admin toggle
- announcement date and effective date
- confirmed lifecycle event
- replacement or new default, only if expressly stated
- coordinates named by the notice
- coordinates not named by the notice
- unknowns requiring vendor confirmation
- human owner, evidence source and next action

Do not infer that matching names mean matching endpoints.
Do not convert “no shutdown date announced” into “no shutdown planned”.

Now consider a fictional insurer. [WORKFLOWA] is a staff knowledge assistant in the Gemini Enterprise app, configured in global and displaying Gemini 3.5 Flash. [WORKFLOWB] assists a claims officer to draft correspondence through an API integration pinned to gemini-3.5-flash. The claims officer reviews every draft and remains responsible for the correspondence.

The 21 July notice places [WORKFLOWA] inside the confirmed scope coordinates. It does not establish an API shutdown for [WORKFLOWB]. The insurer opens one urgent transition ticket for the first workflow and one monitoring item for the second. Both retain their own evidence, test deadline and human owner. This is a fictional worked example, not a statement about any insurer's deployment.

What does this mean for Australian financial-services teams?

Start with use-case impact, not vendor chronology. A model removal may be minor for an optional drafting aid and material for a heavily used workflow supporting customer enquiries, claims processing, risk reporting or operational knowledge. AI should continue to assist the professional. A person must review the work and make any decision reserved for them by law, duty or organisational policy.

For APRA-regulated entities, the current CPS 230 determination has been in force since 1 July 2026, a clock we tracked in CPS 230's AI vendor contract deadline. It covers technology, data and change-management risk, effective controls, monitoring and service-provider risk. It also requires an entity to assess operational impacts and interdependencies in its own context (APRA CPS 230). A Google notice does not decide materiality for you, and a Model Address does not prove compliance.

CPS 234 separately makes the lifecycle stage of an information asset, and the materiality and frequency of change, relevant to information-security controls and testing (APRA CPS 234). The practical implication is proportionate evidence. Identify which information assets and workflows use the affected address, test the proposed change and preserve the human approval.

Do not collapse the migration into “old model versus new model”. Compare the whole deployment coordinate. A move from Gemini 3.5 Flash in one region to Gemini 3.6 Flash through another route may alter model behaviour, feature availability and data-location commitments, the same coupling of routing and data we examined in model routing moves your data. Google's location documentation says most non-US regional use of Gemini 3.6 Flash routes to global, subject to stated limitations, while US multi-region access is allowlisted (Google Cloud locations). Verify the exact route before approving it.

Use this prompt to prepare a surface-aware test pack. A human workflow owner must approve the test scope, inspect the evidence and make the go, hold or escalate decision.

Compare [CURRENT_CONFIGURATION] with [PROPOSED_CONFIGURATION] for [WORKFLOW_NAME].

Identify:
1. every change in product, interface, region, selector and model ID
2. the earliest confirmed vendor action date
3. any replacement, default or data route not expressly confirmed
4. controlled work samples for side-by-side testing
5. differences in accuracy, citations, refusals, structured output, tool use, latency and records
6. rollback conditions and evidence gaps

Return a draft go, hold or escalate recommendation with reasons.
Do not make the final deployment decision.
Use synthetic or de-identified test data only.

The testing is deliberately downstream of scope resolution. There is little value in running an expensive evaluation against a workflow the notice never covered, or testing only the model while missing a region or selection-method change.

Do this Monday

1. Search by address. Export AI use cases and add product, edition, interface, region, exact ID or label, selection method and human owner. Do not merge rows by model name.
2. Fence the notice. Record confirmed scope, coordinates not named, unresolved questions, evidence timestamp and the 4 August effective date.
3. Inspect the tenant. Confirm which Gemini Enterprise location, model selector and feature toggles are actually configured. Capture screenshots or configuration exports under your normal evidence process.
4. Ask narrow vendor questions. Request the post-removal default, handling of existing sessions and agents, regional scope, rollback options and any effect on data routing. Record the response source and date.
5. Test and approve. Run representative synthetic or de-identified work through the current and proposed addresses. Require a named human to accept the result, approve the transition and confirm the rollback trigger.

Bottom line

Gemini 3.5 Flash has now left one documented Enterprise app surface. The cited notice does not establish removal from every surface bearing its name. A model register that stores only vendor and model cannot resolve that notice. Record the deployment address, fence the notice's negative scope and treat unknowns as owned control states. Then let a human approve only the workflows and coordinates that the evidence actually reaches.

This article is general information and education only. It is not legal, compliance, financial or professional advice. Obligations vary by organisation and circumstance. Verify current requirements against the primary sources cited and seek advice specific to your situation.

References

1. Google Cloud, “Gemini Enterprise release notes”: https://docs.cloud.google.com/gemini/enterprise/docs/release-notes
2. Google Cloud, “Manage web app features”: https://docs.cloud.google.com/gemini/enterprise/docs/manage-web-app-features
3. Google Cloud, “Data residency for Gemini Enterprise Standard and Plus Editions and Gemini Notebook Enterprise”: https://docs.cloud.google.com/gemini/enterprise/docs/locations
4. Google AI for Developers, “Gemini deprecations”: https://ai.google.dev/gemini-api/docs/deprecations
5. APRA, “CPS 230 Operational Risk Management”: https://www.apra.gov.au/standards/cps-230
6. APRA, “CPS 234 Information Security”: https://www.apra.gov.au/standards/cps-234