Mehr als eine Compliance-Anforderung: Warum Datensouveränität zum neuen strategischen Vorteil wird

Die Diskussion darüber, ob AI im Kundenservice funktioniert, ist vorbei. Die Use Cases sind klar, die Technologie ist ausgereift. Offen bleibt jedoch die Frage, wer tatsächlich die Kontrolle hat. Dabei geht es nicht nur um die AI-Modelle selbst, sondern vor allem um die Kundendaten, die sie verarbeiten. Wenn diese Daten mit einer AI-Plattform geteilt werden: Wer kontrolliert sie? Wo werden sie verarbeitet? Wer hat Zugriff darauf? Und welches Recht gilt letztlich für diese Daten? 

Viele Unternehmen gehen davon aus, dass ihre Richtlinien zur Datenresidenz diese Fragen bereits beantworten. Das ist jedoch nicht der Fall. Datenresidenz legt fest, wo Daten gespeichert werden. Datensouveränität beschreibt dagegen, wer die Kontrolle über die Daten hat, wie sie verwaltet werden und welchen rechtlichen Rahmenbedingungen sie unterliegen. Das eine betrifft den Speicherort, das andere die Kontrolle. 

Mit der Einführung von AI-Systemen in der Customer Experience (CX) müssen Unternehmen genau verstehen, wie Kundendaten durch verschiedene Plattformen fließen, wo die AI-Verarbeitung stattfindet und wer während des gesamten Lebenszyklus jeder Kundeninteraktion die Kontrolle über diese Daten behält. 

Datensouveränität ist eine der wichtigsten Architekturentscheidungen, die ein Unternehmen trifft, auch wenn dieses Thema in Produktdemos oder auf Konferenzen nur selten im Mittelpunkt steht. Denn davon hängt ab, wie viel Kontrolle ein Unternehmen behält, während sich seine AI-Strategie weiterentwickelt. 

Warum Datensouveränität jetzt wichtig ist

Viele Organisationen unterschätzen, wie schnell Datensouveränität zu einem strategischen Thema geworden ist. Bis vor Kurzem wurden die meisten AI-Anwendungen nur in Pilotprojekten, zur Steigerung interner Produktivität oder in wenig kritischen Kundeninteraktionen eingesetzt. Entsprechend waren die Folgen einer unzureichenden Data-Governance relativ überschaubar. Mit AI im Kundenservice hat sich das grundlegend geändert. AI ist kein Backoffice-Tool, das anonymisierte Daten verarbeitet. Vielmehr nutzt AI hochsensible Informationen deiner Kund:innen, wie Kontodaten, Zahlungshistorien, Gesundheitsdaten, Versicherungsansprüche oder Daten zur Identitätsprüfung. Und das in großem Umfang, in Echtzeit und über alle Märkte hinweg, in denen dein Unternehmen tätig ist. Wenn ein solches System eine Länder- oder Rechtsgrenze überschreitet, die es nicht überschreiten sollte, ist das Risiko keineswegs nur theoretisch. Es untergräbt das Kundenvertrauen und setzt das Unternehmen regulatorischen Maßnahmen aus. 

Gleichzeitig wird die globale AI-Landschaft immer fragmentierter. Regierungen verfolgen unterschiedliche Ansätze bei der AI-Regulierung, der Infrastruktur und der Data-Governance. Dadurch wird es für Unternehmen zunehmend schwieriger, auf eine einzige globale Deployment-Strategie zu setzen. Gartner prognostiziert, dass 35% aller Länder bis 2027 auf regionsspezifische AI-Plattformen angewiesen sein werden; heute sind es erst 5%. Besonders relevant ist dabei: Ausgerechnet die Branchen, die am stärksten von Anforderungen an die Datensouveränität betroffen sind, profitieren auch am meisten von AI im Kundenservice. McKinsey schätzt, dass etwa 40% des wirtschaftlichen Potenzials von AI auf einer souveränen oder ausreichend souveränen Infrastruktur beruhen. Dazu zählen Finanzdienstleistungen, das Gesundheitswesen, Versicherungen und die Telekommunikationsbranche. Dort, wo das größte Potenzial liegt, sind auch die Anforderungen am höchsten. 

Wie Regulierung die Architektur beeinflusst

Datensouveränität ist eine grundlegende Design-Entscheidung für jedes AI-Programm und sollte deshalb früh getroffen werden. Denn die Architektur lässt sich später nur schwer ändern. Wer sie von Anfang an einplant, erspart sich später aufwendige Anpassungen. 

AI-Architekturen sind nicht so modular aufgebaut wie klassische Software. Das Modell definiert, wie Daten weitergeleitet werden. Die Datenweiterleitung bestimmt, welche Einblicke in das System möglich sind. Und diese Einblicke legen fest, was Compliance-Teams überhaupt prüfen können. Diese Entscheidungen greifen schon früh in einem AI-Projekt ineinander. Anders als bei klassischer Software lassen sich Komponenten in einer AI-Architektur nicht einfach austauschen. Stattdessen muss häufig auf einer Grundlage neu aufgebaut werden, die bereits produktiv im Einsatz sowie abgesichert ist und Kundendaten in großem Umfang verarbeitet. 

Wie diese Architekturentscheidungen getroffen werden, hängt maßgeblich davon ab, wo eine Plattform gebaut wurde. Europäische Anbieter entwickeln Enterprise-Software seit 2018 unter den Vorgaben der DSGVO. Deshalb gehören Datenisolierung, Datenaufbewahrung, Auditierbarkeit und Governance dort von Anfang an zur Architektur. Plattformen, die unter weniger strengen regulatorischen Anforderungen gebaut wurden, haben zunächst auf Geschwindigkeit gesetzt. Heute versuchen sie, Funktionen für Datensouveränität nachträglich in Architekturen zu integrieren, die ursprünglich nicht dafür ausgelegt waren. Zwei AI-Plattformen können auf den ersten Blick ähnliche Funktionen bieten. Doch ihre Grundlage unterscheidet sich deutlich: Die eine hat Datensouveränität von Anfang an berücksichtigt, die andere musste sie nachträglich ergänzen.

Diese frühen Architekturentscheidungen werden zu einem festen Bestandteil der Systeme, auf die Unternehmen angewiesen sind, wenn regulatorischer, operativer oder geopolitischer Druck zunimmt. Sie erleichtern es, auf neue regulatorische Anforderungen zu reagieren, Abhängigkeiten von einzelnen AI-Anbietern zu vermeiden und den Einsatz autonomer AI-Anwendungen auszubauen. Die notwendigen Guardrails sind bereits in der Architektur verankert. 

Deshalb sind Unternehmen, die Datensouveränität von Beginn an berücksichtigen, deutlich flexibler als solche, die sie erst später nachrüsten.

5 Fragen, die du AI-Anbietern stellen solltest, bevor du dich entscheidest

Immer wieder zeigt sich das gleiche Muster: Datensouveränität wird erst dann zum Thema für Legal oder Procurement, wenn viele Architekturentscheidungen bereits getroffen wurden.  

Das ist zu spät.

Mein Rat an jede:n Enterprise-Buyer: Stelle sicher, dass du diese Fragen beantworten kannst, bevor du einen Anbieter in die engere Auswahl nimmst oder einen Proof of Concept startest:

Wo findet die AI-Verarbeitung tatsächlich statt?

Nicht dort, wo die Daten gespeichert werden, sondern dort, wo das Modell sie verarbeitet. Das ist häufig nicht derselbe Ort. Entscheidend ist der Ort der Verarbeitung. Denn er bestimmt, welchem Rechtsraum die Daten unterliegen. 

Erfolgt dein Deployment in einer Single-Tenant- oder Multi-Tenant-Umgebung? 

Eine logische Trennung ist nicht dasselbe wie eine physische Isolation. In regulierten Branchen wird dein Compliance-Team wissen wollen, ob die Kundendaten physisch von den Daten anderer Organisationen getrennt sind. 

Wer hat die Kontrolle über die Encryption-Schlüssel? 

Wenn dein Anbieter die Schlüssel verwahrt, gilt das auch für jede Regierung, die Jurisdiktion über diesen Anbieter hat. Customer-Managed Encryption Keys (CMEK) verändern diese Situation von Grund auf. Ein AI-Modell benötigt zwar kurzfristig Zugriff, um eine Live-Interaktion zu verarbeiten. Aber wenn du deine eigenen Schlüssel hältst, kontrollierst du die gespeicherten Daten, einschließlich Gesprächsprotokollen, Transkripten und Vektordatenbanken. Widerrufst du deine Schlüssel, werden diese Daten sofort für alle unzugänglich; auch für deinen Anbieter. Das gibt dir die Möglichkeit, deine gespeicherten Daten jederzeit mit sofortiger Wirkung zu sperren.

Ist deine AI-Architektur von einem einzelnen Modell abhängig? 

Die Modell-Abhängigkeit ist eine Frage der Datensouveränität. Denn ein einzelner Modell-Anbieter bedeutet zugleich einen einzelnen Kontrollpunkt für dein gesamtes AI-Programm. Dessen Bedingungen, Preise und geopolitisches Umfeld können sich jederzeit ändern. Eine modellunabhängige Infrastruktur, bei der die Agent-Ebene vom zugrunde liegenden LLM entkoppelt ist, schützt vor dieser Abhängigkeit. Gartner empfiehlt deshalb, modellunabhängige Workflows mit Orchestrierungsebenen zu entwickeln, damit Unternehmen je nach Region zwischen verschiedenen LLMs wechseln können. 

Welchen regulatorischen Hintergrund hat der Anbieter?

Ein Anbieter von AI-Plattformen und -Lösungen, der seit 2018 unter den Vorgaben der DSGVO arbeitet, musste sich mit den entscheidenden Fragen bereits auseinandersetzen: Wohin werden Protokolle gespeichert? Wie werden Embeddings abgelegt? Welche Drittanbieterdienste sind zulässig? Und welche Regeln gelten standardmäßig für die Datenspeicherung? Dieses Wissen steckt in Architekturentscheidungen, die über Jahre hinweg entstanden sind und sich später nur schwer nachrüsten lassen. 

Anbieter sollten in der Lage sein, diese Fragen von Anfang an zu beantworten. Können sie das nicht, solltest du hinterfragen, ob Datensouveränität von Beginn an integriert wurde oder überhaupt Teil der Architektur ist. 

Datensouveränität gehört von Anfang an zur AI-Strategie 

AI kommt in immer komplexeren Customer Journeys, stärker regulierten Umgebungen und bei geschäftskritischen Entscheidungen zum Einsatz. Gerade deshalb sollten Unternehmen das Thema Datensouveränität nicht erst am Ende eines Projekts als reine Compliance-Frage behandeln. Stattdessen sollte bereits bei der Planung der AI-Architektur festgelegt werden, wie Daten geschützt, verarbeitet und kontrolliert werden. Wer Datensouveränität von Anfang an berücksichtigt, schafft die Grundlage für einen sicheren und rechtskonformen Einsatz von AI. 

Die Frage ist nicht, ob Datensouveränität wichtig wird. Entscheidend ist, ob du dich früh genug damit beschäftigst – bevor sich herausstellt, dass ein Pilotprojekt, das zunächst erfolgreich schien, an einer Compliance-Prüfung scheitert, auf die es nie ausgelegt war. 

Je stärker AI in regulierten Kundeninteraktionen zum Einsatz kommt, desto weniger darf Datensouveränität erst nachträglich berücksichtigt werden. Erfahre mehr über die fünf Fragen, die du jedem AI-Anbieter stellen solltest, bevor du dich entscheidest.