What should teams do when AI systems operate across the EU and the US at the same time?

How to govern one AI programme across both jurisdictions

The practical move is to run a single control baseline and then layer jurisdiction-specific requirements on top, rather than building separate AI governance tracks for every market. That keeps policy, approvals, evidence collection, and monitoring consistent while still letting legal and compliance teams map local obligations where they differ.

For teams handling deployment, procurement, or model oversight, the important question is not whether the US and EU rules are identical. It is whether the organisation can prove the same underlying controls, ownership, and audit trail across both environments, with local add-ons only where law or contract demands them.

What the baseline should actually cover

A workable baseline usually includes the core controls that are common to most serious AI governance programmes: documented risk ownership, intended-use boundaries, human oversight, logging, access control to models and data, incident escalation, vendor review, and periodic re-assessment. If those controls are missing, local mapping becomes a paperwork exercise instead of a defensible operating model.

For cross-border AI use, the baseline should be written so that the same system can satisfy multiple regimes without being rewritten from scratch each time a new rule appears. That means separating what is globally mandatory from what is jurisdiction-specific, and keeping the evidence chain stable enough that one review can support multiple filings, audits, or internal attestations.

Where teams already maintain an AI management system, the Agentic AI Compliance Guide is useful because it shows how to anchor governance evidence, oversight, and regulatory mapping in one programme rather than treating each regulation as a separate operating model. For broader identity and governance questions, Ultimate Guide to NHIs, Regulatory and Audit Perspectives can help teams think through audit trails, access governance, and review obligations when AI systems act through non-human credentials or service relationships.

How to map local obligations without duplicating work

The cleanest method is to maintain a control register that tags each requirement by jurisdiction, business unit, and system type. That lets one control, such as retention of evaluation records or access review for production tooling, satisfy several obligations at once when the evidence is the same. It also makes it easier to spot where a single control is being used to cover requirements that actually need different treatment.

This is where legal mapping needs to stay connected to operational reality. If the EU rule asks for one type of documentation and the US state rule asks for another, teams should not create two separate workflows if one workflow can emit both outputs from the same source evidence. The control owner should own the process, while counsel confirms whether the mapped evidence really answers each rule.

For general control structure, ISO/IEC 27001 is often the management-system lens teams use to keep obligations organised, while NIST AI Risk Management Framework helps translate AI-specific risk into repeatable governance actions. If the system touches regulated data or cross-border processing, the GDPR remains a useful reference point for data governance and security controls.

Why cross-border AI programmes fail in practice

The most common failure is treating jurisdiction mapping as a one-time legal exercise instead of an operational control. When the programme changes model, vendor, data source, or deployment region, the mapped obligation can silently drift out of date. Another common failure is overfitting to the strictest rule and then not recording which local obligations were intentionally absorbed, which creates ambiguity during audit or incident review.

Teams also get into trouble when they rely on policy statements without testing whether the organisation can actually produce the evidence. A regulator or customer review usually cares less about the wording of the policy than about the repeatability of logging, approval, retention, exception handling, and escalation. That is why the control baseline should be built around observable evidence, not just principles.

For a cross-border programme, the underlying failure mechanism is usually control fragmentation: separate owners, separate inventories, and separate exception paths create inconsistent answers across regions. The impact is duplicated effort, slower approvals, and a weaker assurance story when a system is used in both the EU and the US.

Practitioner Guidance

What to prioritise: Build one global AI governance baseline first, then maintain a jurisdiction mapping layer that points local obligations back to the same control set. That is the best way to avoid duplicate reviews and inconsistent evidence.

What to verify: Confirm that every cross-border AI system has a named control owner, a current inventory entry, and a clear record of which evidence artefacts satisfy which jurisdictional requirements. If you cannot trace that chain quickly, the programme is not yet operationally stable.

Decision rule: If a control can satisfy both EU and US requirements with the same evidence, reuse it; if the evidence diverges, split the workflow only at the point of divergence, not at the start of the process.

Practitioner takeaway: The goal is not to make every rule look the same, but to make the governance machine stable enough that one control baseline can absorb local variation without losing auditability.

Related resources from NHI Mgmt Group

• How should security teams make NHI best practices usable across the business?
• How should security teams handle risks from AI browser extensions?
• How should security teams govern API keys used for generative AI access?
• How should security teams govern privileged access across service accounts and AI-driven systems?