Was EU-Datenresidenz bei KI-Entwicklung wirklich bedeutet
„DSGVO-konform" auf einer Pricing-Seite und echte EU-Datenresidenz sind zwei verschiedene Dinge. Worauf du achten solltest, wenn du Software mit KI baust — und wie Airbuild jede Frage beantwortet.
Wenn dein Team mit einer KI-Plattform baut, fließen drei Arten von Daten durch sie: dein Code und deine Prompts, deine Geschäftsdokumente (Specs, Screenshots, Uploads) und — sobald die App live ist — die Daten deiner Kunden. Für ein europäisches Unternehmen ist es kein Detail, wo diese verarbeitet und gespeichert werden; es entscheidet, ob deine eigene DSGVO-Story trägt.
Die Fragen an jeden KI-Entwicklungsanbieter
- Wo läuft die generierte Anwendung — welche Region hostet App, Datenbank und Dateien?
- Wo liegen meine Prompts, Dokumente und mein Code at rest?
- Ist der Anbieter selbst Auftragsverarbeiter, und gibt es einen AV-Vertrag und eine öffentliche Sub-Prozessoren-Liste?
- Kann ich den Code nehmen und auf eigener Infrastruktur betreiben, wenn sich die Anforderungen ändern?
Wie Airbuild sie beantwortet
Airbuild ist in Wien gebaut und in der EU gehostet: Deine Projekte, der Chat-Verlauf und deine Uploads liegen at rest verschlüsselt in AWS Frankfurt (eu-central-1), und die Anwendungen, die du veröffentlichst, laufen ebenfalls dort — Backend, Datenbank und Dateien. Bewusst nicht EU-only ist allein die Auslieferung: Veröffentlichte Seiten werden über CloudFront ausgeliefert, ein globales Content Delivery Network. Eine Anfrage erreicht also zuerst den nächstgelegenen Edge-Standort — der auch außerhalb der EU liegen kann —, bevor sie aus Frankfurt beantwortet wird, und die öffentlichen Dateien deiner App (Seiten, Skripte, Bilder) werden an diesem Edge zwischengespeichert. Was gespeichert wird, bleibt in Frankfurt: die Datenbank, die hochgeladenen und generierten Dateien, die Projektquellen. Und AV-Vertrag sowie öffentliche Sub-Prozessoren-Liste gehören zum Produkt, statt erst auf Anfrage zu kommen.
Die schwierigere Hälfte der Frage ist, wo das Modell läuft. Standardmäßig läuft Claude über die EU-Inferenzprofile von Amazon Bedrock, im Code fixiert und durch einen Test abgesichert, damit kein Nicht-EU-Profil unbemerkt hineinrutscht. Die Open-Weight-Modelle — DeepSeek, Kimi K3, Qwen3-Coder und GLM-5.3 — laufen auf der Infrastruktur von Lyceum innerhalb der EU; wer eines davon wählt, bleibt damit ebenfalls in der EU. Was die EU trotzdem verlassen kann, steht geschrieben statt nur angedeutet, und jeder beteiligte Anbieter ist in unserer Sub-Prozessoren-Liste benannt: Claude Fable 5, für das es noch kein EU-Profil gibt, läuft über Bedrocks globales Profil, sodass die Anfrage und die von Bedrock vorgehaltene Kopie außerhalb der EU verarbeitet werden können; ein technischer Fallback kann Anfragen direkt an Anthropic in die USA leiten; ein Modell eines Nicht-EU-Anbieters wird dort verarbeitet, wo dieser Anbieter sitzt — heute betrifft das OpenAI in den USA; und die KI-Bildgenerierung läuft über Googles Gemini-API (Europäische Union und Vereinigte Staaten), unabhängig vom gewählten Chat-Modell. Dieselben Open-Weight-Modelle bieten wir zusätzlich nativ an, direkt beim ursprünglichen Anbieter. Bei DeepSeek, Kimi und GLM laufen diese Routen außerhalb der EU zu den Bedingungen des jeweiligen Anbieters, weshalb dorthin nichts geht, solange sie niemand bewusst auswählt; die native Qwen-Route läuft über Alibabas Frankfurter Endpunkt und bleibt in der EU. Bei allen anderen Anbietern ist das Nicht-Training mit deinen Inhalten Teil unserer AGB. Organisations-Admins können zusätzlich einschränken, welche Modelle ein Team überhaupt nutzen darf.
Und weil alles, was Airbuild generiert, standardmäßiger, exportierbarer Code ist, hat die Residenz-Frage einen letzten Rückhalt: Wenn deine Anforderungen es je verlangen, nimmst du die Anwendung — Frontend, Backend, Datenbankschema — und betreibst sie auf Infrastruktur, die du kontrollierst. Nur Datenresidenz, aus der man aussteigen kann, ist verlässliche Datenresidenz.