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 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 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 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.

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ę.

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ę i 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 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. Log pojedynczej decyzji powinien wskazywać, która wersja promptu i reguł była aktywna w momencie jej podjęcia.

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.

Jak podchodzimy do tego we własnych produktach

Zasadę „AI czyta i proponuje, deterministyczny kod liczy i decyduje” stosujemy konsekwentnie w naszych produktach. W Qkwit model czyta dokumenty księgowe, a podatki i składki liczy osobny silnik. W Taniej po Lek AI rozpoznaje zawartość koszyka zakupowego ze zdjęcia lub tekstu, a łączną cenę koszyka liczy zawsze deterministyczny silnik cenowy. Więcej o samej zasadzie i o tym, gdzie ją stosujemy, piszemy na stronie wdrożeń AI — to nie jest teoria wypracowana pod bankowość, to architektura, którą stosujemy tam, gdzie liczby i decyzje muszą być pewne.

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.