Your customers are in six countries. Your agent is in one.

Asia Pacific has no single rulebook for where customer data may go. A business that sells across borders needs an agent it can run inside each country, not one central copy with a list of exceptions.

What happened

FutureCIO ran an interview with Shashir Shetty, who leads Google Cloud go-to-market for NTT DATA in Asia Pacific, on what it takes to scale agentic AI in the region. His main point is that APAC has no shared framework. Data residency law, AI governance and compliance rules change from one market to the next, and a company operating in five of them is answering to five sets of rules.

The numbers cited in the piece point the same way. 94% of APAC organisations say they are prioritising private or sovereign AI, 93% are considering moving AI infrastructure because of geopolitical and supply chain risk, and 96% name legacy infrastructure as a barrier. Shetty's conclusion is that scaling agents is mostly an operations problem. The model is the easy part.

Why this matters to your business

You don't need a head office in Singapore or Sydney for this to apply. If you have customers in more than one country, a support agent that answers them is moving personal data somewhere, and somebody will eventually ask where.

Follow one conversation. A customer in Jakarta asks about a delayed order, and the question goes to a model. To answer, the agent pulls the order record and the returns policy from a document store. Afterwards the transcript lands in a log, and maybe in a review queue for a person to check. That is four places the customer's data now sits, and with most hosted agent products all four are in whatever region the vendor picked.

This costs you in two ways. The slow one is procurement: an enterprise buyer in a regulated market sends a data residency questionnaire and the deal stalls while you work out the answer. Worse is a rollout that goes live in four markets and then has to be pulled from one because local rules want that data kept in-country. Rebuilding an agent under a deadline costs far more than planning for it up front.

Why this is a CX-Builder use case

The answer Shetty points to is private or sovereign deployment. For a customer-facing agent, the practical version is simple to state: design the agent once, and run a copy of it wherever the data has to stay.

CX-Builder is self-hosted. It runs on infrastructure you choose, so one instance can sit in a cloud region in Singapore, another in a data centre in Indonesia, and a third on your own servers at head office. Each copy carries the same agent design. What changes per country is where the documents, the vector store, the conversation logs and the human review queue live, and which model the agent calls. Where a market will not let customer data leave, that copy can use a model hosted in the country or an open-weight model on your own hardware.

Human-in-the-loop review stays local as well. The person approving a refund in Jakarta sees the transcript on a system in Jakarta, which is often the detail a compliance team asks about first.

What this looks like if you build it

A builder designs the agentflow once in one instance: retrieval over the policy documents, a lookup against the order system, an approval step for anything above a refund threshold. The flow exports as a file and imports into each regional instance. Every instance holds its own credentials, its own vector store loaded with that market's policies in the local language, and its own model endpoint. The logic stays identical across countries, and the parts that vary live in per-instance settings, so an improvement ships as one export instead of six hand edits.

The legacy systems Shetty mentions still matter here. Each copy needs a connector to that country's order or ticketing system, and that is usually where the real work sits.