Security & Data Protection
UpdatedOctober 28, 2026
The seven questions we get asked most often before a team adopts Airbuild, each answered here instead of across four documents. The documents themselves stay authoritative, and every answer links to the one it comes from.
Where is my data stored?
Airbuild stores customer data in the European Union, on AWS in Frankfurt (eu-central-1). Compute, databases, file storage and project sources all run in that region: ECS, RDS, Aurora, EFS and S3. Static assets are delivered 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 at their *.airbuild.space address, or at a custom domain you point at it.
One thing sits outside that region, and only if you put it there: a small number of AI models you can select yourself. Those routes are named in the model section below and in the sub-processor list.
Is Airbuild GDPR compliant?
Airbuild is built for the GDPR: an Austrian company (Airbuild FlexCo, Vienna), hosting in the EU, a public Art. 28 data processing agreement every customer can accept, and a published sub-processor list with 30 days of notice before any change. You can export or delete your account data yourself in the product. Airbuild holds no ISO 27001 or SOC 2 certificate — the ISMS documentation exists in draft.
Read the Data Processing Agreement and the sub-processor list before you sign anything: they name the technical and organisational measures, the transfer instruments and every processor we use. The privacy policy sets out the legal bases and the retention periods, including the seven years of billing records Austrian tax law requires us to keep in anonymised form after an account is deleted.
What we do not have, we do not claim: 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. We do answer security questionnaires.
Who owns the code and the data?
You own the code and the data, on every Airbuild plan. The Terms of Service state that you keep all rights to your content, including the AI output generated for you, and that Airbuild claims no ownership. Generated projects are ordinary source code — React, FastAPI, PostgreSQL — not a proprietary runtime, so an application can run on your own infrastructure.
Getting the code out runs through the Airbuild GitHub App: connect your own repository and every change the agent makes is committed and pushed there. GitHub is included from the Website Builder Pro plan upwards — the plan comparison shows which plans have it.
The personal-data export under Settings → Profile (GDPR Art. 15 and Art. 20) covers your profile, projects, login history and activity as JSON. It does not contain your source code — connect a repository if you want to keep that.
There is no self-hosted or on-premises edition of the Airbuild platform itself. What is portable is the application you build with it.
How is generated code checked before it goes live?
Every Airbuild publish runs an automated security and quality gate against a frozen snapshot of exactly the code that ships. Semgrep looks for insecure patterns, Trivy scans dependencies for known CVEs and for leaked secrets, and Ruff and Biome check code quality including a security ruleset. High-severity findings block the publish. Backend apps also list every endpoint reachable without authentication for confirmation.
Those three checks are on by default for every project and can be switched off per project. Deep quality analysis (SonarQube Cloud), API contract linting (Spectral) and a dynamic scan against a throwaway copy of the running app (OWASP ZAP) are switched on per project; using the generated test suite as a publish gate is a per-project switch too.
A gate acts on what a check reports, not on whether the check managed to report. If a scanner cannot start at all, the publish proceeds rather than being refused, so a publish that went through means nothing blocking was reported — not that every check completed. The Publish checks panel lists the tools that actually ran. The full description is in the security documentation.
How does Airbuild handle the EU AI Act?
Airbuild is the provider of the AI system under Regulation (EU) 2024/1689, and you are the deployer of whatever you build with it; if you make AI features available to others, you may be a downstream provider yourself. Section 31 of the Terms sets that split out in full. Airbuild supports the Article 50 transparency duties with labelling — that is support, not a certification.
In the product, AI interactions are labelled as AI. Every site published from Airbuild carries a machine-readable marker in every HTML file it ships — a generator meta tag reading "Airbuild (AI-assisted)", written on every publish and independent of the SEO settings. AI-generated images are saved with the IPTC digital source type "trainedAlgorithmicMedia" in their EXIF and XMP metadata.
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 AI models process my prompts, and are they used for training?
Airbuild sends your prompts only to the model selected for that project. The default routes run in the EU: Claude through Amazon Bedrock, Mistral in France, and the open-weight models (DeepSeek, Kimi K3, Qwen3-Coder, GLM-5.3) through Lyceum in Germany. Airbuild does not use your content to train models and does not pass it to any model provider for training.
OpenAI and Google models are available too, under Standard Contractual Clauses; 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.
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 models is also available EU-hosted, which is the default.
The sub-processor list names every provider, its processing location and its transfer instrument, and it is the authoritative source — not this summary.
How do I report a security issue?
Report a security issue to Airbuild at security@airbuild.ai and give enough detail to reproduce it. Airbuild acknowledges the report and works with the reporter on a fix. Please do not run scans, penetration tests or load tests against the live service — the Acceptable Use Policy does not permit it. Two other addresses exist: abuse@airbuild.ai for illegal content and abuse, legal@airbuild.ai for copyright and trademark.
Data-protection questions and GDPR requests go to privacy@airbuild.ai. Breach notification towards customers is governed by section 10 of the Data Processing Agreement.
The documents behind this
- Data Processing Agreement
- Sub-processors — provider, location, transfer instrument
- Privacy Policy
- Terms of Service — section 7 (ownership, no training), section 31 (AI Act)
- Acceptable Use Policy
- Security documentation — platform, secrets, published sites
- Blog — EU data residency in AI development
- Blog — The EU AI Act for software teams