Tomás Eberhardt was three coffees into a Thursday when the question arrived that would eat his next six weeks. He was a policy advisor in a bureau of the U.S. Department of State that ran a data-sharing platform with partner governments across Europe, and a program manager had emailed him one line: "Legal says the new analytics tool might make us a high-risk AI provider under the EU AI Act. Is that true, and what do we do?" Tomás had spent his career reconciling overlapping rules, but AI governance had become a special kind of headache. The same analytics tool was simultaneously subject to U.S. federal policy, the European Union's AI Act, a stack of OECD principles his own government had endorsed, and a UNESCO ethics recommendation that kept showing up in partner-country talking points. Four frameworks, one tool, no single rulebook.

This lesson is about that reconciliation problem. For a growing number of U.S. agencies, AI governance is no longer a purely domestic concern. The moment your data crosses a border, your vendor is global, or your mission touches an ally, foreign AI rules become operational requirements rather than foreign-policy trivia. We will pitch this at strategist altitude. The goal is not to make you a lawyer in five jurisdictions but to give you a way to see how the major frameworks line up, where they diverge, and how to satisfy them without building five different systems. The artifact is the tool Tomás built to answer his program manager: a cross-framework crosswalk.

Why International AI Governance Reaches U.S. Agencies

Tomás started by explaining to his bureau leadership why this was their problem and not someone else's. Four pressures pull international AI rules onto a U.S. agency's desk, and none of them require the agency to have any foreign-policy mission at all. They are properties of the system, not of the mandate. An agency that never intends to operate abroad can still acquire foreign obligations through the vendor it selects, the cloud region its data sits in, or the partner who asks to reuse its model.

• Data flows. If your system processes data about people in another jurisdiction, that jurisdiction's rules can attach to your system. Tomás's platform held data on individuals located in the EU, which is exactly what pulled the EU AI Act into scope.
• Global procurement. Agencies buy AI from vendors who also sell into Europe and Asia. Those vendors build to the strictest market they serve, and their contracts, documentation, and flow-down obligations carry foreign requirements into your agency by default.
• Treaty and alliance commitments. The U.S. has endorsed the OECD AI Principles and participates in the G7 process. Endorsements are not binding law, but they are commitments that partner governments expect the U.S. to honor in practice.
• Extraterritorial reach. The EU AI Act applies based on where the AI's effects land, not where the developer sits. A system built entirely in the United States can fall within scope if its output is used in the EU.

The stakes are concrete rather than reputational. International compliance affects whether your systems can operate in certain markets, whether your agency can partner with international governments or multilateral institutions, whether your technology can be imported or exported, whether your data-sharing agreements are legally valid, and whether your supply chain is secure. Getting this wrong can mean loss of partnerships, restricted market access, reputational damage, and security vulnerabilities. That is a fairly ordinary list of program risks, which is the point: this is program management, not diplomacy.

The takeaway Tomás gave his leadership was blunt. International AI governance is not about whether the United States agrees with another country's law. It is about which rules attach to your specific system because of where its data, its vendors, and its effects reach. Agreement is a policy question and it belongs to other people. Attachment is an engineering and contracting question, and it belongs to you.

A Fragmented Landscape, Not a Single Rulebook

The first thing Tomás had to unlearn was the expectation that somewhere there existed an authoritative global AI rulebook he had simply failed to read. There is not one. The landscape is fragmented: overlapping bilateral arrangements, multilateral frameworks, and technical standards, each issued by a different authority, each carrying different compliance weight. Some are binding law. Some are treaty commitments. Some are endorsed principles. Some are certifiable technical specifications. Treating them as one undifferentiated pile of requirements is the fastest way to over-engineer a system and still miss the obligation that actually binds you.

So the practical skill is triage. For any given system, you need to know which instruments create hard legal duties, which create diplomatic or political expectations, and which are simply good practice that you may adopt at your discretion. The rest of this lesson works through those categories in order, starting with the one that generates the most work for U.S. agencies.

The EU AI Act: Risk Tiers and What High-Risk Triggers

The European Union AI Act is the most consequential foreign instrument for U.S. agencies because it is binding, comprehensive, and extraterritorial. Unlike frameworks that describe good behavior, it regulates AI systems as products. It sorts them into four tiers by risk, and the tier determines the obligations. Tomás found that once he stopped reading the Act as a philosophy document and started reading it as a product-safety regime, its structure became predictable.

• Unacceptable or prohibited risk. Banned outright. This tier includes practices such as social scoring by public authorities and certain manipulative or indiscriminate biometric surveillance. These systems cannot be placed on the EU market at all.
• High risk. Permitted but heavily regulated. This tier covers AI used in areas such as critical infrastructure, education, employment, essential public services, law enforcement, and migration. This was the tier Tomás's analytics tool risked falling into.
• Limited risk. Mainly transparency duties. Systems that interact with people, such as chatbots, or that generate synthetic media must disclose that fact so a person knows they are dealing with AI.
• Minimal risk. The vast majority of AI. No specific obligations beyond voluntary good practice.

The whole game is the high-risk tier, because that is where the work lives. A high-risk classification triggers a defined set of obligations: a risk-management system across the lifecycle, data governance and quality controls, technical documentation, record-keeping and logging, transparency to users, human oversight, and accuracy, robustness, and cybersecurity. Tomás realized that almost every one of those obligations had a direct cousin in the frameworks his agency already followed. That insight is what made the crosswalk possible. He was not facing five unrelated rulebooks. He was facing one set of common controls described in five dialects.

Scope is the part agencies get wrong. The curriculum for this lesson states the trigger conditions broadly: treat a system as potentially in scope if it is deployed on EU cloud infrastructure, if it is accessible to EU citizens over the internet, or if it processes EU citizen data. Read that as a planning trigger rather than a legal conclusion. It is deliberately wider than the narrowest defensible reading, and that is the right posture for an inventory sweep, but the actual determination for any specific system belongs to your counsel, not to a checklist and not to this lesson.

Bilateral Arrangements: Allies, Alliances, and Restrictions

Most international AI governance currently happens bilaterally, between the United States and specific countries or regions, rather than through any global body. These arrangements matter operationally because they set the terms on which your agency can share data, buy technology, and run joint programs. Tomás mapped four families of them, and the families behave very differently from one another.

The U.S. and European Union are negotiating comprehensive AI governance frameworks. The current picture includes agreement on principles and values covering democratic governance, rights protection, and transparency; ongoing negotiation on technical standards harmonization; data-sharing arrangements that must account for both GDPR and U.S. requirements; and joint working groups on AI safety, security, and standards. For an agency, the implications are that partnering with EU agencies or operating in EU markets means satisfying both regimes, that data sharing must satisfy GDPR requirements, that contracts with EU partners must address regulatory conflicts explicitly, and that EU standards for data protection, transparency, and human oversight are more stringent than their U.S. counterparts.

NATO is establishing AI governance standards for member states. The curriculum names four strands: a NATO AI Strategy establishing principles for NATO AI use, a NATO Innovation Fund investing in AI startups and capabilities, an AI Ethics Group developing standards for responsible AI in defense, and standards for interoperability across allied systems. For agencies in Defense, State, Homeland Security, or elsewhere supporting NATO, these are not advisory. AI systems used in joint operations must meet NATO standards, supply chains for those systems must meet NATO security standards, and intelligence-sharing agreements have to account for governance differences among allies.

Ally bilaterals form a third family. The U.S. is negotiating bilateral AI governance agreements with key allies including Australia, Canada, Japan, South Korea, and the UK. These typically cover data-sharing frameworks, standards harmonization, joint research and development, interoperability protocols, and supply chain security. The practical consequences for a program office are that the bilateral agreement, not your preference, governs the terms of collaboration; that your systems must be compatible with allied systems; that data sharing must satisfy both sides; and that vendor selection may be constrained by what the agreement permits.

The fourth family inverts the logic. For nations treated as adversaries, the curriculum names China, Russia, Iran, and North Korea, and governance is focused on restriction and containment rather than harmonization: technology export restrictions, restrictions on data sharing and partnerships, supply chain security requirements, and monitoring requirements for systems that may be used against U.S. interests. The curriculum states the operational rules strictly. Any systems, data, or partnerships involving adversary nations require explicit approval. Supply chains must be vetted so that no critical component comes from a restricted source. Hiring international staff may be restricted for certain AI systems. Technology transfer to international partners requires licensing. Treat those as the strict default and get a determination from your security and counsel offices rather than reasoning your way to an exception.

Multilateral Principles: the UN and the OECD

Beyond bilaterals, several multilateral initiatives shape global AI governance without binding anyone directly. At the United Nations, the curriculum names a UN High-Level Panel on Artificial Intelligence that issued principles for AI respecting human rights, the UNESCO Recommendations on AI Ethics establishing principles for responsible AI, and guidance on AI and human rights from the Office of the High Commissioner for Human Rights. None of these are binding. All of them are influential, because major governments and companies are aligning their published policies to them, which means partner governments read your alignment as a signal.

The OECD AI Principles are the closest thing to a shared global baseline. Adopted in 2019 and endorsed by the United States and more than forty other governments, they are not binding, but they shaped nearly everything that came after. They cover AI benefit realization and inclusive growth, human-centered values and fairness, transparency and explainability, robustness, security and safety, and accountability. Because the U.S. endorsed them, partner governments treat OECD alignment as a reasonable expectation, and the NIST AI Risk Management Framework maps cleanly onto them. In practice this means your risk-assessment methodology and your public transparency statements should be able to answer the OECD principles point by point.

The G7 Process, UNESCO, and the Council of Europe

Sitting on top of the OECD baseline is the G7 Hiroshima Process, which produced international guiding principles and a voluntary code of conduct for organizations developing advanced AI. Tomás used the G7 code the way he used the OECD principles: as a source of shared vocabulary that let him talk to partner governments about the same controls without first arguing over whose law applied. When a Dutch counterpart said "human oversight," Tomás could point to the same concept in the EU AI Act, the OECD principles, and the NIST framework, and they could move on to substance rather than jurisdiction.

Two more instruments rounded out his map, and they are easy to confuse, so he kept them distinct. The UNESCO Recommendation on the Ethics of Artificial Intelligence, adopted in 2021, is a global ethics standard agreed by the broad UNESCO membership that centers human rights, human dignity, environmental sustainability, and proportionality. It is a values document rather than a compliance regime, but it carries weight in multilateral settings and in partner countries that adopted it into national policy.

The Council of Europe Framework Convention on Artificial Intelligence is different in kind. It is a treaty, the first binding international treaty on AI, focused on protecting human rights, democracy, and the rule of law across the AI lifecycle. The United States participated in negotiating it. For a strategist the distinction is the lesson: UNESCO sets ethical expectations, the Council of Europe Convention creates treaty-level legal commitments, and conflating the two leads either to overreacting to a recommendation or to underreacting to a treaty. Ask which one you are looking at before you decide how much it costs you.

Technical Standards and Where They Are Converging

Principles tell you what to aim at. Technical standards tell you what to build, and unlike principles they can be formally certified, which makes compliance verifiable rather than asserted. The most established of these for AI management systems is ISO/IEC 42001. The curriculum for this lesson also gestured at a wider family of ISO AI standards covering terminology, risk management, and lifecycle stages, but the specific numbers it gave for those did not survive checking and have been left out rather than repeated; if you need the exact catalogue, pull it from the standards body rather than from a course.

Certification does real work internationally. Systems designed to recognized standards integrate more easily with international partners, and certification gives partners something to inspect other than your assurances. It is worth being precise about what it proves, though. An AI management system certification attests that your organization runs a governed process. It does not certify that any particular model is accurate, fair, or safe, and a partner who reads it that way has misread it.

Harmonization is the other half of the story. ISO, NIST, and emerging government standards are converging on similar approaches to risk assessment methodologies, increasingly aligned with the NIST AI Risk Management Framework; to testing and evaluation protocols including red-teaming, fairness testing, and adversarial testing; to documentation requirements including system cards, impact assessments, and monitoring plans; and to transparency and disclosure mechanisms. Where standards converge, compliance gets simpler. Design to the converged core and you are more likely to satisfy several jurisdictions with one build.

Standards bodies solicit input from government stakeholders, and participation is worth budgeting for. U.S. influence in standards development shapes what becomes the global baseline, early participation means your agency's operational realities are considered while the text is still movable, and visible participation signals to international partners that your agency is engaged and responsible. If your agency has the resources, the concrete moves are to nominate experts to standards committees, to provide feedback on drafts during comment periods, to host working groups or subcommittees, and to fund research addressing open standards questions.

How These Interoperate With NIST and OMB Policy

Here is where Tomás's anxiety eased. He laid the foreign frameworks next to the U.S. instruments his agency already implemented, the NIST AI Risk Management Framework and OMB M-24-10, and found that they were not strangers. The framework's GOVERN, MAP, MEASURE, and MANAGE functions correspond closely to the EU AI Act's risk-management, documentation, and oversight duties, to the OECD principles, and to the UNESCO emphasis on accountability and human oversight. M-24-10's requirement for impact assessments on rights-impacting AI lines up with the EU's high-risk obligations closely enough that the underlying evidence is largely the same evidence.

This convergence is not accidental. These instruments were drafted by people reading each other's work. The strategic consequence is large but it needs stating carefully. An agency that has genuinely implemented the NIST framework and M-24-10 has already done much of the substantive control work the EU AI Act's high-risk tier demands. What it has not done is produce the conformity evidence in the form the EU expects, and it has not obtained any determination that it is compliant. The remaining work is usually documentation, mapping, and disclosure rather than a rebuild, and that is genuinely good news, but "we do NIST" is a starting position in a compliance conversation, not the end of one.

The Artifact: A Cross-Framework Control Crosswalk

This is the table Tomás built and the one his bureau now reuses for every cross-border system. The idea is simple and powerful: pick the controls that matter, then show how each framework expresses that single control. Once you see the same control across the columns, you stop managing five frameworks and start managing one set of controls that happens to answer to five frameworks. The crosswalk is also the artifact you hand to a partner government, a vendor, or a Congressional staffer who asks how U.S. practice compares to international practice.

When Tomás finished the crosswalk for his analytics tool, the answer to his program manager became concrete. The tool's likely high-risk classification under the EU AI Act demanded human oversight, documentation, and transparency. Those three controls already existed because the agency had implemented the NIST framework and M-24-10 impact assessments. Two gaps remained: the EU's specific user-disclosure language, and a logging requirement the U.S. process had not made explicit. Six weeks of anticipated work became a two-control fix plus a documentation pass rather than a rebuild.

Managing Conflicting Requirements

Convergence is the general case. Conflict is the case that ruins your quarter. U.S. requirements and EU requirements diverge in predictable ways: the EU requires specific documentation the U.S. does not mandate; U.S. policy emphasizes security and national security where EU policy emphasizes rights protection; EU data protection requirements are stricter; and U.S. policy emphasizes innovation where EU policy emphasizes safety guardrails. Those are differences of emphasis that become differences of design once you write them into a system.

The curriculum gives four moves for handling them. Design systems to satisfy the more stringent requirement. Document your interpretation and your compliance approach so that a later reviewer can see the reasoning rather than guess at it. Engage with regulators in both jurisdictions where the conflict is significant rather than picking a side quietly. And where harmonization genuinely is not possible, consider separate system configurations for different markets, accepting the maintenance cost with your eyes open.

That last option deserves emphasis precisely because the rest of this lesson argues against it. Building to the strictest applicable standard works when requirements nest, meaning the strict one contains the loose one. It fails when requirements actually conflict, as when one regime requires retaining log data that another restricts you from retaining. In that situation no single build satisfies both, and pretending otherwise produces a system that quietly violates one of them. Identify which of your requirements nest and which collide before you commit to a single-build strategy.

Supply Chain, Vendors, and Export Controls

International AI governance has heavy supply chain implications, and governments worldwide are increasingly focused on them. U.S. allies increasingly require vendor security vetting covering background checks, financial stability, and security certifications; data residency commitments keeping data within specified countries; source code access for critical systems; regular security audits; and provenance documentation for all components. If you are supplying AI to allied governments, expect these. If you are procuring AI from allied vendors, expect to have to enforce them. Either way, supply chain documentation and traceability stop being paperwork and start being the deliverable.

Export controls run in the other direction. U.S. export control regulations restrict certain AI technologies from being exported to specific countries, with the curriculum describing the current focus as China, Russia, Iran, and North Korea, and naming three restricted categories: advanced semiconductor chips used in AI, certain algorithms and technical documentation, and AI systems with dual-use military implications. For your agency the consequences are that AI developed with U.S. federal funding may carry export restrictions, that partnerships with agencies in restricted countries may be barred, that hiring international staff may be restricted for certain AI systems, and that technology transfer to international partners requires licensing. Restricted-party lists change; confirm the current list with your export control officer rather than with a course.

Practical Steps for an Agency Operating Across Borders

Tomás distilled his approach into a method his bureau could repeat without him in the room. It is deliberately sequenced: the classification work is worthless if you have not first established which jurisdictions are in play, and the vendor work is worthless if you have not first decided what your own control set is.

1. Map effects, not just code. Determine where the system's data and outputs land. The EU AI Act and similar instruments attach based on effects, so a U.S.-built tool can be in scope. Identify the jurisdictions before you classify anything.
2. Build for interoperability with one control set. Maintain a single set of controls described in framework-neutral terms, then crosswalk it outward. Do not maintain five separate compliance programs that drift apart.
3. Apply the highest common denominator where requirements nest. Design to the strictest applicable requirement. One system that meets the toughest standard usually satisfies the looser ones and is almost always cheaper than separate configurations per market. Where requirements collide rather than nest, escalate instead of averaging.
4. Flow obligations down to vendors. Most agency AI is procured. Put the binding requirements, including documentation, testing rights, transparency, and data residency where required, into contract clauses. A flow-down allocates contractual responsibility; it does not move your agency's own regulatory exposure or your accountability to the public.
5. Use shared vocabulary with partners. Talk to counterpart governments in the language of common controls, meaning human oversight, transparency, and documentation, rather than competing legal citations. It moves the conversation from jurisdiction to substance.

The single-build discipline deserves emphasis because it prevents the nightmare scenario: a different version of the same system for every market, each drifting out of sync, each its own maintenance burden. Tomás built his tool once, to the strictest applicable standard, and documented how that single build answered each framework. He also wrote down the two places where the standards did not nest, so that the next person to touch the system would find the exceptions instead of rediscovering them.

Where the Landscape Is Heading

International AI governance is evolving quickly, and the curriculum flags four trajectories worth watching. The first is that the baseline is rising. EU standards are stricter than U.S. standards, and other regions including Canada, Japan, South Korea, and Australia are expected to follow the EU approach, with the global baseline likely drifting toward EU-level stringency over the next five to ten years. The implication is to design to stricter standards now rather than to the domestic minimum on the assumption that adaptation later will be easy. It rarely is.

The second trajectory cuts against the first. The world is not converging on a single AI governance standard; it is fragmenting into blocs, with democratic-led standards on one side and authoritarian standards on the other, and systems designed for one bloc may not be compatible with the other. For globally deployed systems, plan for that fragmentation by building modularly enough to adapt to regional requirements without a complete redesign. Rising stringency and bloc fragmentation are both happening, and a strategy that assumes only one of them will fail.

The third is that international attention is concentrating on frontier systems, meaning large language models and advanced generative AI, which raise distinct risks and are attracting regulatory focus. If your agency builds or deploys frontier AI, expect international scrutiny and expect the applicable standards to move under you. The fourth is that supply chain governance has become a proxy for geopolitical competition, with allied nations working to secure trusted supply chains and adversary nations restricted. Vendor and cloud provider choices now carry geopolitical implications beyond technical performance, which is why those decisions need your security and international affairs offices in the room.

Anti-Patterns

• Treating international compliance as someone else's problem until a crisis forces it. Many agencies discover international obligations reactively. Your agency builds an AI system for domestic use; later a partner or international organization wants to use it; you discover it is not EU AI Act ready, or that export controls block the transfer, or that the vendor does not meet a bilateral security requirement. Now you are redesigning systems, renegotiating contracts, or exiting a market under time pressure. Assess international relevance early and design domestic systems to be internationally viable.
• Trying to comply with everything at once. Deciding your system must be certified to an AI management system standard, aligned to the NIST framework, aligned to OECD principles, ready for the EU AI Act, and compatible with NATO standards, then hiring a consultant per standard, produces process layers and slow development cycles without materially improving safety. Prioritize by relevance. Distinguish binding requirements from best practices from aspirational principles, and focus on the converged core where several frameworks want the same evidence.
• Assuming a bilateral agreement resolves your technical conflicts. An agreement establishes a framework; it does not resolve design conflicts. You have a data-sharing agreement with an EU partner promising GDPR compliance, your system needs to log certain data for security purposes, and GDPR restricts retention. The agreement does not say how that resolves. Put technical experts and counsel in the same room, decide how conflicting requirements will be handled in the actual design, and document the decision.
• Treating international AI governance as purely technical. Selecting a cloud provider on performance and cost alone, then discovering that export controls restrict partner access or that the provider is not trusted for national security reasons, means migrating systems you have already built. Consult your agency's international affairs or security office early in vendor selection and partnership decisions, not after award.
• Reading a NIST or M-24-10 implementation as an EU compliance determination. The overlap is real and it is most of the substantive work, which is exactly why this failure mode is tempting. But a mapping you produced is evidence you have organized, not a finding anyone has made about you. Nobody outside your agency has looked at it. Say "we believe we can demonstrate" rather than "we comply," and let counsel own the difference.
• Believing a strictest-standard build automatically satisfies every regime. It does where requirements nest. It does not where they collide, and a retention requirement fighting a retention restriction is the standard example. A single build with an unresolved collision inside it is not compliant with both regimes; it is quietly non-compliant with one of them, and nobody will notice until an audit does.
• Treating a vendor flow-down clause as a transfer of exposure. Putting the foreign obligations in the contract is necessary and it gives you a remedy against the vendor. It does not make the vendor the party a regulator, an Inspector General, or a member of the public will come to when the system misbehaves. The clause moves money and rework; it does not move accountability.

Practice Prompts

1. Four prospective users. Your agency has an AI system currently used domestically. You have received interest from an EU government agency, a NATO ally, a UN agency, and a government in a non-aligned country. For each, identify which international governance frameworks apply, what additional compliance requirements would be needed, whether there are conflicts between requirements, whether the current system can be deployed or needs modification, and what you would recommend.
2. Three systems, one classification exercise. Your agency operates a predictive model for equipment maintenance used internally, a public-facing chatbot answering citizen questions, and a facial recognition system used by border agents. Assume each is deployed on EU cloud infrastructure and accessible to EU residents. For each, state the likely risk classification under the EU AI Act, the compliance obligations that follow, your current status against them, and the changes needed.
3. Conflicting requirements. You are designing a system that must satisfy U.S. requirements emphasizing security and performance monitoring, EU requirements emphasizing data protection and rights protection, and NATO requirements emphasizing interoperability and security certification. Data retention needed for performance monitoring conflicts with data protection restrictions. Identify the specific conflicts, assess the severity of each, develop design approaches that address them, and document how you decided.
4. Research partnerships across three tiers. Your agency is establishing a research partnership with universities in an allied country, a non-aligned country, and a restricted country, involving joint model development, data sharing for training, and publication of results. For each, identify which bilateral or multilateral frameworks apply, what governance agreements are needed, what restrictions apply, and how you would structure the partnership.
5. Standards participation strategy. Your agency wants to influence how international AI standards evolve. Develop a strategy covering which standards bodies to focus on, which initiatives are most relevant to your agency's work, what expertise and resources would be required, how you would staff the participation, and what return you expect from it.

Reflection

Take twenty minutes and answer these in writing rather than in your head. Do any of your agency's AI systems operate internationally or affect international partners, including indirectly through a vendor or a cloud region? Which international governance frameworks actually apply to those systems, and which have you merely heard about? Where are your biggest international compliance gaps, and are they control gaps or evidence gaps? How well does your agency understand the geopolitical dimensions of its vendor and infrastructure choices? And how could your agency participate more effectively in international standards development, given the resources it actually has rather than the ones it wishes it had?

Glossary

• EU AI Act. European Union regulation establishing binding requirements for AI systems in the EU, organized by risk level. Applies to systems deployed in or accessible to EU citizens regardless of where the developer sits.
• Bilateral agreement. A formal agreement between the U.S. government and a specific country governing joint operations, data sharing, standards alignment, or other cooperative arrangements.
• NATO AI Strategy. NATO's framework for AI use across member states, establishing principles for responsible AI and standards for interoperability across allied systems.
• Standards harmonization. The process of aligning technical standards across countries so that a system designed to one standard is more likely to satisfy others. ISO, NIST, and government bodies are working to harmonize AI standards.
• Export controls. Restrictions on transferring certain technologies, knowledge, or data outside the United States, typically for national security or foreign policy reasons. They apply to certain advanced AI capabilities.
• Data residency. A requirement that data stay within a specific geographic location, whether a country or a region. Common in international agreements addressing data protection and sovereignty.
• OECD AI Principles. Non-binding principles for AI governance endorsed by the United States and more than forty other governments, covering benefit realization, human-centered values, transparency, robustness, and accountability.
• Extraterritorial reach. The property of a law that attaches based on where a system's effects land rather than where it was built or where its developer is established.

Related Lessons

• International Standards: EU AI Act and OECD goes deeper on the two instruments this lesson treats as anchors, including the risk tiers and the OECD crosswalk in detail.
• International Governance Coordination covers the machinery of coordinating positions across agencies and forums rather than the content of the frameworks themselves.
• International AI Diplomacy addresses the representational side: how agency staff engage counterpart governments and multilateral bodies.
• Navigating the Federal AI Landscape is the domestic counterpart, mapping the U.S. instruments this lesson crosswalks outward.
• Drafting Agency AI Policies and AI Policy Impact Assessment cover turning framework obligations into agency policy and testing whether that policy works.
• AI Supply Chain Security: End-to-End extends the supply chain and vendor vetting material into a full treatment.
• Contributing to Standards Bodies (NIST, ISO, IEEE, OECD) is the practical follow-on for agencies that decide to participate in standards development.

Closing

International AI governance is not a foreign policy concern that lives down the hall. It is an operational requirement for any agency building systems that touch international partnerships, cross borders, or process international data. The complexity comes from fragmentation rather than from difficulty: no single global standard exists, and overlapping bilateral agreements, multilateral frameworks, and technical standards create a patchwork. Your job is to understand the part of that patchwork your systems actually touch and to navigate it deliberately rather than by accident.

In practice that means assessing international relevance early, understanding which frameworks apply to your specific systems, designing to satisfy the stricter requirement where requirements nest, escalating where they collide, engaging international affairs and security staff in governance decisions rather than after them, participating in standards development where you have the resources, and planning for geopolitical fragmentation while working toward convergence. The agencies that do this well are the ones that treat international compliance as part of AI governance rather than as an appendix to it. Tomás got there by refusing to accept that five rulebooks meant five systems, and the crosswalk he built is still the first document his bureau opens when a cross-border system shows up.

Key Takeaways

• Foreign AI rules attach to your system because of reach, not agreement. Data flows, global vendors, alliance commitments, and extraterritorial design pull international requirements onto U.S. agency desks regardless of whether the U.S. shares the foreign view.
• The landscape is fragmented, so triage before you comply. Some instruments are binding law, some are treaty commitments, some are endorsed principles, and some are certifiable technical standards. Sort them by weight before you spend a dollar on any of them.
• The EU AI Act's high-risk tier is where the work lives. Risk management, data governance, documentation, logging, transparency, human oversight, and robustness are the controls you must be able to demonstrate. The other tiers are mostly prohibitions or simple disclosure.
• Keep UNESCO and the Council of Europe straight. The UNESCO Recommendation is a values and ethics standard; the Council of Europe Framework Convention is a binding treaty. Conflating them means overreacting to one or underreacting to the other.
• The frameworks are one control set in five dialects. Risk classification, transparency, human oversight, documentation, and accountability recur across the EU AI Act, OECD, NIST, UNESCO, and the Council of Europe. A crosswalk turns five rulebooks into one control set with five audiences.
• NIST and M-24-10 do most of the substantive work, not the determination. Genuine implementation leaves mostly documentation, mapping, and disclosure gaps rather than a rebuild, but a mapping you produced is not a compliance finding anyone has made about you.
• Build once to the strictest standard where requirements nest; escalate where they collide. A single strict build beats a configuration per market, but a retention requirement fighting a retention restriction has no single-build answer and pretending otherwise hides a violation.
• Flow international obligations down to vendors, and keep the accountability. Contract clauses covering documentation, testing rights, transparency, and data residency give you a remedy against the vendor; they do not move your exposure or your answerability to the public.
• Supply chain and vendor choices are geopolitical decisions. Vetting, data residency, source code access, audits, provenance documentation, and export controls all sit on top of the technical evaluation. Bring security and international affairs in before award.
• Lead partner conversations with common controls, not citations. Shared vocabulary such as human oversight and transparency moves cross-border discussions from arguing jurisdiction to aligning substance.

Frequently Asked Questions

Does the EU AI Act really apply to a U.S. federal agency? It can, because the Act attaches based on where an AI system's effects land rather than where it was built. The curriculum for this lesson describes the trigger conditions broadly: deployment on EU cloud infrastructure, accessibility to EU citizens over the internet, or processing of EU citizen data. Use those as a planning trigger to identify candidate systems for review, then get a scope determination from counsel for any system that trips them. Do not treat a checklist as the determination.

If we have implemented the NIST AI Risk Management Framework, are we EU-ready? You are much closer than an agency that has not, because the substantive controls overlap heavily. You are not finished. The gaps are usually in the form of the evidence rather than the existence of the control: EU-specific documentation, user-facing disclosure language, and logging that your U.S. process may have left implicit. And no external party has assessed you, so "we implemented NIST" is a position you argue from, not a conclusion.

Are the OECD AI Principles binding on us? No. They are non-binding recommendations. The United States endorsed them along with more than forty other governments, which makes them a commitment partner governments expect to see honored in practice and a reasonable benchmark for your transparency statements and risk methodology, but they create no legal obligation and no enforcement mechanism.

Should we build one system to the strictest standard or separate configurations per market? One system, wherever the requirements nest so that satisfying the strict one satisfies the loose one. That is the cheaper and more maintainable answer and it avoids configurations drifting apart. Where requirements genuinely collide, a single build cannot satisfy both, and separate configurations become the honest option even though they cost more. Identify which of your requirements nest and which collide before committing.

What is the difference between the UNESCO Recommendation and the Council of Europe Convention? Kind, not degree. The UNESCO Recommendation on the Ethics of Artificial Intelligence is a values and ethics standard adopted by the broad UNESCO membership. The Council of Europe Framework Convention on Artificial Intelligence is a treaty, the first binding international treaty on AI, focused on human rights, democracy, and the rule of law across the AI lifecycle. One sets expectations; the other creates treaty-level commitments.

Does an ISO certification prove our AI is safe? No. An AI management system certification attests that your organization runs a governed process with the documentation and review steps the standard requires. It says nothing directly about whether a particular model is accurate, fair, or robust in deployment. It is useful evidence for international partners precisely because it is inspectable, and it is misread whenever anyone treats it as a statement about model behavior.

Who in my agency should own this? In practice it is shared, which is why it falls through cracks. The technical and control work sits with the AI governance function; scope determinations sit with counsel; export control and restricted-party questions sit with your export control and security offices; and engagement with counterpart governments and standards bodies runs through the international affairs or policy office. The one thing that should not be shared is the inventory of which systems have international exposure. Name a single owner for that.