Każda średniej wielkości firma produkcyjna w Polsce i całej UE przetwarza dziesiątki, a nawet setki papierowych lub skanowanych dokumentów dziennie — faktury od dostawców, zamówienia od odbiorców, listy dostawcze, zgłoszenia celne, rysunki techniczne z wymiarami. I przy większości z nich gdzieś siedzi pracownik, który ręcznie przepisuje wartości do ERP, SAP lub Excela. To nie jest problem, który firmy ignorują — to problem, który do tej pory nie opłacało się rozwiązywać inaczej.
W 2026 roku to się zmieniło. Nowoczesne systemy document intelligence — połączenie OCR (optycznego rozpoznawania znaków), modeli vision-language i logiki walidacyjnej — potrafią przetwarzać dokumenty ustrukturyzowane i półustrukturyzowane z dokładnością, której ręczne przepisywanie nie osiągnie. Ten artykuł wyjaśnia, gdzie ta technologia się opłaca, jak wygląda realne wdrożenie oraz gdzie leżą ograniczenia, o których żaden materiał marketingowy nie informuje.
Dlaczego klasyczne OCR nie wystarcza
Gdy większość ludzi słyszy „OCR", wyobraża sobie Tesseract lub Adobe Acrobat — narzędzia, które ze zeskanowanego tekstu robią tekst edytowalny. Do prostych przypadków to wystarczy. Do dokumentów przemysłowych — nie.
Problemy pojawiają się na kilku poziomach jednocześnie:
- Rozmazany lub przekrzywiony skan z 30-letniej faktury faksowej dezorientuje klasyczne OCR znacznie bardziej niż nowoczesny model VLM.
- Tabele, wymiary i schematy są dla tekstowego OCR martwym punktem — otrzymuje się poprawne znaki, ale traci się strukturę, z której wynika sens.
- Zmienność formatów: każdy dostawca ma inny szablon faktury. Klasyczne rozwiązania OCR radzą sobie z tym przez reguły per-szablon (rule-based extraction) — przy dziesiątkach dostawców oznacza to dziesiątki szablonów i permanentny serwis.
- Kontekstowy sens: liczba „1500" w prawym dolnym rogu strony może być numerem strony, numerem zamówienia albo kwotą w euro — bez kontekstu klasyczne OCR nie odróżni tych przypadków.
Nowoczesne VLM (vision-language model, np. Qwen2.5-VL) rozwiązują ten problem inaczej: nie odczytują tylko znaków, lecz rozumieją układ dokumentu i kontekst. To skok jakościowy, a nie ewolucyjny.
Jak wygląda pipeline document intelligence
Rzeczywisty przemysłowy pipeline przetwarzania dokumentów składa się z kilku warstw. Każda z nich może być punktem awarii, jeśli zostanie niedoceniona.
1. Ingestion i normalizacja
Dokument trafia jako zeskanowane PDF, zdjęcie z telefonu, e-mail z załącznikiem lub wynik EDI ze starszego systemu. Pierwszy krok to konwersja do jednolitego formatu wewnętrznego — z metadanymi (źródło, data wpływu, typ dokumentu).
Tu kryje się ukryty problem: przy zdjęciach z terenu jakość wejścia jest skrajnie zmienna. Nieostrość, cień, zagięcia — VLM radzi sobie z tym lepiej niż klasyczne OCR, ale nie nieskończenie lepiej. Jakość wejścia wciąż ogranicza jakość wyjścia.
2. Klasyfikacja dokumentu
Zanim uruchomi się ekstrakcja, system musi wiedzieć, co przetwarza. Faktura, zamówienie, list dostawczy i rysunek techniczny wymagają różnych schematów ekstrakcji. Klasyfikator (prosty model lub logika regułowa nad strukturą dokumentu) przypisuje dokument do właściwej kategorii.
3. Ustrukturyzowana ekstrakcja
Rdzeń pipeline: z dokumentu ekstrahuje się wartości według predefiniowanego schematu. Dla faktury są to typowo:
- Numer faktury, data wystawienia, termin płatności
- NIP dostawcy i odbiorcy
- Pozycje liniowe (opis, ilość, jednostka, cena netto, VAT, cena brutto)
- Kwota całkowita, numer konta bankowego, numer referencyjny
Modele VLM wykonują to bezpośrednio — na wejściu otrzymują obraz lub PDF, a na wyjściu zwracają JSON zgodny z zadanym schematem. Wynik odpowiada koncepcji structured outputs i JSON mode — model produkuje wyłącznie prawidłowy JSON z zdefiniowanymi polami.
W przypadku rysunków technicznych sytuacja jest trudniejsza: wymiary, tolerancje i specyfikacje materiałowe są rozsiane w geometrycznym kontekście schematu. Modele VLM-72B poczyniły tu wyraźny postęp, ale przy precyzyjnych dokumentach technicznych zaleca się człowieka w pętli do finalnej weryfikacji wartości krytycznych.
4. Walidacja i cross-check
Wyekstrahowane wartości przechodzą przez kilka warstw walidacji:
- Spójność matematyczna: suma pozycji liniowych musi odpowiadać kwocie całkowitej; VAT musi odpowiadać podanej stawce.
- Walidacja referencyjna: numer zamówienia na fakturze musi istnieć w ERP; NIP dostawcy musi znajdować się w bazie zatwierdzonych dostawców.
- Walidacja zakresowa: kwota faktury w przedziale typowym dla danego dostawcy (anomalie kierowane do ręcznej weryfikacji).
Ta warstwa walidacji jest kluczowa. W praktyce widzieliśmy przypadki, gdzie model poprawnie wyekstrahował liczby z dokumentu, ale kwota faktury nie odpowiadała sumie pozycji — błąd leżał w oryginalnym dokumencie, nie w ekstrakcji. Bez walidacji ERP zawierałoby niespójne dane.
5. Integracja z ERP i workflow
Zwalidowane rekordy trafiają do ERP przez API. Dokumenty z niskim confidence (model nie jest pewien wartości) lub z nieudaną walidacją trafiają do kolejki ręcznej weryfikacji — z oznaczeniem konkretnego pola, w którym wystąpił problem.
To właściwe podejście: nie pełna automatyzacja, lecz asystowana automatyzacja z jasnym human-in-the-loop tam, gdzie pojawia się niepewność.
Gdzie automatyzacja się opłaca, a gdzie nie
Nie każdy typ dokumentu jest równie dobrze przystosowany do automatyzacji. Na podstawie praktycznych wdrożeń można stwierdzić:
Bardzo odpowiednie: - Faktury od stałych dostawców (system „uczy się" formatu) - Standaryzowane formularze zamówień (własne i od partnerów handlowych) - Listy dostawcze z kodami kreskowymi lub kodami QR (podejście hybrydowe OCR + barcode) - Certyfikaty materiałów o określonej strukturze
Odpowiednie z zastrzeżeniem: - Faktury od nowych dostawców (pierwsze przetwarzanie wymaga większej kontroli) - Zamówienia otrzymane e-mailem w plain text lub HTML — tu LLM nad treścią wiadomości może działać lepiej niż OCR nad obrazem - Karty techniczne z tabelami parametrów
Mniej odpowiednie bez specjalistycznego rozwiązania: - Dokumenty pisane ręcznie, stare faksy niskiej jakości - Rysunki techniczne z kompleksowymi schematami geometrycznymi i tolerancjami — ekstrakcja działa, ale wymaga weryfikacji - Umowy i dokumenty prawne o skomplikowanej strukturze (tu wartościowszy jest LLM nad dokumentacją przemysłową niż czysty pipeline OCR)
Decyzje techniczne — chmura vs. on-prem
Większość firm, z którymi pracujemy, staje przed pytaniem: chmurowe API czy własna instalacja?
Cloud API (Azure AI Document Intelligence, Google Document AI, AWS Textract): - Szybki start, zero infrastruktury - Model pay-per-page — przy dużych wolumenach (dziesiątki tysięcy dokumentów miesięcznie) koszty mogą być istotne - Faktury i zamówienia zawierają wrażliwe dane biznesowe — w branżach regulowanych lub przy wewnętrznej polityce GDPR chmura jest problematyczna
On-prem VLM (np. Qwen2.5-VL-72B skwantyzowany):
- Pełna kontrola nad danymi — żaden egress
- Wyższe wymagania VRAM: model 72B wymaga konfiguracji multi-GPU (rząd 40+ GB VRAM dla inferencji)
- Jednorazowa inwestycja w sprzęt, następnie koszt marginalny bliski zeru przy skalowaniu wolumenu
Dla większości firm przemysłowych w UE argument on-prem jest mocny, jeśli dysponuje się wystarczającym wolumenem (rzędu tysięcy dokumentów miesięcznie). Przy niższych wolumenach lub szybkim starcie cloud API może być rozsądnym punktem wyjścia z planem migracji.
Integracja ze structured outputs i ERP
Krytycznym szczegółem w tym pipeline jest niezawodność formatu wyjściowego z LLM. Model, który raz zwraca czysty JSON, a innym razem JSON opakowany w blok markdown, jest dla zautomatyzowanej integracji bezużyteczny.
Nowoczesne modele obsługują constrained decoding — model generuje tokeny zgodnie z zdefiniowanym schematem JSON, przez co fizycznie nie jest w stanie zwrócić nieprawidłowego JSON. To konieczność, nie opcja, w przypadku wdrożeń produkcyjnych. Więcej na ten temat w artykule Structured outputs i JSON mode.
Dla integracji z ERP obowiązuje zasada: nigdy nie piszcie bezpośrednio do ERP z modelu AI. Standardowy wzorzec to:
- 1.AI ekstrahuje i waliduje → wynik do tabeli staging
- 2.Reguły walidacyjne (skrypt lub workflow engine) sprawdzają spójność
- 3.Przy sukcesie → automatyczny import do ERP; przy niepewności → kolejka do ręcznej kontroli
- 4.Ludzki recenzent widzi dokument, wyekstrahowane wartości i konkretne pole z problemem
Ten wzorzec zachowuje audytowalność i zapobiega cichemu uszkodzeniu danych w ERP.
Rysunki i dokumentacja techniczna
Osobną kategorię stanowią rysunki techniczne — DXF, PDF z geometrią, schematy elektryczne. Tradycyjne OCR jest tu praktycznie bezużyteczne, ponieważ większość informacji leży w relacjach między elementami graficznymi, a nie w samym tekście.
Nowoczesne modele VLM potrafią z rysunku technicznego wyekstrahować: - Wymiary i tolerancje (z dokładnością zależną od jakości wejścia) - Opisy materiałów i wykończeń powierzchni - Numery części i rewizji
Gdzie wciąż potrzebna jest ludzka kontrola: krytyczne tolerancje bezpieczeństwa, schematy instalacji elektrycznej dla stref ATEX, dokumenty dla procesów certyfikacyjnych. AI pełni tu rolę asystenta, a nie autonomicznej decyzji — podobnie jak przy AI Copilot dla operatorów, gdzie model redukuje pracę, lecz nie zastępuje odpowiedzialności.
Typowe błędy przy wdrożeniu
Na koniec części technicznej — problemy, które widzimy wielokrotnie:
„Wdrożymy i zapomnimy" — pipeline document intelligence wymaga monitoringu. Nowy dostawca z niestandardowym szablonem faktury obniży confidence score i trafi do kolejki ręcznej; to jest w porządku, ale kolejka musi być obserwowana.
Niedocenianie zmienności — w pilotażu testuje się 50 faktur od 5 dostawców. Na produkcji jest ich 500, z czego niektórzy zmieniają szablony bez uprzedzenia. Testujcie na zróżnicowanej próbce, a nie na „czystych" przypadkach.
Confidence score bez kalibracji — model podaje pewność ekstrakcji, ale te wyniki są kalibrowane na danych treningowych, a nie na Państwa dokumentach. W pierwszych tygodniach produkcji śledźcie, gdzie model deklaruje „pewność" i gdzie popełniał błędy — na tej podstawie ustawcie progi dla ręcznej kontroli.
Ignorowanie przypadków brzegowych — co się stanie, jeśli przyjdzie faktura po niemiecku? Albo dokument z dwiema fakturami w jednym PDF? Te przypadki trzeba zdefiniować i zaimplementować jawnie, a nie liczyć na to, że model sam sobie z nimi poradzi.
Najczęstsze pytania
Jak dokładne są nowoczesne systemy ekstrakcji z faktur?
Dla ustrukturyzowanych faktur od stałych dostawców nowoczesne pipeline VLM osiągają w praktyce dokładność na poziomie 95–99% dla kluczowych pól (numer faktury, kwota, data). Dla nowych lub niestandardowych formatów dokładność jest niższa — dlatego kluczowa jest warstwa walidacyjna i kolejka ręcznej kontroli. Liczby z materiałów marketingowych (99,9%) pochodzą zazwyczaj z kontrolowanych testów, a nie z rzeczywistych wdrożeń produkcyjnych z pełną zmiennością wejść.
Czy do document intelligence potrzebne jest GPU?
Dla chmurowego API — nie; płaci się za wywołania API. Dla wdrożeń on-prem z modelami VLM (70B+) — tak; potrzeba rzędu 40+ GB VRAM dla rozsądnych latencji inferencji. Mniejsze modele (7–14B) poradzą sobie nawet z RTX 4090 (24 GB VRAM przy kwantyzacji), ale z niższą dokładnością na złożonych dokumentach technicznych. Do faktur i zamówień wystarczy model 7B z dobrą wydajnością.
Czy możemy to podłączyć do naszego SAP / Optima / innego ERP?
Tak — pipeline document intelligence produkuje ustrukturyzowany JSON, który można importować przez API ERP lub przez standardowe interfejsy integracyjne (REST, IDOC dla SAP, import CSV dla prostszych systemów). Sama integracja nie jest problemem; większą pracą jest zdefiniowanie logiki stagingowej i reguł walidacyjnych specyficznych dla Państwa procesów biznesowych.
Co z dokumentami w różnych językach (np. słowacki, czeski, angielski)?
Nowoczesne modele VLM są wielojęzyczne i obsługują większość języków europejskich bez specjalnej konfiguracji. Reguły walidacyjne (np. format NIP, IBAN) należy skonfigurować per-kraj. Jeśli przetwarza się duże wolumeny z określonego kraju, warto zweryfikować dokładność na rzeczywistych próbkach — wydajność nie jest zawsze jednakowa w różnych językach.
Jak długo trwa wdrożenie?
Prosty pilotaż na jednym typie dokumentu (np. faktury od top-20 dostawców) można uruchomić w 4–6 tygodniach. Pełne wdrożenie produkcyjne z integracją z ERP, monitoringiem i pokryciem wszystkich typów dokumentów mieści się w przedziale 3–6 miesięcy, w zależności od złożoności środowiska i liczby punktów integracyjnych.
*MP Industrial Solutions pomaga firmom przejść od ręcznego przepisywania dokumentów do weryfikowalnego zautomatyzowanego przepływu — od pilotażu na jednym typie faktury po wdrożenie produkcyjne z integracją ERP. Jeśli rozwiązujecie Państwo kwestie document intelligence lub zastanawiacie się, od czego zacząć, chętnie ocenimy Wasz konkretny przypadek.*