Zurück zum Blog

EU Data Act für Softwareunternehmen: Datenzugang und Cloud-Wechsel vorbereiten

Data SovereigntyComplianceSoftware ArchitectureBackend Development

Der EU Data Act ist für Softwareunternehmen seit dem 12. September 2025 kein späteres Compliance-Thema mehr. Wer vernetzte Produkte, IoT-Plattformen, SaaS-Integrationen oder Cloud-Dienste betreibt, muss erklären können, welche Daten entstehen, wer sie nutzen darf und wie sie technisch bereitgestellt oder übertragen werden.

Was der EU Data Act für Softwareunternehmen bedeutet

Der EU Data Act regelt nicht einfach Datenschutz. Er schafft Regeln dafür, wer Daten aus vernetzten Produkten, zugehörigen Services und Datenverarbeitungsdiensten nutzen, portieren oder von einem Anbieter zu einem anderen mitnehmen kann.

Für wachsende Softwareteams wird daraus eine Architekturaufgabe. Produktdaten müssen auffindbar, klassifizierbar und über stabile Schnittstellen bereitstellbar sein. Gleichzeitig bleiben DSGVO, Geschäftsgeheimnisse, Sicherheitsanforderungen und Kundenverträge relevant.

Für Führung und Engineering sind besonders diese Fragen wichtig:

  • Datenumfang: Welche Rohdaten, Metadaten und vorverarbeiteten Daten entstehen durch Nutzung des Produkts?
  • Zugriffsmodell: Können Nutzer oder berechtigte Dritte Daten ohne manuelle Sonderprozesse erhalten?
  • Mandantengrenzen: Sind Kundendaten technisch sauber getrennt oder nur über Konventionen geschützt?
  • Portabilität: Sind Daten maschinenlesbar, dokumentiert und frei von unnötigen Cloud-Abhängigkeiten?

Der EU Data Act ersetzt keine gute Datenarchitektur. Er macht aber sichtbar, wo ein System bisher nur intern funktionierte und für Kunden, Partner oder Regulatorik nicht erklärbar ist.

Wo Teams mit Datenzugang und Cloud-Wechsel starten sollten

Der häufigste Fehler ist, den EU Data Act als juristische Textarbeit zu behandeln. Die teuren Lücken liegen meist im Backend: unklare Event-Schemas, manuelle Exporte, Datenkopien ohne Owner, fehlende Löschlogik oder provider-spezifische Formate, die niemand sauber migrieren kann.

Ein pragmatischer Startpunkt ist ein kleines Inventar für die produktkritischen Datenflüsse:

data_access_inventory:
  product_area: fleet_monitoring
  owner: platform-team
  data_classes: ["sensor_data", "usage_metadata", "maintenance_events"]
  export_format: "jsonl"
  tenant_boundary: "database_schema_per_customer"
  cloud_dependency: "managed_timeseries_database"

Daraus entstehen konkrete Entscheidungen:

  • API statt Ticketprozess: Wiederkehrende Datenzugriffe brauchen eine produktfähige Schnittstelle, keinen manuellen Support-Export.
  • Datenklassifizierung vor Export: Personenbezogene Daten, Betriebsgeheimnisse und sicherheitsrelevante Daten dürfen nicht im selben Prozess behandelt werden.
  • Schema-Governance: Events und Exportformate brauchen Versionierung, Deprecation-Regeln und Verantwortliche.
  • Wechselpfade testen: Cloud-Switching bleibt Theorie, wenn Backups, Objektstrukturen, IAM und Laufzeitdienste nie außerhalb des aktuellen Providers geprüft wurden.
  • Verträge und Technik synchronisieren: Was Sales verspricht, Legal formuliert und Engineering liefern kann, muss zusammenpassen.

Besonders relevant wird das für Hersteller und Plattformanbieter, die später an Catena-X, Manufacturing-X oder anderen Datenräumen teilnehmen wollen. Souveräner Datenaustausch funktioniert nur, wenn Rechte, Schnittstellen und Betriebsverantwortung bereits im Produkt angelegt sind.

Warum das wichtig ist

Der EU Data Act verschiebt Datenzugang von einer Sonderanfrage zu einer erwartbaren Produkteigenschaft. Für Entscheider geht es deshalb nicht nur um Bußgelder, sondern um Vertragsfähigkeit, Cloud-Verhandlungsmacht, Partnerintegration und das Vertrauen von Unternehmenskunden. Teams, die ihre Datenflüsse früh ordnen, reduzieren spätere Migrationskosten und können neue Geschäftsmodelle auf gemeinsamen Daten schneller prüfen. Teams, die warten, bauen Compliance unter Zeitdruck in gewachsene Systeme ein. Das wird teurer, langsamer und riskanter als eine Architektur, die Datenzugang, Interoperabilität und Cloud-Wechsel von Anfang an ernst nimmt. Eine Architecture & AI Review kann prüfen, ob Datenflüsse, Schnittstellen und Cloud-Abhängigkeiten bereits belastbar genug sind.