Minji Thorvaldsen ran compliance for a SaaS analytics company that had grown from a single-market startup to a platform used in 19 countries, mostly by accident. Sales had landed customers in Germany, Brazil, South Korea, and Australia without anyone stopping to ask what 19 simultaneous data jurisdictions actually meant for the AI scoring engine at the heart of the product. By the time Minji was hired to sort it out, the company had a model trained on data it could not legally transfer out of South Korea, an EU customer waiting 6 months for a data processing agreement, and a compliance gap in Brazil's Lei Geral de Proteção de Dados (LGPD), Brazil's data protection law, that the sales team had simply ignored at deal close. The cost to remediate was estimated at $1.2 million and 14 months of engineering time.

Compliance as a System, Not a Knowledge Problem

Cross-border AI compliance is not about knowing every regulation in every country. No individual practitioner can maintain that knowledge, and treating it as a knowledge problem is how organizations end up depending on one overworked person who becomes a bottleneck and then leaves. It is about building a system of people, process, and tooling that catches jurisdiction-specific issues before they become architectural problems. The difference is decisive, because the cost of a compliance finding rises sharply with the stage at which it is discovered. A constraint identified during design changes a diagram. The same constraint identified after a customer contract changes a production system that other people depend on, under commercial pressure, with a deadline someone else set.

The Three Layers of Compliance

When an AI system operates across borders, its compliance requirements fall into three distinct layers. They are worth separating because each has different owners, different timelines, and different remediation costs when missed, and because they apply simultaneously rather than in sequence. An organization that has satisfied the data layer has not thereby addressed the other two.

Layer 1: Data Rules

Every jurisdiction that matters has rules about personal data: what you can collect, how long you can keep it, whether you can transfer it across borders, and what rights individuals hold over it. The EU's General Data Protection Regulation (GDPR) is the most widely known but it is not the only one, and assuming it is the strictest everywhere is a mistake that shows up in the training pipeline. Brazil's LGPD, South Korea's Personal Information Protection Act (PIPA), China's Personal Information Protection Law (PIPL), and California's CCPA each have their own scope, transfer restrictions, and enforcement priorities.

For AI systems specifically, three data questions carry the architectural weight: can you train on data from this jurisdiction, can you transfer it out, and can you use it for automated decisions? Those three answers determine whether a given model architecture is legally viable in each market, and they determine it before you build rather than after. Minji's company had answered none of them for South Korea, which is why it discovered its transfer restriction as a property of a model that already existed.

Layer 2: AI-Specific Rules

A smaller but growing set of jurisdictions has AI-specific regulation layered on top of general data rules. The EU AI Act is the most comprehensive, classifying AI systems by risk and imposing conformity assessment requirements on high-risk uses. China has its own algorithmic recommendation regulation and generative AI rules. The US lacks a federal AI law but has sector-specific guidance from the FDA, CFPB, EEOC, and FTC that applies to AI within each of their domains, which means the absence of a single statute does not translate into an absence of obligations.

The important structural point is that these rules attach to what the system does, the use case, rather than only to what data it processes. The same model architecture carries different requirements depending on its application: used for product recommendations it is usually lower-risk, and used for employment screening it is often high-risk. A team that has cleared an architecture for one purpose has not cleared it for another, and a product decision to extend a working model into a new use is therefore a compliance event, not just a roadmap item.

Layer 3: Sector-Specific Rules

If your AI operates in a regulated sector such as financial services, healthcare, insurance, or utilities, a third layer of requirements applies regardless of general data law or AI-specific law. These layers stack rather than substitute. A credit-scoring AI in the EU faces GDPR, the EU AI Act's high-risk classification, and the EU Consumer Credit Directive at the same time, and all three apply simultaneously. Where their requirements differ, the most restrictive requirement in each area governs, which means compliance design has to be built against the union of the obligations rather than against whichever regime the team happens to know best.

The Compliance Inventory System

Minji's first action was to build a jurisdiction inventory: a living document mapping every market the product operates in against the three layers. It is deliberately a simple artifact, because its value depends on product and engineering teams using it without help. The format is a spreadsheet with a column for each of the following.

• Country
• Data transfer rules, covering whether data can be received and whether it can be transferred out
• Key data rights that affect the product, such as the right to explanation and the right to deletion
• AI-specific rules applicable to the use case
• Sector-specific rules applicable
• Current compliance status, recorded as compliant, gap, or unknown
• Owner and review date

This is not a legal opinion document, and describing it as one is the fastest way to make it useless. It is a quick-reference map that tells product and engineering teams what constraints exist before they make architectural decisions. Legal counsel validates it; the product team uses it daily. The "unknown" status is a feature rather than an embarrassment, because an explicitly recorded unknown is a question someone can be assigned, whereas an omitted row is a question nobody knows to ask.

The inventory only works if someone owns it and updates it on a defined schedule. Quarterly review is the minimum. In jurisdictions with active regulatory development, currently including the EU, China, and the US, monthly monitoring of regulatory news is warranted. Without an owner and a cadence, the document ages into a description of a product that no longer exists, and the teams relying on it will not notice, because a stale inventory looks exactly like a current one.

Architecture Decisions with Compliance Consequences

Three technical architecture choices carry the highest compliance consequences, and each must be made with the jurisdiction inventory open rather than reconciled against it afterwards.

Where Training Data Lives

If you train a model on data from a jurisdiction with strict transfer restrictions, such as South Korea, China, or Russia, that training must happen within the jurisdiction's borders or on data that has been anonymized or pseudonymized to a standard that satisfies local law. Building a single global training pipeline without these constraints designed in is a legal liability waiting to be discovered, and it is discovered at the worst possible moment: when the model already works and the business is depending on it. Retrofitting jurisdictional separation into a pipeline that assumed one pool of data is close to a rebuild.

Where Inference Happens

Processing personal data to generate an AI output is typically regulated in the same way as any other processing of personal data, a point that teams often miss because inference feels transient. If a user in Germany submits data to your API and inference happens in a US data center, you have a cross-border data transfer, and it requires either a compliance mechanism, such as Standard Contractual Clauses for EU transfers to the US, or a change to your infrastructure. Deciding which of those two routes you are taking is a design decision with cost implications, and it is much cheaper to make while the deployment topology is still a diagram.

Audit Trails and Explainability

Multiple frameworks converge on the same requirement: GDPR's right to explanation for automated decisions, the EU AI Act's documentation requirements for high-risk systems, and the CFPB's adverse action requirements in US consumer lending all require that you can explain, after the fact, why the AI made a specific decision about a specific individual. If your model architecture does not support that, and some deep learning models are inherently opaque, then you need either a different model type for regulated use cases or a post-hoc explanation layer that satisfies the applicable standard. This is a choice about model selection, which means it belongs at the beginning of the project, not in the response to a regulator's letter.

Operationalizing Compliance Across Teams

Compliance is only effective if it lives inside product and engineering decisions rather than in legal documents that the people making those decisions never open. Four operational practices carry most of the weight, and each attaches an existing question to an existing moment rather than creating a new process for its own sake.

• Compliance review at feature inception. When a new AI feature is proposed, the first question in the spec review should be which jurisdictions it affects and whether there are compliance implications. This takes 15 minutes and can prevent months of rework, because at inception the answer changes a specification rather than a system.
• Legal review of data flows before new market entry. Every new country is a new row in the inventory and potentially a new set of constraints. Entering a market without legal review of AI data flows is precisely the mistake Minji was hired to fix, and it is generally made by people who did not know a review existed.
• Compliance training for commercial teams. Sales and account management teams closing deals in new jurisdictions need to know what commitments they can and cannot make about data handling. A deal closed on a verbal assurance that the team will figure out data residency later creates a problem that engineering then has to solve under contract pressure, on a timeline set by the customer.
• Regulatory monitoring with clear ownership. Assign a named person to monitor regulatory developments in each significant jurisdiction. The job is not to be a lawyer; it is to flag news and guidance to the legal team early enough that a deadline does not arrive unexpectedly. Ownership by a team rather than a person is equivalent to no ownership.

The cheapest compliance work is the work you do before the architecture decision. The most expensive is the work you do after the customer contract. Everything in this section is an attempt to move work from the second category into the first.

Anti-Patterns

• Treating compliance as a knowledge problem. Depending on one person to hold every jurisdiction's rules in their head produces a bottleneck that disappears when they do.
• Assuming GDPR compliance covers everything. Other regimes have their own scope, transfer restrictions, and enforcement priorities, and a transfer restriction elsewhere will surface as a property of a model you already built.
• Clearing an architecture once. Extending a working model into a new use case changes its risk classification, which makes it a compliance event rather than a roadmap item.
• Treating the jurisdiction inventory as a legal document. If product and engineering cannot use it without counsel present, they will make architectural decisions without it.
• Leaving rows out instead of marking them unknown. A recorded unknown can be assigned to somebody; an omitted row is a question nobody knows to ask.
• A global training pipeline with no jurisdictional separation. Retrofitting separation into a pipeline that assumed one pool of data is close to a rebuild.
• Deciding explainability after model selection. Some architectures cannot produce the explanation regulated use cases require, and by then the choice has been made.
• Assigning regulatory monitoring to a team. Ownership without a named individual means the monitoring happens when someone has time, which is to say after the deadline.

Practice Prompts

• Build the first rows. Start a jurisdiction inventory for the markets that matter most, filling only country, data transfer rules, and current status. Mark honestly how many are unknown.
• Answer the three data questions. For one jurisdiction you operate in, establish whether you can train on its data, transfer it out, and use it for automated decisions.
• Classify one use case twice. Take a model in production and describe its risk classification for its current use and for one plausible extension. Note where the answers differ.
• Trace one inference path. Follow a single user request from submission to output and write down every country its data passes through.
• Test your explainability. Pick a consequential automated decision your system made and try to produce, from existing artifacts, an explanation of why it was made for that individual.
• Run the 15-minute review. Add the jurisdiction question to the next feature spec review and record how long it actually took and what it surfaced.
• Name the monitors. Write down the individual responsible for regulatory monitoring in each significant jurisdiction. Note every jurisdiction where you cannot write a name.

Reflection

Consider the markets your AI systems currently serve and ask how each one was entered. In most organizations the honest answer is that several arrived through a sales opportunity rather than a decision, which is exactly how Minji's company reached 19 jurisdictions without anyone assessing what that meant. The question is not whether that happened; it is whether it can still happen tomorrow, which depends entirely on whether new market entry currently triggers anything at all.

Then ask where in your development lifecycle a jurisdiction question is actually asked. If the answer is at legal review before contract signature, the system is functioning as a late detector rather than a control: the finding still arrives, but it arrives after the architecture is built and often after commercial commitments have been made. Moving that question to feature inception costs 15 minutes per feature, and it is the single change that converts the most expensive category of compliance work into the cheapest.

Glossary

• Jurisdiction inventory. A living map of every market the product operates in against the three compliance layers, with a status, an owner, and a review date per row.
• Data rules layer. Requirements governing collection, retention, cross-border transfer, and automated decision use of personal data.
• AI-specific rules layer. Regulation attaching to what an AI system does, typically classified by the risk of the use case.
• Sector-specific rules layer. Obligations that apply because of the industry, independent of data law or AI law, and stacking on top of both.
• Cross-border data transfer. Movement of personal data out of a jurisdiction, which includes sending data to an inference endpoint in another country.
• Standard Contractual Clauses. A compliance mechanism for transfers, cited here for EU transfers to the US.
• Conformity assessment. The evaluation the EU AI Act imposes on systems classified as high-risk.
• Right to explanation. The requirement that an individual can be told why an automated decision was made about them.
• Post-hoc explanation layer. An added component that produces decision explanations when the underlying model cannot, used where the applicable standard allows it.
• Data residency. The requirement that data remain physically within a given jurisdiction, frequently promised in sales conversations before it is designed for.

Related Lessons

Cross-border compliance draws on both the regulatory and the operational sides of the curriculum. Navigating Global AI Regulatory Divergence covers the strategic picture when jurisdictions pull in different directions, and Regulatory Landscape & Compliance Requirements introduces the individual regimes in more depth. Data Privacy & Compliance and Data Privacy Regulations and Compliance Basics address the data layer, while High-Risk AI & Enhanced Oversight covers what changes when a use case is classified as high-risk. Compliance System Design and Audit & Compliance Monitoring are where the inventory becomes an operating process, Documentation, Audit & Regulators covers the evidence you will be asked for, and Transparency and Explainability in AI Systems goes deeper into the explanation requirement discussed here. Cultural & Regulatory Differences adds the context for operating across markets.

Closing

Nothing that happened to Minji's company required anyone to act badly. Sales closed deals, engineering built a pipeline that worked, and the product spread into markets faster than anyone tracked. The failure was structural: there was no moment at which entering a new country obliged anyone to ask a question, so nobody asked one, and the answers arrived later as architecture problems with a price attached. The remedy is unexciting and it is durable. Keep an inventory that product teams actually use, put the jurisdiction question at the start of the feature review, make sure the people signing contracts know what they may promise, and give regulatory monitoring a name rather than a team. Those four things move compliance from the expensive end of the project to the cheap one, which is the entire game.

Key Takeaways

• Cross-border compliance has three layers. General data rules, AI-specific rules, and sector-specific rules, all of which may apply simultaneously to a single deployment, with the most restrictive requirement governing.
• It is a system problem, not a knowledge problem. No practitioner can hold every jurisdiction's rules; the goal is a process that catches issues before they become architectural.
• A jurisdiction inventory is the foundational tool. A living map of each market against each layer, with named owners, review dates, and unknowns recorded rather than omitted.
• Three architecture decisions carry the highest compliance risk. Where training data lives, where inference happens, and whether audit trails and explainability are built in from the start.
• AI-specific rules attach to the use case, not the architecture. The same model carries different obligations for product recommendations than for employment screening.
• The most expensive remediation is post-contract. Data architecture changes under an active customer agreement are technically and commercially difficult.
• Commercial teams are a compliance risk if untrained. Deal commitments made without compliance awareness create obligations engineering must then fulfill under pressure.
• Compliance review at feature inception costs 15 minutes. Remediation after deployment costs months and significant budget.
• Named ownership of regulatory monitoring is non-negotiable. Unowned monitoring means you learn about regulatory changes when they have already become problems.

Frequently Asked Questions

Do we need a lawyer for every jurisdiction we operate in? No, and structuring the work that way is what makes compliance unaffordable. The inventory is built and used by product and compliance staff and validated by legal counsel, which concentrates expensive expertise on the questions that genuinely need it. Counsel confirms interpretations and reviews data flows before market entry. The daily work of checking a constraint before an architectural decision belongs to the team making the decision.

What goes in the inventory when we simply do not know the answer? Write "unknown" and attach an owner and a date. This is the status that makes the inventory honest, because a recorded unknown becomes a question somebody has been assigned, while a blank or a missing row silently reads as no constraint. An inventory full of unknowns at the start is a working document. An inventory with no unknowns at all usually means nobody looked hard.

We already comply with GDPR. Does that cover the rest? Not reliably. Other regimes, including LGPD, PIPA, PIPL, and CCPA, each have their own scope, transfer restrictions, and enforcement priorities, and some impose constraints GDPR does not. Minji's company discovered a South Korean transfer restriction only after it had trained a model on data it could not move. GDPR alignment is a strong foundation for the data layer, and it says nothing at all about the AI-specific and sector-specific layers.

Our model is a deep learning system we cannot easily explain. Is that disqualifying? It depends on the use case and the jurisdiction, which is why the question belongs at model selection rather than at deployment. Where GDPR's right to explanation, the EU AI Act's documentation requirements for high-risk systems, or the CFPB's adverse action requirements apply, you need either a model type that supports explanation or a post-hoc explanation layer meeting the applicable standard. The failure mode to avoid is discovering the requirement once the architecture is fixed and the honest options have all become expensive.