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 numer), 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.

Krzysztof
Wojdyło