Data Act zmienia sposób, w jaki należy patrzeć na zamówienia obejmujące urządzenia IoT, inteligentne maszyny, pojazdy połączone z siecią, sprzęt medyczny czy oprogramowanie sterujące takimi urządzeniami. W takich postępowaniach przedmiotem zainteresowania zamawiającego nie powinien być już tylko sam sprzęt i jego funkcjonalność. Równie ważne stają się dane generowane podczas używania urządzenia, możliwość dostępu do nich, zasady korzystania z nich przez wykonawcę oraz ochrona tajemnicy przedsiębiorstwa i danych osobowych. Jeżeli te kwestie zostaną pominięte na etapie przygotowania zamówienia, po podpisaniu umowy może okazać się, że zamawiający formalnie posiada urządzenie, ale nie ma praktycznej kontroli nad generowanymi przez nie informacjami.
Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2023/2854, czyli Data Act, stosuje się co do zasady od 12 września 2025 r. Trzeba jednak pamiętać o istotnym przepisie przejściowym: obowiązek projektowania produktów i usług w sposób zapewniający użytkownikowi dostęp do danych, określony w art. 3 ust. 1 Data Act, ma zastosowanie do produktów skomunikowanych i związanych z nimi usług wprowadzonych na rynek po 12 września 2026 r.
Kiedy Data Act ma znaczenie w zamówieniu publicznym?
Pierwszym krokiem przed przygotowaniem SWZ i projektu umowy powinno być ustalenie, czy zamówienie obejmuje rozwiązania, do których stosuje się Data Act.
W praktyce szczególnej analizy wymagają przede wszystkim zamówienia dotyczące:
- produktów skomunikowanych,
- usług powiązanych z takimi produktami,
- systemów wykorzystujących dane generowane podczas korzystania z urządzeń,
- rozwiązań IoT,
- pojazdów i maszyn wyposażonych w moduły komunikacyjne,
- inteligentnej infrastruktury miejskiej,
- sprzętu medycznego przekazującego dane,
- aplikacji i oprogramowania wpływających na działanie urządzeń.
Data Act reguluje również usługi przetwarzania danych, w tym rozwiązania chmurowe. W ich przypadku szczególne znaczenie mają m.in. regulacje dotyczące zmiany dostawcy. W zamówieniu obejmującym zarówno urządzenia IoT, jak i infrastrukturę chmurową trzeba więc przeanalizować więcej niż jeden obszar rozporządzenia.
Co jest produktem skomunikowanym według Data Act?
Art. 2 pkt 5 Data Act obejmuje pojęciem produktu skomunikowanego rzecz, która pozyskuje, generuje lub zbiera dane dotyczące sposobu jej używania albo otoczenia i może przekazywać dane np. przez połączenie elektroniczne, fizyczne lub dostęp bezpośrednio na urządzeniu. Podstawową funkcją takiego produktu nie może być jednak przechowywanie, przetwarzanie lub przesyłanie danych w imieniu podmiotu innego niż użytkownik.
W praktyce mogą to być przykładowo:
- samochody wyposażone w system telematyczny,
- inteligentne liczniki,
- urządzenia monitorujące zużycie energii,
- maszyny budowlane i rolnicze wyposażone w czujniki,
- sprzęt laboratoryjny przekazujący dane diagnostyczne,
- urządzenia wykorzystywane w systemach smart city,
- inteligentne urządzenia stosowane w budynkach,
- niektóre urządzenia medyczne.
Nie każde urządzenie podłączone do sieci automatycznie będzie jednak produktem skomunikowanym w rozumieniu Data Act. Trzeba sprawdzić jego podstawową funkcję oraz sposób generowania i komunikowania danych.
Przykładowo serwer, którego zasadniczym zadaniem jest przechowywanie i przetwarzanie danych na rzecz innych podmiotów, nie powinien być traktowany tak samo jak inteligentna pompa wodociągowa generująca dane dotyczące ciśnienia, zużycia energii, temperatury i swojej pracy.
Przykład: inteligentne urządzenia dla spółki komunalnej
Miejska spółka wodociągowa kupuje 36 sterowników pomp wyposażonych w moduły łączności. Urządzenia automatycznie rejestrują ciśnienie, zużycie energii, liczbę godzin pracy, temperaturę oraz komunikaty o awariach. Dane są przekazywane także do platformy producenta.
W takim przypadku nie wystarczy określić w zamówieniu parametrów technicznych urządzeń. Zamawiający powinien również ustalić:
- jakie dane generują sterowniki,
- które informacje trafiają do producenta,
- kto ma dostęp do danych,
- przez jaki czas są one przechowywane,
- czy zamawiający może pobrać dane we własnym systemie,
- w jakim formacie dane zostaną przekazane,
- czy możliwy jest dostęp automatyczny przez API,
- do jakich własnych celów producent będzie mógł wykorzystywać dane.
Czy zamawiający publiczny może być użytkownikiem w rozumieniu Data Act?
Tak. Sam publiczny charakter podmiotu nie wyklucza uznania go za użytkownika.
Zgodnie z art. 2 pkt 12 Data Act użytkownikiem może być osoba fizyczna albo prawna będąca właścicielem produktu skomunikowanego, podmiot, któremu na podstawie umowy przyznano tymczasowe prawo do korzystania z produktu, albo podmiot korzystający z usługi powiązanej.
Motyw 18 Data Act wprost wskazuje przy tym, że użytkownikiem może być również organ sektora publicznego.
Dlatego jednostka publiczna kupująca urządzenie IoT, biorąca je w leasing albo korzystająca z usługi powiązanej może korzystać z praw przysługujących użytkownikowi na podstawie Data Act.
Nie należy natomiast utożsamiać tej sytuacji z odrębnymi regulacjami Data Act dotyczącymi żądania przez organy sektora publicznego dostępu do danych z powodu wyjątkowej potrzeby. To inny mechanizm prawny. W zamówieniu na własne urządzenia zamawiający może występować przede wszystkim jako użytkownik produktu lub usługi.
Kiedy wykonawca będzie posiadaczem danych?
Drugą kluczową rolą jest posiadacz danych.
Zgodnie z art. 2 pkt 13 Data Act chodzi o osobę fizyczną albo prawną mającą – na podstawie Data Act, innego prawa Unii, zgodnego z nim prawa krajowego, a w określonych przypadkach także umowy – prawo lub obowiązek wykorzystywania i udostępniania danych.
W zamówieniach publicznych posiadaczem danych często będzie producent urządzenia lub dostawca usługi powiązanej, jeżeli ma rzeczywisty i prawnie dopuszczalny dostęp do danych generowanych przez produkt.
Nie oznacza to jednak, że każdy wykonawca dostarczający urządzenie automatycznie jest posiadaczem danych.
Możliwa jest sytuacja, w której wykonawca sprzedaje urządzenie, lecz po dostawie nie otrzymuje żadnych informacji generowanych podczas jego używania. Dane zapisują się lokalnie albo są przesyłane wyłącznie do infrastruktury zamawiającego. W takim modelu sam fakt sprzedaży urządzenia nie przesądza jeszcze o statusie posiadacza danych.
Dlatego już na etapie analizy rynku warto ustalić rzeczywisty przepływ danych:
urządzenie → system zamawiającego → chmura wykonawcy → producent → podwykonawca
Dopiero taka mapa pokazuje, kto faktycznie uzyskuje dostęp do informacji.
Czym jest usługa powiązana i dlaczego ma znaczenie?
Art. 2 pkt 6 Data Act odnosi się do usługi cyfrowej, w tym oprogramowania, która jest powiązana z produktem w taki sposób, że bez niej produkt nie mógłby wykonywać co najmniej jednej ze swoich funkcji albo która została później połączona z produktem po to, aby dodać, zmienić lub uaktualnić jego funkcje.
Typowym przykładem może być aplikacja sterująca inteligentnym urządzeniem.
Nie każda usługa wykonywana wokół urządzenia będzie jednak usługą powiązaną. Sam serwis mechaniczny, doradztwo, finansowanie czy zapewnienie dostępu do internetu nie stają się usługami powiązanymi tylko dlatego, że dotyczą urządzenia IoT.
W postępowaniu warto więc oddzielić:
- dostawę samego urządzenia,
- oprogramowanie odpowiedzialne za jego funkcjonowanie,
- usługi transmisji danych,
- serwis i konserwację,
- analizę danych,
- hosting lub usługę chmurową.
Takie rozdzielenie znacznie ułatwia późniejsze określenie praw i obowiązków dotyczących danych.
Jakie informacje wykonawca powinien przekazać przed zawarciem umowy?
Data Act nakłada szczególne obowiązki informacyjne dotyczące produktów skomunikowanych i usług powiązanych.
Z punktu widzenia zamówień publicznych jest to istotne już na etapie przygotowania dokumentacji przetargowej. Zamawiający powinien zaprojektować postępowanie tak, aby informacje wymagane przez Data Act rzeczywiście otrzymał przed związaniem się umową.
W odniesieniu do produktu skomunikowanego informacje powinny pozwalać ustalić między innymi:
- jakie rodzaje danych produkt może generować,
- jaki jest ich format i szacunkowa ilość,
- czy dane mogą być generowane w czasie rzeczywistym,
- gdzie są przechowywane,
- jak długo mogą być przechowywane,
- w jaki sposób użytkownik może uzyskać do nich dostęp,
- jak można je pobrać lub – jeżeli ma to zastosowanie – usunąć.
Przy usłudze powiązanej zakres informacji jest szerszy i obejmuje również m.in. dane, które będzie pozyskiwał przyszły posiadacz danych, częstotliwość ich zbierania, warunki dostępu, cele wykorzystywania danych oraz informacje dotyczące tajemnicy przedsiębiorstwa.
W praktyce dobrym rozwiązaniem może być wymaganie od wykonawcy przygotowania karty danych produktu, stanowiącej załącznik do oferty albo umowy.
Taka karta może określać:
- kategorie generowanych danych,
- formaty plików lub interfejsy API,
- częstotliwość generowania informacji,
- miejsce przechowywania,
- okres retencji,
- podmioty uzyskujące dostęp,
- cele używania danych przez wykonawcę,
- zasady udostępniania danych osobom trzecim,
- dane objęte tajemnicą przedsiębiorstwa,
- stosowane zabezpieczenia.
Czy wykonawca może wykorzystywać dane zamawiającego do własnych celów?
Nie można przyjąć, że skoro wykonawca technicznie otrzymuje dane, może następnie dowolnie z nich korzystać.
Art. 4 ust. 13 Data Act przewiduje, że posiadacz danych może wykorzystywać łatwo dostępne dane nieosobowe wyłącznie na podstawie umowy z użytkownikiem.
Dla zamawiającego oznacza to, że kwestia wykorzystywania danych przez wykonawcę powinna zostać świadomie uregulowana w umowie.
Nie wystarczy ogólne stwierdzenie, że wykonawca „może korzystać z danych w celu świadczenia usług”. Warto dokładnie wskazać:
- konkretne kategorie danych,
- dopuszczalne cele ich wykorzystywania,
- okres korzystania z danych,
- zasady agregowania danych,
- możliwość wykorzystania danych do rozwoju produktów,
- zasady przekazywania ich podwykonawcom,
- zasady usuwania danych po zakończeniu umowy.
Data Act ogranicza również możliwość wykorzystywania danych do uzyskiwania informacji o sytuacji ekonomicznej, aktywach czy metodach produkcji użytkownika, jeżeli mogłoby to osłabić jego pozycję handlową.
W przypadku zamawiającego publicznego ryzyko nie zawsze będzie miało klasyczny charakter konkurencyjny, ale precyzyjne określenie celów wykorzystania danych pozostaje równie istotne.
Udostępnianie danych przez wykonawcę innym podmiotom
Szczególnej uwagi wymaga model, w którym dane trafiają nie tylko do wykonawcy, ale również do jego dostawcy chmury, producenta komponentów albo podmiotu zajmującego się analizą danych.
Art. 4 ust. 14 Data Act ogranicza możliwość udostępniania przez posiadacza danych nieosobowych danych z produktu osobom trzecim do celów innych niż wykonanie umowy z użytkownikiem.
Dlatego w projekcie umowy warto wymagać co najmniej:
- wskazania kategorii odbiorców danych,
- określenia celu udostępniania,
- zobowiązania odbiorców do odpowiedniej ochrony informacji,
- zakazu dalszego niekontrolowanego przekazywania danych,
- określenia zasad postępowania z danymi po zakończeniu współpracy.
Pozwala to uniknąć sytuacji, w której dane eksploatacyjne infrastruktury publicznej zaczynają krążyć pomiędzy kolejnymi podmiotami bez rzeczywistej kontroli zamawiającego.
Jak zamawiający może uzyskać dostęp do danych?
Data Act przewiduje dwa zasadnicze modele dostępu.
Dostęp bezpośrednio z produktu
Jeżeli rozwiązanie techniczne na to pozwala, użytkownik może uzyskiwać dane bezpośrednio z urządzenia lub usługi, np. przez panel użytkownika, port komunikacyjny albo API.
Art. 3 ust. 1 Data Act zakłada projektowanie produktów i usług w taki sposób, aby objęte tym przepisem dane wraz z metadanymi były co do zasady łatwo, bezpiecznie i nieodpłatnie dostępne w odpowiednim formacie. Trzeba jednak pamiętać o szczególnym przepisie przejściowym dotyczącym produktów i usług wprowadzonych na rynek po 12 września 2026 r.
Dostęp za pośrednictwem posiadacza danych
Jeżeli użytkownik nie może uzyskać danych bezpośrednio, art. 4 ust. 1 Data Act pozwala mu żądać od posiadacza danych udostępnienia danych łatwo dostępnych wraz z metadanymi potrzebnymi do ich interpretacji i wykorzystania.
Zamawiający powinien więc przed zakupem wiedzieć nie tylko, że „ma prawo do danych”, lecz również jak technicznie będzie to prawo wykonywał.
Warto określić w umowie:
- sposób składania żądania,
- kanał dostępu,
- wymagany format,
- sposób uwierzytelnienia,
- parametry API,
- częstotliwość aktualizacji,
- warunki dostępu w czasie rzeczywistym,
- odpowiedzialność za niedostępność interfejsu.
Przykład: system zarządzania flotą
Powiat kupuje 18 pojazdów służbowych wyposażonych w system telematyczny. Dane dotyczą między innymi przebiegu, zużycia paliwa, stanu podzespołów, lokalizacji i sposobu eksploatacji.
Po roku powiat chce powierzyć analizę kosztów floty innej firmie niż dostawca pojazdów.
Jeżeli odpowiednie dane są objęte Data Act, użytkownik może w określonych warunkach żądać ich udostępnienia wybranej osobie trzeciej. W praktyce już umowa na zakup pojazdów powinna więc zapewniać techniczną możliwość eksportu danych w formacie pozwalającym na ich rzeczywiste wykorzystanie. Sam plik PDF z miesięcznym zestawieniem może być niewystarczający, gdy celem jest automatyczna analiza tysięcy rekordów.
Czy zamawiający może dowolnie używać otrzymanych danych?
Prawo dostępu nie oznacza pełnej swobody wykorzystania.
Art. 4 ust. 10 Data Act zabrania użytkownikowi wykorzystywania danych uzyskanych w odpowiedzi na wniosek do opracowania produktu skomunikowanego konkurującego z produktem, z którego dane pochodzą. Użytkownik nie może również przekazywać danych osobie trzeciej w takim celu.
Zakaz dotyczy konkurencyjnego produktu skomunikowanego. Nie oznacza automatycznego zakazu rozwijania każdej usługi bazującej na uzyskanych danych.
Dla zamawiającego ma to znaczenie np. wtedy, gdy chce przekazać dane innemu wykonawcy w celu stworzenia niezależnego systemu analitycznego, predykcyjnego utrzymania urządzeń albo optymalizacji ich pracy.
Przed takim działaniem trzeba ustalić, czy nowy projekt jest usługą wykorzystującą dane, czy w rzeczywistości zmierza do opracowania produktu konkurencyjnego.
Tajemnica przedsiębiorstwa nie zawsze blokuje dostęp do danych
Jednym z najczęstszych sporów wokół Data Act może być powoływanie się przez producentów na know-how i tajemnicę przedsiębiorstwa.
Sama okoliczność, że określone dane mają wartość gospodarczą, nie oznacza jeszcze automatycznie, że można odmówić ich udostępnienia.
Art. 4 ust. 6–8 Data Act przewiduje stopniowany mechanizm ochrony.
Najpierw należy zidentyfikować dane stanowiące tajemnicę przedsiębiorstwa. Następnie posiadacz danych lub właściciel tajemnicy oraz użytkownik powinni uzgodnić proporcjonalne środki służące ochronie poufności.
Mogą to być przykładowo:
- umowy o poufności,
- ograniczenie dostępu do określonego personelu,
- odpowiednie uprawnienia systemowe,
- rejestrowanie dostępu,
- szyfrowanie,
- zabezpieczenia przed kopiowaniem,
- techniczne protokoły dostępu,
- zobowiązania nakładane na dalszych odbiorców danych.
Jeżeli uzgodnione zabezpieczenia nie zostaną wdrożone lub poufność zostanie zagrożona, posiadacz danych może w określonych przypadkach wstrzymać albo zawiesić udostępnianie danych.
Całkowita odmowa jest rozwiązaniem dalej idącym. Data Act przewiduje ją dla wyjątkowych sytuacji, w których posiadacz danych będący jednocześnie posiadaczem tajemnicy przedsiębiorstwa jest w stanie wykazać, że mimo zastosowanych zabezpieczeń ujawnienie konkretnych informacji z dużym prawdopodobieństwem spowodowałoby poważną szkodę ekonomiczną.
Jak zabezpieczyć tajemnicę przedsiębiorstwa w umowie?
W praktyce zamówień publicznych warto z góry ustalić procedurę obejmującą:
- identyfikację danych chronionych,
- uzasadnienie ich poufnego charakteru,
- określenie osób uprawnionych do dostępu,
- uzgodnienie zabezpieczeń technicznych,
- zasady przekazywania danych podmiotom trzecim,
- procedurę reagowania na naruszenie poufności,
- konsekwencje naruszenia obowiązków.
Niezależnie od Data Act należy pamiętać o krajowej ochronie tajemnicy przedsiębiorstwa, w szczególności wynikającej z art. 11 ustawy o zwalczaniu nieuczciwej konkurencji.
Data Act a RODO – dostęp do danych nie oznacza automatycznie prawa do danych osobowych
Produkty skomunikowane bardzo często generują jednocześnie dane osobowe i nieosobowe.
Samochód może rejestrować parametry techniczne silnika, ale jednocześnie dane lokalizacyjne pozwalające ustalić, kto prowadził pojazd. Urządzenie medyczne może zbierać informacje techniczne dotyczące działania aparatury razem z danymi dotyczącymi konkretnego pacjenta.
W takich sytuacjach Data Act nie zastępuje RODO.
Art. 1 ust. 5 Data Act pozostawia bez uszczerbku unijne i krajowe przepisy dotyczące ochrony danych osobowych, prywatności i poufności komunikacji. Data Act nie tworzy więc samodzielnej podstawy prawnej pozwalającej użytkownikowi swobodnie otrzymać dane osobowe innych osób.
Jeżeli użytkownik żądający informacji nie jest osobą, której dotyczą dane osobowe, art. 4 ust. 12 Data Act wymaga istnienia odpowiedniej podstawy prawnej przetwarzania zgodnie z art. 6 RODO. Jeżeli chodzi o szczególne kategorie danych, trzeba dodatkowo uwzględnić art. 9 RODO.
Przykład: aparatura diagnostyczna w szpitalu
Szpital wojewódzki bierze w pięcioletni leasing 14 urządzeń diagnostycznych. Producent zapewnia jednocześnie aplikację monitorującą pracę sprzętu oraz zdalny serwis.
System gromadzi dane techniczne, takie jak temperatura urządzenia, zużycie elementów i komunikaty serwisowe. W określonych sytuacjach w tym samym środowisku informatycznym mogą jednak pojawiać się również identyfikatory pacjentów i informacje dotyczące zdrowia.
Nie można potraktować całej bazy jako jednego zbioru „danych z urządzenia” i założyć, że Data Act wystarczy jako podstawa ich przekazania.
Przed uruchomieniem dostępu należy między innymi:
- ustalić, które dane są osobowe,
- określić role stron na gruncie RODO,
- wskazać podstawę przetwarzania,
- ocenić, czy występują szczególne kategorie danych,
- zapewnić odpowiednie środki bezpieczeństwa,
- ustalić zakres danych rzeczywiście potrzebnych użytkownikowi.
Właśnie dlatego w zamówieniach obejmujących IoT analiza Data Act i analiza RODO powinny być prowadzone równolegle.
Prawo do dzielenia się danymi a przenoszenie danych z RODO
Art. 5 Data Act pozwala użytkownikowi żądać, aby posiadacz danych udostępnił określone dane wybranej przez użytkownika osobie trzeciej.
Mechanizmu tego nie należy utożsamiać z prawem do przenoszenia danych z art. 20 RODO.
Prawo przewidziane w RODO dotyczy danych osobowych i jest ograniczone określonymi warunkami. Data Act obejmuje natomiast również dane nieosobowe i został zbudowany właśnie po to, aby zwiększać możliwość korzystania z danych generowanych przez produkty i usługi.
W zamówieniach publicznych może to mieć szczególne znaczenie przy zmianie podmiotu serwisującego urządzenie, wdrażaniu dodatkowej aplikacji analitycznej albo integracji kilku systemów różnych producentów.
Kiedy obowiązki dotyczące dostępu do danych mogą być wyłączone?
Nie można zakładać, że rozdział II Data Act stosuje się identycznie do każdego producenta.
Art. 7 ust. 1 przewiduje wyjątek dotyczący danych generowanych w wyniku używania produktów skomunikowanych wyprodukowanych lub zaprojektowanych przez mikroprzedsiębiorstwa i małe przedsiębiorstwa oraz usług powiązanych przez nie dostarczonych, pod warunkiem spełnienia dodatkowych przesłanek wskazanych w tym przepisie.
Regulacja obejmuje również szczególne czasowe rozwiązanie dotyczące przedsiębiorstw, które od niedawna kwalifikują się jako średnie, oraz produktów wprowadzanych przez takie przedsiębiorstwa.
Dlatego przed wpisaniem do umowy katalogu obowiązków odwołujących się do rozdziału II Data Act należy sprawdzić również status przedsiębiorcy, który wytwarza lub projektuje produkt albo dostarcza usługę powiązaną.
Istotna jest przy tym rzeczywista struktura przedsiębiorstw partnerskich i powiązanych oraz rola podwykonawcy. Samo oświadczenie wykonawcy, że jest „małym przedsiębiorcą”, nie powinno kończyć analizy.
Umowa nie może odbierać użytkownikowi praw gwarantowanych przez Data Act
Data Act zabezpiecza użytkownika również przed próbą umownego wyłączenia przyznanych mu praw.
Właściwą podstawą jest w tym przypadku art. 7 ust. 2 Data Act. Postanowienie umowy, które ze szkodą dla użytkownika wyłącza prawa przyznane w rozdziale II, stanowi odstępstwo od nich albo zmienia ich skutek, nie jest dla użytkownika wiążące.
Ma to bardzo praktyczne znaczenie.
Wykonawca nie powinien próbować rozwiązać kwestii danych krótką klauzulą typu:
„wszelkie dane generowane przez urządzenie pozostają wyłączną własnością producenta, a zamawiającemu nie przysługuje prawo dostępu do nich”.
W zależności od rodzaju danych, okoliczności i zakresu zastosowania Data Act takie postanowienie może kolidować z bezwzględnie chronionymi uprawnieniami użytkownika.
Zamiast próbować całkowicie wyłączać dostęp, strony powinny dokładnie określić jego mechanizm, format, zabezpieczenia i dopuszczalne sposoby wykorzystywania danych.
Co wpisać do SWZ i umowy dotyczącej urządzeń IoT?
W zamówieniach obejmujących produkty skomunikowane lub usługi powiązane warto stworzyć osobny rozdział dokumentacji poświęcony danym.
Powinien on odpowiadać przynajmniej na następujące pytania:
1. Jakie dane powstają?
Należy przygotować katalog kategorii danych generowanych przez produkt i usługę.
2. Gdzie trafiają dane?
Trzeba określić lokalizację przechowywania oraz wszystkich uczestników przepływu informacji.
3. Kto jest użytkownikiem i posiadaczem danych?
Role powinny wynikać z rzeczywistego modelu technicznego, a nie wyłącznie z nazwy strony umowy.
4. Jak zamawiający uzyska dane?
Umowa powinna wskazywać format, kanał, interfejs, częstotliwość oraz zasady dostępu.
5. Czy wykonawca może używać danych?
Jeżeli tak, należy jednoznacznie określić zakres oraz cele ich wykorzystywania.
6. Komu wykonawca może przekazać dane?
Trzeba uregulować podwykonawców, dostawców infrastruktury oraz innych odbiorców.
7. Które dane są objęte tajemnicą przedsiębiorstwa?
Najlepiej identyfikować je z wyprzedzeniem zamiast dopiero po powstaniu sporu.
8. Czy zbiór zawiera dane osobowe?
Jeśli tak, konieczna jest odrębna analiza zgodności z RODO.
9. Co stanie się z danymi po wygaśnięciu umowy?
Należy ustalić ich eksport, migrację, zwrot i usunięcie.
10. Jak zostanie udokumentowana zgodność z Data Act?
Warto przewidzieć obowiązki informacyjne, dokumentacyjne i możliwość kontroli.
Najczęstsze błędy przy stosowaniu Data Act w zamówieniach publicznych
Największym ryzykiem nie jest zazwyczaj brak odwołania do nazwy rozporządzenia, lecz brak przełożenia przepisów na konkretny model techniczny.
Szczególnie problematyczne może być:
- zamówienie urządzenia bez określenia praw do generowanych danych,
- pozostawienie wykonawcy pełnej swobody w używaniu informacji,
- brak wiedzy o tym, gdzie dane są przechowywane,
- brak technicznej możliwości ich eksportu,
- utożsamienie każdego wykonawcy z posiadaczem danych,
- traktowanie wszystkich danych jako tajemnicy przedsiębiorstwa,
- nieuwzględnienie RODO przy zbiorach mieszanych,
- pominięcie statusu producenta jako mikro-, małego lub średniego przedsiębiorstwa,
- próba umownego wyłączenia praw użytkownika gwarantowanych przez Data Act.
Pamiętaj, że skuteczne stosowanie Data Act wymaga współpracy prawników, specjalistów od zamówień publicznych, informatyków i osób odpowiedzialnych za bezpieczeństwo informacji. Sama analiza projektu umowy może nie wystarczyć, jeżeli nikt nie sprawdzi architektury systemu i rzeczywistego przepływu danych.
Podsumowanie
Data Act powoduje, że przy zakupie nowoczesnych urządzeń dla sektora publicznego trzeba myśleć nie tylko o własności sprzętu, ale również o kontroli nad danymi powstającymi podczas jego używania.
Zamawiający powinien już przed wszczęciem postępowania ustalić, czy nabywany produkt jest produktem skomunikowanym, czy towarzyszy mu usługa powiązana, jakie dane będą generowane oraz kto będzie miał do nich dostęp.
W projekcie umowy szczególnego znaczenia nabierają postanowienia dotyczące:
- dostępu do danych,
- ich formatu i sposobu pobierania,
- wykorzystywania danych przez wykonawcę,
- przekazywania informacji osobom trzecim,
- ochrony tajemnicy przedsiębiorstwa,
- ochrony danych osobowych,
- migracji i usunięcia danych po zakończeniu współpracy.
Najlepszym momentem na rozwiązanie tych problemów jest etap przygotowania zamówienia. Po zakupie urządzeń zmiana architektury technicznej lub wymuszenie dostępu do danych może być znacznie trudniejsze i droższe.
Podstawa prawna
- art. 1 ust. 5, art. 2 pkt 5, pkt 6, pkt 12, pkt 13 i pkt 17, art. 3 ust. 1–3, art. 4 ust. 1–2, ust. 6–8, ust. 10, ust. 12–14, art. 5, art. 7 ust. 1–2, art. 50 – rozporządzenie Parlamentu Europejskiego i Rady (UE) 2023/2854 z dnia 13 grudnia 2023 r. w sprawie zharmonizowanych przepisów dotyczących sprawiedliwego dostępu do danych i ich wykorzystywania oraz w sprawie zmiany rozporządzenia (UE) 2017/2394 i dyrektywy (UE) 2020/1828 (akt w sprawie danych);
- art. 4 – ustawa z dnia 11 września 2019 r. – Prawo zamówień publicznych;
- art. 4 pkt 7, art. 6, art. 9, art. 20 – rozporządzenie Parlamentu Europejskiego i Rady (UE) 2016/679 z dnia 27 kwietnia 2016 r. w sprawie ochrony osób fizycznych w związku z przetwarzaniem danych osobowych i w sprawie swobodnego przepływu takich danych oraz uchylenia dyrektywy 95/46/WE (ogólne rozporządzenie o ochronie danych);
- art. 11 – ustawa z dnia 16 kwietnia 1993 r. o zwalczaniu nieuczciwej konkurencji.
Tematy porad zawartych w poradniku
- Data Act w zamówieniach publicznych
- dostęp do danych z urządzeń IoT
- Data Act a RODO
- umowa na produkt skomunikowany
- dane z urządzeń w zamówieniach publicznych