Jak przeprowadzić ocenę skutków dla ochrony danych przed wdrożeniem AI

Projekt AI jest gotowy, ale ryzyko dla danych osobowych pozostaje niewidoczne

Typowa sytuacja: narzędzie działa technicznie, lecz organizacja nie zna skutków jego użycia

Najtrudniejszy moment często przychodzi tuż przed zakupem licencji albo uruchomieniem pilotażu. Dział biznesowy widzi sprawne narzędzie: chatbot odpowiada klientom, model porządkuje zgłoszenia, system HR ocenia CV, a mechanizm scoringowy wskazuje osoby wymagające dodatkowej weryfikacji. Technicznie wszystko wygląda obiecująco. Brakuje jednak odpowiedzi na znacznie ważniejsze pytania: jakie dane trafiają do systemu, kto ma do nich dostęp, co dokładnie wpływa na wynik algorytmu i jakie konsekwencje ponosi osoba, której dane są analizowane.

Wdrożenie systemu AI nie ogranicza się do instalacji aplikacji lub zawarcia umowy z dostawcą. Jeżeli narzędzie przetwarza dane osobowe, administrator danych musi ocenić nie tylko bezpieczeństwo serwera czy szyfrowanie transmisji, ale również wpływ rozwiązania na prywatność, autonomię i prawa konkretnych osób. To właśnie jest praktyczny sens oceny skutków dla ochrony danych, czyli DPIA (Data Protection Impact Assessment). ^[2]

Problem nie sprowadza się wyłącznie do ryzyka wycieku danych. Model może tworzyć błędne profile osób, utrwalać stronniczość wynikającą z danych historycznych, sugerować nieuzasadnione decyzje albo utrudniać realizację prawa dostępu do danych. W przypadku generatywnej sztucznej inteligencji dochodzi jeszcze ryzyko, że pracownik wpisze do promptu za dużo informacji, w tym dane klientów, dane kandydatów, informacje finansowe lub poufne dane dotyczące zdrowia. ^[4]

Przykładowo dział HR może chcieć użyć AI do wstępnego sortowania aplikacji na stanowisko pracy. Jeżeli system nadaje kandydatom ocenę lub automatycznie odrzuca część zgłoszeń, organizacja powinna umieć wyjaśnić, na jakich danych opiera się proces, czy wynik podlega realnej kontroli człowieka oraz jak kandydat może zakwestionować niekorzystną decyzję. Sam zapis w regulaminie dostawcy, że narzędzie „wspiera zgodność”, nie rozwiązuje tych kwestii.

Dlaczego zgoda, umowa i ustawienia prywatności nie wystarczają

Częstym błędem jest założenie, że ocena skutków dla ochrony danych nie będzie potrzebna, skoro organizacja ma zgodę osoby, podstawę umowną albo aktywowała ustawienia ograniczające wykorzystanie danych przez dostawcę. Każdy z tych elementów może być ważny, ale odpowiada na inne pytanie. Podstawa prawna wyjaśnia, czy dane wolno przetwarzać. Umowa z dostawcą porządkuje relacje między stronami. Konfiguracja prywatności ogranicza wybrane ryzyka techniczne. DPIA natomiast ma ustalić, czy całe planowane przetwarzanie powoduje wysokie ryzyko dla praw i wolności osób oraz jak je ograniczyć przed rozpoczęciem operacji. ^[1]

Nie należy też utożsamiać oceny skutków z jednorazowym formularzem wypełnionym po wdrożeniu. Dokument przygotowany wyłącznie po to, by „był w dokumentacji RODO”, zwykle nie daje wartości. Nie zmieni już architektury rozwiązania, zakresu danych ani sposobu działania modelu. Dobra DPIA ma wpływać na decyzje zakupowe, projektowe i organizacyjne wtedy, gdy można jeszcze ograniczyć koszty oraz uniknąć zmian wymagających przebudowy gotowego systemu.

DPIA jako decyzja biznesowa, a nie przeszkoda dla projektu

Ocena skutków dla ochrony danych nie musi oznaczać wielotygodniowego audytu każdego narzędzia wykorzystującego algorytmy. Jej zakres powinien odpowiadać realnej skali ryzyka. Prosty asystent pomagający redagować ogólne materiały marketingowe, do którego nie trafiają dane osobowe, wymaga zupełnie innego podejścia niż system analizujący rozmowy z klientami, nagrania głosowe lub dane pracowników.

Dobrze przygotowana DPIA pozwala szybciej podjąć jedną z trzech decyzji: wdrożyć rozwiązanie w zaproponowanym kształcie, wdrożyć je po zastosowaniu konkretnych zabezpieczeń albo zrezygnować z danego scenariusza i wybrać mniej ingerującą alternatywę. Z perspektywy kosztów to korzystniejsze niż kupienie systemu, zasilenie go danymi, a następnie odkrycie, że nie da się spełnić obowiązków informacyjnych lub zapewnić odpowiedniej kontroli nad decyzjami algorytmu.

Dlaczego systemy AI tak często wymagają oceny skutków dla ochrony danych

Cechy AI, które podnoszą poziom ryzyka

Obowiązek przeprowadzenia DPIA nie wynika automatycznie z tego, że rozwiązanie nosi etykietę „AI”. Kluczowe jest prawdopodobieństwo wystąpienia wysokiego ryzyka dla praw i wolności osób fizycznych. Systemy sztucznej inteligencji często spełniają kryteria podwyższonego ryzyka, ponieważ potrafią analizować dane na dużą skalę, łączyć informacje z wielu źródeł i wyciągać wnioski, których osoba nie przekazała wprost.

Ryzyko rośnie szczególnie wtedy, gdy narzędzie tworzy profile osób, ocenia ich zachowanie, wiarygodność, efektywność, preferencje, sytuację ekonomiczną albo cechy osobiste. Znaczenie ma także kontekst. Ocena zainteresowań użytkownika w serwisie rozrywkowym i ocena kandydata do pracy mogą technicznie wykorzystywać podobne metody analityczne, lecz skutki dla osoby będą całkowicie inne.

Podwyższonego poziomu ostrożności wymagają systemy przetwarzające dane szczególnych kategorii, informacje o zdrowiu, dane biometryczne, wizerunek, głos, lokalizację lub dane dzieci. Podobnie jest wtedy, gdy AI prowadzi monitoring na większą skalę, obserwuje zachowania użytkowników w czasie albo łączy dane pozyskane z różnych usług.

Wsparcie człowieka a automatyczne rozstrzyganie spraw

Nie każda rekomendacja algorytmu jest decyzją podejmowaną wyłącznie w sposób zautomatyzowany. Różnica ma jednak znaczenie tylko wtedy, gdy człowiek rzeczywiście analizuje wynik i ma możliwość go zakwestionować. Pracownik, który mechanicznie akceptuje ocenę wygenerowaną przez system, nie zapewnia realnej kontroli. Sama obecność człowieka w interfejsie nie neutralizuje ryzyka.

Przy ocenie systemu trzeba ustalić, czy wynik AI przesądza o dostępie do pracy, kredytu, ubezpieczenia, świadczenia, usługi lub innej istotnej korzyści. Im bardziej automatyczna rekomendacja determinuje sytuację osoby, tym dokładniej należy opisać zasady ingerencji człowieka, kompetencje osób dokonujących weryfikacji oraz procedurę obsługi błędów i odwołań.

Kiedy nie należy czekać z rozpoczęciem DPIA

Ocena ryzyka powinna ruszyć zanim organizacja wybierze dostawcę, podpisze umowę, zasili środowisko produkcyjne danymi lub rozpocznie pilotaż na danych rzeczywistych. To nie oznacza, że każdy pomysł wymaga od razu kompletnej dokumentacji. Na etapie rozpoznania wystarczy krótka kwalifikacja ryzyka i mapa planowanego przypadku użycia. Jeżeli pojawiają się przesłanki wysokiego ryzyka, należy rozszerzyć analizę do pełnej DPIA.

Warto przeczytać również powiązany artykuł: Data poisoning – czy sabotaż modelu jest przestępstwem?.

Ryzykowny bywa także pozornie niewinny test na darmowym koncie. Gdy pracownik wkleja do publicznego narzędzia fragment korespondencji z klientem, CV kandydata albo opis sprawy reklamacyjnej, przetwarzanie danych osobowych już się rozpoczęło. Brak płatnej umowy lub formalnego wdrożenia nie oznacza braku obowiązków wynikających z RODO.

DPIA nie jest dokumentem zamkniętym na zawsze. Należy ją zaktualizować, gdy zmienia się cel przetwarzania, zakres danych, dostawca, sposób trenowania modelu, grupa osób objętych analizą albo skala projektu. Aktualizacji wymaga również sytuacja, w której pierwotnie narzędzie jedynie pomagało pracownikowi, a później zaczęło automatycznie podejmować lub istotnie wpływać na decyzje dotyczące osób.

Jak rozpocząć DPIA bez budowania kosztownego projektu dokumentacyjnego

Ustal właściciela procesu i minimalny skład zespołu

Za przeprowadzenie oceny skutków dla ochrony danych odpowiada administrator danych. W praktyce nie powinien jednak próbować wykonywać jej wyłącznie przez dział prawny, ochronę danych lub IT. Każda z tych osób zna jedynie fragment procesu. Biznes rozumie cel i skutki działania narzędzia, zespół techniczny zna architekturę oraz integracje, a osoba odpowiedzialna za ochronę danych pomaga ocenić zgodność i ryzyko dla osób.

Efektywny, niewielki zespół zwykle obejmuje:

• właściciela procesu biznesowego, który potrafi wyjaśnić, po co organizacji AI i jak będzie używana;
• osobę odpowiedzialną za ochronę danych lub compliance;
• przedstawiciela IT, bezpieczeństwa albo architektury systemów;
• przedstawiciela działu, który będzie korzystał z narzędzia na co dzień;
• w razie potrzeby osobę odpowiedzialną za zakupy, zarządzanie dostawcami lub bezpieczeństwo informacji.

Jeżeli w organizacji powołano inspektora ochrony danych, powinien on otrzymać możliwość przedstawienia opinii w sprawie DPIA. Nie oznacza to, że inspektor automatycznie „zatwierdza” każdy projekt albo przejmuje odpowiedzialność administratora. Jego zadaniem jest doradztwo i monitorowanie przestrzegania zasad ochrony danych, natomiast decyzję o wdrożeniu podejmuje administrator.

Zacznij od warsztatu mapującego, nie od rozbudowanego audytu

Przy ograniczonym budżecie rozsądne jest rozpoczęcie od krótkiego warsztatu roboczego. Jego celem nie jest omawianie całej technologii AI ani odtwarzanie dokumentacji producenta. Trzeba ustalić, co dzieje się z konkretną informacją od chwili jej pozyskania do chwili usunięcia, anonimizacji albo archiwizacji.

Dobry warsztat pozwala szybko odkryć problemy, których nie widać w materiałach sprzedażowych. Dostawca może deklarować wysokie standardy bezpieczeństwa, ale nie odpowie za organizację, czy pracownicy będą wpisywać do promptów pełne dane klientów, czy wyniki AI zostaną zapisane w systemie HR oraz kto będzie sprawdzał błędne klasyfikacje. Te elementy zależą od wdrażającej organizacji.

W małej firmie warsztat może zająć kilka godzin i zakończyć się prostą mapą procesu. W większej organizacji należy przygotować osobne spotkania dla procesu biznesowego, IT oraz dostawcy. Kosztowniejszy audyt zewnętrzny ma sens wtedy, gdy projekt obejmuje szczególnie wrażliwe dane, dużą skalę przetwarzania, złożone transfery danych lub decyzje o poważnych skutkach dla osób.

Zbierz fakty w jednym miejscu, zanim zaczniesz oceniać ryzyko

Po warsztacie nie warto od razu pisać długiego dokumentu. Najpierw należy uzupełnić podstawowy zestaw informacji o rozwiązaniu. Dzięki temu zespół nie będzie opierał DPIA na założeniach, prezentacji handlowej dostawcy ani deklaracjach typu „system nie przechowuje danych”, których nikt nie zweryfikował.

W praktyce wystarczy robocza karta procesu, zawierająca odpowiedzi na kilka konkretnych pytań:

• jaki problem biznesowy ma rozwiązać narzędzie i jaki jest dokładny cel przetwarzania danych;
• które osoby będą objęte procesem, na przykład klienci, kandydaci, pracownicy, użytkownicy aplikacji lub osoby kontaktujące się z organizacją;
• jakie dane trafiają do systemu, skąd pochodzą i które z nich są rzeczywiście potrzebne;
• czy dane są przekazywane w promptach, załącznikach, przez integrację API, import pliku lub automatyczne połączenie z innym systemem;
• jakie wyniki tworzy AI oraz czy są one zapisywane, wykorzystywane do oceny osoby lub przekazywane dalej;
• kto otrzymuje dostęp do danych wejściowych, wyników, logów i panelu administracyjnego;
• czy dostawca wykorzystuje dane do własnych celów, w tym do rozwijania lub trenowania modeli;
• gdzie dane są przetwarzane, przechowywane i skąd zapewniane jest wsparcie techniczne;
• jak długo przechowywane są prompty, wyniki, kopie zapasowe oraz logi bezpieczeństwa;
• jakie zabezpieczenia już istnieją, a które są dopiero planowane.

Najważniejsze jest rozdzielenie trzech rodzajów informacji: danych przekazywanych do narzędzia, danych powstających w wyniku działania AI oraz danych technicznych generowanych przy korzystaniu z usługi. Organizacja często analizuje wyłącznie prompt lub plik wejściowy, pomijając historię rozmów, identyfikatory użytkowników, metadane, logi API i oceny wygenerowane przez model. Tymczasem właśnie te elementy mogą przesądzać o rzeczywistym zakresie przetwarzania.

Nie przyjmuj deklaracji dostawcy bez przełożenia ich na proces

Dokumentacja dostawcy może potwierdzać szyfrowanie, certyfikaty bezpieczeństwa albo możliwość wyłączenia treningu na danych klienta. To ważne informacje, ale nie kończą analizy. Trzeba ustalić, czy dana funkcja jest dostępna w wybranym planie usługi, czy wymaga dodatkowej konfiguracji oraz kto po stronie organizacji potwierdzi jej uruchomienie.

Przykładowo dostawca może oferować skrócony okres retencji logów, lecz domyślne ustawienie konta nadal będzie przechowywało historię zapytań dłużej, niż potrzebuje tego organizacja. Może również zapewniać mechanizm kontroli dostępu, podczas gdy projekt zakłada używanie jednego wspólnego konta przez cały dział. W takim przypadku problem nie wynika z braku funkcji technicznej, lecz ze sposobu wdrożenia.

Przed zakończeniem części przygotowawczej warto zebrać umowę powierzenia przetwarzania danych lub równoważne postanowienia, opis podwykonawców, informacje o lokalizacji przetwarzania, zasady retencji oraz opis środków bezpieczeństwa. Jeżeli dostawca nie potrafi przekazać tych informacji w stopniu pozwalającym ocenić projekt, jest to istotny sygnał ryzyka zakupowego, a nie drobna formalność do wyjaśnienia po wdrożeniu.

Warto przeczytać również powiązany artykuł: Czy można opatentować architekturę sieci neuronowej?.

Ocena skutków krok po kroku: od opisu procesu do decyzji o wdrożeniu

1. Opisz rzeczywisty przebieg operacji, a nie tylko nazwę narzędzia

Pierwsza część właściwej DPIA powinna pokazywać, jak działa konkretny proces w organizacji. Sam zapis „wykorzystanie generatywnej AI do usprawnienia obsługi klienta” nie pozwala ocenić ryzyka. Trzeba opisać kolejne etapy: źródło danych, moment przekazania ich do systemu, sposób analizy, tworzenie wyniku, decyzję człowieka, zapis w systemach wewnętrznych oraz usunięcie danych. ^[3]

Opis powinien uwzględniać także sytuacje wyjątkowe. Należą do nich błędne przypisanie sprawy, wprowadzenie przez pracownika danych nieadekwatnych do celu, awaria integracji, dostęp administratora dostawcy, eksport wyników do pliku czy ręczne kopiowanie odpowiedzi z narzędzia do innego systemu. To właśnie na styku standardowego procesu i działań wykonywanych „na skróty” często pojawiają się największe luki.

Przydatne jest zapisanie procesu prostym schematem:

1. osoba przekazuje dane organizacji lub dane są pobierane z istniejącego systemu;
2. dane są wybierane, filtrowane albo przygotowywane do analizy;
3. narzędzie AI otrzymuje dane przez interfejs, prompt, plik lub integrację;
4. model tworzy odpowiedź, klasyfikację, rekomendację albo ocenę;
5. uprawniona osoba weryfikuje wynik i podejmuje dalsze działanie;
6. wynik jest zapisywany, przekazywany odbiorcy albo odrzucany;
7. dane i logi są usuwane zgodnie z ustalonym okresem przechowywania.

Nie trzeba tworzyć rozbudowanego diagramu architektury, jeśli proces jest prosty. Opis ma jednak pozwalać osobie niezwiązanej z projektem zrozumieć, które dane przemieszczają się między systemami i kto może mieć do nich dostęp.

2. Oceń konieczność i proporcjonalność zastosowanego rozwiązania

Kolejny etap dotyczy pytania, czy organizacja rzeczywiście potrzebuje wszystkich danych, funkcji i integracji przewidzianych w projekcie. Nie chodzi o ocenę przydatności biznesowej AI jako takiej, lecz o sprawdzenie, czy cel można osiągnąć przy mniejszej ingerencji w prywatność.

Warto zadać zespołowi kilka praktycznych pytań:

• czy model musi otrzymywać pełny dokument, czy wystarczy jego ograniczony fragment;
• czy można usunąć identyfikatory bez utraty funkcjonalności;
• czy wynik powinien dotyczyć konkretnej osoby, czy wystarczy analiza zbiorcza;
• czy konieczne jest zachowywanie pełnej historii promptów i odpowiedzi;
• czy integracja z systemem źródłowym musi działać automatycznie, czy na początku bezpieczniejszy będzie kontrolowany import;
• czy narzędzie musi generować ocenę punktową, czy wystarczy wskazanie informacji wymagających sprawdzenia przez pracownika.

Przykładem może być system wspierający dział jakości w analizie zgłoszeń. Jeśli celem jest wykrywanie powtarzających się problemów produktowych, organizacja może nie potrzebować imienia, numeru telefonu ani pełnej historii klienta. Często wystarczy pseudonimizowany identyfikator sprawy, treść zgłoszenia po ograniczeniu danych nadmiarowych oraz kategoria produktu.

Na tym etapie należy także sprawdzić, czy osoby otrzymają zrozumiałą informację o przetwarzaniu oraz czy organizacja potrafi obsłużyć ich prawa w praktyce. Jeżeli system tworzy ocenę, rekomendację lub profil, trzeba ustalić, czy można odnaleźć dane dotyczące konkretnej osoby, wyjaśnić wykorzystanie wyniku i skorygować błędne informacje.

3. Zidentyfikuj zagrożenia dla osób, a nie wyłącznie zagrożenia dla systemu

Ocena bezpieczeństwa IT i DPIA częściowo się pokrywają, ale nie są tym samym. W analizie skutków należy opisać, co może wydarzyć się osobie, której dane są przetwarzane. Wyciekanie danych jest jednym z ryzyk, lecz nie jedynym. Równie istotne mogą być niesprawiedliwa ocena, ograniczenie dostępu do usługi, ujawnienie informacji wrażliwych, błędne przypisanie cech do osoby lub brak możliwości zakwestionowania wyniku.

W przypadku AI warto rozważyć między innymi następujące zdarzenia:

• pracownik przekazuje do narzędzia więcej danych, niż przewiduje proces;
• dostawca lub jego podwykonawca uzyskuje dostęp do danych bez wystarczającej podstawy i kontroli;
• model generuje nieprawdziwą informację, która zostaje potraktowana jako fakt;
• system nieprawidłowo klasyfikuje osobę, a wynik wpływa na jej sytuację;
• kryteria działania rozwiązania powodują nieuzasadnione różnicowanie osób;
• osoba nie otrzymuje jasnej informacji o roli AI w procesie;
• organizacja nie potrafi ustalić, skąd pochodzi wynik ani kto podjął ostateczną decyzję;
• dane pozostają w logach, historii rozmów lub kopiach zapasowych dłużej, niż jest to uzasadnione.

Dla każdego zagrożenia należy ocenić prawdopodobieństwo jego wystąpienia oraz wagę możliwych konsekwencji. Ocena nie musi opierać się na skomplikowanej matematyce. Ważniejsze od pozornej precyzji jest uzasadnienie: dlaczego dane ryzyko uznano za niskie, średnie albo wysokie oraz jakie fakty potwierdzają tę ocenę.

4. Dobierz zabezpieczenia, które zmieniają sposób działania projektu

Środki ograniczające ryzyko powinny odpowiadać konkretnym problemom wykrytym w analizie. Ogólne stwierdzenie „stosujemy szyfrowanie i kontrolę dostępu” nie wystarczy, jeżeli ryzyko dotyczy błędnej rekomendacji modelu albo wpisywania nadmiarowych danych do promptów.

W zależności od procesu skuteczne mogą być między innymi:

• ograniczenie pól przekazywanych do modelu i automatyczne maskowanie wybranych identyfikatorów;
• wyłączenie wykorzystywania danych klienta do treningu, o ile dostawca oferuje taką opcję;
• skrócenie retencji historii rozmów, logów i plików wejściowych;
• role użytkowników oraz odrębne konta zamiast współdzielonych danych dostępowych;
• zatwierdzanie wyników AI przez osobę posiadającą odpowiednie kompetencje;
• instrukcja określająca, jakich danych nie wolno umieszczać w promptach;
• testy jakości modelu na reprezentatywnych przypadkach, w tym na przykładach błędnych i nietypowych;
• mechanizm eskalacji spraw, w których wynik AI jest niepewny lub może wywołać istotny skutek dla osoby;
• rejestrowanie decyzji człowieka i powodów odejścia od rekomendacji systemu;
• okresowe sprawdzanie, czy model nie zmienia jakości działania po aktualizacji narzędzia lub danych wejściowych.

Ważne, aby przy każdym zabezpieczeniu wskazać właściciela i termin wdrożenia. Środek zapisany w DPIA, ale nieprzypisany do konkretnej osoby lub zespołu, pozostaje jedynie deklaracją. Dobrą praktyką jest rozróżnienie zabezpieczeń koniecznych przed uruchomieniem od działań rozwojowych, które mogą zostać wykonane po starcie projektu.

5. Oceń ryzyko resztkowe i podejmij decyzję, której da się bronić

Po zastosowaniu planowanych środków należy ponownie ocenić ryzyko. Celem nie jest osiągnięcie zerowego ryzyka, ponieważ w praktyce jest to niemożliwe. Chodzi o ustalenie, czy pozostałe ryzyko jest akceptowalne w świetle celu projektu, skali przetwarzania i możliwych skutków dla osób.

Decyzja powinna być konkretna. Najczęściej przyjmuje jedną z następujących form:

• wdrożenie dopuszczone — ryzyko resztkowe jest odpowiednio ograniczone, a wymagane zabezpieczenia zostały wdrożone;
• wdrożenie warunkowe — projekt może ruszyć dopiero po spełnieniu jasno opisanych warunków, na przykład zmianie ustawień retencji, podpisaniu odpowiedniej umowy z dostawcą lub wdrożeniu kontroli człowieka;
• pilotaż o ograniczonym zakresie — rozwiązanie jest testowane bez pełnego zasilania danymi lub wobec węższej grupy, aby potwierdzić działanie zabezpieczeń;

Pytania od czytelników

Pytanie czytelnika

Czy testowanie narzędzia AI na prawdziwych danych wymaga wcześniejszej DPIA?

Odpowiedź redakcji: Jeżeli test obejmuje dane osobowe, należy rozpocząć od kwalifikacji ryzyka. Gdy przetwarzanie może powodować wysokie ryzyko dla praw i wolności osób, potrzebna jest pełna DPIA przed rozpoczęciem takiego testu.

Pytanie czytelnika

Czy korzystanie z darmowego narzędzia AI oznacza, że organizacja nie przetwarza danych osobowych?

Odpowiedź redakcji: Nie. Wklejenie do narzędzia danych klientów, kandydatów lub innych osób może już oznaczać rozpoczęcie przetwarzania danych osobowych, niezależnie od tego, czy usługa jest bezpłatna.

Pytanie czytelnika

Kto powinien uczestniczyć w przygotowaniu DPIA dla systemu AI?

Odpowiedź redakcji: W pracach warto uwzględnić właściciela procesu, osobę odpowiedzialną za ochronę danych lub compliance, przedstawiciela IT albo bezpieczeństwa oraz użytkowników narzędzia. W razie potrzeby należy zaangażować także zakupy i zarządzanie dostawcami.

Pytanie czytelnika

Czy obecność pracownika kontrolującego wynik AI zawsze oznacza realny nadzór człowieka?

Odpowiedź redakcji: Nie. Kontrola jest realna tylko wtedy, gdy pracownik rozumie wynik, ma kompetencje do jego zakwestionowania i może samodzielnie ocenić sprawę, zamiast mechanicznie akceptować rekomendację systemu.

Źródła

• [1] Urząd Ochrony Danych Osobowych – Kiedy trzeba przeprowadzić ocenę skutków dla ochrony danych? ↑
• [2] Urząd Ochrony Danych Osobowych – Zanim wdrożysz narzędzie AI, sprawdź czy jest ono zgodne z zasadami RODO ↑
• [3] Europejska Rada Ochrony Danych – Data protection impact assessment ↑
• [4] CNIL – Development of AI Systems: What should be checked? ↑