Your automation runs in Europe. Your data might not.

Here is a question that tends to ruin a good meeting: where does your data physically go when an automated workflow runs? Not which tools you pay for. Where the actual bytes travel, step by step, from the moment someone hits submit until the record lands in your CRM.

Almost nobody can answer it. I have asked this in companies of two people and companies of two thousand, and the room goes quiet either way. People know their tool stack. They have signed the contracts. They have a vague sense that everything is "in Europe." But the path a single record takes through that stack? That is usually a black box, and the black box is exactly where the risk lives.

This is not a compliance lecture. It is a practical look at why data flow is the blind spot in nearly every automation, where data quietly crosses borders, and how to draw your own map in an afternoon.

"GDPR-compliant" describes a contract, not your process

When a vendor markets itself as GDPR-compliant, that tells you something about their paperwork. It tells you nothing about what your specific workflow does. Make is headquartered in Prague with EU servers. A Make scenario can still ship data to a US service in five clicks, and that is not Make's fault. The platform is European. Your data flow might not be.

The mistake is treating compliance as a property of tools. It is not. Compliance is a property of the route one record takes. Two companies can use the same tools, sign the same data processing agreements, and end up in completely different places, because one of them chained the modules in a way that sends personal data overseas and the other did not.

So I stopped asking clients for their tool list. I ask them to walk me through one record instead. "Take the last job application that came in. Tell me everywhere that CV travels before it reaches HR." It rarely takes under ten minutes, and it is almost always incomplete. The gaps in that story are the whole point.

Where the workflow runs is not where the data lives

This trips up almost everyone, so it is worth slowing down. The place your automation tool executes its logic and the place your data ends up are two different things.

Say you self-host n8n on a server in Frankfurt. Looks clean. All in Germany. Then your workflow adds a step that summarizes some text using the OpenAI API. The n8n server is in Frankfurt, the orchestration happens in Frankfurt, but the text being processed gets sent to the US the moment that step fires. Where your engine sits is irrelevant to the data passing through it. n8n is the conveyor belt, not the warehouse.

The reverse holds too. You can run a US tool like Zapier and still keep certain data inside the EU, if you pick the modules deliberately. The logo on the invoice tells you nothing. The path of each field tells you everything.

The chain behind the chain

Every vendor you sign with has vendors of their own. Your automation tool runs on cloud infrastructure. Your CRM uses an email delivery service. That delivery service maybe uses a US data center for deliverability checks. This is subprocessing, and it is the part nobody reads.

Any serious vendor publishes a subprocessor list, usually on a boring page titled "Subprocessors." That page is tedious and it holds the one fact that matters when something goes wrong. I have seen a supposedly all-European newsletter tool list a US analytics provider as a subprocessor, quietly routing every opened email address through the States. Nobody at the company knew, because nobody had ever opened the list.

Three places data crosses a border without anyone noticing

Theory only gets you so far. Three real shapes I have seen more than once, at very different sizes, all with the same plot twist: the data flow does something nobody intended.

A solo consultant automates her lead handling. Contact form, into a Google Sheet via Zapier, then an AI tool drafts a personalized reply. The most innocent setup imaginable. Except the form runs on a US provider, Zapier is a US company, the sheet sits in a US region depending on the account, and the AI step ships the person's name and request to a model in the States. One inquiry, four handoffs, four transfers overseas. She thought she was doing "a little automation." She had built a cross-border transfer chain without noticing.

A 120-person company had a genuinely clean stack: German CRM, EU-hosted automation, every contract in place. Then someone in sales added a handy step that enriches each new lead with company data, sending the contact's email address to an enrichment service in the US. The data protection officer had no idea, because that step was added after his review. That is the structural trap. Automations are not built once and frozen. They grow, and every new block can change the data flow while the original assessment sits untouched. We fixed it by sending only the email domain instead of the full address. The personal link disappears, the value stays.

The third one is my favorite, because it is so easy to miss. A large enterprise had its core automation set up properly in Europe. The problem was the logging. Every workflow run, including the records it processed, was shipped to a central logging tool for debugging, and that tool lived in a US region because IT had configured it years earlier. The real data stayed in Europe. Every error log with full records went to the States. Logs are the most overlooked data flow there is, because they feel like technical plumbing rather than processing. They are processing, if personal data is in them, and plaintext logs contain a startling amount.

"But it's just business contacts"

Someone always raises this: we don't handle sensitive personal data, it's all B2B, company emails. Reasonable, and wrong. An address like john.smith@company.com identifies a specific person, business or not. GDPR doesn't care whether the context is professional. The same goes for the fields riding along in every B2B automation: contact name, direct line, job title, that note from the sales call. "John was annoyed on the phone" is personal data with a judgment attached. Routing it through a US service is not a non-event just because it's about business. "It's only B2B" is the sentence most unnoticed transfers hide behind.

The table I draw in every project

When I audit a stack, the same table always falls out of it. One row per processing step, four columns: what personal data, which vendor, where it is stored, and is it a third-country transfer. It is unglamorous, and that is the point.

Once this is on the table, the conversation changes. "We're basically compliant" becomes "we need to deal with rows three, four, and six." Not a fun moment for the client, but the first honest one.

Is a US service automatically illegal after Schrems II?

No. I get this in almost every project, so here is the short version. A transfer to the US is not banned outright, it needs a solid legal basis. Since the EU-US Data Privacy Framework in 2023, there is an adequacy decision again for US companies certified under it. If your workflow sends data to a vendor on the DPF list, that transfer is generally covered.

The weight sits on "certified." Not every US company is on the list, certification can be revoked, and the decision is politically fragile. A "Schrems III" is considered a realistic possibility. Betting your entire data flow on one vendor's current DPF status is building on ground that can shift.

My practical take: check each US service in your table against the public DPF list, and wherever you can, shrink the amount of personal data that takes that path in the first place. Domain instead of full address. Data minimization at the handoff point is the sturdiest protection, because it survives the next political decision.

How to map your own data flow this afternoon

You do not need a lawyer or an expensive tool for the first pass. You need a blank doc, access to your automation, and the discipline to look at every step on its own.

Start with a real record, not "the process" in the abstract. The last application, the last order, the last support ticket. Real data forces you to trace honestly instead of copying the ideal from a diagram. Then walk the workflow module by module and write down which personal fields pass through each step, by name, not as "customer data." For every vendor that shows up, check two things: which region holds the data per contract, and who they list as subprocessors. Search the vendor name plus "subprocessors" and read the boring page.

Fill in the third-country column for each step, and where the answer is yes, note the legal basis. Anywhere you cannot name one, you have found a gap, and finding it was the entire job. Last, do not forget the logs. Look at your tool's notification and logging settings. That line is often the most surprising entry in the whole table.

What I actually took away from all this

After dozens of these audits, one thing is clear: the privacy risk in automation almost never sits in a deliberate violation. Nobody builds an illegal transfer chain on purpose. The risk sits in the gap between what a company believes its process does and what it actually does. And that gap widens with every new automation, because workflows grow and nobody revisits the old assessment.

The second thing: privacy in automation is an architecture problem, not a contract problem. The best fixes I have seen were not new agreements. They were small changes to the data flow. A domain instead of an address. A logging target in the EU. An enrichment step that only handles non-personal fields. An hour of work each, solving problems a lawyer could only confirm for you at a much higher rate.

And the last, almost boring point: the company that knows its data flow sleeps better. Not because it has zero overseas transfers, almost everyone has some, but because it can answer the question. When a regulator knocks, when a prospect asks, when a customer wants to know where their data lives, the table is the difference between a calm answer and an awkward silence. I ran into that 80-person manufacturer again, by the way. His first automation runs almost unchanged today. What changed is that he now knows where the data goes. That was the whole job.