Pracowałam w sektorze bankowym ponad dwadzieścia lat, w tym na stanowiskach C-level. To daje perspektywę, która trochę różni się od perspektywy dostawcy technologii. Bank nie jest laboratorium. Bank jest instytucją, która musi przede wszystkim działać — a każda nowa technologia, która wchodzi do organizacji, jest oceniana nie przez pryzmat tego, czy jest nowoczesna, ale czy w razie awarii potrafimy powiedzieć regulatorowi, co się stało i dlaczego.
Z tej perspektywy patrzę na rynek agentów AI w bankowości. Są use case'y, które są już dzisiaj wdrażalne produkcyjnie, z akceptowalnym ryzykiem i mierzalną wartością. Są inne, które brzmią dobrze na konferencjach, ale w rzeczywistości nikt rozsądny w zarządzie banku ich nie zaakceptuje w tej dekadzie.
Use case'y produkcyjnie dojrzałe
Analiza dokumentów kredytowych w backoffice
Agent przyjmuje dokumentację (sprawozdania finansowe, umowy, korespondencję) i wykonuje ustrukturyzowaną ekstrakcję danych plus weryfikację spójności. Człowiek analityk dostaje dokumentację już wstępnie przetworzoną, z podświetlonymi punktami wymagającymi uwagi. Redukcja czasu analizy 40-60% w typowych scenariuszach kredytowych MSP.
Dlaczego działa: zadanie jest dobrze zdefiniowane, dane strukturalne, output weryfikowalny przez człowieka, decyzja kredytowa nadal należy do analityka. Ryzyko regulacyjne minimalne, bo agent jest narzędziem wspomagającym, nie decyzyjnym.
Automatyzacja code review i refactoringu systemów wewnętrznych
Banki siedzą na dekadach kodu COBOL, Java starych generacji, skryptów bazy danych. Agent AI analizuje kod, identyfikuje problemy bezpieczeństwa, proponuje refactoring, generuje testy. Nie zastępuje zespołu developerów, ale znacząco podnosi jego produktywność — obecni developerzy banku rozmawiają z kodem, a nie tylko go czytają.
Dlaczego działa: code review jest zadaniem zamkniętym, z mierzalną jakością (testy, statyczna analiza), a błędy są wychwytywalne przez istniejące procesy CI/CD. Model open-source (Deepseek-Coder, Qwen-Coder, GLM) daje wystarczającą jakość przy pełnej kontroli nad danymi.
Analiza treści skarg i reklamacji
Agent przyjmuje zgłoszenie od klienta, kategoryzuje problem, przeszukuje bazę wcześniejszych przypadków, proponuje ścieżkę rozwiązania dla pracownika obsługi. Nie podejmuje decyzji o zwrocie czy rekompensacie, ale dramatycznie skraca czas, w którym pracownik dociera do sensownej propozycji.
Dlaczego działa: tekstowy input, wysoka redundancja historycznych przypadków, kontekst ograniczony do jednego zgłoszenia, człowiek podejmuje decyzję. Dodatkowa wartość: agent może wykrywać wzorce (np. rosnąca liczba skarg w jednym produkcie), których nie widać w klasycznych metrykach.
Compliance monitoring i AML pre-screening
Agent analizuje transakcje pod kątem potencjalnych naruszeń AML/KYC, ale nie podejmuje decyzji — przygotowuje tzw. alert z uzasadnieniem dla analityka compliance. W rzeczywistości wykonuje tę samą pracę, którą dziś wykonują młodsi analitycy compliance w pierwszej linii, tyle że szybciej i bez zmęczenia. Analityk senior dostaje tylko alerty, które faktycznie wymagają decyzji.
Dlaczego działa: duża liczba transakcji do analizy, wysoka redundancja, jasne kryteria wstępnej oceny, finalna decyzja człowieka. Kluczowe jest logowanie — agent musi pozostawić audytowalny ślad rozumowania dla każdej decyzji kierowanej do eskalacji.
Use case'y w fazie wczesnego wdrożenia
Konwersacyjny agent obsługi klienta pierwszej linii
Z pozoru oczywiste zastosowanie, w praktyce pełne pułapek. Agent obsługi klienta, który ma dostęp do systemów bankowych, to jednocześnie najlepsze UX dla klienta i największe ryzyko regulacyjne. Banki, które wdrażają agentów w tym obszarze, bardzo starannie ograniczają zakres: tylko informacje, nie transakcje; tylko produkty standardowe, nie inwestycyjne; z natychmiastowym przekazaniem do człowieka przy każdym sygnale skomplikowania.
W 2026 jest to rynek wczesnego wdrożenia. Banki z dojrzałymi systemami (np. ING, Santander w Polsce) mają pilotaże; masowe wdrożenia poczekają, aż ustabilizuje się interpretacja AI Act w obszarze interakcji z konsumentem.
Wewnętrzny asystent wiedzowy dla doradców
Agent, który potrafi odpowiadać na pytania pracowników banku o produkty, procedury, regulacje. Redukuje czas szukania informacji, eliminuje eskalacje do helpdesków produktowych. Wdrożenia są bezpieczniejsze regulacyjnie (nie interakcja z klientem), ale wymagają dobrej bazy wiedzy wewnętrznej — a tej banki często nie mają w formie nadającej się do AI.
Wyzwanie: agent jest tak dobry jak wiedza, do której ma dostęp. Banki z dobrym knowledge management wygrywają; banki, w których wiedza krąży w mailach i rozmowach na Teams, muszą ją najpierw skodyfikować.
Asystent inwestycyjny dla klientów premium
Produkt, który brzmi atrakcyjnie marketingowo, ale jest bardzo trudny regulacyjnie. MiFID II, rekomendacje inwestycyjne, odpowiedzialność za doradztwo. Wdrożenia w Europie są bardzo ograniczone — dominują rozwiązania, w których agent przygotowuje materiały, ale rekomendację zawsze wydaje człowiek licencjonowany.
Use case'y, które jeszcze nie są gotowe
Dla uczciwości — kilka tematów, które pojawiają się w prezentacjach, ale w 2026 wciąż nie są gotowe do produkcji w polskim banku:
Autonomiczne decyzje kredytowe dla klientów indywidualnych i mikrofirm. Technologicznie możliwe; regulacyjnie dyskwalifikowane pod AI Act jako high-risk system. Wdrożenie wymaga pełnej dokumentacji modelu, audytu, explainability, a i tak człowiek musi pozostać w pętli dla każdej decyzji odmownej.
Pełnoautomatyczne onboardowanie klienta (KYC, AML, otwarcie rachunku) bez human-in-the-loop. Podobnie — możliwe, ale ryzyko regulacyjne przewyższa oszczędność operacyjną.
Autonomiczne zarządzanie portfelem inwestycyjnym. Różnica między robodoradcą (istniejący produkt, prostą klasyfikację ryzyka) a autonomicznym menedżerem portfela (zmienna strategia, decyzje w czasie rzeczywistym) jest dla regulatora fundamentalna.
Agenci, którzy samodzielnie „rozmawiają z systemami banku" w celu rozwiązania problemu klienta. Wizja zero-touch operations jest atrakcyjna, ale w 2026 realny system zawsze ma gate keeperów — agent nie wykonuje transakcji, tylko przygotowuje jej wykonanie dla człowieka lub procedury dwuosobowej.
Architektura produkcyjna — co w niej musi być
Produkcyjne wdrożenie agenta w polskim banku wymaga kilku warstw, które nie są opcjonalne.
Warstwa modelu. Preferowany — on-premise deployment modelu open-source na infrastrukturze banku lub w izolowanym private cloud. Modele komercyjne (GPT, Claude, Gemini) są dopuszczalne tylko w ścieżce konkretnie uzgodnionej z DORA (Third-Party Provider), co jest procesem kilkumiesięcznym.
Warstwa orchestracji. Framework agentowy (open-source, najczęściej LangChain/LangGraph lub własny) kontrolujący cykl agenta: plan → akcja → weryfikacja → decyzja o następnym kroku. Musi mieć deterministyczne limity (liczba iteracji, czas, zużycie tokenów).
Warstwa narzędzi. Ściśle zdefiniowany zestaw akcji, które agent może wykonać. Nie ma możliwości „kreatywnego" dostępu do systemów; każdy endpoint jest zdefiniowany, zabezpieczony, logowany. Agent używa tych samych mechanizmów autoryzacji co człowiek-pracownik o analogicznym profilu uprawnień.
Warstwa logowania i audytu. Każda akcja agenta, każda myśl w chain-of-thought, każde wywołanie narzędzia — pełen log, niemodyfikowalny, w systemie SIEM banku. To jest wymaganie DORA i jednocześnie warunek rozliczalności.
Warstwa human-in-the-loop. Określona jasno dla każdego use case'u: w którym momencie agent przekazuje zadanie człowiekowi, w jakim formacie, z jaką rekomendacją. Dla większości zastosowań bankowych agent przygotowuje, nie decyduje.
Warstwa monitoringu jakości. Agent produkcyjny musi mieć ciągły monitoring: czy działa w granicach założonej jakości, czy jego odpowiedzi są spójne między podobnymi przypadkami, czy nie zaczyna zachowywać się dziwnie (drift). Samplowanie i weryfikacja przez człowieka jest częścią codziennej operacji.
Open-source czy komercyjne — decyzja w 2026
Rok temu odpowiedź dla bankowości była zwykle „komercyjne modele są po prostu lepsze". Dzisiaj sytuacja jest bardziej zniuansowana.
Modele open-source (Deepseek, Qwen 2.5/3, GLM-4, Kimi K2, Bielik dla języka polskiego) osiągnęły poziom, który dla większości zadań backoffice nie różni się odczuwalnie od modeli komercyjnych. Dla zadań obsługi klienta, analizy dokumentów, ekstrakcji danych, generowania kodu — są produkcyjnie wystarczające.
Dla zadań wymagających wyjątkowej jakości rozumowania (złożone kazusy prawne, skomplikowane przypadki kredytowe, analiza strategiczna) modele komercyjne wciąż mają przewagę. Ale ta przewaga się zawęża, a koszt regulacyjny korzystania z nich w bankowości rośnie.
W praktyce polskie banki w 2026 coraz częściej wybierają architekturę hybrydową: modele open-source on-premise dla wszystkich procesów dotykających danych klienta lub wrażliwych; modele komercyjne, w bezpiecznym tunelu, dla zadań wewnętrznych niedotykających danych klienta. Ta architektura jest defendable dla DORA i jednocześnie korzysta z przewag obu światów.
DORA, AI Act i realne wymagania compliance
Dla osób pracujących w bankowości regulacje nie są „coś, co dołożymy na końcu" — są projektowym wymaganiem od dnia pierwszego. Wdrożenie agenta AI bez rozpracowanego compliance jest wdrożeniem, które nigdy nie opuści fazy pilotażu.
DORA (Digital Operational Resilience Act, w pełnej mocy od stycznia 2025) wymaga, by każdy system ICT istotny dla działalności banku był objęty ramami zarządzania ryzykiem. Agent AI — szczególnie jeśli ma dostęp do systemów wewnętrznych — prawie zawsze podpada pod tę kategorię. Oznacza to: inwentaryzacja, klasyfikacja ryzyka, plany ciągłości, testy odporności, monitoring incydentów.
Dla agentów opartych na modelach zewnętrznych (np. GPT przez API OpenAI) DORA wprowadza dodatkowe wymagania dotyczące third-party providers — formalizacja relacji z dostawcą, prawa audytu, klauzule awaryjne. Dla modeli on-premise te wymagania są ograniczone.
AI Act (w pełni obowiązujący od sierpnia 2026) wprowadza kategoryzację systemów AI według ryzyka. Agenci uczestniczący w decyzjach kredytowych, ocenach zdolności kredytowej, oczach zatrudnienia są klasyfikowani jako high-risk i podlegają rozszerzonym wymaganiom: dokumentacja techniczna, rejestracja w bazie EU, monitoring, prawo do wyjaśnienia dla klienta, możliwość ludzkiej weryfikacji.
Dla wdrożeń w sektorze bankowym oznacza to w praktyce: zanim zacznie się pisać jakikolwiek kod, trzeba wiedzieć, do której kategorii AI Act podpadnie system, i zaprojektować architekturę pod wymagania tej kategorii. Retrofit jest możliwy, ale kosztowny.
Rekomendacje KNF — polski Urząd Komisji Nadzoru Finansowego wydaje rekomendacje w zakresie korzystania z chmury, outsourcingu, bezpieczeństwa ICT. Nie regulują one bezpośrednio AI, ale tworzą ramy, w których wdrożenie agenta musi się mieścić. Rekomendacja D (bezpieczeństwo systemów ICT) i rekomendacja o chmurze są szczególnie istotne.
GDPR — w kontekście agentów AI GDPR jest szczególnie ważny dla dwóch rzeczy: przetwarzania danych osobowych w promptach (często zapomniane; dane klienta trafiające do agenta podlegają tym samym zasadom co w dowolnym innym systemie) oraz prawa do wyjaśnienia decyzji automatycznej (art. 22).