Datenhoheit ist mehr als lokales Hosting

Der Ort eines Servers sagt, wo Daten verarbeitet werden. Datenhoheit zeigt, wer Verarbeitung bestimmen, prüfen, begrenzen, übertragen und beenden kann.

„Wir betreiben das System lokal, deshalb sind die Daten sicher" klingt beruhigend. Die Aussage verwechselt jedoch Standort mit Kontrolle. Ein Server kann im eigenen Gebäude stehen und trotzdem über schwache Administratorrechte, unverschlüsselte Sicherungen, unkontrollierte Updates oder undokumentierte Fernzugriffe verfügen. Umgekehrt kann ein externer Dienst technische und organisatorische Kontrollen bieten, die eine kleine Organisation allein kaum betreiben könnte – und dennoch Abhängigkeiten, Unterauftragnehmer oder internationale Übermittlungen erzeugen, die bewusst bewertet werden müssen.

Datenhoheit ist deshalb keine Eigenschaft eines Rechenzentrums. Sie ist die nachweisbare Fähigkeit einer Organisation, über Daten und abgeleitete Artefakte während des gesamten Lebenszyklus wirksam zu bestimmen. Dazu gehören Eingaben, Dokumente, Embeddings, Zwischenspeicher, Protokolle, Backups, Modelle, Konfigurationen und Ausgaben. Wer nur den primären Speicher betrachtet, übersieht häufig den größeren Teil der tatsächlichen Verarbeitung.

Lokal beschreibt eine Platzierung, keine Vertrauensstufe

On-Premises, Private Cloud, Public Cloud, Edge und Hybrid sind Bereitstellungsmodelle. Keines ist automatisch sicher, souverän oder ungeeignet. Das Risiko entsteht aus dem Zusammenspiel von Datenklasse, Zweck, Architektur, Zugriff, Lieferkette, Betrieb und Rechtsraum.

NIST Zero Trust formuliert dafür einen hilfreichen Grundsatz: Vertrauen entsteht nicht allein aus physischem oder netzwerktechnischem Standort. Ein Gerät im internen Netz kann kompromittiert sein; ein privilegiertes Konto kann missbraucht werden; ein lokaler Dienst kann Pakete oder Telemetrie aus externen Quellen beziehen. Jede Anfrage braucht deshalb eine begründete, begrenzte und überprüfbare Autorisierung.

Die bessere Frage lautet nicht: „Ist es lokal?" Sie lautet: „Welche Kontrollbehauptung können wir für diesen Datenfluss belegen?"

Datenhoheit besitzt sechs Kontrolldimensionen

Eine belastbare Bewertung trennt mindestens sechs Dimensionen:

1 · Rechtliche und vertragliche Kontrolle: Wer ist für welchen Zweck verantwortlich, wer verarbeitet im Auftrag, welche Unterauftragnehmer und Regionen sind beteiligt?

2 · Technische Kontrolle: Welche Systeme speichern, übertragen oder transformieren Daten, und wie werden Schnittstellen, Mandanten und Umgebungen getrennt?

3 · Operative Kontrolle: Wer darf konfigurieren, aktualisieren, wiederherstellen, überwachen und Störungen bearbeiten?

4 · Kryptografische Kontrolle: Wer besitzt Schlüssel, darf sie verwenden, rotieren, sperren oder vernichten?

5 · Portabilitäts- und Exit-Kontrolle: Können Daten, Metadaten, Regeln, Protokolle und Abhängigkeiten vollständig exportiert und anderswo weiterbetrieben werden?

6 · Nachweis- und Auditkontrolle: Kann die Organisation Zugriff, Änderung, Löschung und Ausnahme mit belastbarer Evidenz rekonstruieren?

Eine Plattform kann in einer Dimension stark und in einer anderen schwach sein. Ein „Souveränitäts-Score" ohne diese Aufschlüsselung verschleiert eher, als dass er entscheidet.

Erst die Datenreise abbilden, dann die Plattform bewerten

Vor einer Architekturentscheidung entsteht eine Data Flow Map. Sie erfasst Quelle, Zweck, Datenklasse, Übertragung, Verarbeitung, Speicherung, abgeleitete Artefakte, Empfänger, Aufbewahrung und Löschpfad. Für KI-Anwendungen gehören auch Prompt-Verläufe, Suchindizes, Vektorrepräsentationen, Caches, Evaluationsdaten, Sicherheitsprotokolle, Support-Dumps und Telemetrie dazu.

Ein lokal ausgeführtes Modell kann beispielsweise Dokumente auf dem eigenen Rechner verarbeiten, aber Erweiterungen aus externen Paketquellen laden. Ein Suchdienst kann Inhalte lokal halten, jedoch Embeddings über eine entfernte Schnittstelle erzeugen. Ein Supportprozess kann Protokolle aus einer europäischen Umgebung in ein globales Ticketsystem kopieren. Souveränität wird an diesen Übergängen entschieden, nicht am Marketingetikett des Hauptsystems.

Die Karte muss Soll und Ist unterscheiden. Architekturdiagramme zeigen häufig nur vorgesehene Verbindungen. Netzwerkbeobachtung, Konfigurationsprüfung, Lieferanteninformationen und Tests zeigen, welche Verbindungen tatsächlich existieren.

Rollen und Verträge müssen die technische Realität abbilden

Datenschutzrechtliche Rollen sind keine frei wählbaren Produktbezeichnungen. Verantwortlichkeit und Auftragsverarbeitung ergeben sich aus tatsächlichen Zwecken und Entscheidungsmöglichkeiten. Verträge sollten Verarbeitung, Weisungen, Vertraulichkeit, Sicherheit, Unterauftragnehmer, Unterstützung, Rückgabe, Löschung und Prüfrechte so beschreiben, dass sie zur realen Architektur passen.

Eine Liste von Unterauftragnehmern ist nur der Anfang. Relevant sind deren Aufgabe, Datenzugriff, Standort, Wechselverfahren und technische Begrenzung. Wenn ein Anbieter seine Lieferkette ändert, braucht die Organisation eine definierte Bewertung und gegebenenfalls Widerspruchs- oder Exit-Optionen. Papierkontrolle ohne technische Überprüfung ist ebenso unvollständig wie technische Kontrolle ohne klare Verantwortlichkeit.

Identität ist die neue Grenze

Ein internes Netz ist keine Identität. Zugriff wird an Personen, Dienste, Geräte und Workloads gebunden. Least Privilege, starke Authentisierung, zeitlich begrenzte Administratorrechte, getrennte Servicekonten und überprüfte Machine Identities reduzieren die Wirkung kompromittierter Zugangsdaten.

Besonders kritisch sind Break-Glass-Konten, Supportzugänge und Automationsschlüssel. Sie brauchen Owner, Zweck, Ablaufdatum, Protokollierung und regelmäßige Rezertifizierung. Ein lokaler Administrator mit dauerhaftem Vollzugriff kann ein größeres Risiko sein als ein eng begrenzter externer Dienst. Umgekehrt darf ein Cloud-Kontrollpanel nicht zur einzigen ungeschützten Schaltstelle für Daten, Schlüssel und Backups werden.

Verschlüsselung ist erst mit Schlüsselkontrolle aussagekräftig

„Verschlüsselt" beantwortet nicht, wer entschlüsseln kann. Zu unterscheiden sind Transportverschlüsselung, Verschlüsselung ruhender Daten, anwendungsseitige Verschlüsselung und Schlüsselverwaltung. Provider-managed Keys erleichtern den Betrieb, können dem Betreiber aber technisch breite Möglichkeiten lassen. Customer-managed Keys verlagern Kontrolle, erzeugen jedoch eigene Pflichten für Rotation, Backup, Berechtigung, Verfügbarkeit und Notfallwiederherstellung.

Entscheidend ist die Key-Custody-Kette: Wer erzeugt den Schlüssel? Wo liegt er? Wer kann Nutzung genehmigen? Welche Protokolle entstehen? Was geschieht bei Rollenwechsel, Vorfall oder Vertragsende? Ein Schlüssel, den niemand zuverlässig wiederherstellen kann, bedroht Verfügbarkeit. Ein Schlüssel, den zu viele Personen exportieren können, bedroht Vertraulichkeit.

Lokaler Betrieb hat eigene Fehlermuster

Lokale Systeme reduzieren bestimmte externe Datenflüsse und können für abgeschottete oder latenzkritische Szenarien sinnvoll sein. Sie übertragen aber Verantwortung auf die Organisation. Patchstände, Hardwareausfall, physischer Schutz, Endpoint-Sicherheit, Backup-Trennung, Monitoring, Incident Response und Personalvertretung müssen tatsächlich geleistet werden.

Typische Schwächen sind gemeinsame Administratorkonten, Sicherungen im selben Brandabschnitt, fehlende Wiederherstellungstests, veraltete Abhängigkeiten und unbemerkte Telemetrie. „Kein Internetzugang" hilft nur, wenn Softwareversorgung, Datentransfer und Wartung kontrolliert gelöst sind. Ein USB-Datenträger oder improvisierter Fernzugriff kann die vermeintliche Grenze sofort umgehen.

Cloud-Betrieb verschiebt Verantwortung, er beseitigt sie nicht

Cloud-Dienste können professionelle Sicherheitsfunktionen, Redundanz, Automatisierung und schnelle Skalierung bieten. Die Organisation bleibt dennoch für Datenklassifikation, Konfiguration, Identitäten, Zweck, Berechtigungen und Lieferantenauswahl verantwortlich. Fehlkonfigurierte Speicher, überbreite Rollen oder unkontrollierte Exporte werden nicht durch Zertifikate geheilt.

Zu bewerten sind Mandantentrennung, Regionen, Supportzugriff, Telemetrie, Subprozessoren, Schlüsseloptionen, Wiederherstellung, Verfügbarkeit und Vertragsänderungen. Internationale Übermittlungen sind eine eigene rechtliche und technische Frage; der Name einer Region allein beweist nicht, dass jeder Zugriff und jeder Folgeprozess dort verbleibt.

Hybridarchitektur braucht explizite Vertrauensgrenzen

Hybrid ist nicht automatisch der sichere Mittelweg. Es vervielfacht Schnittstellen, Identitäten, Synchronisation und Betriebsmodelle. Für jede Grenze muss klar sein, welche Daten passieren, wer die Übertragung startet, wie Inhalte gefiltert werden, was bei Verbindungsabbruch geschieht und welche Seite führend ist.

Ein sinnvolles Muster ist, Rohdaten in einer kontrollierten Zone zu halten und nur minimierte, freigegebene Artefakte in eine andere Zone zu übertragen. Das funktioniert aber nur, wenn Transformation und Re-Identifikationsrisiko geprüft werden. Auch Embeddings oder aggregierte Merkmale können sensible Information enthalten; „abgeleitet" bedeutet nicht automatisch „anonym".

Löschung umfasst Kopien und Ableitungen

Eine Schaltfläche „Datensatz löschen" beweist keine vollständige Löschung. Ein Löschkonzept unterscheidet produktive Daten, Replikate, Caches, Suchindizes, Logs, Backups und abgeleitete Artefakte. Es definiert Fristen, Ausnahmen, technische Umsetzung, Wiederherstellungseffekt und Nachweis.

Backups lassen sich häufig nicht punktuell verändern, ohne ihre Integrität zu gefährden. Dann braucht es eine begründete Aufbewahrungslogik, Zugriffssperren und Regeln, die gelöschte Datensätze bei einer Wiederherstellung erneut entfernen. Für trainierte oder feinabgestimmte Modelle ist zu klären, ob Daten rekonstruierbar sind, ob ein Modellartefakt ersetzt werden muss und welche Löschbehauptung fachlich überhaupt belegbar ist.

Exit-Fähigkeit ist ein Bestandteil der Architektur

Souveränität zeigt sich, wenn eine Beziehung endet. Ein Exit Plan nennt exportierbare Datenformate, Metadaten, Identitäten, Schlüssel, Regeln, Konfigurationen, Protokolle, Modelle, Lizenzen und Abhängigkeiten. Er enthält Fristen, Kosten, Verantwortliche, Parallelbetrieb, Validierung und Löschbestätigung.

Ein CSV-Export reicht selten. Ohne Schemata, Beziehungen, Versionshistorie und Provenienz kann der Inhalt fachlich unbrauchbar sein. Proprietäre Schnittstellen und verwaltete Spezialdienste erhöhen Wechselkosten. Diese Abhängigkeiten sind nicht grundsätzlich falsch; sie müssen vor der Einführung sichtbar, bewertet und getestet werden. Ein jährlicher Testexport ist überzeugender als eine unverprobte Vertragsklausel.

Kontrolle muss gemessen und nach Änderungen erneuert werden

Eine Architekturentscheidung ist kein Dauerzertifikat. Neue Modelle, Regionen, Pakete, Subprozessoren, Administrationsrollen und Logging-Funktionen verändern den Kontrollzustand. Deshalb erhalten kritische Datenflüsse Owner, Kontrollziel, Test, Evidenz, Prüfintervall und Eskalationsregel.

Messbar sind etwa verwaiste privilegierte Konten, Schlüsselalter, fehlgeschlagene Wiederherstellungstests, unklassifizierte Exporte, nicht genehmigte Endpunkte, Löschrückstände und Zeit bis zum Widerruf eines Zugriffs. Ein Architecture Decision Record hält Annahmen, Alternativen, Gründe, Restunsicherheiten und Exit-Bedingungen fest. Änderungen lösen eine gezielte Neubewertung aus.

Methode: MAP → CLASSIFY → CONTROL → VERIFY → EXIT → REVIEW

MAP bildet echte Datenflüsse und Ableitungen ab. CLASSIFY ordnet Zweck, Sensitivität, Rollen und Folgen zu. CONTROL setzt Identität, Schlüssel, Berechtigungen, Aufbewahrung und Verträge um. VERIFY prüft Konfiguration, Verhalten, Wiederherstellung, Löschung und Evidenz. EXIT testet Portabilität und Beendigung. REVIEW bewertet Veränderungen, Vorfälle und Wirksamkeit.

Das Ergebnis ist keine pauschale Empfehlung für lokal oder Cloud. Es ist eine begründete Architekturentscheidung, in der jede wesentliche Kontrollbehauptung einen Owner und einen Nachweis besitzt.

Übungsblatt: Erstelle eine Data Sovereignty Control Map

1. Wähle einen realen KI-Datenfluss und zeichne Quelle, Verarbeitung, Speicherung, Ableitungen und Empfänger.

2. Klassifiziere Rohdaten, Prompts, Embeddings, Logs, Backups und Ausgaben getrennt.

3. Ordne für jede Station Owner, Betreiber, Region, Identität und Schlüsselverantwortung zu.

4. Formuliere je eine Kontrolle für Zugriff, Übertragung, Aufbewahrung, Löschung und Änderung.

5. Definiere Evidenz: Welche Prüfung beweist, dass die Kontrolle tatsächlich wirkt?

6. Simuliere einen Anbieterwechsel oder Systemausfall und dokumentiere Export, Wiederanlauf und Löschung.

7. Benenne drei Restunsicherheiten und entscheide, wer sie bis wann klärt.

Alle Materialien zum Download – die Themenübersicht und das Übungsblatt:

Einordnung: Der Beitrag bietet ein Architektur- und Kontrollmodell, keine Rechtsberatung. Ob und welche Pflichten gelten, hängt von Rollen, Daten, Zweck, Region und Risikoklasse ab. „Lokal", „Cloud" und „hybrid" sind Bereitstellungsformen, keine pauschalen Qualitäts- oder Compliance-Siegel.

Quellen und fachliche Einordnung