Wielu przedsiębiorców pyta wprost: skoro AI potrafi napisać e-mail i przeanalizować dokument, to dlaczego nie miałoby po prostu policzyć podatku? Odpowiedź jest prosta i dotyczy natury modeli językowych, a nie ich „inteligencji”: model językowy nie gwarantuje, że dwa razy policzy to samo tak samo. Silnik podatkowy musi.

Dlaczego model językowy nie jest kalkulatorem

Model językowy, taki jak Claude, generuje odpowiedź token po tokenie, na podstawie prawdopodobieństwa. To świetnie sprawdza się przy czytaniu, klasyfikowaniu i podsumowywaniu dokumentów — zadaniach, w których dopuszczalna jest pewna elastyczność interpretacji. Nie sprawdza się przy liczeniu podatku, gdzie wynik musi być identyczny za każdym razem, niezależnie od tego, ile razy zapytanie zostanie powtórzone, jaką wersję modelu akurat obsługuje dostawca, albo jak sformułowany był prompt.

To nie jest wada konkretnego modelu — to właściwość całej kategorii technologii. Podatki i składki ZUS mają jasno określone reguły, stawki i terminy zapisane w przepisach. Te reguły trzeba zaimplementować jako deterministyczny kod, który dla tych samych danych wejściowych zawsze zwraca ten sam wynik — nie jako pytanie do modelu językowego.

Nawet gdyby model za każdym razem trafiał w prawidłowy wynik, to wciąż byłby to system, którego nie da się w prosty sposób wyjaśnić ani skontrolować. Deterministyczny kod można otworzyć, przeczytać linijka po linijce i wskazać dokładnie, który przepis odpowiada za którą część wyniku. Odpowiedź modelu językowego takiej ścieżki nie ma — jest wygenerowana, nie wyprowadzona z jawnego wzoru.

Co to znaczy „brak powtarzalności” w praktyce

Wyobraźmy sobie dwa identyczne zestawy dokumentów księgowych, wprowadzone tydzień po tygodniu. Silnik deterministyczny policzy z nich dokładnie ten sam podatek, dzień w dzień — bo działa na regułach, nie na przewidywaniach.

Model językowy, poproszony wprost o „policzenie podatku”, może dojść do innego wyniku dla identycznych danych — nie dlatego, że się „myli losowo”, ale dlatego, że nie jest do tego zaprojektowany. To narzędzie do rozumienia języka i treści dokumentów, nie do wykonywania powtarzalnej arytmetyki prawnej. Rozdzielenie tych dwóch ról — AI proponuje, kod decyduje — to fundament, na którym budujemy własne produkty, nie tylko zalecenie z artykułu.

Konsekwencje pomyłki w podatkach nie są abstrakcyjne — to realne pieniądze, terminy urzędowe i odpowiedzialność przedsiębiorcy. Dlatego to jedno z tych miejsc, gdzie decyzje muszą pozostać deterministyczne, niezależnie od tego, jak dobry jest model językowy.

Jak to rozwiązujemy w Qkwit: AI czyta, silnik liczy

W Qkwit — naszym produkcie księgowym z AI dla jednoosobowych działalności gospodarczych — rozdzielenie ról jest architektoniczną zasadą, nie dodatkiem.

AI (Claude) czyta i klasyfikuje dokumenty: odczytuje dane z faktur, paragonów i potwierdzeń, rozpoznaje kategorie kosztów, porządkuje informacje w formę, którą da się dalej przetworzyć. To zadanie, w którym model językowy jest naprawdę dobry — rozumienie treści dokumentu, nawet gdy format się różni.

Samo liczenie podatków i składek ZUS wykonuje deterministyczny silnik — kod, który dla tych samych danych wejściowych zawsze zwróci ten sam wynik, zgodny z aktualnymi stawkami i regułami. Model językowy nigdy nie jest ostatnim ogniwem w łańcuchu decyzji o kwocie, jaką przedsiębiorca ma zapłacić.

To podejście pozwala korzystać z mocnych stron AI (czytanie, rozumienie, klasyfikacja dokumentów) bez przenoszenia na model odpowiedzialności, do której nie jest przeznaczony.

Co by się stało, gdyby to AI liczyło podatek samodzielnie

Warto rozważyć odwrotny scenariusz: model językowy dostaje dane wejściowe i sam zwraca kwotę podatku do zapłaty. Pierwszy problem pojawia się przy kontroli — trudno wykazać krok po kroku, jak model doszedł do konkretnej liczby, bo nie ma tu jawnego wzoru, tylko wygenerowana odpowiedź. Drugi problem to zmiana stawek: kiedy w trakcie roku zmienia się próg podatkowy albo wysokość składki, deterministyczny kod aktualizuje się w jednym miejscu i wynik natychmiast jest spójny dla wszystkich użytkowników. Model językowy nie ma takiego jednego miejsca do aktualizacji — jego „wiedza” o stawkach zależy od tego, czego się nauczył i co dostał w kontekście zapytania, a to nie jest mechanizm, na którym warto opierać zgodność z przepisami.

Trzeci problem to spójność między użytkownikami. Dwóch przedsiębiorców z identyczną sytuacją podatkową powinno dostać identyczny wynik, niezależnie od tego, kto i kiedy zadaje pytanie. Deterministyczny silnik gwarantuje to z definicji. Model językowy — nie, bo po prostu nie taka jest jego natura.

Gdzie AI faktycznie się przydaje w księgowości

Granica nie oznacza, że AI ma w księgowości małą rolę — wręcz przeciwnie. To właśnie ekstrakcja i klasyfikacja dokumentów jest zadaniem, które najbardziej spowalnia księgowość JDG, i to tam AI realnie skraca czas pracy. Pisaliśmy o tym szerzej w artykule o AI w księgowości JDG — skrócenie miesiąca rozliczeniowego bierze się właśnie z automatyzacji czytania dokumentów, nie z automatyzacji liczenia podatków.

Podobny wzorzec widzimy też po stronie biur rachunkowych, gdzie wolumen dokumentów jest jeszcze większy — więcej w artykule o AI dla biur rachunkowych.

Co to oznacza dla biur rachunkowych i JDG

Dla firmy wybierającej narzędzie księgowe z AI to konkretna wskazówka: warto zapytać dostawcę wprost, co dokładnie liczy model językowy, a co kod. Jeśli odpowiedź brzmi „model liczy podatek”, warto dopytać, jak zagwarantowana jest powtarzalność wyniku — bo to pytanie, na które sama natura modeli językowych nie daje dobrej odpowiedzi.

Dobre wdrożenie AI w księgowości nie polega na oddaniu modelowi całego procesu. Polega na dokładnym rozdzieleniu: co AI czyta i klasyfikuje, a co liczy deterministyczny kod — i pilnowaniu tej granicy tak samo rygorystycznie, jak pilnuje się terminów podatkowych.

Najczęstsze pytania

Czy AI w ogóle nie powinno mieć nic wspólnego z liczeniem podatków? AI dobrze sprawdza się w czytaniu i klasyfikowaniu dokumentów, z których dane trafiają do obliczeń. Samo liczenie — zastosowanie stawek i reguł do konkretnych kwot — powinno zawsze wykonywać deterministyczne oprogramowanie, nie model językowy.

Dlaczego model językowy nie gwarantuje tego samego wyniku za każdym razem? Bo generuje odpowiedzi na podstawie prawdopodobieństwa, a nie z zestawu twardych reguł arytmetycznych. To świetne narzędzie do rozumienia języka, ale nie do wykonywania powtarzalnych obliczeń prawnych.

Jak Qkwit rozwiązuje ten problem? AI czyta i klasyfikuje dokumenty (faktury, paragony, potwierdzenia), a podatki i składki ZUS liczy oddzielny, deterministyczny silnik — model językowy nigdy nie jest ostatnim ogniwem decydującym o kwocie.

Czy to podejście spowalnia proces w porównaniu do „AI liczy wszystko”? Nie — ekstrakcja dokumentów przez AI to i tak najbardziej czasochłonny etap księgowości. Rozdzielenie ról nie spowalnia procesu, tylko eliminuje ryzyko błędu tam, gdzie błąd kosztuje najwięcej.

Czy to podejście dotyczy tylko JDG, czy też firm z innymi formami działalności? Sama zasada — AI czyta, kod liczy — jest uniwersalna i stosujemy ją też poza księgowością, np. przy decyzjach w sektorze finansowym. W Qkwit obsługa spółek i biur rachunkowych jest w przygotowaniu, ale ten sam podział ról obowiązuje od pierwszego dnia projektu, niezależnie od tego, jaką formę działalności docelowo obsłuży.

Co dokładnie może pójść nie tak, jeśli model liczy podatek bezpośrednio? Największe ryzyko to brak gwarancji tego samego wyniku dla tych samych danych oraz brak jasnej ścieżki wyjaśnienia, skąd wzięła się konkretna kwota. Przy kontroli podatkowej albo reklamacji użytkownika to różnica między pokazaniem konkretnego przepisu a przyznaniem, że wynik został „wygenerowany”.

Porozmawiajmy o Waszej księgowości

Jeśli zastanawiacie się, jak bezpiecznie wprowadzić AI do procesów księgowych bez oddawania mu decyzji, których nie powinien podejmować — napiszcie do nas.