The EU AI Act arrives on August 2. Can you prove where your AI data goes?

On 2 August, a further set of EU AI Act obligations takes effect. If you build or operate AI inside a regulated European business, the practical effect is blunt: someone now has to answer, in writing, where your AI data goes and who processes it. That is what EU AI Act data residency really means: not where your database lives, but where each inference request actually goes. Most teams cannot answer that cleanly today. Here is why, and what to do about it before the date.

The question you can no longer avoid

The best models are US-controlled. So teams reach for them, wire up an SDK, and ship. It works, right until someone in security or compliance asks the obvious question: when a user pastes a customer record, a patient note, or a contract into that feature, where does it go? Through whose infrastructure? Under which country's law?

For a lot of teams the honest answer is "we are not sure." That uncertainty is exactly what the new rules are built to remove. Between the AI Act's accountability and transparency obligations and the GDPR rules on transfers to non-EU providers, the era of shipping AI features and sorting out the paperwork later is closing.

A region setting is not proof of residency

The common response is to switch on a provider's EU region and move on. That helps. It is also not a guarantee. It is a setting, and a setting depends on every engineer remembering to apply it, on every call, in every service, forever. One new endpoint, one refactor, one library default, and regulated data is on a US-controlled model again.

And when an auditor asks you to demonstrate that a specific request stayed in the EU, a configuration screen is not evidence. "We ticked the EU box" is a claim. What a reviewer wants is a record: for this request, the model was X, the provider was Y, the region was Z, and here is why it was allowed. Residency you configure is not the same as residency you can prove.

Pseudonymized is not anonymous

There is a second trap. Teams assume that stripping names makes data safe to send anywhere. Under the GDPR, pseudonymized data is still personal data (Recital 26). Masking a customer's name reduces exposure; it does not turn a transfer to a US provider into a non-transfer. The rules still apply. Treating pseudonymization as a way out is how well-meaning teams end up out of compliance.

What "governed" actually means

Governance is not a policy document that lives in a wiki. It is an enforcement point that sits between your application and the models, and it does three things by default:

• It keeps regulated data in the EU and fails closed. Nothing reaches a non-EU model unless you have explicitly allowed it, for that traffic, on the record. The default is safe, not the exception.
• It pseudonymizes personal data before anything leaves, so exposure is reduced even on the routes you do permit.
• It writes an audit record for every request: which model ran, in which region, through which provider, and why the routing was allowed.

The difference is where the rule lives. In most stacks, residency is a convention scattered across services and dependent on people remembering. Governed means the rule lives in code, in one place, at the model router, enforced on every request rather than hoped for.

A checklist you can run this week

You do not need us to start. Whether or not Akumi is ever in the picture, this is worth doing before August:

• Map where your AI requests actually go today, feature by feature.
• Find every path where regulated data can reach a non-EU model, including the ones added "temporarily."
• Decide who owns the written answer to "where does this data live," before an auditor decides for you.
• Put an enforcement point between your app and external models, not just a policy that assumes good behavior.

If you run that honestly and like what you find, good. If you do not, that gap is the thing to close before the date, not after.

How Akumi closes the gap

Akumi is a governed, EU-sovereign AI platform. You send inference to one OpenAI-compatible endpoint for every model, EU-sovereign or external. Residency is enforced at the egress guard, not left to a setting. Personal data is pseudonymized by a firewall that is on by default. And every request produces a residency record you can hand to a reviewer.

In practice that means you change one base_url, keep shipping the AI features you were already building, and get an answer to "where does our data go" that holds up in an audit instead of a shrug. We do not compete on token price. We compete on the answer a DPO needs first.

If that is the question on your desk before August 2, we should talk.

A note from the founder: I am building Akumi because I watched good AI projects stall in legal review, not because the model was wrong, but because nobody could say where the data went. If that is your situation, I would like to hear about it. Jelle, founder, Akumi.