Wie wir mit Ihren Daten umgehen
Eine allgemein verständliche Beschreibung der Sicherheitsarchitektur, Datenresidenz und KI-Herkunft hinter Carlen.ai — so geschrieben, dass sie überprüft und nicht nur geglaubt werden kann.
Sicherheitsarchitektur
Jede Organisation bei Carlen.ai ist auf Datenbankebene isoliert — nicht nur im Anwendungscode.
Row-Level-Security pro Organisation
Jede Tabelle (Models, Produkte, Sessions, Generierungen, Budgets, Audit-Log …) ist über Postgres Row-Level-Security-Policies auf die jeweilige Organisation beschränkt — eine Organisation kann keine Zeilen einer anderen Organisation lesen oder schreiben. Das erzwingt die Datenbank selbst, nicht nur eine Prüfung in der Anwendungsschicht.
Verschlüsselte Verbindungs-Zugangsdaten
Shop- und API-Zugangsdaten (z. B. Ihre WooCommerce- oder Shopware-Schlüssel) werden mit AES-256-GCM verschlüsselt, bevor sie in die Datenbank geschrieben werden. Geheimnisse werden nie im Klartext gespeichert.
Rollenbasierte Zugriffskontrolle (RBAC)
Jede schreibende Aktion in der Anwendung wird durch eine explizite Berechtigungsprüfung gegen die Rolle des Aufrufers in dieser Organisation abgesichert — siehe Rollenliste unten.
Eigene Infrastruktur für Kerndaten
Datenbank, Authentifizierung und Dateispeicher laufen auf unserer eigenen Infrastruktur (Open-Source-Stack Postgres/GoTrue/Storage), nicht bei einem Drittanbieter-Managed-Database-Dienst — Ihre Daten liegen standardmäßig nicht in einer fremden Multi-Tenant-Cloud-Datenbank.
Rollen
Datenresidenz
Wir sind transparent darüber, was bei uns bleibt und was an einen spezialisierten Dritten geht — und warum.
- Die primäre Bereitstellung ist ein einzelner, selbst gehosteter Stack (Datenbank, Auth, Objektspeicher) statt eines geteilten Multi-Region-Cloud-Dienstes — der Betreiber wählt den Standort. Unser eigenes Deployment-Runbook empfiehlt EU-Hosting-Anbieter (Hetzner, Deutschland; OVH, Frankreich).
- Datenbank-Backups werden 30 Tage lokal und bis zu 180 Tage extern (off-site) aufbewahrt, gemäß unserer internen Backup-Richtlinie.
- Eine kleine Zahl konkreter Funktionen wird an spezialisierte Subauftragsverarbeiter ausgelagert statt intern von Grund auf gebaut — die Liste unten zeigt genau, wer was bekommt und warum.
Subauftragsverarbeiter
Wir erzählen keine "null Drittanbieter"-Geschichte — hier steht genau, wer worauf Zugriff hat und warum.
| Anbieter | Zweck | Betroffene Daten | Region |
|---|---|---|---|
| fal.ai | Primäre KI-Bild- und Videogenerierung (Inferenz + LoRA-Training) | Hochgeladene Produkt-/Model-Referenzfotos, generierte Ergebnisse | USA |
| Black Forest Labs | Sekundäre/Failover-KI-Bildinferenz (Absicherung gegen Anbieterrisiko) | Wie bei fal.ai, nur auf dem Ausweichpfad | Deutschland (EU, Sitz) |
| Anthropic | LLM: Generierung von Marketingtexten und automatisierter Qualitäts-"Richter" | Produktdaten, Prompts, generierter Text | USA |
| Resend | Zustellung von Transaktions- und Kampagnen-E-Mails | E-Mail-Adresse des Empfängers, E-Mail-Inhalt | USA |
| Inngest | Orchestrierung von Hintergrundjobs (Training, Videogenerierung, wiederkehrende Jobs wie DSGVO-Anonymisierung) | Job-Metadaten (IDs, Referenzen) — keine rohen Bilddateien | USA |
| Slack (optional) | Interne Betriebsbenachrichtigungen, nur wenn der Betreiber einen Webhook konfiguriert | Alert-Metadaten — keine Kundenbilder | USA |
| PostHog | Produktanalyse — geplant, noch nicht integriert | — | EU-Hosting-Option in Prüfung |
Die Region entspricht dem öffentlich dokumentierten Hauptsitz/der primären Infrastruktur des jeweiligen Anbieters. Jeder dieser Anbieter ist ein echter Subauftragsverarbeiter im Rahmen eines Auftragsverarbeitungsvertrags — kontaktieren Sie uns für aktuelle DPA/SCC-Dokumentation.
Ihre eigene Shop-Plattform (WooCommerce, Shopware, Shopify, PrestaShop, Shoper …) ist kein Subauftragsverarbeiter von uns — wir rufen nur deren API auf, mit den von Ihnen bereitgestellten Zugangsdaten, um die von Ihnen generierten Fotos zu veröffentlichen. Sie bleibt Ihr System.
Wie unsere KI funktioniert
Compliance von Anfang an: was generiert wird, worauf wir trainiert haben und wie es gekennzeichnet wird.
Basismodelle sind KI von Drittanbietern (GPAI)
Die zugrunde liegenden Bild- und Video-Modelle (z. B. FLUX.1 sowie Video-Engines von Anbietern wie ByteDance) werden von ihren jeweiligen Herstellern entwickelt und gepflegt. Nach dem EU AI Act liegen GPAI-Pflichten wie die Urheberrechts-Policy nach Art. 53 und die Zusammenfassung der Trainingsdaten bei diesen vorgelagerten Anbietern, nicht bei uns.
Unser Fine-Tuning nutzt ausschließlich eigene, lizenzierte Fotos
Wir trainieren kleine LoRA-Adapter pro Model, ausschließlich anhand von Fotografien, an denen wir die Rechte besitzen und die im Rahmen eines dokumentierten Einwilligungsprozesses für dieses konkrete Model entstanden sind. Kein Scraping von Bildern Dritter, niemals. Der Trainings-Compute für ein einzelnes Model ist gering — ein einzelner Trainingsjob auf unserem verwalteten Trainer läuft typischerweise 10–30 Minuten auf einer einzelnen GPU-Instanz — weit unter der Compute-Schwelle (mehr als ein Drittel des Trainings-Compute eines Basismodells, wobei die Schwelle selbst bei über 3×10²¹ FLOP liegt), ab der der EU AI Act einen Fine-Tuner als eigenständigen GPAI-Anbieter einstufen würde. Wir sind ein nachgelagerter Deployer von Drittanbieter-Modellen, kein GPAI-Anbieter.
Jedes Ergebnis ist gekennzeichnet
Generierte Fotos tragen IPTC-Digital-Source-Type-Metadaten, einen kryptografischen C2PA-Content-Credential sowie ein unsichtbares Wasserzeichen im Pixelbereich (TrustMark), das Größenänderung, erneute Kompression und Zuschnitt übersteht — das deckt Fälle ab, in denen Metadaten von einer nachgelagerten Plattform entfernt werden. Das ist das vollständige Paar an Mechanismen, das der Code of Practice der EU zur KI-Kennzeichnung vorsieht. Ein technischer Hinweis: Wasserzeichen und C2PA-Signierung stützen sich auf ein natives Rust-Binärmodul — das veröffentlichte Upstream-Paket enthält nur einen macOS-Build, daher kompilieren wir es aus dem Quellcode (fixiert auf einen verifizierten Upstream-Commit) beim Bau des Produktions-Docker-Images, und wir haben einen vollständigen Signier-und-Lese-Durchlauf sowie den TrustMark-Aufruf innerhalb genau dieses Images auf linux/amd64 und linux/arm64 verifiziert. Sollte diese Schicht bei einem Deployment je nicht verfügbar sein, schaltet sie sich sicher ab, statt die Generierung zu unterbrechen, und die IPTC-Metadatenschicht erfüllt die Grundanforderung weiterhin allein. Generierte Videos tragen dieselbe C2PA-Signierung; ein unsichtbares Wasserzeichen für Video ist eine offen benannte Lücke (keine Anbieterlösung deckt heute Video ab).
Penetrationstests
Wir verpflichten uns zu einem jährlichen Penetrationstest durch Dritte, während wir in Richtung Enterprise-Kunden wachsen. Zum Zeitpunkt der Veröffentlichung wurde unser erster externer Pentest noch nicht durchgeführt — das ist eine Zusage für die Zukunft, keine Aussage über einen abgeschlossenen Auftrag.
Wir sind heute nicht ISO-27001-zertifiziert. Eine formale Zertifizierung ist auf unserer Roadmap, sobald wir Enterprise-Größenordnung erreichen — nicht etwas, das wir bereits behaupten zu besitzen.
Support
Wir streben an, jede Support-Anfrage innerhalb von 24 Stunden an Werktagen zu beantworten — auf Polnisch oder Englisch. Support ist über den In-App-Chat im Dashboard sowie per E-Mail erreichbar.
Live-Status
Verfügbarkeit und Vorfallshistorie von App und API werden auf unserer öffentlichen Statusseite veröffentlicht, die automatisch aktualisiert wird.
status.carlen.aiSicherheitskontakt
Eine Schwachstelle gefunden, benötigen Sie unseren Auftragsverarbeitungsvertrag (AVV/DPA), oder haben Sie eine Sicherheitsfrage für Ihre eigene Compliance-Prüfung? Kontaktieren Sie uns direkt.
security@carlen.aiEin Standard-Auftragsverarbeitungsvertrag (DSGVO Art. 28) sowie unser Dokument zu technischen und organisatorischen Maßnahmen (TOMs) sind auf Anfrage erhältlich.