Jak szkolić modele AI na danych z produkcji, nie łamiąc RODO i tajemnicy przedsiębiorstwa

Od czego zacząć: jakie dane z produkcji naprawdę są „wrażliwe”

Mapa danych w fabryce – szybki przegląd źródeł

Pierwsze pytanie, zanim ktoś wrzuci dane z produkcji do modelu AI, brzmi zwykle: „czy te dane w ogóle podpadają pod RODO albo tajemnicę przedsiębiorstwa?”. Żeby odpowiedzieć sensownie, trzeba najpierw zobaczyć pełny obraz – gdzie w zakładzie w ogóle powstają dane.

Typowe źródła danych w fabryce przemysłowej to:

• SCADA / PLC / systemy automatyki – sygnały z czujników, stany maszyn, alarmy, przełączenia trybów pracy.
• MES – zlecenia produkcyjne, czasy przezbrojeń, raporty z linii, często też informacja o zmianie, brygadzie, operatorze.
• CMMS – zgłoszenia awarii, zlecenia serwisowe, listy części, nazwiska serwisantów wewnętrznych i zewnętrznych.
• ERP – zamówienia, dane klientów i dostawców, koszty, marże, numery partii, powiązanie produkcji z kontraktami.
• Systemy jakości (LIMS, QMS) – wyniki pomiarów, próbki, reklamacje, raporty niezgodności, często komentarze pracowników.
• HMI / panele operatorskie – logi logowań, zmiany parametrów ręcznie wprowadzane przez operatorów.
• Monitoring wizyjny – kamery bezpieczeństwa, systemy wizyjnej kontroli jakości, nagrania z hal i stanowisk.
• Systemy HR / czasu pracy – wejścia/wyjścia, zmiany, grafiki, często później łączone z efektywnością linii.

Intuicyjnie łatwo wskazać dane „maszynowe” (temperatury, prędkości, prądy silników) i dane „ludzkie” (logi operatorów, nagrania z kamer). W praktyce najwięcej problemów jest w szarej strefie – tam, gdzie dane z ludzi i maszyn łączą się ze sobą.

Prosty przykład z linii pakującej:

• SCADA zapisuje prędkość taśmy, liczbę paczek, zatrzymania, błędy czujników.
• MES przypisuje każde zlecenie produkcyjne do konkretnej zmiany i brygady.
• CMMS trzyma informacje, kto zgłosił awarię, kto wykonał naprawę.
• System wizyjny archiwizuje zdjęcia wadliwych produktów – czasem w kadrze pojawia się ręka operatora albo etykieta z danymi klienta.

Na pierwszy rzut oka chcemy szkolić model predykcji awarii na „parametrach technicznych”. W praktyce w tym samym rekordzie lub po złączeniu tabel mogą być:

• identyfikator operatora lub jego data i godzina wejścia na linię,
• nazwa klienta, którego towar pakujemy,
• numer umowy, który zdradza cennik i warunki handlowe,
• oznaczenia partii, po których można wrócić do reklamacji konkretnej osoby.

Z punktu widzenia AI większość tych informacji to „szum”, ale z punktu widzenia RODO i tajemnicy przedsiębiorstwa – materiał o wysokiej wrażliwości. Dlatego kluczowe jest nie pytanie „czy mamy dane osobowe?”, tylko „gdzie w strumieniu danych technicznych realnie mieszają się informacje o ludziach i biznesie”.

Kiedy RODO, a kiedy tylko (albo aż) tajemnica przedsiębiorstwa

RODO dotyczy danych osobowych, czyli informacji, które pozwalają zidentyfikować osobę fizyczną bezpośrednio lub pośrednio. W zakładzie produkcyjnym to nie tylko oczywiste rzeczy typu imię i nazwisko.

Przykłady danych osobowych w realnej fabryce:

• ID operatora w logach maszyn – jeśli system logowania wiąże identyfikator z konkretną osobą, nawet „OP1234” jest daną osobową.
• Nagrania z kamer – twarz, sylwetka, sposób poruszania się, czasem głos – wszystko to może identyfikować konkretną osobę.
• Komentarze w systemach jakości – „Janek z linii 3 znowu źle ustawił ciśnienie” to klasyczna informacja o osobie.
• Dane serwisantów – kto przyjechał z firmy zewnętrznej, o której godzinie, jakie czynności wykonał.
• Dane BHP i zdrowotne – zapisy o wypadkach, ekspozycji na szkodliwe czynniki, ograniczeniach zdrowotnych; to mogą być dane szczególnych kategorii.

Z drugiej strony są dane, które nie identyfikują osób, ale stanowią tajemnicę przedsiębiorstwa lub informacje poufne biznesowo:

• Receptury i parametry procesu – temperatury, składy, kolejność operacji, czasy reakcji.
• Dokładne KPI linii – wskaźniki OEE, czasy cyklu, poziomy scrapu, które pokazują realną efektywność zakładu.
• Dane o wadach i reklamacjach – z których można wywnioskować słabe punkty procesu.
• Ceny, rabaty, warunki umów z kluczowymi klientami – dane w ERP i powiązaniu z produkcją.

Te dane nie podlegają RODO (bo nie dotyczą osób fizycznych), ale dla konkurencji są złotem. Modele AI trenowane na takich danych mogą – przy braku zabezpieczeń – stać się kanałem wycieku know-how.

Granica między RODO a „tylko” tajemnicą przedsiębiorstwa bywa myląca przy pseudonimach. Nawet jeśli zrezygnujesz z imion i nazwisk, pseudonim może nadal być daną osobową, jeżeli przy użyciu innych danych dostępnych w organizacji da się ustalić, o kogo chodzi.

Przykładowo, jeżeli łączysz:

• numer brygady,
• konkretną zmianę,
• rodzaj uprawnień (np. tylko jedna osoba ma uprawnienia UDT na tej linii),

to nawet przy braku nazwiska, przy odrobinie znajomości zakładu wiadomo, który pracownik stoi za rekordem. Z punktu widzenia RODO to dalej dane osobowe i wymagają podstawy prawnej, informacji dla pracownika, oceny ryzyk, odpowiednich zabezpieczeń.

Prosty schemat klasyfikacji danych przed projektem AI

Zanim ktokolwiek zacznie myśleć o architekturze systemu, przydaje się banalnie prosty, ale skuteczny podział wszystkich danych, których dotknie model AI, na cztery „koszyki”:

1. Dane osobowe – wszystko, co pozwala zidentyfikować konkretnego pracownika, kontrahenta czy gościa zakładu.
2. Dane osobowe szczególnych kategorii – zwłaszcza dane zdrowotne (BHP), informacje o karach porządkowych, wypadkach, orzeczeniach lekarskich.
3. Dane poufne biznesowo / tajemnica przedsiębiorstwa – know-how procesowe, plan produkcji, wyniki jakości, koszty, marże, receptury.
4. Dane względnie neutralne – proste sygnały maszynowe, dane techniczne urządzeń bez powiązania z osobami i bez wartości konkurencyjnej (np. standardowy katalog producenta maszyny).

Trzy podstawowe kryteria, które ułatwiają klasyfikację:

• Kto jest „bohaterem” danych? Jeśli to człowiek – mamy RODO. Jeśli maszyna lub produkt – patrzymy na ryzyko biznesowe.
• Czy z kombinacji pól można kogoś pośrednio zidentyfikować? Mała liczba osób na zmianie, unikalne uprawnienia, szczególne role – to typowe sygnały ostrzegawcze.
• Czy ujawnienie tej informacji konkurentowi zabolałoby firmę? Jeśli tak, to minimum to reżim tajemnicy przedsiębiorstwa i dodatkowe zabezpieczenia przy szkoleniu modeli.

Ten podział nie jest akademickim ćwiczeniem. Na jego podstawie można od razu powiązać klasy danych z wymaganiami dla architektury:

• Koszyk 1 i 2 (dane osobowe) – zwykle wymagają:
  • jasnej podstawy prawnej (np. prawnie uzasadniony interes, wykonanie umowy, rzadziej zgoda),
  • DPIA (oceny skutków dla ochrony danych), jeżeli ryzyko jest wysokie,
  • preferencji dla on-premise lub chmury w UE z dobrą umową powierzenia.
• Koszyk 3 (tajemnica przedsiębiorstwa) – silne NDA, ograniczone udostępnianie dostawcom, kontrola nad tym, czy model nie „uczy się” wspólnie z danymi innych klientów.
• Koszyk 4 (neutralne) – idealny materiał startowy do prototypowania, testowania architektur, generowania syntetycznych danych.

Dobrą praktyką jest spisanie tej klasyfikacji w krótkiej notatce projektowej. To później podstawa do rozmowy z inspektorem ochrony danych i działem prawnym – zamiast ogólnego „będziemy trenować AI”, pokazujesz, jakie konkretne kategorie danych będą użyte i w jaki sposób.

Gdzie i jak szkolić model: on-premise, chmura, SaaS – plusy, minusy, ryzyka

Trzy podstawowe modele przetwarzania w przemyśle

Drugi duży zestaw pytań dotyczy miejsca szkolenia modeli: „czy to musi być u nas w serwerowni?”, „czy możemy użyć chmury?”, „czy dostawca SaaS może trenować na naszych danych?”. To nie jest tylko decyzja techniczna – od niej zależy, kto realnie kontroluje dane i jakie umowy trzeba skonstruować.

Najczęściej spotykane warianty to:

1. Trenowanie lokalne (on-premise, edge)

Model uczy się na sprzęcie znajdującym się fizycznie w zakładzie lub w infrastrukturze kontrolowanej bezpośrednio przez firmę:

• serwery w lokalnej serwerowni,
• „appliance” ML zainstalowany u klienta przez dostawcę,
• moduły edge z GPU zainstalowane przy liniach, szkolące model na miejscu.

2. Chmura (prywatna lub publiczna)

Dane są wysyłane do środowiska chmurowego, gdzie wykonuje się trening modelu. Może to być:

• prywatna chmura należąca do grupy kapitałowej,
• instancja w chmurze publicznej (np. europejskie DC dużego dostawcy),
• platforma ML (PaaS) udostępniająca gotowe narzędzia do trenowania.

3. SaaS z wbudowaną AI

System dostawcy (np. system CMMS, rozwiązanie do predykcji awarii czy analizy jakości) ma wbudowaną funkcję AI. Dane są wysyłane do dostawcy, który:

• świadczy usługę,
• decyduje o tym, jak model jest trenowany,
• często chce wykorzystywać dane wielu klientów, by poprawiać model ogólny.

Technicznie trzy scenariusze mogą być bardzo podobne, ale z perspektywy RODO i tajemnicy przedsiębiorstwa różnice są zasadnicze.

Porównanie ryzyk RODO i tajemnicy przedsiębiorstwa

Uproszczając, pytanie brzmi: kto kontroluje dane i kto ponosi ryzyko ich wycieku. Tabela pomaga poukładać sobie obraz:

W praktyce, przy danych osobowych, RODO zasadniczo nie zakazuje chmury ani SaaS – ale wymaga:

• jasnej roli dostawcy (podmiot przetwarzający / współadministrator),
• konkretnych zapisów w umowie (cel, zakres, środki bezpieczeństwa, podprzetwarzający, transfery poza EOG),
• realnego sprawdzenia, czy dostawca spełnia minimalne standardy bezpieczeństwa.

Przy tajemnicy przedsiębiorstwa punktem ciężkości jest to, czy model AI może być uczony na wspólnej puli danych wielu klientów, a później trafiać do innych firm. Jeżeli dostawca AI:

• nie rozdziela instancji modelu per klient,
• używa jednego „głównego” modelu dla całej bazy klientów,
• zastrzega w umowie prawo do „ulepszania usług” na danych klientów,
• nie daje opcji całkowitego wyłączenia trenowania na Twoich danych,

– to w praktyce prosisz konkurencję, aby pomogła szkolić Twojego dostawcę, a Ty szkolisz jego. Przy prostym systemie biurowym może to być akceptowalne, przy recepturach produkcyjnych czy algorytmach optymalizacji kosztów energii – dużo mniej.

Jak negocjować warunki trenowania modeli z dostawcą

Przy SaaS i chmurze kluczowe jest, żeby temat trenowania modeli nie był ukryty w marketingu, tylko jasno opisany w umowie. W praktyce przydaje się kilka prostych zasad negocjacyjnych:

• Rozdziel usługę od trenowania na danych. W umowie osobno opisuj:
  • co jest potrzebne do bieżącego świadczenia usługi (np. predykcja awarii dla Twoich maszyn),
  • a co jest „ekstra” – trenowanie ogólnego modelu dostawcy na danych z wielu firm.
• Domyślnie „opt-out” dla danych wrażliwych i tajemnicy przedsiębiorstwa. Jeśli dostawca chce trenować modele ogólne:
  • wyłącz z tego dane osobowe i krytyczne know-how,
  • albo wprowadź twardy wymóg wcześniejszej anonimizacji / agregacji.
• Żądaj jasnego podziału modeli. Dobry kompromis:
  • instancja modelu per klient dla danych szczególnie wrażliwych,
  • osobny, „wspólny” model uczony wyłącznie na zanonimizowanych, zagregowanych cechach.
• Zapisz scenariusze wyjścia. Przy zmianie dostawcy:
  • co dzieje się z Twoimi danymi treningowymi,
  • czy dostajesz kopię wytrenowanego modelu,
  • w jakim zakresie dostawca może dalej używać wiedzy z Twoich danych.

Na spotkaniu z dostawcą dobrze działa proste pytanie: „Proszę pokazać diagram: gdzie są moje dane, który model jest tylko mój, a który jest wspólny?”. Jeżeli firma nie potrafi tego narysować w pięć minut na tablicy, to raczej nie chcesz jej powierzać danych całej produkcji.

Praktyczne kryteria wyboru: kiedy on‑premise, kiedy chmura, kiedy SaaS

Wybór modelu przetwarzania warto oprzeć na kilku prostych kryteriach, a nie na tym, co akurat jest „modne”. Pomaga sobie odpowiedzieć na trzy pytania:

• Jak bardzo wrażliwe są dane? Jeśli dominują dane z koszyka 1–3, szczególnie receptury i dane osobowe operatorów – przewagę ma on‑premise lub chmura z mocnym odseparowaniem środowiska.
• Jak szybko trzeba iterować modele? Gdy liczy się tempo eksperymentów (np. setki treningów tygodniowo), chmura daje przewagę kosztową i organizacyjną nad własną serwerownią, o ile poprawnie ustawisz RODO i tajemnicę przedsiębiorstwa.
• Czy AI jest sercem biznesu, czy „dodatkiem”? Jeśli model decyduje o planie produkcji, zużyciu energii i jakości – lepiej mieć większą kontrolę (on‑premise / własna instancja w chmurze). Jeżeli to tylko funkcja dodatkowa w CMMS – dobrze skonfigurowany SaaS może być w zupełności wystarczający.

W praktyce w zakładach produkcyjnych często wygrywa model mieszany: krytyczne modele (np. optymalizacja receptury) trzymane są lokalnie lub w wydzielonej chmurze, a mniej wrażliwe funkcje (np. klasyfikacja usterek w zgłoszeniach serwisowych) działają jako SaaS. Z punktu widzenia RODO i tajemnicy przedsiębiorstwa to zwykle zdrowsze podejście niż „wszystko do chmury” albo „wszystko w serwerowni od lat 90.”.

Od surowych logów do zbioru treningowego: jak „odchudzić” dane bez zabijania modelu

Najwięcej problemów z RODO i tajemnicą przedsiębiorstwa nie wynika z samego modelu, tylko z tego, co wrzucamy do środka. Surowe logi z systemów produkcyjnych mają w sobie wszystko: identyfikatory maszyn, czas, użytkowników, komentarze operatorów, numery zleceń, czasem nawet fragmenty korespondencji z klientem.

Bez prostego procesu „odchudzania” danych kończy się na tym, że data scientist trenuje na pełnym zrzucie bazy, a dział prawny dowiaduje się o tym po fakcie. Da się to poukładać w kilku krokach.

Mapa danych: co naprawdę jest potrzebne do modelu

Zanim ktokolwiek dotknie SQL-a, dobrze jest zadać jedno pozornie banalne pytanie: jakie zmienne ten model realnie potrzebuje. W praktyce sprowadza się to do prostego ćwiczenia przy tablicy:

• z lewej – surowe tabele i pola (np. log PLC, rejestr błędów, dane z MES/ERP),
• z prawej – problem biznesowy (predykcja awarii, scrap rate, czas przezbrojenia),
• pośrodku – lista kandydatów na cechy modelu (feature’y).

Warto tu od razu oznaczyć pola, które są zbędne lub ryzykowne z perspektywy RODO i tajemnicy przedsiębiorstwa, np.:

• pełne imię i nazwisko operatora,
• dokładny numer zlecenia powiązany z klientem,
• numer seryjny kontraktowego komponentu, który sam w sobie jest informacją poufną klienta,
• pełny opis reklamacji z danymi kontaktowymi.

W większości problemów predykcyjnych w przemyśle modelowi wystarczy informacja o warunkach procesu (parametry maszyn, stan linii, klastry przyczyn awarii), a nie to, że akurat „Jan Kowalski zlecenie 123/2024 dla klienta X” obsługiwał daną zmianę.

Anonimizacja, pseudonimizacja, agregacja – co jest realne na hali

Teoretycznie opcji ochrony jest sporo, ale w fabryce liczy się to, co da się wdrożyć bez paraliżu OT. Trzy techniki, które najczęściej „dowiozły” projekty:

1. Pseudonimizacja identyfikatorów osobowych

Zamiast pełnych danych pracowników i kontrahentów stosuje się trwałe, losowe identyfikatory:

• operator_001, operator_002 zamiast imienia i nazwiska,
• klient_seg_A, klient_seg_B zamiast pełnych danych klienta,
• hashowane ID użytkownika w logach systemów.

Klucz łączący te identyfikatory z realną osobą lub firmą przechowywany jest osobno, z ograniczonym dostępem (np. tylko HR / dział jakości), a do środowiska trenowania w ogóle nie trafia. Z perspektywy RODO to nadal dane osobowe, ale:

• model nie „widzi” konkretnej osoby,
• ryzyko identyfikacji z poziomu danych treningowych drastycznie spada,
• łatwiej argumentować proporcjonalność zakresu danych przy DPIA.

2. Anonimizacja i przycinanie szczegółowości

To podejście polega na takim przekształceniu danych, aby nie można było zidentyfikować osoby ani konkretnego klienta. W praktyce przydają się proste zabiegi:

• zaokrąglanie czasu do przedziałów (np. co 5–15 minut zamiast dokładnej sekundy),
• podmiana dat na sztuczne osie czasu (dzień 0, 1, 2 od startu kampanii produkcyjnej),
• zamiana dokładnych wartości na przedziały (np. „zlecenie małe/średnie/duże” zamiast konkretnej liczby sztuk),
• usuwanie treści tekstowych zawierających swobodny opis (tam najczęściej kryją się dane osobowe i poufne szczegóły umów).

Anonimizacja pełna bywa trudna, szczególnie w małych zakładach, gdzie już sama kombinacja „linia + zmiana + produkt” może wskazywać konkretną osobę. Dlatego kluczowa jest ocena, czy po kombinacji przycięcia, pseudonimizacji i kontroli dostępu ryzyko jest na akceptowalnym poziomie.

3. Agregacja i wyciąganie cech (feature engineering)

Zamiast trenować na surowych logach, można zbudować warstwę pośrednią: obliczyć cechy zagregowane, które są już „czystszym” materiałem treningowym. Przykłady:

• liczba mikroprzestojów na godzinę zamiast listy wszystkich zatrzymań z komentarzami operatora,
• średnie, minima i maksima temperatur/ciśnień w oknie czasowym,
• procent czasu w „stanie ostrzegawczym” maszyny zamiast pełnego logu stanów.

Taka warstwa cech może zostać zbudowana automatycznie w hurtowni danych lub w osobnym pipeline’ie ETL. Z punktu widzenia tajemnicy przedsiębiorstwa ważne jest, że do modelu nie trafiają pełne receptury czy kompletne sekwencje sterowania, tylko ich uogólnione parametry.

Przykład z linii montażowej: co usunąć, co zostawić

Załóżmy, że celem jest model przewidujący zwiększone ryzyko braków na linii montażowej. W surowych danych są m.in.:

• log pracy linii (czas, stany, prędkość),
• identyfikator operatora i brygady,
• numery zleceń i komponentów,
• komentarze operatorów przy zgłoszeniach problemów,
• dane z kamer wizyjnych (obrazy detali).

Bezpieczniejszy zbiór treningowy może wyglądać tak:

• parametry pracy linii zagregowane w 5-minutowych oknach (średnia prędkość, liczba krótkich zatrzymań, odchylenie od normy),
• pseudonim operatora (operator_123) bez powiązania z personalnymi danymi w systemie treningowym,
• label jakościowy w postaci „procent braków w oknie czasowym”, bez numerów zleceń i nazw klienta,
• z obrazów usunięte wszystkie elementy, na których może pojawić się np. etykieta klienta z danymi (przycięcie kadru, maskowanie).

Model nadal może nauczyć się zależności między warunkami procesu a jakością, ale znika większość realnego ryzyka, że ktoś z zewnątrz odtworzy listę klientów, kluczowych operatorów czy pełną technologię montażu.

Pipeline danych treningowych jako „produkt” z własnym właścicielem

Przy małych pilotażach dane treningowe często powstają „na kolanie” – ktoś robi eksport z MES, ktoś inny łączy to z Excelem, a potem całość ląduje na laptopie data scientista. Do pierwszego POC często „jakoś działa”, ale RODO i tajemnica przedsiębiorstwa są wtedy czystą loterią.

Bezpieczniejszym podejściem jest traktowanie pipeline’u danych treningowych jak osobnego produktu IT:

• ma jasnego właściciela biznesowego (np. szef utrzymania ruchu / jakości),
• ma opisany zakres danych wejściowych i wyjściowych,
• ma zdefiniowane reguły pseudonimizacji, anonimizacji i agregacji,
• ma udokumentowane punkty dostępu (kto i skąd może pobrać dane).

To podejście ułatwia później audyt, a przy okazji porządkuje współpracę z dostawcami: zamiast dawać im dostęp do pełnych logów produkcyjnych, udostępniasz przetworzoną, kontrolowaną warstwę danych treningowych.

Uporządkowany proces trenowania: dostęp, nadzór i dokumentacja

Nawet najlepsza anonimizacja nie pomoże, jeśli model trenuje się z pendrive’a wpiętego w losowy serwer. Z perspektywy RODO, ale też zdrowego rozsądku, cały proces trenowania powinien być poukładany jak każda inna operacja na danych w firmie produkcyjnej.

Kto co może robić z danymi – role i uprawnienia

Jedno z częstszych „cichych” ryzyk to szeroki dostęp do pełnych zbiorów treningowych. Przy projektach AI łatwo dochodzi do sytuacji, w której:

• data scientist ma dostęp do surowej bazy ERP/MES,
• dostawca zewnętrzny widzi pełne dane osobowe operatorów,
• admin techniczny ma możliwość eksportu wszystkiego „na wszelki wypadek”.

Prościej i bezpieczniej jest zdefiniować kilka ról:

• Właściciel danych (np. dyrektor produkcji / jakości) – decyduje, jakie dane mogą być użyte i w jakim celu.
• Opiekun zgodności (np. IOD + prawnik) – sprawdza, czy zakres i sposób przetwarzania pasuje do RODO i umów z klientami.
• Zespół techniczny (IT/OT, data engineering) – buduje pipeline, ale pracuje na zdefiniowanej warstwie danych, nie na całej firmowej bazie „na zapas”.
• Dostawca / data scientist – ma dostęp do minimalnego zbioru, często już po anonimizacji/agregacji.

Przy większych projektach dobrym nawykiem jest prosta matryca: role × systemy × typ danych (surowe / przetworzone / wyniki modelu). To dokument, który bardzo lubią zarówno audytorzy bezpieczeństwa, jak i dział prawny.

Środowisko trenowania: osobno od produkcji

Modele lubią eksperymenty, produkcja – stabilność. Wspólne środowisko dla obu to przepis na kłopoty. Praktycznie każda większa fabryka, która przeszła kilka wdrożeń AI, kończy z podziałem:

• Środowisko produkcyjne – systemy sterowania, MES, ERP, z restrykcyjnym dostępem, zmianami tylko przez ustalony proces change management.
• Środowisko danych i eksperymentów AI – wydzielone serwery / instancje chmurowe, do których trafiają już przetworzone dane.

Taki podział pozwala:

• ograniczyć ryzyko przypadkowej ingerencji w system produkcyjny podczas testów modeli,
• wdrożyć inne, bardziej elastyczne zasady dostępu (np. czasowe uprawnienia dla dostawcy) bez naruszania rygorów OT,
• lepiej logować i audytować operacje na danych treningowych.

Przy projektach w chmurze analogią jest osobne konto/subskrypcja na potrzeby data science, z jasnymi zasadami wgrywania danych z zakładu i eksportu wyników z powrotem.

Logowanie i ślad po decyzjach: nie tylko dla kontroli

RODO lubi logi, ale dobrze prowadzone dzienniki operacji pomagają też samemu zespołowi. Przy szkoleniu modeli przydaje się, aby dało się odpowiedzieć na kilka pytań także za rok:

• na jakim konkretnie zbiorze był trenowany dany model (wersja danych, okres, zakres),
• kto miał dostęp do tych danych i w jakim okresie,
• jakie przekształcenia danych zostały zastosowane (pseudonimizacja, agregacja, filtry),
• kto zatwierdził użycie danego modelu w produkcji.

Da się to zrobić „lekko”, bez armii compliance. Wystarczy, że:

• pipeline danych ma wersjonowanie (np. w repozytorium lub narzędziu typu Data Catalog),
• modele są wersjonowane (tagi, eksperymenty),
• istnieje prosty protokół akceptacji modelu (krótki formularz z opisem celu, zakresu danych i wyniku oceny ryzyka).

Przy ewentualnej kontroli taka dokumentacja pokazuje, że przetwarzanie danych pod kątem AI to nie jest „dziki zachód”, tylko powtarzalny proces z kontrolą ryzyk.

Minimum dokumentacyjne: co mieć w szufladzie zanim włączysz trening

Nie trzeba od razu tworzyć pięciusetstronicowej dokumentacji. Jest jednak kilka dokumentów, które dobrze mieć, zanim model zacznie jeść dane z produkcji:

• Opis procesu przetwarzania – kilka stron: cel, kategorie danych, źródła, miejsce trenowania (on‑prem/chmura/SaaS), podstawy prawne dla danych osobowych.
• Rejestr czynności / rejestr kategorii czynności – zaktualizowany o nowy proces „trenowanie modeli predykcyjnych na danych produkcyjnych”.
• DPIA (ocena skutków dla ochrony danych) – zwłaszcza gdy:
  • model dotyczy pracy ludzi (np. ocena efektywności, planowanie zmian),
  • przetwarzane są duże zbiory danych osobowych z wielu systemów,
  • jest ryzyko profilowania pracowników lub klientów.
• Procedura korzystania z danych produkcyjnych do prac rozwojowych – prosty dokument określający:
  • kto może inicjować projekty AI,
  • kto zatwierdza zakres danych,
  • jak wybiera się dostawcę i jakie minimalne zapisy muszą być w umowie.

Ten „pakiet minimum” mocno usprawnia rozmowę z IOD, prawnikiem i działem bezpieczeństwa. Zamiast ogólnej dyskusji „czy w ogóle można AI na naszych danych”, pojawia się konkret: na jakich danych, gdzie, w jakim celu i z jaką ochroną.

Przy większej skali projektów sensowne jest spięcie tego pakietu z istniejącymi procedurami jakościowymi (ISO, IATF). Część firm wpisuje trenowanie modeli do istniejących instrukcji pracy z danymi produkcyjnymi, zamiast budować równoległy, „kosmiczny” proces tylko dla AI. Dzięki temu kontrola widzi znajome formaty dokumentów, a inżynierowie nie muszą uczyć się całkiem nowego języka – zmienia się głównie zakres zastosowania i lista ryzyk.

Pomaga też zasada: każdy nowy projekt AI przechodzi krótki „przegląd startowy” z udziałem właściciela danych, IOD i IT/OT. To może być godzinne spotkanie z prostym szablonem pytań: co trenujemy, na czym, gdzie, z kim i co z tego potem wynika dla procesu produkcyjnego i ludzi. Zamiast długiej korespondencji mailowej jest jedna rozmowa, po której zostaje komplet uzgodnień i jasne „zielone” lub „czerwone światło”.

W praktyce ogranicza to też „dzikie” eksperymenty. Jeżeli wiadomo, że każdy projekt musi przejść przez wspólny stół, znika pokusa, żeby „na szybko” wrzucić surowe dane z produkcji do jakiegoś zewnętrznego narzędzia tylko po to, by zobaczyć, co z tego wyjdzie. Z punktu widzenia RODO i tajemnicy przedsiębiorstwa to właśnie takie spontaniczne próby bywają najbardziej ryzykowne.

Jeżeli w firmie działa już komitet sterujący ds. digitalizacji czy inwestycji IT, dobrze jest dołączyć projekty AI na danych produkcyjnych do jego agendy. Kilka zdań o nowym modelu na każdym spotkaniu – jaki zakres danych, jakie ryzyka, co zostało uzgodnione z IOD – wystarczy, żeby zarząd miał przekonanie, że temat jest pod kontrolą, a nie „dzieje się gdzieś w kącie serwerowni”.

Ostatecznie decyzja nie brzmi: „czy AI w ogóle wolno”, tylko: „na jakich warunkach chcemy je stosować w naszej fabryce”. Dla jednych rozsądny będzie prosty model predykcyjny trenowany lokalnie na mocno odchudzonych logach, dla innych – rozbudowane rozwiązanie w chmurze z udziałem zewnętrznego dostawcy. Klucz w tym, by wybór nie wynikał z przypadku czy marketingu, ale z trzech prostych filtrów: jakie konkretnie dane wypuszczamy z produkcji, gdzie i jak je przetwarzamy oraz kto będzie musiał to kiedyś wyjaśnić przed klientem, audytorem albo regulatorem.

Kluczowe Wnioski

• Kluczowym problemem nie jest sama obecność danych osobowych, ale miejsca, w których dane techniczne z maszyn realnie mieszają się z informacjami o ludziach i biznesie (np. połączenie SCADA, MES, CMMS i systemu wizyjnego w jednym modelu).
• Dane „maszynowe” rzadko są w 100% neutralne – w jednym rekordzie obok temperatur i prędkości mogą pojawić się identyfikatory operatorów, numery umów, nazwy klientów czy oznaczenia partii prowadzące prosto do reklamacji konkretnej osoby.
• RODO obejmuje nie tylko imię i nazwisko, ale też wszelkie identyfikatory (ID operatora, logi z HMI, nagrania z kamer, komentarze w systemach jakości), które w połączeniu z innymi danymi pozwalają rozszyfrować konkretną osobę.
• Nawet pozornie anonimowe pseudonimy (brygada, zmiana, unikalne uprawnienia na linii) mogą nadal być danymi osobowymi, jeśli w realiach zakładu wystarczy minimalna wiedza, by wskazać pracownika – model AI nie „widzi” problemu, ale RODO już tak.
• Dane nieosobowe też wymagają szczególnej ochrony, bo zawierają know-how i tajemnicę przedsiębiorstwa: receptury, parametry procesów, KPI linii, poziomy scrapu, warunki umów – model uczony na takich danych może stać się bocznym kanałem wycieku informacji do dostawcy technologii.
• Praktyczny start projektu AI to prosty podział wszystkich używanych danych na cztery koszyki: dane osobowe, dane osobowe szczególnych kategorii, dane poufne biznesowo oraz dane względnie neutralne – dopiero po takim „segregowaniu śmieci” ma sens dyskusja o architekturze i chmurze.