GDPR International Data Transfers for AI-Built Apps: Find Every One Before You Write Any Paperwork

Short answer: first build a list of every place your users' data ends up. Only then start on the forms. If an AI coding tool built your app, that list is not in your head. You never made the choices. It is in your config files, your package list, your webhook settings, and the vendor pages that name your vendors' own vendors. Build the map first. Chapter V of GDPR then tells you what each line on it needs.

We have run more than 700 audits of AI-built SaaS, websites and apps. Transfer work shows the same pattern as everything else. The code works. Nobody knows what it touches.

The rule, in plain words

GDPR splits the world in two. Inside the European Economic Area, or EEA, data moves freely. Outside it, you need a reason.

Article 44 sets the principle. You may only send personal data outside the EEA if the protection GDPR gives it travels with it. Nothing further down the chain may strip that away. The rest of Chapter V, Articles 45 to 49, lists the ways to meet that test.

Two things trip founders up here.

The first is the word transfer. It sounds like a file you send on purpose. It is far wider than that. Say a company outside the EEA stores your data. Or runs code over it. Or holds a backup copy. Or has staff who can log in and read it. Each of those is a transfer. Access counts, not just movement. A support engineer in another country opening a ticket and reading a customer record is a transfer.

The second is who is on the hook. You are. Your vendor may hold the data abroad. But you chose them, so Article 44 puts the duty on you.

Why AI-built apps are a special case

A normal engineering team picks vendors on purpose. Someone opens a sheet, argues about price and region, and signs. That leaves a trail. The transfer list is half written before anyone asks for it.

An AI-built app skips all of that. You described a product. The tool wired up a database, a host, a login provider, a mail sender, a payment page and a model API. It took each one's default settings. Defaults are picked for speed and for the biggest user base. That usually means a region outside the EEA.

So you now own a data flow you did not design. You have never seen it written down. That is not a legal problem yet. It is a hunt. And a hunt is something you can finish in an afternoon.

Find every transfer in your own app

Work through these six places in order. Write each finding into one table with four columns. The vendor. The data that reaches it. The country or region. And what makes it lawful. That last column will be empty at first. That is the point.

1. Region settings you already have

Open each vendor dashboard and find where the region is set. Database host. File storage. Login provider. Analytics. Error tracking. Background jobs. Write down what it says, not what you assumed. Projects made in a hurry sit wherever the signup flow put them.

While you are there, check whether the region can still be changed. For some services it is fixed at setup. Moving then means a full move of the data. Better to learn that now than mid-way through a customer's review.

2. Environment variables and config files

Open your .env file and the same settings on your deploy platform. Every key in there points at a company. A key you do not recognise is a vendor you forgot you had.

Look for region hints inside the values themselves. Hostnames and endpoint URLs often name the region in plain text. A client library given a URL will use it. A toggle set somewhere else does not override that.

3. Package list and SDK imports

Read your package.json or requirements.txt line by line. Then grep your source for the imports you really use. AI tools install more than they wire up. The two lists differ. Only the second one matters here.

Watch for anything that sends data out on its own. Analytics. Recording tools. Error reporting. Feature flags. Customer chat. Email and SMS. Any model or embedding API.

4. Webhooks, callbacks and outbound calls

Search your code for outbound HTTP calls. Then search your vendor dashboards for webhook URLs. People miss this one most. It sits in neither the package list nor the env file.

A signup handler that posts a new user's email to a marketing tool is a transfer. So is a payment webhook that passes on a name and address. Neither shows up anywhere but the code.

5. Logs, traces and backups

Find where your app logs go. Find where error reports go. Find where backups are written. Then check the region of each one on its own, apart from your main database.

Logs are the quiet one. Log whole request bodies and you log email addresses, names, sometimes tokens. If those logs leave the EEA, so does everything in them.

6. Your vendors' vendors

Every serious vendor lists its own vendors, called sub-processors. The list is often linked from their DPA or trust page. Open each one and read it.

Under Article 28 your processor needs your say-so before bringing in a sub-processor. It must also pass the same duties down the chain. So an EU-based vendor running on machines outside the EEA still creates a transfer. That one goes on your map, not just theirs. Our guide to DPAs with AI coding tools covers what to look for in those terms.

The region-toggle trap

Choosing an EU region is worth doing. It really does remove transfers. It just does not remove all of them. The gap between "EU region selected" and "no transfers" is wider than it looks. That gap is where a customer questionnaire tends to catch people out.

Six paths commonly survive an EU region setting:

• Logs and error reports. Often a second service, with its own region, set on its own.
• Backups and copies. Kept safe elsewhere, sometimes in another region on purpose.
• Edge and serverless code. Data can rest in the EU while the code reading it runs nearest the user.
• Support access. A vendor's staff can often read live data. They sit wherever they sit.
• Their vendors. Covered above, and invisible from your own dashboard.
• Model APIs. Send user text to a model and you send whatever the text holds.

None of this means you did something wrong. It means the map has more lines than the dashboard let on.

What each transfer needs

Now take your table and fill in the last column. There are three realistic answers.

Article 45: adequacy

The European Commission can rule that a country guards data well enough. Transfers there then need no extra safeguard. This is called adequacy. Where it covers your vendor's country, that line on your map is settled. You still owe everything else GDPR asks. You just do not need clauses.

The United Kingdom is the clearest example today. The Commission renewed its two UK decisions on 19 December 2025. The ICO records that both now run to 27 December 2031. Data can move from the EEA to the UK on that alone.

Article 46: Standard Contractual Clauses

Where adequacy does not apply, you fall back on contract terms. The Commission pre-approves a set of them, called Standard Contractual Clauses. Most large vendors put them inside their DPA. That is why signing the DPA matters. An unsigned one is a real gap.

Signing is not the end of it. You also have to check that the other country's laws will not defeat those promises. Then write down what you found. That check is called a transfer impact assessment. The EDPB's Recommendations 01/2020 set out the method in six steps, starting with knowing your transfers, which is the inventory you just built.

Serving UK users too? The UK runs its own version of this, with its own addendum. The ICO says an EU assessment can feed the UK one.

Article 49: derogations

Article 49 lists a few narrow exceptions. Explicit consent, given after a warning about the risks. A transfer needed to carry out a contract with that person. Important public interest. Legal claims. A short list of others.

It is not a route for the vendors your product runs on. The catch-all ground in Article 49(1) only covers transfers that are not repeated. They must also touch a limited number of people. Your database host runs every second of every day.

Adequacy is a decision, not a law of nature

One honest note, because it shapes how you build.

Adequacy decisions are reviewed, and they can be challenged. In July 2026 the EDPB wrote to the European Commission about the EU-US Data Privacy Framework. It asked the Commission to assess a United States Supreme Court ruling on the independence of federal agencies. Its point was that independent oversight is one of the things Article 45(2)(b) asks the Commission to weigh. That letter is a request to look again. It is not a change in the law, and the framework stands.

The lesson is not to panic about any one decision. It is to avoid a stack that stands or falls on one. Where a vendor offers both an EU region and clauses, take both. Keep the DPA and the written check on file even where adequacy covers you today. Then a change in status means an update to a file. Not an emergency move of your data.

What a scan can see, and what it cannot

Worth being straight here, because it sets how much of the work is yours.

An outside check of your live product sees the outside of your stack. It can list the services your pages load and call. It can flag missing security headers. It can name the vendors you seem to lean on. Two checks in our Compliance Score do just that: third-party SaaS identified and vendor security documentation. Between them you get a first draft of column one.

What no outside scan sees is the inside. It cannot read your backup region. Nor your log target. Nor your support-access settings. Nor your vendors' own vendor pages. Those are yours to open. A scan starts the list and catches things you forgot. It does not finish it.

It matters that the security side holds up too. Missing HTTP security headers show up in 83% of the scans we run. Contract terms do not help much if the data can be reached without going near the vendor. Safeguards and security are one job seen from two sides.

Fix checklist

1. Build the four-column table. Vendor, data, country, and what makes the transfer lawful.
2. Walk the six sources above. Config, packages, webhooks, logs, backups, vendor pages.
3. Move to an EU region anything that offers one and is not set up yet.
4. Sign the DPA with every vendor that has one. Check the clauses are in it.
5. Write a transfer impact assessment for each transfer you cover with clauses.
6. Stop logging whole request bodies. For most AI-built apps it is the cheapest way to cut what leaves.
7. Name the transfers in your privacy policy. Article 13 says you must tell people their data goes abroad, and what guards it.
8. Re-read those vendor pages on a set date. Vendors add new ones, and the notice tends to arrive by email.

Where this sits in the wider picture

Transfers are one file in a wider set. The list you build here is the same one that feeds your data map. A good map is what makes a data protection impact assessment possible. It is also what makes a subject access request answerable instead of frightening. Build it once. Use it four times.

It also ties back to choices baked into your code at the start. Privacy by design is mostly about not collecting data you never needed. The less data leaves your app, the shorter this map gets. The same logic covers tracking scripts that fire before consent. Those are a consent problem, and quietly a transfer as well.

One thing it does not tie to: the EU AI Act. That law covers how AI systems are built and disclosed, including the Article 50 duties. It says nothing about where data may travel. It gives you no route to move data outside the EEA. Two files, kept apart. Closing one does not close the other.

Want the wider view first? Start with our GDPR guide for AI-built apps, or the shorter compliance checklist. Two quick wins sit underneath all of it. Run the security headers checker, then read our note on secrets exposed in AI-built bundles. Our Replit and Bolt comparison also shows how far the defaults differ between tools.

FAQ