Rozeta

Zabezpieczenia projektu

Bezpieczeństwo, RODO i kontrola człowieka

Ramy pytań i dowodów potrzebnych przed pilotażem: od ról i celu przetwarzania po retencję, dostęp, ocenę ryzyka, audyt i bezpieczne zakończenie.

Role

Role wynikają z rzeczywistych decyzji o danych

Przed udostępnieniem danych trzeba ustalić, kto określa cele i sposoby przetwarzania, kto działa na udokumentowane polecenie oraz którzy dostawcy uczestniczą w łańcuchu. Nazwa produktu ani zapis w prezentacji nie rozstrzygają tych ról; decyduje konkretny model organizacyjny i umowny.

KOD.AI sp. z o.o. jest organizacją rozwijającą projekt Rozeta dla Mieszkańców. Ta strona nie ustanawia KOD.AI administratorem, podmiotem przetwarzającym ani współadministratorem dla przyszłego pilotażu. Role, instrukcje, odpowiedzialności i punkty kontaktu muszą zostać ocenione i zapisane dla danego zakresu.

  • Właściciel celu operacyjnego i podstawa udostępnienia każdego zbioru danych.
  • Udokumentowane instrukcje dla podmiotu przetwarzającego i lista dalszych podmiotów.
  • Odpowiedzialność za żądania osób, incydenty, zmiany celu i zakończenie współpracy.

Zakres danych

Najpierw cel, potem najmniejszy potrzebny zbiór

Cel powinien być opisany jako konkretne zadanie, na przykład ocena jakości klasyfikacji jednej kolejki w trybie cienia. Ogólne hasło „rozwój AI” nie wyjaśnia, które pola są potrzebne ani kiedy należy je usunąć. Nowy sposób użycia danych wymaga ponownej oceny, a nie cichego rozszerzenia zakresu.

Minimalizacja obejmuje zarówno dane przekazane do analizy, jak i treść logów, kopii, eksportów oraz przykładów używanych do kontroli jakości. Gdy wystarcza pseudonim, kategoria lub przybliżona lokalizacja, pełne dane identyfikujące nie powinny trafiać do danego etapu procesu.

  • Mapa pól łącząca każde pole z celem, odbiorcą i okresem przechowywania.
  • Redakcja lub pseudonimizacja przed przekazaniem danych do środowiska pilotażowego.
  • Zakaz wykorzystywania danych pilotażowych do innych celów bez odrębnej oceny i decyzji.

Kontrole

Retencja i dostęp muszą działać w praktyce

Okres przechowywania należy ustalić osobno dla danych źródłowych, wyników, dzienników audytowych, nagrań, kopii zapasowych i materiałów do analizy błędów. Sam zapis w polityce nie wystarcza: potrzebny jest mechanizm usunięcia oraz dowód, że obejmuje eksporty i środowiska pomocnicze.

Dostęp powinien być nadawany według roli, zatwierdzany przez właściciela danych, okresowo przeglądany i odbierany po zmianie obowiązków. Konta współdzielone utrudniają audyt. Dostęp uprzywilejowany wymaga silnego uwierzytelnienia, rejestracji operacji i procedury awaryjnej.

  • Macierz uprawnień dla danych źródłowych, wyników, konfiguracji i logów.
  • Wersjonowany harmonogram retencji z właścicielem i sposobem bezpiecznego usunięcia.
  • Rejestr podmiotów, lokalizacji przetwarzania, transferów i technicznych środków ochrony.
  • Test odtworzenia oraz test usunięcia wykonane przed danymi produkcyjnymi.

DPIA i AI

Ocena ryzyka poprzedza szersze użycie

Zespół odpowiedzialny za wdrożenie powinien ocenić, czy planowane przetwarzanie wymaga oceny skutków dla ochrony danych (DPIA), a następnie udokumentować tę decyzję. Zakres zależy między innymi od rodzaju danych, skali, monitorowania, osób objętych procesem i możliwych konsekwencji błędu.

Oddzielnej analizy wymaga kwalifikacja rozwiązania na gruncie unijnego AI Act oraz obowiązki związane z konkretnym sposobem użycia. Nie należy przypisywać systemowi kategorii wyłącznie na podstawie nazwy technologii. Zmiana celu, danych, modelu lub poziomu automatyzacji powinna uruchamiać ponowny przegląd ryzyka.

  • Opis przepływu danych, interesariuszy, zagrożeń i środków ograniczających ryzyko.
  • Ocena skutków błędnej klasyfikacji, przeoczenia, fałszywego alarmu i niedostępności usługi.
  • Decyzja właściciela ryzyka oraz warunki, których niespełnienie blokuje uruchomienie.

Nadzór

Człowiek potrzebuje informacji i realnej możliwości zmiany

Nadzór nie polega na samym wyświetleniu wyniku operatorowi. Osoba odpowiedzialna powinna rozumieć znaczenie pola, widzieć poziom niepewności i dane źródłowe potrzebne do oceny, móc poprawić lub odrzucić rekomendację oraz wiedzieć, kiedy eskalować sprawę.

Dziennik powinien łączyć wersję konfiguracji, czas operacji, źródło, wynik, korektę i rolę użytkownika. Nie powinien gromadzić większej ilości treści niż wymaga kontrola. Dostępna ścieżka wyjaśnienia i zakwestionowania wyniku musi odpowiadać rzeczywistemu wpływowi systemu na osobę.

  • Wersjonowanie taksonomii, progów, instrukcji i wdrożonego wariantu systemu.
  • Możliwość wyłączenia automatycznej rekomendacji bez zatrzymania podstawowej usługi.
  • Przegląd korekt, różnic między grupami i przypadków, w których operator nie miał dość informacji.

Gotowość

Bezpieczne zakończenie jest częścią projektu

Plan pilotażu powinien obejmować zgłoszenie i obsługę incydentu, komunikację do właściwych ról, wyłączenie integracji oraz odtworzenie bezpiecznego procesu ręcznego. Brak wymaganej konfiguracji, uprawnienia lub połączenia powinien zatrzymać daną funkcję i pokazać błąd, a nie uruchamiać nieuzgodniony zamiennik.

Na zakończenie zespół uzgadnia zwrot lub usunięcie danych, zachowanie wymaganych zapisów, odebranie dostępów i udokumentowanie wyniku. Te czynności obowiązują także wtedy, gdy pilotaż nie przechodzi do kolejnego etapu.

  • Ćwiczenie obsługi incydentu i lista kontaktów przed rozpoczęciem pracy na danych.
  • Kryteria zatrzymania związane z bezpieczeństwem, prywatnością i jakością nadzoru.
  • Protokół zakończenia obejmujący dane, konta, klucze, kopie i dokumentację.

Źródła

Podstawa do dalszej oceny

Poniższe materiały są źródłami pierwotnymi. Nie zastępują analizy prawnej, oceny ryzyka ani uzgodnień właściwych dla konkretnego wdrożenia.