Artykuł 36 rozporządzenia Data Act (DA) wprowadza nowe, przełomowe zasady dotyczące inteligentnych umów (smart contracts), które są wykorzystywane do automatycznego wykonywania umów o dzielenie się danymi. Regulacja ta łączy prawo i technologię, nakładając konkretne obowiązki na dostawców aplikacji oraz podmioty wdrażające inteligentne kontrakty w działalności gospodarczej. Celem jest zapewnienie bezpieczeństwa, przejrzystości i kontroli nad procesami automatyzacji danych w ramach unijnego ekosystemu danych.
Wprowadzenie i ratio legis art. 36 Data Act
Artykuł 36 DA ustanawia techniczne i prawne wymagania konstrukcyjne dla smart contracts, które służą realizacji umów o udostępnianie danych zgodnie z rozdziałem II rozporządzenia.
Jego głównym celem jest zagwarantowanie, że automatyczne wykonywanie umów o dzieleniu się danymi będzie bezpieczne, kontrolowalne i zgodne z wolą stron.
Zgodnie z motywami 104 i następnymi preambuły Data Act, unijny ustawodawca chciał zapobiec sytuacjom, w których działanie inteligentnych umów prowadzi do nieprzewidywalnych lub nieodwracalnych skutków prawnych, nad którymi użytkownicy lub posiadacze danych nie mają kontroli.
Oznacza to, że art. 36 DA pełni funkcję prewencyjną i ochronną – wymaga, aby automatyzacja umów była projektowana w sposób bezpieczny, możliwy do wstrzymania i audytowalny. Innymi słowy, ustawodawca unijny nakazuje, by smart contract nie był „czarną skrzynką”, której działania nie można zatrzymać ani zrozumieć.
Zakres zastosowania art. 36 Data Act
Artykuł 36 ma zastosowanie wyłącznie w określonych przypadkach, gdy spełnione są trzy łączne warunki:
- Umowa o dzielenie się danymi (data sharing agreement) – czyli porozumienie między:
- użytkownikiem a osobą trzecią, lub
- posiadaczem danych a osobą trzecią (np. odbiorcą danych),
zawarte na podstawie art. 5 Data Act, który reguluje zasady dalszego udostępniania danych pochodzących z produktów połączonych lub usług cyfrowych.
- Wykorzystanie inteligentnej umowy (smart contract) – oznacza, że wykonanie tej umowy odbywa się przy użyciu zakodowanego, automatycznego mechanizmu, który:
- udostępnia dane,
- kontroluje dostęp,
- zarządza przepływem danych,
bez konieczności każdorazowej interwencji człowieka.
- Profesjonalne wdrożenie – smart contract jest wdrażany przez dostawcę aplikacji lub inną osobę działającą zawodowo, np. programistę, integratora systemowego czy software house.
⚠️ Uwaga: Przepis nie ma zastosowania do inteligentnych umów wykorzystywanych do innych celów, takich jak płatności, uwierzytelnianie czy identyfikacja – chyba że służą one bezpośrednio wykonaniu umowy o udostępnianie danych.
Podobnie, jeśli automatyzacja jest tylko dodatkiem do tradycyjnej umowy, a nie jej głównym sposobem realizacji, przepisy art. 36 DA nie znajdą zastosowania.
Zasady projektowania inteligentnych umów
Kluczowe wymagania projektowe
Zgodnie z art. 36 ust. 1 DA, inteligentna umowa używana do realizacji umowy o udostępnianie danych musi spełniać pięć zasadniczych wymagań konstrukcyjnych. Odpowiedzialność za ich wdrożenie ponosi:
- dostawca aplikacji, w której wykorzystywany jest smart contract, lub
- osoba wdrażająca kontrakt w ramach działalności zawodowej (np. podwykonawca technologiczny, integrator systemu).
Poniżej omówiono każde z wymagań:
1. Odporność i kontrola dostępu
Smart contract musi być odporny na błędy i manipulacje. Obejmuje to:
- zabezpieczenie przed błędami funkcjonalnymi (np. zapętleniami kodu, nieprawidłowym wykonaniem warunków umowy),
- ochronę przed atakami zewnętrznymi (np. reentrancy, nieautoryzowanym dostępem),
- wdrożenie mechanizmów kontroli dostępu zarówno w warstwie aplikacyjnej, jak i kodu kontraktu.
Celem tego wymogu jest zapewnienie, że umowa nie zostanie zmodyfikowana lub uruchomiona bez autoryzacji odpowiednich stron.
2. Możliwość bezpiecznego zakończenia i przerwania działania
Kod inteligentnej umowy musi umożliwiać:
- zatrzymanie lub zawieszenie jej działania,
- przerwanie transakcji lub zresetowanie logiki, np. w przypadku cofnięcia zgody na udostępnienie danych, błędu lub incydentu bezpieczeństwa.
📌 Ten wymóg ma zapobiec tzw. nieodwracalnemu wykonaniu umowy, czyli sytuacji, gdy po uruchomieniu kodu nie można już zatrzymać jego skutków prawnych.
3. Archiwizacja i audytowalność
Po dezaktywacji smart contractu musi istnieć możliwość:
- zarchiwizowania kodu źródłowego i logiki działania,
- odtworzenia przebiegu wykonania umowy (audytowalność),
- zachowania śladów transakcyjnych – np. logów, historii zdarzeń.
To kluczowy warunek zapewnienia rozliczalności i dowodowości w razie sporu oraz umożliwienia organom kontrolnym weryfikacji zgodności z przepisami Data Act.
4. Wielowarstwowa kontrola dostępu
Smart contract musi zapewniać kontrolę dostępu na kilku poziomach:
- zarządzania aplikacją,
- środowiska wykonawczego (np. blockchain, serwer),
- logiki kontraktu (np. kto może aktywować lub modyfikować kod).
Oznacza to, że pojedyncze zabezpieczenie (np. hasło czy token) nie jest wystarczające. Wymagane są kompleksowe, wielopoziomowe zabezpieczenia.
5. Spójność z umową o udostępnianie danych
Kod inteligentnej umowy musi odzwierciedlać postanowienia umowy głównej i działać ściśle w jej ramach.
Nie może:
- zmieniać treści umowy,
- ograniczać uprawnień stron,
- ani wykonywać czynności niezależnie od zapisów kontraktu.
Logika smart contractu powinna być transparentna i zgodna z ustaleniami stron, a jej funkcje – możliwe do wyjaśnienia i kontroli.
📄 Przykład praktyczny
Firma DataLink Sp. z o.o. udostępnia dane telemetryczne z floty pojazdów firmie AutoSecure SA w celu analizy ryzyka ubezpieczeniowego. Obie strony zawierają umowę o dzielenie się danymi zgodnie z Data Act.
Dostawca aplikacji wdraża smart contract, który automatycznie udostępnia dane w określonych interwałach i zapisuje historię przesyłów.
Zgodnie z art. 36 DA, DataLink musi zapewnić, aby ten kontrakt:
- mógł zostać zatrzymany lub zawieszony, gdy użytkownik cofnie zgodę na udostępnianie danych,
- miał funkcję audytu, umożliwiającą odtworzenie historii przekazywania danych,
- i odzwierciedlał warunki umowy głównej (np. zakres danych, czas ich przechowywania).
W przeciwnym razie smart contract nie będzie zgodny z wymogami Data Act, a dostawca może ponieść odpowiedzialność regulacyjną.
Ocena zgodności smart contracts z art. 36 Data Act
Zgodnie z art. 36 ust. 2 DA, każdy podmiot wdrażający inteligentne umowy w kontekście wykonywania umów o udostępnianie danych ma obowiązek:
- przeprowadzić ocenę zgodności inteligentnej umowy z wymogami rozporządzenia, oraz
- wystawić deklarację zgodności UE, jeśli ocena wypadnie pozytywnie.
To oznacza, że dostawca lub wdrażający nie może po prostu uznać, że jego smart contract „jest zgodny” – musi przeprowadzić udokumentowaną samoocenę zgodności, podobnie jak w innych obszarach prawa technicznego UE (np. w przypadku sprzętu elektronicznego czy oprogramowania medycznego).
Charakter oceny zgodności
🔹 Samoocena – proces nie wymaga udziału jednostki notyfikowanej (czyli zewnętrznego organu certyfikującego). To twórca lub wdrażający smart contract sam odpowiada za wykonanie analizy zgodności z pięcioma zasadniczymi wymaganiami z ust. 1.
🔹 Zakres oceny – obejmuje wszystkie aspekty:
- odporność kodu i zabezpieczenia dostępu,
- możliwość zatrzymania działania kontraktu,
- audytowalność i archiwizację,
- kontrolę dostępu w różnych warstwach,
- zgodność logiki kodu z treścią umowy o udostępnianie danych.
🔹 Podstawa oceny – może opierać się na:
- normach zharmonizowanych, jeżeli zostaną opublikowane w Dzienniku Urzędowym UE,
- lub – do czasu ich przyjęcia – na wewnętrznych procedurach i analizie ryzyka, udokumentowanej przez dostawcę.
Deklaracja zgodności ma więc charakter formalnego oświadczenia producenta (lub wdrażającego), że dane rozwiązanie spełnia wszystkie wymagania określone w rozporządzeniu.
W razie kontroli lub sporu sądowego to właśnie ta dokumentacja będzie podstawą oceny, czy podmiot wypełnił swoje obowiązki wynikające z Data Act.
Odpowiedzialność za zgodność smart contracts
W art. 36 ust. 3 DA wprowadzono jednoznaczny reżim odpowiedzialności.
Za zapewnienie zgodności inteligentnej umowy z zasadniczymi wymaganiami odpowiada:
- dostawca aplikacji, która wykorzystuje smart contract do udostępniania danych, lub
- osoba wdrażająca smart contract w ramach działalności zawodowej, jeśli nie ma formalnego dostawcy aplikacji.
Oznacza to, że nie można „rozłożyć” odpowiedzialności między kilka podmiotów (np. platformę, programistę i klienta).
Regulacja wymaga, aby co najmniej jeden konkretny podmiot ponosił pełną odpowiedzialność za zgodność danego rozwiązania.
📄 Przykład praktyczny
Software house CodeSphere Sp. z o.o. opracowuje dla platformy analitycznej DataView SA smart contract automatyzujący przekazywanie danych środowiskowych z czujników IoT do systemu klienta przemysłowego.
Jeśli DataView wdraża kontrakt w swojej aplikacji – to ona odpowiada za jego zgodność z Data Act (nawet jeśli kod opracował zewnętrzny programista).
Gdyby jednak CodeSphere wdrażała ten kontrakt samodzielnie w ramach usługi integracyjnej, to ona byłaby odpowiedzialna za zgodność z art. 36 DA.
W obu przypadkach nie ma możliwości przerzucenia odpowiedzialności na klienta, który korzysta jedynie z efektu działania kontraktu.
Znaczenie norm zharmonizowanych i specyfikacji technicznych
Zgodnie z art. 36 ust. 4 DA, inteligentna umowa uznawana jest za zgodną z wymogami, jeśli spełnia normy zharmonizowane, do których odniesienia opublikowano w Dzienniku Urzędowym Unii Europejskiej.
To tzw. domniemanie zgodności – znany z prawa unijnego mechanizm (stosowany np. w dyrektywach nowego podejścia), który:
- upraszcza proces oceny,
- ujednolica praktyki rynkowe,
- i ułatwia organom kontrolnym weryfikację spełnienia wymogów.
Wniosek Komisji do organizacji normalizacyjnych
Zgodnie z art. 36 ust. 5 DA, Komisja Europejska może zwrócić się do europejskich organizacji normalizacyjnych – takich jak CEN, CENELEC czy ETSI – o opracowanie odpowiednich norm technicznych dotyczących inteligentnych umów.
Będzie to pierwszy krok w kierunku ujednolicenia technicznych standardów smart contracts w UE.
Choć Komisja inicjuje proces, nie ma gwarancji, że organizacje normalizacyjne przyjmą takie normy – wówczas uruchamiany jest kolejny mechanizm.
Wspólne specyfikacje Komisji Europejskiej
Zgodnie z art. 36 ust. 6 DA, jeśli:
- Komisja złożyła wniosek o opracowanie normy zharmonizowanej, ale
- wniosek został odrzucony,
- norma nie powstała w terminie,
- lub nie jest zgodna z oczekiwaniami Komisji, oraz
- w Dzienniku Urzędowym UE nie opublikowano żadnej normy obejmującej wymagania z ust. 1,
– Komisja może przyjąć wspólne specyfikacje techniczne w formie aktu wykonawczego.
Tego rodzaju specyfikacje mają taki sam skutek jak normy zharmonizowane – zapewniają domniemanie zgodności, ale są tworzone bezpośrednio przez Komisję, a nie przez organizacje normalizacyjne.
Procedura przyjmowania specyfikacji
Zanim Komisja przyjmie taki akt wykonawczy:
- musi poinformować komitet ds. normalizacji, o którym mowa w art. 22 rozporządzenia (UE) nr 1025/2012,
- a następnie skonsultować projekt z Europejską Radą ds. Innowacji w zakresie Danych (EDIB) oraz z zainteresowanymi stronami (branżą technologiczną, organizacjami użytkowników itp.).
Dzięki temu zapewnia się transparentność procesu i możliwość uwzględnienia praktyki rynkowej.
Domniemanie zgodności przy wspólnych specyfikacjach
Jeżeli smart contract spełnia wspólne specyfikacje przyjęte przez Komisję, uznaje się go za zgodny z art. 36 DA, w zakresie objętym tymi specyfikacjami (art. 36 ust. 9 DA).
To drugi, obok norm zharmonizowanych, mechanizm domniemania zgodności.
Kolizja norm i specyfikacji
W przypadku, gdy po czasie organizacja normalizacyjna opracuje i opublikuje normę zharmonizowaną, która dotyczy tych samych wymagań, Komisja musi uchylić swój wcześniejszy akt wykonawczy (art. 36 ust. 10 DA).
Zapewnia to pierwszeństwo norm rynkowych nad regulacją administracyjną, zgodnie z zasadą prawa technicznego UE.
Sprzeciw państw członkowskich
Zgodnie z art. 36 ust. 11 DA, każde państwo członkowskie może zgłosić sprzeciw wobec przyjętej przez Komisję wspólnej specyfikacji, jeśli uzna, że nie w pełni spełnia ona zasadnicze wymagania rozporządzenia.
W takim przypadku Komisja dokonuje oceny sprzeciwu i może odpowiednio zmienić akt wykonawczy.
To ważny mechanizm kontroli jakości i równowagi między poziomem unijnym a krajowym.
📄 Przykład
Komisja Europejska zleca ETSI opracowanie normy dotyczącej mechanizmów bezpieczeństwa w smart contracts.
ETSI jednak nie publikuje normy w terminie, dlatego Komisja wydaje specyfikację techniczną określającą wymagania dotyczące m.in. audytowalności kodu i funkcji zatrzymania.
Po dwóch latach ETSI opracowuje jednak pełną normę zharmonizowaną – wówczas Komisja uchyla swoją specyfikację, a rynek przechodzi na stosowanie normy ETSI.
Znaczenie praktyczne dla dostawców i twórców aplikacji
Artykuł 36 Data Act wprowadza nową kategorię wymogów techniczno-regulacyjnych dotyczących inteligentnych umów. Nie chodzi tu o treść samej umowy, lecz o sposób jej wykonywania – zakodowany w formie logiki automatycznej.
Dla przedsiębiorców tworzących lub wdrażających takie rozwiązania (np. software house’ów, integratorów, dostawców API, platform danych) oznacza to obowiązek wdrożenia pełnego reżimu zgodności technicznej.
Każdy podmiot, który wdraża smart contract służący realizacji umowy o udostępnianie danych, musi:
- spełnić pięć zasadniczych wymagań projektowych (bezpieczeństwo, kontrola, audytowalność, spójność, możliwość zatrzymania);
- przeprowadzić ocenę zgodności z tymi wymaganiami;
- sporządzić i przechowywać deklarację zgodności UE;
- umożliwić audyt lub kontrolę przez właściwe organy, w tym krajowe organy nadzoru ds. danych (zob. art. 38 DA).
Compliance by design – zgodność projektowana od początku
W praktyce oznacza to konieczność wdrożenia zasady compliance by design, czyli projektowania inteligentnych umów w sposób zgodny z wymogami regulacyjnymi już od najwcześniejszego etapu ich tworzenia.
Obejmuje to m.in.:
- planowanie architektury kodu z możliwością zatrzymania działania (tzw. emergency stop),
- dokumentowanie logiki działania kontraktu,
- wdrożenie mechanizmów śledzenia transakcji (logów),
- uwzględnienie procedur audytu kodu,
- utrzymywanie spójności między treścią umowy a jej wykonaniem technicznym.
Praktyczne wyzwania dla przedsiębiorców
Wdrożenie wymogów art. 36 DA może być szczególnie trudne dla mniejszych firm technologicznych, które nie mają wyspecjalizowanych zespołów ds. bezpieczeństwa kodu lub audytu zgodności.
W praktyce pojawią się m.in. następujące wyzwania:
- Brak wytycznych Komisji Europejskiej co do metodyki samooceny;
- Brak norm zharmonizowanych w początkowej fazie stosowania Data Act, co utrudni jednoznaczną ocenę;
- Zróżnicowanie poziomu dojrzałości technicznej firm – część przedsiębiorstw wdroży zaawansowane procedury, inne ograniczą się do formalnej deklaracji.
Skutkiem tego może być fragmentacja rynku, w której różne podmioty będą w różny sposób interpretować wymogi zgodności.
Z punktu widzenia ryzyka prawnego, technologicznego i operacyjnego oznacza to większe ryzyko sporów oraz kontroli ze strony organów nadzorczych.
Znaczenie dla klientów i użytkowników danych
Artykuł 36 DA nie tylko nakłada obowiązki na dostawców – ma też funkcję ochronną dla użytkowników i odbiorców danych.
Dzięki tej regulacji użytkownik ma gwarancję, że:
- Smart contract nie może samodzielnie zmienić treści umowy o udostępnianie danych;
- Kod jest audytowalny i kontrolowalny;
- W każdej chwili możliwe jest przerwanie jego działania w przypadku błędu, wycofania zgody lub naruszenia bezpieczeństwa.
Co powinien zrobić klient?
Użytkownicy, którzy zawierają umowy o udostępnianie danych realizowane poprzez smart contracts, powinni:
- żądać od dostawcy przedstawienia dokumentacji zgodności z art. 36 DA, w tym:
- deklaracji zgodności UE,
- opisu logiki działania kontraktu,
- informacji o możliwości zatrzymania działania kontraktu;
- wprowadzić do umowy SLA (Service Level Agreement) klauzule:
- zobowiązujące dostawcę do udostępnienia dokumentacji samooceny,
- określające procedurę awaryjnego zatrzymania („emergency stop”),
- wskazujące osoby uprawnione do aktywowania mechanizmu zatrzymania.
📌 Mechanizm emergency stop
To funkcja techniczna wbudowana w smart contract, która umożliwia natychmiastowe wstrzymanie jego działania w razie:
- wykrycia błędu lub luki bezpieczeństwa,
- cofnięcia zgody użytkownika,
- sytuacji kryzysowej (np. awarii lub nieautoryzowanego dostępu).
Zazwyczaj realizowana jest jako funkcja pause() lub emergencyStop(), uruchamiana przez zaufany podmiot – np. administratora systemu lub organ nadzorczy w ramach tzw. multisig (wielopodpisowej autoryzacji).
Obowiązki organizacyjne w ramach compliance
Z punktu widzenia organizacji wdrażających rozwiązania automatyzujące dostęp do danych, art. 36 DA wymaga stworzenia nowych procedur compliance technologicznego.
Każda firma, która tworzy lub wdraża smart contracts w kontekście Data Act, powinna:
- 📄 Ustanowić procedurę oceny zgodności smart contracts z wymogami Data Act;
- 🗂️ Prowadzić rejestr wdrożonych inteligentnych umów, w którym dokumentuje:
- nazwę kontraktu i jego przeznaczenie,
- osobę odpowiedzialną za wdrożenie,
- wynik oceny zgodności i numer deklaracji UE;
- 🔍 Wprowadzić regularne przeglądy kodu i logiki działania (code review, audyty bezpieczeństwa);
- 🧩 Zapewnić szkolenia dla zespołów compliance z zakresu oceny technicznej zgodności kodu z wymogami prawa materialnego.
Znaczenie art. 36 DA w praktyce rynkowej
Artykuł 36 DA to jedno z najbardziej innowacyjnych rozwiązań rozporządzenia Data Act – po raz pierwszy w unijnym prawie uregulowano obowiązki dotyczące kodu komputerowego jako elementu wykonania umowy cywilnoprawnej.
Z perspektywy biznesowej oznacza to:
- konieczność łączenia kompetencji prawnych i technologicznych,
- większą odpowiedzialność dostawców IT za bezpieczeństwo i zgodność kodu,
- potrzebę współpracy między działami prawno-compliance, IT i bezpieczeństwa informacji.
Dla rynku to również sygnał, że automatyzacja kontraktów podlega takim samym zasadom zgodności jak inne technologie wysokiego ryzyka, a transparentność i możliwość kontroli kodu stają się wymogiem prawnym, nie tylko dobrą praktyką.
Podstawa prawna
- art. 36 ust. 1–11 – Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2023/2854 z dnia 13 grudnia 2023 r. w sprawie zasad sprawiedliwego dostępu do danych i ich wykorzystywania (Data Act)
- art. 5 – Data Act (umowy o udostępnianie danych)
- art. 22 – Rozporządzenie (UE) nr 1025/2012 w sprawie normalizacji europejskiej
- art. 38–39 – Data Act (organy nadzorcze i dochodzenie roszczeń)
Tematy zawarte w poradniku
- Wymagania techniczne i prawne dla smart contracts zgodnie z Data Act
- Ocena zgodności i deklaracja UE dla inteligentnych umów
- Odpowiedzialność dostawców aplikacji za zgodność kodu
- Normy zharmonizowane i wspólne specyfikacje Komisji Europejskiej
- Compliance by design w automatyzacji umów o udostępnianie danych