Najczęstsze błędy w projektach AI

AI przemysłowe (industrial AI) nie upada przez algorytmy. Upada przez ludzi i procesy.

Jeżeli projekt AI w fabryce „nie dowiózł wartości”, to niemal na pewno nie dlatego, że model był za słaby. Upadał wcześniej – na etapie celu, odpowiedzialności, danych i decyzji operacyjnych.

W produkcji AI nie jest eksperymentem badawczym. Jest narzędziem – najczęściej modelem machine learning – wpływającym na koszt, bezpieczeństwo i ciągłość pracy. A mimo to wiele organizacji traktuje je jak demo technologii albo prezentację dla zarządu.

Poniżej dziesięć powodów, dla których projekty AI w przemyśle kończą się ciszą po pilocie i dlaczego to nie jest wina AI.

1) „Wdrażamy AI” to nie jest cel operacyjny

Projekt startuje od deklaracji „wdrażamy AI”. Ale to nie jest cel to jest hasło.

Bez wskazania konkretnego problemu biznesowego np. redukcji nieplanowanych przestojów przez predykcyjne utrzymanie ruchu lub obniżenia braków dzięki analityce jakości real-time – projekt niemal zawsze dowiezie coś: dashboard, model, wykres. Nie dowiezie natomiast decyzji.

AI bez jasno przypisanego celu operacyjnego to sztuka dla sztuki.

Co robić:

• Wybrać jeden koszt zdarzenia do obniżenia: przestój krytyczny, scrap, przekroczenia mocy, straty energii/mediów, zdarzenia bezpieczeństwa.
• Ustalić 2–3 wskaźniki sukcesu powiązane z ROI: MTTD/MTTR, poprawa OEE, koszt energii na partię, liczba interwencji uruchomionych „na sygnał”.
• Dopisać wskaźnik adopcji: kto używa wyniku, kiedy i w jakim procesie decyzyjnym.

2) Wynik istnieje, ale nikt za niego nie odpowiada

Model machine learning wykrywa anomalię, system generuje alert, dashboard świeci się na czerwono. I nic się nie dzieje. Bo w przeciwieństwie do maszyn, wyniki AI nie mają naturalnego właściciela. Jeżeli nie są wpięte w procedurę operacyjną, zostają „obok procesu”. W fabryce wszystko ma gospodarza. Jeżeli AI go nie ma – nie istnieje.

Co robić:

• Wyznaczyć Product Ownera w operacjach (produkcja/UR/energia/jakość), a nie w IT.
• Ustalić procedurę: sygnał → ocena → działanie → potwierdzenie efektu.
• Wprowadzić proces feedbacku jako część procesu (trafność sygnału, przyczyna, rezultat).

3) Dane z OT traktuje się jak prawdę objawioną

„Dane szeregów czasowych (time-series) mamy w Historianie, więc możemy trenować model.” To podejście jest błędne. Macie surowe sygnały, nie dane gotowe do analityki. Bez właściwej kontekstualizacji danych (data contextualization) model nie jest w stanie odróżnić normalnego od anormalnego.
Model uczony na nieopisanym kontekście nie jest inteligentny – jest losowy.

Co robić

• Zidentyfikować data pipeline od źródła (SCADA/PLC/historian) do wejścia modelu – luki w tym pipeline są miejscem, w którym większość projektów się wykłada.
• Wskazać wściela danych procesowych (kto odpowiada za znaczenie sygnałów i zmianę tagów).
• Zaplanować monitoring jakości danych do zakresu projektu.

4) Pilot działa, bo wszyscy go ręcznie ratują

Pilot często „wychodzi”, bo ktoś poprawia dane, ktoś interpretuje wynik, ktoś pamięta, że „to trzeba sprawdzić”. Skalowanie z proof of concept (POC) na produkcję wymaga standardów: modelu obiektowego, definicji KPI, zarządzania zmianą i bezpieczeństwem operacyjnym. Jeżeli rozwiązanie nie jest powtarzalne, ustandaryzowane i utrzymywalne nie jest rozwiązaniem, tylko prezentacją.

Co robić

• Zaplanować „co dalej po pilocie”: następne obiekty, następne linie, kolejne use-case’y.
• Pilnować powtarzalności: szablony KPI, alarmów i raportów zamiast każdorazowego projektowania od zera.
• Ustalić, kto utrzymuje rozwiązanie po pilocie (zespół, budżet, SLA/tryb wsparcia).

5) Organizacja próbuje zrobić wszystko naraz

Równoczesne wdrożenie integracji OT/IT, platformy danych, modeli machine learning i aplikacji użytkownika często przeciąża organizację i zwiększa ryzyko opóźnień.

Co robić

• Wprowadzić etapowanie: monitoring/KPI → alarmy i odchylenia → scenariusze → modele → automatyzacja.
• Ustalić „moment wartości” na etap (np. skrócenie diagnozy o X% w 6–8 tygodni).
• Pozwolić na ustabilizowanie integracji i danych przed intensywnym modelowaniem.

6) Model działa… do pierwszej zmiany procesu

Procesy produkcyjne ewoluują: receptury, surowce, nastawy, modernizacje. Model bez opieki podlega model drift – traci trafność w miarę zmian warunków, a zaufanie użytkowników spada.

Co robić

• Przygotować plan utrzymania MLOps: monitoring jakości predykcji, przeglądy, triggery retrainingu i procedury rollback.
• Ustalić odpowiedzialność za dopuszczanie nowych wersji modeli oraz procedurę wycofania (rollback).
• Traktować modele jak element konfiguracji produkcyjnej: version control, audit trail i change management – tak jak każdy inny zasób produkcyjny.

7) Operator dowiaduje się o AI na szkoleniu

W środowisku zmianowym liczą się prostota, jednoznaczność komunikatów i przewidywalna reakcja. Bez tego rozwiązanie bywa postrzegane jako dodatkowe obciążenie. Jeżeli operator liniowy (frontline operator) widzi AI pierwszy raz na slajdzie, to nie ufa progom, nie ufa alarmom, nie ufa rekomendacjom. A w środowisku zmianowym brak zaufania oznacza jedno: ignorowanie sygnałów. AI, które nie pasuje do rytmu zmiany, nie wejdzie do pracy.

Co robić

• Zaprosić operatorów i UR od początku do definiowania symptomów, progów i priorytetów.
• Stworzyć standard komunikatu operacyjnego: obiekt, pilność, uzasadnienie, rekomendowane kroki, zasady eskalacji.
• Zaplanować szkolenia oparte na realnych przypadkach i zdarzeniach, nie na prezentacjach ogólnych.

8) „Czarna skrzynka” zabija odpowiedzialność

Gdy system wpływa na decyzje kosztowe i bezpieczeństwa, organizacja potrzebuje nie tylko wyniku, ale także uzasadnienia i historii: co było przesłanką, co zrobiono i jaki był efekt. Bez tego trudno utrzymać standard działania i trudno bronić decyzji w audycie.

Co robić

• Wymagać minimalnego poziomu wyjaśnialności (explainability): jakie symptomy i trendy wpłynęły na sygnał.
• Wymuszać ślad decyzyjny: czas sygnału, działania, rezultat, wniosek.
• Dla obszarów krytycznych zastosować podejście hybrydowe: reguły + progi condition-based maintenance (CBM) / reliability-centered maintenance (RCM) + machine learning.

9) Cybersecurity traktuje się jak formalność

AI w fabryce generuje nowe przepływy danych i integracje OT/IT – a z nimi nowe powierzchnie ataku (attack surfaces) w cyberbezpieczeństwie OT. Bez zasad dostępu, audytu i gotowości operacyjnej projekt jest blokowany przez security albo staje się ryzykiem.

Co robić

• Zatwierdzić architekturę stref i kontrolowane punkty wymiany danych.
• Wymagać RBAC/SSO, rozdzielenia uprawnień oraz audytu zmian KPI/reguł/modeli.
• Pilnować logów, kopii i odtwarzania oraz procesu aktualizacji jako części rozwiązania.

10) Brakuje warstwy wiedzy, więc sygnał niczego nie zmienia

Sygnał bez ustandaryzowanej reakcji nie porządkuje pracy. Największą wartość daje połączenie danych z wiedzą ekspercką (domain expertise) skodyfikowaną w procedurach: checklisty, standardowe procedury operacyjne (SOP), wymagania BHP, standardy eskalacji i lessons learned z wcześniejszych incydentów.

Co robić

• Zbudować bazę wiedzy powiązaną z obiektami i zdarzeniami.
• Wprowadzić pętlę ciągłego doskonalenia: symptom → root cause analysis → działanie → efekt → lessons learned.
• Tam, gdzie ma to sens, uruchomić szybki dostęp do wiedzy oparty o zasoby wewnętrzne i kontrolę uprawnień.