AI do generowania instrukcji pracy: jak to działa i ile kosztuje

Najczęstsze pytanie, które dostaję od dyrektorów produkcji po przeczytaniu czegoś o "AI w fabryce", brzmi: dobra, ale jak to konkretnie działa, jeśli chciałbym wygenerować instrukcję stanowiskową dla nowej linii? Co dzieje się od momentu, gdy mam stos PDF-ów producenta i jedną starą instrukcję na Worda z 2019 roku, do momentu, gdy operator dostaje świeży, zatwierdzony SOP?

Ten tekst jest odpowiedzią na to pytanie. Z naciskiem na "konkretnie".

Piszę dalszy ciąg notatki o pięciu workflowach AI w polskiej produkcji, w której generowanie SOP wymieniłem jako jeden z najmniej ryzykownych wdrożeniowo workflowów. Tutaj rozwijam ten wątek o szczegóły, które do tamtego tekstu się nie zmieściły: jak wygląda pipeline, jakie ma warstwy, gdzie najczęściej kosztuje więcej niż się spodziewacie, jak zaplanować pilotaż i jakie są realne kategorie kosztów. Bez liczb wyssanych z palca, bez marketingu, bez slajdów "wystarczy włączyć".

Założenie: czytasz to z perspektywy operacyjnej, niekoniecznie technicznej. Jesteś dyrektorem produkcji, kierownikiem technologicznym, mistrzem albo szefem biura technicznego, który chce policzyć, czy ten workflow ma sens i co kupuje, jeśli powie "tak".

Spis treści

1. Co właściwie się generuje (i czego AI nie zrobi)
2. Architektura: cztery warstwy, które musisz mieć
3. Pipeline krok po kroku: od źródeł do zatwierdzonego SOP
4. Co decyduje o jakości wyniku
5. Kategorie kosztów (i gdzie ludzie się sparzą)
6. Pilotaż w 6 tygodni: realny plan
7. Kiedy NIE warto wdrażać
8. Czego tu nie pokrywam
9. Co dalej

Co właściwie się generuje (i czego AI nie zrobi)

Zanim cokolwiek, ustalmy zakres. "Generowanie instrukcji pracy" obejmuje dziś trzy rzeczy, które warto rozróżnić.

Pierwszy zakres: instrukcje stanowiskowe operacyjne. SOP, które operator ma przy maszynie. Sekwencja kroków, parametry, krytyczne punkty kontroli, akcje w razie odchyleń. To 70 do 80 procent typowego wdrożenia.

Drugi zakres: instrukcje BHP i procedury bezpieczeństwa. Generowane na bazie oceny ryzyka, dokumentacji producenta i wymagań prawnych. Tu AI pomaga, ale zatwierdzenie musi pochodzić od osoby z formalnym mandatem (BHP-owca, technologa). Ryzyko prawne za błędną treść spada na firmę, nie na narzędzie.

Trzeci zakres: instrukcje serwisowe i utrzymania ruchu. Procedury okresowych przeglądów, wymiany komponentów, diagnostyki. Sąsiaduje z workflow asystenta serwisowego, ale to inna ścieżka generacji.

Czego AI nie zrobi. Nie napisze instrukcji do procesu, którego nie ma w dokumentach. Jeśli mistrz "ma to w głowie" i nigdy nie spisał ustawień, AI tego nie wyciągnie. Można to nadrobić wywiadami nagrywanymi i transkrybowanymi (sam to robiłem), ale to dodatkowy projekt, nie efekt uboczny wdrożenia AI. To jest punkt, gdzie wiele firm się zatrzymuje. Mają nadzieję, że narzędzie "uzupełni" wiedzę milczącą, i są rozczarowane, gdy nie uzupełnia.

Drugi limit: AI nie zatwierdzi SOP w waszym imieniu. Zatwierdzenie to akt zarządczy z odpowiedzialnością prawną. Możecie zautomatyzować draft, walidację formatu i routing do osoby zatwierdzającej. Klik "zatwierdzam" pozostaje przy człowieku z mandatem.

Architektura: cztery warstwy, które musisz mieć

Każdy sensowny pipeline generowania SOP składa się z czterech warstw. Brak którejkolwiek psuje wynik. Jakość każdej z osobna decyduje o tym, czy w ogóle warto zaczynać.

Warstwa 1: Źródła wiedzy. Manuale producenta (PDF), istniejące instrukcje (Word, PDF), schematy techniczne, notatki ze szkoleń, opisy procesu, parametry z systemów MES/SCADA jeśli są wyeksportowalne, nagrania z wywiadów z mistrzami (transkrybowane). To jest baza. Jeśli baza jest słaba, reszta nie ma znaczenia.

Warstwa 2: Indeksacja i wektoryzacja. Dokumenty są dzielone na fragmenty, opisywane metadanymi (do której maszyny, której linii, której wersji procesu się odnoszą), wektoryzowane (zamieniane na reprezentację, którą model rozumie semantycznie). To jest serce techniczne. Tu siedzi RAG (Retrieval-Augmented Generation), o którym piszę szerzej osobno. Dla operacyjnego czytelnika ważne jest jedno: bez tej warstwy AI nie rozumie kontekstu waszej fabryki, generuje ogólniki.

Warstwa 3: Szablon i polityka generowania. Format SOP, którego używacie (struktura nagłówków, sekcje obowiązkowe, język, oznaczenia krytycznych punktów). Plus reguły: czego AI nie wolno powiedzieć (np. niejednoznaczności w sekcji BHP), kiedy ma poprosić o weryfikację człowieka, jakie metadane (autor, wersja, data, status zatwierdzenia) ma uzupełnić automatycznie. Tu wdrażacie waszą dyscyplinę dokumentacyjną, czego sam model nie wie.

Warstwa 4: Walidacja i zatwierdzanie. Pipeline routingu drafta do osoby odpowiedzialnej (technolog, kierownik produkcji, BHP, mistrz). Mechanizm porównania wersji, śledzenia zmian, podpisu cyfrowego lub elektronicznego zatwierdzenia. Bez tej warstwy generujecie świetne drafty, które zalegają miesiącami w "do akceptacji" i nigdy nie trafiają do operatora.

Cztery warstwy. Z mojego doświadczenia: warstwa 1 (źródła) zwykle wymaga najwięcej pracy. Warstwa 4 (walidacja) jest najczęściej niedoceniana. Warstwy 2 i 3 to "techniczne wnętrzności", którymi zwykle zajmuje się dostawca albo wewnętrzny zespół IT.

Pipeline krok po kroku: od źródeł do zatwierdzonego SOP

Konkretny przepływ, który widziałem w działających wdrożeniach. Zakładam, że tworzymy SOP dla nowego stanowiska na linii X.

Krok 1. Operator zlecenia (zwykle kierownik produkcji lub technolog) wskazuje zakres. "Potrzebuję SOP dla stanowiska Y na linii X, materiał A, wariant produkcyjny B." Wskazanie odbywa się przez interfejs (web, dedykowana aplikacja, formularz). Pod spodem system mapuje to na konkretne źródła: który manual producenta, które historyczne instrukcje, które notatki, które parametry z MES.

Krok 2. AI generuje draft. Wykorzystując źródła z kroku 1 i szablon z warstwy 3, model generuje pierwszy draft SOP. Zwykle 60 do 80 procent finalnej treści jest "od razu rozsądne". Pozostałe 20 do 40 procent wymaga korekt: terminy ujęte inaczej niż u was przyjęte, sekcje BHP wymagające doprecyzowania, brakujące referencje do norm.

Krok 3. Pierwsza walidacja automatyczna. System sprawdza formalnie: czy są wszystkie sekcje obowiązkowe, czy oznaczenia normatywne są zgodne ze słownikiem, czy nie ma niejednoznacznych sformułowań w sekcjach krytycznych. Jeśli coś nie gra, AI sygnalizuje. Jeśli wszystko gra formalnie, draft trafia do osoby zatwierdzającej.

Krok 4. Człowiek zatwierdza lub odsyła z uwagami. Technolog albo kierownik produkcji czyta draft. Zwykle: 15 do 30 minut na pierwszy przejazd, 5 do 15 minut na kolejne (gdy pipeline jest dotarty). Uwagi mogą być punktowe (zmień jedno zdanie) albo strukturalne (zmień podejście do sekcji X). Punktowe AI obsługuje natychmiast. Strukturalne wymagają nowego draftu z dodatkową instrukcją.

Krok 5. Zatwierdzenie i publikacja. Po finalnej akceptacji SOP dostaje numer wersji, podpis (elektroniczny lub cyfrowy), trafia do systemu dystrybucji (DMS, Confluence, dedykowany system, papier z barkodem na stanowisku). Stara wersja zostaje zarchiwizowana z możliwością odtworzenia.

Krok 6. Pętla zwrotna z operacji. Operator albo mistrz wskazuje, że SOP jest niespójny z rzeczywistością (np. zmieniliście narzędzie, dodaliście kontrolę). System zbiera te uwagi i przy następnej aktualizacji uwzględnia je w generowaniu. To ważne, bo bez pętli zwrotnej SOP starzeją się w tle, a wy o tym nie wiecie.

Pełen pipeline w działającym wdrożeniu: od momentu zlecenia do zatwierdzonego SOP zwykle 30 do 90 minut dla aktualizacji istniejącego, 2 do 6 godzin dla zupełnie nowego stanowiska. Porównanie do "tradycyjnie": 4 do 8 godzin dla aktualizacji, 16 do 40 godzin dla nowego.

Co decyduje o jakości wyniku

W kolejności malejącego wpływu (z mojego doświadczenia, bez pretensji do uniwersalności).

Jakość źródeł. Niespójna terminologia w manualach, stare wersje schematów, brak metadanych (jaki dokument do której maszyny), notatki w pięciu różnych miejscach. To jest pierwszy hamulec. Wdrożenie bez choć minimalnego porządku w źródłach zwraca rezultat na poziomie "lepiej napisać ręcznie".

Definicja szablonu SOP. Jeśli macie 50 instrukcji w 8 różnych formatach, AI nie wie, którego trzymać się jako wzorca. Decyzja "od którego formatu zaczynamy" to decyzja kierownicza, nie techniczna. W praktyce wybieracie jeden z istniejących (najlepiej najbardziej rygorystyczny) albo projektujecie nowy. Proces decyzyjny 1 do 3 dni warsztatowych, ale bez niego nie ruszacie.

Dostępność osób walidujących. Jeśli draft trafia do technologa, który dostępny jest dwa razy w tygodniu po godzinie, czas cyklu się rozjeżdża. Wdrożenie wymaga rozmowy z zarządem o priorytecie walidacji SOP. Często to oznacza, że pierwsze 2 do 3 miesiące dedykowana osoba (część etatu) zajmuje się tylko walidacją, dopóki rytm się nie ustabilizuje.

Wybór narzędzia i architektury. O tym osobno w sekcji o kosztach. Krótko: nie wszystkie platformy AI rozumieją dokumentację techniczną. Niektóre świetnie radzą sobie z tekstem ogólnym, słabo z tabelami parametrów, schematami i specyficznymi normami branżowymi (PN-EN, ISO, DIN, ASME). Test z waszymi rzeczywistymi dokumentami w trakcie ewaluacji jest niezbywalny.

Bezpieczeństwo danych. Manuale producenta są często chronione NDA. Wewnętrzne procesy to know-how firmy. Jeśli wdrożenie korzysta z publicznych modeli (OpenAI, Anthropic) bez izolacji, część firm produkcyjnych nie ma prawa tego zrobić (NDA producenta, polityka bezpieczeństwa, NIS2 dla podmiotów kluczowych). Decyzja architektoniczna (chmura publiczna, prywatne wdrożenie, on-prem) wpływa na koszt o 30 do 100 procent. Techniczny widok na tę decyzję piszę osobno na aionprem.pl, tu poprzestaję na widoku operacyjnym.

Kategorie kosztów (i gdzie ludzie się sparzą)

Realne kategorie kosztów wdrożenia AI do generowania SOP w firmie 100 do 300 FTE. Liczby z moich obserwacji rynkowych, nie z cenników wendorów.

Kategoria 1: Pilotaż.

• Zakres: jedna linia, 10 do 20 SOP, jeden typ dokumentów źródłowych.
• Czas: 4 do 8 tygodni.
• Koszt: 30 do 70 tys. PLN.

Co składa się na tę sumę: licencja (lub abonament) za okres pilotażu, prace integracyjne, czyszczenie wybranych źródeł, konfiguracja szablonu, szkolenie dla 3 do 5 osób, raport z pilotażu. Czego zwykle nie ma w cenniku: czasu waszych ludzi na walidację draftów. Realnie to 40 do 80 godzin czasu technologa lub kierownika produkcji w trakcie pilotażu. Wyceniajcie sami.

Kategoria 2: Pełne wdrożenie.

• Zakres: cała operacja, 80 do 200 SOP, wiele typów dokumentów.
• Czas: 4 do 6 miesięcy od decyzji go.
• Koszt jednorazowy: 120 do 350 tys. PLN.
• Koszt utrzymania rocznego: 80 do 220 tys. PLN.

Co składa się: licencja/abonament roczny, prace migracyjne (porządkowanie i indeksacja źródeł całej firmy), konfiguracja szablonów dla wszystkich kategorii SOP, integracje z systemami (DMS, ERP, MES jeśli relewantny), szkolenia szerokie (15 do 40 osób), procedury utrzymania (kto aktualizuje, kto monitoruje, kto audytuje treść).

Czego ludzie nie liczą:

Pierwsze: czas na czyszczenie źródeł. Często 30 do 50 procent kosztu całego wdrożenia. Jeśli wendor mówi, że "źródła nie są problemem", pytajcie dalej.

Drugie: koszt zmiany organizacyjnej. Zmiana procesu zatwierdzania SOP to często zmiana podziału odpowiedzialności. Coś, co robił mistrz "po godzinach", teraz robi formalnie inny dział. To rzadko kosztuje pieniędzy, ale często kosztuje czas zarządu na rozstrzygnięcie sporów kompetencyjnych.

Trzecie: koszt aktualizacji bazy wiedzy. Po pierwszych 6 do 12 miesiącach dokumenty się dezaktualizują (nowe normy, zmiany w maszynach, nowi dostawcy). Bez procesu ciągłej aktualizacji jakość wyników spada. Realny koszt: 0,2 do 0,5 etatu dedykowanej osoby do "knowledge ops".

Kategoria 3: Koszty ukryte infrastruktury.

Jeśli wybieracie wdrożenie on-prem albo prywatną instancję (typowo dla podmiotów kluczowych NIS2 lub firm z surowymi NDA producentów), dochodzi koszt sprzętu (zwykle GPU lub appliance), utrzymania (energia, klimatyzacja, monitoring) i administracji. Dla średniej firmy: 80 do 250 tys. PLN jednorazowo plus 30 do 80 tys. PLN rocznie.

Dla wdrożeń w chmurze publicznej te koszty wchodzą w abonament i zwykle są niższe per nominal, ale wracają w postaci ograniczeń architektonicznych (gdzie są dane, kto ma do nich dostęp, czy spełnia to wasze wymagania compliance).

Sumarycznie dla firmy 100 do 300 FTE, pierwszy rok łącznie:

• Wariant chmurowy: 150 do 400 tys. PLN.
• Wariant prywatny/on-prem: 250 do 600 tys. PLN.
• Drugi rok i kolejne: 80 do 220 tys. PLN rocznie (chmurowy) lub 110 do 300 tys. PLN rocznie (on-prem).

Liczby te należy traktować jako orientacyjne. Każda firma jest inna, każdy wendor wycenia inaczej. Ale zakres jest realny i odporny na trafienie w "niespodziankę dwukrotnie droższą".

Pilotaż w 6 tygodni: realny plan

Jeśli zarząd zaakceptował kierunek i chcecie zacząć, oto plan pilotażu, który widziałem działający.

Tydzień 1: Wybór zakresu i przygotowanie źródeł.

Wybieracie jedną linię produkcyjną. Najlepiej tę, na której jest między 10 a 20 instrukcji, jednolity typ dokumentacji producenta, czytelny technolog z mandatem do podejmowania decyzji walidacyjnych. Zbieracie wszystkie istniejące źródła (manuale, stare SOP, schematy, notatki) w jednym miejscu. Robicie audyt: czy są spójne, czy są aktualne, co brakuje.

Czas wewnętrzny: 8 do 16 godzin łącznie (technolog plus IT plus kierownik linii).

Tydzień 2: Konfiguracja narzędzia i szablonu.

Wendor (albo wasz zespół jeśli DIY) konfiguruje pipeline, indeksuje źródła z tygodnia 1, definiuje szablon SOP zgodny z waszym standardem. Pierwszy test: generuje 2 do 3 SOP "na sucho", żeby zobaczyć, jak wygląda jakość na waszych dokumentach.

Czas wewnętrzny: 4 do 8 godzin (technolog na walidację pierwszych testów).

Tydzień 3 i 4: Generacja 10 do 20 SOP.

Iteracyjnie: generujecie draft, technolog waliduje, AI uczy się na uwagach, generujecie kolejny. Po tygodniu jakość pierwszego draftu zwykle skacze (mniej manualnych korekt). Po dwóch tygodniach pipeline jest "dotarty" do waszej specyfiki.

Czas wewnętrzny: 30 do 50 godzin (technolog plus mistrz plus ewentualnie BHP w roli walidatora dla sekcji bezpieczeństwa).

Tydzień 5: Weryfikacja na produkcji.

Wybieracie 3 do 5 wygenerowanych SOP, dajecie do faktycznego użycia operatorom. Zbieracie feedback (czy instrukcja jest zrozumiała, czy zgadza się z rzeczywistością, czy są elementy mylące). Korygujecie.

Czas wewnętrzny: 8 do 16 godzin (mistrz plus kierownik linii plus operator).

Tydzień 6: Decyzja i raport.

Pomiar końcowy: ile godzin zaoszczędziliśmy w porównaniu do pisania ręcznego (mierzcie konkretnie), jaka jakość pierwszego draftu (procent treści, która nie wymaga korekty), ile czasu osoby walidującej. Raport dla zarządu z rekomendacją: rozwijamy, zatrzymujemy, zmieniamy podejście.

Czas wewnętrzny: 4 do 8 godzin (kierownik produkcji do napisania raportu, technolog do weryfikacji metryk).

Sumarycznie czas wewnętrzny pilotażu: 50 do 100 godzin pracy waszych ludzi. To jest druga rata kosztu pilotażu, której nie ma w cenniku wendora. Wycenione godzinowo (technolog 150 do 250 PLN, kierownik produkcji 200 do 350 PLN) to dodatkowe 10 do 30 tys. PLN.

Realny całkowity koszt pilotażu, czyli to, co zobaczy CFO: 40 do 100 tys. PLN. Jeśli wendor pokazuje wam 25 tys., dopytajcie, co jest poza zakresem.

Kiedy NIE warto wdrażać

Trzy sytuacje, w których generowanie SOP przez AI nie zwróci się w 18 miesiącach albo jest po prostu złym priorytetem.

Sytuacja 1: Mała firma z niską rotacją SOP. Jeśli macie 10 do 20 stabilnych instrukcji, których nie aktualizujecie częściej niż raz na 2 lata, wartość wdrożenia jest marginalna. Lepszy priorytet: porządek w istniejących dokumentach, ewentualnie prosty system zarządzania dokumentacją (DMS) bez warstwy generacyjnej.

Sytuacja 2: Brak osób walidujących. Jeśli nie macie technologa, kierownika produkcji albo dedykowanej osoby z mandatem do walidacji SOP, generowanie przez AI tworzy tylko więcej draftów w korkach zatwierdzeń. Wartość pojawia się dopiero, gdy jest komu pracować z generowanymi treściami.

Sytuacja 3: Operacja nieustabilizowana. Jeśli firma jest w trakcie poważnej restrukturyzacji, zmiany ERP, fuzji, przejęcia, zmiany lokalizacji, nowych linii produkcyjnych co miesiąc - generowanie SOP przed ustabilizowaniem procesów to praca w błotnistym terenie. Lepiej: poczekać 6 do 12 miesięcy, ustabilizować, potem wdrażać.

W każdej z tych sytuacji nie znaczy "nigdy". Znaczy "nie teraz".

Czego tu nie pokrywam

Trzy obszary, do których wrócę osobno.

Po pierwsze, techniczna architektura warstwy RAG. Jak konkretnie zaprojektować chunking, jakie embeddingi wybrać, jak optymalizować retrieval dla dokumentacji technicznej z tabelami i diagramami. Wracam do tematu osobno w klastrze RAG, też dla audytorium technicznego na aionprem.pl.

Po drugie, integracja z istniejącymi systemami zarządzania dokumentacją (DMS). SharePoint, Confluence, dedykowane DMS-y branżowe (np. SOLIDWORKS PDM dla firm konstrukcyjnych) mają różne profile integracji. Każdy zasługuje na osobne potraktowanie.

Po trzecie, AI Act i SOP. Czy generowany SOP jest "AI system" w rozumieniu AI Act, jakie są obowiązki, kto je przejmuje (wy jako operator czy wendor jako dostawca). Ważny temat, ale wymaga osobnej analizy prawnej. Najpewniej wrócę do niego, gdy AI Act wejdzie w fazę egzekwowania dla high-risk systemów (2027).

Co dalej

Jeśli ten workflow was interesuje, dwa konkretne kroki, które warto zrobić w najbliższych tygodniach.

Pierwszy: inwentaryzacja źródeł. Niezależnie od decyzji o wdrożeniu, audyt waszej dokumentacji technicznej to praca, która zwraca się sama. Pół etatu przez miesiąc i wiecie, gdzie naprawdę jesteście.

Drugi: rozmowa z technologiem i kierownikiem produkcji o priorytecie aktualizacji SOP. Jeśli odpowiedź brzmi "robimy, gdy mamy czas", AI tego nie zmieni. Jeśli odpowiedź brzmi "robimy systematycznie, ale to się nie nadąża", AI ma sens.

Trzeci, bonusowy: jeśli macie pilotaż w głowie, ale chcecie najpierw policzyć "co to znaczy konkretnie u nas", chętnie wymienię obserwacje. Bez handlowca, bez deck'a, 30 minut. Wystarczy umówić termin.

Następna notatka: asystent serwisowy AI w średniej firmie produkcyjnej - dlaczego to najczęściej pierwszy workflow, który firmy wybierają, i co o nim warto wiedzieć, zanim podpiszecie pilotaż.

---

Fryderyk Pryjma pisze o AI w polskiej i europejskiej produkcji. Pracuje też nad własnym narzędziem w tej kategorii.