EU Data Act i 'Access by Design': Co musi zrobić Twój dział IT przed wrześniem 2026

Wrzesień 2026 to termin, który działy IT powinny mieć wbity w kalendarz. Od tego momentu każdy nowy produkt lub usługa cyfrowa wprowadzana na rynek UE musi spełniać wymóg access by design - czyli wbudowanego, technicznego mechanizmu dostępu do danych już na poziomie projektu architektury, nie jako późniejszy dodatek. Unijny Akt o Danych (Data Act) nie jest kolejnym dokumentem do przeczytania i odłożenia na półkę. Dla zespołów produktowych i architektów systemów to realne wyzwanie inżynieryjne z twardym deadlinem.

Czym właściwie jest EU Data Act i kogo dotyczy

Akt o Danych wszedł w życie 11 stycznia 2024 roku. Większość jego przepisów stosuje się od 12 września 2025 roku, ale obowiązek access by design dla nowych produktów wchodzi od 12 września 2026 roku. Rozporządzenie obejmuje producentów urządzeń IoT i powiązanych usług cyfrowych, dostawców usług przetwarzania danych (w tym chmury) oraz podmioty publiczne - choć każda z tych grup ma nieco inne obowiązki.

Kluczowy punkt: Data Act reguluje dane generowane przez użytkowanie produktów, nie dane osobowe jako takie. Chodzi o dane z maszyn, urządzeń, sensorów, systemów przemysłowych. Użytkownik - czy to konsument, czy firma - ma prawo dostępu do tych danych i prawo do ich udostępnienia stronie trzeciej.

Zakres terytorialny i firmy spoza UE

Data Act ma zasięg eksterytorialny porównywalny z RODO. Dotyczy każdego podmiotu, który produkuje lub sprzedaje urządzenia IoT na rynek UE, oferuje powiązane usługi cyfrowe użytkownikom w UE, lub przetwarza dane na zlecenie podmiotów unijnych. Firma z siedzibą w Stanach Zjednoczonych sprzedająca inteligentne urządzenia przemysłowe do Niemiec - tak, Data Act jej dotyczy.

Access by Design: imperatyw inżynieryjny, nie prawniczy

Tradycyjne podejście do zgodności z regulacjami wygląda mniej więcej tak: prawnicy czytają przepis, opisują wymaganie, IT dostaje ticket do zaimplementowania. Przy access by design ten model nie zadziała - wymaganie jest wbudowane w samą architekturę produktu i nie da się go dodać na końcu bez przeprojektowania systemu.

Co konkretnie oznacza "access by design" w praktyce inżynieryjnej?

• Dane generowane przez urządzenie lub usługę muszą być domyślnie dostępne dla użytkownika w formacie nadającym się do odczytu maszynowego
• Produkt musi mieć wbudowane interfejsy (API lub inne mechanizmy) umożliwiające bezpieczne przekazanie danych stronie trzeciej wskazanej przez użytkownika
• Dostęp nie może wymagać nadmiernych kroków technicznych ani nieproporcjonalnych kosztów po stronie użytkownika
• Dane muszą być udostępniane w czasie zbliżonym do rzeczywistego, o ile jest to technicznie możliwe

To oznacza, że nowe produkty planowane na rynek po wrześniu 2026 roku muszą mieć te mechanizmy zaprojektowane od zera. Nie wystarczy zaktualizować dokumentacja ani dodać endpoint w API - chodzi o to, żeby architektura od początku zakładała, że dane nie są własnością producenta do wyłącznego dysponowania.

Jakie dane podlegają obowiązkowi

Nie każdy bajt generowany przez urządzenie wchodzi w zakres regulacji. Data Act obejmuje dane, które są:

1. Generowane w trakcie użytkowania produktu lub powiązanej usługi cyfrowej
2. Niezbędne do oceny stanu produktu, jego wydajności lub środowiska użytkowania
3. Rejestrowane przez producenta lub dostępne mu w inny sposób

Dane, które producent celowo wyłączył z rejestracji, nie muszą być udostępniane - ale to podejście ma swoje granice i ryzyko (o tym za chwilę).

Przenoszalność danych i chmura - nowe zasady gry

Drugi duży blok wymagań dotyczy dostawców usług przetwarzania danych, przede wszystkim chmury. Data Act wprowadza zakaz nadmiernych opłat za wyjście (egress fees) i nakłada obowiązek umożliwienia łatwego transferu danych do konkurencyjnego dostawcy.

Co to oznacza dla strategii multi-cloud

Dla firm korzystających z chmury publicznej to dobra wiadomość: koszty przenoszenia danych między dostawcami mają się zmniejszyć, a vendor lock-in będzie trudniejszy do utrzymania przez samych dostawców. Dla dostawców chmury to presja na interoperacyjność, której wcześniej aktywnie unikali.

Praktyczne konsekwencje dla architektów:

• Kontrakty z dostawcami chmury będą wymagały renegocjacji lub przeglądu pod kątem zgodności z Data Act
• Należy audytować obecne koszty egress i sprawdzić, czy dostawca jest gotowy na zmiany wynikające z rozporządzenia
• Strategia multi-cloud staje się nie tylko wyborem technicznym, ale też narzędziem zgodności regulacyjnej

Warto zaznaczyć, że przepisy dotyczące dostawców chmury stosują się stopniowo - część wymogów weszła wcześniej, pełne wdrożenie rozciąga się na kilka lat.

Jak chronić IP i tajemnice handlowe przy otwartym dostępie

To pytanie, które pojawia się w każdej rozmowie o Data Act z architektami i prawnikami. Regulacja przyznaje prawo dostępu do danych, ale jednocześnie wprost chroni uzasadnione interesy producenta w zakresie tajemnicy handlowej.

Producent może odmówić udostępnienia danych stronie trzeciej (nie użytkownikowi), jeśli ich ujawnienie naraziłoby na szkodę tajemnicę handlową. Jednak takie odmowy muszą być uzasadnione, proporcjonalne i udokumentowane - nie mogą być standardową odpowiedzią na każde żądanie.

Techniczna architektura ochrony IP

Dobre podejście to projektowanie warstwy dostępu do danych tak, żeby oddzielała dane operacyjne (podlegające udostępnieniu) od danych diagnostycznych zawierających informacje o wewnętrznym działaniu produktu (potencjalnie objętych ochroną). Kilka sprawdzonych wzorców:

• Data aggregation layer - agregacja danych przed udostępnieniem, usuwająca szczegóły technologiczne wrażliwe dla IP
• Differential privacy - techniki matematyczne pozwalające udostępniać dane zbiorcze bez ujawniania szczegółów indywidualnych pomiarów
• Selective disclosure APIs - interfejsy z granularną kontrolą, które dane są dostępne i w jakim zakresie

Kluczowe jest udokumentowanie klasyfikacji danych jeszcze na etapie projektu. Jeśli decyzja o tym, co jest tajemnicą handlową, zapada po fakcie - producent jest w o wiele gorszej pozycji przy ewentualnym sporze.

Data Act vs. RODO: gdzie są napięcia

Oba rozporządzenia dotyczą danych, ale mają różne cele i różną logikę. RODO chroni dane osobowe i daje podmiotowi danych prawo do kontroli nad informacjami o sobie. Data Act tworzy prawa dostępu do danych generowanych przez urządzenia, nawet jeśli te dane nie są danymi osobowymi.

Problem pojawia się, gdy te zakresy się nakładają. Dane z inteligentnego urządzenia domowego - termostat, inteligentny licznik - mogą być jednocześnie danymi technicznymi (zakres Data Act) i danymi osobowymi (zakres RODO), bo ujawniają wzorce zachowania konkretnej osoby.

Cztery obszary wymagające skoordynowania

1. Minimalizacja danych vs. obowiązek dostępu - RODO każe zbierać tylko niezbędne dane, Data Act może wymagać ich rejestrowania i udostępniania
2. Cel przetwarzania - udostępnienie danych stronie trzeciej na żądanie użytkownika musi mieć podstawę prawną zgodną z RODO
3. Bezpieczeństwo danych - kanały dostępu wymagane przez Data Act muszą spełniać wymogi bezpieczeństwa z art. 32 RODO
4. Prawa do usunięcia - żądanie usunięcia danych osobowych może kolidować z historycznym dostępem do danych zagwarantowanym przez Data Act

Dochodzi do tego AI Act - jeśli dane z urządzeń zasilają system AI wysokiego ryzyka, dochodzą kolejne wymagania dotyczące jakości danych i dokumentacji. I NIS2, jeśli infrastruktura przetwarzania danych mieści się w kategorii podmiotów istotnych lub ważnych.

Praktyczny plan działania dla działów IT

Termin wrzesień 2026 wydaje się odległy, ale biorąc pod uwagę typowe cykle produktowe, czas na projektowanie nowych produktów już teraz. Firmy, które zaczną od przeglądu portfolio produktowego i mapy danych w 2025 roku, będą w o wiele wygodniejszej sytuacji niż te, które zaczną sześć miesięcy przed deadlinem.

Krok 1: Inwentaryzacja produktów i danych

Zacznij od odpowiedzi na pytania: Które produkty lub usługi wchodzą w zakres Data Act? Jakie dane generują? Kto ma do nich dostęp dzisiaj? Skąd płyną dane i gdzie są przechowywane?

To zadanie dla wspólnego zespołu: architekci, product managerowie, prawnicy i specjaliści ds. ochrony danych. Nie da się tego zrobić w silosie.

Krok 2: Ocena luki architektonicznej

Dla każdego produktu w zakresie - sprawdź, czy istnieją mechanizmy techniczne pozwalające na udostępnienie danych użytkownikowi na żądanie, przekazanie danych stronie trzeciej wskazanej przez użytkownika, rejestrację i audyt żądań dostępu oraz odwołanie zgody na dostęp strony trzeciej.

Jeśli tych mechanizmów nie ma - masz lukę architektoniczną do wypełnienia. Lepiej wiedzieć o tym teraz niż w sierpniu 2026.

Krok 3: Projektowanie API dostępu do danych

Nowe produkty powinny mieć osobny, dobrze zabezpieczony interfejs dostępu do danych - z uwierzytelnianiem, logowaniem i granularną kontrolą zakresu udostępnianych informacji. Warto rozważyć standardy takie jak OpenAPI do dokumentacji czy OAuth 2.0 do autoryzacji - to ułatwi interoperacyjność wymaganą przez przepisy.

Krok 4: Klasyfikacja danych i dokumentacja ochrony IP

Przed wdrożeniem dostępu - zdefiniuj, które dane są tajemnicą handlową i dlaczego. Udokumentuj tę klasyfikację. Zbuduj techniczne mechanizmy segregacji danych na etapie architektury, nie jako późniejszą nakładkę.

Krok 5: Przegląd umów z dostawcami chmury

Sprawdź aktualne umowy pod kątem opłat za wyjście i możliwości transferu danych. Nie czekaj, aż dostawca sam dostosuje warunki - negocjuj proaktywnie, zwłaszcza przy odnowieniach kontraktów.

Szansa, nie tylko obowiązek

Firmy, które potraktują access by design jako pretekst do porządnego audytu architektury danych, mogą wyjść z tego ćwiczenia z lepiej udokumentowanymi systemami, wyraźniejszą mapą przepływów danych i solidniejszą podstawą do budowania produktów opartych na danych.

Interoperacyjność wymagana przez Data Act może też otworzyć nowe możliwości biznesowe: dostęp do danych od innych producentów, partnerstwa z podmiotami trzecimi, nowe usługi oparte na agregacji danych z wielu źródeł.

Deadline wrześniowy to koniec punktu startowego - czas na projektowanie jest teraz.

Źródła

1. The EU Data Act: What Businesses Need to Know - Latham & Watkins, szczegółowa analiza prawna i praktycznych konsekwencji Data Act dla firm
2. EU Data Act: Time for a Reality Check - Corporate Compliance Insights / ZwillGen, analiza operacyjnych implikacji i napięć między Data Act a RODO
3. The EU Data Act: Where Things Stand Now - Bird & Bird, marzec 2026, przegląd statusu wdrożenia, kluczowych terminów i obowiązku access by design
4. Akt o Danych - Komisja Europejska - oficjalna strona KE z tłem, celami i mechanizmem działania rozporządzenia