· Explainer

EU data residency and the EU AI Act for software built with AI

By Airbuild · Published 7 November 2026 · Last reviewed 7 November 2026

EU data residency for AI-built software means your source code, your prompts and your customers’ data are processed and stored inside the European Union — and that you can name every processor that touches them, including the AI models.

Two separate bodies of law apply to anyone building software with AI in Europe: the GDPR, which has governed personal data since 2018, and the AI Act (Regulation (EU) 2024/1689), whose main obligations have applied since 2 August 2026. This page sets out what each one requires, what Airbuild does about it, and — the part that decides whether you are compliant — what remains your job. It is not legal advice.

· Who answers for what

Role under the AI Act

AirbuildAirbuild is the provider of the AI system (Regulation (EU) 2024/1689).
YouYou are the deployer of what you build — and a downstream provider yourself if you ship AI features to others.

Risk classification

AirbuildAirbuild classifies its own system and keeps prohibited practices out via the Acceptable Use Policy.
YouClassifying your application — prohibited, high-risk, limited or minimal — is yours. Airbuild supplies no AI Act technical documentation for it.

Article 50 labelling

AirbuildEvery published site ships a machine-readable marker; AI images carry IPTC provenance metadata.
YouDeciding whether your use case needs visible disclosure to your users, and writing it.

Data protection

AirbuildProcessor under Art. 28 GDPR: EU hosting, a public DPA, a sub-processor list with 30 days of notice.
YouController: legal basis, information duties, retention, and the privacy policy of the app you publish.
The split that matters: Airbuild is the provider of the AI system and a processor of your data. Almost everything that depends on what your software actually does stays with you.

What does EU data residency actually mean?

EU data residency means the data is processed and stored in the European Union — but the phrase is weaker than it sounds, because residency alone says nothing about who can reach the data or where its sub-processors sit. A platform can host in Frankfurt and still route your prompts to a model that runs elsewhere, and that routing is a transfer under Chapter V of the GDPR whether or not the marketing page mentions it.

The question worth asking a vendor is therefore not "do you host in the EU" but "can you name every processor and its location". Article 28(2) of the GDPR requires a processor to have written authorisation before engaging another processor, and Article 30 requires a record of processing activities. A vendor that cannot produce a sub-processor list cannot support either duty, regardless of where its servers are.

For AI builders there is a second layer: the model. Your prompts are the most revealing thing you send a code generator — they describe the business logic you are about to build. Where they are processed, and whether they are retained for training, is a separate question from where the database lives.

Where does Airbuild process and store data?

Airbuild stores customer data in the European Union, on AWS in Frankfurt — the region AWS calls eu-central-1. Compute, databases, file storage and project sources all run in that region: ECS, RDS, Aurora, EFS and S3. Static assets go out over the CloudFront edge network, whose origins stay in eu-central-1. Data is encrypted at rest with AES-256 via AWS KMS and in transit with TLS 1.2 or higher; project secrets are encrypted a second time at the application layer.

Published sites are served from the same EU infrastructure, whether they run at their airbuild.space address or at a custom domain pointed at it. The company behind all of this is Austrian — Airbuild FlexCo, Vienna — which matters for jurisdiction: your processor is established in the Union, not represented in it.

One category sits outside that region, and only if you put it there: a small number of AI models you select yourself. Those are named in the next section and in the sub-processor list, which is the authoritative version of everything on this page.

Which AI models see your prompts, and where do they run?

Airbuild sends your prompts only to the model selected for that project, and the default routes run in the EU: Claude through Amazon Bedrock, Mistral in France, and the open-weight models — DeepSeek, Kimi K3, Qwen3-Coder and GLM-5.3 — through Lyceum in Germany. Choosing nothing therefore keeps your prompts in the Union.

OpenAI and Google models are available as well, under Standard Contractual Clauses as provided for in Article 46(2)(c) GDPR; neither provider uses API data to train its models. One Claude model, Fable 5, runs on Bedrock’s global inference profile and may be processed outside the EU — that is a property of the model, not of your settings, so it is named rather than buried.

Three routes are an explicit opt-in exception and nothing reaches them unless you pick them: the native DeepSeek route, whose provider states that inputs are processed in China and used to train its models; the native Kimi route, whose terms permit using content to improve the service; and the native GLM route, processed in Singapore. Each of those three models is also available EU-hosted, and the EU-hosted version is the default.

Does Airbuild train on your code?

No. Airbuild does not use your content to train models and does not pass it to any model provider for training. Section 7 of the Terms states it, and the default model routes are chosen so that the providers behind them do not train on API data either.

The exception is the one named above and it is yours to make: if you deliberately select the native DeepSeek or native Kimi route, you are choosing a provider whose own terms permit using the content. Nothing routes there by itself. This is the shape a training policy should have — a default that protects you, an exception you have to reach for, and both written down where you can check them.

Worth noting what this does not cover: your own application’s data. If you build a product that sends customer data to a model, that is your processing and your disclosure duty, and the policy above does not reach it.

Who is the provider and who is the deployer under the EU AI Act?

Under the AI Act, Airbuild is the provider of the AI system and you are the deployer of whatever you build with it — and if you make AI features available to others, you may be a downstream provider yourself. Section 31 of the Terms sets the split out in full. The distinction is not bookkeeping: most of the Act’s duties attach to what a system is used for, and the person who decides that is the deployer.

In practice this means Airbuild answers for the builder and you answer for the application. Classifying your own use case — prohibited, high-risk, limited or minimal risk — stays with you, and Airbuild does not supply AI Act technical documentation for the application you build. Practices prohibited under Article 5 are out of bounds under the Acceptable Use Policy, which have applied since 2 February 2025.

If a vendor tells you their platform makes you AI Act compliant, that claim cannot be true for a general-purpose builder. What a platform can do is support your duties and not get in the way of them.

Which AI Act dates actually apply?

The dates have moved, so the ones worth memorising are fewer than the internet suggests. Article 5 prohibitions and the AI literacy duty have applied since 2 February 2025. Most of the rest, including the Article 50 transparency obligations, applies since 2 August 2026. The high-risk obligations were postponed by the Digital Omnibus on AI, Regulation (EU) 2026/1744, which entered into force on 27 July 2026 and moved them to 2 December 2027 for stand-alone high-risk systems and 2 August 2028 for systems embedded in products — see the Council’s own timeline.

One date is close enough to act on. Generative systems that were already on the market before 2 August 2026 have until 2 December 2026 to meet the machine-readable marking requirement of Article 50(2). If you publish AI-generated content in the Union and your system predates that cut-off, that deadline is weeks away, not years.

Treat any date you read — including these — as needing a check against the Official Journal before you rely on it. The Omnibus amendment is recent and secondary sources disagree on its details.

What does Airbuild do about the Article 50 labelling duty?

Airbuild supports the Article 50 transparency duties with labelling, and that is support rather than a certification. In the product, AI interactions are labelled as AI. Every site published from Airbuild ships a machine-readable marker in every HTML file: a generator meta tag reading "Airbuild (AI-assisted)", written on every publish and independent of your SEO settings. AI-generated images are saved with the IPTC digital source type "trainedAlgorithmicMedia" in their EXIF and XMP metadata.

That is the mechanism Article 50(2) asks for — a mark in the artefact that a machine can read, rather than a sentence on a page that a screenshot removes. Because it is written on every publish and cannot be switched off with the SEO settings, it does not depend on anyone remembering it.

What it does not do is decide for you whether your users need to be told, in words, that they are looking at AI-generated content. That judgement depends on your use case and sits with the deployer. The marker is the machine-readable half of the duty; the human-readable half is yours to write.

What does Airbuild not have?

Airbuild holds no ISO 27001 and no SOC 2 certificate. The ISMS documentation exists in draft, no SOC 2 audit is in progress, and no external penetration test has been commissioned to date. Section 11 of the DPA states this in the same words, which is the point: a claim you can only find in the contract is worth less than one you can find before signing it.

This matters for your own evaluation. If your procurement requires a certificate, Airbuild does not have one today and no amount of EU hosting substitutes for it. If your procurement requires a processor agreement, a named sub-processor list and a documented transfer basis, those exist and are public.

Security questionnaires do get answered. A vendor that tells you what it does not have is giving you the more useful half of the answer.

What is still your job?

Four things stay with you no matter how the platform is built. You are the controller for the personal data your application processes, which means the legal basis, the information duties and the retention periods are yours. You classify your own AI use case under the Act. You decide whether your users need a visible disclosure. And you write the privacy policy, imprint and cookie notice of the site you publish.

Airbuild gives you the inputs for all four: a public Art. 28 processing agreement, a sub-processor list with 30 days of notice before any change, a privacy policy naming the legal bases and retention periods — including the seven years of billing records Austrian tax law requires, kept in anonymised form after an account is deleted — and self-serve export and deletion in the product.

The honest summary: EU residency and a named processor chain remove the questions you cannot answer yourself. They do not remove the ones only you can answer, because only you know what your software does.

The documents behind this

Check it yourself

The sub-processor list names every provider, its location and its transfer instrument. Read that before you read any marketing page, including this one.