Jak zbudować zestaw danych do wizji komputerowej w fabryce i zadbać o RODO oraz BHP

Kontekst biznesowy: po co w ogóle budować zestaw danych w fabryce

Typowe zastosowania wizji komputerowej w przemyśle

Wizja komputerowa w fabryce najczęściej nie zaczyna się od „sztucznej inteligencji” jako takiej, ale od bardzo przyziemnych problemów: zbyt dużo braków jakościowych, przestoje, wypadki, stracony czas na ręczne inspekcje. Zestaw danych z kamer przemysłowych jest tylko środkiem do rozwiązania tych problemów.

Najczęstsze scenariusze, które wprost determinują, jakiego rodzaju dane trzeba zbudować:

• Kontrola jakości – wykrywanie wad produktów, nieprawidłowych etykiet, brakujących elementów, zarysowań, zabrudzeń, błędnego montażu. Zazwyczaj kamery są skierowane na produkt, a ludzie pojawiają się w kadrze sporadycznie lub wcale.
• Bezpieczeństwo pracy (BHP) – wykrywanie braku kasku, kamizelki, rękawic, obecności ludzi w strefach niebezpiecznych, nieprawidłowej pozycji ciała przy pracy z maszynami. Tu obraz bardzo często zawiera sylwetki pracowników, a więc wchodzi w zakres RODO.
• Logistyka i przepływ materiałów – śledzenie palet, wózków widłowych, kontenerów, oznaczeń na paczkach, wykorzystanie przestrzeni magazynowej. Sylwetki pracowników są zwykle tłem, ale nadal mogą być rozpoznawalne.
• Utrzymanie ruchu – obserwacja maszyn i linii, wykrywanie nienaturalnych wibracji, wycieków, dymu, iskier, nieprawidłowego ruchu taśm. Tu łatwiej o „czyste” dane bez osób, ale często kamery są w strefach, gdzie ludzie się przemieszczają.

Każdy z tych scenariuszy wymaga innego sposobu kadrowania, innych metadanych i innych polityk retencji nagrań. Jednocześnie każdy inaczej „dotyka” obszaru ochrony danych osobowych i przepisów BHP.

PoC kontra system produkcyjny: różne wymagania wobec danych

PoC (proof of concept, szybki dowód wykonalności) zwykle powstaje z kilku godzin nagrań lub kilkuset zdjęć, zebranych „jak się udało” – byleby model coś zobaczył i dało się wykazać, że w ogóle działa. Na tym etapie rzadko myśli się o RODO, retencji czy formalnych procedurach BHP przy montażu kamery. To błąd, który mści się później.

System produkcyjny wymaga czegoś zupełnie innego:

• Skalowalności – dane muszą odzwierciedlać realną zmienność środowiska: różne zmiany, różne partie surowców, inne oświetlenie, różne zachowania ludzi.
• Powtarzalności – sposób zbierania danych musi być możliwy do odtworzenia po roku, gdy zmieni się linia, produkt lub stanowisko.
• Udowadnialnej zgodności – ktoś zada pytanie: „Czy ten system jest zgodny z RODO? Czy montaż kamery był zgodny z BHP? Jakie były podstawy prawne?” i trzeba będzie pokazać dokumenty, nie tylko slajdy.
• Bezpiecznej eksploatacji – kamera, okablowanie, serwery i prace montażowe nie mogą generować dodatkowego ryzyka dla ludzi na hali.

W PoC można jeszcze przymknąć oko na pewne uproszczenia. W systemie produkcyjnym każde naruszenie procedur (np. montaż kamery bez oceny ryzyka BHP, zbyt szeroki monitoring ludzi bez podstawy prawnej) oznacza realne ryzyko prawne i wizerunkowe.

Jak dane ograniczają i kształtują możliwości modelu

Model wizji komputerowej „widzi” tyle, ile nauczy się z danych. Granice tego, co potrafi, są bezpośrednio zależne od tego, co jest w zestawie danych. Jeśli np. w nagraniach nie ma ludzi w części kadru, bo zostało to wycięte ze względu na RODO, model nie będzie w stanie nauczyć się relacji między pozycją operatora a produktem.

Najważniejsze zależności między danymi a modelem:

• Zakres klas i zdarzeń – jeśli model ma wykrywać 5 rodzajów wad, w danych muszą być zdjęcia pokazujące wszystkie te wady w różnych wariantach i kontekstach. To samo dotyczy zachowań BHP (np. różne typy kasków, różne sposoby „braku kasku”).
• Warunki środowiskowe – modele są wrażliwe na oświetlenie, refleksy, kurz, dym, kondensację pary. Zestaw danych musi obejmować te warunki, bo inaczej system będzie działał świetnie w dzień i słabo w nocy albo latem lepiej niż zimą.
• Rozdzielczość i kadrowanie – w rozdzielczości zbyt niskiej nie da się odróżnić cyfr na etykiecie, a twarz staje się plamą. Z kolei zbyt wysoka rozdzielczość może być prawnym problemem (duża rozpoznawalność osób). To wymusza konkretne decyzje sprzętowe.
• Czas reakcji – jeśli system ma wykrywać wejście człowieka do strefy niebezpiecznej „w czasie rzeczywistym”, dane muszą odzwierciedlać dynamikę ruchu. 1 klatka na sekundę może wystarczyć do kontroli etykiety, ale nie do monitorowania ruchu wózka widłowego.

Projekt zestawu danych nie jest więc wyłącznie techniczną zabawą z kamerami. To świadome ograniczanie i kształtowanie tego, co system będzie w stanie realnie zrobić na hali – przy jednoczesnym respektowaniu prywatności i bezpieczeństwa ludzi.

Dlaczego RODO i BHP trzeba planować od początku

RODO i BHP w projektach wizji komputerowej pojawiają się zawsze. Pytanie tylko, czy na początku, czy dopiero gdy ktoś zgłosi sprzeciw albo wydarzy się incydent. Opóźnione zaangażowanie prawnika, IOD (Inspektora Ochrony Danych) i służb BHP zwykle kończy się koniecznością przeprojektowania połowy systemu.

Kluczowe powody, by ująć RODO i BHP od pierwszego szkicu:

• Ograniczenie zakresu danych na starcie – jeśli od razu projektuje się kadry tak, by minimalizować widoczność twarzy i sylwetek, wiele problemów znika. Nie trzeba potem w panice anonimizować terabajtów nagrań.
• Wybór właściwej podstawy prawnej – inne zasady obowiązują przy kontroli jakości produktów, a inne przy monitorowaniu zachowań pracowników. Czasem potrzebne są dodatkowe postanowienia w regulaminie pracy, czasem konsultacje ze związkami zawodowymi.
• Bezpieczeństwo montażu i eksploatacji – kamera umieszczona nad linią może wymagać pracy na wysokości, użycia podnośnika, czasowego wyłączenia maszyn. Bez konsultacji z BHP łatwo zrobić zle montowane uchwyty, wystawione kable lub elementy, o które można zahaczyć.
• Świadome poinformowanie ludzi – gdy projekt jest jawny i dobrze opisany (co kamera „widzi”, po co, jak długo są przechowywane dane), opór pracowników spada, a projekt nie kończy się konfliktem.

Planowanie RODO i BHP od początku nie jest „hamulcem postępu”. Przyspiesza wdrożenie, bo redukuje liczbę niespodzianek i przeróbek tuż przed startem systemu produkcyjnego.

Definicja problemu i zakres: co kamera ma „widzieć”, a czego nie

Precyzyjne zdefiniowanie celu systemu wizji komputerowej

Pierwsze pytanie, na które trzeba odpowiedzieć: co dokładnie ma robić system wizji komputerowej? Różnica między „kontrola etykiety” a „monitorowanie zachowań pracowników” to nie tylko inne dane, ale też inne podstawy prawne i różne oczekiwania biznesowe.

Przykładowe precyzyjne cele:

• „Wykrywanie brakującej naklejki na każdym opakowaniu schodzącym z linii X.”
• „Sygnalizowanie wejścia człowieka w żółtą i czerwoną strefę przy prasie hydraulicznej.”
• „Rozpoznawanie nieprawidłowej pozycji palców przy pracy z nożem taśmowym.”
• „Zliczanie ilości palet przejeżdżających przez węzeł logistyczny Y w ciągu zmiany.”

Każdy z takich celów przekłada się na konkretne wymagania wobec zestawu danych: inne pola widzenia, rozdzielczość, liczba przykładów pozytywnych/negatywnych, inny sposób anonimizacji. W definicji celu dobrze jest od razu dodać ograniczenia: „Nie interesuje nas identyfikacja pracownika jako osoby, interesuje nas wyłącznie detekcja obecności sylwetki w strefie.”

Konsekwencje celu dla RODO: ludzie vs. maszyny i produkty

Jeżeli kamera „widzi” wyłącznie produkt i maszynę, a człowiek jest poza kadrem, problem z RODO jest ograniczony. Dane o maszynach i produktach (wygląd detalu, stan taśmy, pozycja palety) nie są danymi osobowymi. Sprawa zmienia się radykalnie, gdy w kadrze pojawiają się pracownicy.

Obraz wideo staje się daną osobową, gdy:

• możliwa jest bezpośrednia identyfikacja osoby (wyraźna twarz, charakterystyczne znaki, identyfikator imienny),
• lub możliwa jest pośrednia identyfikacja – np. przez połączenie obrazu z grafikiem zmian, miejscem pracy, oznaczeniami na odzieży.

Dwa systemy wizji komputerowej mogą używać tych samych kamer, ale podlegać zupełnie innym zasadom:

• System kontrolujący nadruk na etykiecie, gdzie produkt kadrowany jest z góry i człowiek się nie pojawia – RODO jest w tle (logi, dostęp do danych), ale nie dotyczy bezpośrednio treści obrazu.
• System analizujący, czy pracownik ma kask i kamizelkę – obraz zawiera twarz, sylwetkę, sposób poruszania się, co jednoznacznie wchodzi w zakres ochrony danych osobowych.

Dlatego już na etapie definicji problemu trzeba zdecydować: system ma rozpoznawać osoby (np. identyfikacja konkretnego operatora – zwykle wyższe ryzyko prawne), czy jedynie anonimowo detektować sylwetki i ich pozycję w przestrzeni.

Minimalizacja zakresu zbieranych danych (privacy by design)

Zasada „privacy by design” mówi, że system od samego początku ma być tak zaprojektowany, by zbierać jak najmniej danych osobowych. W środowisku przemysłowym przekłada się to głównie na kadrowanie, pola widzenia i parametry nagrywania.

Praktyczne techniki minimalizacji:

• Ograniczenie pola widzenia – kamera jest ustawiona tak, by widziała tylko obszar roboczy produktu, a nie całe stanowisko, szczególnie nie część socjalną czy przejścia ogólne.
• Ustawienie odpowiedniej odległości – zbyt bliskie ujęcie może umożliwić identyfikację osób, zbyt dalekie uniemożliwi rozpoznanie etykiety. Ustalenie „złotego środka” wymaga prototypowania z udziałem IOD i BHP.
• Dostosowanie rozdzielczości – zamiast nagrywać obraz 4K, który pozwala odczytać każdy znaczek na odznace, można świadomie użyć niższej rozdzielczości, wystarczającej do celu (np. sprawdzenia kształtu produktu), ale utrudniającej identyfikację twarzy.
• Brak zbędnego dźwięku – jeśli system wizji komputerowej nie potrzebuje audio, nie należy go nagrywać. Nagrania dźwiękowe znacząco zwiększają zakres danych osobowych (głos, rozmowy).

Minimalizacja dotyczy też czasu: nagrywanie 24/7 „na wszelki wypadek” generuje problemy z retencją danych, kopią zapasową, ewentualnym wyciekiem. Lepszy jest jasno określony harmonogram: np. nagrywanie tylko w okresie zbierania danych treningowych, a później przetwarzanie „w locie” bez stałego zapisu pełnego wideo.

Przykład: kontrola etykiet vs. monitoring ścieżek pieszych na hali

Dwa krótkie, kontrastujące scenariusze dobrze pokazują różnicę w zakresie danych.

Kontrola etykiet na opakowaniach: kamera nad taśmą, kadrowanie tylko na górną część opakowania. Dane:

• obraz produktu z bliska, bez sylwetek pracowników,
• krótka retencja – nagrania służą tylko do zbudowania zestawu danych, potem system działa na pojedynczych klatkach w czasie rzeczywistym,
• brak identyfikowalnych osób w treści nagrania, więc RODO dotyczy głównie logów systemu i dostępu administratorów.

Monitoring ścieżek pieszych na hali: kamera pod sufitem, szeroki kąt, widać wózki widłowe, ludzi chodzących między regałami, czasem fragmenty stanowisk pracy. Dane:

• pełne sylwetki, często twarze, charakterystyczny chód – wszystkie te elementy mogą identyfikować osoby,
• silne powiązanie z grafikiem pracy i strefą zatrudnienia konkretnego pracownika,
• konieczność wyraźnego komunikatu o monitoringu, ocena wpływu na prywatność (DPIA), konsultacje z IOD i często z reprezentacją pracowników.

W tym drugim przypadku minimalizacja może polegać np. na rozmyciu twarzy w czasie rzeczywistym i przetwarzaniu na zanonimizowanym obrazie, tak by model wykrywał jedynie „obecność człowieka w strefie”, a nie konkretną osobę.

Ramy prawne: RODO, monitoring i wymagania BHP w środowisku produkcyjnym

Kiedy obraz z kamery staje się daną osobową

Podstawa prawna przetwarzania obrazu wizyjnego

Obraz z kamery w fabryce niemal nigdy nie jest przetwarzany na podstawie zgody pracownika. Zgoda w relacji pracodawca–pracownik jest zbyt łatwa do zakwestionowania (brak dobrowolności). Typowe podstawy prawne to:

• art. 6 ust. 1 lit. c RODO – obowiązek prawny – np. realizacja wymagań BHP wynikających z przepisów, gdy bez systemu wizji nie da się w praktyce osiągnąć wymaganego poziomu bezpieczeństwa,
• art. 6 ust. 1 lit. f RODO – prawnie uzasadniony interes administratora – np. poprawa jakości produkcji, analiza przestojów, zabezpieczenie mienia,
• art. 6 ust. 1 lit. b RODO – wykonanie umowy – rzadziej, np. gdy przetwarzanie jest konieczne do realizacji kontraktu z klientem (kontrola jakości zadeklarowana w umowie).

Wybór podstawy prawnej trzeba spiąć z celem systemu. Jeśli system służy wyłącznie kontroli jakości etykiet, trudno uzasadniać to obowiązkiem BHP. Jeżeli z kolei algorytm ma wykrywać wejście w strefę zagrożenia, interes BHP będzie kluczowy.

Uwaga: „prawnie uzasadniony interes” wymaga przeprowadzenia testu równowagi – czy interes pracodawcy nie jest nadmiernie inwazyjny wobec prywatności pracowników. System śledzenia każdego ruchu operatora z dokładnością do sekund najczęściej tego testu nie przejdzie.

Monitoring wizyjny a systemy przemysłowej wizji komputerowej

W wielu krajach (w tym w Polsce) monitoring wizyjny w zakładach pracy jest regulowany osobno (np. Kodeksem pracy). Klasyczny monitoring to kamery bezpieczeństwa, często z rejestratorem w ochronie. Systemy wizji komputerowej potrafią działać inaczej:

• obraz jest przetwarzany automatycznie przez algorytm, bez stałego podglądu przez człowieka,
• nagrywane są tylko pojedyncze klatki (frames) lub krótkie sekwencje do treningu modelu,
• po wytrenowaniu modelu zapisuje się już tylko metadane (np. liczba wykrytych nieprawidłowych etykiet, alarm wejścia w strefę).

Mimo tego, że „nikt nie siedzi przed monitorem”, przepisy o monitoringu dalej mają zastosowanie. Trzeba m.in.:

• wyznaczyć cele monitoringu i czas retencji w regulaminach wewnętrznych,
• oznaczyć obszary objęte kamerami w sposób czytelny dla pracowników i gości,
• uniknąć monitoringu miejsc szczególnie chronionych (szatnie, toalety, pomieszczenia socjalne) – systemów uczących się też to dotyczy.

Tip: jeśli system wizji komputerowej technicznie nie nadaje się do celów kontrolnych wobec ludzi (np. niska rozdzielczość, brak pełnego nagrywania), warto to opisać w dokumentacji. Zmniejsza to obawy załogi, a przy ewentualnej kontroli pokazuje, że projekt był projektowany z myślą o minimalizacji ingerencji w prywatność.

Ocena skutków dla ochrony danych (DPIA) w projektach wizji komputerowej

Jeśli system przetwarza dane wideo z pracownikami i wpływa na ich ocenę, bezpieczeństwo lub sytuację zawodową, zwykle trzeba wykonać DPIA (Data Protection Impact Assessment – ocena skutków dla ochrony danych). Dla fabrycznych zastosowań wizji komputerowej DPIA powinna obejmować m.in.:

• mapę kamer i obszarów objętych zasięgiem,
• opis przepływu danych – od sensora przez sieć, system zapisu, aż po narzędzia do trenowania modeli,
• analizę ryzyk – wyciek nagrań, wykorzystanie w celach dyscyplinarnych poza pierwotnym celem, błędna klasyfikacja i jej skutki (np. niesłuszne obwinienie pracownika),
• środki ograniczające ryzyko – anonimizacja, ograniczona retencja, kontrola dostępu.

Na etapie DPIA sensownie wychodzą na jaw „ukryte” zastosowania, o których ktoś myślał po cichu: np. wykorzystanie tych samych kamer do ewaluacji wydajności pracowników. Jeżeli pojawią się takie pomysły, trzeba je albo wyraźnie ująć w dokumentacji wraz z oceną ryzyka, albo z nich zrezygnować.

Wymagania BHP wobec montażu i obsługi systemu kamer

Włączenie służb BHP do projektu wizji komputerowej nie kończy się na akceptacji idei kamer. Dochodzą wymagania techniczne i organizacyjne:

• bezpieczny montaż – praca na wysokości, praca w strefie ruchu przenośników czy wózków wymaga procedur, czasem wstrzymania linii i odseparowania strefy,
• odporność konstrukcji – uchwyty kamer nie mogą odpaść od wibracji, nie powinny wystawać na trasę ładunków czy ludzi, przewody muszą być zabezpieczone przed zahaczeniem i zgnieceniem,
• strefy zagrożenia wybuchem (ATEX) – w niektórych halach nie można wnieść standardowej elektroniki, trzeba dobrać sprzęt z odpowiednimi certyfikatami.

System wizji, który ma pełnić funkcję środka ochronnego (np. wykrywać wejście w strefę roboczą robota i zatrzymywać go), podlega dodatkowo normom bezpieczeństwa maszyn (np. wymagany poziom SIL/PL). Wtedy projekt przestaje być „tylko IT/AI”, a staje się pełnoprawnym elementem systemu bezpieczeństwa – z wszystkimi obowiązkami walidacji i testów.

Transparentność wobec pracowników i związków zawodowych

Każdy projekt z kamerami w hali prędzej czy później trafi na radar związków zawodowych lub rady pracowników. Im wcześniej pojawi się otwarta komunikacja, tym mniejsze ryzyko blokady wdrożenia.

Przydatny jest zestaw konkretnych materiałów:

• opis celów i ograniczeń systemu, w tym jasno wskazane: czego system nie robi (np. brak identyfikacji indywidualnych pracowników),
• mapa kamer z zaznaczeniem stref nagrywania i stref wyłączonych,
• informacja o czasie przechowywania danych i o tym, kto ma do nich dostęp,
• procedura zgłaszania zastrzeżeń lub incydentów związanych z systemem wizji.

Dobrym ruchem jest pokazanie surowych próbek danych (z zanonimizowanymi twarzami) oraz tego, jak wyglądają wyjścia modelu – np. kontury sylwetek, pola detekcji, wykresy statystyk. Znika wtedy magia „wielkiego oka”, a zostaje konkretne narzędzie produkcyjne.

Projekt danych: jakie dane są potrzebne do konkretnego zastosowania wizji komputerowej

Przekład wymagań biznesowych na wymagania datasetu

„Chcemy, żeby model wykrywał brak etykiety” to zbyt mało, żeby zbudować sensowny zestaw danych. Trzeba zejść poziom niżej i ustalić techniczne parametry:

• jakie warianty produktu muszą się znaleźć w zbiorze (różne formaty opakowań, warianty graficzne etykiet),
• jakie warunki oświetlenia i pracy linii są istotne (start, praca stabilna, zatrzymania, czyszczenie),
• jakie typy defektów mają być rozpoznawane (brak etykiety, krzywe naklejenie, przetarcie, zamiana etykiet),
• jakie fałszywie podobne przypadki trzeba zebrać, by nauczyć model, czego nie uznawać za błąd (np. cień, odbłysk folii, narożnik kartonu).

Dopiero z takiej listy da się zbudować profil datasetu: ile obrazów potrzebujemy, w jakich kategoriach, ile przykładów „dobrych” vs. „złych”, czy potrzebna będzie augmentacja (sztuczne zwiększanie różnorodności danych).

Zakres informacji w pojedynczej próbce danych

Próbka danych w projekcie przemysłowym to zwykle nie tylko sama klatka wideo czy zdjęcie. Przy kompletnym podejściu do datasetu każda próbka może mieć:

• obraz (frame) lub krótki klip,
• metadane techniczne: czas, ID linii, numer maszyny, typ produktu, prędkość taśmy,
• etykiety (labels) – np. bounding box z pozycją etykiety, klasa „OK”/„NOK”, typ błędu,
• flagę anonimizacji – czy w kadrze występują osoby lub elementy wymagające dodatkowego przetwarzania.

Przy systemach BHP rozszerza się to o informacje o konfiguracji stref i kontekście zdarzenia: czy w danym momencie była aktywna procedura serwisowa (lockout/tagout), czy maszyna pracowała, czy była w trybie przygotowania.

Równowaga klas i różnorodność przypadków

Typowy problem w fabryce: 99,9% produktów jest poprawnych, więc „naturalne” nagrania dają prawie wyłącznie klasę „OK”. Model uczony na takim zbiorze świetnie rozpoznaje poprawne przypadki, ale kompletnie gubi się przy defektach.

Możliwe rozwiązania:

• inscenizowane błędy – kontrolowane tworzenie wad (np. celowe złe naklejenie etykiety) podczas testów, z zachowaniem zasad BHP i jakości,
• symulacje – cyfrowe generowanie defektów na bazie poprawnych zdjęć (np. zniekształcanie etykiety, dodawanie zaszumień),
• targetowane zbieranie danych – ręczne „łapanie” rzadkich zdarzeń, np. podczas uruchomień, przez krótki czas z większą gęstością nagrywania.

Dla zastosowań BHP defektem jest np. brak kasku czy wejście w strefę. Tu także zdarzenia „NOK” są rzadkie, więc trzeba je celowo przećwiczyć w kontrolowanych warunkach (np. trening BHP z udziałem ochotników) i nagrać jako materiał treningowy.

Ograniczanie danych identyfikujących w opisie próbek

W projekcie datasetu łatwo skupić się tylko na obrazie. Tymczasem wiele „wrażliwych” informacji wycieka w metadanych: ID operatora, numer stanowiska przypisany do konkretnej osoby, precyzyjna data i godzina połączona z planem zmian.

Praktyczne zasady:

• zamiast ID pracownika – losowy pseudonim, jeśli w ogóle jest potrzebny do analizy,
• zamiast dokładnej daty – przedziały czasowe lub numer sesji zbierania danych (sesja 1, sesja 2),
• zamiast dokładnej lokalizacji stanowiska – kod linii oderwany od mapy personalnej.

Jeżeli metadane nie są konieczne do trenowania modelu, lepiej ich po prostu nie gromadzić. Przy ewentualnym wycieku to one pozwalają „dopięknąć” identyfikację konkretnego człowieka.

Architektura techniczna zbierania danych wizyjnych na hali produkcyjnej

Topologia systemu: edge, on-premise, chmura

Projektując zbieranie danych wideo w fabryce, trzeba zdecydować, gdzie te dane będą przetwarzane:

• Edge – przetwarzanie bezpośrednio na kamerze lub małym komputerze przy linii. Dane surowe mogą w ogóle nie wychodzić z danej strefy, do serwera lecą tylko wyniki (np. sygnał „błąd etykiety”).
• On-premise – centralny serwer w sieci zakładowej, gdzie spływa wideo z kamer. Tu trenuje się i testuje modele, czasem także realizuje inference (wnioskowanie) w czasie rzeczywistym.
• Chmura – wykorzystywana najczęściej do eksperymentów i treningu ciężkich modeli. W kontekście RODO wymaga bardzo konkretnej umowy powierzenia przetwarzania i kontroli lokalizacji danych (regiony serwerów).

W kontekście prywatności edge jest najbezpieczniejszy – minimalizuje ilość surowego wideo w obiegu. Architektura hybrydowa (edge + on-prem/chmura) pozwala np. trzymać jedynie zanonimizowane próbki poza halą.

Ścieżka danych: od kamery do repozytorium datasetu

Dobrze zaprojektowana ścieżka danych obejmuje kilka warstw:

1. Akwizycja – kamera generuje strumień wideo (np. RTSP) lub serię obrazów. W tym punkcie dane są jeszcze „surowe”.
2. Filtracja i preselekcja – system od razu odrzuca niepotrzebne fragmenty (np. gdy linia stoi, gdy nie ma produktu w polu widzenia) oraz może wykonać wstępną anonimizację (rozmycie twarzy).
3. Buforowanie krótkoterminowe – lokalny dysk lub NAS, na którym dane są trzymane krótko (np. kilka dni) do wstępnej selekcji przez zespół inżynierski.
4. Repozytorium datasetu – docelowy magazyn danych treningowych, z kontrolą wersji (np. DVC, Git LFS, własne rozwiązanie) i ograniczonym dostępem.

Między poziomem bufora a repozytorium powinny działać automatyczne procesy anonimizacji i pseudonimizacji, tak aby w głównym zbiorze do uczenia modeli nie trafiały nagrania z pełnymi danymi osobowymi.

Bezpieczeństwo i segmentacja sieci dla systemów wizyjnych

Separacja logiczna i fizyczna komponentów

System wizji komputerowej na hali rzadko jest pojedynczym pudełkiem. To zwykle kombinacja kamer, switchy, serwerów, paneli HMI i interfejsów do PLC. Im lepiej są od siebie odseparowane, tym łatwiej utrzymać porządek zarówno od strony cyberbezpieczeństwa, jak i RODO.

Typowy podział to co najmniej trzy segmenty sieciowe:

• sieć OT (Operational Technology) – sterowniki PLC, napędy, panele operatorskie,
• sieć wizyjna – kamery, edge boxy, serwery przetwarzania,
• sieć IT/biurowa – stanowiska inżynierów, dostęp do chmury, systemy MES/ERP.

Połączenia między tymi segmentami warto realizować przez kontrolowane punkty styku (firewalle, routery z ACL, proxy), a nie przez „jeden duży VLAN na wszystko”. Znacznie ogranicza to scenariusze, w których np. malware z laptopa biurowego zaczyna skanować kamery na hali.

Kontrola dostępu do wideo i datasetów

Kamery przemysłowe mają tendencję do bycia „tak po prostu w sieci”. Przy pracy z danymi z ludźmi to prosta droga do naruszenia RODO. Niezbędne jest spięcie całej ścieżki dostępu z tożsamością użytkownika.

Praktyczny model wygląda tak:

• dostęp do samego live view z kamer tylko z wybranych stanowisk i kont (np. serwis, utrzymanie ruchu),
• dostęp do surowych nagrań wyłącznie dla wąskiej grupy (inspektor BHP, inspektor ochrony danych, wyznaczeni inżynierowie),
• dostęp do zbiorów treningowych z reguły szerzej – ale dopiero po anonimizacji i pseudonimizacji.

W praktyce pomaga integracja z istniejącym systemem kontroli dostępu (AD/LDAP) oraz logowanie wszystkich operacji na danych (kto pobrał, co obejrzał, co wyeksportował). Dla datasetu warto przyjąć podobne standardy jak dla systemów finansowych – eksport danych „na pendrive” powinien być wyjątkiem, a nie normą.

Mechanizmy ochrony transmisji i magazynowania danych

Wideo RTSP lecące „po plain TCP” między kamerą a serwerem to nadal częsty widok. W momencie, kiedy w kadrze znajdują się ludzie, powinna się zapalić lampka: to są dane osobowe przesyłane w sieci produkcyjnej.

Podstawowe mechanizmy techniczne:

• szyfrowanie transmisji – RTSP over TLS, HTTPS dla API kamer, VPN między halą a data center/chmurą,
• szyfrowanie w spoczynku – dyski z włączonym szyfrowaniem (np. LUKS, BitLocker) na serwerach z nagraniami i datasetami,
• rotacja kluczy – cykliczna zmiana haseł i certyfikatów, szczególnie przy serwisowaniu kamer lub wymianie urządzeń.

Tip: przy audycie RODO oraz audycie cyber w fabryce bardzo dobrze wygląda wykaz, które komponenty są szyfrowane i w jaki sposób. Dobrze to mieć spisane, a nie dopiero „odtwarzać z pamięci” na pytania działu compliance.

Procedury backupu i retencji datasetów

Zbiory danych do trenowania modeli mają jedną specyfikę: są duże i łatwo się w nich gubić. Dodatkowo, gdy wchodzą w grę dane osobowe, dochodzi obowiązek ograniczonego czasu przechowywania.

Przy porządnym podejściu istnieją równolegle:

• backupy operacyjne – krótkookresowe kopie na wypadek awarii (dni/tygodnie),
• archiwa wersji datasetów – powiązane z wersjami modeli (model v1 → dataset v1.3),
• harmonogram kasowania – zdefiniowany dla surowych nagrań, materiału z twarzami i zanonimizowanych zbiorów.

Surowe nagrania z kamer, na których widać pracowników, nie mogą leżeć „na zawsze, bo może się przydadzą do kolejnego modelu”. Harmonogram retencji powinien wymuszać automatyczne usuwanie po upływie określonego czasu, a dataset do kolejnego projektu buduje się już z materiału zanonimizowanego lub nowych nagrań.

Minimalizacja i anonimizacja danych: jak nagrywać ludzi i nie naruszyć RODO

Rozróżnienie: dane osobowe vs. dane techniczne

Pierwszy krok to nazwanie rzeczy po imieniu. Każde wideo, na którym można rozpoznać człowieka (po twarzy, sylwetce, charakterystycznym sposobie poruszania się, ubiorze z imiennikiem), to dane osobowe. Wszystko inne – produkt, maszyny, etykiety – to dane techniczne.

Przy planowaniu datasetu dobrze jest mieć listę, co w typowym kadrze stanowi potencjalny identyfikator:

• twarz lub profil twarzy,
• ciało o charakterystycznej sylwetce czy sposobie chodzenia (gait),
• indywidualne elementy ubioru (np. imię na kamizelce, numer na kasku),
• ekran HMI z loginem operatora.

Cel: dane techniczne zostają, dane osobowe są albo eliminowane z kadru, albo zanonimizowane, albo przynajmniej pseudonimizowane, jeśli potrzebny jest jakiś ślad do analizy zdarzeń.

Minimalizacja przy samym projektowaniu kadrów

Największą „anonimizację” robi nie algorytm, tylko geometria kadru. Im mniej ludzi trafia do zasięgu kamery, tym mniejszy problem prawny i techniczny.

Praktyczne zabiegi na etapie montażu:

• węższe pole widzenia – dobór obiektywu tak, by widzieć tylko produkt i krytyczną część maszyny, nie całą halę,
• perspektywa z góry – montaż kamery nad linią, tak aby sylwetki ludzi były jedynie konturami, bez wyraźnych twarzy,
• maski prywatności w kamerze – większość kamer IP umożliwia zdefiniowanie stref, które są permanentnie zamazane lub zaciemnione,
• fizyczne osłony – przesłony, tunele, światło tła ograniczające widoczność przestrzeni poza produktem.

Uwaga: maski prywatności i kadrowanie powinny być traktowane jak część projektu bezpieczeństwa, a nie „później się ustawi”. Zmiana pola widzenia kamery po roku może całkowicie zmienić profil ryzyka RODO.

Anonimizacja wideo i obrazów – techniczne podejścia

Gdy nie da się wyeliminować ludzi z kadru, pozostaje ich muskularna obróbka. Chodzi o taki proces, w którym obraz jest automatycznie przekształcany, zanim trafi do głównego repozytorium datasetu.

Najczęściej stosowane techniki:

• detekcja osób (np. modele YOLO, Detectron2) i nałożenie rozmycia (blur) lub mozaiki na wykryte sylwetki/twarze,
• maskowanie całych stref – jeśli wiesz, że w danej strefie w kadrze mogą być tylko ludzie (np. przejście między liniami), tę strefę można trwale zasłonić,
• wyodrębnienie tylko ROI (Region Of Interest) – wycinanie z kadru samego produktu i ignorowanie reszty sceny.

Przykład z praktyki: przy projekcie wykrywania poprawności okularów ochronnych operatora BHP chciał mieć nagrania „w razie wypadku”, ale zespół AI potrzebował wyłącznie informacji, czy okulary są na głowie. Kompromis: na potrzeby datasetu wycinano tylko prostokąt wokół głowy i ramion, reszta sylwetki była maskowana, a kopia pełnego wideo trafiała do systemu monitoringu z krótką retencją i ścisłym dostępem.

Pseudonimizacja i kontrola reidentyfikacji

Anonimizacja oznacza, że nie da się już „odwrócić” procesu i dojść do konkretnej osoby. W fabryce często to jest zbyt daleko idące – czasem trzeba wiedzieć, kto uczestniczył w zdarzeniu BHP, albo zweryfikować skargę pracownika. Wtedy stosuje się pseudonimizację.

Pseudonimizacja w ujęciu datasetu oznacza np.:

• nadanie osobom w kadrze losowych ID („osoba_123”), które nie są bezpośrednio powiązane z tożsamością,
• przechowywanie klucza mapującego ID <→ konkretna osoba w osobnym, mocno zabezpieczonym systemie (poza datasetem),
• ograniczenie liczby osób uprawnionych do „odwiązania” ID od danych personalnych.

Kluczowe jest, żeby dataset używany do trenowania modelu nie zawierał tej mapy. Dla zespołu ML osoba_123 to po prostu przykład, a nie Jan Kowalski z trzeciej zmiany. Reidentyfikacja powinna wymagać formalnej procedury (np. zgoda IOD i kierownika zakładu).

Różne poziomy anonimizacji w zależności od użycia

Inny poziom szczegółowości jest potrzebny przy:

• analizie incydentów BHP – pełne nagranie, często bez anonimizacji, ale z bardzo krótką retencją i ścisłym dostępem,
• budowaniu modelu produkcyjnego – obraz przetworzony, z zamazanymi twarzami i usuniętymi metadanymi osobowymi,
• materiałach szkoleniowych lub benchmarkach – dane silnie zanonimizowane, często z dodatkową degradacją jakości, by uniemożliwić rozpoznanie osoby.

Użyteczne jest sformalizowanie „klas” danych wideo, np. poziom A (pełne dane, tylko dla IOD/BHP), poziom B (częściowo zanonimizowane, dla inżynierów) i poziom C (w pełni zanonimizowane, dopuszczalne do dzielenia się zewnętrznie, np. z integratorem). Każda klasa ma własne reguły przechowywania, backupu i udostępniania.

Anonimizacja metadanych i logów

Nawet perfekcyjnie rozmyte twarze nie pomogą, jeśli w metadanych zostaną dokładne identyfikatory. Przy datasetach w przemyśle szczególnie „przeciekają”:

• loginy operatorów w systemach MES,
• numery identyfikacyjne stanowisk powiązane z konkretną osobą w grafiku,
• szczegółowe znaczniki czasu, które można zestawić z rejestrem wejść/wyjść do zakładu.

Bezpieczniejsza praktyka to:

• agregowanie czasu do okien (np. „sesja poranna”, „sesja testowa 3”) zamiast dokładnego timestampu, jeśli nie jest on krytyczny dla analizy,
• używanie lokalnych identyfikatorów sesji zamiast realnych ID linii/stanowisk (mapowanie przechowywane osobno),
• usuwanie pełnych logów systemowych z finalnego datasetu – zachowywanie ich tylko w systemach monitoringu, nie w repozytorium danych treningowych.

Organizacja procesu anonimizacji: pipeline i odpowiedzialności

Anonimizacja nie może być „ręczną robotą na boku”. W fabryce, która generuje setki gigabajtów nagrań, trzeba potraktować to jako normalny pipeline danych, z jasno określonymi krokami i właścicielami.

Przykładowy przepływ:

1. Surowe wideo trafia do bufora o ograniczonej pojemności (np. NAS w wydzielonej podsieci).
2. Automatyczny proces wykrywa kadry z ludźmi i stosuje rozmycie, wycina ROI, usuwa metadane osobowe.
3. Zespół inżynierski dokonuje szybkiego przeglądu i oznacza klipy/obrazy przydatne do trenowania modeli.
4. Próbki spełniające kryteria trafiają do repozytorium datasetu; reszta jest automatycznie kasowana po ustalonym czasie.

Za każdy etap odpowiada inny „właściciel”: OT/IT za infrastrukturę i bezpieczeństwo, zespół AI/ML za jakość anonimizacji i przydatność danych, IOD za zgodność z politykami ochrony danych. Dzięki temu nie ma sytuacji, w której „wszyscy trochę odpowiadają”, więc w efekcie nikt nie czuje się odpowiedzialny.

Szkolenie zespołów z praktycznej ochrony danych wizyjnych

Nawet najlepsze procedury można obejść jednym nieprzemyślanym eksportem plików. Zespół utrzymania ruchu, automatycy i inżynierowie od AI muszą rozumieć, z czym pracują, gdy manipulują nagraniami.

Kilka punktów, które opłaca się przećwiczyć na warsztatach:

• kiedy udostępnienie screena z kamery na służbowym komunikatorze jest już udostępnieniem danych osobowych,
• jak właściwie zanonimizować materiał, zanim trafi do dostawcy zewnętrznego (np. integratora systemu),
• jak reagować, gdy ktoś prosi „podeślij nagranie, bo chcę coś pokazać kolegom od IT”.

Najlepiej działają krótkie, konkretne przykłady z własnej fabryki – np. zanonimizowane zrzuty ekranu „przed” i „po”, zestaw dobre praktyki vs. złe praktyki. Inżynierom technicznym łatwiej wtedy potraktować RODO jak zestaw wymagań projektowych, a nie czysto prawną abstrakcję.

Najważniejsze wnioski

• Zestaw danych z kamer to narzędzie do rozwiązania konkretnych problemów (braki jakościowe, BHP, przestoje, logistyka), a nie cel sam w sobie – scenariusz biznesowy precyzyjnie definiuje, co i jak trzeba nagrywać.
• Różne zastosowania (kontrola jakości, BHP, logistyka, utrzymanie ruchu) wymagają zupełnie innego kadrowania, metadanych i polityki retencji nagrań, a także w różnym stopniu ingerują w prywatność pracowników.
• PoC robione „na szybko” z losowych nagrań nie spełnia wymagań systemu produkcyjnego; w produkcji kluczowe są skalowalność, powtarzalność zbierania danych, udokumentowana zgodność z RODO i bezpieczny montaż zgodny z BHP.
• To, czego model ma się nauczyć, musi fizycznie znaleźć się w danych: pełny zakres klas/zdarzeń, różne warunki środowiskowe, odpowiednia rozdzielczość oraz liczba klatek na sekundę dopasowana do dynamiki zjawiska.
• Decyzje dotyczące ochrony danych (RODO) wpływają bezpośrednio na możliwości modelu – np. agresywne wycinanie ludzi z kadru uniemożliwia uczenie zależności między zachowaniem operatora a stanem produktu lub maszyny.
• RODO i BHP trzeba włączyć od pierwszego szkicu rozwiązania: od projektowania kadr ograniczających rozpoznawalność osób, przez dobór podstawy prawnej monitoringu, po analizę ryzyka i procedury bezpiecznego montażu kamer.
• Projektowanie zestawu danych to decyzja systemowa, a nie tylko techniczna: jednocześnie kształtuje realne możliwości modelu na hali i określa poziom ryzyka prawnego, wizerunkowego oraz bezpieczeństwa pracowników.