Data Act Access by Design Österreich bedeutet: Der Zugang zu nutzbaren Produktdaten wird vor der Freigabe als Bestandteil des vernetzten Produkts und des verbundenen Dienstes geplant. Er ist kein Export-Ticket, das erst nach dem Marktstart bearbeitet wird. Für österreichische Hersteller, deren Produktdaten in Wartungs-, Automatisierungs- oder KI-Abläufe einfließen, lautet die Führungsfrage deshalb: Trägt die Architektur einen autorisierten Datenzugang, ohne Datenschutz, Sicherheit oder Geschäftsgeheimnisse zu unterlaufen?
Warum wird der 12. September 2026 zu einer Architekturentscheidung?
Für neu in Verkehr gebrachte vernetzte Produkte und verbundene Dienste muss der Datenzugang von Beginn an mitgedacht werden. Artikel 3 Absatz 1 beschreibt Produktdaten, Daten verbundener Dienste und die zu ihrer Auslegung erforderlichen Metadaten als standardmäßig einfach, sicher, unentgeltlich, umfassend, strukturiert und maschinenlesbar zugänglich. Soweit relevant und technisch durchführbar, soll der Zugang direkt möglich sein.
Das ist keine fertige API-Spezifikation. Produkt, Betrieb, Informationssicherheit, Datenschutz und Rechtsberatung müssen weiterhin klären, welche Daten betroffen sind, wer als Nutzer oder Dateninhaber handelt, welcher Zugang technisch tragfähig ist und welche Nachweise die Freigabe stützen.
Illustratives Wiener Szenario: Die Telemetrie läuft, der Nutzerzugang nicht
Im technischen Freigabebericht steht kein Ausfall. Gerät, Dashboard und Modell funktionieren. Trotzdem wurden drei Fragen zu einer einzigen grünen Statusanzeige verdichtet: Kann der Hersteller Daten sehen? Kann der Nutzer die relevanten Daten verwenden? Kann ein autorisierter Dritter sie sicher übernehmen? Die Geschäftsführung braucht darauf eine dokumentierte Antwort.
Was heißt Access by Design auf Architekturebene?
Access by Design verlangt auf Architekturebene einen geplanten Weg von der Datenerzeugung bis zur autorisierten Nutzung. Dazu gehören verständliche Metadaten, Identitäts- und Berechtigungskontrollen, ein widerrufbarer Drittzugang und belastbare Betriebsnachweise. Der bloße Hinweis, dass Telemetrie in einem Herstellerportal sichtbar ist, reicht als Architekturantwort nicht aus.
Die rechtliche Anwendbarkeit bleibt einzelfallbezogen. Die technische Aufgabe ist konkret: Produkt, verbundener Dienst, Datenspeicher, Verarbeitungsschritte, Zugriffsschnittstellen, Nutzer, Dritte, Kontrollverantwortliche und Freigaben werden als ein System erfasst.
Welche vernetzten Produkte und verbundenen Dienste gehören in die Prüfung?
Ein vernetztes Produkt ist nicht auf Consumer-IoT beschränkt. Die Europäische Kommission nennt unter anderem vernetzte Fahrzeuge, Gesundheits- und Fitnessgeräte sowie Industrie- und Landmaschinen. Ein verbundener Dienst ist ein digitaler Dienst, der so mit dem Produkt verbunden ist, dass er dessen Funktionen beeinflusst oder anpasst.
Der richtige Ausgangspunkt ist daher die Produkt-Service-Grenze und nicht das Marketingetikett „IoT“. Eine Maschine, ihre Steuerungsanwendung, ein Fernwartungsdienst und eine KI-Komponente können betrieblich eine Kette bilden, obwohl sie unterschiedliche Rollen und Datenverantwortung erzeugen.
Wer trägt welche Rolle: Hersteller, Dateninhaber, Nutzer oder Dritter?
Die Geschäftsführung oder der benannte Sponsor trägt die Freigabeentscheidung. Die Datenarchitektur muss jedoch die Akteure trennen. Der Hersteller konzipiert das Produkt und bringt es in Verkehr. Der Dateninhaber kann über ohne Weiteres verfügbare Daten verfügen. Der Nutzer besitzt, mietet oder least das Produkt oder nimmt den verbundenen Dienst in Anspruch. Ein Dritter kann auf Verlangen des Nutzers Daten erhalten, soweit die einschlägigen Grenzen eingehalten werden.
Ein Unternehmen kann mehrere Rollen zugleich einnehmen. Vertrag und tatsächlicher Systembetrieb beeinflussen die Zuordnung. Deshalb wird die Rollenkarte pro Produkt und Dienst erstellt und nicht aus einer allgemeinen Vorlage übernommen.
Welche Daten sind zugänglich und wo verläuft die Grenze?
Die offizielle Erläuterung der Kommission unterscheidet ohne Weiteres verfügbare Rohdaten und vorverarbeitete Daten von abgeleiteten oder erschlossenen Daten. Ebenso wichtig sind relevante Metadaten, ohne die Werte nicht zuverlässig ausgelegt und verwendet werden können. Eine Datei mit unbekannten Feldcodes ist zwar technisch lesbar, aber operativ kaum brauchbar.
Die Frist rechtfertigt keine zusätzliche Datensammlung. Wenn personenbezogene Daten vorkommen, müssen Datenzugang, Datenminimierung, Zweckbindung, Aufbewahrung und Sicherheit gemeinsam gestaltet werden.
Warum betrifft das die Produktionsreife von KI-Systemen?
Ein KI-Ablauf kann nicht nachvollziehbarer sein als sein Datenpfad. Wenn ein autorisierter Nutzer Quelle, Bedeutung, Zeitraum, Qualitätskontrolle und erlaubten Zweck der Produktdaten nicht bestimmen kann, lassen sich Modellergebnisse schwer reproduzieren, hinterfragen oder zu einem anderen Dienst übertragen.
Die Sechs-Ebenen-Karte für Access-by-Design-Bereitschaft
Für jede Ebene müssen eine verantwortliche Person und ein prüfbarer Nachweis benannt werden können.
| Ebene | Entscheidungsfrage | Mindestnachweis |
|---|---|---|
| 1. Umfang und Rollen | Welches Produkt, welcher verbundene Dienst, Nutzer und Dateninhaber werden geprüft? | Systemgrenze, Datum des Inverkehrbringens, Rollenkarte und Freigabeverantwortung |
| 2. Daten und Metadaten | Welche Roh- oder vorverarbeiteten Daten sind ohne Weiteres verfügbar und wodurch werden sie verständlich? | Feldkatalog, Herkunft, Einheiten, Zeitstempel, Qualitätshinweise und Ausschlüsse |
| 3. Zugangsmechanismus | Kann der Nutzer Daten einfach, strukturiert und maschinenlesbar erhalten? | Dokumentierte API, Portal- oder Exportstrecke, Beispielantwort und Verfügbarkeitstest |
| 4. Identität und Sicherheit | Wie werden Nutzer und autorisierte Dritte authentifiziert, berechtigt und gesperrt? | Berechtigungsmodell, Zugangsdatenfluss, Limits, Audit-Log und Vorfallsweg |
| 5. Schutzgrenzen | Wo verändern personenbezogene Daten, Geschäftsgeheimnisse, Produktsicherheit oder Drittstaatenbezug den Pfad? | Datenklassifizierung, Rechtsgrundlagenentscheidung, Schutzmaßnahmen und Eskalationsverantwortung |
| 6. Nachweise und Verträge | Ist belegbar, was zugesagt, getestet, freigegeben und betrieben wurde? | Vorvertragliche Information, Schnittstellentest, Entscheidungsprotokoll und Prüftermin |
Vier Freigabewege statt eines binären Compliance-Häkchens
Das Managementergebnis sollte nicht vorschnell „konform“ oder „nicht konform“ heißen. Erforderlich ist eine kontrollierte Produktentscheidung, die offene Ebenen und deren Konsequenzen sichtbar macht.
| Entscheidung | Wann sie passt | Erforderlicher Nachweis |
|---|---|---|
| Freigabe | Umfang, Zugang, Kontrollen, Nachweise und Verantwortung sind für das geprüfte Produkt geklärt. | Unterzeichnete Baseline und nächster Prüftermin |
| Freigabe unter Auflagen | Eine begrenzte Lücke hat Verantwortliche, Frist, kompensierende Kontrolle und Rücknahmeauslöser. | Auflagenregister und dokumentierte Risikoannahme |
| Neukonzeption | Daten oder Metadaten sind ohne improvisierten manuellen Weg nicht sicher, konsistent oder unabhängig nutzbar. | Neue Schnittstellengrenze, Testplan und Release-Gate |
| Stopp und Fachprüfung | Anwendbarkeit, Datenschutzgrundlage, Geschäftsgeheimnis, Sicherheit oder vertragliche Befugnis ist wesentlich und ungeklärt. | Stoppentscheidung, gesicherte Belege und präzise Rechts- oder Sicherheitsfrage |
Wie verändern Datenschutz, Geschäftsgeheimnisse und Sicherheit den Zugang?
Datenzugang hebt andere Schutzregeln nicht auf. Die Kommission weist darauf hin, dass für personenbezogene Daten eine gültige Rechtsgrundlage nötig sein kann, wenn der Nutzer nicht die betroffene Person ist. Sie erläutert außerdem Schutzmaßnahmen für Geschäftsgeheimnisse und begrenzte Ausnahmen bei schwerem wirtschaftlichem Schaden oder Risiken für die Produktsicherheit.
Die Architekturantwort lautet Trennung: Felder klassifizieren, personenbezogene Daten minimieren, Zwecke begrenzen, sensible Metadaten schützen, Rollen einzeln authentifizieren, Offenlegungsentscheidungen protokollieren und Ausnahmen an zuständige Fachleute eskalieren. Dieser Beitrag liefert keine Rechtsberatung.
Was ist in den nächsten sieben Tagen zu tun?
Fixieren Sie den Freigabeumfang und erfassen Sie alle vernetzten Produkte und verbundenen Dienste, deren Inverkehrbringen nach dem 12. September 2026 geplant ist. Benennen Sie Freigabesponsor, Produktverantwortung, Dateninhaber, Informationssicherheit sowie Datenschutz- und Rechtseigentümer. Testen Sie einen echten Nutzerzugang von der Identitätsprüfung bis zur nutzbaren Bereitstellung samt Metadaten.
Ein fehlgeschlagener Test gehört in die Freigabeentscheidung und nicht unkommentiert in den Backlog. Ordnen Sie die Lücke einem der vier Wege zu.
Was muss innerhalb von 30 Tagen stehen?
Erstellen Sie Daten- und Metadatenkatalog, grenzen Sie ohne Weiteres verfügbare von abgeleiteten Daten ab, dokumentieren Sie die Zugriffsschnittstelle und definieren Sie Autorisierung und Widerruf für Dritte. Prüfen Sie Fehlerfälle: nicht erreichbarer Export, veraltete Metadaten, überbreite Berechtigung, Mandantendurchgriff, verspäteter Widerruf und zweckfremde Nutzung.
Was muss innerhalb von 90 Tagen betrieblich funktionieren?
Überführen Sie die Freigabe in eine Betriebskontrolle. Beobachten Sie Bearbeitungszeit, Schnittstellenverfügbarkeit, Ablehnungsgründe, Sicherheitsereignisse, Schemaänderungen und Nachweisaktualität. Wiederholen Sie die Entscheidung, wenn sich Produkt, verbundener Dienst, Datenspeicher, Schnittstelle, KI-Zweck oder Drittbeziehung wesentlich verändert.
Das minimale Nachweispaket für Produktdaten
Das Paket beweist für sich allein keine Rechtskonformität. Es verhindert aber, dass die Freigaberunde von Erinnerungen, Screenshots und Annahmen ohne Eigentümer abhängt. Der KI-Systemverantwortliche erhält damit genug Kontext, um Zweck, Berechtigung und Reproduzierbarkeit des nachgelagerten Ablaufs zu prüfen.
Wann ist ein Architecture Mandate sinnvoll?
Ein Architecture Mandate ist sinnvoll, wenn ein wesentlicher KI- oder Automatisierungsablauf von Produktdaten abhängt und Umfang, Zugang, Befugnisse, Kontrollen und Nachweise vor der Freigabe nicht zusammenpassen. Das Mandat schafft eine begrenzte Produktionsentscheidung; es ersetzt weder Rechtsberatung noch Zertifizierung und verspricht keine vollständige Produktimplementierung.
Bringen Sie ein Produkt oder einen Ablauf, das geplante Datum des Inverkehrbringens, den heutigen Datenzugang, betroffene Nutzer, eine vorhandene Systemskizze und die offene Freigabeentscheidung mit.
Häufige Fragen zu Access by Design
Beginnt der gesamte EU Data Act am 12. September 2026?
Nein. Der Data Act ist grundsätzlich seit 12. September 2025 anwendbar; das spätere Datum betrifft die Konstruktionspflicht aus Artikel 3 Absatz 1 für danach in Verkehr gebrachte vernetzte Produkte und verbundene Dienste.
Verlangt Access by Design immer eine Echtzeit-API?
Nein. Direkter Zugang ist vorgesehen, soweit er relevant und technisch durchführbar ist; der vertretbare Mechanismus hängt vom Produkt, den verfügbaren Daten, dem Nutzerbedarf sowie Sicherheits- und Rechtsgrenzen ab.
Sind KI-Erkenntnisse und abgeleitete Daten automatisch umfasst?
Nein. Die offizielle Orientierung unterscheidet ohne Weiteres verfügbare Roh- und vorverarbeitete Daten von erschlossenen oder abgeleiteten Daten; deshalb muss die Datengrenze ausdrücklich dokumentiert werden.
Darf ein Hersteller bei Geschäftsgeheimnissen jeden Zugang verweigern?
Nein. Schutzmaßnahmen und mögliche Ausnahmen sind bedingt und einzelfallbezogen; sie verlangen verhältnismäßige Maßnahmen, dokumentierte Gründe und Fachprüfung statt einer pauschalen Verweigerung.
Was sollte ein österreichisches Produktteam zuerst prüfen?
Beginnen Sie mit einer Produktfreigabe: Akteure, Datum des Inverkehrbringens, Daten und Metadaten, Zugangsweg, Berechtigungen, Schutzgrenzen und die für die endgültige Entscheidung verantwortliche Person.
Geprüfte offizielle Quellen
- EUR-Lex — Verordnung (EU) 2023/2854
- Europäische Kommission — Data Act explained
- Digital Austria — Data Act
- RTR — Zeitplan und Umsetzung
- RTR — Datenzugang und Datennutzung
Quellenstand: 6. September 2026. Der Beitrag ist eine operative Architekturanalyse und keine Rechtsberatung.
Weiterlesen