Working across countries: what cross-border data really demands

The performance metrics for the new AI agent looked perfect. It could reason over user history to provide support, globally. The engineering team was ready to celebrate. But the project was one legal review away from a full stop.

This is the moment architects building modern AI systems now face. The challenge isn't just latency; it's jurisdiction. When an LLM agent needs to access data, the laws of physics are far more forgiving than the laws of nations. And that changes the architectural requirements completely.

The Real Constraint Is Jurisdiction, Not Code

Early in my career, the goal was to make geography irrelevant. A single, globally distributed database felt like the peak of elegant design. I was wrong. For any system handling personal data, geography is the one constraint that matters most, especially since landmark legal rulings tightened the rules on data transfers.

Events like the "Schrems II" judgment from the Court of Justice of the European Union effectively dismantled prior data-sharing agreements between the EU and US. As the European Data Protection Board (EDPB) guidance makes clear, this re-asserted the primacy of physical location in a digital world. Your architecture must honor these boundaries as if they were firewalls, because legally, they are. You can't just let an agent in a US-based cluster process the PII of a German citizen, even if it's just for a few seconds in memory.

Agentic Freedom vs. Deterministic Control

This legal reality creates a fundamental tension in modern systems. Deterministic automation, like a data pipeline that populates a dashboard, is relatively easy to secure. You can define its data access patterns, audit them, and prove that only aggregated, anonymized data ever crosses a border.

Agentic systems are different. An LLM-based agent, by its nature, has a more dynamic and less predictable access pattern. It might follow a chain of thought that requires pulling multiple, disparate pieces of user data. This freedom is powerful, but it's also a massive compliance risk. A "helpful" agent that pulls a user's full address and support history from a European database to answer a query from a support engineer in the US has just executed a regulated, and likely illegal, data transfer.

Standard role-based access control isn't enough. We need to enforce policy based on the data's origin jurisdiction, the processor's location, and the nature of the task. This requires building the legal constraints directly into the system's architecture.

The Cellular Pod: An Architecture for Compliance

The most durable pattern I've found is to deploy fully isolated, nearly identical stacks—or "pods"—in each legal jurisdiction. A pod in the EU has its own app servers, databases, and local agents. It serves European users and only stores and processes their data within that pod. This cellular architecture provides maximum isolation.

This approach contrasts with globally distributed databases that offer features like geo-partitioning. While elegant, that model places the entire compliance burden on the database configuration, which can be a single point of catastrophic failure. A misconfigured table or an unplanned query can easily violate the rules. The pod model enforces isolation at the network and infrastructure layer, which is harder to misconfigure. It's a boring pattern that works, a point echoed in guidance from major providers, like the AWS whitepaper on Architecting for Data Sovereignty, which favors physically separate regional deployments.

Federated Orchestration: A Global Brain with Local Hands

A cellular architecture doesn't mean you can't have a globally coherent agentic system. The key is to separate orchestration from execution. A central orchestrator can manage tasks globally, but it never touches raw, restricted data. The pattern works like this:

1. The central orchestrator receives a task, like "summarize user X's recent issues."
2. It identifies the user's home jurisdiction and dispatches the task to the appropriate regional pod's API. The payload contains the task instructions, not the user's data.
3. The pod's local agent executes the task entirely within the pod, using its direct access to the regional database.
4. The local agent generates a result—a summary, in this case—and passes it through a deterministic "policy filter" that strips any remaining PII before sending it back to the central orchestrator.

In this model, the global "brain" only ever sees sanitized, safe-to-transfer results. The "hands" that do the sensitive work remain strictly within their legal jurisdiction.

What This Actually Means for Builders

Designing agentic systems for a multi-jurisdiction world isn't about picking a specific LLM. It’s a shift in mindset. It’s about treating legal and geographical boundaries as first-class architectural constraints.

• Involve legal on day one. Don't present a finished architecture to your compliance team. Build it with them as you define how your agents will access and process data.
• Default to isolated pods. Start with fully separated regional stacks. It is far easier to build secure, policy-gated bridges between isolated cells than it is to chisel a monolith apart under regulatory pressure.
• Make jurisdiction a core data attribute. From the moment data is created, it should be tagged with its jurisdiction of origin. This metadata must drive all access control decisions.
• The agent doesn't fetch; it receives. Design your agentic workflows so that the local system passes context to the agent. The agent should operate on data it is given inside the pod, not be allowed to freely query across services and regions.

Getting this right isn't a feature; it is the foundation. It's the difference between a durable, global AI platform and one that's a single court ruling away from extinction.