LLM w automatyzacji biznesowej.

Trzy role, które LLM dobrze spełnia w workflow

Większość sensownych zastosowań LLM w automatyzacji mieści się w trzech kategoriach, które wracają u różnych klientów z różnych branż:

• Klasyfikacja nieustrukturyzowanego wejścia: mail, ticket, PDF, zgłoszenie przez formularz. Trzy-dziesięć kategorii, potrzebna jest jedna etykieta plus ewentualnie konfidencja. LLM daje 85-95 procent accuracy na realnych danych (bez fine-tuningu, z dobrze napisanym promptem).
• Ekstrakcja strukturalna: z dokumentu albo wiadomości wyciągam konkretne pola (kwota, NIP, numer zamówienia, data) do JSON albo schematu Pydantic. Kluczowe: validacja po stronie workflow, retry z poprawką, fallback na OCR przy trudnych dokumentach.
• Generowanie pierwszej wersji: draft odpowiedzi na maila, podsumowanie notatki ze spotkania, opis produktu z brief'a. Człowiek na końcu edytuje i wysyła, ale 60-85 procent pracy jest zrobione. Typowa oszczędność czasu 40-70 procent per task.

Wszystkie trzy scenariusze łączy jedna cecha: wejście jest tekstowe i nieustrukturyzowane, a regułowy pipeline zrobiłby się bardzo skomplikowany albo wymagałby dedykowanego modelu ML. LLM jest "wystarczająco dobry" za rząd wielkości mniejszy wysiłek niż klasyczne rozwiązanie.

Kiedy LLM wygrywa z klasycznym ML

Klasyczne uczenie maszynowe (Random Forest, XGBoost, BERT-owe klasyfikatory) ma niszę, w której wciąż wygrywa:

• Strukturalne dane tabelaryczne: klasyfikacja transakcji bankowych na podstawie kwoty, MCC, dnia tygodnia. Dobrze wytrenowany XGBoost bije LLM na dokładności i kosztuje ułamek w inferencji.
• Bardzo wąska domena z dużym datasetem: klasyfikacja zdjęć produktów w e-commerce z 10 000 przykładów per kategoria. Fine-tuned CNN albo CLIP dobijają do 99 procent accuracy, LLM zostaje w 85-90 procent.
• Realtime scoring: fraud detection na płatności, która musi być oceniona w 50 ms. Klasyczny ML model w pamięci zwraca wynik w mikrosekundach, LLM dodaje 1-3 sekundy opóźnienia.

LLM wygrywa gdy: nie masz labelowanego datasetu (albo masz 20-50 przykładów), kategorie są nieustalone albo ewoluują, input jest długi i kontekstowy, a koszt pojedynczej decyzji wynosi centy nie ułamki.

Koszt LLM w produkcji

Koszt operacyjny LLM dekomponuje się na trzy składniki:

• Input tokens: zawartość twojego promptu plus ewentualny kontekst (np. fragmenty z RAG). Dla klasyfikacji maila typowo 500-2000 tokens. Dla ekstrakcji z PDF o średniej długości 3000-8000 tokens.
• Output tokens: odpowiedź modelu. Dla klasyfikacji zwykle poniżej 100 tokens. Dla ekstrakcji 200-500. Dla generowania draftów 500-2000.
• Dodatkowe koszty: embeddings dla RAG (tanio, ułamek kosztu inferencji), context caching (jeśli ten sam prompt wysyłany wielokrotnie), fine-tuning (jednorazowy, kilkaset do kilku tysięcy PLN dla typowych zadań).

Kalkulacja ROI zaczyna się od: wolumenu (executions miesięcznie), średniego kosztu per execution (input plus output tokens × cena), porównanego z kosztem człowieka robiącego to samo. Jeśli ROI wychodzi dopiero przy skali, której nie masz, wdrożenie LLM warto odłożyć.

Prompt engineering w praktyce produkcyjnej

Prompt w produkcji to nie ciąg tekstu, który napiszesz raz i zapomnisz. To kawałek kodu z własnym cyklem życia:

• Versioning: prompty trzymam w repo obok kodu workflow, z wersjami i changelog. Zmiana promptu to commit z opisem "dlaczego".
• Test set: przy każdym prompt'cie mam kilkadziesiąt realnych przykładów z expected output. Przed deploy nowego promptu odpalam test, porównuję accuracy.
• Few-shot examples: dla klasyfikacji i ekstrakcji dokładam w prompt 3-7 przykładów z poprawnymi odpowiedziami. Poprawia accuracy o 10-20 punktów procentowych bez fine-tuningu.
• Output format: wymaga strukturalnego JSON albo Pydantic schema. Model zwracający free-text jest trudniejszy do przetwarzania niż model zwracający {"category": "X", "confidence": 0.9}.
• Guardrails przeciwko halucynacjom: w prompt explicite instrukcja "jeśli nie wiesz, zwróć null" plus validacja po stronie workflow. Model, który "strzela", gdy nie wie, jest gorszy niż model, który się przyznaje.

RODO, AI Act, tajemnica zawodowa

Trzy warstwy compliance, które sprawdzam przed wdrożeniem LLM u klienta:

• Miejsce przetwarzania danych: dla RODO-sensitive workflow wymagam region EU (Vertex AI europe-west4). Dla klientów z sektora regulowanego (finanse, zdrowie) dodatkowo DPA z dostawcą modelu i opcja zero-data-retention.
• AI Act 2026 (klasyfikacja ryzyka): workflow do podejmowania decyzji kredytowych, HR albo zdrowotnych mogą podpadać pod kategorię high-risk. To oznacza dodatkowe wymagania: dokumentacja systemu, human oversight, audit log decyzji. Dla większości workflow marketingowych i operacyjnych ryzyko jest minimal albo limited.
• Tajemnica zawodowa: dla kancelarii prawnej, biura księgowego albo służby zdrowia dane klientów nie mogą trafiać do modelu bez umowy powierzenia. Rozważam wtedy self-hosted open-source model albo dedykowaną instancję od dostawcy Enterprise.

Praktyczny test: czy jesteś w stanie pokazać klientowi końcowemu, kto przetwarzał jego dane i gdzie. Jeśli tak, jesteś OK pod RODO. Jeśli "no, używamy jakiegoś LLM, nie wiem dokładnie", trzeba to pozszywać przed live.

Pięć pułapek, które widzę najczęściej

• Optymistyczny benchmark: klient mówi "przetestowaliśmy i działa 95 procent". Pytam ile było przykładów w teście. "20". 20 to za mało na wyciąganie wniosków. Real accuracy po 1000 produkcyjnych execution zwykle jest 5-15 punktów niżej.
• Brak human-in-the-loop na starcie: workflow odpala automatyzację od pierwszego dnia bez nadzoru człowieka. Po tygodniu wychodzą błędy, których nikt nie wyłapał. Zawsze zaczynam od "LLM sugeruje, człowiek zatwierdza" i stopniowo zwiększam automatyzację, gdy stats się stabilizują.
• Prompt jako secret sauce w głowie jednej osoby: prompt, który ktoś napisał przez weekend i nie udokumentował. Po odejściu tej osoby nikt nie wie, dlaczego model odpowiada tak a nie inaczej.
• Brak monitoringu dryfu modelu: model działał 95 procent w styczniu, w czerwcu działa 78 procent. Bez ciągłego evala na bieżących danych tego nie wyłapiesz.
• Over-prompting: prompt urósł do 3000 tokens z warstwami instrukcji, przykładów i guardrails. Każdy call kosztuje 3x więcej niż trzeba, a accuracy nie rośnie. Regularnie robię "prompt diet": usuwam instrukcje, które nie wpływają na test set.

Najczęstsze pytania

Co warto przeczytać obok