Google’s Tokyo data-agent endpoint keeps ML processing in-region—but not every data path

Google has added a Tokyo regional endpoint to the Conversational Analytics API for agents that query BigQuery. The November 5 release note says asia-northeast1 now supports both data residency for data at rest and jurisdictional machine-learning processing for data in use.

For Japanese organizations that could not treat a global endpoint as an acceptable control boundary, this is a meaningful deployment change. It is not, however, a promise that every byte involved in an analytical conversation stays in Tokyo.

What the regional promise covers

Google’s data-residency documentation says the commitment applies to DataAgent resources—including configuration, context, system instructions and example queries—and to Conversation resources, including messages and conversation state.

For BigQuery-backed agents, the Tokyo endpoint covers those resources at rest and commits Google to performing machine-learning processing of customer data in the selected jurisdiction. Teams must call the regional hostname and use the matching asia-northeast1 location in request paths. A global endpoint does not provide these residency commitments.

The dataset location is a separate decision

The regional API endpoint does not move or pin the underlying BigQuery dataset. Google explicitly says an agent using the Tokyo endpoint can connect to datasets in any region or combination of regions. That flexibility is useful, but it means architects must validate two boundaries independently: where the agent and conversation resources live, and where BigQuery stores and executes against the source data.

The commitment also excludes service data such as resource identifiers and labels, and it does not cover data in transit. Google describes the in-use promise specifically as jurisdictional ML processing, not comprehensive residency for every state of data in use.

BigQuery and Looker do not have the same matrix

The Tokyo addition applies to BigQuery data sources. Google’s current table lists no Tokyo endpoint for Looker-backed agents, and its Looker residency commitments cover data at rest rather than jurisdictional ML processing in use.

That makes the practical rollout checklist short but important: select the regional endpoint deliberately, match the request location, confirm dataset placement separately, align any CMEK key with the endpoint region, and document the exclusions. The new endpoint closes a real jurisdictional gap for BigQuery conversational analytics. It does not collapse the agent, model, network and warehouse into one residency boundary.