Kiedy produkt SaaS lub aplikacja wymagają DPIA

Zespół produktu SaaS dodaje funkcję, która analizuje działania użytkowników i przypisuje im ocenę ryzyka. Klienci będą mogli wykorzystywać ją do ograniczania operacji na swoich kontach. Dla zespołu deweloperskiego oznacza to nowy zestaw zdarzeń, model obliczeniowy i ekran z wynikiem. Dla osób, których działania ocenia system, konsekwencje mogą być poważniejsze: błędna ocena może zablokować dostęp do usługi lub wzbudzić nieuzasadnione podejrzenia.

W takiej sytuacji przed uruchomieniem może być konieczne przeprowadzenie DPIA — Data Protection Impact Assessment, czyli oceny skutków przetwarzania danych dla praw i wolności osób fizycznych. Jej zadaniem nie jest potwierdzenie gotowości produktu za pomocą formalnego dokumentu. Ocena powinna pokazać, jakie konsekwencje może spowodować nowe przetwarzanie, czy cel można osiągnąć w sposób wiążący się z mniejszym ryzykiem oraz jakie zmiany należy wprowadzić w funkcji przed jej wydaniem.

Kiedy ocena jest obowiązkowa

Zgodnie z GDPR DPIA przeprowadza się przed rozpoczęciem przetwarzania, jeżeli z uwagi na jego charakter, zakres, kontekst i cele prawdopodobnie będzie ono powodować wysokie ryzyko naruszenia praw lub wolności osób fizycznych. Sam fakt wprowadzenia nowej funkcji nie oznacza zatem jeszcze obowiązku przeprowadzenia pełnej oceny. Jednak brak danych medycznych lub finansowych również nie gwarantuje, że ryzyko nie występuje.

GDPR wprost wskazuje w szczególności trzy sytuacje: systematyczną ocenę na dużą skalę cech osobowych opartą na zautomatyzowanym podejmowaniu decyzji, które wywołują skutki prawne lub w podobny sposób istotnie wpływają na osobę; przetwarzanie na dużą skalę szczególnych kategorii danych lub danych dotyczących wyroków skazujących; systematyczne monitorowanie na dużą skalę miejsc dostępnych publicznie. Organy nadzorcze publikują również wykazy operacji, dla których wymagana jest DPIA. Przy uruchamianiu produktu w konkretnym kraju należy sprawdzić odpowiedni wykaz.

W przypadku produktu cyfrowego sygnałami wskazującymi na potrzebę dokładniejszej oceny mogą być profilowanie, łączenie danych z różnych źródeł, stałe monitorowanie zachowania, przetwarzanie danych osób wymagających szczególnej ochrony lub wykorzystywanie wyniku do podejmowania decyzji mającej istotny wpływ na daną osobę. Ocenia się połączenie okoliczności, a nie obecność w opisie funkcji słów «AI», «analityka» lub «scoring».

Tabela nie oznacza, że dla każdej wskazanej funkcji DPIA jest zawsze obowiązkowa. Pokazuje, dlaczego decyzji nie można podejmować wyłącznie na podstawie nazwy narzędzia: znaczenie mają dane, skala przetwarzania oraz rzeczywiste konsekwencje dla danej osoby.

Na jakim etapie rozwoju produktu rozpocząć DPIA

Ocenę przeprowadza się, dopóki można jeszcze wpłynąć na architekturę funkcji. Jeśli zespół wybrał już dostawcę, zebrał dane historyczne i uruchomił funkcję dla wszystkich klientów, DPIA staje się opisem gotowego rozwiązania. Usunięcie wykrytych problemów wymaga wtedy znacznie więcej czasu.

Praktycznym momentem na wstępną ocenę jest omawianie wymagań dotyczących funkcji. Zespół produktowy opisuje cel i oczekiwany rezultat, zespół techniczny wyjaśnia, jakie dane będą potrzebne i jak będzie przebiegać przetwarzanie, a specjalista ds. ochrony danych ocenia przesłanki wysokiego ryzyka. Jeśli ich nie ma, decyzję i jej podstawy należy udokumentować. Jeśli takie przesłanki występują, rozpoczyna się pełną DPIA i doprecyzowuje ją w miarę rozwoju funkcji.

Jakie zmiany wymagają powrotu do oceny

DPIA nie kończy się wraz z pierwszym wydaniem. Nawet jeśli pierwotna wersja funkcji została oceniona, warunki jej wykorzystania mogą się zmienić:

• Podłączono nowe źródło danych. Na przykład do działań w ramach usługi dodano informacje z CRM lub dane zewnętrznego dostawcy. Takie połączenie pozwala wyciągać wnioski, które nie były możliwe przy pierwotnym przetwarzaniu.
• Zmieniono konsekwencje wyniku. Początkowo ocena ryzyka służyła jako wskazówka dla operatora, a teraz automatycznie uruchamia blokadę konta. Dane mogą pozostać takie same, ale potencjalna szkoda dla osoby staje się poważniejsza.
• Rozszerzono grupę odbiorców lub skalę. Funkcję przetestowaną na niewielkiej grupie uruchomiono dla wszystkich klientów albo zaczęto stosować wobec dzieci, pracowników lub innej grupy, której sytuacja wymaga szczególnej uwagi.
• Przekazano dane nowemu dostawcy. Zewnętrzna usługa uzyskała dostęp do danych źródłowych lub wyników modelu. Należy sprawdzić jej rolę, cele wykorzystywania informacji, warunki przechowywania oraz wpływ na wcześniej wybrane środki ochrony.

Każda taka zmiana nie oznacza, że ocenę trzeba będzie przygotować od nowa od pierwszej strony. Zespół powinien jednak sprawdzić, czy jej wnioski pozostają aktualne, i zaktualizować DPIA przed rozpoczęciem zmienionego przetwarzania, jeśli zmienił się poziom ryzyka.

Co analizować na przykładzie funkcji scoringowej

Załóżmy, że platforma pomaga firmom wykrywać podejrzane działania na kontach klientów. Początkowo pokazywała operatorowi listę nietypowych zdarzeń. W nowej wersji system będzie przypisywał każdemu użytkownikowi wynik ryzyka i automatycznie ograniczał dostęp po osiągnięciu określonego progu.

Cel funkcji jest jasny: zmniejszenie ryzyka oszustwa. Dla DPIA takie wyjaśnienie nie jest wystarczające. Trzeba przeanalizować konkretny łańcuch: jakie zdarzenia składają się na wynik, czy wykorzystywane są informacje z innych usług, jak długo przechowywana jest historia, kto widzi ocenę i co dokładnie dzieje się po uruchomieniu modelu.

Następnie ocenia się możliwe konsekwencje dla ludzi. Błędna blokada może uniemożliwić dostęp do własnych środków lub potrzebnej usługi. Zbyt szeroki dostęp pracowników klienta do wyników ryzyka może prowadzić do nieuzasadnionych wniosków na temat użytkownika. Jeśli model jest trenowany na danych kilku klientów, pojawia się odrębne pytanie, w jakich celach i na jakiej podstawie informacje te są wykorzystywane.

Rezultatem DPIA mogą być zmiany w produkcie: usunięcie z modelu zbędnych cech, skrócenie okresu przechowywania historii, zastąpienie automatycznej blokady weryfikacją przez pracownika lub zapewnienie osobie zrozumiałego sposobu zakwestionowania decyzji. Taka ocena wpływa na wymagania dotyczące funkcji, a nie tylko na treść dokumentacji.

Co powinna zawierać sama ocena

GDPR wymaga opisania planowanego przetwarzania i jego celów, oceny konieczności i proporcjonalności działań, określenia ryzyka dla ludzi oraz środków służących jego ograniczeniu. W przypadku zespołu SaaS można to wygodnie przełożyć na kilka praktycznych pytań:

1. Dlaczego funkcja jest potrzebna i jakie dane są dla niej rzeczywiście niezbędne? Należy sprawdzić, czy można osiągnąć rezultat przy mniejszym zakresie danych, krótszym okresie przechowywania lub bez powiązania zdarzeń z konkretnym użytkownikiem.
2. Jaką szkodę może spowodować przetwarzanie? Bierze się pod uwagę nie tylko wyciek lub nieuprawniony dostęp. Błędny wniosek modelu, niesprawiedliwe ograniczenie dostępu do usługi oraz brak możliwości zakwestionowania decyzji również mogą naruszać prawa człowieka.
3. Jakie środki zmieniają poziom ryzyka? Dla każdego istotnego ryzyka wskazuje się konkretne rozwiązanie: ograniczenie dostępu, weryfikację przez człowieka, zmianę logiki modelu, kontrolę jakości danych lub zrozumiałą procedurę odwoławczą.
4. Jakie ryzyko pozostaje po zastosowaniu tych środków? Zespół dokumentuje wynik, osoby odpowiedzialne za zmiany oraz warunki, po spełnieniu których można uruchomić funkcję.

DPIA warto omawiać z osobami, które projektują i wykorzystują funkcję. W razie potrzeby uwzględnia się opinię osób, których dotyczy przetwarzanie, lub ich przedstawicieli. Jeśli w firmie wyznaczono DPO, jego opinia również powinna zostać uzyskana w ramach oceny.

Kto przeprowadza DPIA w B2B SaaS

Jeśli klient wykorzystuje SaaS do własnych celów i decyduje, czyje dane są do niego wprowadzane oraz w jaki sposób wykorzystywany jest wynik, obowiązek oceny takiego przetwarzania zazwyczaj spoczywa na kliencie jako administratorze danych. Dostawca produktu powinien przekazać mu informacje i zapewnić wsparcie niezbędne do przeprowadzenia oceny: opis działania funkcji, kategorii danych, ustawień, ryzyka oraz środków ochrony.

Jednocześnie dostawca nie powinien uznawać tej kwestii za całkowicie go niedotyczącą. Podejmuje on decyzje dotyczące architektury i może samodzielnie określać cele poszczególnych operacji, na przykład wykorzystywania danych do rozwoju własnego produktu. Takie operacje wymagają odrębnej oceny jego roli oraz, w przypadku wysokiego ryzyka, przeprowadzenia własnej DPIA.

W przypadku skalowalnego SaaS warto przygotować materiały dotyczące funkcji, które każdy klient będzie mógł wykorzystać w swojej ocenie. Pozwalają one zaoszczędzić czas, ale nie zastępują analizy konkretnego zastosowania: jeden klient wykorzystuje wynik wyłącznie jako wskazówkę dla pracownika, a drugi używa go do automatycznej odmowy świadczenia usługi. Konsekwencje są różne.

Kiedy należy odłożyć wydanie

DPIA nie daje firmie prawa do zaakceptowania dowolnego ryzyka tylko dlatego, że zostało ono zapisane w tabeli. Jeśli ocena wskazuje na wysokie ryzyko rezydualne, którego nie można ograniczyć za pomocą odpowiednich środków, przed rozpoczęciem przetwarzania wymagana jest uprzednia konsultacja z właściwym organem nadzorczym. Nie można uruchomić spornej funkcji, dopóki ta kwestia nie zostanie rozwiązana.

Częściej ocena prowadzi do bardziej praktycznego rozwiązania: zmiany ustawień domyślnych, usunięcia automatycznego działania, ograniczenia grupy uczestników pilotażu lub dodania weryfikacji wyniku przez człowieka. Po wprowadzeniu zmian ryzyko ocenia się ponownie. Dlatego DPIA warto uwzględnić w kryteriach gotowości funkcji do wydania na równi z testowaniem i bezpieczeństwem.

Główne pytanie dla zespołu brzmi: co zmieni się dla człowieka po uruchomieniu funkcji i czy firma będzie w stanie wyjaśnić oraz ograniczyć możliwą szkodę? Jeśli odpowiedź wymaga przeprojektowania produktu, DPIA została przeprowadzona we właściwym czasie.