--- title: "Model proponuje, kod rozstrzyga" url: "https://predictes.com/pl/blog/model-proponuje-kod-rozstrzyga" description: "Hiperautomatyzacja działa, gdy każdy krok trafia do właściwego wykonawcy: model czyta i proponuje, deterministyczny kod sprawdza i zapisuje, a resztę biorą ludzie." --- # Model proponuje, kod rozstrzyga 21 kwietnia 2026·3 min czytania·predictes Weźmy zwykły proces faktur zakupowych. Faktura przychodzi jako PDF na wspólną skrzynkę. Ktoś ją czyta, odszukuje zamówienie, porównuje ilości z przyjęciem magazynowym, dekretuje, sprawdza, kto może zatwierdzić taką kwotę, księguje i planuje płatność. Są dwa znane sposoby, żeby zautomatyzować to źle. Pierwszy pisze reguły do wszystkiego, łącznie z czytaniem, i przez następny rok utrzymuje szablony pod układ faktury każdego dostawcy. Drugi oddaje całość modelowi — „przeczytaj fakturę i ją zaksięguj” — co działa na pokazie i pada na pierwszym audycie, bo nikt nie umie powiedzieć, dlaczego konkretna faktura została zaksięgowana tak, a nie inaczej. Wersja, która działa, dzieli proces według rodzaju pracy w każdym kroku, a nie według systemu, którego ten krok akurat dotyka. ## Podział według rodzaju pracy **Czytanie.** Zamiana czegoś, co napisano dla ludzi, na pola: faktury, maila, dokumentu WZ, formularza reklamacji. W tym modele są dobre, a reguły najbardziej kruche. **Klasyfikowanie i redagowanie.** Jaki to rodzaj sprawy, do którego zespołu należy, jak powinna brzmieć odpowiedź albo propozycja dekretacji. To też praca dla modelu, o ile nic nie wychodzi z firmy wyłącznie na jego słowo. **Rozstrzyganie przy niejednoznaczności.** Czy reklamacja jest w istocie rezygnacją, czy pozycja faktury opisana w jeden sposób odpowiada pozycji zamówienia opisanej w inny. Model proponuje odpowiedź i pokazuje, na czym ją opiera. **Sprawdzanie względem faktów.** Czy dostawca istnieje, czy pozycje sumują się do kwoty, czy ilość mieści się w tolerancji względem przyjęcia, czy ten numer faktury był już księgowany. To kod, zawsze. Model można zapytać, czy suma się zgadza; funkcja to wie. **Zmiana stanu i stosowanie zasad.** Księgowanie, płatność, zmiana danych podstawowych, limit zatwierdzania, rozdzielenie obowiązków. Kod i konfiguracja, w transakcji, czytelne dla ludzi odpowiedzialnych za zgodność. Błąd kosztownyBłąd tani Kod i regułySprawdzalne fakty, pieniądze i stan. Nie ma czego interpretować. Model proponujeKod weryfikuje propozycję, wątpliwe przypadki idą do człowieka. Zwykła automatyzacjaIntegracja i reguła. Model niczego tu nie dodaje. Model działa samOdwracalne i tanie w poprawce, jak wstępne przypisanie sprawy. Pola i rekordyTekst i dokumenty Większość prawdziwych procesów ma kroki we wszystkich czterech ćwiartkach. ## Szwem jest propozycja, a nie działanie Wzorzec, który to spina, łatwo opisać: model nigdy sam nie zmienia stanu. Jego wynikiem jest propozycja — ustrukturyzowany obiekt z odczytanymi polami, wybraną pozycją zamówienia, proponowanym kontem i wskazaniem, z którego miejsca dokumentu pochodzi każda wartość. Propozycja trafia do warstwy weryfikacji napisanej zwykłym kodem, która sprawdza ją względem systemów źródłowych: czy są wymagane pola, czy każdy identyfikator wskazuje istniejący rekord, czy zgadzają się sumy i podatek, czy zachowano tolerancje, czy nic nie jest księgowane drugi raz, czy zamówienie jest wciąż otwarte. Zatwierdzana jest tylko propozycja, która przeszła, i zatwierdza ją kod. Kod nie stwierdzi, czy model dobrze przeczytał dokument. Stwierdzi natomiast, czy odczyt jest spójny ze wszystkim, co firma już wie — i wiele błędnych odczytów odpada właśnie tutaj. Te, które przechodzą wszystkie kontrole i nadal są błędne, to ryzyko resztkowe, które mierzy się próbkowaniem, a nie nadzieją. ## Czego nie wolno trzymać w promptcie Limit zatwierdzania wpisany do promptu jest prośbą. Obowiązuje tak długo, jak model odczytuje go zgodnie z intencją. Ten sam limit w kodzie po prostu obowiązuje — i da się go przejrzeć, wersjonować i zmieniać pod tą samą kontrolą co każde inne ustawienie finansowe. To samo dotyczy wszystkiego, o co zapyta audytor albo regulator. Dział zgodności przejrzy tabelę reguł. Nie przejrzy zachowania modelu na wejściach, których nikt jeszcze nie widział, i nie powinien być o to proszony. Jest też prostsza wersja tej zasady: nie każcie modelowi robić niczego, co da się policzyć albo wyszukać. Arytmetyka, logika dat, odczyt danych podstawowych i wykrywanie duplikatów są w kodzie tańsze, szybsze i po prostu dokładne. ## Gdzie wchodzi człowiek Propozycje, które nie przeszły weryfikacji, oraz te, które model sam oznaczył jako niepewne, trafiają do człowieka — razem z propozycją, kontrolą, która nie przeszła, i dowodem. Człowiek podejmuje jedną decyzję, zamiast robić sprawę od nowa. To, które kontrole odpadają i jak często, staje się najużyteczniejszą mapą procesu, jaką kiedykolwiek będziecie mieli. Kontrola, która odpada stale, wskazuje na słaby odczyt, brakujący rekord referencyjny albo regułę, która jest po prostu błędna — a każda z tych rzeczy ma innego właściciela. ## Zacznijcie od opisania kroków Rozrysujcie jeden proces jako kroki i opiszcie każdy z nich: czytanie, klasyfikacja, rozstrzygnięcie, sprawdzenie, zmiana stanu. Te etykiety w dużej mierze same projektują system i od razu pokazują, gdzie model zarabia na swoje miejsce, a gdzie dokładałby tylko ryzyko. Ta granica — co model może proponować, co egzekwuje kod i co zawsze idzie do człowieka — jest pierwszą rzeczą, którą ustalamy przy [inżynierii agentów AI](https://predictes.com/pl/services/ai-agents-engineering), i zapisujemy ją w kodzie, a nie w promptcie. - hiperautomatyzacja - walidacja - projektowanie procesów - agenci AI ## Czytaj dalej - [Dostawca wycofał model. Co dalej z Waszym systemem](https://predictes.com/pl/blog/dostawca-wycofal-model-co-dalej-z-waszym-systemem) - [Baza operacyjna i lakehouse: dwie pamięci systemu AI-native](https://predictes.com/pl/blog/baza-operacyjna-i-lakehouse-dwie-pamieci-systemu-ai-native)