Bankowość należy do branż, w których błąd automatyzacji kosztuje najwięcej — dlatego wdrożenie AI zaczyna się tam nie od pytania „co da się zautomatyzować”, tylko „jak to udokumentować i nadzorować”. To różnica, która decyduje, czy projekt przejdzie audyt.

Dlaczego bankowość wymaga innego podejścia do AI

W większości branż błędna automatyzacja oznacza poprawkę i przeprosiny. W bankowości błędna decyzja — źle oceniony wniosek kredytowy, niesłusznie zablokowana transakcja, przeoczony sygnał w monitoringu transakcji — ma konsekwencje dla konkretnej osoby albo firmy i podlega kontroli, która sięga dalej niż wewnętrzny dział jakości. Dlatego pytanie „czy AI się myli” jest tu drugorzędne wobec pytania „czy da się odtworzyć, dlaczego AI zaproponowało to, co zaproponowało, i kto to zatwierdził”.

Warto przy tym rozróżnić rodzaje zastosowań, bo nie każde niosą to samo ryzyko. Wykrywanie nietypowych wzorców w transakcjach, wstępna ocena ryzyka jako jeden z sygnałów wspierających analityka, klasyfikacja i porządkowanie dokumentów na potrzeby zgodności, asystent podsumowujący sprawę dla osoby, która i tak podejmie decyzję — to zastosowania, w których AI realnie odciąża zespół, o ile ostatnia decyzja i tak zostaje po stronie człowieka albo deterministycznej reguły. Inna kategoria to sytuacje, w których model miałby samodzielnie rozstrzygać o czymś nieodwracalnym — i to jest dokładnie granica, której nie warto przekraczać bez bardzo dobrego powodu.

To nie jest argument przeciwko automatyzacji. To argument za tym, żeby projektować ją inaczej niż w mniej regulowanych branżach — od początku z myślą o nadzorze i dokumentowalności, a nie jako dodatek wpięty na końcu projektu.

Model eskalacji: AI proponuje, decyzja należy do człowieka lub deterministycznego kodu

Fundamentem takiego podejścia jest rozdzielenie ról między AI a mechanizmem decyzyjnym: model może klasyfikować, oceniać ryzyko, zwracać uwagę na anomalię — ale finalna decyzja krytyczna zostaje po stronie deterministycznych reguł albo człowieka, który świadomie ją podejmuje. Pisaliśmy o tym szerzej przy okazji automatyzacji decyzji z eskalacją — w bankowości ten model przestaje być opcją projektową, a staje się warunkiem koniecznym.

W praktyce oznacza to progi: poniżej pewnego poziomu pewności albo powyżej pewnego poziomu istotności decyzji (kwota, ryzyko, wpływ na klienta) sprawa trafia do człowieka z uprawnieniem do faktycznego odrzucenia rekomendacji, a nie tylko formalnego kliknięcia „zatwierdzam”. Podobnie pisaliśmy o granicy między tym, co AI może oceniać, a co musi zostać policzone deterministycznie, w kontekście sektora finansowego — bankowość jest tego najbardziej wymagającym przypadkiem.

Audytowalność: każda decyzja musi dać się odtworzyć

Dokumentowalność

Każda rekomendacja AI powinna zostawiać ślad: jakie dane wzięła pod uwagę, jaki wynik zwróciła, kto i kiedy ją zatwierdził albo odrzucił, oraz — jeśli człowiek podjął inną decyzję niż sugerowana — dlaczego. Bez tego audyt wewnętrzny czy zewnętrzny nie ma się o co oprzeć poza samym wynikiem końcowym. Ten sam ślad jest też najprostszym sposobem, żeby z czasem poprawiać sam mechanizm — widać w nim, gdzie ludzie najczęściej odrzucają rekomendacje, a to zwykle najlepsza wskazówka, co jeszcze wymaga poprawy.

Powtarzalność

Te same dane wejściowe i te same reguły powinny prowadzić do tego samego wyniku, a zmiana modelu czy reguł powinna być wersjonowana i możliwa do wskazania w czasie. To odróżnia system, który da się skontrolować, od czarnej skrzynki, która „zwykle działa dobrze”. Bez wersjonowania trudno w ogóle odpowiedzieć na pytanie, czy decyzja sprzed pół roku zostałaby dziś podjęta tak samo.

Ślad decyzyjny dla audytu wewnętrznego i zewnętrznego

Zespół audytu — wewnętrzny albo zewnętrzny regulator — powinien móc prześledzić pojedynczą decyzję od danych wejściowych do wyniku bez konieczności odtwarzania logiki modelu z pamięci osób, które go wdrażały. To wymaganie architektoniczne, nie proceduralne — trzeba je zaprojektować w systemie, a nie dopisać do niego procedurą już po fakcie, gdy dokumentacja i tak powstaje na gorąco i pod presją czasu.

Praktyczna konsekwencja jest taka, że decyzje o logowaniu i wersjonowaniu trzeba podjąć na etapie projektowania architektury, a nie dopiero wtedy, gdy padnie pytanie z audytu. Dopisanie audytowalności do gotowego systemu zwykle oznacza przebudowę, a nie prostą konfigurację — dlatego audyt procesu, o którym piszemy niżej, warto zrobić, zanim padnie decyzja o konkretnym narzędziu.

Jak wygląda ścieżka audytu w praktyce

Prześledźmy to na jednym przykładzie, bez odnoszenia się do konkretnego typu decyzji. Dane wejściowe trafiają do modelu, który zwraca rekomendację razem z poziomem pewności. System sprawdza próg: jeśli pewność jest wysoka, a istotność decyzji niska, rekomendacja może zostać zastosowana automatycznie — ale nawet wtedy zapisywany jest komplet danych wejściowych, wynik modelu i informacja, że próg pozwolił na automatyczne zastosowanie. Jeśli pewność jest niska albo stawka wysoka, sprawa trafia do osoby, która widzi rekomendację, dane, na których się opiera, oraz może ją zatwierdzić, zmienić albo odrzucić — a każda z tych trzech decyzji jest zapisywana z uzasadnieniem. Dopiero taki komplet — dane wejściowe, wynik modelu, próg, decyzja człowieka i uzasadnienie — pozwala odpowiedzieć na pytanie audytora „dlaczego akurat tak” miesiące później, bez pytania nikogo o pamięć.

Rola logów i wersjonowania reguł oraz promptów

W systemach opartych na modelach językowych zmienia się nie tylko kod, ale też treść promptu, którym model jest instruowany, oraz zestaw reguł, według których ocenia się jego rekomendacje. Każda taka zmiana wpływa na przyszłe decyzje, więc powinna być wersjonowana dokładnie tak samo jak zmiana w kodzie — z numerem wersji, datą wdrożenia i możliwością wycofania. Log pojedynczej decyzji powinien wskazywać, która wersja promptu i reguł była aktywna w momencie jej podjęcia. Bez tego nie da się odpowiedzieć na pytanie, czy zmiana wprowadzona później poprawiła, czy pogorszyła jakość rekomendacji — a to pytanie prędzej czy później zada zarówno wewnętrzny zespół, jak i audyt zewnętrzny.

Nadzór człowieka jako zasada projektowa, nie dodatek

Najczęstszy błąd, jaki widzimy, to traktowanie nadzoru człowieka jako formalności dodanej na żądanie działu zgodności — ekran z przyciskiem „zatwierdź”, którego w praktyce nikt realnie nie kwestionuje, zwłaszcza gdy w kolejce czeka kilkaset spraw dziennie do jednego kliknięcia. Nadzór, który ma sens, wymaga, żeby osoba zatwierdzająca miała realny czas, informacje i uprawnienia do odrzucenia rekomendacji, a system był tak zaprojektowany, żeby to odrzucenie było równie łatwe jak zatwierdzenie. Inaczej mówiąc: liczba spraw trafiających do człowieka musi być dopasowana do tego, ile realnie może on ocenić, a nie do tego, ile system jest w stanie wygenerować.

Jak podchodzimy do tego we własnych produktach

Zasadę „AI czyta i proponuje, deterministyczny kod liczy i decyduje” stosujemy konsekwentnie we wszystkich trzech własnych produktach, które używają Claude na produkcji: w Qkwit model czyta dokumenty księgowe, a podatki i składki liczy osobny silnik; w Taniej po Lek Apteczkomat rozpoznaje koszyk zakupowy, ale finalna wycena podlega regułom cenowym; w Brokiku AI dostosowuje dokumenty i wyceny, a ostateczne warunki umowy pozostają zgodne z lokalnym prawem najmu w danym kraju. Więcej o samej zasadzie i o tym, gdzie ją stosujemy, piszemy na stronie oferty wdrożeń AI. To nie jest teoria wypracowana pod bankowość — to architektura, którą stosujemy tam, gdzie liczby i decyzje muszą być pewne, niezależnie od branży.

Zanim zaczniecie rozmowę o konkretnym narzędziu

Praktyczna wskazówka dla zespołu oceniającego dostawcę AI do zastosowań bankowych: zapytajcie wprost, co dokładnie jest logowane przy każdej decyzji, jak wygląda ścieżka odrzucenia rekomendacji i czy da się odtworzyć konkretną decyzję sprzed kilku miesięcy bez pytania osoby, która ją wdrażała. Odpowiedzi na te pytania mówią o gotowości do audytu więcej niż jakakolwiek prezentacja funkcji.

Najczęstsze pytania

Czy AI może podejmować decyzje kredytowe samodzielnie? W modelu, który stosujemy, AI ocenia i proponuje, ale finalna decyzja krytyczna — szczególnie ta o istotnym wpływie na klienta — zostaje po stronie deterministycznych reguł albo człowieka z realnym uprawnieniem do jej zmiany.

Jak zapewnić audytowalność bez zatrudniania dodatkowego zespołu? Audytowalność to kwestia architektury, nie dodatkowych ludzi — logowanie danych wejściowych, wyniku, zatwierdzenia i wersji reguł powinno być częścią systemu od pierwszego dnia, a nie osobnym procesem obok niego.

Czy nadzór człowieka spowalnia automatyzację? Spowalnia te przypadki, które i tak wymagają uwagi — pozostałe, jednoznaczne, przechodzą automatycznie. Dobrze zaprojektowany próg eskalacji sprawia, że nadzór trafia tam, gdzie jest potrzebny, a nie wszędzie po równo.

Co powinno się logować przy każdej decyzji wspieranej przez AI? Dane wejściowe, wynik modelu, poziom pewności, decyzję osoby zatwierdzającej i — jeśli różni się od rekomendacji — uzasadnienie tej różnicy.

Od czego zacząć wdrożenie AI w instytucji finansowej? Od audytu procesu, który pokazuje, gdzie decyzje są dziś podejmowane, jakie mają znaczenie i gdzie granica automatyzacji powinna przebiegać, zanim jeszcze wybierze się narzędzia.

Jeśli rozważacie wdrożenie AI w organizacji, w której każda decyzja musi dać się uzasadnić i prześledzić, napiszcie do nas — zaczynamy zawsze od audytu, nie od gotowego rozwiązania.