Three Questions That Decide If Your AI Is Provable in the EU

An auditor or regulator rarely asks, “do you have EU residency?” The question is “show me.” The difference between being right and being able to prove it is the whole difference in an audit – and it’s testable in advance. Three check questions are enough to see whether your AI use holds up. They’re also free to ask in advance – and very expensive to get as a surprise.

Question 1: Is the whole flow provable in the EU?

Not “does the vendor promise EU?” but: can you show in writing where storage, transit, and inference happen – for the exact SKU, tier, and model you’re running?

Most residency promises cover storage but not inference – the actual model run. And product-level promises say nothing about your configuration: the same service can process data in the EU or the US depending on deployment type, tenant age, and model version. The proof is a dated written statement per configuration, not a screenshot from a marketing page.

The test: ask whoever owns the solution to produce the statement within one business day. If it doesn’t exist, the answer to question 1 is no – no matter how good the procurement felt. Also write into the contract that the statement must be updated when things change – proof with a best-before date beats one that’s quietly gone stale.

Question 2: What’s your defensible transfer mechanism?

Sooner or later the question lands: what happens the day a US government request hits your vendor? Then you need to point to a working transfer mechanism – depending on the vendor path, usually DPF participation or Standard Contractual Clauses supplemented with your own TIA.

That the question isn’t theoretical was shown by Microsoft France, which under oath before the French Senate couldn’t guarantee that data is never handed over to US authorities. That testimony is a useful risk reference in your TIA: even vendors with strong EU commitments are ultimately subject to US law. Your mechanism has to hold up even in that scenario – with mitigations like customer-controlled keys and a documented residual risk.

Also rehearse the scenario before it happens: who in the organization fields the question, which documents get pulled, and who contacts the vendor? An hour-long tabletop exercise quickly shows whether the mechanism is a document or a capability.

Question 3: Can you draw the complete subprocessor and retention map?

Put a critical reviewer in front of a whiteboard and draw the flow: every party that touches your data, in which region, with what retention. If the map survives the follow-up questions, you’re in good shape. It usually breaks down in three places:

• Multi-model routing – assistants that select a model per call, where each model is its own subprocessor with its own terms.
• Hyperscaler dependencies – the lab’s model runs on a cloud whose surrounding services have their own regions and flows.
• Mandatory retention on frontier models – the newest models can have logging that can’t be contracted away, with different terms than the vendor’s GA lineup.

A concrete example: an organization runs an assistant that routes simple questions to a cheap model and hard ones to a frontier model. The map turns out to have two completely different retention paths – one with zero data retention, the other with mandatory logging. Without the map, both would have been described as “the same tool.” Draw the map before the vendor draws it for you – whoever holds the pen picks the level of detail, and the gaps show up in the details.

The answers belong in the DPIA and contract annexes

The three answers shouldn’t live in email threads or inside an architect’s head. They belong in your DPIA and in the contract annexes – dated and versioned, so you can show what you knew and decided at every point in time. At every model upgrade or subprocessor change, the documents get updated and a new date. The version history has its own evidentiary value: it shows the governance has lived over time and wasn’t written up the week before the audit.

That’s the whole method: three questions, written answers, living documents. An AI initiative that passes them isn’t just more lawful – it’s also easier to build on, since every new use case inherits a map that already checks out. Want to stress-test your own map ahead of an important decision? Get in touch – at Weapp we build AI solutions where provability is part of the delivery.