Trzy lata patrzyłem na ten sam pitch deck w różnych wersjach: „wdrożymy AI asystenta dla operatorów, zaoszczędzą 30 % czasu, ROI w 8 miesięcy". Rzeczywistość po 12 miesiącach w 10 wdrożeniach: cztery use-case'y, które się zwróciły (często trzykrotnie), i sześć, które zjadły budżet i zespół przeszedł od entuzjazmu przez frustrację do milczenia. Oto konkretne use-case'y z liczbami i kilka, które radzimy klientom odrzucić niezależnie od tego, ile mają wolnych pieniędzy.
Cztery use-case'y, które zarabiają
1. SOP search & shift-handover summary
**Use-case:** operator potrzebuje szybko znaleźć procedurę („jak zresetować alarm 14-021 na linii L4") albo przejmuje zmianę i chce mieć 90-sekundowy brief o tym, co działo się na poprzednich dwóch zmianach.
**Stack:** RAG nad dokumentami SOP + shift logs + maintenance tickets. Tablet na linii (Zebra ET40, Panasonic Toughbook) lub voice assistant przez Bluetooth headset (Plantronics Voyager 5200 UC) dla głośnych środowisk.
**Realne liczby z wdrożenia (niemiecki Tier-2 automotive supplier, 3-miesięczny pilot):** - 14 godzin / tydzień zaoszczędzonego czasu na zmianie i SOP-wyszukiwaniu przez 8 operatorów - Przy stawce godzinowej 28 EUR / h fully-loaded → **1 568 EUR / miesiąc oszczędności** - Wdrożenie i integracja: 38 000 EUR (RAG pipeline + 6 tygodni field tuning) - **ROI: 24 miesiące** w jednej linii. Przy skalowaniu na 4 linie → 8 miesięcy.
Kluczowe: nie graliśmy z „wgraj wszystko". Domenowy engineer z operatorem przeszedł 200 najczęstszych pytań ze zmianowego logu i tymi chunkami nastrojono retrieval. Pytania, które się nie pojawiają, nie były optymalizowane — ROI ich nie potrzebuje.
2. Troubleshooting wizard dla PLC / SCADA / robotyki
**Use-case:** Operator napotyka alarm, którego nie potrafi od razu zidentyfikować. Otwiera copilota, pisze „Allen-Bradley CompactLogix 5380, alarm code 16#0001, RPI exceeded" i dostaje: - opis błędu w języku naturalnym - top-3 najbardziej prawdopodobne przyczyny według historycznych ticketów - step-by-step diagnostykę - link do manuala Rockwell z dokładną stroną
**Stack:** RAG nad: manualami PLC (Rockwell Knowledgebase, Siemens TIA Portal docs, Beckhoff TwinCAT docs) + wewnętrzny issue tracker (Jira, ServiceNow, własny system) + fora społeczności (Plctalk.net, Reddit /r/PLC scraped). Embedding model: BGE-M3 lub Cohere multilingual. Reranker: BGE-Reranker-v2-m3.
**Realne liczby z wdrożenia (słoweński EMS producent, pełnoprawne wdrożenie 9 miesięcy):** - MTTR (Mean Time To Repair) spadł o 18 % w ciągu 6 miesięcy - Zastąpił nieformalną interakcję „pytam Piotra, który od 10 lat pracuje z tymi liniami" — Piotr mógł robić bardziej wartościowe rzeczy - Przy 200 incydentach / miesiąc × średnio 45 min MTTR × 18 % redukcji × 65 EUR / h technika → **8 775 EUR / miesiąc** - Wdrożenie: 52 000 EUR - **ROI: 6 miesięcy.**
Kluczowe: Piotr nie odszedł. Piotr pomagał trenować system — jego 10 lat doświadczeń zintegrowało się w prompt-templates i feedback loop. Bez Piotra system byłby generyczny i zwróciłby się za 24+ miesięcy.
3. Quality deviation reporting / 8D draft
**Use-case:** Linia wyprodukowała batch z odchyleniem (zła kalibracja, wada materiału, błąd operatora). Operator + quality engineer muszą spisać raport 8D, root cause analysis, corrective action plan. Trwa to typowo 4–8 godzin.
**Stack:** LLM (Claude Sonnet 4.6, lokalnie Llama 3.3 70B lub Qwen2.5-32B-Instruct) z dostępem do: szablonu 5 Why, formatu Ishikawa, historycznych raportów 8D firmy, wytycznych ISO 9001 / IATF 16949. Quality engineer opisuje defekt w 3–5 zdaniach, system generuje **draft** 8D — ludzki review i uzupełnienie pozostają.
**Realne liczby z wdrożenia (austriacki tier-1 metal forming):** - 8D draft time: z 6 h na 1,5 h średnio - 14 raportów / miesiąc × 4,5 h oszczędności × 55 EUR / h engineer → **3 465 EUR / miesiąc** - Wdrożenie: 18 000 EUR (prostszy stack, bo bardziej rygorystyczny format) - **ROI: 5 miesięcy.**
Kluczowe: AI nigdy nie zamknęło 8D — to jest human-in-the-loop gate. Generuje draft + propozycje działań prewencyjnych według precedensów. Bez review ROI zmieniłoby się w compliance risk.
4. Multi-language operator instructions
**Use-case:** Linia ma operatorów z 5 krajów (SK, UA, RO, PL, HU). SOP-y są w oryginale angielskim. Operatorzy potrzebują native-language wykładu krok po kroku.
**Stack:** GPT-5 lub Claude Sonnet 4.6 (cloud, business-tier subscription z GDPR EU region) z tool-call do native TTS (Azure Speech, ElevenLabs). Operator skanuje kod QR SOP-u, dostaje wykład w swoim języku, może zadawać pytania uzupełniające.
**Realne liczby (polski montaż elektroniki):** - Onboarding nowego operatora: z 12 dni na 7 dni (40 % redukcji) - Przy 6 nowych operatorach / kwartał × 5 dni × 8 h × 22 EUR / h fully-loaded → **5 280 EUR / kwartał = 21 120 EUR rocznie** - Wdrożenie: 24 000 EUR - **ROI: 14 miesięcy.**
Kluczowe: SOP-y były jakościowe w oryginale. Dla fabryk ze złymi, przestarzałymi SOP-ami system tłumaczy złe instrukcje — to nie tłumacz błędów, tylko bariera językowa.
Sześć use-case'ów, gdzie się nie zwróci
1. Real-time process control
„Dodamy AI, która w czasie rzeczywistym optymalizuje parametry na linii". Nigdy.
Latencja wywołania LLM to 800–3 000 ms. Process control loop pracuje na cyklach 10–100 ms. Poza tym: wymagania regulacyjne (IEC 61508, ISO 13849) wymagają deterministycznego zachowania — LLM z definicji ma niedeterminizm.
**Co zamiast:** klasyczny PLC + classical control (PID, MPC). LLM ma wartość **off-line w analizie logów i proponowaniu tuningu** parametrów — nie real-time inference.
2. Routine vision QA
„LLM z vision module ogląda zdjęcie detalu i mówi, czy ma defekt".
Multimodal LLM (GPT-4o, Claude Sonnet 4.6 vision) ma 3–5 sek latencji, 70–85 % accuracy w nieeksperckim zadaniu vision, $0,005–0,015 per obraz. Purpose-built vision system (Cognex VisionPro Deep Learning, Keyence CV-X) ma 30–80 ms latencji, 98–99,7 % accuracy, zero per-image cost po zakupie HW.
**Kiedy LLM ma sens:** **incident analysis** (po fakcie, ekspert chce szybką ocenę), edge case kategoryzacja (defekt, którego nie znał classifier), generowanie defect reportów z 50 zdjęć. Real-time QA na linii — nigdy.
3. Maintenance scheduling
„LLM decyduje, kiedy planować konserwację prewencyjną na podstawie usage patterns".
Na to istnieje CMMS (Computerized Maintenance Management System) — IBM Maximo, SAP PM, Limble, MaintainX. Systemy te mają deterministyczne reguły, integrację z ERP (co trzeba zamówić) i audytowalne logi. LLM nie dodaje wartości do optymalizacji, którą deterministyczny scheduler robi lepiej.
**Kiedy LLM pomoże:** **wyjaśnianie** dlaczego CMMS zaproponował konkretny harmonogram, summary report dla managementu („w tym tygodniu konserwacja zajęła 47 % kapacity zespołu, 60 % z tego było na linii L3, a trzy najczęstsze awarie to..."). Decision-making — nie.
4. Safety-critical interaction
„AI copilot mówi operatorowi, czy bezpiecznie jest wejść do strefy".
LSI (Life Safety Interlock) musi być FMEA-analizowany, certyfikowany (SIL 2/3), deterministyczny. LLM nie ma tu miejsca — ani jako kanał wtórny, ani informacyjny. Język LSI to: light curtain, safety relay, dwukanałowy start, manual reset, żadnego oprogramowania, nad którym stałby LLM.
**Kiedy LLM pomoże:** **symulacja szkoleniowa** scenariuszy safety dla operatorów poza strefą żywą. Live decision — absolutnie nie.
5. Inventory / orders / supply chain decisions
„AI zdecyduje, ile surowca zamówić, na podstawie trendów".
To zadanie systemu ERP-MRP (SAP S/4HANA, Oracle, NetSuite) z poprawnymi modułami forecast. LLM doda tu 5–10 % marginal accuracy w porównaniu z dobrze skonfigurowanym MRP i 30–50 % w porównaniu ze złym. Ale naprawienie złego MRP jest tańsze i bardziej zrównoważone niż dodanie warstwy LLM nad nim.
6. „Uniwersalny chatbot dla całej fabryki"
„Operator może zapytać o cokolwiek — SOP-y, HR, payroll, dane operacyjne, OEE, jakość, planowanie".
Single chatbot, który umie wszystko, umie źle wszystko. Authority boundaries (HR data vs. operational data vs. financial data) się rozmywają, role-based access control jest w LLM niemożliwy do zaimplementowania w sposób solidny (prompt injection breaks RBAC), a operator traci zaufanie przy pierwszej złej odpowiedzi.
**Lepsze podejście:** 3–5 wyspecjalizowanych copilotów z zawężoną domeną. Każdy z własnym RAG-iem, własnym system promptem, własnym audit logiem. Jednolite UI, wyspecjalizowany backend.
Stack decyzji w 2026
Lokalny vs. cloud LLM
**Lokalny (własny serwer GPU):** odpowiedni dla większych wdrożeń (50+ operatorów dziennie), branż regulowanych (automotive aerospace z ITAR-compliance), fabryk bez stabilnego internetu.
Konkretne modele w 2026: - **Qwen2.5-32B-Instruct AWQ** — 24 GB VRAM, doskonała zdolność multilingual, dobre dla języków EU - **Llama 3.3 70B AWQ** — 48 GB VRAM, silniejszy reasoning, lepszy do troubleshooting - **Mistral Small 3 (22B)** — 16 GB VRAM, dobry wybór dla cost-sensitive setupów
Hardware: 1× RTX A6000 (48 GB) lub 2× RTX 4090 (cumulative 48 GB) dla Llama 3.3 70B. Cena 12–18 k EUR. Throughput przy vLLM serving: 40–80 RPS przy typowym shop-floor query mix.
**Cloud LLM:** odpowiedni dla mniejszych wdrożeń, faz pilotażowych, projektów, w których nie potrzebują Państwo data residency. Default w 2026: **Claude Sonnet 4.6 (Anthropic EU region)** lub **GPT-5 (Azure OpenAI EU)**. Per-query cost typowo 0,002–0,012 EUR przy RAG z 4 k input tokenów + 300 output tokenów. Koszt miesięczny przy 200 zapytań / dzień × 22 dni × 8 operatorów = **75–250 EUR / miesiąc**.
UI: tablet vs. voice
**Tablet:** Zebra ET40 (3 800 EUR), Panasonic Toughbook G2 (4 200 EUR), Microsoft Surface Pro 11 w obudowie IP65 (2 800 EUR). Odpowiedni dla szczegółowego troubleshooting, foto attachment, rysowania schematów. Hałas linii nie przeszkadza.
**Voice (Bluetooth headset):** Plantronics Voyager 5200 UC (260 EUR), Jabra Engage 65 (310 EUR), Apple AirPods Pro 2 w industrial setup (310 EUR + custom dock). Odpowiednie do operacji hands-free, środowiska głośne do 95 dB z active noise cancelation. Latencja STT (Speech-to-Text) jest krytyczna — Whisper v3 large na lokalnym GPU 200–400 ms, cloud Azure Speech 250–500 ms.
W pilotach stwierdziliśmy, że **kombinacja** sprawdza się najlepiej: tablet do szczegółowej interakcji, voice do quick query („jak zresetować alarm 14-021" podczas marszu do maszyny).
Framework pilotażowy, który nie pali pieniędzy
1. **Wybiorą Państwo 1 (max 2) use-case'y** z rekomendowanych 4. Nigdy nie „wdrożymy wszystko naraz". 2. **Zdefiniują Państwo mierzalny KPI** *przed* startem: oszczędność godzin, redukcja MTTR, draft time, onboarding time. Bez baseline measurement ROI report będzie wishful thinking. 3. **8-tygodniowa faza PoC:** 4 tygodnie integracji + 4 tygodnie field testing z 6–10 operatorami. Żadnego skalowania przed zakończoną PoC. 4. **Stop-go gate po PoC:** jeśli KPI nie osiągnęły co najmniej 50 % celu, nie skalować. Sprawdzić stack lub anulować projekt. 5. **6-miesięczny rollout** do wszystkich operatorów + integracja z istniejącymi systemami (MES, CMMS, ERP read-only access).
Konkretny przykład ze wspomnianego niemieckiego suppliera: 80 godzin marnotrawstwa w integracji wynikło z tego, że zespół próbował połączyć AI copilota z **9 wewnętrznymi systemami** w fazie PoC. Realnie 6 z 9 okazało się zbędnymi, a 3 wystarczyły. Ale priorytet „integrate everything first" stracił pierwsze 3 miesiące projektu.
---
*Wdrażamy shop-floor AI copilot rozwiązania z 8-tygodniową PoC + 6-miesięcznym rolloutem. Jeśli rozważają Państwo ten typ wdrożenia, pierwszy warsztat (3 godziny) przejdzie 4 rekomendowane use-case'y na Państwa konkretnym procesie i odrzuci te, które nie zwrócą się w rozsądnym horyzoncie.*