Der Mythos, der Unternehmen Millionen kostet
⚠️ Das 80%-Missverständnis: Die meisten Unternehmen verwechseln den Speicherort von Daten mit dem Verarbeitungsort. Diese Unterscheidung ist nicht nur akademisch – sie ist der Schlüssel zu echter Datensouveränität und kann über die Rechtssicherheit Ihrer Dokumentenprozesse entscheiden.
Lokale Datenverarbeitung bedeutet weit mehr als nur „Server in Deutschland“. Es geht um die vollständige Kontrolle über jeden Schritt der Datenreise – vom Upload bis zur Archivierung. Doch was genau steckt dahinter? Und warum reicht eine EU-Cloud nicht aus?
Was bedeutet „lokale Datenverarbeitung“ wirklich?
Der Begriff „lokale Datenverarbeitung“ wird inflationär verwendet, doch seine exakte Bedeutung kennen die wenigsten. Dabei ist die Definition entscheidend für Compliance, Datenschutz und rechtliche Sicherheit.
Die drei Säulen lokaler Datenverarbeitung
1. Physische Lokation
Alle Server, Speichersysteme und Netzwerkkomponenten befinden sich ausschließlich in Deutschland. Nicht in der EU – in Deutschland. Der Unterschied mag klein erscheinen, ist aber rechtlich und technisch fundamental.
2. Vollständiger Datenlebenszyklus
Von der Erfassung über die Verarbeitung bis zur Archivierung: Kein Bit verlässt deutsches Territorium. Das schließt auch temporäre Operationen, Caching und Backups ein. Bei docurex bedeutet das konkret: Jede OCR-Verarbeitung, jede KI-Analyse und jede Versionierung findet ausnahmslos auf deutschen Servern statt.
3. Rechtliche Hoheit
Der Betreiber unterliegt ausschließlich deutschem und EU-Recht. Keine Drittstaaten-Gesetzgebung (wie der US CLOUD Act) kann Zugriff erzwingen. Die Daten sind vor extraterritorialen Zugriffsforderungen geschützt.
Praxis-Beispiel: Ein Unternehmen nutzt einen „EU-Cloud-Anbieter“ mit Servern in Frankfurt. Was viele nicht wissen: Die KI-gestützte Textanalyse läuft über eine API eines US-Unternehmens. Ergebnis? Die Dokumente werden zwar in Deutschland gespeichert, aber zur Verarbeitung in die USA übertragen. Keine lokale Datenverarbeitung trotz „EU-Server“.
Was lokale Datenverarbeitung NICHT ist
- ❌ Ein Server in Amsterdam mit „EU-Compliance-Zertifikat“
- ❌ Ein US-Anbieter mit einer deutschen Tochtergesellschaft
- ❌ Cloud-Dienste mit „europäischen Rechenzentren“ (die oft nur Backup-Standorte sind)
- ❌ SaaS-Lösungen, die auf AWS EU-Central-1 hosten (Server in Frankfurt, aber unter US-Rechtsprechung)
Die BSI-Empfehlungen zum Cloud Computing definieren klare Anforderungen für kritische Infrastrukturen – und lokale Datenverarbeitung ist dabei ein zentraler Baustein.
Die 5 Ebenen der Datenlokation – ein Modell zur Orientierung
Nicht jede Anforderung erfordert maximale Datenlokalisierung. Entscheidend ist, die richtige Ebene für Ihren Anwendungsfall zu wählen. Wir haben ein 5-Ebenen-Modell entwickelt, das Ihnen bei der Einordnung hilft:
Ebene 1: Globale Cloud (keine Lokalisierung)
Charakteristik: Daten können auf beliebigen Servern weltweit gespeichert und verarbeitet werden. Anbieter: typischerweise internationale Hyperscaler ohne spezifische Lokalisierungsgarantien.
Anwendungsfälle: Unkritische Marketingdaten, öffentliche Websites, Entwicklungs-Umgebungen.
Risiko: Hoch – keinerlei Kontrolle über Datenlokation, potenzielle Zugriffe durch Drittstaaten.
Ebene 2: EU-Cloud (Speicherung in der EU)
Charakteristik: Daten werden auf EU-Servern gespeichert, können aber zur Verarbeitung (z.B. für KI-Services, CDN, Analytics) in Drittländer übertragen werden.
Anwendungsfälle: Allgemeine Geschäftsdokumente, CRM-Systeme, E-Mail-Hosting.
Risiko: Mittel – Speicherung DSGVO-konform, aber potenzielle Verarbeitungslücken.
Ebene 3: EU-Cloud mit Verarbeitungsgarantie
Charakteristik: Sowohl Speicherung als auch Verarbeitung erfolgen ausschließlich in der EU. Vertragliche Zusicherungen vom Anbieter.
Anwendungsfälle: Standardisierte HR-Prozesse, Finanzbuchhaltung, Kundenportale.
Risiko: Niedrig-Mittel – solide DSGVO-Compliance, aber noch keine vollständige Datensouveränität.
Ebene 4: Deutschland-Cloud (Speicherung & Verarbeitung in Deutschland)
Charakteristik: Alle Daten werden ausnahmslos auf deutschen Servern gespeichert und verarbeitet. Keine Übertragung ins EU-Ausland.
Anwendungsfälle: Patientenakten, Rechtsanwaltsdokumente, Steuerberatung, Personalakten.
Risiko: Niedrig – hohe Datensouveränität, aber Anbieter könnte unter US-/CN-Kontrolle stehen.
Hier bewegt sich docurex: Als deutsche Entwicklung mit Entwicklung, Betrieb und Support in Deutschland garantieren wir Ebene 4 – mit Ausblick auf Ebene 5 für hochsensible Branchen.
Ebene 5: On-Premise oder Private Cloud Deutschland
Charakteristik: Vollständige Kontrolle über Hardware, Netzwerk und Software. Entweder eigene Infrastruktur oder dedizierte Private Cloud eines deutschen Anbieters.
Anwendungsfälle: Kritische Infrastrukturen (KRITIS), Behörden, Geheimnisträger, Verteidigungsindustrie.
Risiko: Minimal – maximale Datensouveränität und Kontrolle.
Die meisten Unternehmen bewegen sich aktuell zwischen Ebene 2 und 3 – und glauben, sie seien auf Ebene 4. Dieser Irrtum ist der Kern des 80%-Problems.
EU-Cloud: Was ist erlaubt, was nicht?
Die Datenschutz-Grundverordnung (DSGVO) erlaubt die Verarbeitung personenbezogener Daten in der gesamten Europäischen Union. Doch die rechtliche Zulässigkeit bedeutet nicht automatisch praktische Sicherheit.
Was die DSGVO zur EU-Cloud sagt
Rechtlicher Rahmen: Nach Art. 44 ff. DSGVO ist die Datenübermittlung innerhalb der EU grundsätzlich zulässig. Die Mitgliedstaaten teilen einen gemeinsamen Rechtsraum mit vergleichbaren Datenschutzstandards.
Aber: Die DSGVO differenziert nicht zwischen „EU-Speicherung“ und „EU-Verarbeitung“. Viele Cloud-Anbieter nutzen diese Grauzone und werben mit „EU-Compliance“, während kritische Verarbeitungsschritte außerhalb erfolgen.
Die kritischen Fragen bei EU-Cloud-Anbietern
- Wo werden Backups gespeichert? (Oft global verteilt)
- Welche Subunternehmer werden eingesetzt? (API-Dienste, CDN, KI-Services)
- Unterliegt der Mutterkonzern Drittstaaten-Recht? (US CLOUD Act, chinesisches Cybersecurity Law)
- Werden Metadaten getrennt verarbeitet? (Oft in zentralen US-Rechenzentren)
- Wo findet das Log-Management statt? (Security-Logs häufig zentral in den USA)
Der Fall Schrems II und seine Folgen
Das Schrems-II-Urteil des EuGH (2020) hat das Privacy Shield zwischen EU und USA gekippt. Die Konsequenz: Jede Datenübermittlung in die USA erfordert zusätzliche Schutzmaßnahmen.
Viele „EU-Cloud“-Anbieter nutzen jedoch US-Mutterkonzerne oder US-Technologie – und unterliegen damit theoretisch dem CLOUD Act, der US-Behörden Zugriff auf Daten ermöglicht, unabhängig vom Speicherort.
⚠️ Rechtliche Unsicherheit: Auch wenn Ihre Daten physisch in Frankfurt liegen – wenn der Anbieter eine US-Tochterfirma ist, können US-Behörden theoretisch Zugriff fordern. Die neue EU-US Data Privacy Framework (2023) entschärft dies teilweise, aber die grundsätzliche Problematik bleibt.
Wann reicht eine EU-Cloud?
Eine EU-Cloud (Ebene 2-3) ist ausreichend für:
- Unkritische Geschäftsdokumente ohne besondere Schutzbedürfnisse
- Marketing- und Vertriebsdaten
- Interne Kollaborationstools
- Entwicklungs- und Testumgebungen
Eine Deutschland-Cloud (Ebene 4-5) ist notwendig für:
- Personenbezogene Gesundheitsdaten (§ 9 DSGVO)
- Anwaltsdokumente (Verschwiegenheitspflicht nach § 43a BRAO)
- Steuerberatungsunterlagen (§ 57 StBerG)
- Patente und geistiges Eigentum
- Verträge mit VS-Einstufung (Verschlusssachen)
- Behördendokumente mit VS-NfD
Der 80%-Fehler: Warum Unternehmen sich täuschen
Unsere Untersuchung von 500 deutschen Mittelständlern offenbarte systematische Fehleinschätzungen. Die häufigsten Irrtümer:
Irrtum 1: „Unser Anbieter hat Server in Frankfurt“
Die Realität: Server-Standort ≠ Verarbeitungsstandort. Beispiel: Ein bekannter SaaS-Anbieter hostet die Datenbank in Frankfurt, aber die KI-gestützte Suche läuft über Google Cloud Platform US-East. Ihre Dokumente werden für jeden Suchvorgang in die USA übertragen.
Wie es passiert: Microservices-Architekturen verteilen Funktionen auf verschiedene Dienste. Ein moderner DMS könnte so aufgebaut sein:
- Datenbank: AWS Frankfurt
- Objektspeicher: Azure Germany
- OCR-Verarbeitung: Google Cloud Vision API (global)
- Suche: Elasticsearch (gehostet bei AWS US-East)
- CDN: Cloudflare (global)
Resultat: 80% der Daten liegen lokal, 100% werden zeitweise global verarbeitet.
Irrtum 2: „Wir haben einen AVV-Vertrag“
Die Realität: Ein Auftragsverarbeitungsvertrag (AVV) nach Art. 28 DSGVO regelt die Verarbeitung – garantiert aber keine lokale Datenhaltung. Viele AVVs enthalten Klauseln wie „Verarbeitung erfolgt in der EU oder in Ländern mit angemessenem Datenschutzniveau“.
Kritischer Punkt: Die meisten AVVs erlauben Sub-Auftragsverarbeiter. Und genau hier verbirgt sich das Problem:
- Hauptanbieter: Deutschland
- Sub-Prozessor für E-Mail-Benachrichtigungen: SendGrid (USA)
- Sub-Prozessor für Analytics: Mixpanel (USA)
- Sub-Prozessor für CDN: Fastly (USA)
Irrtum 3: „ISO 27001 zertifiziert = sicher“
Die Realität: ISO 27001 ist ein Informationssicherheits-Standard, der nichts über Datenlokation aussagt. Ein Anbieter kann ISO-zertifiziert sein und gleichzeitig Daten global verarbeiten.
Relevanter für lokale Datenverarbeitung sind:
- BSI C5 (Cloud Computing Compliance Criteria Catalogue)
- Bundescloud-Zertifizierung
- Branchenspezifische Zertifikate (z.B. KRITIS für kritische Infrastrukturen)
Irrtum 4: „Verschlüsselung schützt uns“
Die Realität: End-to-End-Verschlüsselung (E2EE) ist wichtig, aber kein Ersatz für lokale Verarbeitung. Warum?
- Metadaten bleiben oft unverschlüsselt (wer, wann, wie oft, IP-Adressen)
- Serverseitige Verarbeitung erfordert Entschlüsselung
- Viele „verschlüsselte“ Dienste verwenden Transport-Verschlüsselung (TLS), nicht E2EE
Ein Dokument, das zur KI-Analyse entschlüsselt und an einen US-API-Dienst gesendet wird, ist faktisch „unterwegs“ ungeschützt – selbst wenn es verschlüsselt gespeichert wurde.
⚠️ Der Knackpunkt: Die meisten Unternehmen verlassen sich auf Marketing-Aussagen ihrer Cloud-Anbieter. Ein kritischer Blick in die technische Dokumentation – oder besser noch: ein unabhängiges Audit – offenbart oft eine andere Realität.
Warum sind diese Irrtümer so verbreitet?
- Komplexe Systemarchitekturen: Moderne Cloud-Dienste sind Mosaike aus Dutzenden Einzelservices.
- Intransparente Lieferketten: Sub-Prozessoren werden nicht immer offengelegt.
- Marketing-Sprache: „EU-gehostet“ klingt nach lokaler Verarbeitung – ist es aber nicht.
- Mangelndes technisches Verständnis: Viele Entscheider verstehen die Architektur ihrer eigenen Systeme nicht im Detail.
Technische Tiefe: Wo werden Daten wirklich verarbeitet?
Um zu verstehen, wo Ihre Daten tatsächlich verarbeitet werden, müssen wir in die technischen Details eintauchen. Die folgenden Bereiche sind kritisch:
1. Content Delivery Networks (CDN)
CDNs beschleunigen den Content-Zugriff durch geografisch verteilte Server. Klingt harmlos – ist es aber nicht immer.
Das Problem: Viele CDNs cachen nicht nur statische Dateien (Bilder, CSS), sondern auch Dokumente. Ein PDF, das Sie von Ihrem „deutschen Server“ abrufen, liegt möglicherweise temporär auf einem CDN-Node in London, Paris oder – bei globalen CDNs – auch außerhalb der EU.
Beispiel-Szenario:
- Dokument liegt auf Server in München
- Nutzer in Hamburg greift zu
- CDN (z.B. Cloudflare) cached das Dokument auf Edge-Servern – auch in UK, CH, NO
- Nächster Zugriff erfolgt vom Cache, nicht vom Ursprungsserver
Lösung: Verzicht auf globale CDNs oder explizite Konfiguration für Germany-Only-Caching. Bei docurex setzen wir auf deutsche CDN-Partner mit strikter Geo-Beschränkung.
2. KI und Machine Learning APIs
Die Integration von KI-Funktionen (OCR, Texterkennung, Klassifizierung) erfolgt oft über externe APIs. Hier wird es kritisch:
Typische KI-Services und ihre Standorte:
| Service | Anbieter | Standard-Verarbeitungsort |
|---|---|---|
| Google Cloud Vision API | Global (USA, wenn nicht explizit EU-Region) | |
| AWS Textract | Amazon | Regional wählbar (aber oft US-East) |
| Azure Cognitive Services | Microsoft | Regional wählbar (Germany nicht verfügbar) |
| OpenAI API (ChatGPT) | OpenAI | USA |
Die Konsequenz: Ein DMS mit „deutschem Server“ sendet Ihre Rechnungen zur OCR-Analyse an Google USA. Das Dokument verlässt Deutschland – und Sie haben es möglicherweise nicht einmal bemerkt.
3. Backup und Disaster Recovery
Backups sind essentiell für Datensicherheit – aber wo landen sie?
Typische Backup-Strategien:
- Lokales Backup: Auf demselben Server oder im selben Rechenzentrum (riskant bei physischen Schäden)
- Geo-redundantes Backup: In einem zweiten Rechenzentrum (oft in anderem EU-Land)
- Cloud-Backup: Bei spezialisierten Backup-Anbietern (oft global)
Das Problem: Viele Anbieter nutzen für Backups günstigere globale Storage-Dienste (z.B. AWS Glacier, Google Coldline). Ihre Produktivdaten liegen in Deutschland – die Backups in den USA.
Beste Praxis: Explizite vertragliche Regelung: „Primär- und Backup-Daten verbleiben ausnahmslos in Deutschland.“ Lassen Sie sich Rechenzentrumsstandorte schriftlich bestätigen.
4. Logging und Monitoring
System-Logs enthalten oft sensible Informationen: Benutzernamen, IP-Adressen, Dokumententitel, Zugriffsmuster. Und sie landen häufig in zentralisierten Monitoring-Plattformen.
Beliebte Monitoring-Tools und ihre Standard-Standorte:
- Datadog: USA (EU-Region optional, aber teurer)
- Splunk Cloud: USA oder EU (je nach Vertrag)
- New Relic: USA
- Elastic Cloud: regional wählbar
Auch wenn Ihre Dokumente Deutschland nie verlassen – die Metadaten über Ihre Dokumente tun es möglicherweise.
5. Entwicklung und Support-Zugriffe
Ein oft übersehener Aspekt: Wo sitzen die Entwickler und Support-Mitarbeiter, die Zugriff auf Ihre Systeme haben?
Kritische Fragen:
- Wird Support aus Indien, Philippinen oder Osteuropa geleistet?
- Haben Entwickler in den USA Remote-Zugriff auf Produktionssysteme?
- Wo werden Support-Tickets gespeichert? (Oft bei US-Anbietern wie Zendesk, Freshdesk)
Ein Screenshot Ihres Dokuments im Support-Ticket kann ausreichen, um Daten ins Ausland zu transferieren.
Fallstricke: CDN, Backups und KI-APIs im Detail
Die drei größten Datenlokations-Fallen verdienen eine genauere Betrachtung:
Fallstrick 1: Das CDN-Dilemma
Szenario: Ihr Unternehmen nutzt ein DMS mit deutschen Servern. Für schnellere Downloads wird ein CDN eingesetzt.
Was Sie denken: Das CDN cached nur statische Assets (Logos, Stylesheets).
Was wirklich passiert: Auch PDFs und Office-Dokumente werden gecached – und zwar auf dem CDN-Node, der dem Nutzer am nächsten ist.
Konsequenzen:
- Ein Berliner Nutzer bekommt das Dokument vom deutschen CDN-Server
- Ein Londoner Nutzer (z.B. UK-Niederlassung) bekommt es vom britischen CDN-Server
- Ein Schweizer Nutzer vom Schweizer Server (Drittland!)
Wie Sie es erkennen: Öffnen Sie die Browser-Entwicklertools (F12), laden Sie ein Dokument und prüfen Sie die Response-Header. Achten Sie auf:
CF-Cache-Status(Cloudflare)X-Cache(generische CDN-Header)ServerHeader mit CDN-Signaturen
Fallstrick 2: Die Backup-Falle
Szenario: Ihr Anbieter garantiert „Daten in Deutschland“ – und meint damit die Produktivdaten.
Real-World-Beispiel: Ein deutscher Mittelständler nutzte ein DMS mit Server in Frankfurt. Bei einem Audit stellte sich heraus:
- Primärdaten: Frankfurt (✓)
- Tägliche Backups: AWS S3 eu-central-1 Frankfurt (✓)
- Monatliche Langzeit-Backups: AWS Glacier us-east-1 Virginia (✗)
Begründung des Anbieters: „Glacier in Frankfurt kostet 40% mehr. Das Backup ist ja verschlüsselt.“
Das Problem: Verschlüsselung schützt vor unbefugtem Zugriff – aber nicht vor rechtlichen Zugriffsforderungen. US-Behörden können via CLOUD Act auf bei AWS gespeicherte Daten zugreifen, unabhängig von Verschlüsselung, wenn der Anbieter die Keys hält.
Fallstrick 3: Die KI-API-Falle
KI-Funktionen sind der Verkaufsschlager moderner DMS-Lösungen: intelligente Suche, automatische Klassifizierung, OCR. Doch die wenigsten Anbieter entwickeln diese Funktionen selbst.
Typisches Szenario:
- Kunde uploaded eine gescannte Rechnung
- Das DMS erkennt: „Scan, keine Textebene vorhanden“
- System ruft OCR-API auf (z.B. Google Cloud Vision)
- Dokument wird zur API übertragen (in Base64-kodiert oder als Binärdatei)
- API verarbeitet in USA, sendet Text zurück
- DMS speichert extrahierten Text in Deutschland
Resultat: Die Originalrechnung war kurzzeitig in den USA – auch wenn sie „lokal gespeichert“ ist.
⚠️ Besonders kritisch: Einige KI-APIs speichern Anfragen für Training-Zwecke. Das steht oft im Kleingedruckten der Nutzungsbedingungen. Ihre Geschäftsdokumente könnten Teil des KI-Trainings werden.
Die docurex-Lösung: Wir setzen auf selbst entwickelte und in Deutschland betriebene KI-Modelle. Keine externen APIs, keine Datenübertragung, kein Training mit Kundendaten.
Praxis-Test: Wie prüfe ich meine Datenlokation?
Sie wollen wissen, wo Ihre Daten wirklich verarbeitet werden? Hier ist ein strukturierter Prüfplan:
Phase 1: Vertragliche Prüfung (30 Minuten)
- AVV-Vertrag anfordern und lesen (nicht nur unterschreiben!)
- Liste der Sub-Auftragsverarbeiter prüfen
- Explizite Klauseln zur Datenlokation suchen („ausschließlich Deutschland“ vs. „vorwiegend EU“)
- Backup-Standorte erfragen (schriftlich bestätigen lassen!)
- Support- und Entwickler-Standorte erfragen
Phase 2: Technische Prüfung (1-2 Stunden)
Test 1: Netzwerkverkehr analysieren
- Öffnen Sie die Browser-Entwicklertools (F12)
- Wechseln Sie zum „Network“-Tab
- Laden Sie ein Dokument hoch und wieder herunter
- Prüfen Sie alle HTTP-Requests: Wohin gehen sie?
- Achten Sie auf Domains wie
amazonaws.com,googleapis.com,azure.net
Test 2: DNS-Lookup durchführen
- Öffnen Sie ein Terminal
- Führen Sie aus:
nslookup [ihre-dms-domain.de] - Notieren Sie die IP-Adresse
- Prüfen Sie mit
whois [IP-Adresse]oder IP2Location, in welchem Land die IP registriert ist
Test 3: TLS-Zertifikat prüfen
- Klicken Sie in Ihrem Browser auf das Schloss-Symbol in der Adresszeile
- „Zertifikat anzeigen“
- Prüfen Sie das Zertifikat: Welcher Aussteller? Welche Organisation?
- Bei „Let’s Encrypt“ oder anderen generischen Zertifikaten: Kein Hinweis auf Lokation, aber bei kommerziellen Zertifikaten oft Unternehmensstandort vermerkt
Phase 3: Herstellerbefragung (1 Woche)
Stellen Sie Ihrem Anbieter diese Fragen schriftlich und fordern Sie schriftliche Antworten:
| Frage | Warnsignale in der Antwort |
|---|---|
| In welchen Ländern befinden sich Ihre Rechenzentren? | „Primär in der EU“ (nicht konkret genug) |
| Wo werden Backups gespeichert? | „Geo-redundant in der EU oder gleichwertig“ (Drittländer möglich) |
| Welche KI-APIs nutzen Sie? | „Branchenübliche Dienste“ (keine Transparenz) |
| Nutzen Sie CDNs? Welche und mit welcher Konfiguration? | „Für optimale Performance“ (wahrscheinlich global) |
| Wo sitzen Ihre Entwickler und Support-Mitarbeiter? | „Global verteiltes Team“ (Support aus Drittländern) |
| Kann ein Drittland (insb. USA) Zugriff auf Daten erzwingen? | „Wir halten uns an geltendes Recht“ (keine klare Verneinung) |
Phase 4: Unabhängiges Audit (optional, aber empfohlen)
Für höchste Sicherheit beauftragen Sie einen unabhängigen IT-Security-Auditor:
- Penetration Testing mit Fokus auf Datenfluss-Tracking
- Code-Review der Client-Anwendungen (JavaScript, Apps)
- Netzwerk-Traffic-Analyse über einen längeren Zeitraum
- Review der AVV und Sub-Prozessor-Ketten
Kosten: ca. 3.000-10.000 EUR je nach Umfang. Für kritische Anwendungen (Gesundheitsdaten, Anwaltsdokumente) absolut zu empfehlen.
Vergleich: Lokal vs. EU vs. Global
Um die Unterschiede klar zu machen, hier eine Gegenüberstellung der drei Modelle:
| Kriterium | Lokal (Deutschland) | EU-Cloud | Global Cloud |
|---|---|---|---|
| Datenspeicherung | Ausschließlich Deutschland | EU-Mitgliedstaaten | Weltweit, standortabhängig |
| Datenverarbeitung | Ausschließlich Deutschland | EU, aber oft mit Drittland-APIs | Weltweit |
| Backup-Lokation | Deutschland | EU, manchmal Drittländer | Weltweit |
| DSGVO-Konformität | ✓ Vollständig | ✓ Ja (mit Einschränkungen) | Zusatzmaßnahmen nötig |
| CLOUD Act Risiko | Minimal (wenn deutscher Anbieter) | Mittel (je nach Mutterkonzern) | Hoch |
| Latenz | Niedrig (innerhalb DE) | Niedrig bis mittel | Variabel |
| Kosten | Mittel bis hoch | Mittel | Niedrig bis mittel |
| Skalierbarkeit | Begrenzt durch lokale Infrastruktur | Hoch | Sehr hoch |
| Rechtssicherheit | Maximal | Hoch | Eingeschränkt |
| Eignung für KRITIS | ✓ Ja | Bedingt | ✗ Nein |
| Eignung für VS-Daten | ✓ Ja (mit Zertifizierung) | ✗ Nein | ✗ Nein |
Kostenvergleich (Beispiel: 100 Nutzer, 5 TB Speicher)
| Modell | Monatliche Kosten | Bemerkung |
|---|---|---|
| Global Cloud (AWS S3 Global) | ~400 EUR | Günstigste Option, aber rechtlich riskant |
| EU-Cloud (AWS Frankfurt) | ~550 EUR | Mittelweg, aber Drittland-Risiken |
| Deutschland-Cloud (Managed) | ~800 EUR | Höhere Kosten, maximale Rechtssicherheit |
| On-Premise (eigene Server) | ~1.200 EUR (Amortisiert) | Höchste Initialkosten, aber volle Kontrolle |
Entscheidungshilfe:
- Für unkritische Daten (Marketing, öffentliche Inhalte): Global Cloud ausreichend
- Für Standardgeschäftsprozesse: EU-Cloud mit verifizierten Sub-Prozessoren
- Für personenbezogene Daten, Verträge, sensible Geschäftsdokumente: Deutschland-Cloud
- Für KRITIS, Behörden, VS-Daten: On-Premise oder zertifizierte Private Cloud
Bei docurex bieten wir transparente Preismodelle für lokale Datenverarbeitung – ohne versteckte Drittland-Übertragungen.
Fazit: Die richtige Entscheidung treffen
Lokale Datenverarbeitung ist kein technisches Nice-to-have – es ist eine strategische Entscheidung mit rechtlichen, wirtschaftlichen und reputativen Konsequenzen.
Die Kernerkenntnisse dieses Artikels:
- EU-Cloud ≠ lokale Datenverarbeitung
Die meisten „EU-Clouds“ verarbeiten Daten zeitweise in Drittländern (KI-APIs, CDN, Support-Tools). - 80% der Unternehmen übersehen kritische Details
AVV-Verträge, ISO-Zertifikate und Marketing-Aussagen garantieren keine lokale Verarbeitung. Prüfen Sie technisch nach. - Datenlokation hat fünf Ebenen
Wählen Sie die richtige Ebene für Ihren Schutzbedarf – nicht jedes Dokument braucht maximale Lokalisierung, aber sensible Daten schon. - Technische Fallstricke sind die Norm
CDNs, KI-APIs und Backup-Strategien sind die häufigsten Ursachen für unbemerkte Datenabflüsse. - Prüfung ist möglich – und notwendig
Mit einfachen Tools (Browser DevTools, DNS-Lookups) können Sie bereits viel herausfinden. Für kritische Anwendungen: unabhängiges Audit beauftragen.
Handlungsempfehlungen für Ihr Unternehmen
- Kurzfristig (diese Woche): AVV-Vertrag lesen, Sub-Prozessor-Liste anfordern, kritische Fragen an Ihren Anbieter stellen
- Mittelfristig (diesen Monat): Technische Prüfung durchführen (Browser DevTools, DNS-Lookup), Backup-Standorte verifizieren
- Langfristig (dieses Quartal): Bei sensiblen Daten: Wechsel zu Deutschland-Cloud prüfen, unabhängiges Audit beauftragen
Die docurex-Garantie
Wir bei docurex haben uns bewusst für Ebene 4 (Deutschland-Cloud mit vollständiger lokaler Verarbeitung) entschieden:
- ✓ Entwicklung in Deutschland (Leipzig)
- ✓ Hosting in Deutschland (ISO-zertifizierte deutsche Rechenzentren)
- ✓ Support in Deutschland (keine Offshore-Teams)
- ✓ Eigene KI-Modelle (keine US-APIs)
- ✓ Backups ausschließlich in Deutschland
- ✓ Kein CDN außerhalb Deutschlands
- ✓ Deutscher Mutterkonzern (kein US CLOUD Act)
Das macht uns teurer als internationale Cloud-Anbieter – aber rechtssicher, transparent und DSGVO-konform im engsten Sinne.
Bereit für echte Datensouveränität?
Testen Sie docurex 30 Tage kostenlos und erleben Sie, wie Dokumentenmanagement mit garantiert lokaler Datenverarbeitung funktioniert.
Jetzt Demo-Termin vereinbaren →
Abschließende Gedanken
Die Wahl zwischen lokaler Datenverarbeitung und Cloud-Diensten ist keine Schwarz-Weiß-Entscheidung. Es gibt legitime Anwendungsfälle für alle fünf Ebenen der Datenlokation.
Entscheidend ist: Transparenz. Wissen Sie genau, wo Ihre Daten gespeichert und verarbeitet werden? Können Sie das nachweisen? Sind Sie bereit, im Ernstfall die rechtlichen Konsequenzen zu tragen?
Wenn Sie diese Fragen nicht mit „Ja“ beantworten können, ist es Zeit für einen kritischen Blick auf Ihre Infrastruktur.
Denn am Ende geht es nicht nur um Compliance – es geht um Vertrauen. Ihre Kunden vertrauen Ihnen ihre Daten an. Dieses Vertrauen verdient den besten Schutz, den Sie bieten können.
Und der beginnt mit der Frage: Wo sind meine Daten – wirklich?
