AI proponuje, kod liczy: dlaczego rozdzielamy te role

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, nie tylko liczba w statystyce jakości modelu.

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, bez wyjątków od tej zasady. Taki podział nie jest wyborem estetycznym — wynika z tego, jak działają te dwie technologie, i z tego, co się dzieje, kiedy się je pomyli albo zamieni ich role miejscami.

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 nie powinno wejść do codziennego użycia. 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. AI 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. Ta granica obowiązuje niezależnie od tego, ile dokumentów przechodzi przez system w danym miesiącu.

Ten sam wzorzec widać też w Brokik, naszej platformie do zarządzania najmem działającej w 25 krajach. AI dostosowuje istniejący dokument najmu do zwykłego, wolnego opisu sytuacji, a asystent konfiguracji przygotowuje wersje robocze rekordów nieruchomości i najemców — które użytkownik zawsze zatwierdza, zanim trafią do systemu. Model proponuje treść i porządkuje dane, natomiast to, co faktycznie zostaje zapisane, zależy od decyzji człowieka, a nie od tego, co model uzna za stosowne.

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, a nie dopiero wtedy, gdy trzeba go tłumaczyć komuś z zewnątrz.

Co to oznacza dla wdrożenia w Waszej firmie

Jeśli planujecie wdrożenie AI w obszarze, który dotyka pieniędzy — fakturowania, rozliczeń, limitów kredytowych — warto już na etapie projektowania odpowiedzieć na trzy pytania: co ma czytać i proponować model, co ma liczyć i decydować kod, i gdzie człowiek może to skorygować. Dobra architektura loguje obie warstwy osobno, żeby w razie pomyłki było wiadomo, na którym etapie coś poszło nie tak. Więcej o tym, jak projektujemy takie wdrożenia, piszemy na stronie wdrożeń AI.

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.