Najgroźniejszy błąd w automatyzacji dokumentów nie polega na tym, że model AI raz źle rozpozna fakturę. Problem zaczyna się wtedy, gdy organizacja traktuje wynik modelu jak decyzję biznesową i bez dodatkowej kontroli przekazuje dokument do księgowania, płatności, archiwizacji albo udostępnienia.
Dobrze zaprojektowany obieg działa inaczej. AI może rozpoznać, że plik wygląda jak faktura, umowa, reklamacja czy zamówienie, odczytać pola i przypisać wynikowi confidence score. Dopiero kolejne reguły określają, czy wynik można przyjąć automatycznie, skierować do pracownika czy całkowicie zatrzymać.
To ważne również dlatego, że confidence score nie jest uniwersalną gwarancją poprawności. Microsoft Document Intelligence zwraca wartości od 0 do 1 i opisuje je jako oszacowanie pewności predykcji, ale ich praktyczna interpretacja zależy od modelu, klasy dokumentu, danych treningowych i rodzaju pola. Wynik 0,97 nie oznacza więc automatycznie, że w każdym procesie można zaakceptować dokument bez kontroli.
Bezpieczny system zaczyna się od ustalenia, jaki błąd firma jest gotowa zaakceptować i ile ten błąd kosztuje.
Confidence score trzeba skalibrować do konkretnego procesu, nie do intuicji
Najczęstszy skrót projektowy wygląda tak: „jeżeli confidence przekracza 90%, dokument akceptujemy”. Taka reguła jest wygodna, ale sama liczba nie mówi jeszcze, czy próg ma sens.
Załóżmy, że system rozpoznaje cztery klasy dokumentów:
- faktura kosztowa,
- zamówienie,
- umowa,
- korespondencja ogólna.
Dla faktur błędne zaklasyfikowanie dokumentu jako korespondencji może opóźnić jego obsługę. To problem operacyjny, ale zwykle odwracalny. Znacznie poważniejsza jest sytuacja odwrotna: zwykłe pismo zostaje błędnie uznane za fakturę i trafia do procesu finansowego.
Dlatego ten sam próg dla wszystkich klas jest zwykle złym pomysłem.
Można przyjąć przykładowy, wyłącznie ilustracyjny mechanizm:
- faktura z confidence co najmniej 0,98 oraz kompletem wymaganych danych — przechodzi do następnego etapu automatycznego;
- wynik od 0,90 do mniej niż 0,98 — trafia do szybkiej weryfikacji człowieka;
- poniżej 0,90 — dokument trafia do kolejki wyjątków;
- dokument niepasujący do znanych wzorców — niezależnie od score trafia do człowieka.
Te liczby nie są normą techniczną ani rekomendacją dla każdej firmy. Próg należy wyznaczyć na reprezentatywnym zbiorze dokumentów i sprawdzić osobno dla poszczególnych klas. W procesie obejmującym kilka typów faktur warto przetestować osobno faktury elektroniczne, skany, zdjęcia telefonem, dokumenty wielostronicowe oraz formularze dostawców stosujących nowe szablony.
Sam test „ogólnej accuracy” również jest za mało użyteczny. Potrzebne są co najmniej:
- precision dla klasy — jaki odsetek dokumentów oznaczonych przez AI jako dana klasa rzeczywiście do niej należy;
- recall — jaki odsetek dokumentów należących do klasy system w ogóle wykrył;
- liczba false positive, czyli dokumentów niesłusznie wpuszczonych do procesu;
- liczba false negative, czyli dokumentów, które powinny zostać obsłużone, ale zostały odrzucone lub źle przekierowane;
- odsetek dokumentów wymagających ręcznego poprawiania, czyli rework rate.
Przy fakturach koszt błędu false positive może być zdecydowanie wyższy niż koszt false negative. W przypadku klasyfikacji korespondencji reklamacyjnej sytuacja może wyglądać odwrotnie: przeoczenie reklamacji z terminem odpowiedzi może być bardziej dotkliwe niż wysłanie jednego zwykłego pisma do dodatkowej kontroli.
Próg musi więc wynikać z kosztu konkretnego rodzaju pomyłki, a nie z tego, że 95% wygląda „wystarczająco dobrze”.
Jest jeszcze jeden problem: wyniki confidence nie muszą być idealnie skalibrowane. Model może być regularnie zbyt pewny albo zbyt zachowawczy. Dlatego trzeba okresowo porównywać deklarowane przedziały confidence z rzeczywistą skutecznością. Jeżeli dokumenty z wynikiem 0,95–1,00 są poprawne tylko w 92% przypadków, organizacja powinna traktować to jako informację o zachowaniu własnego modelu, a nie zakładać, że sama wartość 0,95 rozwiązuje problem.
Microsoft zwraca też uwagę na różne poziomy confidence — przykładowo dla dokumentu, pola, słowa czy elementów tabeli. W praktyce to oznacza, że wysoka pewność klasy dokumentu nie gwarantuje poprawnego odczytu numeru rachunku, kwoty czy daty.
To szczególnie istotne w księgowości. AI może z dużą pewnością stwierdzić „to jest faktura”, a równocześnie źle odczytać jedną cyfrę numeru rachunku albo kwotę brutto. Klasyfikacja dokumentu i kontrola danych muszą więc pozostać dwoma osobnymi etapami.
Człowiek nie powinien sprawdzać wszystkiego, ale musi widzieć właściwe wyjątki
Ręczna weryfikacja każdego dokumentu zabija sens automatyzacji. Z kolei kontrolowanie wyłącznie rekordów z niskim confidence pozostawia niewidoczny obszar: błędy popełniane z wysoką pewnością.
Praktyczny obieg powinien więc mieć co najmniej trzy ścieżki.
Pierwsza to automatyczna akceptacja techniczna dla dobrze rozpoznanych, typowych dokumentów spełniających ustalone warunki. Słowo „techniczna” ma znaczenie. Jeżeli AI rozpoznało fakturę i poprawnie odczytało pola, nie oznacza to jeszcze automatycznej zgody na przelew.
Druga ścieżka obejmuje dokumenty niepewne: niskie confidence, brakujące pola, problemy OCR, nietypowy układ, sprzeczność danych lub nieznanego wystawcę.
Trzecia obejmuje przypadki, których nie należy automatyzować nawet przy bardzo wysokiej pewności modelu.
Dotyczy to zwłaszcza operacji takich jak:
- zatwierdzenie płatności,
- usunięcie dokumentu,
- ujawnienie informacji osobie trzeciej,
- zmiana okresu retencji,
- nadanie uprawnień,
- wykonanie nieodwracalnej operacji w systemie finansowym lub kadrowym.
Tutaj AI może przygotować decyzję, ale nie powinno automatycznie utożsamiać klasyfikacji z autoryzacją.
Dobry przykład daje obsługa faktur. System może sklasyfikować PDF jako fakturę, rozpoznać NIP, numer dokumentu, kwotę i termin płatności. Następnie zwykłe reguły biznesowe powinny sprawdzić między innymi, czy:
- kontrahent istnieje w ERP;
- numer rachunku zgadza się z danymi kontrahenta;
- suma netto, VAT i brutto jest logicznie zgodna;
- faktura nie została już zarejestrowana;
- wymagane pola nie są puste;
- dokument nie ma brakujących stron;
- wartość nie przekracza limitu wymagającego dodatkowej akceptacji.
Dopiero po tych kontrolach dokument może przejść dalej.
Szczególnego traktowania wymagają dokumenty OOD — out of distribution, czyli odbiegające od danych, na których model był budowany lub testowany. W praktyce będą to na przykład nowy szablon faktury zagranicznego dostawcy, skan o bardzo niskim kontraście, dokument z nietypową orientacją stron albo PDF zawierający jednocześnie fakturę i załącznik wyglądający jak drugi formularz.
Podobnie należy postąpić, gdy:
- liczba stron nie zgadza się z deklarowaną;
- dokument kończy się na stronie „2 z 3”, ale system otrzymał dwie strony;
- pola wzajemnie sobie przeczą;
- nagle pojawia się nieznany układ dokumentu;
- wymagane pole ma wartość pustą;
- model klasyfikuje dokument z wysoką pewnością, lecz reguły biznesowe wykrywają anomalię.
Takie przypadki powinny automatycznie trafiać do kolejki człowieka, nawet gdy sam confidence wygląda dobrze.
Jest też kontrola, którą firmy często pomijają: losowa próbka dokumentów z najwyższym confidence. Jeżeli sprawdzane są wyłącznie rekordy poniżej progu, firma nigdy nie dowie się, czy model nie zaczął popełniać systematycznych błędów z wysoką pewnością.
Można na przykład kontrolować losowo 1–5% automatycznie przyjętych dokumentów. To ponownie zakres ilustracyjny, nie gotowy standard. Wielkość próbki zależy od liczby dokumentów, konsekwencji błędów i stabilności procesu. Przy 200 dokumentach miesięcznie ręczne sprawdzenie 10 może być rozsądne. Przy 200 tys. potrzebne będzie sensowne próbkowanie statystyczne i monitoring według klas, źródeł oraz wersji modelu.
Najbardziej irytująca część takiego systemu pojawia się w okresie wdrożenia: kolejka wyjątków bywa początkowo większa, niż zakłada biznes. To normalne. Obniżanie progu tylko po to, żeby zwiększyć procent automatyzacji, zwykle maskuje problem zamiast go rozwiązywać. Najpierw trzeba sprawdzić, które klasy generują najwięcej ręcznej pracy i dlaczego.
Bez logów i analizy błędów nie wiadomo, czy automatyzacja nadal działa
Model, który działał dobrze trzy miesiące temu, nie musi działać tak samo dzisiaj. Dostawcy zmieniają szablony dokumentów, użytkownicy zaczynają przesyłać zdjęcia zamiast PDF-ów, pojawiają się nowi kontrahenci, zmieniają się pieczęcie, układ tabel czy sposób numerowania pól.
To jest drift danych, a czasem także drift samego procesu biznesowego.
Dlatego dla każdej decyzji AI warto rejestrować przynajmniej:
- identyfikator dokumentu;
- datę przetwarzania;
- nazwę i wersję modelu;
- klasę przewidzianą przez AI;
- confidence score;
- istotne wyniki ekstrakcji;
- informację o przejściu przez reguły walidacyjne;
- decyzję automatyczną lub człowieka;
- korektę wykonaną przez człowieka;
- przyczynę korekty;
- wersję konfiguracji progów.
W danych audytowych nie trzeba bezmyślnie kopiować pełnej treści każdego dokumentu. Zakres logowania powinien uwzględniać poufność, RODO, politykę retencji i zasadę minimalizacji danych. Celem jest możliwość odpowiedzi na pytanie „dlaczego ten dokument trafił tą ścieżką?”, a nie stworzenie drugiego, niekontrolowanego archiwum w logach.
Raz na tydzień lub miesiąc — zależnie od wolumenu i ryzyka — należy analizować błędy per klasa, a nie tylko jeden zbiorczy procent skuteczności.
Przykład: system ma 98,5% poprawności ogólnej. Wynik wygląda świetnie. Po rozbiciu okazuje się jednak, że faktury stanowią 90% wszystkich dokumentów i są rozpoznawane niemal bezbłędnie, natomiast aneksy do umów mają tylko 78% poprawnych klasyfikacji. Średnia ukryła więc problem właśnie w klasie, w której pomyłka może mieć poważniejszą konsekwencję.
Raport operacyjny powinien pokazywać co najmniej:
- liczbę dokumentów na klasę;
- udział automatycznych akceptacji;
- udział ręcznej weryfikacji;
- false positive i false negative według klasy;
- rework rate;
- błędy według dostawcy lub źródła dokumentów;
- zmianę rozkładu confidence w czasie;
- udział dokumentów nietypowych lub odrzuconych;
- porównanie wersji modelu.
Nowej wersji modelu nie należy wdrażać bez możliwości rollbacku. Praktyczna procedura powinna pozwalać szybko wrócić do poprzedniej wersji, jeżeli po publikacji wzrośnie liczba korekt albo pojawi się błąd dotyczący konkretnej klasy.
Potrzebne jest również jasne prawo wstrzymania automatyzacji. Jeżeli pracownik zauważy serię błędów — na przykład kilka faktur tego samego dostawcy z błędnie odczytanym numerem rachunku — powinien móc skierować tę klasę lub źródło dokumentów do ręcznej obsługi bez oczekiwania na przebudowę całego systemu.
Takie podejście jest zgodne z szerszym sposobem zarządzania ryzykiem AI opisywanym przez NIST AI RMF oraz przez ENISA: model trzeba traktować jako element pełnego cyklu życia systemu, obejmującego testowanie, wdrożenie, utrzymanie i kontrolę, a nie jako jednorazowo „wytrenowane” narzędzie.
Na gruncie europejskim dodatkowym błędem byłoby automatyczne stwierdzenie, że każdy system DMS wykorzystujący AI jest systemem wysokiego ryzyka w rozumieniu AI Act. Klasyfikacja regulacyjna zależy od przeznaczenia i zastosowania systemu, a nie od samego faktu wykorzystywania sztucznej inteligencji. Od 2 sierpnia 2026 r. zasadnicza część AI Act już obowiązuje, przy czym przepisy dotyczące określonych systemów wysokiego ryzyka mają dalsze terminy przejściowe.
Osobnym ryzykiem jest sposób przetwarzania dokumentów. Faktura może zawierać dane kontrahenta, umowa — informacje handlowe, a akta pracownicze — dane szczególnie wrażliwe dla organizacji. Nie należy wysyłać dokumentów firmowych do publicznie dostępnych usług AI bez ustalenia zasad przetwarzania, retencji, lokalizacji danych, dostępu administratorów i wykorzystania treści przez dostawcę. Najpierw trzeba sprawdzić umowę, konfigurację konkretnej usługi oraz politykę bezpieczeństwa organizacji.
Najważniejszą decyzją wdrożeniową nie jest więc wybór najwyższego możliwego progu confidence. Najpierw trzeba wybrać jedną klasę dokumentu, zebrać reprezentatywną próbkę, zmierzyć false positive i false negative, ustalić koszt obu rodzajów błędów i dopiero wtedy wyznaczyć próg automatycznej akceptacji. Następnie należy dodać ręczną kolejkę wyjątków i losową kontrolę wyników z wysokim confidence. Dopiero po tych krokach ma sens zwiększanie poziomu automatyzacji.
FAQ
Czy confidence score 0,99 oznacza 99% gwarancji poprawności?
Nie. To wynik pewności generowany przez konkretny model. Jego użyteczność trzeba sprawdzić na własnych, reprezentatywnych danych i obserwować, jak score przekłada się na rzeczywistą liczbę błędów.
Jaki próg confidence ustawić dla automatycznej klasyfikacji dokumentów?
Nie ma jednego prawidłowego progu. Należy ustalać go osobno dla klas dokumentów, biorąc pod uwagę precision, recall, koszt false positive i false negative, jakość dokumentów oraz wyniki testów. Próg 0,95 czy 0,98 może być punktem startowym eksperymentu, ale nie uniwersalną normą.
Czy przy bardzo wysokim confidence można zrezygnować z kontroli człowieka?
Nie w każdym procesie. Wysoki confidence może uzasadniać automatyczne wykonanie niskiego ryzyka, np. skierowanie dokumentu do odpowiedniego folderu. Nie powinien samodzielnie autoryzować płatności, usunięcia danych, ujawnienia informacji ani innych nieodwracalnych operacji. Dodatkowo należy kontrolować losową próbkę wyników o wysokiej pewności, aby wykrywać błędy systematyczne.
Co sprawdzić jako pierwsze w działającym już obiegu AI?
Najpierw zestaw ręczne korekty z klasą dokumentu, confidence score i wersją modelu. Jeżeli organizacja nie rejestruje tych trzech informacji, właśnie ten brak trzeba usunąć w pierwszej kolejności. Bez nich nie da się wiarygodnie ocenić progów, wykryć driftu ani ustalić, czy nowsza wersja modelu faktycznie poprawiła proces.
