DSGVO-konform heißt nicht Cookie-Banner — es ist eine Architektur-Entscheidung

Die meisten DACH-Founder denken bei DSGVO an Cookie-Banner und Datenschutzerklärungen. Das ist der sichtbare Teil. Der wichtigere Teil läuft im Hintergrund: wo deine Daten liegen, wer Zugriff hat, und ob du überhaupt noch Kontrolle darüber hast.

Wenn du ein KI-Tool für dein Business wählst — egal ob für Content, Lead-Gen oder Automatisierung — triffst du eine Architektur-Entscheidung. Keine Marketing-Entscheidung. Die Frage ist nicht "Welches Tool hat die beste UI?", sondern "Wo landen meine Kundendaten, und kann ich das vor der Aufsichtsbehörde verteidigen?"

US-Cloud ist kein DSGVO-Problem mehr — oder doch?

Das EU-US Data Privacy Framework hat die rechtliche Lage entspannt. US-Anbieter mit DPF-Zertifizierung dürfen personenbezogene Daten aus der EU verarbeiten. Klingt nach grünem Licht für AWS, Google Cloud, OpenAI.

Aber: DPF ist ein politisches Konstrukt. Privacy Shield wurde gekippt. Safe Harbor wurde gekippt. DPF kann genauso kippen. Wenn du dein Business auf US-Cloud baust und DPF fällt, hast du ein Problem. Nicht in drei Jahren. Sofort.

Die Frage ist nicht ob DPF sicher ist. Die Frage ist: Willst du dein Business-Risiko an eine politische Vereinbarung koppeln, die du nicht kontrollierst?

Was "DSGVO-konform" wirklich bedeutet

DSGVO-Konformität ist keine Checkbox. Es ist ein Set von Architektur-Entscheidungen:

• Datenhoheit: Du musst wissen wo deine Daten liegen. Nicht "irgendwo in der Cloud". Konkret: welches Rechenzentrum, welches Land, welcher Anbieter.
• Verarbeitungsort: Wenn du KI-Content generierst, wo läuft das Modell? Wenn du Leads enrichst, wo liegt die Datenbank? Wenn du Emails verschickst, wo ist der SMTP-Server?
• Subprozessoren: Jeder Drittanbieter in deiner Pipeline ist ein Subprozessor. Du brauchst AVVs (Auftragsverarbeitungsverträge) mit jedem einzelnen. Nicht "die haben bestimmt einen AVV". Du musst ihn haben.
• Datenlöschung: Wenn ein Kunde Löschung verlangt, kannst du das umsetzen? Oder sind seine Daten in fünf verschiedenen SaaS-Tools verteilt, von denen drei keine API für Löschung haben?

Das sind keine theoretischen Fragen. Das sind Fragen die dir die Aufsichtsbehörde stellt wenn ein Kunde sich beschwert.

Self-hosted bei Hetzner: Die Architektur-Entscheidung

ConnectEngine OS läuft auf einem Hetzner VPS in Helsinki. Nicht weil Hetzner billiger ist (ist es nicht immer). Sondern weil es eine bewusste Architektur-Entscheidung ist:

• EU-Rechenzentrum: Daten verlassen nie die EU. Kein DPF-Risiko. Kein Standardvertragsklauseln-Theater.
• Volle Kontrolle: Ich kann auf die Datenbank zugreifen. Ich kann Backups machen. Ich kann Daten löschen. Ich muss nicht auf ein Support-Ticket warten.
• Keine Vendor-Lock-in: Wenn Hetzner morgen die Preise verdoppelt, kann ich zu einem anderen EU-Hoster migrieren. Die Daten gehören mir.
• Transparenz: Ich weiß genau welche Services laufen. Keine "managed services" die im Hintergrund Daten an Dritte schicken.

Das bedeutet mehr Arbeit. Ich muss Server-Updates selbst machen. Ich muss Backups selbst organisieren. Ich muss Monitoring selbst aufsetzen. Aber dafür habe ich Kontrolle.

AI-Generationen: Wo landen deine Prompts?

Wenn du ein KI-Tool nutzt um Content zu generieren, schickst du Daten an ein Modell. Die Frage ist: wo läuft das Modell, und was passiert mit den Daten?

OpenAI API: Daten gehen in die USA. OpenAI sagt "wir trainieren nicht auf API-Daten". Das ist eine Policy, keine technische Garantie. Policies können sich ändern.

Anthropic API: Gleiche Story. Daten gehen in die USA. Anthropic hat bessere Privacy-Policies als OpenAI, aber es ist trotzdem US-Cloud.

Self-hosted Modelle: Du kannst Llama, Mistral oder andere Open-Source-Modelle auf deinem eigenen Server laufen lassen. Daten verlassen nie deinen Server. Aber: du brauchst GPU-Power, und die Qualität ist (noch) nicht auf OpenAI/Anthropic-Level.

ConnectEngine OS nutzt Anthropic Claude via API. Das ist ein bewusster Trade-off: bessere Qualität gegen US-Cloud-Abhängigkeit. Aber: die Prompts enthalten keine personenbezogenen Daten. Content-Ideen, URLs, Keywords — nichts was unter DSGVO fällt. Wenn du Lead-Daten oder Kundennamen in Prompts packst, sieht die Rechnung anders aus.

Lead-Gen: Das DSGVO-Minenfeld

Lead-Generierung ist der härteste DSGVO-Use-Case. Du scrapst Daten, du enrichst sie, du speicherst sie, du kontaktierst Leute. Jeder Schritt ist DSGVO-relevant.

Die Regeln für B2B-Outreach in DACH:

• Öffentlich zugängliche Daten: Du darfst Daten scrapen die öffentlich sind (Google Maps, Unternehmenswebsites, LinkedIn). Aber: nur für den Zweck für den sie veröffentlicht wurden. "Steht auf der Website" heißt nicht "darf in meine CRM-Datenbank".
• Berechtigtes Interesse: B2B-Cold-Outreach ist unter "berechtigtem Interesse" erlaubt, wenn es relevant ist. "Relevant" heißt: du kontaktierst einen E-Commerce-Shop mit einem E-Commerce-Tool, nicht einen Zahnarzt mit einem SaaS für Agenturen.
• Opt-out: Jede Email braucht einen funktionierenden Unsubscribe-Link. "Antworten Sie mit STOP" reicht nicht. Es muss ein One-Click-Opt-out sein.
• Datensparsamkeit: Du darfst nur die Daten speichern die du brauchst. Nicht "ich scrape alles und schaue später was ich brauche".

LeadFlow (das Lead-Gen-Modul von ConnectEngine OS) scrapt mit Apify, enricht mit Hunter.io, und speichert in Supabase. Alle drei Services haben AVVs. Supabase liegt in der EU. Hunter.io ist US-basiert aber DPF-zertifiziert. Apify ist EU-basiert. Das ist die Architektur-Entscheidung: EU-first wo möglich, DPF-zertifiziert wo nötig.

Was du vor der Tool-Wahl prüfen musst

Bevor du ein KI-Tool oder Automatisierungs-Tool in dein Business integrierst, prüfe:

1. Wo liegen die Daten? Nicht "in der Cloud". Konkret: welches Rechenzentrum, welches Land. Wenn der Anbieter das nicht sagen kann oder will, ist das ein Red Flag.
2. Wer hat Zugriff? Support-Teams? Entwickler? Subprozessoren? Jeder Zugriff ist ein DSGVO-Risiko.
3. Gibt es einen AVV? Auftragsverarbeitungsvertrag ist Pflicht wenn der Anbieter personenbezogene Daten verarbeitet. "Steht in den Terms" reicht nicht. Du brauchst einen unterschriebenen AVV.
4. Wie funktioniert Datenlöschung? Gibt es eine API? Gibt es ein UI? Oder musst du ein Support-Ticket aufmachen und hoffen dass es in drei Wochen bearbeitet wird?
5. Was passiert bei Kündigung? Bekommst du deine Daten zurück? In welchem Format? Oder sind sie für immer in der Cloud des Anbieters?

Das sind keine Nice-to-have-Fragen. Das sind Must-have-Fragen. Wenn du die Antworten nicht hast, bist du nicht DSGVO-konform. Egal wie gut der Cookie-Banner aussieht.

Der Preis von Kontrolle

Self-hosted ist mehr Arbeit. Keine Frage. Du musst Server managen, Backups machen, Updates einspielen, Monitoring aufsetzen. Das kostet Zeit.

Aber: du kaufst dir Kontrolle. Kontrolle über deine Daten. Kontrolle über deine Compliance. Kontrolle über dein Business-Risiko.

Wenn DPF kippt, hast du kein Problem. Wenn dein SaaS-Anbieter die Preise verdoppelt, kannst du migrieren. Wenn ein Kunde Datenlöschung verlangt, kannst du es sofort umsetzen. Das ist der Preis von Kontrolle wert.

DSGVO ist kein Marketing-Problem

DSGVO wird oft als Compliance-Theater behandelt. Cookie-Banner, Datenschutzerklärung, fertig. Aber DSGVO ist ein Architektur-Problem. Die Entscheidungen die zählen triffst du nicht im Marketing-Team. Du triffst sie wenn du deine Infrastruktur aufsetzt.

Wo liegen deine Daten? Wer hat Zugriff? Kannst du sie löschen? Kannst du sie migrieren? Das sind die Fragen die dein Business-Risiko bestimmen.

Self-hosted bei Hetzner ist eine Antwort. Nicht die einzige Antwort. Aber eine Antwort die funktioniert. EU-Rechenzentrum, volle Kontrolle, keine DPF-Abhängigkeit. Das ist DSGVO-konform. Nicht weil es einen Cookie-Banner hat. Sondern weil die Architektur stimmt.