EU Data Act im IT-Betrieb: Welche 5 Vorarbeiten Service- und Plattform-Teams für Datenzugang und Cloud-Wechsel jetzt sauber aufsetzen sollten

Seit dem 12. September 2025 gilt der EU Data Act in der Praxis. Viele IT-Organisationen haben das Gesetz bislang vor allem als regulatorisches Randthema für Rechtsabteilung oder Produktmanagement verbucht. Das ist zu kurz gedacht. Denn die Verordnung greift tief in Betriebsrealitäten ein, die Service-Management, Plattformteams, Beschaffung und Architektur direkt betreffen: Daten aus vernetzten Produkten müssen zugänglich gemacht werden, Nutzer sollen diese Daten einfacher mit Dritten teilen können, und für Datenverarbeitungsdienste, also vor allem Cloud- und Plattformleistungen, wird der Anbieterwechsel stärker operationalisiert.

Gerade für Unternehmen mit IoT-nahen Services, vernetzten Maschinen, smarten Gebäuden, Fahrzeugflotten oder plattformbasierten Serviceangeboten ist das kein abstrakter Zukunftspunkt mehr. Die EU-Kommission betont, dass Nutzer von vernetzten Produkten und zugehörigen Diensten Zugang zu den von ihnen mit erzeugten Daten erhalten sollen. Gleichzeitig sollen Cloud-Kunden leichter zwischen Anbietern wechseln oder mehrere Dienste parallel nutzen können. Für IT- und Service-Organisationen heißt das: Wer Datenzugang, Rollen, Vertragsklauseln und Exit-Prozesse nicht vorbereitet, baut sich den nächsten Governance- und Betriebsstau selbst.

Fünf Vorarbeiten sollten deshalb 2026 verbindlich werden.

1. Erst den Geltungsbereich klären, bevor einzelne Teams hektisch Maßnahmen bauen

Der häufigste Fehler ist ein zu enger Blick. Viele Häuser denken beim Data Act sofort an klassische IoT-Produkte im Verkauf. Tatsächlich kann der Anwendungsbereich deutlich breiter sein: vernetzte Maschinen in Produktion oder Logistik, Gebäude- und Energietechnik, medizinische Geräte, Flottenlösungen oder digitale Zusatzdienste rund um ein verbundenes Produkt. Die EU-Kommission nennt ausdrücklich vernetzte Autos, Smart-Home-Geräte, Industrie- und Landmaschinen als typische Beispiele.

Für die Praxis braucht es deshalb zuerst ein belastbares Scope-Register. Dort sollten mindestens stehen: welches vernetzte Produkt oder welcher related service betroffen ist, welche Roh- oder vorverarbeiteten Daten dabei entstehen, wer intern fachlicher Owner ist, wer als Datenhalter auftritt, welche Kunden- oder Nutzergruppen betroffen sind und welche nachgelagerten Betriebs- oder Supportprozesse daran hängen. Ohne diese Sicht bleibt der Data Act ein diffuser Compliance-Begriff, aus dem weder Architektur noch Service-Prozess saubere Aufgaben ableiten können.

Wichtig ist außerdem die Trennung zwischen wirklich verfügbaren Nutzungsdaten und abgeleiteten Mehrwertdaten. Die Kommission macht klar, dass sich die Regeln auf Rohdaten und vorverarbeitete Daten beziehen, die dem Datenhalter ohne unverhältnismäßigen Aufwand zur Verfügung stehen. Wer diese Abgrenzung nicht dokumentiert, riskiert später unnötige Konflikte mit Kunden, Partnern und internen Produktteams.

2. Datenzugang nicht juristisch, sondern als operativen Serviceprozess modellieren

Der Data Act verlangt nicht nur abstrakte Rechte, sondern praktisch nutzbare Prozesse. Nutzer sollen Daten anfordern können, und zwar über einen einfachen Weg. Datenhalter müssen außerdem vorab transparent machen, welche Daten in welcher Art entstehen. Genau hier liegt eine klassische ITSM-Aufgabe.

Statt auf Einzelfallbearbeitung per Mail zu setzen, sollten Organisationen einen klaren Serviceprozess definieren: Wer darf Anfragen stellen, wie wird die Berechtigung geprüft, welches Datenformat wird geliefert, welche Fristen gelten, welche Identitäts- und Vollmachtsprüfung ist nötig, und welche Teams übernehmen Eskalationen? Gerade im B2B-Umfeld ist das entscheidend, weil nicht der einzelne Endnutzer, sondern häufig Betreiber, Leasingnehmer oder Kundenorganisationen als berechtigte Nutzer auftreten.

Praktisch heißt das: Request-Modelle im Servicekatalog anlegen, Standardtexte für Annahme und Rückfragen vorbereiten, Datenlieferungen über nachvollziehbare Kanäle abwickeln und Logging für Nachweiszwecke mitdenken. Wer diesen Punkt sauber löst, verhindert, dass Data-Access-Anfragen später zwischen Service Desk, Fachteam, Produktmanagement und Legal hängen bleiben.

3. Vertrags- und Exit-Klauseln für Cloud- und Plattformdienste jetzt systematisch nachziehen

Der betriebliche Hebel des Data Act endet nicht bei Produktdaten. Die Kommission hebt ausdrücklich hervor, dass Kunden von Datenverarbeitungsdiensten leichter zwischen Cloud-Anbietern wechseln oder mehrere Dienste parallel nutzen können sollen. Ergänzend hat sie unverbindliche Standardvertragsklauseln unter anderem für Switching & Exit, Vertragsbeendigung sowie Security & Business Continuity veröffentlicht.

Für IT-Management und Plattformteams ist das ein Signal: Anbieterwechsel darf nicht erst dann konkret werden, wenn ein Vertrag ausläuft, Preise steigen oder ein Souveränitätsproblem akut wird. Jede Verlängerung eines Cloud-, SaaS- oder Plattformvertrags sollte künftig entlang eines Exit-Fragenkatalogs geprüft werden. Dazu gehören Exportformate, technische Schnittstellen, Migrationsunterstützung, verfügbare Metadaten, Lösch- und Übergabefristen, Parallelbetrieb, Identitäts- und Rollenübernahme sowie Support während einer Übergangsphase.

Besonders wichtig ist, diese Punkte nicht nur im Einkauf zu verhandeln, sondern technisch zu testen. Ein vertraglich zugesicherter Export ist wenig wert, wenn Datenstrukturen unvollständig, API-Limits zu eng oder Abhängigkeiten zu proprietären Workflows zu hoch sind. Gute Plattformorganisationen führen deshalb Exit-Readiness-Checks ähnlich konsequent wie Restore-Tests oder Notfallübungen.

4. Sicherheits-, Geheimnis- und Rollenfragen vor dem ersten Konflikt klären

Der Data Act ist kein Freifahrtschein für unkontrollierte Datenweitergabe. Die Kommission verweist ausdrücklich auf Datenschutz, Schutz von Geschäftsgeheimnissen und mögliche Sicherheitsrisiken. Datenhalter können Schutzmaßnahmen vereinbaren und Datenteilung unter engen Voraussetzungen auch begrenzen, etwa wenn ernsthafte Sicherheitsauswirkungen drohen.

Genau deshalb genügt es nicht, nur ein Exportskript zu bauen. Unternehmen brauchen eine Entscheidungsmatrix. Welche Datentypen dürfen standardisiert herausgegeben werden? Wo sind personenbezogene Daten mit betroffen? Welche Freigabe braucht ein Drittzugriff? Welche Schutzmaßnahmen gelten für Betriebsgeheimnisse, technische Konfigurationsdaten oder sicherheitsrelevante Telemetrie? Und wer entscheidet im Grenzfall, wenn Kunde, Betreiber und Hersteller unterschiedliche Interessen haben?

Für Service-Organisationen empfiehlt sich ein schlankes Governance-Modell mit klarer Beteiligung von Informationssicherheit, Datenschutz, Produktverantwortung und gegebenenfalls OT-Verantwortlichen. Sonst landen komplexe Fälle im Improvisationsmodus, und genau dort entstehen später die teuersten Fehler.

5. Datenzugang und Wechselbereitschaft als laufende Steuerungsgröße etablieren

Der Data Act ist kein Projekt mit Enddatum, sondern eine neue Betriebsanforderung. Deshalb sollten IT- und Service-Teams zwei Fähigkeiten dauerhaft messen: erstens, wie belastbar Anfragen zu Produktdaten operationalisiert sind, und zweitens, wie realistisch ein Anbieterwechsel bei kritischen Cloud- oder Plattformdiensten tatsächlich wäre.

Sinnvolle Steuerungsgrößen sind zum Beispiel: Anteil der betroffenen Services mit dokumentiertem Data-Act-Scope, Anteil der Verträge mit geprüftem Exit- und Switching-Abschnitt, Zahl der getesteten Exporte pro kritischem Dienst, Bearbeitungszeit für Datenzugangsrequests, Zahl offener Sicherheits- oder Datenschutz-Ausnahmen sowie dokumentierte Verantwortlichkeiten für Grenzfälle. Diese Kennzahlen gehören nicht in ein juristisches Nebendokument, sondern in die regulären Governance-Routinen von Architektur, Supplier Management und Service Management.

Wer diesen Schritt geht, gewinnt mehr als nur Compliance. Die eigene Verhandlungsposition gegenüber Plattformanbietern wird besser, Kundenanfragen lassen sich geordneter bedienen, und Lock-in-Risiken werden sichtbar, bevor sie in einer Krise teuer explodieren.

Fazit

Der EU Data Act trifft 2026 nicht nur Hersteller vernetzter Produkte, sondern auch die Betriebs- und Steuerungslogik moderner IT-Organisationen. Datenzugang muss als Serviceprozess funktionieren, Cloud-Wechsel braucht belastbare Exit-Fähigkeiten, und Sicherheits- sowie Rollenfragen dürfen nicht erst im Streitfall geklärt werden. Wer jetzt Scope, Prozesse, Vertragsstandards, technische Tests und Governance sauber aufsetzt, macht aus regulatorischem Druck einen praktischen Reifegewinn für IT-Betrieb und Service Management.

Quellen

• European Commission: Data Act
• European Commission: Data Act explained
• European Commission: EU Data Act gives users control over data from connected devices
• European Commission: Frequently Asked Questions about the Data Act
• European Commission: Draft Recommendation on Model Contractual Terms and Standard Contractual Clauses for cloud contracts