Wem gehören die Datenräume der KI?

KI entsteht nicht nur in einem Modell. Sie entsteht in einem Raum aus Quellen, Katalogen, Schnittstellen, Identitäten, Verträgen, Merkmalen, Vektoren, Protokollen und abgeleiteten Produkten. Sobald mehrere Organisationen beteiligt sind, reicht die Frage „Wo liegen die Daten?" nicht mehr. Der Speicherort sagt wenig darüber aus, wer rechtmäßig verfügen, technisch kontrollieren oder wirtschaftlich profitieren darf.

Die Frage „Wem gehört der Datenraum?" ist deshalb absichtlich unbequem. Sie zeigt, dass Eigentum als alleinige Kategorie zu grob ist. Daten lassen sich kopieren, kombinieren und gleichzeitig nutzen. Personenbezogene Daten sind keine Sache, die eine Organisation wie einen Tisch besitzt. Geschäftsgeheimnisse, urheberrechtliche Inhalte, Datenbankleistungen, vertragliche Rechte und gesetzliche Zugangsansprüche können denselben Bestand unterschiedlich prägen.

Ein tragfähiger Datenraum ersetzt die Suche nach dem einen Eigentümer durch eine Landkarte von Rechten, Pflichten, Kontrolle und Verantwortung.

Datenraum bedeutet Föderation, nicht Zentralspeicher

Ein Datenraum ist kein besonders großer Data Lake. In einer föderierten Architektur können Datensätze bei ihren Anbietern bleiben. Gemeinsame Identitäten, Kataloge, Vertragsmodelle, Policy-Regeln und Vertrauensdienste machen sie auffindbar und unter Bedingungen nutzbar. Austausch kann als Download, API, sichere Rechenumgebung, Query oder abgeleitetes Ergebnis erfolgen.

Diese Trennung ist wichtig: Ein Katalogeintrag ist noch kein Datenzugang, eine Zugangsberechtigung noch keine beliebige Nutzung und ein technischer Transfer noch keine Rechtsgrundlage. Auch die zentrale Plattform wird nicht automatisch Eigentümerin aller Inhalte, nur weil sie Metadaten oder Transaktionen vermittelt.

Föderation verteilt Macht, beseitigt sie aber nicht. Wer Identitäten zulässt, Standards setzt, Policies prüft, Katalogranking steuert oder Teilnehmer ausschließt, kontrolliert wesentliche Teile des Raums. Governance muss deshalb auch die Betreiber der gemeinsamen Infrastruktur begrenzen.

Sieben Fragen sind präziser als „Wem gehören die Daten?"

Für jeden Datenbestand werden getrennt beantwortet:

1 · Herkunft: Wer oder was hat die Daten erzeugt, erhoben oder abgeleitet?

2 · Rechtliche Position: Welche Rechte, Pflichten, Schutzinteressen und Rechtsgrundlagen gelten?

3 · Entscheidungsbefugnis: Wer darf Zwecke, Empfänger, Laufzeit und Bedingungen bestimmen?

4 · Technische Kontrolle: Wer verwaltet Speicher, Schlüssel, Identitäten, Policies und Logs?

5 · Nutzungsumfang: Welche Handlungen sind erlaubt, verboten oder an Pflichten gebunden?

6 · Wertverteilung: Wer trägt Kosten, erhält Vergütung und profitiert von abgeleiteten Produkten?

7 · Exit: Wie werden Daten, Metadaten, Provenienz und Modelle portiert, zurückgegeben oder gelöscht?

Die Antworten können auf unterschiedliche Akteure zeigen. Der Datenanbieter kann einen Datensatz kontrollieren, eine betroffene Person besitzt Datenschutzrechte, ein Betreiber verarbeitet im Auftrag, ein Nutzer erhält einen engen Zweckzugang und eine Aufsichtsstelle darf prüfen.

Datenarten dürfen nicht vermischt werden

Ein KI-Datenraum enthält mindestens Rohdaten, kuratierte Datensätze, Metadaten, Embeddings, Feature Stores, Trainings- und Evaluationssätze, Modellparameter, Prompts, Outputs, Feedback, Protokolle und Nutzungsstatistiken. Jede Schicht besitzt eine eigene Herkunft und Risikostruktur.

Ein Embedding ist nicht automatisch anonym, nur weil es für Menschen nicht lesbar ist. Ein abgeleiteter Score kann personenbezogen sein, wenn er sich auf eine identifizierte oder identifizierbare Person bezieht. Synthetische Daten können Ursprungsinformationen preisgeben oder Rechte aus Ausgangsdaten berühren. Ein Modell kann Trainingsinhalte memorisieren, ohne eine Kopie des Trainingssatzes zu sein.

Deshalb braucht jedes Datenprodukt ein Manifest: Datenart, Quelle, Zeitraum, Version, Transformationskette, Personenbezug, Schutzklasse, Qualitätsgrenzen, zulässiger Zweck, verbotene Nutzung, Aufbewahrung und Löschweg.

Zugang ist nicht gleich Nutzung

Ein Partner kann einen Datensatz sehen, ohne ihn für Modelltraining nutzen zu dürfen. Er kann ihn analysieren, aber nicht weitergeben; ein Ergebnis erzeugen, aber keine Einzelwerte exportieren; ihn für einen Auftrag verwenden, aber nicht zur Produktverbesserung speichern.

Solche Grenzen gehören nicht nur in Fließtextverträge. Sie werden als testbare Policies, Rollen und technische Kontrollpunkte umgesetzt. Maschinenlesbare Policy-Modelle können Erlaubnisse, Verbote, Pflichten und zeitliche oder räumliche Constraints ausdrücken. Sie ersetzen keine juristische Prüfung, helfen aber, Vertrag und Ausführung miteinander zu verbinden.

Das Zugriffstoken referenziert daher Dataset-ID, Version, Zweck, erlaubte Operation, Empfänger, Ablaufzeit und Weitergaberegel. Eine neue Zwecksetzung benötigt eine neue Prüfung. „Zugang zum Datenraum" darf nie als Generalvollmacht wirken.

Der Katalog ist die Verfassungsschicht des Datenraums

Ohne gemeinsame Metadaten bleibt ein föderierter Raum unsichtbar. Ein Katalog beschreibt Datensätze und Datendienste, ihre Herausgeber, Themen, Schnittstellen, räumliche und zeitliche Abdeckung, Versionen und Zugangsbedingungen. Standardisierte Vokabulare wie DCAT erleichtern föderierte Suche und Austausch zwischen Katalogen.

Der Katalog darf jedoch nicht mehr versprechen als der Anbieter belegen kann. Qualitätsangaben benötigen Messmethode und Zeitpunkt. Verfügbarkeit, Aktualität und Lizenz werden versioniert. Ein Datensatz, dessen Policy geändert wurde, bleibt nicht unter derselben undifferenzierten Kennung im Umlauf.

Ranking und Suche sind Governance-Fragen: Wenn der Betreiber bestimmte Anbieter bevorzugt oder sensible Merkmale offenlegt, verändert er den Markt und das Risiko. Kriterien und Interessenkonflikte müssen transparent sein.

Identität und Vertrauen müssen überprüfbar bleiben

Teilnehmer benötigen mehr als Benutzername und Passwort. Der Datenraum muss Organisation, Rolle, Vertretungsbefugnis und relevante Nachweise prüfen. Vertrauensanker bestätigen Claims; sie garantieren aber nicht die Qualität jeder Transaktion. Auch ein korrekt identifizierter Teilnehmer kann Daten falsch nutzen.

Onboarding umfasst deshalb Identität, Policy-Akzeptanz, technische Tests, Mindestschutz und Ansprechpartner. Offboarding ist ebenso wichtig: Tokens werden widerrufen, laufende Transfers beendet, Aufbewahrungspflichten geklärt und Nachweise gesichert. Ein Teilnehmer darf nicht über vergessene Servicekonten weiter zugreifen.

Provenienz verbindet Quelle, Nutzung und Ergebnis

KI macht Datenketten länger. Ein Output kann aus Dokumenten, Tabellen, Sensorwerten, Retrieval-Ergebnissen und menschlichen Korrekturen entstehen. Ohne Provenienz lässt sich später kaum feststellen, welche Quelle eine Aussage, Entscheidung oder Modelländerung beeinflusst hat.

Ein Provenienzgraph referenziert Entitäten, Aktivitäten und verantwortliche Akteure. Er dokumentiert, welcher Datensatz in welcher Version durch welchen Prozess in welches Artefakt einfloss. Dabei wird nicht jede sensible Nutzlast in das Log kopiert. Stabile IDs, Hashes und geschützte Verweise reichen häufig aus.

Provenienz unterstützt Vergütung, Qualitätskorrektur, Löschfolgen und Streitklärung. Wird eine Quelle zurückgezogen oder als fehlerhaft erkannt, zeigt der Graph, welche Produkte neu bewertet werden müssen.

KI-Training braucht eine eigene Rechtekette

„Für Analyse freigegeben" bedeutet nicht automatisch „für Training freigegeben". Training erzeugt schwer rücknehmbare Ableitungen. Der Vertrag muss klären, ob Basismodell, Fine-Tuning, Evaluation, Retrieval-Index oder nur eine zeitlich begrenzte Auswertung erlaubt ist. Ebenso wichtig sind kommerzielle Nutzung, Weitergabe, Modellzugang, Sicherheitsforschung und Umgang mit Outputs.

Rechte werden bis zu den Quellen zurückverfolgt. Der Datenraum kann keine weitergehenden Befugnisse vergeben, als seine Teilnehmer besitzen. Fehlt ein belastbarer Nachweis, wird der Datensatz nicht stillschweigend in ein Trainingskorpus übernommen.

Bei personenbezogenen Daten bleiben Zweckbindung, Rechtsgrundlage, Transparenz, Datenminimierung und Betroffenenrechte maßgeblich. Vertragliche Zustimmung zwischen Organisationen schafft nicht automatisch eine datenschutzrechtliche Erlaubnis.

Der Data Act ordnet Zugang, nicht universelles Dateneigentum

Der EU Data Act enthält unter anderem Regeln zu Daten vernetzter Produkte und verbundener Dienste, zur Bereitstellung an Nutzer und Dritte sowie zum Wechsel zwischen Datenverarbeitungsdiensten. Er schafft damit konkrete Zugangs- und Nutzungskonstellationen. Daraus folgt kein pauschales Eigentumsrecht an allen erzeugten Daten.

Der Data Governance Act adressiert andere Bausteine, darunter die Weiterverwendung bestimmter geschützter Daten öffentlicher Stellen, Datenvermittlungsdienste und Datenaltruismus. Auch hier bleibt Datenschutzrecht anwendbar. Gute Architektur bildet diese Rechtsregime als differenzierte Policy-Profile ab, nicht als ein einziges Label „EU-konform".

Portabilität ist erst mit Exit vollständig

Souveränität zeigt sich nicht daran, dass ein Anbieter „Ihre Daten" verspricht. Sie zeigt sich beim Wechsel. Ein belastbarer Exit exportiert Primärdaten, Metadaten, Versionen, Policies, Provenienz, Qualitätsnachweise und relevante Konfigurationen in dokumentierten Formaten. Er nennt Fristen, Kosten, Unterstützung und Löschbestätigung.

Für KI kommen Vektorindizes, Evaluationsfälle, Feedbackhistorie und nachvollziehbare Modelladapter hinzu. Nicht alles ist übertragbar; proprietäre Laufzeitkomponenten können Grenzen setzen. Diese Grenzen müssen vor Vertragsbeginn sichtbar sein. Eine theoretische Exportdatei ohne Importpfad ist keine Portabilität.

Der Exit wird regelmäßig getestet. Teilnehmer messen Exportvollständigkeit, Wiederanlaufzeit, Funktionsverlust und Restabhängigkeiten. Offene Standards reduzieren Lock-in, garantieren aber ohne dokumentierte Semantik und Tests noch keinen funktionierenden Wechsel.

Ein Control Plane darf nicht zum heimlichen Eigentümer werden

Gemeinsame Dienste für Identität, Katalog, Policy, Abrechnung und Audit bilden den Control Plane. Er kennt viele Metadaten und kann den Zugang beeinflussen. Deshalb benötigt er Zweckbegrenzung, getrennte Rollen, transparente Regeln, Auditierbarkeit und die Möglichkeit, Komponenten auszutauschen.

Der Betreiber darf Transaktionsdaten nicht automatisch für eigene Modelle oder Marktanalysen verwenden. Sekundärnutzung braucht eine eigene Rechts- und Vertragsgrundlage. Logs werden nach Schutzbedarf minimiert und aufbewahrt; Manipulation wird verhindert, unbegrenzte Vorratsspeicherung aber ebenso.

Die Data-Space-Charta macht Rechte ausführbar

1 · INVENTORY: Datenprodukte, Ableitungen, Rollen und Systeme erfassen.

2 · CLASSIFY: Personenbezug, Schutzrechte, Geheimnisse, Wirkung und Qualität bewerten.

3 · AUTHORISE: Zweck, Operation, Empfänger, Dauer und Pflichten festlegen.

4 · CATALOGUE: standardisierte, versionierte und belegte Metadaten veröffentlichen.

5 · EXCHANGE: minimal nötige Daten über kontrollierte Schnittstellen bereitstellen.

6 · TRACE: Quelle, Policy, Aktivität und Ergebnis über Provenienz verbinden.

7 · ENFORCE: Verstöße stoppen, Tokens widerrufen und Vorfälle behandeln.

8 · SETTLE: Vergütung, Korrektur, Haftung und Streitwege regeln.

9 · EXIT: Portierung, Löschung, Nachweis und Offboarding testen.

Die Antwort auf die Titelfrage lautet daher: Der Datenraum gehört nicht einfach dem Betreiber, dem Datenlieferanten oder der KI. Er ist ein geregeltes Verhältnis zwischen Beteiligten. Souverän ist nicht, wer alles besitzt, sondern wer Rechte nachweisen, Grenzen durchsetzen, Abhängigkeiten verstehen und den Raum ohne Kontrollverlust verlassen kann.

Übungsblatt: Entwirf eine Data-Space Rights Map

1. Wähle ein Datenprodukt und trenne Rohdaten, Ableitungen, Metadaten, Outputs und Logs.

2. Ordne jeder Schicht Herkunft, rechtliche Position, Entscheider und technischen Controller zu.

3. Formuliere erlaubte Zwecke, verbotene Nutzungen, Pflichten und Ablaufzeit.

4. Definiere Katalogfelder, Qualitätsnachweis und Versionslogik.

5. Zeichne Identitäts-, Freigabe-, Austausch- und Provenienzpfad.

6. Beschreibe Vergütung, Incident-, Korrektur- und Streitprozess.

7. Führe einen Exit-Test mit Export, Import, Löschung und Nachweis durch.

Reflexion: Welche Stelle kann heute faktisch über Daten entscheiden, ohne ausdrücklich dazu legitimiert zu sein? Welche Information würde bei einem Anbieterwechsel unwiederbringlich verloren gehen?

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

Einordnung: „Eigentum an Daten" ist keine universelle juristische Kategorie. Je nach Datenart und Kontext überlagern sich Datenschutz, Geschäftsgeheimnisse, geistige Rechte, Datenbankrechte, Vertrag, Zugangspflichten und technische Kontrolle. Fachlich geprüft am 17. Juli 2026.