Exit aus der KI-Cloud: Datenportabilität, Anbieterwechsel und Lock-in nach dem Data Act

Exit-Umfang vor Vertragsschluss definieren

Der Begriff „alle Daten“ ist für einen Exit zu unbestimmt. Zu inventarisieren sind Eingaben, Ausgaben, hochgeladene Dokumente, strukturierte Fachdaten, Metadaten, Nutzer- und Berechtigungsdaten, Prompts, Vorlagen, Konfigurationen, Protokolle und Vektordatenbanken. Für jedes Objekt ist festzulegen, ob es exportierbar ist, wem Rechte daran zustehen und ob es für die Fortführung des Prozesses tatsächlich benötigt wird.

Kundenspezifische Anpassungen können von einfachen Einstellungen bis zu feinabgestimmten Komponenten reichen. Daraus folgt nicht automatisch ein Anspruch auf Herausgabe von Modellgewichten, proprietärer Plattformsoftware oder geschützten Werkzeugen des Anbieters. Leistungsbeschreibung und Vertrag müssen deshalb unterscheiden zwischen kundeneigenen Daten, exportierbaren digitalen Vermögenswerten, gemeinsam erzeugten Artefakten und Bestandteilen, die beim Anbieter verbleiben. Unklare Kategorien erzeugen später Lock-in und Streit.

• Daten und digitale Vermögenswerte einzeln inventarisieren
• Rechte, Exportfähigkeit und betriebliche Bedeutung zuordnen
• Modellgewichte nur bei klarer Leistungs- und Rechtsgrundlage einplanen

Quellen: [1]

Wechselregeln des Data Act einordnen

Der Data Act enthält Vorgaben zum Wechsel zwischen Datenverarbeitungsdiensten und gilt seit 12. September 2025. Für einen KI Cloud-Dienst ist zunächst zu prüfen, welche Leistung als Datenverarbeitungsdienst erfasst ist und wie die gesetzlichen Switching-Regeln auf Architektur und Vertrag wirken. Ein Schlagwort wie SaaS, Modellzugang oder Plattform entscheidet die Einordnung nicht allein; maßgeblich sind die Merkmale der konkreten Leistung.

Die Regeln zielen auf den Abbau vertraglicher, technischer, kommerzieller und organisatorischer Wechselhindernisse. Daraus folgt kein grenzenloses Recht auf beliebige Technologieübertragung. Schutz von Geschäftsgeheimnissen, Integrität des Dienstes und Rechte Dritter bleiben relevant. Die Pflichten unterscheiden zudem nach Diensttyp: Bei Infrastruktur-Diensten verlangt Art. 30 Data Act angemessene Maßnahmen zur Erleichterung funktionaler Äquivalenz; bei anderen Datenverarbeitungsdiensten stehen insbesondere offene Schnittstellen und Kompatibilität im Vordergrund. Unternehmen sollten gesetzliche Mindestpositionen deshalb mit konkreten vertraglichen Abläufen verbinden.

• Anwendungsbereich für jede Servicekomponente prüfen
• Vertragliche, technische und kommerzielle Hürden getrennt erfassen
• Gesetzliche Rechte in einen operativen Exit-Prozess übersetzen

Quellen: [1]

Portabilität technisch konkret machen

Ein Export ist nur nützlich, wenn Daten vollständig, verständlich und maschinenlesbar bereitgestellt werden. Der Vertrag sollte Formate, Schemas, Schnittstellen, Dokumentation, Zeichencodierung, Zeitstempel und Prüfsummen vorgeben. Bei Vektordatenbanken oder proprietären Indizes ist zu klären, ob Rohdaten, Vektoren, Metadaten und Zuordnungen migriert werden können und welche Bestandteile beim Zielanbieter neu erzeugt werden müssen.

Portabilität umfasst auch semantische Verständlichkeit. Eine große Datei ohne Datenmodell, Feldbeschreibung oder Referenzen kann technisch übertragen, aber praktisch wertlos sein. Deshalb gehören Testexporte in den Regelbetrieb. Das Unternehmen sollte prüfen, ob ein unabhängiges Team die Daten importieren, Stichproben abgleichen und kritische Funktionen wiederherstellen kann. Fehlerquoten, fehlende Objekte und Umwandlungsverluste brauchen definierte Akzeptanzschwellen.

• Offene Formate und dokumentierte Schemas bevorzugen
• Rohdaten, Metadaten, Indizes und Verknüpfungen unterscheiden
• Testexport und Wiederimport regelmäßig durchführen

Quellen: [1]

Übergang und Betriebsfähigkeit planen

Der Exit-Plan muss die gesetzlichen und vertraglichen Phasen abbilden. Nach Art. 25 Data Act darf die Frist zur Einleitung des Wechsels grundsätzlich höchstens zwei Monate betragen; die reguläre Übergangsfrist beträgt höchstens 30 Kalendertage. Ist diese technisch nicht einzuhalten, muss der Anbieter dies innerhalb von 14 Arbeitstagen begründen und eine alternative Frist nennen, die sieben Monate nicht überschreiten darf. Nach Ende der Übergangsphase ist grundsätzlich ein Datenabrufzeitraum von mindestens 30 Kalendertagen vorzusehen. Für kritische Prozesse sind Parallelbetrieb, Rückfalloptionen, eingefrorene Änderungen und abgestimmte Sicherheitskontrollen zu planen.

Übergangsleistungen sollten Inhalt, Dauer, Servicelevel und Kosten klar regeln. Dazu können technische Ansprechpartner, Fehlerbehebung, erneute Exporte und Unterstützung bei Schnittstellen gehören. Der bisherige Anbieter darf nicht allein bestimmen, wann der Wechsel als abgeschlossen gilt. Der Kunde braucht nachvollziehbare Abnahmekriterien für Vollständigkeit, Integrität, Nutzbarkeit und Kontinuität sowie einen Eskalationsweg, falls Fristen oder Qualitätswerte verfehlt werden. Wechselentgelte dürfen bis 12. Januar 2027 die dem Anbieter unmittelbar entstehenden Wechselkosten nicht übersteigen; ab diesem Datum sind Wechselentgelte nach Art. 29 Data Act grundsätzlich unzulässig. Davon zu unterscheiden sind reguläre Leistungsentgelte und vertraglich vereinbarte vorzeitige Beendigungsentgelte, deren Zulässigkeit gesondert zu prüfen ist.

• Kündigungs-, Übergangs- und Abruffristen des Data Act im Vertrag operationalisieren
• Parallelbetrieb und Rückfalloption risikobasiert planen
• Wechselentgelte und sonstige Exit-Kosten rechtlich und kaufmännisch trennen
• Abnahme an Integrität, Vollständigkeit und Nutzbarkeit knüpfen

Quellen: [1] [3]

Rechte, Datenschutz und Löschung sichern

Exportierte Inhalte können personenbezogene Daten, Geschäftsgeheimnisse oder geschützte Werke enthalten. Portabilität schafft keine neue datenschutzrechtliche Rechtsgrundlage und überträgt keine fremden IP-Rechte. Vor Migration sind Zweck, Empfänger, Berechtigungen und Schutzmaßnahmen zu prüfen. Datenminimierung bleibt sinnvoll: Nicht jede historische Protokolldatei muss in das Zielsystem übernommen werden, wenn Aufbewahrung weder erforderlich noch rechtmäßig ist.

Nach erfolgreicher Übernahme ist die Löschung beim bisherigen Anbieter nach vertraglichen und gesetzlichen Anforderungen zu steuern. Zu erfassen sind Produktionssysteme, Sicherungskopien, temporäre Speicher und Unterauftragnehmer. Ein Löschungsnachweis sollte Umfang, Zeitpunkt und verbleibende technisch bedingte Fristen erklären. Rechtliche Aufbewahrungspflichten oder Sicherheitskopien können differenzierte Regeln verlangen; ein pauschales Versprechen „sofort überall gelöscht“ ist ohne technische Prüfung nicht belastbar.

• Rechtsgrundlagen und Rechte vor dem Export prüfen
• Migration nach Datenminimierung und Berechtigungen gestalten
• Löschung einschließlich Backups und Unterauftragnehmern nachweisen

Quellen: [1]

Vorschlag und geltendes Recht unterscheiden

Der allgemeine Digital Omnibus COM(2025) 837 schlägt Änderungen und eine Neuordnung im europäischen Datenrecht vor. Am Rechtsstand 16. September 2026 ist er ein Gesetzgebungsvorschlag und darf nicht wie bereits geltendes Recht behandelt werden. Verträge, Wechselprozesse und Streitentscheidungen sind daher auf den geltenden Data Act und sonstige anwendbare Regeln zu stützen. Künftige Änderungen können über Anpassungsklauseln berücksichtigt werden.

Ein belastbarer Vertrag vermeidet statische Gesetzeszitate als einzigen Mechanismus. Er enthält eigene Leistungs-, Mitwirkungs- und Nachweispflichten, die auch bei Rechtsänderungen praktisch funktionieren. Vor einem tatsächlichen Exit sind Rechtsstand, Dienstkategorie und aktuelle Leitlinien erneut zu prüfen. Gute Vorbereitung stärkt Verhandlungsmacht und Betriebsfähigkeit, garantiert aber keinen verlustfreien Wechsel; technische Unterschiede und Rechte Dritter können eine vollständige Funktionsgleichheit begrenzen.

• COM(2025) 837 ausdrücklich als Vorschlag kennzeichnen
• Verträge am geltenden Data Act ausrichten
• Rechtsstandscheck vor Vertragsabschluss und Wechsel wiederholen

Quellen: [2] [1] [3]

Häufige Fragen