EU Data Act im Regelbetrieb: Welche 5 Baustellen IT-Leitungen 2026 bei Cloud-Wechsel und Gerätedaten jetzt schließen sollten

Der EU Data Act ist seit dem 12. September 2025 anwendbar. Viele IT-Organisationen behandeln ihn trotzdem noch wie ein späteres Rechtsprojekt für Compliance oder Einkauf. Das ist gefährlich kurz gedacht. Denn die Verordnung greift direkt in operative Fragen hinein, die CIOs, Service Owner, Architekturteams und Provider-Manager ohnehin steuern müssen: Wer bekommt Zugriff auf Nutzungsdaten aus vernetzten Produkten, wie werden diese Daten geteilt, was steht in Cloud-Verträgen zum Exit, und wie belastbar ist ein echter Providerwechsel im Betrieb?

Gerade für Unternehmens-IT ist das relevant, weil die Verordnung zwei bislang oft getrennte Welten zusammenzieht. Zum einen geht es um Daten aus Connected Products und Related Services, also etwa Maschinen, Fahrzeuge, Gebäude- oder Medizintechnik. Zum anderen geht es um Regeln für den Wechsel zwischen Anbietern von Datenverarbeitungsdiensten, also praktisch um Cloud-, Plattform- und ähnliche Servicebeziehungen. Wer das nur juristisch liest, verpasst die eigentliche Aufgabe: Der Data Act muss in Betriebsmodelle, Serviceverträge und Transition-Prozesse übersetzt werden.

Für 2026 sind deshalb vor allem fünf Baustellen wichtig.

1. Gerätedaten aus der Grauzone holen und fachlich inventarisieren

Der erste Fehler in vielen Organisationen lautet: Niemand weiß genau, welche verbundenen Produkte im Unternehmen überhaupt kontinuierlich Daten erzeugen, wer als Nutzer gilt und welcher Hersteller oder Anbieter als Data Holder auftritt. Genau hier beginnt der Data Act aber praktisch. Laut EU-Kommission sollen Nutzer von Connected Products Zugang zu den Daten erhalten, die bei der Nutzung entstehen, und diese Daten bei Bedarf auch mit Dritten teilen können.

Für IT-Leitungen heißt das nicht, sofort jedes IoT-Projekt neu aufzusetzen. Aber es braucht ein belastbares Inventar in drei Schichten: erstens die betroffenen Produktklassen wie Produktionsanlagen, Fahrzeugflotten, Gebäudetechnik oder Spezialgeräte, zweitens die zugehörigen Services und Portale, drittens die Vertrags- und Rollenlage. Spätestens wenn Fachbereiche Wartungs- oder Optimierungsservices einkaufen wollen, sollte klar sein, welche Roh- oder vorverarbeiteten Daten überhaupt verfügbar sind und ob deren Zugriff heute real oder nur theoretisch ist.

Praxistipp: Ergänzen Sie Ihr Asset- oder Service-Portfolio nicht nur um Hersteller und Betreiber, sondern um die Felder „daten­erzeugendes Produkt“, „relevanter Service“, „Nutzer“, „Data Holder“ und „kritische Drittparteienfreigaben“.

2. Einen echten Datenzugriffsprozess definieren, nicht nur eine Rechtsposition

Der Data Act stärkt den Zugang zu Daten, doch ein Anspruch ohne Prozess hilft im Alltag wenig. Viele Organisationen werden 2026 erleben, dass Fachbereiche zwar auf Gerätedaten zugreifen möchten, operative Teams aber weder einen Standardweg noch Verantwortlichkeiten dafür definiert haben. Dann entsteht genau das Muster, das man aus dem ITSM gut kennt: Jede Anfrage wird zum Sonderfall.

Deshalb sollte es einen klaren Datenzugriffsprozess geben. Dazu gehören ein Eingangskanal, eine Rollenklärung, eine Prüfung auf Datenschutz, Vertraulichkeit und Sicherheitsrisiken sowie ein definierter Übergabemechanismus. Besonders wichtig ist die Unterscheidung zwischen Rohdaten, vorverarbeiteten Daten und abgeleiteten Daten, denn nicht alles ist im gleichen Umfang erfasst. Ebenso relevant ist die Frage, wie Anfragen dokumentiert und wie Ablehnungen begründet werden.

Aus ITSM-Sicht gehört das nicht in einen losen Mailprozess, sondern in ein steuerbares Request-Modell mit SLAs, Eskalation und Knowledge-Bausteinen. Wer schon heute Service-Requests für Datenbereitstellung, Export oder Drittfreigabe modelliert, spart später erhebliche Reibung zwischen Fachbereich, Recht, Security und Betrieb.

3. Cloud-Wechsel als Betriebsfähigkeit testen, nicht als Vertragsklausel abhaken

Ein besonders unterschätzter Teil des Data Act betrifft den Wechsel zwischen Anbietern von Datenverarbeitungsdiensten. Die EU-Kommission stellt klar, dass Nutzer zwischen Cloud-Anbietern wechseln oder mehrere Dienste parallel nutzen können sollen. Für IT-Leitungen ist das keine abstrakte Marktordnung, sondern eine operative Hausaufgabe: Ein Exit ist erst dann belastbar, wenn Datenexport, Schnittstellen, Identitäten, Betriebsdokumentation und Wiederanlauf auch praktisch funktionieren.

Genau hier liegen 2026 die größten Lücken. Viele Verträge nennen Exit-Unterstützung, aber kaum jemand testet, ob Backups wirklich lesbar sind, Exportformate weiterverarbeitet werden können, Netzwerk- und IAM-Abhängigkeiten dokumentiert sind oder Migrationsfenster mit dem Geschäftsbetrieb vereinbar bleiben. Hinzu kommt, dass Plattformdienste oft enger verknüpft sind als klassische IaaS-Verträge. Wer Container, Datenbanken, Logging, KI-Dienste und Identitätskomponenten aus einem Baukasten bezieht, braucht einen viel genaueren Exit-Pfad.

Praktisch sinnvoll ist deshalb ein Cloud-Switching-Runbook pro kritischem Provider. Darin sollten mindestens stehen: exportierbare Datenarten, proprietäre Abhängigkeiten, notwendige Zielplattformen, Sicherheits- und Continuity-Anforderungen, Kontaktpunkte beim Anbieter, Testzyklen und ein realistischer Aufwand für Transition oder Parallelbetrieb.

4. Verträge an den Standardklauseln spiegeln und unfaire Schieflagen sichtbar machen

Die Kommission hat Anfang 2026 nicht nur FAQs veröffentlicht, sondern auch Entwürfe für nicht bindende Model Contractual Terms und Standard Contractual Clauses. Gerade für Cloud-Verträge ist das praktisch relevant, weil dort Bausteine zu Switching, Exit, Vertragsbeendigung sowie Security und Business Continuity während des Wechsels beschrieben werden.

Für Unternehmen heißt das nicht, jedes bestehende Vertragswerk sofort komplett neu zu verhandeln. Aber es ist sinnvoll, die eigenen Schlüsselverträge an genau diesen Themen zu spiegeln. Gibt es klare Regeln für Herausgabe, Format, Fristen und Verantwortlichkeiten? Sind Sicherheitsleistungen während eines Wechsels sauber beschrieben? Darf der Anbieter Vertragsbedingungen einseitig verschieben oder Haftung so weit begrenzen, dass der Exit faktisch entwertet wird?

Hier lohnt sich eine gemeinsame Review-Schleife von Vendor Management, Recht und IT-Betrieb. Besonders wirksam ist ein Ampelbild pro Provider: grün für belastbar, gelb für verhandelbar, rot für echte Exit-Risiken. So wird aus einem schwer greifbaren Regulierungsthema ein steuerbarer Bestandteil des Lieferantenmanagements.

5. Data Act nicht isolieren, sondern in Governance und Service-Transition einbauen

Die fünfte Baustelle ist organisatorisch. Der Data Act scheitert selten an fehlender Aufmerksamkeit, sondern an falscher Zuordnung. Wenn Recht die Regeln kennt, Procurement die Verträge hält, der Fachbereich die Daten braucht und der IT-Betrieb die technische Realität trägt, aber niemand das Gesamtbild führt, bleibt alles Stückwerk.

2026 braucht es deshalb einen klaren Governance-Anker. In vielen Organisationen bietet sich dafür ein kleines, funktionsübergreifendes Steuerungsformat an, etwa über Architecture Board, Provider Governance oder ein Data-Governance-Gremium. Wichtig ist, dass dort drei Fragen regelmäßig beantwortet werden: Welche betroffenen Produkte und Services sind geschäftskritisch? Wo fehlen belastbare Datenzugriffs- oder Exit-Prozesse? Und bei welchen Verträgen oder Plattformen ist das Risiko operativ höher als auf dem Papier?

Genauso wichtig ist die Verankerung in bestehenden Abläufen. Neue Anbieter sollten bereits in der Service-Transition auf Datenzugriff, Exportfähigkeit und Exit vorbereitet werden. Wesentliche Risiken gehören ins Lieferanten- und Risikomanagement. Wiederkehrende Konflikte um Datenbereitstellung gehören in Problem- oder Continual-Improvement-Backlogs. Dann bleibt der Data Act kein Sonderthema, sondern wird Teil normaler Betriebsführung.

Was IT-Leitungen jetzt konkret tun sollten

Der Data Act ist 2026 kein Zukunftssignal mehr, sondern Betriebsrealität. Wer jetzt nur auf Juristen oder den nächsten Vertragszyklus wartet, baut neue Abhängigkeiten auf, statt bestehende zu reduzieren. Der bessere Weg ist nüchtern und operativ: betroffene Produkte inventarisieren, Datenzugriffsprozesse modellieren, Cloud-Exit-Fähigkeit testen, Verträge gegen die neuen Leitplanken spiegeln und Governance sauber verankern.

Genau darin liegt der fachliche Nutzen der Verordnung für die IT: Sie zwingt Organisationen, über Datenhoheit, Portabilität und Providerabhängigkeit nicht nur strategisch zu reden, sondern sie im Alltag messbar zu machen. Für CIOs und Service-Verantwortliche ist das anstrengend, aber auch eine Chance. Wer diese fünf Baustellen jetzt schließt, verbessert nicht nur Compliance, sondern vor allem seine operative Verhandlungs- und Handlungsfähigkeit.

Quellenbasis für die Einordnung: EU-Kommission, „Data Act“ und „Data Act explained“; EU-Kommission, „EU Data Act gives users control over data from connected devices“; EU-Kommission, FAQ zum Data Act sowie Entwurf der Standard Contractual Clauses und Model Contractual Terms von März 2026.