What EU data residency really means for AI development

When your team builds with an AI platform, three kinds of data flow through it: your code and prompts, your business documents (specs, screenshots, uploads), and — once the app is live — your customers’ data. For a European company, where each of these is processed and stored is not a detail; it decides whether your own GDPR story holds.

The questions to ask any AI development vendor

• Where does the generated application run — which region hosts the app, its database and its files?
• Where do my prompts, documents and code live at rest?
• Is the vendor itself the processor, and does it offer a DPA and a public list of sub-processors?
• Can I take the code and run it on my own infrastructure if requirements change?

How Airbuild answers them

Airbuild is built in Vienna and hosted in the EU: your projects, chat history and uploads sit encrypted at rest in AWS Frankfurt (eu-central-1), and the applications you publish run there too — backend, database and files. Delivery is the one part that is deliberately not EU-only: published sites go out through CloudFront, a global content delivery network, so a visitor’s request reaches the nearest edge location — which may be outside the EU — before it is answered from Frankfurt, and the public files of your app (pages, scripts, images) are cached at that edge. What is stored stays in Frankfurt: the database, the uploaded and generated files, the project sources. And the DPA and a public sub-processor list come with the product rather than on request.

The harder half of the question is where the model runs. By default Claude runs on Amazon Bedrock’s EU inference profiles, pinned in code and asserted by a test, so a non-EU profile cannot slip in unnoticed. The open-weight models — DeepSeek, Kimi K3, Qwen3-Coder and GLM-5.3 — run on Lyceum’s infrastructure inside the EU, so picking one of those keeps the request in the EU too. What can still leave the EU is written down rather than implied, and every provider involved is named on our sub-processor page: Claude Fable 5, for which no EU profile exists yet, runs on Bedrock’s global profile, so the request and the copy Bedrock retains can be processed outside the EU; a technical fallback can route requests directly to Anthropic in the US; a model you select from a non-EU provider is processed where that provider sits, which today means OpenAI in the US; and AI image generation runs on Google’s Gemini API (European Union and United States), whichever chat model you picked. The same open-weight models are also offered natively, straight from their original provider. For DeepSeek, Kimi and GLM those routes run outside the EU under that provider’s own terms, which is why nothing goes to them unless someone picks that route deliberately; Qwen’s native route runs on Alibaba’s Frankfurt endpoint and stays in the EU. For every other provider, no training on your content is part of our terms. An organization admin can also limit which models a team may use at all.

And because everything Airbuild generates is standard, exportable code, the residency question has a final backstop: if your requirements ever demand it, you can take the application — frontend, backend, database schema — and run it on infrastructure you control. Data residency you can exit is the only kind worth relying on.