Wdrażanie AI w zakładzie: checklist krok po kroku dla kierownika i IT

Na początek: co musimy rozstrzygnąć, zanim ruszy projekt

Krótkie pytania kontrolne, które najczęściej zadaje kierownik produkcji i lider IT/OT przed wdrożeniem AI w zakładzie. Jeśli choć na dwa nie ma jasnej odpowiedzi – zacznij od uzupełnienia braków.

• Jaki dokładnie problem biznesowy rozwiązuje AI i ile dziś nas kosztuje (przestój, braki, energia, jakość)?
• Dlaczego to jest pierwszy use case, a nie inny? Co zmierzymy i po czym poznamy, że się opłaca?
• Czy mamy dane o odpowiedniej jakości, zgodne z prawem i łatwo dostępne (formaty, etykiety, częstotliwość, uprawnienia)?
• Gdzie będzie działać inferencja: edge, on‑prem czy chmura? Jak połączymy to z PLC/SCADA/MES/ERP?
• Kto jest właścicielem procesu i kto operacyjnie odpowiada za model, po wdrożeniu 24/7?
• Jakie mamy bramy decyzyjne PoC → pilotaż → produkcja i kto podpisuje go/no‑go?
• Jak adresujemy cyberbezpieczeństwo i bezpieczeństwo funkcjonalne (SIL), skoro AI działa blisko maszyn?
• Jak unikamy vendor lock‑in i jaki jest uczciwy TCO przez 3 lata?
• Jak będziemy szkolić operatorów i co zrobimy, jeśli model się myli (procedury, fallback)?

Błąd 1: Zaczynanie od technologii, a nie od problemu procesu

Dlaczego szkodzi

Wybór narzędzia przed diagnozą kończy się dopasowywaniem procesu do produktu. Takie projekty miewają świetne demo i słabe liczby na hali. Brakuje wskaźnika bazowego (baseline), więc nie da się policzyć zwrotu, a dyskusja zamienia się w „czy to działa” zamiast „czy to opłaca się skalować”.

Jak rozpoznać wcześnie

• Slajdy z funkcjami modelu zamiast mapy strat procesu (scrap, przestoje, nadprodukcja, energointensywność).
• Brak twardego pytania: „O ile procent redukujemy X i jak to zmierzymy co tydzień?”
• Oferta dostawcy z gotowym „AI boxem” bez wglądu w Wasze dane i ograniczenia OT.

Lepsze podejście: problem → metryka → dane → narzędzie

Zacznij od konkretu: „redukcja braków na linii A o 15%, w ciągu 90 dni”. Określ metryki: FPY, OEE, energia na sztukę, MTBF, MTTR. Policz baseline z ostatnich 3–6 miesięcy. Dopiero potem pytaj, czy AI jest najlepszą dźwignią względem alternatyw (SMED, Poka‑Yoke, automatyzacja bez AI). Jeśli tak – opisz, jakie sygnały i decyzje będą wspierać operatora lub automatykę.

Przykład: zamiast „chcemy AI do wizji”, zdefiniuj „chcemy zmniejszyć reklamacje spoin o 30% dzięki wizyjnej detekcji porów ON‑LINE i regulacji parametrów spawania w 2 s od wykrycia”. To zawęża wybór do kamer, latencji, integracji z PLC i rodzaju modelu.

Błąd 2: Zły pierwszy use case – zbyt ambitny albo zbyt banalny

Skutki złego wyboru

Zbyt ambitny przypadek (np. pełna autonomizacja przepływu w złożonym procesie) kończy się „wiecznym PoC”. Zbyt banalny (np. raportowanie, które prostszy skrypt robi szybciej) nie buduje zaufania do AI i nie uzasadnia kosztu MLOps.

Kryteria selekcji pierwszego use case

• Wpływ: oszczędność roczna > 3× kosztu pilota/roku utrzymania.
• Wykonalność: dane dostępne od ręki lub w 4–8 tygodni; decyzja operacyjna możliwa w trybie doradczym lub półautomatycznym.
• Ryzyko: porażka nie zatrzymuje produkcji; istnieje bezpieczny fallback.
• Widoczność: wynik jest mierzalny w 90 dni (nie „kiedyś”).
• Skalowalność: rozwiązanie da się przenieść na 2–3 kolejne linie bez przepisywania wszystkiego.

Prosty scoring do decyzji

Oceń każdy kandydat 1–5 w pięciu kryteriach powyżej. Wybierz 2–3 najlepsze i przeprowadź szybkie warsztaty danych. Jeśli po audycie danych ocena spada poniżej 15/25 – przesuń przypadek na później.

Błąd 3: Dane w chaosie – brak jakości, etykiet i praw do użycia

Dlaczego to zabija projekt

Nawet dobry zespół i dostawca przegrywają z danymi z brakami: dziury czasowe, różne strefy czasowe, niespójne ID partii, zmiany nazw tagów w SCADA, brak etykiet w wizyjnym QC. Bez praw do danych (licencje na kamery, oprogramowanie) lub jasnych zasad prywatności – ryzyko prawne wstrzymuje wdrożenie.

Audyt danych: szybka lista kontrolna

• Zakres: które linie, które zmienne procesowe, z jaką częstotliwością i przez jaki okres?
• Jakość: brakujące wartości, latency, jitter, kalibracje, wersje receptur.
• Spójność: jednoznaczne łączenie zdarzeń (ID partii, stemple czasu zsynchronizowane NTP/PTP).
• Etykiety: kto je tworzy, jakim narzędziem, jak mierzymy ich rzetelność (inter‑annotator agreement)?
• Prawa: kto jest właścicielem danych i modeli; czy istnieją ograniczenia umów na sensory/SCADA?
• Dostęp: jak fizycznie pobieramy dane (historians, OPC UA, API MES), w jakim formacie i gdzie je trzymamy.

Data Readiness Level: prosta skala

1. Poziom 1: wiemy, że jakieś dane są.
2. Poziom 2: mamy próbkę danych, ale bez etykiet i z dziurami.
3. Poziom 3: mamy ciągły strumień i etykiety na małej próbce, uzgodnione prawa do użycia.
4. Poziom 4: komplet do PoC – dane dobrej jakości z 3–6 mies., jasne ID i prawa.
5. Poziom 5: gotowość do produkcji – pipeline, kontrole jakości danych, monitoring driftu.

PoC zaczynaj co najmniej od poziomu 3; pilota od 4; produkcję od 5.

Dwa krótkie przykłady

• Wizja: kamery mają nagrania, ale bez etykiet wad. Rozwiązanie: jedno popołudnie z trzema brygadzistami, 500 zdjęć oznaczonych w prostym narzędziu + definicja klasy „sporna”.
• Dane procesowe: SCADA archiwizuje co 1 s, ale PLC zmienia parametry między odczytami. Rozwiązanie: event‑based logging z PLC (na zmianę), synchronizacja czasu i bufor na edge.

Błąd 4: Rozmyte role kierownika, IT/OT i dostawcy

Objawy złej organizacji

• „Kto ma podpisać odbiór?” – projekt spowalnia, bo nie ma właściciela biznesowego.
• IT nie wie o testach na hali, OT dowiaduje się po fakcie o połączeniu do PLC.
• Dostawca sam narzuca scope i harmonogram, bo po stronie zakładu brak decyzyjności.

RACI dla wdrażania AI – minimum organizacyjne

• Właściciel procesu (kierownik produkcji/UR): Accountable – cel biznesowy, akceptacja KPI, priorytetyzacja.
• Lider IT/OT: Responsible – architektura, integracje, bezpieczeństwo, utrzymanie.
• Inżynier procesu/automatyk: Responsible – punkty integracji z maszynami, HMI, testy.
• Specjalista ds. jakości/energii: Consulted – definicje metryk i akceptacja wyników.
• Dostawca/partner: Responsible – modele, pipeline, dokumentacja, szkolenia.
• Zarząd/COO: Informed – bramy go/no‑go, budżet, komunikacja.

Rytm i artefakty zarządcze

• Kick‑off: 2 h, definicja KPI, baseline, ryzyka, architektury i ról.
• Weekly 30 min: ryzyka, metryki, blokery, decyzje.
• Go/no‑go bramy: koniec PoC, koniec pilota, start produkcji. Protokół z podpisami.
• Artefakty: karta projektu (1 strona), plan testów, karta bezpieczeństwa, RACI, dziennik zmian na maszynach.

Do listy rytmów dopisz jasne Definition of Done na

Definition of Done dla etapów PoC, pilota i produkcji

• PoC – zakończone, gdy: istnieje policzalny baseline; zebrano reprezentatywną próbkę danych; metryki modelu mierzone offline osiągają ustalony próg (np. recall/MAE); ryzyka techniczne opisane; decyzja: wchodzi do pilota, jeśli wynik > próg i koszt integracji mieści się w widełkach.
• Pilot – zakończony, gdy: model działa na realnych danych w czasie docelowym (latencja, SLA), zintegrowany z PLC/SCADA/MES; operator ma HMI i procedurę odrzucenia/superwizji; istnieje bezpieczny fallback; przeszkolono zespół; metryki biznesowe poprawiły się przez min. 4–6 tygodni; gotowa dokumentacja utrzymaniowa.
• Produkcja – start możliwy, gdy: jest monitoring zdrowia modelu i danych (drift), alerty i on‑call; wersjonowanie modeli i rollback w 1 klik; backupy i jawny plan aktualizacji; zatwierdzony plan bezpieczeństwa (ISA/IEC 62443), testy przywracania; podpisany RACI operacyjny.

Błąd 5: KPI bez progu akceptacji i brak „kontraktu na wynik”

Dlaczego hamuje postęp

Jeśli metryka nie ma progu i okna oceny, projekt grzęźnie w „jeszcze tydzień testów”. Zespół świętuje dobre sample, a linia nie widzi trwałej poprawy.

Jak rozpoznać wcześnie

• Prezentacje z pojedynczymi przykładami „hitów” i cisza o błędach.
• Brak rozróżnienia metryk technicznych (precision, MAE) i biznesowych (OEE, FPY, MTBF).
• Brak zdefiniowanego okresu obserwacji (np. 30 dni produkcyjnych).

Lepsze podejście: macierz akceptacji

• Ustal KPI główny i wspierające, np. „−12% braków na linii A w 8 tygodni” oraz progi skuteczności modelu (np. recall ≥ 0,9 przy FPR ≤ 0,05).
• Określ akceptowalne koszty uboczne (np. do 3% fałszywych alarmów/zmian receptury na zmianę).
• Wpisz do karty projektu: okno oceny (dni/zmiany), źródło danych referencyjnych i kto podpisuje wynik.

Krótki przykład: wizja QC – pilot jest „zdany”, jeśli przez 6 tygodni odsetek reklamacji spoin spada ≥ 25% vs. baseline, a liczba nieuzasadnionych odrzuceń nie przekracza 2% partii.

Błąd 6: Architektura niepasująca do procesu (edge/chmura/on‑prem)

Dlaczego szkodzi

Źle dobrane miejsce inferencji przesuwa problem: za duża latencja, niepotrzebne koszty chmury, trudny serwis na hali lub zbyt kruchy łańcuch integracji.

Jak wybrać mądrzej

• Latencja i deterministyczność: jeśli decyzja ma zapaść do 100 ms lub bez Internetu – inferencja na edge; gdy analiza jest partiowa/raportowa – chmura/on‑prem.
• Dostęp do danych: czy wymagane są surowe strumienie wideo/telemetrii? Jeśli tak, przenieś przetwarzanie bliżej źródła i wysyłaj tylko cechy/wyniki.
• Integracja: PLC/SCADA – preferuj OPC UA/MQTT i bufor na DMZ OT–IT; MES/ERP – API i kolejki (Kafka/AMQP) zamiast „punkt‑punkt”.
• Zgodność i koszty: dane wrażliwe/eksportowe – rozważ on‑prem; obciążenie nieregularne – chmura z autoskalą.

Wzorce minimalne

• Edge gateway z akceleratorem (GPU/TPU) + agent do aktualizacji modeli w oknie serwisowym.
• Warstwa pośrednia: broker MQTT/OPC UA + historyk danych; kolejka zdarzeń do systemów biznesowych.
• Jedno źródło prawdy dla konfiguracji (Git) i deklaratywne opisy wdrożeń (IaC/Ansible/K8s).

Przykład: detekcja defektów na prasie – model na edge (latencja < 50 ms), a do chmury idą tylko metadane i próbki „sporne” do re‑treningu.

Błąd 7: Cyberbezpieczeństwo i bezpieczeństwo funkcjonalne „na końcu”

Skutki zaniedbania

Stop‑test w ostatnim tygodniu, bo nie ma przeglądu zgodności lub ryzyko wymusza odłączenie od PLC. Czasem drobna luka (zły patch lub otwarty port) blokuje cały rollout.

Co wdrożyć od startu

• Segmentacja zgodnie z ISA/IEC 62443 (strefy i konduity) i jawny plan dostępu (jump‑server, MFA, logging).
• Model zagrożeń dla integracji AI z maszyną: co jeśli model się myli/opóźnia? Gdzie jest granica automatyzmu (SIL/PL)?
• Testy bezpieczeństwa: skan podatności narzędzi i kontenerów, kontrola SBOM, polityka aktualizacji offline.
• Procedury: HAZOP‑lite dla punktów ingerencji w proces, scenariusze awaryjne (manual override, E‑stop niezależny od AI).

Krótki scenariusz: predykcja awarii łożysk – AI tylko rekomenduje zjazd do serwisu, a decyzję wykonuje CMMS + brygadzista; nigdy automatyczny STOP bez ścieżki SIL.

Błąd 8: Lock‑in na modelach, danych i sprzęcie

Objawy

• Modele w niedokumentowanym formacie, brak prawa do eksportu wag.
• Dane trzymane w chmurze dostawcy, wysoki koszt egress.
• Edge na zamkniętym urządzeniu z własnym runtime – aktualizacje tylko przez vendor.

Jak się zabezpieczyć

• Zapisy umowne: prawa do danych i do wytrenowanych modeli; prawo do audytu i migracji w 30 dni.
• Otwarte formaty: ONNX/PMML dla modeli, Parquet/CSV dla danych, API dokumentowane.
• Architektura „pluggable”: adaptery do PLC/SCADA po standardach; modele jako kontenery; możliwość drugiego dostawcy na ten sam interfejs.
• TCO realistyczne: dolicz etykietowanie, egress, utrzymanie edge, retrening co X tygodni, testy regresji, wsparcie 24/7.

Błąd 9: Brak planu MLOps i operacyjnego utrzymania

Dlaczego wraca jak bumerang

Model działa w dniu 1, a w dniu 60 wyniki się rozjeżdżają: zmienił się surowiec, oświetlenie, receptura. Bez monitoringu i cyklu zmian zaczyna się ręczne gaszenie pożarów.

Elementy minimalne

• Repozytorium modeli i danych referencyjnych (model registry + wersjonowanie zestawów danych).
• CI/CD dla modeli: pipeline treningu, testy dokładności i bezpieczeństwa, zatwierdzanie, kanary/shadow‑mode.
• Monitoring: metryki predykcyjne, drift danych, opóźnienia, dostępność; alerty do on‑call.
• Runbooki: rollback, eskalacja, okna serwisowe, plan retreningu (np. co kwartał lub po przekroczeniu progu driftu).

Błąd 10: Pierwszy use case „brzmi dobrze”, ale nie dowozi wyniku

Skutki złego wyboru

• Miesiące pracy bez wpływu na OEE/FPY – trudno obronić kolejny budżet.
• Trudne integracje na start (np. 5 systemów, 3 działy) i rosnące ryzyko opóźnień.
• Brak sponsora biznesowego – decyzje się rozmywają.

Jak rozpoznać na etapie planu

• Nie ma jednego KPI biznesowego, który „cierpi” i który można policzyć co tydzień.
• Dane są rozproszone i wymagają wielu wyjątków lub intensywnej przebudowy linii.
• Po stronie hali – brak przygotowanego operatora, brak miejsca w HMI na komunikaty.

Lepsze kryteria wyboru (szybki scoring 1–5)

• Wpływ na wynik: prognozowana redukcja braków/awarii vs. koszt pilota.
• Dojrzałość danych: dostęp, jakość, etykiety, prawa do użycia – minimum 3/5.
• Integracja: ≤ 2 systemy krytyczne w pierwszym kroku (np. PLC + SCADA).
• Latencja: czy decyzja może być rekomendacją, a nie twardym sterowaniem na starcie?
• Sponsor: wskazany właściciel procesu gotowy podpisać akceptację.

Krótki przykład: zamiast „pełna optymalizacja receptury pieca”, zacznij od „wczesne wykrycie odchyleń temperatury strefy 3 i rekomendacja korekty” – jeden KPI, prosta integracja i szybka ocena wyniku.

Błąd 11: „Dane są” – bez jakości, etykiet i praw do użycia

Konsekwencje w projekcie

• PoC działa na wyczyszczonych próbkach, a produkcja widzi losowe spadki jakości.
• Spór prawny o wykorzystanie zapisów z kamer/SCADA lub brak zgody dostawcy maszyny.
• Przestoje z powodu niesynchronizowanego czasu – metryki z różnych źródeł nie „sklejają się”.

Audyt danych w 7 dni – co wiemy? czego nie wiemy?

• Źródła: lista topiców/zmiennych, częstotliwość próbkowania, odstępy, brakujące okna.
• Jakość: odsetek null, outlierów, zapadów komunikacji; profilowanie statystyczne per zmiana.
• Etykiety: skąd ground truth (QC, CMMS, waga), opóźnienie zapisu, zgodność definicji.
• Prawa: zapisy umów z OEM i regulaminy – czy wolno trenować i eksportować dane/modele.
• Czas: NTP/PTP na PLC/SCADA/edge, dryf zegarów, procedura korekty.

Co wdrożyć przed PoC

• Data contract: nazwy, jednostki, częstotliwość, SLA dostępności, właściciel zmiennej.
• Profilowanie automatyczne i sanity checks w pipeline; alert przy odchyleniu od rozkładu.
• Plan etykietowania: próbki „trudne”, podwójna adnotacja i zgodność (agreement) min. 0,8.
• Bufor na edge z 24–72 h historii + mechanizm re‑uploudu po utracie łącza.

Błąd 12: UX/HMI pominięte – operator nie ufa rekomendacjom

Objawy na hali

• Alarmy „zalewają” ekran, brak priorytetyzacji – po tygodniu wszyscy je ignorują.
• Model „wie”, operator nie – brak kontekstu, brak przyczyny i ścieżki odrzucenia.

Jak zaprojektować interakcję z AI

• Minimalny HMI: status modelu, pewność predykcji, sugerowana akcja, czas na reakcję.
• Tryby pracy: rekomendacja, shadow-mode, częściowa automatyzacja; jasne progi przełączeń.
• Priorytety alarmów: 3 poziomy z limitami częstotliwości; agregacja powtarzalnych zdarzeń.
• Ścieżka sprzeciwu: „odrzuć z powodem” zapisany do logów – paliwo do retreningu.
• Szkolenie 1 h na zmianę + karta skrócona przy stanowisku; kontakt do on‑call.

Przykład: wizyjna kontrola etykiet – zamiast „BŁĄD”, pokaż zdjęcie z zaznaczeniem obszaru i komunikat „brak kodu partii – zablokuj sztukę lub potwierdź poprawność”.

Błąd 13: Brak ścieżki audytu i walidacji jakości

Dlaczego wraca przy pierwszym audycie

• Nie ma dowodu, jaką wersją modelu podjęto decyzję w danej partii.
• QC nie uznaje wyników, bo definicje i progi nie są zatwierdzone w procedurach.

Co wdrożyć, by przejść audyt

• Śledzenie: ID modelu, wersja danych, commit konfiguracji i numer partii w jednym rekordzie.
• Walidacja analogią IQ/OQ/PQ: instalacja (edge/hardware), operacyjność (SLA/latencja), wydajność (KPI w oknie oceny).
• Retencja: logi decyzji i obrazów/próbek „spornych” z polityką przechowywania.
• Zmiany: procedura oceny wpływu (MoC) i podpisy jakości przy aktualizacji modelu.

Błąd 14: Skalowanie bez standardów między liniami i zakładami

Efekt domina kosztów

• Każdy pilot inny: inne złącza, inne formaty danych, inny edge – utrzymanie drożeje wykładniczo.
• Brak powtarzalnej listy „site readiness” – rollout ślimaczy się zakład po zakładzie.

Standaryzacja przed roll‑outem

• Profile referencyjne: 2–3 warianty architektury (latencja niska/średnia/wysoka) i gotowe BOM.
• Wspólne adaptery: OPC UA/MQTT, jednolite nazewnictwo tagów i jednostki (UCUM).
• Automatyzacja: IaC do edge, golden image systemu, polityka aktualizacji i kluczy.
• Katalog czujników/kamer: zatwierdzone modele, montaż, zasilanie, okablowanie.
• Site Readiness: check sieci (VLAN/DMZ), zasilanie, miejsce na szafę, zgody BHP/poż.

Końcowa checklista przed startem pilota i skalowaniem

Pilot – gotowość techniczna i organizacyjna

• KPI i progi akceptacji wpisane w kartę projektu; okno oceny i źródło prawdy zdefiniowane.
• Dane: zakończony audyt jakości/etykiet/praw; włączone profilowanie i alerty.
• Architektura: decyzja edge/chmura/on‑prem z uzasadnieniem; bufor danych i fallback.
• Integracje: przetestowane punkty PLC/SCADA/MES, kolejki zdarzeń i HMI z trybem „odrzuć”.
• Bezpieczeństwo: segmentacja 62443, jump‑server, SBOM, procedura patchowania.
• MLOps: registry modeli, pipeline CI/CD, monitoring driftu, plan retreningu.
• Role: RACI podpisane; on‑call i kontakty operacyjne aktywne.
• Szkolenia: operatorzy i UR przeszkoleni; karta skrócona na stanowiskach.

Skalowanie – gotowość do roll‑outu

• Wzorzec architektoniczny wybrany i udokumentowany; BOM i instrukcje montażu.
• Standardy danych i tagów przyjęte w skali firmy; data contracts per linia.
• Automatyzacja wdrożeń: IaC, obrazy edge, testy regresji przed każdym releasem.
• Umowy: prawa do danych i modeli, klauzula migracji, koszty egress policzone w TCO.
• Logistyka: harmonogram okien serwisowych, dostęp do szaf, rezerwa sprzętu.
• Audytowalność: ścieżka IQ/OQ/PQ dla każdej lokalizacji, retencja logów i próbek.

Najczęstszy poślizg na finiszu

Rozszerzenie scope tuż przed startem („dodajmy jeszcze tę linię i dwa alarmy”) potrafi wywrócić harmonogram i metryki. Zablokuj zmiany po bramie go/no‑go i wprowadzaj je dopiero jako kolejny, osobny inkrement – z własnym KPI i budżetem.

Błąd 15: Lock‑in na dostawcy i TCO z niespodzianką

Dlaczego szkodzi

• Koszty rosną po pilocie: opłaty od urządzenia/strumienia wideo + egress danych niszczą biznes‑case.
• Brak możliwości migracji: zamknięte formaty modeli i danych, brak prawa do retreningu poza usługą dostawcy.
• Ryzyko przerwy: jedyny dostawca i jedyna ścieżka serwisu – każda awaria to czekanie.

Jak rozpoznać na etapie umowy i architektury

• Formaty „własne”: brak eksportu modeli do ONNX/PMML, dane tylko w prywatnym blobie.
• Licencje: per kamera/per PLC/per linia, dodatkowe opłaty za inference na edge i za API.
• Egress i utrudnienia: płatne wyprowadzenie danych, brak BYO‑storage (S3 kompatybilne), brak obrazu kontenera do uruchomienia on‑prem.
• Prawa: brak klauzuli „right to train and export”, brak przenoszalności kluczy i obrazów.

Co zrobić lepiej

• Architektura wyjścia: prawo do eksportu danych + modeli, dostęp do kontenerów inference, format ONNX jako minimum.
• Otwarte interfejsy: OPC UA/MQTT/REST; własność danych po stronie klienta, przechowywanie w repozytorium firmowym (S3/NAS).
• Warunki finansowe: pułap na egress, indeksacja cen ograniczona, rozliczenie za wynik (KPI) zamiast wyłącznie „per urządzenie”.
• Plan B: escrow kodu/konfiguracji, kompatybilność z Kuberenetes/VM, możliwość roll‑back bez udziału dostawcy.
• Zakupy: krótkie kontrakty z opcją przedłużenia po pilocie, ocena TCO w horyzoncie 3 lat (CAPEX+OPEX+utrzymanie+szkolenia).

Krótki przykład: dostawca wizyjny licencjonuje „per kamera” i blokuje eksport nagrań. Alternatywa: kontener inference na edge, zapis próbki spornej w S3, model w ONNX, rozliczenie za przepustowość i SLA – bez kar za wyjście.

Błąd 16: Niewłaściwy wybór edge/chmura/on‑prem do charakteru procesu

Gdzie się wywraca

• Latencja: decyzje wymagające <100 ms biegną przez chmurę – straty jakości lub bezpieczeństwa.
• Łączność: zanik WAN zatrzymuje inference i alarmowanie; produkcja działa „na ślepo”.
• Gęstość danych: wideo/akustyka w GB/h pchane do chmury – koszty i opóźnienia eksplodują.
• Zgodność: wymagania rezydencji danych i audytu blokują wyjście poza site.

Wczesne sygnały błędnej decyzji

• „Twarde” sterowanie planowane od razu z modelu w chmurze.
• Brak bufora lokalnego i trybu degradacji (safe default) przy utracie łącza.
• Transmisja pełnego obrazu w wysokiej rozdzielczości poza site bez kompresji/feature’ów.
• Polityka IT: zakaz ruchu wychodzącego z OT, a projekt wymaga stałego tunelu.

Decyzja architektoniczna – proste kryteria

• Latencja decyzji:
  • <50 ms – inference na edge; sterowanie przez PLC.
  • 50–500 ms – edge lub on‑prem (serwer w DMZ OT), agregacja lokalna.
  • sekundy+ – chmura dopuszczalna (rekomendacje, harmonogramy, analizy wsadowe).
• Łączność: niestabilny WAN – edge z buforem 24–72 h i mechanizmem re‑uploudu.
• Gęstość danych: wideo/audio – ekstrakcja cech na edge, do chmury tylko metadane i próbki sporne.
• Zgodność i audyt: wymagane logi lokalne + ścieżka IQ/OQ/PQ – preferuj on‑prem/edge.
• Utrzymanie: brak kompetencji do serwisu serwerów na site – prosty edge + zarządzanie centralne.

Scenariusz: kontrola wizyjna spoin. Wersja stabilna: inference na edge przy linii, do chmury trafiają metryki i 1–2% kadrów „spornych” do retreningu; trening modeli poza produkcją w chmurze lub on‑prem.

Błąd 17: Rozmyta odpowiedzialność między produkcją, IT/OT i dostawcą

Skutki w operacjach

• Długi MTTR: incydent „wisi”, bo nikt nie wie, kto ma reagować – model, sieć czy PLC?
• Brak akceptacji na zmianie: operatorzy obchodzą system lub ignorują alarmy.
• Spory o jakość: QC kwestionuje decyzje bez jasnej ścieżki eskalacji i dowodów.

Jak to rozpoznać zanim będzie za późno

• Brak RACI na incydenty (model, integracja, HMI, sieć, sprzęt) i brak on‑call z numerem.
• Procedury UR i instrukcje stanowiskowe nie zawierają kroków z AI/HMI.
• Brak „właściciela procesu” po stronie biznesu z prawem do akceptacji KPI.

Co ustawić zamiast

• RACI per obszar: kto triage, kto naprawia, kto akceptuje powrót do produkcji; czasy reakcji.
• On‑call: dyżur inżynierski (IT/OT/MLOps) z rotą i runbookami; test pagera raz w miesiącu.
• Zmiana i szkolenia: lider zmiany jako „champion” AI, 1 h onboard na zmianę + karta skrócona.
• Eskalacja jakości: jasna ścieżka „spór o decyzję” – zapis próbki, ID modelu, ocena QC w 24 h.
• Okna zmian: stałe sloty na releasy modeli/integracji, mini‑UAT z operatorem przy linii.

Co wiemy? Kto dziś odbiera alarm „model w shadow‑mode vs. produkcja”. Czego nie wiemy? Kto decyduje o rollbacku przy >5% odrzuceń na zmianie i jak to dokumentujemy.

Błąd 18: PoC bez punktu odniesienia (baseline) i grupy kontrolnej

Dlaczego szkodzi

• „Sukces” jest subiektywny: brak twardego porównania z dotychczasową metodą myli efekt nowości z realnym zyskiem.
• Nie wiadomo, co skalować: bez baseline nie policzysz ROI, MTBF czy FP/FN na tym samym koszyku przypadków.

Jak rozpoznać z wyprzedzeniem

• Brak opisanej metody liczenia KPI „przed” i „po” na tym samym oknie danych.
• Ocena „na żywo” bez rejestru przypadków i bez podpisu QC/produkcji.
• Model działa solo – brak trybu shadow albo A/B z ręczną decyzją referencyjną.

Co zrobić lepiej

• Baseline: licz te same KPI dla procedury obecnej (np. ręczna kontrola wizyjna) w zdefiniowanym oknie (np. 4 tygodnie, 3 zmiany).
• Shadow/A-B: uruchom model w cieniu i porównaj z decyzją człowieka/PLC; konfliktowe przypadki oznacz do przeglądu QC w 24 h.
• Źródło prawdy: jeden rejestr spraw z ID próbki, wersją modelu i werdyktem referencyjnym.

Przykład: kontrola etykiet. Najpierw mierzysz odsetek błędów operatorów vs. kontrola wtórna. Potem model w shadow‑mode; dopiero po 2–3 tygodniach zbieżności >X% przełączasz na „recommend” lub „gate”. Co wiemy? Z ilu przypadków liczymy skuteczność. Czego nie wiemy? Kto zatwierdza rozbieżności i kiedy.

Błąd 19: Chaotyczne dane i etykiety – brak wiarygodnego ground truth

Skutki

• Model uczy się sprzeczności: różne osoby inaczej oznaczają ten sam defekt.
• Brak śladu audytowego: nie da się odtworzyć, na czym trenował model i dlaczego zmienił zachowanie.

Wczesne symptomy

• Etykiety w Excelach/mailach, brak wersjonowania próbek i schematu klas.
• Drift definicji jakości: „zarysowanie lekkie” raz jest OK, raz NOK – bez daty wejścia zmiany.
• Brak polityki retencji: stare dane z innej receptury mieszają się z aktualną produkcją.

Korekta procesu danych

• Schema i instrukcja znakowania: definicje klas ze zdjęciami poglądowymi; 2‑osobowa weryfikacja spornych przypadków.
• Repo danych: wersjonowane zbiory (DVC/Lake), metadane: receptura, maszyna, czas, ID operatora.
• Zmiany w definicjach jakości: data wejścia, zakres, komunikat do zespołu; osobny zbiór do retreningu po zmianie.
• Próbki „trudne”: koszyk do okresowego przeglądu, min. 10% w walidacji, stały rozkład klas.

Scenariusz: w jednej zmianie „mikropęknięcie” klasyfikowane jako NOK, w innej jako obserwacja. Rozwiązanie: ujednolicony leksykon defektów z mini‑galerią referencyjną na HMI, a zmiany publikowane jak zmiana instrukcji stanowiskowej.

Błąd 20: Interfejs i alarmy niepasujące do pracy na zmianie

Dlaczego szkodzi

• Zmęczenie alarmami: operatorzy ignorują komunikaty, bo system „krzyczy” za często.
• Obejścia: wyłączanie funkcji lub praca na „manualu” bez zapisu decyzji.

Jak poznać, że UX jest problemem

• Wysoki odsetek „ack bez działania” na HMI.
• Długi czas od alarmu do reakcji mimo dobrej łączności i braku awarii.
• Feedback: „nie wiem, co mam zrobić po alarmie” lub „za dużo klików”.

Jak to poprawić

• Priorytetyzacja: 3 poziomy alarmów, każdy z jasnym działaniem „następny krok” (procedura/telefon).
• Higiena alarmów: próg histerezy, łączenie powtarzalnych zdarzeń, dead‑band czasowy.
• Kontext na HMI: zdjęcie/próbka, przyczyna, wersja modelu, guzik „zgłaszam błąd decyzji”.
• Tryb degradacji: jeden, widoczny przełącznik „safe default”; zapis kto i kiedy włączył.
• Testy z operatorem: 30‑min UAT przy linii przed każdym releasem modeli/interfejsu.

Co wiemy? Ile alarmów na godzinę na zmianę i jaki jest odsetek fałszywych. Czego nie wiemy? Czy operator dostał jednoznaczny krok działania po komunikacie.

Błąd 21: Cyberbezpieczeństwo OT traktowane „na końcu”

Konsekwencje

• Nieplanowane postoje: zablokowane aktualizacje, wygasłe certyfikaty, awarie dostępu zdalnego.
• Ryzyko audytowe: brak SBOM, brak ścieżki zatwierdzeń zmian w OT (MOC).

Jak wcześnie wykryć ryzyko

• Brak sponsorów po stronie bezpieczeństwa/IT w RACI i brak przeglądu MOC.
• Tajny „tunel” VPN z edge do chmury, brak jump‑servera i logów dostępu.
• Hasła w plikach konfiguracyjnych, brak rotacji kluczy i polityki certyfikatów.

Jak ustawić bezpieczne minimum

• Segmentacja i dostęp: sieci OT z DMZ, tylko połączenia inicjowane z OT; jump‑server z MFA i nagrywaniem sesji.
• Tożsamość i sekrety: krótkie certyfikaty dla edge, rotacja kluczy, brak haseł w czystym tekście, Vault/KMS.
• Zmiany w OT (MOC): checklista akceptacji dla każdego releasu modelu/softu, test cofnięcia (rollback) i plan okna serwisowego.
• SBOM i łatki: inwentaryzacja komponentów, ocena CVE przed wdrożeniem, kalendarz patchy zsynchronizowany ze zmianą.

Krótki przykład: kamera IP z domyślnym hasłem i otwartym portem do Internetu. Korekta: VLAN z listą ACL, PoE za firewallem, dostęp tylko z jump‑servera, rotacja haseł przez centralny system.

Błąd 22: Brak planu utrzymania modeli – drift i „nagła degradacja”

Dlaczego to boli

• Nowa partia materiału lub inny operator i metryki spadają z dnia na dzień.
• Skalowanie zatrzymane: każdy site wymaga „ręcznego” dostrajania bez przewidywalnego cyklu.

Jak to wychwycić zawczasu

• Brak monitoringu rozkładów cech i stabilności danych (PSI/KS) oraz brak alertów na drift.
• Nie ma budżetu i okna na retrening, a wersjonowanie modeli/danych jest tylko „na słowo”.

Plan utrzymaniowy zamiast gaszenia pożarów

• Monitoring: progi alertów na drift cech i etykiet, separacja metryk: pre‑decision, post‑decision, biznesowe.
• Retraining window: cykl (np. co 4–8 tygodni) z koszykiem „spornych” próbek i walidacją na hold‑out site.
• Wersjonowanie i roll‑back: model+data+konfiguracja jako jeden artefakt; test regresji przed publikacją.
• Budżet i role: czas ludzi (QC/MLOps) policzony w TCO; zatwierdzający po stronie procesu ma prawo „stop”.

Ostrzeżenie końcowe: najczęściej potyka się zespół, który „dowiezie” świetny pilot i nie zabezpieczy cyklu życia. Bez planu utrzymania nawet najlepszy model zacznie po cichu przegrywać z rzeczywistością.