Data Act i produkty IoT od 12 września 2026 r. Jak zapewnić użytkownikowi dostęp do danych?

Data Act jest stosowany zasadniczo od 12 września 2025 roku. Kolejna ważna data dotyczy jednak producentów produktów IoT i dostawców usług powiązanych. Obowiązek z art. 3 ust. 1 Data Act obejmie produkty skomunikowane i związane z nimi usługi wprowadzane na rynek po 12 września 2026 roku. Mają być projektowane w taki sposób, aby dane produktu, dane usługi powiązanej i metadane potrzebne do ich wykorzystania były domyślnie łatwo, bezpiecznie i bezpłatnie dostępne dla użytkownika. Jeżeli ma to znaczenie i jest technicznie wykonalne, dostęp powinien być bezpośredni. W pozostałych przypadkach posiadacz danych musi zapewnić prostą elektroniczną ścieżkę udostępnienia, na przykład przez portal lub API. W artykule wyjaśniamy, jakie dane obejmuje ten obowiązek, jak zaprojektować proces dostępu i kiedy udostępnienie trzeba pogodzić z RODO, cyberbezpieczeństwem oraz ochroną tajemnic przedsiębiorstwa.

Najważniejsze informacje

• Data Act nie zaczyna obowiązywać dopiero we wrześniu 2026 roku. Rozporządzenie jest stosowane zasadniczo od 12 września 2025 roku.
• Po 12 września 2026 roku art. 3 ust. 1 obejmie produkty skomunikowane i usługi powiązane wprowadzane na rynek po tej dacie.
• Produkt powinien domyślnie zapewniać dane w sposób łatwy, bezpieczny, bezpłatny, kompletny oraz w ustrukturyzowanym, powszechnie używanym formacie nadającym się do odczytu maszynowego.
• Jeżeli bezpośredni dostęp z urządzenia lub usługi nie jest właściwy albo technicznie wykonalny, dane łatwo dostępne posiadaczowi trzeba udostępnić użytkownikowi bez zbędnej zwłoki.
• Zakres obejmuje przede wszystkim dane surowe i wstępnie przetworzone oraz metadane niezbędne do ich interpretacji. Nie obejmuje automatycznie każdego wniosku, prognozy i wyniku utworzonego za pomocą złożonego, własnościowego algorytmu.
• Użytkownikiem może być konsument, firma albo podmiot publiczny, który jest właścicielem produktu, korzysta z niego na podstawie najmu lub leasingu albo otrzymuje usługę powiązaną.
• Użytkownik może zażądać przekazania danych wybranemu podmiotowi trzeciemu, na przykład niezależnemu serwisowi lub dostawcy usługi optymalizacyjnej.
• Powołanie się na tajemnicę przedsiębiorstwa nie uzasadnia automatycznie odmowy. Najpierw trzeba wskazać konkretne tajemnice i uzgodnić proporcjonalne zabezpieczenia.
• Data Act nie zastępuje RODO i sam nie tworzy podstawy do gromadzenia danych osobowych. Jeżeli użytkownik nie jest osobą, której dane dotyczą, udostępnienie danych osobowych wymaga odrębnej podstawy prawnej.
• Dostęp użytkownika ma być bezpłatny. W relacji pomiędzy posiadaczem danych a biznesowym odbiorcą danych może natomiast wystąpić rozsądna i niedyskryminacyjna rekompensata.

Zapraszamy do współpracy

Szczegółowe informacje o ofercie i warunkach współpracy można uzyskać telefonicznie lub wysyłając zapytanie za pomocą formularza kontaktowego.

BPPZ – Biuro Porad Prawnych Zacharski

– Chcesz przygotować produkt IoT, umowy i proces udostępniania danych?

• +48 600 784 526
• kontakt@bppz.pl

Zadzwoń Napisz wiadomość

Co dokładnie zmienia się 12 września 2026 roku?

Rozporządzenie (UE) 2023/2854, określane jako Data Act lub akt w sprawie danych, weszło w życie 11 stycznia 2024 roku. Jest stosowane zasadniczo od 12 września 2025 roku. Oznacza to, że prawa użytkowników do dostępu do danych łatwo dostępnych posiadaczowi oraz do przekazania takich danych podmiotowi trzeciemu nie powinny być przedstawiane jako całkowicie nowy obowiązek rozpoczynający się dopiero w 2026 roku.

Artykuł 50 Data Act ustanawia jednak osobny termin dla obowiązku wynikającego z art. 3 ust. 1. Dotyczy on projektowania i wytwarzania produktów skomunikowanych oraz projektowania i świadczenia usług powiązanych. Obowiązek ten stosuje się do produktów i związanych z nimi usług wprowadzanych na rynek po 12 września 2026 roku.

Data	Znaczenie dla firmy
11 stycznia 2024 r.	Data Act wszedł w życie
12 września 2025 r.	Rozporządzenie zaczęło być zasadniczo stosowane, w tym prawa dostępu do danych łatwo dostępnych posiadaczowi
Po 12 września 2026 r.	Produkty skomunikowane i usługi powiązane wprowadzane na rynek muszą spełniać obowiązek projektowania dostępu z art. 3 ust. 1

Ta różnica ma znaczenie praktyczne. W przypadku starszego produktu posiadacz danych może być zobowiązany do udostępnienia użytkownikowi danych, które już legalnie otrzymuje albo może uzyskać prostą operacją. Data Act nie nakłada jednak z mocą wsteczną obowiązku przebudowania każdego wcześniej wprowadzonego urządzenia tak, aby zapewniało bezpośredni dostęp zgodny z art. 3 ust. 1.

W odniesieniu do nowego produktu nie wystarczy natomiast przygotowanie adresu e-mail, na który użytkownik może wysłać żądanie. Dostęp do danych ma zostać uwzględniony w architekturze urządzenia, aplikacji i usługi. Zespół produktowy powinien rozstrzygnąć tę kwestię przed zamrożeniem projektu, wyborem protokołów komunikacyjnych i ustaleniem modelu przechowywania danych.

Czym jest produkt skomunikowany?

Data Act posługuje się pojęciem „connected product”, tłumaczonym w polskiej wersji rozporządzenia jako produkt skomunikowany. Jest nim rzecz, która uzyskuje, generuje albo zbiera dane dotyczące swojego używania lub otoczenia i może je komunikować za pomocą usługi łączności elektronicznej, połączenia fizycznego albo dostępu na urządzeniu.

Jednocześnie podstawową funkcją takiego produktu nie może być przechowywanie, przetwarzanie lub przesyłanie danych w imieniu podmiotu innego niż użytkownik.

W praktyce produktami skomunikowanymi mogą być między innymi:

• maszyny przemysłowe wyposażone w czujniki;
• inteligentne urządzenia gospodarstwa domowego;
• połączone pojazdy i urządzenia flotowe;
• instalacje HVAC zarządzane cyfrowo;
• urządzenia rolnictwa precyzyjnego;
• systemy magazynowe i logistyczne;
• urządzenia medyczne, jeżeli nie podlegają wyłączeniu lub szczególnej regulacji sektorowej;
• liczniki, falowniki, magazyny energii i systemy zarządzania energią;
• kamery, czujniki dostępu i inne urządzenia bezpieczeństwa połączone z aplikacją lub chmurą.

Nie każde urządzenie z łącznością automatycznie staje się produktem skomunikowanym. Trzeba sprawdzić jego podstawową funkcję, rodzaj generowanych danych oraz to, czy dane dotyczą używania produktu lub jego otoczenia. Urządzenie ogólnego przeznaczenia, którego podstawową funkcją jest przetwarzanie lub przechowywanie danych, może znajdować się poza tym zakresem.

Istotna jest również ocena całego ekosystemu. Na przykład sama kamera IP może generować dane o stanie urządzenia, błędach, temperaturze, czasie pracy i konfiguracji, a jednocześnie rejestrować treść obrazu. Dane techniczne mogą podlegać zasadom Data Act, podczas gdy treść nagrania wymaga odrębnej analizy, w szczególności na gruncie RODO i przepisów dotyczących monitoringu. Zasady bezpieczeństwa takiego urządzenia opisuje artykuł BPPZ Kamery IP w firmie. Jak zabezpieczyć monitoring przed przejęciem i naruszeniem RODO?.

Czym jest usługa powiązana?

Usługa powiązana to usługa cyfrowa, inna niż usługa łączności elektronicznej, która jest połączona z produktem przy zakupie, najmie albo leasingu w taki sposób, że bez niej produkt nie wykonywałby jednej lub kilku swoich funkcji. Może to być także usługa dołączona później przez producenta albo podmiot trzeci, aby dodać, zaktualizować lub dostosować funkcje urządzenia.

Przykładem może być:

• aplikacja sterująca inteligentnym termostatem;
• platforma chmurowa do zarządzania maszyną;
• oprogramowanie aktualizujące funkcje pojazdu;
• panel zarządzania systemem energetycznym;
• usługa umożliwiająca zdalne konfigurowanie urządzenia;
• cyfrowy interfejs, przez który użytkownik przekazuje polecenia produktowi.

Nie każda usługa oferowana obok produktu jest usługą powiązaną. Zwykłe doradztwo, odrębna analityka finansowa albo tradycyjna usługa naprawy nie stają się nią tylko dlatego, że dotyczą urządzenia. Znaczenie ma funkcjonalne połączenie z produktem i wymiana danych lub poleceń wpływających na jego działanie.

Rozróżnienie powinno zostać opisane w dokumentacji produktu. Jeżeli producent błędnie uzna część usługi za niezależny dodatek, może pominąć dane usługi powiązanej przy projektowaniu dostępu.

Kto jest użytkownikiem, posiadaczem danych i odbiorcą danych?

Data Act rozdziela role, które w jednym modelu biznesowym mogą należeć do różnych podmiotów.

Rola	Znaczenie	Przykład
Użytkownik	Właściciel produktu, podmiot posiadający czasowe prawo do korzystania albo odbiorca usługi powiązanej	Fabryka leasingująca maszynę
Posiadacz danych	Podmiot mający prawo lub obowiązek używania i udostępniania danych na podstawie Data Act, prawa UE, prawa krajowego lub ustaleń umownych	Producent otrzymujący dane telemetryczne do swojej chmury
Odbiorca danych	Przedsiębiorca inny niż użytkownik, któremu posiadacz udostępnia dane	Niezależny serwis albo dostawca analityki energetycznej
Osoba, której dane dotyczą	Osoba fizyczna, do której odnoszą się dane osobowe	Kierowca pojazdu służbowego albo operator maszyny

Producent nie zawsze jest posiadaczem danych. Jeżeli dane trafiają do platformy prowadzonej przez inny podmiot, trzeba ustalić, kto decyduje o ich wykorzystaniu, kto ma techniczną możliwość ich pozyskania i kto jest zobowiązany do obsługi żądania.

Również nabywca nie zawsze będzie jedynym użytkownikiem. Produkt może zostać wynajęty, leasingowany, współdzielony albo używany przez kilka spółek. System weryfikacji uprawnień musi więc obsługiwać zmianę właściciela, wygaśnięcie leasingu, przekazanie urządzenia oraz wielu użytkowników o różnych zakresach dostępu.

Jakie dane trzeba udostępnić?

Data Act obejmuje dane produktu oraz dane usługi powiązanej. Do udostępnianego zestawu trzeba dołączyć metadane potrzebne do interpretacji i używania danych.

Dane produktu

Są to dane generowane przez używanie produktu skomunikowanego, które producent zaprojektował jako możliwe do pobrania za pomocą łączności elektronicznej, połączenia fizycznego albo dostępu na urządzeniu. Obejmuje to także dane dostępne producentowi, użytkownikowi albo podmiotowi trzeciemu.

Przykładami mogą być:

• temperatura, ciśnienie, wilgotność i przepływ;
• prędkość, położenie i przyspieszenie;
• zużycie energii lub paliwa;
• czas pracy i liczba cykli;
• stan baterii i podzespołów;
• komunikaty o błędach i zdarzenia serwisowe;
• ustawienia wprowadzone przez użytkownika;
• status pracy, tryb czuwania i przestoje;
• dane o otoczeniu rejestrowane przez czujniki.

Dane usługi powiązanej

Obejmują cyfrowe odwzorowanie działań użytkownika albo zdarzeń związanych z produktem, zapisanych celowo lub powstałych jako skutek uboczny działania użytkownika podczas świadczenia usługi.

Mogą to być na przykład:

• polecenia wysłane z aplikacji do urządzenia;
• zmiany harmonogramu pracy;
• wybór trybu działania;
• zdarzenia powstałe przy zdalnym sterowaniu;
• informacje o korzystaniu z określonych funkcji usługi.

Dane surowe i wstępnie przetworzone

Zakres obejmuje dane surowe oraz dane wstępnie przetworzone po to, aby były zrozumiałe i nadawały się do wykorzystania. Wstępne przetworzenie może polegać na przeliczeniu sygnału czujnika na temperaturę, ciśnienie, prędkość lub inną wielkość fizyczną. Posiadacz danych nie musi jednak dokonywać znacznych inwestycji w czyszczenie i przekształcanie danych tylko po to, aby spełnić żądanie.

Metadane

Sam plik z wartościami może być bezużyteczny bez informacji o jednostkach, znacznikach czasu, identyfikatorach czujników, częstotliwości pomiaru, wersji oprogramowania i kodach błędów. Dlatego Data Act obejmuje metadane niezbędne do interpretacji oraz dalszego używania danych.

Element	Przykład
Wartość	82,4
Jednostka	stopnie Celsjusza
Źródło	czujnik temperatury 04
Czas	2026-09-14 10:31:08 UTC
Kontekst	praca w trybie produkcyjnym
Jakość	pomiar prawidłowy, bez flagi błędu
Wersja	firmware 5.2.1

Metadane powinny być opisane w sposób stabilny. Jeżeli producent zmienia słownik pól lub znaczenie kodów, powinien wersjonować dokumentację i poinformować użytkowników API.

Jakich danych Data Act nie nakazuje automatycznie udostępniać?

Obowiązek nie obejmuje każdej informacji znajdującej się w systemie producenta.

Poza podstawowym zakresem mogą pozostawać:

• wnioski i informacje wyprowadzone z danych w wyniku dodatkowych inwestycji;
• oceny, prognozy i rekomendacje utworzone za pomocą złożonych, własnościowych algorytmów;
• wyniki zaawansowanej fuzji danych z wielu czujników, jeżeli stanowią odrębnie wyprowadzoną informację;
• treści tekstowe, dźwiękowe i audiowizualne rejestrowane, przesyłane albo odtwarzane przez produkt;
• dane przetwarzane przez urządzenie wyłącznie w imieniu podmiotu innego niż użytkownik;
• informacje, których posiadacz nie otrzymuje i nie może legalnie uzyskać prostą operacją, jeżeli rozpatrywane jest żądanie z art. 4 lub 5.

Granica pomiędzy wstępnym przetworzeniem a informacją wyprowadzoną bywa trudna. Nazwanie każdego wyniku „analityką własnościową” nie rozwiązuje problemu. Firma powinna przygotować katalog danych i dla każdego pola wskazać źródło, etap przetworzenia, sposób obliczenia oraz powód zaliczenia go do zakresu albo wyłączenia.

W razie sporu znaczenie będzie miało to, czy dana wartość jedynie tłumaczy sygnał urządzenia na użyteczną jednostkę, czy powstaje dzięki dodatkowym nakładom, łączeniu wielu źródeł i zastosowaniu złożonego modelu. Decyzję warto udokumentować przed otrzymaniem pierwszego żądania.

Jak powinien wyglądać dostęp zaprojektowany zgodnie z art. 3 ust. 1?

Produkt skomunikowany i usługa powiązana powinny być projektowane tak, aby dane oraz odpowiednie metadane były domyślnie:

• łatwo dostępne;
• bezpieczne;
• bezpłatne dla użytkownika;
• kompletne;
• ustrukturyzowane;
• dostępne w powszechnie używanym formacie;
• możliwe do odczytu maszynowego;
• bezpośrednio dostępne, jeżeli ma to znaczenie i jest technicznie wykonalne.

„Domyślnie” oznacza, że dostęp nie powinien wymagać niestandardowego projektu wykonywanego dopiero po zakupie produktu. Rozwiązanie powinno stanowić część architektury urządzenia i usługi.

Zasada ta jest zbliżona organizacyjnie do podejścia privacy by design, ale ma inny cel. Privacy by design ogranicza ryzyko dla danych osobowych, natomiast Data Act wymaga zaprojektowania realnej kontroli użytkownika nad danymi produktu. Oba wymagania trzeba pogodzić. Więcej o uwzględnianiu ochrony danych już na etapie projektu opisuje artykuł BPPZ Privacy by design w małej firmie.

Przed zatwierdzeniem rozwiązania firma powinna przeprowadzić wspólny przegląd prawny, produktowy i techniczny. Pomocne może być projektowe doradztwo prawne, obejmujące kwalifikację produktu, mapę danych, role stron, interfejs użytkownika i treść umów.

Bezpośredni dostęp czy portal i API?

Data Act nie narzuca jednego interfejsu dla każdego produktu. Odpowiedni model zależy od architektury, częstotliwości danych, ryzyka i sposobu korzystania.

Model	Kiedy może być właściwy	Najważniejsze wymagania
Dostęp na urządzeniu	Dane są przechowywane lokalnie i użytkownik może je pobrać bez udziału producenta	Czytelna instrukcja, standardowy format, uwierzytelnienie i zabezpieczenie portu
Połączenie lokalne	Produkt udostępnia dane przez kabel, Bluetooth, Wi-Fi lub sieć lokalną	Stabilny protokół, kontrola dostępu, dokumentacja i ochrona przed nieuprawnionym odczytem
Portal użytkownika	Dane mają umiarkowany wolumen i użytkownik potrzebuje okresowych eksportów	Eksport maszynowy, historia, zakres dat, metadane, brak ograniczenia wyłącznie do PDF
API	Dane są potrzebne regularnie, automatycznie lub w czasie rzeczywistym	Dokumentacja, wersjonowanie, limity proporcjonalne do obciążenia, tokeny, logi i dostępność
Strumień danych	Przypadek wymaga ciągłego odbioru i rozwiązanie jest technicznie wykonalne	Ciągłość, znaczniki czasu, obsługa błędów, bezpieczeństwo i mechanizmy wznowienia

Bezpośredni dostęp ma być zapewniony wtedy, gdy jest istotny i technicznie wykonalny. Nie oznacza to, że każdy czujnik musi posiadać publiczny interfejs sieciowy. Wbudowanie niezabezpieczonego API tylko po to, aby formalnie wykazać dostęp, mogłoby naruszać wymagania bezpieczeństwa.

Jeżeli użytkownik nie może uzyskać danych bezpośrednio, posiadacz danych powinien udostępnić dane łatwo dostępne na podstawie prostego żądania elektronicznego, jeżeli jest to technicznie wykonalne. Dane mają zostać przekazane bez zbędnej zwłoki, w tej samej jakości, która jest dostępna posiadaczowi, oraz w razie potrzeby w sposób ciągły i w czasie rzeczywistym.

PDF z podsumowaniem może być przydatny dla człowieka, ale zwykle nie wystarczy jako jedyny format. Użytkownik powinien otrzymać dane w postaci umożliwiającej ich automatyczne przetwarzanie, na przykład CSV, JSON, XML albo za pomocą dobrze opisanego API.

Jak przygotować ścieżkę żądania użytkownika?

Proces nie powinien wymagać od użytkownika korespondencji z kilkoma spółkami ani poszukiwania właściwego formularza w regulaminach. Najlepiej zapewnić jeden punkt wejścia, który rozpoznaje produkt, użytkownika i oczekiwany sposób dostępu.

Praktyczny proces może wyglądać następująco:

1. Użytkownik loguje się do konta albo składa elektroniczne żądanie.
2. System weryfikuje, czy jest właścicielem produktu, najemcą, leasingobiorcą lub odbiorcą usługi powiązanej.
3. Weryfikacja obejmuje tylko informacje niezbędne do potwierdzenia uprawnienia.
4. Użytkownik wybiera produkt, zakres czasu i sposób otrzymania danych.
5. System przedstawia dostępne kategorie danych oraz metadane.
6. Dane są udostępniane bez zbędnej zwłoki, a przy właściwym przypadku także w sposób ciągły.
7. Użytkownik może wskazać podmiot trzeci i określić cel oraz okres udostępniania.
8. System rejestruje wykonanie żądania, błędy i zmiany uprawnień w zakresie potrzebnym do bezpieczeństwa oraz utrzymania infrastruktury.
9. Użytkownik może zakończyć udostępnianie podmiotowi trzeciemu.
10. Odmowa lub ograniczenie otrzymuje konkretne uzasadnienie i informację o dostępnych środkach zaskarżenia.

Data Act zakazuje czynienia korzystania z praw nadmiernie trudnym. Interfejs nie może ukrywać eksportu, zmuszać do wielokrotnego potwierdzania tej samej decyzji ani przedstawiać neutralnego wyboru w sposób nakłaniający użytkownika do pozostawienia danych wyłącznie producentowi.

Jak zweryfikować użytkownika bez zbierania nadmiernych danych?

Posiadacz danych może sprawdzić, czy osoba fizyczna lub prawna rzeczywiście jest użytkownikiem. Nie powinien jednak żądać informacji wykraczających poza to, co jest potrzebne do weryfikacji.

Możliwe mechanizmy to:

• konto powiązane z numerem seryjnym produktu;
• kod aktywacyjny przekazany przy zakupie;
• potwierdzenie z aplikacji lub urządzenia;
• informacja o leasingu albo najmie;
• uprawnienie nadane przez właściciela produktu;
• uwierzytelnienie organizacyjne i role użytkowników;
• okresowy przegląd prawa do dostępu.

Szczególnej uwagi wymagają produkty wieloużytkownikowe. Sam właściciel floty nie powinien automatycznie otrzymywać wszystkich danych osobowych kierowców tylko dlatego, że jest użytkownikiem pojazdów w rozumieniu Data Act. Z kolei pracownik korzystający z urządzenia nie musi mieć prawa do danych handlowych całej organizacji.

System powinien rozdzielać kategorie danych, produkty, okresy oraz role. Przy zmianie właściciela albo zakończeniu leasingu dostęp należy odebrać, a nowemu użytkownikowi zapewnić bezpieczną aktywację bez ujawniania historii poprzednika ponad dopuszczalny zakres.

Informacje, które trzeba przekazać przed zawarciem umowy

Data Act wymaga przejrzystości jeszcze przed zakupem, najmem albo leasingiem produktu. Sprzedawca, wynajmujący lub leasingodawca powinien przekazać jasne informacje dotyczące danych, które produkt może generować.

Obszar	Informacja dla przyszłego użytkownika
Zakres danych	Typ, format i szacowana ilość danych produktu
Częstotliwość	Czy dane powstają stale i w czasie rzeczywistym
Przechowywanie	Czy dane pozostają na urządzeniu lub serwerze i przez jaki okres
Dostęp	Jak uzyskać, pobrać lub w odpowiednim przypadku usunąć dane
Warunki techniczne	Interfejs, warunki używania i jakość usługi dostępu

Dostawca usługi powiązanej powinien dodatkowo poinformować między innymi o:

• charakterze, szacowanej ilości i częstotliwości zbierania danych produktu;
• charakterze i ilości danych usługi powiązanej;
• sposobie oraz okresie przechowywania;
• tożsamości przyszłego posiadacza danych i innych podmiotów przetwarzających;
• celach własnego wykorzystywania danych;
• zamiarze dopuszczenia innych podmiotów do danych;
• sposobie żądania przekazania danych podmiotowi trzeciemu i zakończenia udostępniania;
• prawie złożenia skargi do właściwego organu;
• tajemnicach przedsiębiorstwa zawartych w danych;
• okresie trwania i sposobie zakończenia umowy.

Informacji nie należy ukrywać w obszernym regulaminie. Karta produktu, oferta, proces zakupowy i umowa powinny przekazywać spójny komunikat. Sprzedawca musi otrzymać od producenta aktualne dane techniczne, a dostawca usługi powinien aktualizować opis po zmianie architektury lub zakresu telemetrii.

Czy użytkownik może przekazać dane niezależnemu serwisowi?

Tak. Użytkownik może zażądać, aby posiadacz danych udostępnił dane łatwo dostępne wybranemu podmiotowi trzeciemu. Może to być niezależny serwis, dostawca usługi predykcyjnego utrzymania, integrator, dostawca analityki energetycznej albo inny partner wskazany przez użytkownika.

Dane powinny zostać przekazane:

• bez zbędnej zwłoki;
• w tej samej jakości, którą dysponuje posiadacz;
• łatwo i bezpiecznie;
• w kompletnym, ustrukturyzowanym i maszynowo czytelnym formacie;
• w razie potrzeby oraz możliwości technicznych w sposób ciągły i w czasie rzeczywistym;
• bezpłatnie dla użytkownika.

Podmiot trzeci może przetwarzać dane tylko w celu i na warunkach uzgodnionych z użytkownikiem. Nie może wykorzystywać ich do stworzenia produktu skomunikowanego konkurującego z produktem źródłowym. Może jednak na ich podstawie oferować konkurencyjną usługę, na przykład naprawę, diagnostykę albo optymalizację.

Odbiorca nie powinien profilować użytkownika, jeżeli nie jest to potrzebne do wykonania zamówionej usługi. Nie może również przekazywać danych dalej bez odpowiedniego ustalenia z użytkownikiem i zachowania wymaganych zabezpieczeń. Po zakończeniu celu dane powinny zostać usunięte, chyba że w odniesieniu do danych nieosobowych użytkownik uzgodnił inaczej.

Przedsiębiorstwo wyznaczone jako strażnik dostępu na podstawie Digital Markets Act nie może być uprawnionym podmiotem trzecim w tym mechanizmie.

Czy dostęp do danych zawsze jest bezpłatny?

Dostęp użytkownika do danych z art. 3 i 4 ma być bezpłatny. Posiadacz nie powinien uzależniać eksportu podstawowego zakresu danych od wykupienia dodatkowego pakietu premium.

Przekazanie danych podmiotowi trzeciemu również ma być bezpłatne dla użytkownika. Nie oznacza to jednak, że posiadacz danych zawsze wykonuje usługę nieodpłatnie wobec biznesowego odbiorcy. W relacji B2B posiadacz i odbiorca mogą uzgodnić rozsądną, niedyskryminacyjną rekompensatę. Może ona uwzględniać koszty formatowania, elektronicznego przekazania i przechowywania, a także określone inwestycje w pozyskanie danych.

Jeżeli odbiorcą jest MŚP albo organizacja badawcza nienastawiona na zysk, która nie jest powiązana z większym przedsiębiorstwem, rekompensata nie może przekroczyć kosztów bezpośrednio związanych z udostępnieniem wskazanych w art. 9 ust. 2 lit. a Data Act.

Model rozliczeń powinien być przejrzysty. Posiadacz danych musi przedstawić podstawę kalkulacji w zakresie umożliwiającym ocenę jej zgodności z Data Act. Opłata nie może służyć do faktycznego zablokowania konkurencyjnej usługi.

Data Act a RODO

Produkty IoT często generują jednocześnie dane nieosobowe i dane osobowe. Lokalizacja pojazdu, identyfikator konta, głos, obraz, harmonogram obecności, sposób korzystania z urządzenia albo dane zdrowotne mogą odnosić się do zidentyfikowanej lub możliwej do zidentyfikowania osoby.

Data Act nie zastępuje RODO. Nie tworzy też podstawy prawnej do zbierania lub generowania danych osobowych przez posiadacza danych. Projektując produkt, firma nadal musi określić cele, podstawy prawne, zakres danych, okresy przechowywania, odbiorców i zabezpieczenia.

Sytuacja	Znaczenie prawne
Użytkownik jest osobą, której dotyczą wszystkie żądane dane	Prawa z Data Act uzupełniają prawa dostępu i przenoszenia z RODO
Użytkownik jest firmą, a dane dotyczą jej pracowników lub klientów	Udostępnienie wymaga ważnej podstawy z art. 6 RODO, a przy danych szczególnych także przesłanki z art. 9 RODO
Zestaw łączy dane osobowe i nieosobowe	Trzeba zastosować RODO do części osobowej i nie blokować bez podstawy części nieosobowej
Dane mają trafić do podmiotu trzeciego	Należy ustalić role stron, podstawę udostępnienia, zakres, cel i zabezpieczenia
Użytkownik żąda danych innej osoby	Samo bycie użytkownikiem produktu nie wystarcza do pominięcia praw osoby, której dane dotyczą

W praktyce potrzebny jest mechanizm filtrowania danych. Firma może zastosować separację tenantów, role, pseudonimizację, ograniczenie przedziału czasu, wyodrębnienie danych określonego użytkownika albo agregację. Anonimizacja musi być rzeczywista. Usunięcie imienia nie wystarcza, jeżeli po numerze pojazdu, dokładnej lokalizacji i godzinach pracy nadal można ustalić konkretną osobę.

Przy rozbudowanych produktach warto połączyć analizę Data Act z oceną przepływów danych osobowych i bezpieczeństwa. Punktem wyjścia może być audyt RODO, obejmujący mapę danych, role administratorów i procesorów, podstawy prawne, retencję oraz mechanizmy realizacji praw.

Jak pogodzić dostęp z cyberbezpieczeństwem?

Data Act nie wymaga tworzenia niezabezpieczonego kanału. Interfejs powinien zapewniać dostęp uprawnionemu użytkownikowi i jednocześnie chronić produkt, usługę, innych użytkowników oraz infrastrukturę producenta.

Minimalny zestaw środków może obejmować:

• uwierzytelnianie wieloskładnikowe dla kont uprzywilejowanych;
• tokeny API o ograniczonym zakresie i czasie ważności;
• szyfrowanie transmisji oraz danych przechowywanych;
• rozdzielenie użytkowników i organizacji;
• limity zapytań chroniące dostępność systemu;
• rejestrowanie błędów, prób nadużyć i zmian uprawnień;
• bezpieczne wersjonowanie API;
• możliwość unieważnienia klucza albo zakończenia strumienia;
• testy penetracyjne i przeglądy konfiguracji;
• mechanizm aktualizacji zabezpieczeń produktu.

Ograniczenia nie mogą jednak pozbawiać prawa dostępu. Limit API powinien chronić usługę, a nie uniemożliwiać pobranie rzeczywistego wolumenu danych. Logi nie mogą być przechowywane szerzej i dłużej niż jest to potrzebne do wykonania żądania, utrzymania infrastruktury i bezpieczeństwa.

Strony mogą ograniczyć albo zakazać dostępu, używania lub dalszego udostępniania, jeżeli przetwarzanie mogłoby podważyć wymagania bezpieczeństwa wynikające z prawa UE lub prawa krajowego i prowadzić do poważnego niekorzystnego wpływu na zdrowie, bezpieczeństwo lub ochronę osób fizycznych. Nie jest to ogólna klauzula „ze względów bezpieczeństwa”. Odmowa wymaga konkretnej oceny i zawiadomienia właściwego organu.

Tajemnica przedsiębiorstwa nie oznacza automatycznej odmowy

Dane produktu mogą ujawniać parametry procesu, zachowanie urządzenia albo informacje techniczne mające wartość gospodarczą. Data Act zachowuje ochronę tajemnic przedsiębiorstwa, ale wymaga stopniowego podejścia.

Posiadacz danych powinien:

1. zidentyfikować konkretne dane stanowiące tajemnicę;
2. oznaczyć je, także w metadanych;
3. wyjaśnić, kto jest uprawnionym posiadaczem tajemnicy;
4. uzgodnić z użytkownikiem lub podmiotem trzecim proporcjonalne środki ochrony;
5. zastosować ograniczenia dostępu, poufność umowną i zabezpieczenia techniczne;
6. udostępnić dane po wdrożeniu uzgodnionych środków.

Środkami mogą być umowa o poufności, modelowe postanowienia umowne, ścisłe role dostępu, odseparowane środowisko, ograniczenie eksportu, znakowanie, monitoring bezpieczeństwa lub określone standardy techniczne.

Jeżeli nie uda się uzgodnić środków albo odbiorca ich nie wdroży, posiadacz może wstrzymać udostępnianie danych oznaczonych jako tajemnica. Decyzja powinna zostać uzasadniona na piśmie, a właściwy organ zawiadomiony.

Całkowita odmowa jest rozwiązaniem wyjątkowym. Posiadacz tajemnicy musi wykazać na podstawie obiektywnych elementów, że mimo zabezpieczeń ujawnienie konkretnych danych z dużym prawdopodobieństwem spowoduje poważną szkodę gospodarczą. Ogólne stwierdzenie, że cała telemetria ma charakter poufny, nie spełnia tego standardu.

Czy posiadacz może wykorzystywać dane produktu do własnych celów?

W odniesieniu do łatwo dostępnych danych nieosobowych posiadacz danych może wykorzystywać je na podstawie umowy z użytkownikiem. Umowa powinna jasno określać cele, na przykład diagnostykę, ulepszanie produktu, utrzymanie bezpieczeństwa albo tworzenie zagregowanych statystyk.

Posiadacz nie może używać takich danych do wyprowadzania informacji o sytuacji gospodarczej, aktywach, metodach produkcji albo sposobie korzystania przez użytkownika w sposób, który mógłby osłabić jego pozycję handlową na rynku.

Nie powinien także przekazywać nieosobowych danych produktu innym podmiotom w celach niezwiązanych z wykonaniem umowy z użytkownikiem. Jeżeli korzysta z dostawców wspierających wykonanie umowy, powinien odpowiednio ograniczyć dalsze udostępnianie.

Regulamin typu „możemy wykorzystywać wszystkie dane do dowolnych celów biznesowych i przekazywać je partnerom” będzie trudny do pogodzenia z tymi wymaganiami. Cele i kategorie odbiorców powinny odpowiadać rzeczywistemu modelowi usługi.

Umowy potrzebne w ekosystemie IoT

Zgodność nie kończy się na API. Umowy muszą odpowiadać architekturze danych i rolom stron.

Firma powinna przejrzeć co najmniej:

• warunki sprzedaży, najmu i leasingu produktu;
• umowę dotyczącą usługi powiązanej;
• regulamin aplikacji lub platformy;
• zasady własnego wykorzystywania danych nieosobowych;
• umowę z użytkownikiem biznesowym;
• warunki udostępnienia podmiotowi trzeciemu;
• umowy z integratorami, dostawcami chmury i podwykonawcami;
• umowy powierzenia oraz uzgodnienia administratorów na gruncie RODO;
• klauzule dotyczące poufności i tajemnic przedsiębiorstwa;
• zasady zakończenia usługi, zmiany użytkownika i usunięcia dostępów.

Postanowienia nie mogą wyłączać ani ograniczać praw użytkownika wynikających z rozdziału II Data Act. W relacji B2B trzeba również uwzględnić zakaz jednostronnie narzuconych nieuczciwych warunków dotyczących dostępu do danych, korzystania z nich, odpowiedzialności i środków ochrony prawnej.

Komisja Europejska opublikowała niewiążące modelowe postanowienia umowne dotyczące dostępu do danych i ich wykorzystywania. Mogą one stanowić punkt wyjścia, ale wymagają dopasowania do produktu, modelu danych, RODO i zasad bezpieczeństwa.

Wyłączenie dla mikroprzedsiębiorstw i małych przedsiębiorstw

Obowiązki rozdziału II nie mają zastosowania do danych generowanych przez produkty skomunikowane wytwarzane lub projektowane albo usługi powiązane świadczone przez mikroprzedsiębiorstwo lub małe przedsiębiorstwo.

Wyłączenie nie działa jednak, gdy:

• przedsiębiorstwo ma partnera lub podmiot powiązany, który nie jest mikroprzedsiębiorstwem ani małym przedsiębiorstwem;
• mała firma została podwykonawcą większego przedsiębiorstwa w zakresie produkcji albo projektowania produktu lub świadczenia usługi powiązanej.

Data Act przewiduje też czasowe rozwiązanie dla przedsiębiorstwa, które uzyskało status średniego przedsiębiorstwa krócej niż rok wcześniej, oraz dla produktów wprowadzonych przez nie na rynek w okresie jednego roku.

Statusu nie należy oceniać wyłącznie na podstawie liczby pracowników jednej spółki. Trzeba uwzględnić relacje partnerskie i powiązania kapitałowe zgodnie z unijną definicją MŚP. Firma powinna udokumentować analizę, ponieważ błędne zastosowanie wyłączenia może opóźnić projekt techniczny o wiele miesięcy.

Co z produktami wprowadzonymi na rynek przed 12 września 2026 roku?

Artykuł 3 ust. 1 nie nakłada na takie produkty nowego, retrospektywnego obowiązku zaprojektowania bezpośredniego dostępu. Nie oznacza to jednak, że wszystkie dane starszych produktów pozostają poza Data Act.

Od 12 września 2025 roku posiadacz powinien udostępniać użytkownikowi dane produktu i usługi powiązanej, które są dla niego łatwo dostępne, jeżeli użytkownik nie może uzyskać ich bezpośrednio. Podobnie użytkownik może żądać przekazania tych danych podmiotowi trzeciemu.

W praktyce dla portfela starszych produktów trzeba ustalić:

• które urządzenia nadal przesyłają dane do chmury;
• jakie dane posiadacz legalnie otrzymuje;
• które dane może uzyskać prostą operacją bez nieproporcjonalnego wysiłku;
• czy istnieje eksport, portal albo API;
• jak zrealizować żądanie bez przebudowy urządzenia;
• które ograniczenia wynikają z architektury, bezpieczeństwa albo braku danych;
• jak rozdzielić dane osobowe różnych użytkowników.

Dobrym rozwiązaniem może być wspólny portal dla urządzeń starszych i nowych, przy czym nowe produkty powinny dodatkowo spełniać standard projektowania z art. 3 ust. 1.

Procedura przygotowania produktu IoT w 10 krokach

1. Ustal, czy rozwiązanie jest produktem skomunikowanym

Opisz podstawową funkcję produktu, źródła danych, sposób łączności i relację z usługą cyfrową. Nie opieraj kwalifikacji wyłącznie na nazwie handlowej „smart”.

2. Zidentyfikuj usługi powiązane

Sprawdź aplikacje, platformy chmurowe, oprogramowanie zdalnego sterowania i aktualizacje funkcjonalne. Oddziel je od usług niezwiązanych bezpośrednio z działaniem produktu.

3. Zbuduj katalog danych

Dla każdej kategorii określ źródło, format, częstotliwość, wolumen, miejsce przechowywania, retencję, status osobowy oraz etap przetworzenia.

4. Wyznacz role

Ustal użytkownika, posiadacza danych, dostawcę usługi, sprzedawcę, leasingodawcę, procesorów i potencjalnych odbiorców. Osobno określ role na gruncie RODO.

5. Wybierz model dostępu

Zdecyduj, które dane będą dostępne bezpośrednio, które przez portal, a które przez API. Uzasadnij przypadki, w których bezpośredni albo ciągły dostęp nie jest właściwy lub technicznie wykonalny.

6. Zaprojektuj bezpieczeństwo i weryfikację

Wprowadź role, uwierzytelnianie, tokeny, separację organizacji, szyfrowanie, logowanie oraz procedurę odebrania dostępu.

7. Przygotuj przekazanie podmiotowi trzeciemu

Użytkownik powinien móc wskazać odbiorcę, zakres, cel i okres udostępniania. Potrzebny jest mechanizm zakończenia transmisji oraz obsługi tajemnic przedsiębiorstwa.

8. Połącz Data Act z RODO

Ustal podstawy prawne, minimalizację, retencję, prawa osób, filtry danych i transfery poza EOG. Sprawdź, czy potrzebna jest DPIA.

9. Zaktualizuj informacje i umowy

Przygotuj informacje przedkontraktowe, regulamin usługi, warunki używania danych nieosobowych, zasady API i postanowienia dla podmiotów trzecich.

10. Przetestuj pełny scenariusz

Przeprowadź test od aktywacji urządzenia, przez pobranie danych, do przekazania niezależnemu serwisowi. Sprawdź czas realizacji, kompletność, metadane, bezpieczeństwo i obsługę odmowy.

Praktyczny scenariusz: inteligentna instalacja HVAC

Producent wprowadza po 12 września 2026 roku sterownik instalacji HVAC dla hal produkcyjnych. Produkt zbiera temperaturę, wilgotność, ciśnienie, czas pracy, pobór energii, komunikaty błędów i ustawienia użytkownika. Aplikacja chmurowa pozwala zmieniać harmonogram i tryby działania.

Użytkownikiem jest fabryka leasingująca urządzenie. Producent odbiera telemetrię do swojej chmury i pozostaje posiadaczem łatwo dostępnych danych. Dostawca chmury działa technicznie na jego polecenie.

Prawidłowy model może wyglądać następująco:

1. Fabryka otrzymuje przed zawarciem umowy opis kategorii, formatów, wolumenu, częstotliwości i retencji danych.
2. Portal pozwala pobrać dane historyczne w CSV i JSON wraz ze słownikiem pól.
3. API zapewnia bieżące dane o temperaturze, energii i stanie urządzenia.
4. Konto administratora fabryki może nadawać dostęp operatorom tylko do określonych hal.
5. Fabryka wskazuje niezależną firmę optymalizującą zużycie energii jako podmiot trzeci.
6. System wydaje ograniczony token API, obejmujący wybrane urządzenia i okres.
7. Dane identyfikujące pracowników nie są przekazywane, ponieważ nie są potrzebne do optymalizacji.
8. Własnościowy wynik producenta przewidujący awarię na podstawie złożonego modelu nie jest automatycznie częścią obowiązkowego eksportu, ale surowe i wstępnie przetworzone dane wejściowe pozostają dostępne.
9. Kody diagnostyczne zawierające tajemnicę są oznaczone, a strony uzgadniają poufność i kontrolę dostępu.
10. Po zakończeniu współpracy fabryka odwołuje token podmiotu trzeciego, a odbiorca usuwa dane zgodnie z uzgodnionym celem i RODO.

Taki model umożliwia korzystanie z niezależnej usługi bez ujawniania całej technologii producenta i bez otwierania niezabezpieczonego interfejsu.

Najczęstsze błędy przy wdrażaniu Data Act

Traktowanie 12 września 2026 roku jako początku całego Data Act

Firma odkłada wszystkie działania, mimo że prawa z art. 4 i 5 są stosowane zasadniczo od 12 września 2025 roku.

Eksport wyłącznie do PDF

Użytkownik otrzymuje wizualny raport, ale nie może automatycznie przetworzyć danych ani połączyć ich z własnym systemem.

Brak metadanych

Plik zawiera liczby bez jednostek, znaczników czasu, identyfikatorów czujników i opisu kodów.

Portal bez możliwości przekazania danych podmiotowi trzeciemu

Użytkownik może pobrać pojedynczy plik, ale nie może uruchomić bezpiecznego, ciągłego dostępu dla niezależnego serwisu.

Nadmierna weryfikacja

Posiadacz żąda pełnego odpisu umowy, dokumentów tożsamości kilku osób i danych niezwiązanych z prawem do produktu, chociaż wystarczyłoby konto oraz numer seryjny.

Jedno konto dla wszystkich użytkowników

System nie rozdziela właściciela, leasingobiorcy, operatora i serwisu, przez co udostępnia zbyt wiele danych albo blokuje uprawnionych.

Oznaczenie całej bazy jako tajemnicy przedsiębiorstwa

Firma nie wskazuje konkretnych informacji, nie proponuje zabezpieczeń i automatycznie odmawia dostępu.

Założenie, że Data Act jest podstawą przetwarzania danych osobowych

Producent nie ustala podstaw z RODO i nie sprawdza, czy użytkownik żąda danych innych osób.

Niespójne informacje sprzedażowe i techniczne

Umowa obiecuje dane w czasie rzeczywistym, ale API aktualizuje je raz na dobę albo nie obejmuje części kategorii.

Brak planu dla starszych produktów

Firma projektuje tylko nową generację urządzenia i ignoruje żądania dotyczące danych już otrzymywanych z istniejących produktów.

Checklista gotowości na 12 września 2026 roku

Obszar	Pytanie kontrolne	Dowód wykonania
Zakres	Czy produkt spełnia definicję produktu skomunikowanego?	Karta kwalifikacji prawnej
Usługi	Czy zidentyfikowano wszystkie usługi powiązane?	Mapa usług i funkcji
Dane	Czy istnieje katalog danych produktu i usługi?	Rejestr pól, źródeł i formatów
Metadane	Czy użytkownik otrzyma jednostki, czas i kontekst?	Słownik danych i wersjonowanie
Role	Czy wskazano użytkownika, posiadacza i odbiorców?	Mapa ról i odpowiedzialności
Dostęp	Czy wybrano dostęp lokalny, portal, API lub strumień?	Architektura rozwiązania
Format	Czy dane są ustrukturyzowane i maszynowo czytelne?	Przykładowy eksport i specyfikacja
Bezpieczeństwo	Czy uwierzytelnienie i uprawnienia są proporcjonalne?	Model kontroli dostępu i testy
Podmiot trzeci	Czy użytkownik może rozpocząć i zakończyć udostępnianie?	Scenariusz API i procedura
Tajemnice	Czy tajemnice zostały wskazane konkretnie?	Klasyfikacja oraz wzór zabezpieczeń
RODO	Czy określono dane osobowe, podstawy i filtry?	Analiza RODO lub DPIA
Retencja	Czy dane są przechowywane przez uzasadniony okres?	Polityka retencji
Informacje	Czy sprzedawca i usługodawca mają komplet treści przedkontraktowych?	Karta produktu i regulamin
Umowy	Czy warunki nie ograniczają praw użytkownika?	Zatwierdzone wzory umów
Testy	Czy wykonano żądanie użytkownika i transmisję do serwisu?	Protokół testu end to end
Starsze produkty	Czy ustalono dane łatwo dostępne z istniejącej floty?	Plan obsługi produktów legacy
Odpowiedzialność	Czy wyznaczono właściciela procesu i zastępstwo?	Matryca RACI

Dokumentacja powinna odpowiadać działającemu rozwiązaniu. Jeśli firma potrzebuje połączyć procedurę dostępu, wymagania RODO, umowy i podział odpowiedzialności, pomocne może być wdrożenie RODO rozszerzone o procesy dotyczące produktu i udostępniania danych.

Krajowy nadzór nad Data Act w Polsce

Data Act jest rozporządzeniem unijnym i stosuje się bezpośrednio. Państwa członkowskie muszą jednak wyznaczyć właściwe organy, określić procedury oraz ustanowić sankcje.

Według wersji projektu ustawy o sprawiedliwym dostępie do danych i ich wykorzystywaniu opublikowanej na stronie Kancelarii Prezesa Rady Ministrów, zadania właściwego organu, koordynatora danych oraz organu certyfikującego organy rozstrzygania sporów ma wykonywać Prezes UKE. Prezes UODO zachowuje kompetencje w zakresie ochrony danych osobowych wynikające z Data Act i RODO.

Ponieważ na dzień przygotowania artykułu krajowe rozwiązanie nadal ma status projektu, przed publikacją lub aktualizacją materiału należy ponownie sprawdzić stan procesu legislacyjnego. Nie zmienia to bezpośrednio stosowanych obowiązków wynikających z samego rozporządzenia.

Podsumowanie

Data Act wymaga, aby dane generowane przez produkty IoT nie pozostawały wyłącznie pod kontrolą producenta albo operatora platformy. Użytkownik ma otrzymać realny, bezpieczny i bezpłatny dostęp do danych produktu oraz usługi powiązanej, a także możliwość przekazania ich wybranemu podmiotowi trzeciemu.

Po 12 września 2026 roku obowiązek z art. 3 ust. 1 obejmie produkty skomunikowane i związane z nimi usługi wprowadzane na rynek po tej dacie. Dostęp powinien zostać zaprojektowany od początku, a nie dodany jako ręczna procedura po premierze produktu. W praktyce oznacza to potrzebę przygotowania katalogu danych, metadanych, interfejsu, ról użytkowników, bezpieczeństwa, informacji przedkontraktowych i umów.

Najtrudniejsze przypadki będą dotyczyć danych mieszanych, wielu użytkowników, tajemnic przedsiębiorstwa i integracji z niezależnymi usługodawcami. Firma powinna rozstrzygnąć te kwestie wspólnie z działem produktowym, IT, bezpieczeństwem, prawnikiem i IOD. Prawidłowo zaprojektowany proces może jednocześnie zapewnić użytkownikowi kontrolę nad danymi, chronić technologię producenta i stworzyć podstawę dla nowych usług serwisowych oraz analitycznych.

Dzielimy się wiedzą

Data Act łączy prawo, architekturę produktu, umowy, cyberbezpieczeństwo i ochronę danych osobowych. Dlatego zgodności nie da się osiągnąć samą zmianą regulaminu. W BPPZ przekładamy wymagania dotyczące danych na praktyczne procesy, dokumentację i rozwiązania możliwe do wdrożenia przez zespoły produktowe oraz IT.

Projektujesz produkt IoT lub usługę powiązaną?

Możemy pomóc ustalić zakres Data Act, zbudować katalog danych, ocenić model dostępu, przygotować umowy i połączyć nowe obowiązki z RODO oraz cyberbezpieczeństwem.

FAQ

Źródła:

1. EUR-Lex – Rozporządzenie (UE) 2023/2854 w sprawie zharmonizowanych przepisów dotyczących sprawiedliwego dostępu do danych i ich wykorzystywania.
2. EUR-Lex – Rozporządzenie (UE) 2016/679, w szczególności art. 5, 6, 9, 12, 15, 20, 25 i 32.
3. Komisja Europejska – Data Act: informacje o regulacji, przykładach zastosowania i materiałach wdrożeniowych.
4. Komisja Europejska – Najczęściej zadawane pytania dotyczące Data Act, wersja 1.4 z 22 stycznia 2026 r..
5. Komisja Europejska – Modelowe postanowienia umowne dotyczące dostępu do danych i ich wykorzystywania.
6. UODO – Akt w sprawie danych już obowiązuje i nie zastępuje RODO.
7. Kancelaria Prezesa Rady Ministrów – Projekt ustawy o sprawiedliwym dostępie do danych i ich wykorzystywaniu.