Tech kontra wirus – contact tracing | Co do zasady

Walka z koronawirusem dynamicznie wchodzi w kolejną fazę. Po pierwszym szoku zaczynamy uświadamiać sobie, że czynnikiem decydującym o tempie powrotu do nieco normalniejszego życia może okazać się technologia. Nie chodzi przy tym wyłącznie o biotechnologię. Równie istotne mogą okazać się rozwiązania zapewniające względną kontrolę nad wirusem do czasu wprowadzenia na rynek skutecznych szczepionek.

Chcielibyśmy tym tekstem rozpocząć cykl publikacji na temat prawnych aspektów rozwiązań, które mają nas wspierać w walce z koronawirusem. Rozwiązania te są bardzo interesujące od strony koncepcyjnej i technologicznej, ale często wiążą się z wieloma ważnymi zagadnieniami prawnymi.

Wybór pierwszego tematu jest z perspektywy prawnika dosyć oczywisty. Chodzi o aplikacje oparte na koncepcji „contact tracing”, czyli monitorujące interakcje między ludźmi w celu identyfikacji osób zarażonych koronawirusem. W rozwiązaniach tych pokładamy duże nadzieje na pokonanie pandemii. Są one jednak oparte na idei monitorowania ludzkich zachowań, co tworzy zasadnicze wyzwania prawne.

O co chodzi w contact tracingu?

Aplikacje „contact tracing” to bardzo wiele potencjalnych rozwiązań, które mają zasadniczo wspólny cel. Chodzi o skuteczne identyfikowanie osób, które mogą być zainfekowane koronawirusem. Identyfikacja takich osób jest jednym z kluczowych czynników, które mogą powstrzymać rozprzestrzenianie się wirusa do czasu nabycia przez społeczeństwa zbiorowej odporności.

Osiągnięcie tego celu jest możliwe dzięki monitorowaniu interakcji między ludźmi. Po ustaleniu, że określona osoba jest nosicielem wirusa, można szybko odtworzyć historię jej społecznych interakcji i dotrzeć do osób, które z powodu interakcji z nosicielem są w grupie ryzyka. Takie osoby mogą być np. priorytetowo poddawane testom na obecność wirusa.

Wskazany cel można osiągnąć na wiele sposobów. Powstają bardzo różne pomysły, sytuacja jest niezwykle dynamiczna i trudno w tym momencie przesądzić, jakie rozwiązania będą dominujące. W praktyce należy liczyć się z tym, że w różnych regionach świata będą stosowane różne rozwiązania.

Wspólną cechą wielu rozwiązań jest technologia używana do monitorowania interakcji. Najwięcej aplikacji opiera się na funkcji Bluetooth w smartfonach. Technologia ta umożliwia automatyczną wymianę danych pomiędzy urządzeniami znajdującymi się w określonej odległości od siebie. Dzięki temu smartfony mogą gromadzić dane na temat interakcji ich użytkowników.

Tym, co istotnie różnicuje projekty „contact tracing”, są przyjęte rozwiązania dotyczące zakresu zbieranych i przetwarzanych danych oraz architektury aplikacji, w szczególności tego, w jakim stopniu system wymiany danych jest scentralizowany, a w jakim zdecentralizowany.

Modele najbardziej scentralizowane mogą umożliwiać zbieranie danych pozwalających na jednoznaczną identyfikację osób oraz przekazywanie tych danych do odpowiednich organów administracji (np. administracji sanitarnej, ale również policji). Na przeciwległym biegunie są modele, które przewidują jedynie przetwarzanie anonimowych identyfikatorów oraz wymianę danych w modelu peer-to-peer, bez angażowania administracji.

Różnice między modelami najlepiej zilustrować, śledząc cykl życia danych w aplikacji. Zakładamy, że obywatele używają masowo smartfonów z włączoną funkcją Bluetooth (w tym kontekście powstaje zresztą pierwszy ważny dylemat: w jakim stopniu używanie aplikacji powinno być dobrowolne, a w jakim wymuszone). Smartfony zapisują dane dotyczące interakcji z innymi smartfonami. W praktyce zapisują określone identyfikatory generowane przez te smartfony (tu kolejny dylemat dotyczący tego, jak skonstruowane są identyfikatory) oraz np. dane o odległości oraz czasie interakcji. Dane te są zapisywane na smartfonach. W zależności od wybranego modelu mogą być również przekazywane dalej, np. do centralnego repozytorium danych kontrolowanych przez organy administracji. Modele mogą różnić się również długością przechowywania zebranych danych. Kluczowym momentem w działaniu aplikacji jest pozyskanie informacji, że określona osoba jest nosicielem wirusa. Modele mogą różnić się tym, jak taka informacja trafia do systemu. Niektóre zakładają dobrowolność zgłoszenia takiej informacji do systemu przez obywatela, inne zakładają „odgórne” wprowadzanie takich informacji przez administrację (oczywiście w tym drugim wariancie system musiałby dopuszczać przetwarzanie danych, które pozwalałyby administracji porównywać dane o osobach zainfekowanych z danymi pozyskiwanymi ze smartfonów). Po wprowadzeniu danych o nosicielach do systemu informacja ta pozwala odtworzyć interakcje nosicieli z innymi osobami. Odtworzenie takich interakcji może odbywać się w centralnym repozytorium danych lub lokalnie na smartfonach użytkowników. Należy w tym celu porównać identyfikator nosiciela z identyfikatorami zapisanymi na danym smartfonie. W przypadku ich zgodności aplikacja na podstawie danych o odległości oraz czasie interakcji ocenia prawdopodobieństwo zainfekowania użytkownika smartfona. W tym momencie pojawia się kolejny dylemat. Informacja o ryzyku zarażenia może być dostępna wyłącznie dla użytkownika smartfona albo zostać automatycznie przekazana do organów administracji.

Jak widać, ilość możliwych konfiguracji oraz wariantów aplikacji „social tracing” jest bardzo duża. Gdy koronawirus dotarł do Europy oraz Stanów Zjednoczonych, pomysły na aplikacje zostały poddane rewizji przez pryzmat specyficznego dla tych regionów podejścia do prywatności oraz dopuszczalnych granic ingerencji państwa w prywatność jednostek. Efektem tej rewizji jest kilka bardzo ciekawych inicjatyw, które próbują wypracować standardy aplikacji „contact tracing” uwzględniające regionalną specyfikę w podejściu do prywatności.

Przykładem takiej inicjatywy jest PEPP-PT. Jej twórcy starają się wyznaczać pewne standardy działania aplikacji Proximity-Tracing. W dużym uproszczeniu zakładają one jedynie upublicznianie anonimowych identyfikatorów użytkowników smartfonów. Model umożliwia uzyskanie zakładanego celu, tj. przekazanie osobie zagrożonej zarażeniem stosownej informacji o tym, że znajduje się w gronie osób zagrożonych, bez konieczności przekazywania danych identyfikacyjnych nosiciela. W tym kontekście pojawiła się również koncepcja TCN (temporary contact number), czyli losowo generowanych identyfikatorów, które byłyby zmieniane w regularnych odstępach czasu. Zwiększałoby to anonimowość rozwiązania.

W tworzenie aplikacji zaangażowały się również Apple i Google łącząc siły i tworząc wspólny standard. Zawiera on wiele elementów postulowanych przez PEPP-PT. Wiele wskazuje na to, że to właśnie standard ustanowiony przez Google/Apple ma szansę stać się standardem dominującym.

Zagadnienia prawne

Podstawowym wyzwaniem prawnym związanym z „social tracing” są oczywiście zagadnienia związane z danymi osobowymi. W przestrzeni publicznej pojawiło się już wiele wypowiedzi na ten temat, nie ma sensu ich powielać. Chciałbym za to zwrócić uwagę na kilka mniej oczywistych wątków.

Tak jak wskazałem powyżej, ilość potencjalnych modeli aplikacji „contact tracing” jest bardzo duża. Ta różnorodność przekłada się również na bardzo różne możliwe konfiguracje w zakresie danych osobowych. Po pierwsze, w niektórych modelach zasadne będzie w ogóle pytanie, czy mamy do czynienia z przetwarzaniem przez aplikacje danych osobowych. Część modeli zakłada bowiem jedynie przekazywanie zanonimizowanych identyfikatorów, które będą losowo generowane w określonych odstępach czasu. Co ważne, niektóre modele zakładają, że identyfikatory są przekazywane jednie bezpośrednio między urządzeniami końcowymi użytkowników za pomocą komunikacji Bluetooth. Do centralnego serwera trafiają jedynie klucze, które po ściągnięciu na urządzenia końcowe pozwalałyby sprawdzić, czy określony identyfikator jest zapisany na danym urządzeniu końcowym.

Mamy zatem całą paletę możliwości. W przypadku aplikacji przekazujących do centralnego serwera dane jednoznacznie identyfikujące osobę sprawa wydaje się oczywista. Będzie dochodziło do przetwarzania danych osobowych. Na drugim biegunie będą aplikacje, które tworzą kilkustopniowe poziomy anonimizacji danych. Po pierwsze, konstrukcja aplikacji opiera się na zanonimizowanych, generowanych losowo w określonych odstępach czasu identyfikatorach. Po drugie, do centralnego repozytorium trafiają jedynie klucze szyfrujące, a nie same identyfikatory. W przypadku takich aplikacji, nawet jeżeli uznamy, że anonimowe identyfikatory w określonych okolicznościach mogą umożliwiać identyfikację osób (polecam w tym kontekście analizę systemu DP3T), to są one przetwarzane jedynie na poziomie urządzeń końcowych użytkowników aplikacji. Z kolei uznanie kluczy za dane osobowe jest na pierwszy rzut oka bardziej problematyczne, zwłaszcza jeżeli architektura systemu zapewni, że wyłącznie użytkownicy końcowi są w stanie użyć tych kluczy w celu ustalenia identyfikatorów.

Drugie, być może jeszcze ciekawsze zagadnienie, wiąże się z ustaleniem, czy w niektórych modelach będziemy mieli w ogóle do czynienia z administratorem danych. Dotyczy to w szczególności modeli zdecentralizowanych, zakładających co najwyżej przekazywanie do centralnego serwera jedynie bardzo wąskiej wiązki zanonimizowanych danych. Potencjalny centralny operator repozytorium przetwarzałby jedynie zanonimizowane identyfikatory. Co do zasady nie mógłby również skojarzyć tych identyfikatorów z konkretnymi osobami. Takie skojarzenie możliwe byłoby potencjalnie jedynie na poziomie użytkowników końcowych. Dodatkowo część deweloperów rozważa umieszczanie anonimowych identyfikatorów (ewentualnie kluczy) na blockchainie publicznym, co tym bardziej utrudniłoby zidentyfikowanie ewentualnego administratora danych. W konsekwencji może się zatem okazać, że nawet jeżeli aplikacje będą przetwarzały informacje, które przy ostrożnościowym podejściu do definicji danych osobowych uznamy za dane osobowe, w systemie nie będzie praktycznie podmiotów, które będą zobligowane do stosowania określonych obowiązków wynikających z RODO (np. obowiązków informacyjnych względem podmiotów danych). Administratorami w szczególności nie będą również raczej użytkownicy końcowi. Oni co do zasady będą podlegać pod wyłączenie stosowania RODO z uwagi na używanie aplikacji w ramach czynności o czysto osobistym lub domowym charakterze (art. 2 ust. 2 lit. c) RODO).

Ciekawy wątek w kontekście danych osobowych to również ewentualne profilowanie, które jest realizowane przez aplikacje. Zgodnie z RODO „profilowanie” oznacza dowolną formę zautomatyzowanego przetwarzania danych osobowych, które polega na wykorzystaniu danych osobowych do oceny niektórych czynników osobowych osoby fizycznej, w szczególności do analizy lub prognozy aspektów dotyczących jej zdrowia. Wydaje się, że m.in. temu właśnie mają służyć aplikacje „social tracing”. RODO w art. 22 zawiera bardzo istotny przepis, który próbuje tworzyć ochronę prawną dla jednostek, których sytuacja jest zależna od automatycznego przetwarzania ich danych osobowych, w tym profilowania. Abstrahując od wielu niuansów, które należałoby przeanalizować w celu ustalenia, w jakim w ogóle stopniu art. 22 miałby zastosowanie do przetwarzania danych w aplikacjach „social tracing”, zwróciłbym uwagę na specyfikę tych aplikacji, które dokonują profilowania jedynie na poziomie urządzeń końcowych użytkowników. W takim przypadku, nawet jeżeli mielibyśmy do czynienia z wypełnieniem hipotezy art. 22 RODO, jego zastosowanie byłoby praktycznie wyłączone.

W kontekście prawa telekomunikacyjnego są przynajmniej dwa bardzo istotne elementy, które należy rozważyć w związku z aplikacjami „social tracing”. Po pierwsze, działanie aplikacji należy przeanalizować pod kątem tego, czy dane przetwarzane za pomocą aplikacji są objęte tajemnicą telekomunikacyjną. Jeżeli zidentyfikujemy takie dane, niezależnie od zagadnień związanych z danymi osobowymi należy uzgodnić model działania aplikacji z ograniczeniami w przetwarzaniu tajemnicy telekomunikacyjnej. Po drugie, prawo telekomunikacyjne określa również zasady dostępu do danych znajdujących się na telekomunikacyjnym urządzeniu końcowym oraz instalowania oprogramowania na telekomunikacyjnym urządzeniu końcowym. Aplikacje, które będą przewidywały takie możliwości, muszą być zaprojektowane zgodnie z art. 173 Prawa telekomunikacyjnego.

Aplikacje „contact tracing” należy również na wszelki wypadek przeanalizować przez pryzmat przepisów o wyrobach medycznych. Wraz z postępującą cyfryzacją już od jakiegoś czasu w systemie prawa narasta problem kwalifikacji prawnej aplikacji, które mają zastosowanie do monitorowania ludzkiego zdrowia. Bardzo często wpadają one w tzw. szarą strefę, w której niekiedy bardzo trudno ustalić, czy mamy do czynienia z wyrobem medycznym czy nie. Bierze się to z szerokiej definicji wyrobów medycznych, która obejmuje m.in. oprogramowanie przeznaczone do stosowania u ludzi w celu diagnozowania, zapobiegania, monitorowania, leczenia lub łagodzenia przebiegu choroby. Ważny w tym kontekście jest wyrok TSUE w sprawie C-329/16, a także Wytyczne Komisji Europejskiej na temat kwalifikacji oprogramowania jako wyrobów medycznych.

Zastrzegam, że powyższe komentarze są utrzymane na wysokim poziomie abstrakcji. W praktyce, z uwagi na duże zróżnicowanie poszczególnych aplikacji, konieczna jest szczegółowa analiza prawna każdego modelu, oparta na szczegółach technicznych każdego rozwiązania.

Stanowisko europejskie

W ostatnich dniach swoje oficjalne stanowiska w odniesieniu do aplikacji „contact tracing” wydały również organy europejskie. Na szczególną uwagę zasługuje w tym kontekście Guidance on Apps supporting the fight against COVID 19 pandemic in relation to data protection oraz Toolbox dotyczący aplikacji.

Z przywołanych dokumentów wyłania się wstępny zarys architektury aplikacji „social tracing”, która, biorąc pod uwagę specyfikę europejskiego podejścia do ochrony prywatności, byłaby pożądana z perspektywy organów europejskich. Wytyczne postulują m.in. ustalenie organów publicznych jako administratorów danych. Chodzi przede wszystkim o to, aby uniknąć wątpliwości, jaki podmiot jest zobowiązany do realizowania wynikających z RODO obowiązków względem podmiotów danych. Jako podstawę przetwarzania danych wytyczne sugerują art. 6(1)(c) oraz art. 9(2)(i) RODO. Chodzi o zapewnienie przejrzystości w zakresie podstaw przetwarzania danych. Dane powinny być przechowywane na urządzeniach końcowych i przekazywane do centralnego repozytorium wyłącznie w przypadku pozytywnej diagnozy. W ramach postulatu minimalizacji danych Komisja rekomenduje unikanie przetwarzania danych lokalizacyjnych jako zbędnych w kontekście celów aplikacji. Wytyczne wspierają również zdecentralizowaną architekturę aplikacji jako promującą zasadę minimalizacji danych. Pojawiają się również konkretne postulaty dotyczące stworzenia rozwiązań, które umożliwią interoperacyjność pomiędzy różnymi aplikacjami stosowanymi w poszczególnych państwach członkowskich.

Wytyczanie nowych granic

Niezależnie od prawnych niuansów warto zdać sobie sprawę z szerszego kontekstu dyskusji o aplikacjach „social tracing”. W tych tygodniach rozgrywa się nie tylko walka o nasze zdrowie, ale również o wytyczenie nowych granic dla ochrony prywatności oraz dopuszczalnej państwowej ingerencji w naszą prywatność. Dylematy, których rozstrzyganie było do tej pory procesem rozłożonym na lata, muszą być rozstrzygnięte w ciągu tygodni. W takich okolicznościach chęć opanowania pandemii może stępić naszą wrażliwość na konieczność ochrony naszych fundamentalnych praw. Ryzyko jest przy tym takie, że raz przekroczonych barier być może nie da się już odbudować. W tym kontekście bardzo ważne są inicjatywy takie jak np. Contact Tracing Bill of Rights lub polskie 7 filarów zaufania. Stwarzają one szansę na to, że nasze ostateczne wybory, nawet jeżeli doprowadzą do redefinicji naszego pojęcia prywatności, będą dostatecznie przemyślane.

Tekst ukazał się pierwotnie na blogu newtech.law

Krzysztof Wojdyło, adwokat, praktyka prawa nowych technologii kancelarii Wardyński i Wspólnicy