Vertrauen

Sicherheit & Datenschutz

Stand28. Oktober 2026

Die sieben Fragen, die vor einer Entscheidung für Airbuild am häufigsten kommen — hier beantwortet statt verteilt über vier Dokumente. Maßgeblich bleiben die Dokumente selbst; jede Antwort verlinkt auf ihre Quelle.

Wo werden meine Daten gespeichert?

Airbuild speichert Kundendaten in der Europäischen Union, auf AWS in Frankfurt (eu-central-1). Rechenleistung, Datenbanken, Dateispeicher und Projektquellen laufen in dieser Region: ECS, RDS, Aurora, EFS und S3. Statische Dateien liefert das CloudFront-Edge-Netz aus, dessen Origins in eu-central-1 bleiben. Verschlüsselt wird im Ruhezustand mit AES-256 über AWS KMS, auf dem Transportweg mit TLS 1.2 oder höher.

Projekt-Secrets werden zusätzlich auf Anwendungsebene verschlüsselt. Veröffentlichte Seiten laufen auf derselben EU-Infrastruktur, unter ihrer *.airbuild.space-Adresse oder unter einer eigenen Domain, die darauf zeigt.

Außerhalb dieser Region liegt nur, was du selbst dorthin gibst: einzelne KI-Modelle, die du bewusst auswählst. Welche das sind, steht im Modell-Abschnitt weiter unten und in der Liste der Sub-Prozessoren.

Ist Airbuild DSGVO-konform?

Airbuild ist auf die DSGVO ausgelegt: ein österreichisches Unternehmen (Airbuild FlexCo, Wien), Hosting in der EU, ein öffentlicher Auftragsverarbeitungsvertrag nach Art. 28, den jeder Kunde abschließen kann, und eine veröffentlichte Liste der Sub-Prozessoren mit 30 Tagen Vorlauf vor jeder Änderung. Kontodaten lassen sich im Produkt selbst exportieren und löschen. Zertifiziert nach ISO 27001 oder SOC 2 ist Airbuild nicht — die ISMS-Dokumentation liegt im Entwurf vor.

Vor einer Unterschrift lohnt der Blick in den Auftragsverarbeitungsvertrag und in die Liste der Sub-Prozessoren: dort stehen die technischen und organisatorischen Maßnahmen, die Übermittlungsinstrumente und jeder eingesetzte Auftragsverarbeiter. Die Datenschutzerklärung nennt Rechtsgrundlagen und Aufbewahrungsfristen, darunter die sieben Jahre Abrechnungshistorie, die wir nach einer Kontolöschung in anonymisierter Form aufbewahren müssen (§ 132 BAO).

Was wir nicht haben, behaupten wir nicht: Derzeit läuft kein SOC-2-Audit, und ein externer Penetrationstest wurde bislang nicht beauftragt. Abschnitt 11 des Auftragsverarbeitungsvertrags sagt genau das. Sicherheitsfragebögen beantworten wir.

Wem gehören Code und Daten?

Airbuild beansprucht kein Eigentum an deinen Inhalten: Code und Daten gehören dir, auf jedem Plan. Die Nutzungsbedingungen halten fest, dass alle Rechte an deinen Inhalten bei dir bleiben, einschließlich der für dich erzeugten KI-Ausgaben. Generierte Projekte sind gewöhnlicher Quellcode — React, FastAPI, PostgreSQL — keine proprietäre Laufzeitumgebung; die Anwendung läuft damit auch auf eigener Infrastruktur.

Der Weg nach draußen führt über die Airbuild-GitHub-App: eigenes Repository verbinden, und jede Änderung des Agenten wird dorthin committet und gepusht. GitHub ist ab dem Plan Website Builder Pro enthalten — welcher Plan was hat, zeigt der Planvergleich.

Der Datenexport unter Einstellungen → Profil (DSGVO Art. 15 und Art. 20) liefert Profil, Projekte, Login-Historie und Aktivitäten als JSON. Quellcode ist darin nicht enthalten — dafür verbindest du vorher ein Repository.

Eine selbstgehostete oder On-Premises-Ausgabe der Airbuild-Plattform gibt es nicht. Portabel ist die Anwendung, die du damit baust.

Wie wird generierter Code vor dem Livegang geprüft?

Airbuild prüft vor jeder Veröffentlichung automatisch Sicherheit und Qualität — gegen einen eingefrorenen Stand genau des Codes, der live geht. Semgrep sucht unsichere Muster, Trivy prüft Abhängigkeiten auf bekannte CVEs und auf offengelegte Secrets, Ruff und Biome prüfen die Codequalität samt Security-Regelsatz. Befunde hoher Schwere blockieren die Veröffentlichung. Bei Backend-Apps wird zusätzlich jeder Endpunkt ohne Authentifizierung aufgelistet und muss bestätigt werden.

Diese drei Prüfungen sind für jedes Projekt standardmäßig aktiv und lassen sich pro Projekt abschalten. Tiefenanalyse (SonarQube Cloud), API-Vertragsprüfung (Spectral) und ein dynamischer Scan gegen eine Wegwerf-Kopie der laufenden App (OWASP ZAP) werden pro Projekt zugeschaltet; ob die generierte Testsuite als Publish-Gate zählt, ist ebenfalls eine Projekteinstellung.

Ein Gate entscheidet über das, was eine Prüfung meldet — nicht darüber, ob sie überhaupt melden konnte. Startet ein Scanner gar nicht, läuft die Veröffentlichung weiter. Eine durchgelaufene Veröffentlichung heißt also: nichts Blockierendes gemeldet, nicht: alles geprüft. Welche Werkzeuge tatsächlich gelaufen sind, zeigt das Panel „Publish-Prüfungen“. Ausführlich steht das in der Sicherheits-Dokumentation.

Wie geht Airbuild mit der EU-KI-Verordnung um?

Airbuild ist Anbieter des KI-Systems im Sinne der Verordnung (EU) 2024/1689; wer damit eine Anwendung baut und betreibt, ist deren Betreiber, und wer KI-Funktionen an Dritte weitergibt, kann selbst nachgelagerter Anbieter sein. Abschnitt 31 der Nutzungsbedingungen regelt diese Rollenverteilung. Für die Transparenzpflichten nach Art. 50 liefert Airbuild die Kennzeichnung mit — das ist Unterstützung, keine Zertifizierung.

Im Produkt ist KI als KI gekennzeichnet. Jede aus Airbuild veröffentlichte Seite trägt in jeder ausgelieferten HTML-Datei eine maschinenlesbare Markierung — ein Generator-Meta-Tag mit „Airbuild (AI-assisted)“, geschrieben bei jeder Veröffentlichung und unabhängig von den SEO-Einstellungen. KI-generierte Bilder werden mit dem IPTC-Quellentyp „trainedAlgorithmicMedia“ in EXIF und XMP gespeichert.

Die Einstufung des eigenen Anwendungsfalls — verboten, Hochrisiko, begrenztes oder minimales Risiko — bleibt bei dir, und eine KI-Verordnungs-Technikdokumentation für deine Anwendung liefert Airbuild nicht. Nach Art. 5 verbotene Praktiken sind laut Nutzungsrichtlinie ausgeschlossen.

Welche KI-Modelle verarbeiten meine Prompts — und wird damit trainiert?

Airbuild schickt Prompts nur an das Modell, das für das jeweilige Projekt ausgewählt ist. Die Standardrouten laufen in der EU: Claude über Amazon Bedrock, Mistral in Frankreich und die Open-Weight-Modelle (DeepSeek, Kimi K3, Qwen3-Coder, GLM-5.3) über Lyceum in Deutschland. Airbuild nutzt Kundeninhalte nicht für Modelltraining und gibt sie auch nicht zu Trainingszwecken an Modellanbieter weiter.

Modelle von OpenAI und Google stehen ebenfalls zur Wahl, auf Basis der EU-Standardvertragsklauseln; API-Daten nutzt keiner der beiden zum Training seiner Modelle. Ein Claude-Modell, Fable 5, läuft über Bedrocks globales Inferenzprofil und kann außerhalb der EU verarbeitet werden.

Drei Routen sind eine ausdrückliche Opt-in-Ausnahme und werden ohne deine Auswahl nie genutzt: die native DeepSeek-Route, deren Anbieter angibt, Eingaben in China zu verarbeiten und zum Training seiner Modelle zu verwenden; die native Kimi-Route, deren Bedingungen die Nutzung von Inhalten zur Verbesserung des Dienstes erlauben; und die native GLM-Route mit Verarbeitung in Singapur. Jedes dieser Modelle gibt es auch EU-gehostet — das ist die Voreinstellung.

Die Liste der Sub-Prozessoren nennt jeden Anbieter, seinen Verarbeitungsort und sein Übermittlungsinstrument. Sie ist die maßgebliche Quelle, nicht diese Zusammenfassung.

Wie melde ich eine Sicherheitslücke?

Sicherheitslücken meldest du Airbuild an security@airbuild.ai mit genug Detail zum Nachstellen. Airbuild bestätigt die Meldung und arbeitet mit dem Melder an der Behebung. Scans, Penetrationstests oder Lasttests gegen den laufenden Dienst sind nach der Nutzungsrichtlinie nicht erlaubt. Zwei weitere Adressen gibt es: abuse@airbuild.ai für Missbrauch und rechtswidrige Inhalte, legal@airbuild.ai für Urheber- und Markenrecht.

Datenschutzfragen und DSGVO-Anträge gehen an privacy@airbuild.ai. Die Meldung von Datenschutzverletzungen an Kunden regelt Abschnitt 10 des Auftragsverarbeitungsvertrag.

Die Dokumente dahinter