Datenzugang wird zum Produktworkflow
Der EU Data Act gilt seit dem 12. September 2025 und bewegt sich jetzt von juristischer Vorbereitung in die Produktumsetzung. Er gibt Nutzern vernetzter Produkte und zugehoeriger digitaler Services mehr Kontrolle ueber Daten, die sie erzeugen, und setzt zugleich Erwartungen an Data Sharing, Cloud Switching und Interoperabilitaet.
Fuer Softwareteams ist die praktische Frage nicht nur, ob das Unternehmen eine juristische Einschaetzung hat. Entscheidend ist, ob das Produkt Datenzugang so abbilden kann, dass Nutzer, Support und Engineering damit arbeiten koennen: klare Anfrageflows, erklaerbare Datenumfaenge, sichere Exporte, Third-Party-Sharing-Kontrollen und genug Nachweise fuer spaetere Reviews.
Mit einem Datenzugangs-Inventar starten
Ein Data-Act-Readiness-Plan sollte mit den Daten beginnen, die das Produkt erzeugt, empfaengt und transformiert. Connected Products, Companion Apps, SaaS-Dashboards und Kundenportale mischen oft rohe Geraetesignale, vorverarbeitete Datensaetze, Accountdaten, Billing Events, Analytics, Dokumente und abgeleitete Erkenntnisse. Nicht jede Kategorie gehoert in denselben Access Flow.
Das Produktinventar sollte direkt verfuegbare Produkt- oder Servicedaten von abgeleiteter Intelligenz, vertraulicher Geschaeftslogik und personenbezogenen Daten trennen, die weiterhin eine GDPR-Grundlage brauchen. Diese Unterscheidung verhindert vage Exportversprechen und hilft, einen Anfrageflow zu gestalten, der nuetzlich ist, ohne Trade Secrets, personenbezogene Daten oder operative Interna offenzulegen.
- Connected-Product-Daten, Related-Service-Daten, Account Records, Dokumente und Analytics getrennt erfassen.
- Markieren, welche Daten roh, vorverarbeitet, abgeleitet, personenbezogen, nicht personenbezogen oder Trade-Secret-sensibel sind.
- Definieren, welche Exporte nutzerseitig, adminseitig, partnerseitig oder behoerdenseitig sind.
- Quelle, Owner, Retention-Regel und Review-Status an wichtige Datenkategorien haengen.
- Das Inventar in Testfaelle fuer echte Anfrage- und Export-Screens uebersetzen.
Den Anfrageflow vor der API gestalten
Viele Teams werden mit einem Endpoint starten wollen. Besser ist die Request Journey: Wer fragt Daten an, welchen Umfang kann die Person auswaehlen, ob ein Dritter die Daten erhaelt, welche Berechtigungen gelten und wie der Nutzer die Konsequenz versteht. Eine starke Oberflaeche senkt Supportlast, weil sie das Datenpaket erklaert, bevor der Export erzeugt wird.
Der Flow sollte Umfang, Format, Timing, Sicherheitspruefung und naechste Schritte zeigen. In einem Kundenportal braucht der Nutzer vielleicht eine herunterladbare Datei und eine Historie frueherer Anfragen. In einem industriellen Dashboard braucht ein autorisierter Operator vielleicht wiederkehrenden maschinenlesbaren Zugriff. Bei einer Partnerintegration braucht das Produkt Consent, Vertragsstatus, Rate Limits und Widerruf.
Third-Party-Sharing widerrufbar und sichtbar machen
Der Data Act handelt nicht nur davon, dass ein Nutzer eine Datei herunterlaedt. Nutzer koennen verlangen, dass ein Data Holder Daten mit einem Dritten ihrer Wahl teilt, innerhalb wichtiger Grenzen. Damit wird Data Sharing zu einer Beziehung, die im Produkt sichtbar sein sollte, nicht zu einem versteckten Support-Ticket.
Ein praktisches Portal braucht ein Sharing-Register: Empfaenger, Umfang, Startdatum, Status, rechtliche oder vertragliche Grundlage, technischer Endpoint, letzte Uebertragung und Widerrufspfad. Wenn personenbezogene Daten betroffen sind, braucht der Workflow ausserdem die passende Privacy-Grundlage und eine klare Trennung von nicht personenbezogenen Industriedaten. Der Nutzer sollte verstehen koennen, welcher Zugriff aktiv ist und wie er gestoppt wird.
Cloud Switching ist ein Architektursignal
Der Data Act adressiert auch den Wechsel zwischen Datenverarbeitungsdiensten, darunter Cloud- und Edge-Services. Fuer SaaS-Produkte und operative Plattformen bedeutet das nicht, dass morgen jeder Kunde migriert. Es bedeutet aber, dass Teams wissen sollten, welche Daten und digitalen Assets exportierbar sind, welche Services eng gekoppelt sind und welche Vertraege einen Exit-Pfad versprechen, den die Architektur noch nicht traegt.
Die Engineering-Arbeit ist oft unspektakulaer, aber wertvoll: dokumentierte Schemata, stabile Exportformate, Tenant-Level-Backups, Dependency Maps, Hinweise zur Umgebungserstellung und Migrations-Runbooks. Dieselben Praktiken helfen bei Disaster Recovery, Enterprise Procurement und spaeteren Plattformwechseln, auch wenn keine formale Switching-Anfrage kommt.
Nachweise in Operations einbauen
Datenzugangs-Workflows brauchen Logs, die nuetzlich sind, ohne selbst zum Privacy-Problem zu werden. Teams sollten Anfragezustand, Antragsteller, Umfang, Freigaben, Exportzeitpunkt, Bereitstellungsmethode, Empfaenger, Widerruf und Fehler erfassen. Sie sollten keine unnoetigen Inhalte in Logs sammeln, aber genug operative Nachweise fuer Support, Audits und Incident Review erhalten.
Hier werden Dashboards und Automatisierung Teil der Compliance-Qualitaet. Ein Support-Team sollte offene Anfragen, fehlgeschlagene Exporte, auslaufende Zugriffsfreigaben und ungewoehnliche Transfermuster sehen. Product Teams sollten erkennen, wo Nutzer verwirrt sind. Engineering sollte sehen, welche Datenquellen Exporte langsam oder fragil machen.
Ein praktischer erster Build fuer 2026
Fuer EDS Labs Projekte ist ein sinnvoller erster Data-Act-faehiger Build eng und pruefbar: eine Produkt- oder Portaloberflaeche waehlen, relevante Datenkategorien erfassen, Request- und Sharing-Screens gestalten, einen sicheren Exportpfad implementieren, operative Nachweise loggen und dokumentieren, was bewusst ausserhalb des Scopes bleibt.
So wird der Data Act nicht zur spaeten juristischen Hektik, sondern zu besserer Produktinfrastruktur. Nutzer bekommen verstaendlichen Zugriff auf ihre Daten. Support-Teams bekommen weniger unklare Anfragen. Engineers bekommen klarere APIs, Exportgrenzen und Exit-Plaene, die die Plattform resilienter machen.