Firma chce automatycznie przepisywać dane z faktur, umów albo zeskanowanych formularzy do swojego systemu. Szybko pojawia się wtedy pytanie: wystarczy OCR, czy potrzebne jest już AI?
W praktyce odpowiedź rzadko brzmi „jedno albo drugie”. Pokażę, gdzie kończy się zadanie OCR, gdzie zaczyna się AI i dlaczego pomiędzy odczytaniem dokumentu a zapisaniem danych w systemie potrzebna jest jeszcze walidacja.
Jeśli masz faktury z KSeF w plikach XML, dane są już zapisane w nazwanych polach. Możesz je odczytać bez OCR i AI: narzędzie KSeF XML do Excela tworzy z nich zestawienie CSV, a pliki przetwarza w Twojej przeglądarce.
OCR zamienia obraz w tekst, ale nie musi rozumieć, co ten tekst oznacza
Najprościej mówiąc, OCR robi z obrazu tekst. Jeśli dostanę skan faktury zawierający napis „Razem do zapłaty: 12 480,50 zł”, zadaniem OCR jest rozpoznać litery i cyfry oraz zwrócić je w postaci, którą można dalej przetwarzać.
To ważny etap, ale sam OCR nie musi wiedzieć, że 12 480,50 zł jest kwotą do zapłaty, a nie wartością netto, podatkiem VAT czy pozycją z tabeli. Podobny problem pojawia się przy numerach NIP, datach, nazwach kontrahentów czy numerach umów.
Dlatego w rzeczywistym procesie odczytywanie danych z PDF wygląda raczej tak:
obraz → tekst → rozpoznanie pól → walidacja → zapis w systemie
OCR odpowiada przede wszystkim za pierwszy krok. Kolejne mogą być realizowane przez reguły, klasyczne mechanizmy programistyczne albo AI.
Jeżeli dokumenty zawsze wyglądają tak samo, AI może być zupełnie niepotrzebne. Formularz z pięcioma polami umieszczonymi zawsze w tych samych miejscach często łatwiej i taniej obsłużyć za pomocą OCR oraz prostych reguł.
AI jest przydatne wtedy, gdy dokument trzeba zinterpretować, a nie tylko przeczytać
Problem zaczyna się wtedy, gdy ten sam rodzaj informacji występuje pod różnymi nazwami i w różnych miejscach. Jeden dostawca używa pola „Termin płatności”, drugi „Płatne do”, a trzeci umieszcza datę w tabeli bez żadnej wyraźnej etykiety.
Człowiek zazwyczaj radzi sobie z tym bez zastanowienia, ponieważ rozumie kontekst dokumentu. AI może wykonać podobny krok: dostać tekst rozpoznany przez OCR i określić, które fragmenty odpowiadają interesującym nas informacjom.
Przy automatycznym odczytywaniu faktur mogę więc poprosić model o znalezienie numeru faktury, danych sprzedawcy, NIP-u, kwoty netto, VAT, brutto, waluty i terminu płatności. Przy umowie zestaw pól będzie zupełnie inny: strony, data podpisania, okres obowiązywania, wypowiedzenie czy wartość kontraktu.
OCR odpowiada więc na pytanie „co jest napisane?”, a AI częściej na pytanie „co ten fragment oznacza?”.
To jest praktyczna różnica między OCR a AI. Nie chodzi o wybór modniejszej technologii, tylko o poziom nieprzewidywalności materiału wejściowego.
W bardziej złożonych wdrożeniach dobrze działa również połączenie OCR z modelem językowym uruchomionym lokalnie. Tak działa workflow OCR z lokalnym modelem, który zbudowałem w n8n i FastAPI. Przy dokumentach po polsku jedną z opcji na tym etapie jest Bielik AI: otwarty model, który można uruchomić lokalnie.
Słaby skan psuje wynik jeszcze zanim AI zacznie analizować dokument
Załóżmy, że na fakturze widnieje kwota 18 300 zł, ale zdjęcie zostało zrobione telefonem pod kątem. Fragment strony jest zacieniony, tekst lekko rozmazany, a jedna cyfra została rozpoznana jako litera.
AI dostaje wtedy błędny materiał wejściowy. Może poprawnie zinterpretować strukturę dokumentu, ale nie odzyska informacji, której OCR wcześniej nie odczytał albo odczytał nieprawidłowo.
Dlatego przed analizą często potrzebne jest przygotowanie dokumentu: obrócenie strony, poprawienie kontrastu, usunięcie przekrzywienia czy rozdzielenie wielu stron. Dopiero później uruchamiam właściwe rozpoznawanie tekstu.
Nie każdy błąd jest jednak równie ważny. Literówka w opisie pozycji może nie mieć znaczenia, ale pomylenie 8 z 3 w kwocie albo numerze NIP może już uruchomić błędny proces księgowy.
Im gorsza jakość źródła, tym ważniejsze stają się mechanizmy kontroli wyniku, a nie tylko „lepszy model AI”.
To także jeden z powodów, dla których przy projektowaniu automatyzacji dokumentów warto analizować cały przepływ, a nie wyłącznie narzędzie do OCR.
Wyniku AI nie zapisuję bez kontroli bezpośrednio do systemu
Najbardziej ryzykowny wariant wygląda tak: dokument trafia do AI, model zwraca dane, a aplikacja automatycznie zapisuje je w ERP, CRM albo systemie księgowym. Technicznie można to zrobić. Biznesowo często nie powinno się tego robić.
Model może otrzymać nieczytelny dokument, pomylić dwie podobne wartości albo błędnie zinterpretować pole. Dlatego pomiędzy odczytem a zapisem stosuję walidację.
Dla faktury może ona sprawdzić na przykład, czy NIP ma poprawny format, czy suma netto i VAT odpowiada kwocie brutto, czy data płatności nie występuje przed datą wystawienia oraz czy waluta znajduje się na liście obsługiwanych walut. Jeśli wynik nie przechodzi kontroli, dokument może trafić do człowieka zamiast do automatycznego importu.
To nie oznacza, że każdą fakturę trzeba ręcznie zatwierdzać. Sensowniejszy model to automatyczne przepuszczanie przypadków pewnych i kierowanie do kontroli tylko tych, które są nietypowe albo niespójne.
Przy dużej liczbie dokumentów właśnie taki mechanizm daje największy efekt. Celem nie jest usunięcie człowieka z procesu za wszelką cenę, lecz ograniczenie jego pracy do przypadków, które rzeczywiście wymagają decyzji.
Proste faktury można automatyzować łatwo, ale umowy szybko pokazują granice systemu
Nie wszystkie dokumenty mają ten sam poziom trudności. Czysty PDF wygenerowany przez system księgowy jest zupełnie innym przypadkiem niż zdjęcie papierowej umowy z odręcznymi dopiskami.
| Dokument | Typowy poziom trudności | Co zwykle wystarcza |
|---|---|---|
| Faktura PDF z czytelnym tekstem | niski | odczyt tekstu + reguły |
| Faktury wielu dostawców | średni | OCR + rozpoznawanie pól + walidacja |
| Skan formularza o stałym układzie | niski/średni | OCR + reguły |
| Zdjęcie dokumentu z telefonu | średni/wysoki | przygotowanie obrazu + OCR + AI |
| Umowa wielostronicowa | wysoki | OCR + AI analizujące kontekst |
| Umowa z tabelami, aneksami i dopiskami | bardzo wysoki | AI + reguły + kontrola człowieka |
Przykładowo firma otrzymująca 200 podobnych faktur miesięcznie od kilku stałych dostawców może nie potrzebować rozbudowanej warstwy AI. Koszt budowy i utrzymania bardziej zaawansowanego rozwiązania może być większy niż oszczędność.
Sytuacja zmienia się, gdy dokumentów są tysiące, pochodzą z wielu źródeł i mają różne układy. Jeszcze większą wartość AI może dać przy umowach, gdzie istotna informacja nie zawsze znajduje się obok jednoznacznej etykiety. Trzeba wtedy nie tylko znaleźć tekst, ale zrozumieć jego znaczenie w kontekście całego dokumentu.
Dlatego przed wyborem technologii najpierw sprawdzam próbkę rzeczywistych dokumentów. Kilkadziesiąt przykładów zwykle mówi o problemie więcej niż długa lista funkcji narzędzi do OCR i AI.
Najpierw określ, które błędy możesz zaakceptować, dopiero potem wybierz OCR lub AI
Jeżeli mam ocenić, czego potrzebuje konkretny proces, nie zaczynam od pytania „jaki model AI zastosować?”. Najpierw ustalam, jakie dokumenty rzeczywiście wpływają do firmy, które informacje trzeba z nich pobierać i co stanie się, jeśli któraś wartość zostanie odczytana błędnie.
Dopiero później dobieram technologię. Czasem wystarczy OCR i kilka prostych reguł. Czasem potrzebne jest AI do rozpoznawania pól. Przy trudniejszych dokumentach dochodzi kontrola spójności, ocena pewności wyniku i ręczna weryfikacja wybranych przypadków.
Najlepszy system nie jest tym, który używa najwięcej AI, lecz tym, który dostarcza wystarczająco wiarygodne dane przy uzasadnionym koszcie obsługi.
Jeśli rozważasz automatyczne odczytywanie faktur, umów lub innych dokumentów, zacznij od zebrania kilkunastu lub kilkudziesięciu prawdziwych przykładów. Na ich podstawie można szybko ocenić, gdzie wystarczy OCR, gdzie potrzebne będzie AI i w których miejscach procesu konieczna jest dodatkowa kontrola.