Strukturierte Produktdaten heißt: Jede Produkteigenschaft steckt in einem typisierten Attribut mit E…
EU-gehostet statt Made in Germany: Datensouveränität im Frontend
Käufer im DACH-Raum verlangen keine Server in Frankfurt. Sie verlangen, dass Daten unter EU-Recht bleiben, und stellen diese Frage an jede Schicht im Stack. Für Commerce-Teams rückt damit das Frontend in die Mitte der Compliance-Prüfung, denn Rendering, Edge-Auslieferung, Consent und Tracking sind die Stellen, an denen der erste Personenbezug entsteht.
Was die DACH-Software-Buying-Studie tatsächlich misst
Die Studie „Software Buying in DACH 2026“ von OMR Reviews und cse advisory hat rund 200 Software-Käufer in Deutschland, Österreich und der Schweiz befragt. Die drei Kaufhürden daraus haben wir bereits in unserer Analyse zum Software-Einkauf im DACH-Raum eingeordnet. Eine Zahl lohnt den zweiten Blick: 81 % der Käufer nennen DSGVO-Konformität als Anforderung. Im Enterprise-Segment sind es 100 %.
Die Hosting-Werte schärfen das Bild:
- Nur 3 % akzeptieren eine Cloud außerhalb der EU.
- Je nach Fragestellung bevorzugen 73 % bzw. 76 % EU-Hosting.
- On-Premise liegt unter 9 %.
Der letzte Wert ist so wichtig wie der erste. Käufer wollen Software nicht in den eigenen Serverraum zurückholen. Sie wollen gemanagte Cloud-Services, solange diese unter EU-Recht laufen.
Warum „Made in Germany“ die falsche Frage ist
Lange galt deutsches Hosting als Kurzformel für Vertrauen. Die Studie zeigt in eine andere Richtung: Die Hürde ist nicht die deutsche Adresse, sondern EU-Datensouveränität. Welcher Rechtsrahmen gilt für die Daten, wer kann darauf zugreifen, und kannst du belegen, wo sie verarbeitet werden?
Das verändert die Bewertung. Ein Anbieter mit Rechenzentrum in Deutschland, der Support-Zugriffe, Logs oder Analytics über ein Drittland leitet, kann trotzdem durch die Prüfung fallen. Ein Anbieter mit mehreren EU-Standorten und sauber dokumentierter Verarbeitung kann sie bestehen. Die Fragen werden präziser:
- Wo werden personenbezogene Daten verarbeitet, gespeichert und geloggt?
- Welche Unterauftragsverarbeiter sind beteiligt, und wo sitzen sie?
- Kannst du Standorte wählen oder einschränken, oder entscheidet der Anbieter für dich?
Nichts davon ersetzt deine Datenschutzbeauftragten oder die Rechtsberatung. Es erklärt aber, warum Einkaufsteams diese Fragen inzwischen an jedes System stellen, das Kundenkontakt hat, nicht nur an das Backend.
Im Frontend entsteht der erste Personenbezug
Architektur-Diskussionen behandeln Compliance oft als Backend-Thema: Kundendatenbank, Bestellsystem, ERP. In der Praxis passiert der erste Kontakt mit personenbezogenen Daten früher, im Frontend-Layer.
- Rendering: Jeder serverseitig gerenderte Request trägt eine IP-Adresse, Header und oft Cookies. Nach DSGVO kann schon eine IP-Adresse ein personenbezogenes Datum sein. Wo dein SSR läuft und wo seine Logs landen, ist eine Souveränitätsfrage.
- Edge: Edge-Auslieferung bringt Inhalte nah an die Nutzer. Gecachte, nicht personenbezogene Assets sind selten das Problem. Personalisierte Antworten, Geo-Logik oder Session-Handling an der Edge schon, weil dort nutzerbezogene Daten verarbeitet werden.
- Consent: Das Consent-Banner ist eine Frontend-Komponente. Ob ein Tag vor oder nach der Entscheidung der Nutzer feuert, entscheidet der Frontend-Code, nicht der Vertrag.
- Tracking: Pixel, Tag Manager und Analytics-Skripte können Daten direkt aus dem Browser an Dritte schicken. Jedes Skript, das die Storefront lädt, ist eine mögliche Übermittlung, die du erklären musst.
Rechne externe Fonts, eingebettete Videos, Chat-Widgets und Test-Skripte dazu, und das Frontend wird schnell zur geschäftigsten Verarbeitungsfläche im ganzen Stack. Lädt die Storefront vor dem Consent ein Skript von einem Nicht-EU-Dienst, hilft das EU-Hosting des Backends nicht weiter.
Vier Fragen an deinen Frontend-Layer
Egal ob du eine neue Frontend-Plattform bewertest oder deine bestehende Storefront prüfst, diese vier Fragen decken die Souveränitätsfläche ab:
- Wo läuft das Rendering? Frag nach den Hosting-Standorten von SSR und Edge-Funktionen und danach, wo Request-Logs liegen und wie lange.
- Was passiert an der Edge? Trenne gecachte Auslieferung von der Verarbeitung von Nutzerdaten und prüfe, welche Standorte personalisierte Requests bearbeiten.
- Wird Consent im Komponenten-Layer durchgesetzt? Tracking und Drittanbieter-Skripte sollten erst nach Einwilligung laden, als Eigenschaft der Komponenten, nicht als manuelle Regel pro Seite.
- Wer bekommt die Tracking-Daten? Kläre, ob Events direkt vom Browser an Dritte gehen oder über eine First-Party- oder serverseitige Schicht, die du kontrollierst.
Ein Anbieter, der mit Dokumentation statt mit Zusicherungen antwortet, verkürzt die Prüfung deutlich. Die Mess-Seite haben wir in unserem Beitrag zu Server-Side Tracking im Komponenten-Schema ausführlich behandelt.
Wie Laioutr den Frontend-Layer angeht
Laioutr ist eine Frontend Management Platform (FMP), die sich auf deine bestehenden Commerce- und Content-Systeme setzt. Als Composable Digital Experience Platform entkoppelt Laioutr das Frontend vom Backend, sodass du Hosting-Entscheidungen für das Frontend eigenständig treffen kannst.
- Cloud: Mit Laioutr Cloud (Edge Hosting, separat buchbar) laufen Storefronts über 100+ Edge-Standorte, mit 99,99 % SLA und einer TTFB unter 50 ms. Details findest du beim Edge Hosting.
- Enterprise: Im Enterprise-Setup kommen zusätzliche Rechenzentrumsstandorte in der EU, den USA, Kanada und Australien dazu. Darüber hinaus kannst du über Hyperscaler-Adapter veröffentlichen oder das Frontend auf eigener Infrastruktur betreiben.
- Tracking: Die Tracking-Basis über das Komponenten-Schema ist inklusive. Events werden einmal in den Komponenten definiert, statt über Tag-Regeln verstreut zu sein. Server Side Tracking gibt es als Add-on. Mehr dazu unter Tracking & Analytics.
- Performance: Standortentscheidungen müssen keine Geschwindigkeit kosten. Live-Frontends erreichen im Median einen LCP von 1,2 s, mehr unter Performance und Core Web Vitals.
Welches Setup zu deinen Anforderungen passt und ob es deinen internen Richtlinien genügt, klärst du am besten mit deinem Datenschutz-Team. Wir gehen die Architektur gern gemeinsam mit ihnen durch.
FAQ
Macht EU-Hosting eine Storefront DSGVO-konform?
Nicht allein. DSGVO-Konformität hängt an der ganzen Verarbeitungskette: welche Daten erhoben werden, auf welcher Rechtsgrundlage, welche Unterauftragsverarbeiter beteiligt sind und wie Consent umgesetzt wird. EU-Hosting senkt Übermittlungsrisiken, aber das Frontend entscheidet weiterhin, welche Skripte laden und welche Daten den Browser verlassen. Dieser Beitrag ist keine Rechtsberatung.
Brauche ich On-Premise-Hosting für Datensouveränität?
Laut Studie bevorzugen weniger als 9 % der DACH-Käufer On-Premise. Die meisten wollen gemanagte Cloud-Services unter EU-Recht. Über Hyperscaler-Adapter zu veröffentlichen oder das Frontend auf eigener Infrastruktur zu betreiben, sind Optionen zwischen beiden Modellen.
Ist Edge-Auslieferung ein Problem für Datensouveränität?
Nicht grundsätzlich. Gecachte, nicht personenbezogene Inhalte von Edge-Standorten auszuliefern ist etwas anderes, als dort Nutzerdaten zu verarbeiten. Kläre, welche Requests Personenbezug haben und wo genau diese bearbeitet werden.
Warum sollten sich Frontend-Teams mit der DSGVO beschäftigen?
Weil im Frontend Consent durchgesetzt wird und Tracking-Skripte laden. Entscheidungen über Rendering, Edge-Logik und Drittanbieter-Skripte fallen im Frontend-Code, also gestalten Frontend-Teams die Compliance direkt mit.
Nächste Schritte
Wenn Datensouveränität auf deiner Einkaufs-Checkliste steht, starte mit den vier Fragen oben und kartiere, wo der erste Personenbezug in deiner Storefront entsteht. Wenn du sehen willst, wie Rendering, Edge und Tracking in einem Composable Headless Frontend getrennt sind, buch eine Demo mit unserem Team.