Model dostaje dokumenty zdrowotne, rekrutacyjne i finansowe, bo „może coś wnioskować”. Potem przypisuje ludziom kategorie na podstawie imienia i zachowania. To nie jest lepsza analiza. To nowe przetwarzanie danych i nowe ryzyko. Informacje o zdrowiu mogą należeć do szczególnych kategorii danych osobowych; dokumenty rekrutacyjne i finansowe nie stają się taką kategorią automatycznie, choć nadal mogą zawierać dane osobowe lub poufne. Proces powinien zaczynać się od pytania, czy jest w ogóle potrzebny.
Każdy przepływ danych osobowych wymaga oceny podstawy, minimalizacji i skutku, a szczególne kategorie danych podlegają dodatkowym warunkom. Nie zgaduj kategorii. Nie przenoś pełnych dokumentów do modelu dla wygody. Właściciel i prawnik oceniają, czy proces jest dozwolony.
Zacznij od potrzeby i celu
Zapisz, po co dane są wymagane i czy można wykonać zadanie bez nich. Analiza procesu nie zawsze wymaga danych zdrowotnych lub rekrutacyjnych. Model może pracować na zatwierdzonych polach lub fikcyjnych przypadkach.
Oceń, czy cel jest zgodny z pierwotnym źródłem. Nowa analiza i nowy model mogą zmieniać ocenę. Nie przenoś starej zgody automatycznie.
Przy danych stosuj zasady z artykułu o RODO przy AI. Minimalizacja zaczyna się przed wysłaniem.
Kategorie i dane wywnioskowane
Rozróżnij dane jawne, przypisane i wywnioskowane. Model może zgadywać płeć, pochodzenie, zdrowie, poglądy lub status z nazwy i zachowania. To wymaga osobnej oceny.
Nie używaj zgadywanych kategorii do decyzji i scoringu. W audycie wybranych narzędzi rekrutacyjnych w Wielkiej Brytanii z 2024 r. ICO opisało m.in. problemy z wnioskowaniem cech kandydatów. Raport nie bada generatywnej AI, a jego ustaleń nie należy automatycznie przypisywać każdemu modelowi. Nie traktuj takich wniosków jako pewnych faktów.
Przy scoringu stosuj zasady z artykułu o ryzyku klientów AI. Dane wywnioskowane mogą zmieniać skutek i podstawę.
Minimalny pakiet pól
Przygotuj tylko pola wymagane do zadania. Usuń nazwy, identyfikatory i fragmenty niepotrzebne. Nie wysyłaj pełnej historii dla jednego pytania. Ogranicz kopie robocze.
Przy fikcyjnym przykładzie zachowaj strukturę i trudność bez identyfikowania. Zmiana nazwy nie zawsze wystarcza. Kontekst może nadal identyfikować osobę.
Przy NDA stosuj zasady z artykułu o danych poufnych AI. Prawa i prywatność są osobnymi pytaniami.
Podstawa i rola prawa
Podstawę i dodatkowe warunki ocenia właściwa osoba. Model nie decyduje o nich. Nie przenoś podstaw z innego procesu lub produktu. Zapisz dokument i datę oceny.
Przy danych wrażliwych poproś o ocenę przed pierwszym przesłaniem. Nie przedstawiaj testu jako małego wyjątku. Użyj fikcyjnych danych zamiast produkcyjnych.
Przy prawie stosuj zasady z artykułu o AI Act dla freelancera. Ocena wymaga konkretnego procesu.
Model i odbiorcy
Zapisz dostawcę, plan, region, podwykonawców i retencję. Nie przenoś warunków prywatnego konta na firmowe. Każdy odbiorca może mieć inne reguły.
Nie przesyłaj danych do kolejnego modelu dla lepszej analizy bez oceny. Indeks, cache i logi tworzą nowe kopie. Ogranicz dostęp i role.
Przy podwykonawcach stosuj zasady z artykułu o odbiorcach AI. Mapa powinna obejmować wszystkich.
Odbiór skutku i decyzji
Opisz, jakie decyzje są podejmowane i jakie dane je zmieniają. Nie używaj zgadywanych kategorii jako powodu decyzji. Odbiór powinien obejmować skutek dla osoby i grupy.
Przy wysokim ryzyku wymagaj specjalisty i możliwości odwołania. Model nie powinien być jedynym źródłem decyzji. Człowiek powinien widzieć źródło i ograniczenia.
Warunki udziału osoby oceniającej przedstawia artykuł o człowieku w pętli AI. Przy danych szczególnie wrażliwych ogranicz jej dostęp do informacji potrzebnych do tej decyzji.
Retencja i usuwanie
Zapisz, jak długo dane są potrzebne i jakie kopie istnieją. Nie przechowuj pełnej historii dla ewentualnej analizy. Identyfikator i typ procesu wystarczą przy wielu zadaniach.
Przy usunięciu oceń źródło, indeks, cache, odpowiedzi i backup. Nie przedstawiaj usunięcia jednego pliku jako całego procesu. Restore nie powinien ich wskrzeszać.
Zakres kopii i sposób ich usunięcia pomaga uporządkować przewodnik o usuwaniu danych AI. Uwzględnij także wnioski lub odpowiedzi powstałe na podstawie danych źródłowych.
Przykład: wniosek o zdrowiu z historii zgłoszeń
Wyobraź sobie asystenta, który z opisu nieobecności wnioskuje o stanie zdrowia klienta, choć zadanie polega na zmianie terminu. Taki wniosek może ujawnić informację, której proces nie potrzebuje, i wymaga osobnej oceny kontekstu oraz podstaw przetwarzania.
Ogranicz wejście do danych potrzebnych do ustalenia terminu, a w próbie z fikcyjną wiadomością sprawdź, czy wynik nie tworzy dodatkowej kategorii. Jeżeli pojawi się w logu lub odpowiedzi, oceń zakres kopii i odbiorców.
Ryzyko wnioskowania o osobach w zatrudnieniu omawia również artykuł o rekrutacji AI. Sama etykieta nadana przez model nie dowodzi, że informacja jest prawdziwa.
Przykład: dokument zdrowotny w analizie
Model otrzymuje pełny dokument zdrowotny dla jednego pola. Nie przenoś go bez oceny. Przygotuj minimalny pakiet lub fikcyjny przypadek z tym samym formatem.
Oceń, czy analiza jest potrzebna i jakie dane są wymagane. Ogranicz role i kopie. Nie przechowuj oryginału dla przyszłych analiz bez decyzji.
Przy RAG stosuj zasady z artykułu o danych poufnych i uprawnieniach. Model nie jest domyślnym odbiorcą.
Kiedy zatrzymać proces
Zatrzymaj przy niejasnej podstawie, danych wrażliwych, nowym skutku, niekontrolowanych kopiach i zgadywanych kategoriach. Nie przesyłaj więcej danych dla sprawdzenia. Ogranicz proces.
Przy zatrzymaniu zapisz identyfikator operacji, wersję konfiguracji oraz miejsca przechowywania wyniku. Ogranicz dostęp do dowodów i przekaż ocenę zakresu osobie odpowiedzialnej za ochronę danych.
Po zmianie sprawdź na fikcyjnych danych, czy model nie otrzymuje zbędnych pól ani nie tworzy niezamówionej kategorii. Właściciel procesu potwierdza wynik przed powrotem do zatwierdzonego zastosowania.
Oddziel dane szczególnej kategorii od zwykłej poufności
Słowo „wrażliwe” bywa używane szerzej niż pojęcia RODO. Informacja o cenie oferty może być tajemnicą firmy, a informacja o zdrowiu może należeć do szczególnych kategorii danych osobowych. Jeden dokument potrafi zawierać oba rodzaje. Przy inwentaryzacji nazwij więc konkretną informację i osobę odpowiedzialną za ocenę, zamiast przypisywać całemu plikowi jedną etykietę.
Sprawdź również pola, które nie wyglądają na diagnozę, lecz w zestawieniu mogą ujawnić stan zdrowia albo inne szczególnie chronione informacje. Nie zakładaj, że usunięcie nazwiska zawsze pozbawia rekord możliwości identyfikacji. Ocena zależy od pozostałych danych i dostępnego kontekstu.
Przykładowa tabela przed przekazaniem modelowi
Zespół rozważa analizę zgłoszeń dotyczących dostępności. W pierwszej kolumnie wpisuje cel: wykrycie przeszkód w formularzu. W drugiej wymienia planowane pola: opis błędu, rodzaj urządzenia i adres e-mail. W trzeciej wskazuje, co faktycznie jest potrzebne do decyzji projektowej. Adres kontaktowy może pozostać w systemie obsługi, a do analizy trafić numer zgłoszenia i fragment opisu po kontroli danych.
Jeżeli opis zawiera informację o stanie zdrowia, nie wystarczy automatycznie zastąpić jej słowem „inne”. Osoba odbierająca próbkę powinna sprawdzić, czy opis problemu nadal pozwala go naprawić i czy nie utracono ważnego kontekstu dostępności. Test na fikcyjnym materiale pozwoli ustalić reguły przed pracą na zgłoszeniach klientów.
Ogranicz także wnioski modelu
Polecenie „wywnioskuj chorobę z opisu” tworzy inny problem niż klasyfikacja błędu technicznego. Zapisz, jakich wniosków system nie ma formułować i jak powinien postąpić, gdy nie może przydzielić zgłoszenia bez oceny człowieka. Właściciel procesu sprawdza też, czy kategorie wyjściowe nie zastępują w praktyce informacji, której celowo nie zbierano.
Przykładowy wynik testowy powinien zawierać kategorię problemu, wskazanie brakujących danych i prośbę o ręczny odbiór. Nie musi zawierać oceny osoby. Przy pomyłce zachowaj wersję reguły i przypadek testowy bez kopiowania oryginalnego zgłoszenia do niekontrolowanego zestawu.
Decyzja przed uruchomieniem
Wspólnie z osobą właściwą do oceny prawnej ustal podstawę przetwarzania z art. 6 RODO. Jeżeli proces obejmuje szczególne kategorie danych, sprawdź również, czy zachodzi odpowiedni wyjątek z art. 9 ust. 2. Sprawdź, czy rodzaj i skala planowanego przetwarzania wymagają oceny skutków dla ochrony danych. Samo użycie AI nie rozstrzyga tego automatycznie; liczy się proces i prawdopodobne ryzyko dla osób.
Zapisz wariant bez wysyłania danych do modelu oraz konsekwencje jego wyboru. Może okazać się wolniejszy, ale wystarczający przy niewielkiej liczbie zgłoszeń. Jeżeli nie można uzasadnić celu, zakresu i dostępu, zatrzymaj przekazanie materiału do czasu wyjaśnienia.
Czy agregat rzeczywiście wystarczy
Załóżmy, że kierownik produktu chce poznać najczęstsze przeszkody zgłaszane przez użytkowników. Do decyzji o poprawieniu formularza może wystarczyć liczba zgłoszeń o błędnym kontrastowaniu, niedostępnej etykiecie lub przerwanym zapisie. Nie musi otrzymać pełnych historii konkretnych osób. Przy małych grupach nawet zestawienie zbiorcze może jednak wskazywać pojedynczą osobę, jeżeli zawiera rzadką kombinację cech.
Ustal minimalny poziom szczegółu z właścicielem danych i sprawdź go na przykładowym raporcie. Jeżeli raport nie pozwala rozpoznać przyczyny błędu, bezpieczniejszym rozwiązaniem może być dostęp wybranej osoby do źródła niż kopiowanie całej bazy do kolejnych narzędzi. Przy każdym przekazaniu wskaż cel i odbiorcę.
Nie traktuj danych wygenerowanych z prawdziwych rekordów automatycznie jako anonimowych. Sprawdź metodę ich powstania oraz możliwość odtworzenia informacji o osobie. Jeżeli nie masz odpowiedniego sposobu oceny, użyj ręcznie wymyślonych przykładów do testowania interfejsu i zachowaj prawdziwe przypadki w kontrolowanym środowisku.
Zachowaj wynik tej analizy razem z opisem celu, a nie wyłącznie w wiadomości do dostawcy. Przy kolejnym zastosowaniu wróć do konkretnych pól oraz odbiorców. Zgoda na wcześniejszy raport i techniczna możliwość jego odtworzenia nie rozstrzygają same, czy nowy zakres danych jest potrzebny.
Sprawdź jeden przepływ przed przekazaniem danych
Wybierz fikcyjny formularz, w którym klient opisuje problem, i narysuj drogę wiadomości od przesłania do decyzji pracownika. Zaznacz pola widoczne dla modelu, logów, dostawcy oraz osoby odbierającej wynik. Następnie usuń z próbki informacje, które nie są potrzebne do zadania, i porównaj, czy proces nadal daje użyteczną odpowiedź. Próbka jest przykładem testowym, a nie dowodem działania konkretnego dostawcy.
Jeżeli formularz może zawierać informacje o zdrowiu lub inne dane szczególnej kategorii, zapisz osobno cel ich użycia, podstawę oraz ocenę ograniczeń z osobą odpowiedzialną za ochronę danych. Samo zastąpienie imienia identyfikatorem nie przesądza, że informacji nie można przypisać osobie. Sprawdź również, czy model nie tworzy niepotrzebnych wniosków o cechach, o które proces nie powinien pytać.
Przeprowadź próbę z brakiem danych i z treścią wymagającą ludzkiego odbioru. Model powinien wskazać brak informacji, a reguła systemu powinna określać dalszą ścieżkę. Nie traktuj wyniku modelu jako dowodu prawidłowej kwalifikacji sytuacji osoby. Zachowaj identyfikator próby, wersję konfiguracji i wynik kontroli bez kopiowania wrażliwej treści do raportu.
Po zmianie dostawcy, celu lub rodzaju dokumentu wróć do mapy przepływu. Porównaj nowe pola i odbiorców z poprzednią decyzją, sprawdź retencję oraz możliwość zatrzymania procesu. Przy nierozstrzygniętej podstawie lub nieznanym odbiorcy nie przekazuj rzeczywistych danych do czasu wyjaśnienia.
Zapisz również, kto ma dostęp do błędnych odpowiedzi i czy można je usunąć z kolejki roboczej. Jeśli zespół potrzebuje przykładu do diagnozy, przygotuj dane syntetyczne odtwarzające problem. Nie przesyłaj pełnej wiadomości do kolejnego narzędzia tylko dlatego, że szybciej przygotuje podsumowanie.
Do uporządkowania odpowiedzialności służy Aeneia Audit, a przykładową strukturę mapy opisuje rejestr przepływu danych Aeneia Signal.
Sprawdź nas. To zdrowe.
Temat zmienia się szybko. Linki prowadzą do źródeł pierwotnych i stron, na których możesz zweryfikować kontekst.
