Dateneigentum bei Agentur-Software: So bewertest du es
Dateneigentum heißt fünf Fragen vor dem Kauf: Wo liegen aktive Daten, wer hält die Schlüssel, welche Rechtsordnung gilt, was passiert beim Ausstieg, kann der Anbieter still zugreifen? Die meisten antworten mit Policy, nicht Architektur. Nutze diese als Bestanden/Nicht-bestanden-Kriterien — damit du weißt, ob Kundendaten dir gehören oder geliehen sind.
Bevor du einen Vertrag für Agentur-Software unterschreibst, frag wo deine Daten liegen, wer darauf zugreifen kann und was du bekommst, wenn der Anbieter verschwindet. Die meisten Evaluierungen decken Features, Preis und Integrationen ab. Wenige decken Eigentum ab — weil Anbieter gut darin sind zu sagen “deine Daten gehören dir”, während sie sie architektonisch in einer zentralen Datenbank halten, die nur sie kontrollieren.
Dieser Beitrag gibt dir eine Fünf-Fragen-Checkliste, die Marketing in Bestanden/Nicht-bestanden-Kriterien verwandelt — damit du weißt, was du wirklich kaufst.
Warum Eigentum für Agenturen mehr zählt
Ein Händler, der den Zugang zu Bestandsdaten verliert, hat Schmerz. Eine Agentur, die den Zugang zu Kundendaten verliert, hat es existenziell — weil die Daten nicht nur operativ sind, sondern die Beziehungshistorie, die deine Kunden dir anvertrauen.
Agenturen halten:
- Kundenkontaktdaten und Kommunikationshistorie
- Verträge, Briefs und genehmigte Deliverables
- Finanzdaten — Rechnungen, Sätze, Zahlungshistorie
- Projektzeitpläne, Entscheidungen und Freigaben
- Manchmal Zugangsdaten, Brand Assets und unveröffentlichte Arbeit
Ist irgendetwas davon in Anbieter-Infrastruktur ohne unabhängigen Zugangspfad eingesperrt, besitzt du es in keinem praktischen Sinn. Du mietest es.
Die Fünf-Fragen-Checkliste
1. Wo liegt die aktive Datenbank?
Das ist die wichtigste Frage — und die, die Anbieter am ungernsten präzise beantworten.
| Antwort die du hörst | Was es wirklich bedeutet | Bestanden? |
|---|---|---|
| “Wir hosten auf AWS in eu-west-1” | Ihre Datenbank, ihr Konto, ihre Server | ⚠️ Nur Residenz |
| “Deine Daten werden sicher in unserer Cloud gespeichert” | Zentrale Multi-Tenant-Datenbank, geteilte Infrastruktur | ❌ |
| “Wir nutzen SOC-2-zertifiziertes Hosting” | Compliance über den Host, nicht über deinen Zugang | ⚠️ |
| “Eine dedizierte Datenbank wird auf deinem Cloud-Konto provisioniert” | Deine Datenbank, dein Konto, deine Region | ✅ |
Was du fragen solltest: “Liegt die Produktionsdatenbank auf eurem Cloud-Konto oder auf meinem?”
Ist die Antwort deren, hast du bestenfalls Residenz — kein Eigentum. Deine Daten sind ein Mieter in ihrem Gebäude. Sie halten die Schlüssel zur Haustür.
sSystm provisioniert eine dedizierte D1-Datenbank auf deinem Cloudflare-Konto bei der Anmeldung. Die Antwort auf Frage eins ist verifizierbar: du siehst die Datenbank in deinem eigenen Cloudflare-Dashboard.
2. Wer hält die Verschlüsselungsschlüssel?
Verschlüsselung ist bedeutungslos, wenn nur der Anbieter entschlüsseln kann.
Was du fragen solltest: “Kann ich die Datenbank direkt mit eigenen Zugangsdaten erreichen, unabhängig von eurer Plattform?”
- Wenn ja: du kannst verifizieren, sichern und abfragen ohne um Erlaubnis zu bitten
- Wenn nein: der Anbieter kann alles lesen, und wer ihn kompromittiert auch
Das ist der Unterschied zwischen “verschlüsselt at rest” als Häkchen und Verschlüsselung, die dich wirklich schützt.
3. Welche Rechtsordnung gilt für die Daten?
Für EU-Agenturen und Agenturen mit EU-Kunden ist das nicht optional.
Was du fragen solltest: “Kann ich die Region wählen, in der die Datenbank erstellt wird, und wird das auf Infrastrukturebene durchgesetzt?”
| Antwort | Risiko |
|---|---|
| “Wir sind GDPR-konform” | Ein Policy-Claim — frag was es durchsetzt |
| “Wir verarbeiten Daten in der EU” | Verarbeitung ≠ Speicherung; Unterauftragsverarbeiter können woanders liegen |
| “Du wählst die Region bei Anmeldung; die Datenbank wird dort erstellt” | Architektonische Garantie |
“Wir sind GDPR-konform” ist keine Antwort auf “wo liegen die Daten.” GDPR-Compliance und Datenresidenz hängen zusammen, sind aber nicht dasselbe. Residenz durch Architektur durchgesetzt — die Datenbank wird in der von dir gewählten Region erstellt — ist stärker als Residenz, die in einem AVV versprochen wird.
4. Was passiert beim Ausstieg?
Das ist die Frage, die niemand stellt, bis er sie braucht.
Was du fragen solltest: “Wenn wir den Vertrag morgen kündigen, worauf haben wir Zugang, wie lange und in welchem Format?”
| Antwort | Was du erwarten kannst |
|---|---|
| “Du kannst deine Daten jederzeit exportieren” | CSV/JSON-Dateien; Beziehungen überleben vielleicht nicht |
| “Wir geben 30 Tage zum Export nach Kündigung” | Eine Countdown-Uhr; hoffe der Export ist vollständig |
| “Deine Datenbank bleibt auf deinem Cloud-Konto” | Kein Export nötig; Software wechseln, Daten behalten |
Die dritte Antwort gilt nur bei BYOC oder Self-hosted-Architektur. Jede andere Antwort heißt: du planst eine Migration unter Druck.
Schließt der Anbieter komplett, wird die Ausstiegsfrage dringend — und die Qualität des Exportfensters entscheidet, ob du neu aufbaust oder weitermachst.
5. Kann der Anbieter auf deine Daten zugreifen, ohne dass du es weißt?
Was du fragen solltest: “Unter welchen Umständen greift euer Team auf Kundendaten zu, und ist dieser Zugang geloggt und auditierbar?”
Vernünftige Antworten: Support-Anfragen die du initiierst, Sicherheitsvorfälle mit Benachrichtigung, rechtliche Anforderungen mit Vorankündigung. Unvernünftige Antworten: “wir können auf Daten zugreifen um unser Produkt zu verbessern” ohne Anonymisierung zu spezifizieren, oder gar kein Audit-Trail.
Für Agenturen mit Kundendaten erstreckt sich die Frage auf deine eigenen Kunden: fragt ein Kunde “wer kann unsere Dateien sehen”, brauchst du eine Antwort besser als “die Mitarbeiter unseres SaaS-Anbieters, laut deren Policy.”
Rote Flaggen im Sales-Gespräch
Geh weiter oder eskaliere zur juristischen Prüfung wenn du hörst:
- “Du besitzt deine Daten” ohne zu spezifizieren wo sie liegen oder wie du sie erreichst
- “Wir können dich später migrieren” — Migration ist immer schwerer als versprochen
- “Export ist über unsere API verfügbar” — APIs ändern sich, werden deprecated und schließen
- “Vertrau uns, wir sind SOC-2-zertifiziert” — Zertifizierung ist Prozess, nicht deine Zugriffsrechte
- “Alle unsere Kunden teilen dieselbe Infrastruktur” — Multi-Tenant per Definition
Grüne Flaggen
- Datenbank auf deinem Cloud-Konto provisioniert
- Regionswahl bei Anmeldung, auf Infrastrukturebene durchgesetzt
- Direkter Datenbankzugang mit deinen Zugangsdaten
- AVV, der dich als Verantwortlichen nennt und Unterauftragsverarbeiter listet
- Ausstieg ohne Export-Panik
So nutzt du die Checkliste in der Praxis
Vor der nächsten Demo: schick die fünf Fragen schriftlich. Anbieter, die konkret antworten können, tun es. Anbieter, die mit Marketing-PDFs antworten, sagen dir, dass die Architektur kein Eigentum unterstützt.
Bewerte jeden Kandidaten:
| Frage | Anbieter A | Anbieter B | sSystm (BYOC) |
|---|---|---|---|
| Wo ist die Datenbank? | Deren AWS | Deren AWS | Dein Cloudflare-Konto |
| Wer hält Schlüssel? | Anbieter | Anbieter | Du |
| Rechtsordnung? | “EU-Verarbeitung” | EU-Region wählbar | Region bei Anmeldung gewählt |
| Ausstieg? | 30-Tage-CSV-Export | API-Export | Datenbank bleibt auf deinem Konto |
| Anbieter-Zugang? | “Bei Bedarf” | Geloggt, auf Anfrage | Deine Infrastruktur |
Du suchst nicht Perfektion. Du suchst, ob die Architektur des Anbieters zu seinen Eigentums-Claims passt — oder ob “deine Daten gehören dir” eine juristische Fiktion ist.
Eigentum ist eine Architekturentscheidung
Features lassen sich hinzufügen. Preise verhandeln. Integrationen bauen. Datenarchitektur lässt sich nicht nachträglich einbauen. Die Wahl, ob die Kundendaten deiner Agentur auf deinem Cloud-Konto oder in der zentralen Datenbank eines Anbieters liegen, fällt bei der Anmeldung und ändert sich selten ohne volle Migration.
sSystm ist auf BYOC gebaut, weil Agenturen nicht Marketing-Sprache parsen sollten, um herauszufinden ob Kundendaten wirklich ihnen gehören. Die Checkliste oben sollte fünf Minuten dauern — und die Antworten sollten in deinem Cloud-Dashboard verifizierbar sein, nicht in einer Fußnote.
Verwandt: Was ist ein BYOC Agency OS? · Datenresidenz und GDPR für Agenturen · SaaS-Vendor-Lock-in
Häufige Fragen
Wem gehören die Daten in einer SaaS-Anwendung?
Rechtlich behältst du oft das Eigentum am hochgeladenen Inhalt — aber der Anbieter kontrolliert, wo er gespeichert wird, wie er zugänglich ist und ob du exportieren kannst. 'Du besitzt deine Daten' in den AGB bedeutet nicht, dass du sie unabhängig erreichen kannst. Echtes Eigentum heißt: du hältst die Datenbank, die Schlüssel und die Möglichkeit, deine Datensätze ohne Erlaubnis des Anbieters abzurufen.
Welche Fragen sollte ich zum Dateneigentum stellen, bevor ich Agentur-Software kaufe?
Fünf Essentials: (1) Wo liegt die aktive Datenbank physisch? (2) Wer hält die Verschlüsselungsschlüssel? (3) Welche Rechtsordnung gilt für die Daten? (4) Was passiert mit deinen Daten, wenn du gehst oder der Anbieter schließt? (5) Kann der Anbieter auf deine Daten zugreifen, ohne dass du es weißt? Ist eine Antwort vage, nimm an, der Anbieter kontrolliert die Daten.
Was ist der Unterschied zwischen Datenresidenz und Dateneigentum?
Datenresidenz ist Geographie — wo die Server stehen. Dateneigentum ist Kontrolle — wer die Datenbank, Backups und Schlüssel hält. Ein Anbieter kann in der EU hosten (Residenz) und deine Daten trotzdem in seiner zentralen Multi-Tenant-Datenbank halten, auf die du nicht direkt zugreifen kannst (kein Eigentum). Residenz ohne Eigentum ist ein Policy-Versprechen; Eigentum ist ein Architekturfaktum.
Wie sieht eine gute Auftragsverarbeitungsvereinbarung für Agenturen aus?
Sie soll Verantwortlicher (du), Auftragsverarbeiter (Anbieter), Unterauftragsverarbeiter, Rechtsordnung, Fristen für Breach-Benachrichtigung und dein Recht auf Audit oder Export festlegen. Für Agenturen mit Kundendaten sollte sie auch klären, was mit Kundendatensätzen passiert, wenn dein Vertragsverhältnis mit dem Anbieter endet — nicht nur mit den eigenen Kontodaten deiner Agentur.
Wie beeinflusst BYOC die Bewertung des Dateneigentums?
BYOC (Bring Your Own Cloud) ändert die Antwort auf jede Frage der Checkliste. Die Datenbank wird auf deinem Cloud-Konto provisioniert, du wählst die Region, du hältst die Zugangsdaten, und der Anbieter-Ausstieg erfordert keinen Export — die Daten liegen bereits auf deiner Infrastruktur. Die Bewertung wird zur Verifizierung der Architektur, nicht zum Parsen von Marketing-Sprache.
sSystm ist das erste BYOC-Agentur-OS — deine Kunden, dein Code und deine Cloud auf deinem eigenen Cloudflare-Konto, mit deiner KI, die den ganzen Workspace über MCP bedient.
Auf die Warteliste