W każdym systemie, który wdrażamy, obowiązuje jedna zasada: AI czyta, klasyfikuje i proponuje, a decyzje krytyczne i wszystkie obliczenia wykonuje deterministyczny kod. Tam, gdzie w grę wchodzą pieniądze — podatki, składki, wyceny, salda — to jedyny odpowiedzialny podział ról, jaki znamy.

Co dokładnie robi AI, a co robi kod

Modele językowe są znakomite w zadaniach, w których liczy się rozumienie kontekstu: czytanie faktury zapisanej w nietypowym formacie, rozpoznanie, o co pyta klient w wiadomości napisanej potocznym językiem, wyłapanie z dokumentu informacji, które człowiek by zauważył od razu, a prosty parser — nie. To zadania, w których „prawie dobrze” ma sens i można to iteracyjnie poprawiać.

Obliczenia podatkowe, naliczanie składek, wyliczanie salda czy podejmowanie decyzji, które mają bezpośrednie skutki finansowe albo prawne, rządzą się inną logiką. Tu nie ma miejsca na „prawie dobrze” — albo wynik jest poprawny, albo nie jest, i nawet jeśli model odpowiada poprawnie w zdecydowanej większości przypadków, pojedyncza pomyłka w systemie dotykającym finansów to realna szkoda dla klienta.

Dlatego w naszych wdrożeniach rysujemy tę granicę wprost: AI odpowiada za odczytanie, sklasyfikowanie i zaproponowanie — kod odpowiada za policzenie i zdecydowanie. Te dwie role nigdy się nie mieszają w jednym kroku systemu.

Dlaczego to ważne właśnie w finansach

Modele językowe mogą się mylić — to nie wada konkretnego dostawcy czy konkretnej wersji modelu, tylko właściwość tej technologii jako takiej. W zastosowaniach, gdzie błąd oznacza źle wystawioną fakturę albo niepoprawnie wyliczony podatek, nie da się tego ryzyka zaakceptować bez zabezpieczenia.

Deterministyczny kod ma inną właściwość: dla tych samych danych wejściowych zawsze zwraca ten sam wynik, ten wynik da się przetestować, prześledzić i — co równie ważne — wytłumaczyć podczas kontroli czy audytu. Model językowy tej właściwości z definicji nie ma. Dlatego w miejscach, gdzie liczy się powtarzalność i możliwość rozliczenia się z wyniku, odpowiada za to kod, nie model.

To nie jest ograniczenie, które nakładamy z ostrożności procesowej — to warunek, bez którego wdrożenie AI w obszarze finansowym w ogóle nie powinno wejść na produkcję. Im wcześniej ta zasada zostanie ustalona w projekcie systemu, tym mniej kosztowne jest jej pilnowanie na kolejnych etapach wdrożenia.

Przykład z naszego produktu

Najlepiej widać tę zasadę w Qkwit, naszej księgowości z AI dla jednoosobowych działalności gospodarczych. Claude czyta dokumenty księgowe — faktury, paragony, potwierdzenia — i wyciąga z nich dane: kwoty, daty, kategorie, kontrahentów. To zadanie idealnie pasujące do możliwości modelu językowego: dokumenty bywają różnorodne, skany bywają niskiej jakości, a model radzi sobie z tą zmiennością znacznie lepiej niż sztywny parser.

Samo wyliczenie podatku i składek ZUS na podstawie tych danych wykonuje jednak deterministyczny silnik, nie model. Pisaliśmy szerzej o tym, jak wygląda skrócony miesiąc rozliczeniowy dzięki AI w księgowości JDG — cała oszczędność czasu bierze się z tego, że AI zdejmuje z człowieka żmudne czytanie i wpisywanie danych, a nie z tego, że model „liczy podatki” zamiast księgowego czy silnika obliczeniowego.

Ten sam wzorzec widać też w Brokik, naszej platformie do zarządzania najmem działającej w 25 krajach. AI dostosowuje dokumenty i wycenę do konkretnego przypadku najmu, ale to, jakie zapisy muszą się znaleźć w umowie na danym rynku, wynika z lokalnego prawa najmu i szablonów przypisanych do konkretnego kraju — nie z tego, co model uzna za stosowne w danej chwili. Model proponuje treść, natomiast ostateczny kształt dokumentu podlega regułom ustalonym z góry, a nie generowanym przez AI od zera.

Ten sam wzorzec stosujemy też tam, gdzie automatyzacja decyzji dotyka realnych konsekwencji dla klienta — z jasno wyznaczonym momentem eskalacji do człowieka, gdy sytuacja wykracza poza to, co system może bezpiecznie rozstrzygnąć samodzielnie.

Co się dzieje, gdy ta granica nie jest jasna

Kiedy w projekcie systemu nie ma wyraźnie narysowanej granicy między propozycją modelu a decyzją kodu, model językowy prędzej czy później zaczyna nieformalnie „decydować” — nie dlatego, że ktoś tak zaprojektował system, tylko dlatego, że nikt nie zaprojektował inaczej. W praktyce oznacza to, że błąd, który się pojawi, trudno namierzyć: nie wiadomo, czy przyczyną było błędne rozpoznanie dokumentu przez model, wadliwa reguła w kodzie, czy brak jakiejkolwiek reguły w ogóle. To samo dotyczy odpowiedzialności formalnej — w razie kontroli czy reklamacji trudno wytłumaczyć wynik, który powstał gdzieś pomiędzy propozycją a decyzją, bez jasnego podziału na etapy. Rozdzielenie tych dwóch warstw od samego początku projektu eliminuje ten problem, zanim jeszcze się pojawi.

Co to oznacza dla wdrożenia w Twojej firmie

Jeśli planujecie wdrożenie AI w obszarze, który dotyka pieniędzy — fakturowania, rozliczeń, wycen, limitów kredytowych — warto od razu na etapie projektowania systemu odpowiedzieć sobie na trzy pytania: co dokładnie ma czytać i proponować model, co dokładnie ma liczyć i decydować kod, oraz w którym miejscu człowiek ma możliwość wglądu i korekty. Jeśli tych granic nie da się jasno narysować na kartce, to sygnał, że projekt systemu wymaga jeszcze pracy, zanim trafi na produkcję.

Dobra architektura tego typu systemu prawie zawsze zakłada też logowanie obu warstw osobno: co model zaproponował i dlaczego, oraz jaką decyzję ostatecznie podjął kod. Dzięki temu w razie pomyłki da się precyzyjnie ustalić, na którym etapie coś poszło nie tak — zamiast szukać przyczyny w czarnej skrzynce.

Najczęstsze pytania

Czy AI w ogóle nie powinno dotykać liczb? Może je czytać, wyciągać z dokumentów i porządkować — ale nie powinno samodzielnie wykonywać obliczeń, które mają bezpośrednie skutki finansowe. Te wykonuje deterministyczny kod, korzystając z danych przygotowanych przez model.

Czy taki podział nie spowalnia wdrożenia? W praktyce jest odwrotnie — jasno rozdzielone role ułatwiają testowanie każdej z nich osobno i skracają czas potrzebny na wykrycie i naprawienie błędu, gdy się pojawi.

Jak rozpoznać, że dostawca faktycznie stosuje taki podział, a nie tylko o nim mówi? Warto zapytać wprost, w którym miejscu systemu kończy się propozycja modelu, a zaczyna decyzja kodu — i poprosić o pokazanie tego na konkretnym przykładzie z logów, nie na slajdzie.

Czy ta zasada dotyczy tylko księgowości, czy szerzej finansów? Dotyczy każdego systemu, w którym błąd oznacza konkretną stratę finansową albo konsekwencję prawną — księgowości, bankowości, wycen, rozliczeń. Wszędzie tam obowiązuje ta sama logika.

Czy model w ogóle może uczestniczyć w podejmowaniu decyzji, czy tylko w ich przygotowaniu? Model może przygotować rekomendację i uzasadnienie, ale ostateczna decyzja o skutkach finansowych powinna zapadać w deterministycznej warstwie kodu, z możliwością eskalacji do człowieka tam, gdzie sytuacja jest niejednoznaczna.

Czy warto to wszystko dokumentować już na etapie projektowania systemu, czy można dopisać później? Zdecydowanie warto zrobić to od razu. Dorysowywanie granicy między propozycją a decyzją po fakcie, gdy obie role są już wymieszane w jednym kroku systemu, jest znacznie trudniejsze i kosztowniejsze niż zaprojektowanie jej na starcie.

Jeśli zastanawiacie się, jak taki podział ról zaprojektować w konkretnym procesie w Waszej firmie, napiszcie do nas — chętnie pokażemy, jak wygląda to w praktyce na przykładzie naszych własnych produktów.