Bildquelle: extern
Cloud-Wechsel unter dem Data Act beginnt bei Exporten, Rollen und Runbooks
Der EU Data Act ist kein fernes Regulierungsthema mehr. Die Verordnung gilt praktisch seit dem 12. September 2025 und trifft gleich zwei Betriebsrealitäten, die viele Unternehmen bislang getrennt behandelt haben. Erstens stärkt sie den Zugang zu Daten aus vernetzten Produkten und zugehörigen Diensten. Zweitens setzt sie einen klareren Rahmen dafür, dass Kunden zwischen Anbietern von Datenverarbeitungsdiensten wechseln können, also vor allem zwischen Cloud-, Plattform- und ähnlichen digitalen Services.
Genau darin liegt die eigentliche Relevanz für IT-Betrieb, Service Management und Providersteuerung. Ein kündbarer Vertrag allein macht noch keinen belastbaren Exit. Und ein theoretischer Datenzugang hilft wenig, wenn niemand sauber festgelegt hat, welche Daten überhaupt vorliegen, wer sie anfordern darf, in welchem Format sie geliefert werden und welche Sicherheits- oder Geheimnisschutzfragen vorher geklärt sein müssen. Wer den Data Act nur als Thema für Legal oder Procurement ablegt, übersieht die operative Hausaufgabe.
Für IT-Organisationen lohnt deshalb ein nüchterner Blick auf die Stellen, an denen der Data Act heute schon konkrete Arbeit erzeugt. Besonders wichtig sind Scope, Datenzugriffsprozesse, Exit-Readiness, Vertragsprüfung und eine Governance, die den Stoff dauerhaft im Betrieb hält.
Betroffene Services zuerst sichtbar machen
Der häufigste Fehler beginnt beim Geltungsbereich. Viele Häuser denken beim Data Act sofort an klassische IoT-Produkte im Verkauf. Die EU-Kommission beschreibt aber deutlich breiter, dass Nutzer von Connected Products und Related Services Zugang zu den Daten erhalten sollen, die sie durch die Nutzung mit erzeugen. Dazu gehören je nach Unternehmensrealität auch industrielle Maschinen, Gebäude- und Energietechnik, Fahrzeugflotten, medizinische Geräte oder digitale Zusatzdienste rund um ein verbundenes Produkt.
Für den Betrieb heißt das: Zuerst braucht es ein belastbares Inventar. Darin sollten nicht nur Hersteller und Betreiber stehen, sondern auch der jeweilige Datenhalter, die Nutzerrolle, betroffene Roh- oder vorverarbeitete Daten, relevante Metadaten, angebundene Portale, Drittparteien und die internen Service Owner. Diese Übersicht verhindert, dass Anfragen zu Gerätedaten später zwischen Produktteam, Service Desk, Security, Datenschutz und Einkauf versanden.
Wichtig ist dabei die fachliche Trennschärfe. Die Kommission grenzt aus, dass abgeleitete oder stark angereicherte Daten automatisch in denselben Umfang fallen. Für IT-Teams bedeutet das: Schon im Inventar muss erkennbar sein, welche Daten ohne unverhältnismäßigen Aufwand tatsächlich verfügbar sind und wo Mehrwertdaten, Geschäftsgeheimnisse oder personenbezogene Informationen zusätzliche Prüfungen auslösen.
Datenzugang als Serviceprozess aufbauen
Der Data Act schafft Rechte, aber keine fertigen Betriebsprozesse. Genau dort beginnt die ITSM-Arbeit. Wenn Fachbereiche, Betreiber oder Kundenorganisationen künftig Datenzugang verlangen, reicht ein Postfach für Einzelfälle nicht aus. Es braucht einen definierten Serviceprozess mit Eingangskanal, Berechtigungsprüfung, Rollenklärung, Ausgabepfad, Nachweisführung und Eskalation.
Praktisch heißt das zum Beispiel: ein Request-Modell im Servicekatalog, eine klare Vollmachts- und Identitätsprüfung, Standardformate für Auslieferungen, nachvollziehbare Fristen, Logging der Übergaben und eine Entscheidungsmatrix für Fälle mit Datenschutz-, Sicherheits- oder Geheimnisschutzbezug. Gerade im B2B-Umfeld ist wichtig, dass nicht immer eine einzelne natürliche Person der anfragende Nutzer ist, sondern oft Betreiber, Leasingnehmer oder Kundenorganisationen mit vertretungsberechtigten Rollen.
Wer diesen Prozess früh strukturiert, gewinnt doppelt. Zum einen sinkt die Reibung im Tagesgeschäft. Zum anderen lassen sich wiederkehrende Konflikte als Problem- oder Continual-Improvement-Themen bearbeiten, statt jedes Mal improvisiert zwischen Fachbereich und Betrieb zu vermitteln.
Der eigentliche Härtetest liegt im Cloud-Exit
Besonders relevant für IT-Leitungen ist Kapitel VI des Data Act zum Wechsel zwischen Anbietern von Datenverarbeitungsdiensten. Die Kommission betont, dass Kunden effektiv zwischen Cloud-Anbietern wechseln oder mehrere Dienste parallel nutzen können sollen. Im Alltag wird daraus aber nur dann echte Handlungsfähigkeit, wenn Exit-Pfade geübt und dokumentiert sind.
Genau hier liegen in vielen Organisationen die größten Lücken. Verträge sprechen von Exporten, Unterstützung oder Transition, aber niemand prüft regelmäßig, ob Daten vollständig herauskommen, ob Metadaten und Auditspuren mitwandern, ob IAM-Rollen sauber übertragen werden können, ob API-Limits die Migration ausbremsen oder ob ein Parallelbetrieb realistisch finanzierbar ist. Bei modernen Plattformdiensten kommen weitere Abhängigkeiten hinzu: proprietäre Logging-Formate, KI-Services, Eventing, Sicherheitswerkzeuge, eingebaute Datenpipelines oder providergebundene Automationslogik.
Ein belastbares Exit-Runbook pro kritischem Dienst sollte deshalb mindestens fünf Dinge dokumentieren: exportierbare Datenarten samt Format, Identitäts- und Rollenabhängigkeiten, technische Voraussetzungen auf der Zielplattform, Sicherheits- und Continuity-Maßnahmen während des Wechsels sowie einen realistischen Test- und Kommunikationsplan. Erst wenn diese Punkte einmal praktisch durchgespielt wurden, lässt sich einschätzen, ob ein Cloud-Wechsel mehr ist als eine Verhandlungsfolie.
Verträge gegen die neue Praxis spiegeln
Die EU-Kommission hat zusätzlich FAQs sowie nicht bindende Standard Contractual Clauses und Model Contractual Terms veröffentlicht. Für Cloud-Verträge sind vor allem die Bausteine zu Switching & Exit, Vertragsbeendigung sowie Security & Business Continuity interessant. Sie helfen, aus allgemeinen Exit-Versprechen überprüfbare Vertragsfragen zu machen.
Für Provider Management und Einkauf ist das ein guter Prüfrahmen. Enthält der Vertrag klare Zusagen zu Datenherausgabe, Fristen, Formaten, Support in der Übergangsphase und Verantwortlichkeiten? Sind Sicherheitsleistungen während einer Migration geregelt? Gibt es einseitige Änderungsrechte oder Haftungsbegrenzungen, die den Exit praktisch entwerten? Und passen die Vertragsaussagen überhaupt zu dem, was Architektur und Betrieb technisch beobachtet haben?
Gerade dieser Abgleich zwischen Papier und Realität fehlt oft. Sinnvoll ist daher ein Ampelbild pro kritischem Provider: grün für technisch getestet und vertraglich belastbar, gelb für bekannte Lücken mit klarer Nacharbeit, rot für echte Lock-in-Risiken. So wird der Data Act nicht zum losen Rechtskommentar, sondern zum Instrument im Lieferantenmanagement.
Ohne wiederkehrende Tests bleibt alles Theorie
Der Data Act ist kein Projekt mit sauberem Enddatum. Neue Produkte, neue Plattformdienste, geänderte Schnittstellen und veränderte Vertragsbedingungen verschieben die Lage laufend. Deshalb sollte die Thematik an bestehende Governance-Routinen angedockt werden, etwa an Architecture Boards, Supplier Reviews, Service Transition oder Risiko-Reviews.
Entscheidend ist eine kleine, aber belastbare Taktung. Welche betroffenen Services haben bereits ein sauberes Scope-Register? Wo fehlt ein standardisierter Datenzugriffsprozess? Für welche kritischen Cloud- oder Plattformdienste existiert ein getestetes Exit-Runbook? Welche offenen Punkte liegen bei Security, Datenschutz oder Geschäftsgeheimnissen? Wer diese Fragen quartalsweise beantwortet, erkennt Lock-in-Risiken früh genug, bevor sie bei Vertragsverlängerungen, Preissprüngen oder Souveränitätsdebatten hektisch eskalieren.
Unterm Strich zwingt der Data Act IT-Organisationen zu einer nützlichen Disziplin. Datenhoheit und Portabilität müssen nicht nur vertraglich behauptet, sondern operativ nachgewiesen werden. Genau deshalb beginnt Cloud-Wechsel unter dem Data Act nicht bei der Kündigung, sondern bei Exporten, Rollen und Runbooks, die im Alltag wirklich tragen.
