Awizacja a RODO: dane kierowcy w systemie
System awizacji z definicji przetwarza dane osób fizycznych - kierowców, którzy wjeżdżają na teren zakładu. To znaczy, że wdrożenie jest także decyzją o przetwarzaniu danych osobowych, a nie wyłącznie projektem logistycznym.
Dane kierowcy w systemie awizacyjnym - imię i nazwisko, numer rejestracyjny pojazdu, czasem numer dokumentu - są danymi osobowymi i podlegają RODO. Administratorem jest zwykle zakład, który prowadzi obiekt, dostawca oprogramowania działa jako podmiot przetwarzający na podstawie umowy powierzenia, a przewoźnik pozostaje odrębnym administratorem danych swoich pracowników.
Zastrzeżenie: to opis praktyki wdrożeniowej, a nie porada prawna. Konkretne rozstrzygnięcia - podstawa prawna, zakres danych, okresy retencji - wymagają konsultacji z inspektorem ochrony danych albo prawnikiem po stronie zakładu.
Jakie dane w ogóle się pojawiają
Typowe zgłoszenie awizacyjne zawiera dane firmowe - przewoźnika, kontrahenta, numer zamówienia - oraz dane, które dotyczą konkretnej osoby: imię i nazwisko kierowcy, numer telefonu, numery rejestracyjne ciągnika i naczepy. Na bramie dochodzą czasem numer dokumentu tożsamości albo prawa jazdy, podpis, a przy systemach rozpoznawania tablic również obraz z kamery i znacznik czasu przejazdu.
| Dane | Gdzie powstają | Charakter |
|---|---|---|
| Nazwa przewoźnika, NIP, numer zamówienia | Formularz zgłoszenia | Dane firmowe, poza zakresem RODO |
| Imię, nazwisko i telefon kierowcy | Formularz zgłoszenia | Dane osobowe |
| Numer rejestracyjny ciągnika i naczepy | Formularz, odczyt LPR | Dane osobowe w powiązaniu z kierowcą |
| Numer dokumentu tożsamości, podpis | Stanowisko bramy | Dane osobowe o podwyższonym ryzyku |
| Obraz z kamery, znacznik czasu przejazdu | System LPR | Dane osobowe, informacja o lokalizacji |
Numer rejestracyjny sam w sobie bywa traktowany jako dana osobowa, gdy da się go powiązać z osobą - a w awizacji da się, bo w tym samym rekordzie jest nazwisko kierowcy. Ten sam wniosek dotyczy odczytów z systemu LPR: automatyczny odczyt tablicy zapisany razem ze zgłoszeniem tworzy zbiór danych o przemieszczaniu się konkretnych osób.
Kto jest kim w tym układzie
Zakład prowadzący obiekt decyduje, po co zbiera dane i na jak długo - jest administratorem. Dostawca systemu przetwarza je w imieniu zakładu, więc potrzebna jest umowa powierzenia przetwarzania z określonym zakresem, celem i zasadami usuwania danych po zakończeniu współpracy. Przewoźnik przekazuje dane swoich pracowników i pozostaje ich administratorem - to on ma obowiązek poinformować kierowcę, że jego dane trafią do systemu odbiorcy.
W praktyce najczęściej brakuje trzeciego ogniwa. Kierowca dowiaduje się o przetwarzaniu dopiero na bramie, a klauzula informacyjna wisi tam, gdzie nikt jej nie czyta. Rozwiązaniem jest umieszczenie informacji w samym procesie zgłoszenia - w formularzu, który wypełnia przewoźnik, i na przepustce wydawanej kierowcy.
Na jakiej podstawie
Zgoda kierowcy jest tu podstawą najsłabszą i w praktyce pozorną - trudno mówić o dobrowolności, gdy odmowa oznacza brak wjazdu. Wdrożenia opierają się zwykle na wykonaniu umowy (dostawa realizowana dla kontrahenta) albo na prawnie uzasadnionym interesie administratora: bezpieczeństwie obiektu, kontroli dostępu i ochronie mienia. Ten drugi wymaga udokumentowanego testu równowagi - zapisania, dlaczego interes zakładu przeważa nad prywatnością kierowcy przy tym konkretnym zakresie danych. Brzmienie przepisów podaje tekst rozporządzenia 2016/679.
Minimalizacja: najczęstszy błąd wdrożenia
Systemy awizacyjne bywają konfigurowane zachłannie: skan dowodu osobistego „na wszelki wypadek”, PESEL w polu tekstowym, zdjęcie kierowcy przy każdym wjeździe. Każde takie pole trzeba uzasadnić celem, a nie wygodą. Jeśli celem jest identyfikacja pojazdu, wystarczy numer rejestracyjny. Jeśli kontrola dostępu - imię, nazwisko i numer zgłoszenia. Skan dokumentu tożsamości rzadko bywa konieczny, a jego przechowywanie tworzy ryzyko nieproporcjonalne do korzyści.
Dobrą praktyką jest przegląd formularza pole po polu przed uruchomieniem. Cztery pytania wystarczą, żeby rozstrzygnąć los każdego pola:
- Do czego służy - czy da się wskazać proces, który bez tego pola się zatrzyma.
- Kto je widzi - czy dostęp można zawęzić do jednej roli zamiast wszystkich użytkowników.
- Jak długo żyje - czy pole ma własny okres retencji, czy dziedziczy po całym zgłoszeniu.
- Co się stanie bez niego - czy brak danych blokuje wjazd, czy tylko utrudnia statystykę.
Konfigurację pól opisuje aplikacja do zarządzania przepustkami, a zakres samego zgłoszenia - dane wymagane do awizacji.
Rozdział dostępu: co widzi brama, a co dyspozytura
Ochrona na bramie potrzebuje danych pojazdu, który właśnie podjeżdża, a nie całej historii wjazdów. Magazyn potrzebuje harmonogramu, a nie numerów dokumentów. Rozdzielenie tych widoków jest pracą konfiguracyjną, nie deklaracją w polityce - w systemie sprowadza się do uprawnień przypisanych roli.

Warto zwrócić uwagę na dwa przełączniki, które w kontekście danych osobowych ważą najwięcej. Zgoda na eksport decyduje o tym, czy użytkownik może wyprowadzić zbiór poza system - a arkusz pobrany na pulpit przestaje podlegać jakiejkolwiek kontroli dostępu. Pole akceptowanych adresów IP zawęża logowanie do sieci zakładu, co bywa prostszym zabezpieczeniem niż rozbudowana polityka haseł. Hierarchię uprawnień opisuje VSS.net, a zakres widoku bramy - stanowisko ochrony.
Reguła konfiguracji. Konto serwisowe dostawcy i konto administratora zakładu to dwie różne role. Wspólne konto techniczne, z którego korzystają obie strony, uniemożliwia ustalenie, kto wykonał operację na danych - a to pierwsza rzecz, o którą pyta się po incydencie.
Retencja: od deklaracji do mechanizmu
Okres przechowywania musi być ustalony i faktycznie egzekwowany - deklaracja w polityce, po której dane leżą w bazie latami, jest gorsza niż jej brak. Warto rozdzielić dwa okresy: krótki dla danych operacyjnych i dłuższy dla zanonimizowanych danych statystycznych, z których liczy się wskaźniki terminowości. Statystyka nie potrzebuje nazwiska.
Mechanicznie wygląda to inaczej, niż sugeruje słowo „usuwanie”. Kasowanie wiersza zgłoszenia zabiera też historię wjazdów potrzebną do raportów, więc w praktyce stosuje się anonimizację: zadanie cykliczne nadpisuje pola osobowe wartością pustą, zostawiając znaczniki czasu i identyfikator obiektu. Operacja idzie partiami po kilka tysięcy wierszy, bo jedna transakcja obejmująca pół roku historii eskaluje blokadę na całą tabelę i zatrzymuje obsługę bramy na czas jej trwania. Jeśli kopie zapasowe też podlegają retencji, trzeba ustalić ich okres osobno - anonimizacja w bazie produkcyjnej nie sięga taśm sprzed miesiąca.
Miejsce przechowywania danych bywa osobnym tematem rozmowy z inspektorem ochrony danych. Różnice między wariantami opisuje chmura czy własny serwer.
Najczęściej zadawane pytania
Czy numer rejestracyjny pojazdu jest daną osobową
Zależy od kontekstu. Sam numer w oderwaniu od innych informacji identyfikuje pojazd, a nie osobę. W systemie awizacji leży jednak w tym samym rekordzie co imię i nazwisko kierowcy, więc powiązanie z osobą istnieje i cały zestaw podlega ochronie. Ten sam wniosek dotyczy odczytów z kamer LPR.
Kto jest administratorem danych kierowcy w systemie awizacji
Zakład, który prowadzi obiekt i decyduje o celu oraz zakresie przetwarzania. Dostawca oprogramowania działa jako podmiot przetwarzający na podstawie umowy powierzenia. Przewoźnik pozostaje odrębnym administratorem danych swoich pracowników i to on ma obowiązek poinformować kierowcę o przekazaniu danych odbiorcy.
Czy zgoda kierowcy wystarczy jako podstawa przetwarzania
W praktyce jest podstawą najsłabszą, bo odmowa oznacza brak wjazdu, a więc trudno mówić o dobrowolności. Wdrożenia opierają się zwykle na wykonaniu umowy albo na prawnie uzasadnionym interesie administratora, przy czym ten drugi wymaga udokumentowanego testu równowagi.
Jak długo trzymać dane ze zgłoszeń awizacyjnych
Okres ustala administrator i zapisuje go w polityce, a system ma go egzekwować automatycznie. Rozsądnie jest rozdzielić krótki okres dla danych operacyjnych od dłuższego dla danych statystycznych po anonimizacji - raport terminowości nie potrzebuje nazwiska kierowcy ani numeru dokumentu.
Czy usuwanie danych po okresie retencji może zakłócić pracę systemu
Może, jeżeli zadanie czyszczące działa jedną transakcją na całym zbiorze. Blokada eskaluje wtedy do poziomu tabeli i wstrzymuje zapis nowych zgłoszeń. Poprawnie skonfigurowane zadanie przetwarza dane partiami po kilka tysięcy wierszy, poza godzinami szczytu na bramie.
Co powinna zawierać umowa powierzenia z dostawcą systemu
Zakres i kategorie danych, cel przetwarzania, listę podwykonawców z prawem sprzeciwu, zasady zgłaszania naruszeń oraz sposób postępowania z danymi po zakończeniu współpracy. Osobno warto opisać, kto i na jakich kontach wykonuje prace serwisowe na bazie produkcyjnej.
Słownik pojęć
Pozostałe pojęcia z obsługi transportu zbiera słownik YMS.
- AAdministrator danych
- Podmiot, który decyduje o celach i sposobach przetwarzania danych osobowych - w awizacji zwykle zakład prowadzący obiekt.
- PPodmiot przetwarzający
- Podmiot przetwarzający dane w imieniu administratora na podstawie umowy powierzenia, bez własnego celu przetwarzania.
- MMinimalizacja danych
- Zasada zbierania wyłącznie danych niezbędnych do osiągnięcia określonego celu, stosowana przy projektowaniu formularza zgłoszenia.
- TTest równowagi
- Udokumentowana ocena, czy prawnie uzasadniony interes administratora przeważa nad prawami osoby, której dane dotyczą, przy danym zakresie przetwarzania.
- RRetencja
- Okres, przez jaki dane pozostają w systemie, po którym są usuwane albo anonimizowane przez zadanie działające automatycznie.
- AAnonimizacja
- Trwałe usunięcie powiązania rekordu z osobą przez nadpisanie pól osobowych, przy zachowaniu danych liczbowych i czasowych na potrzeby statystyki.