AI w finansach najlepiej sprawdza się tam, gdzie analityk czyta setki stron, żeby znaleźć kilka istotnych informacji: w raportach, dokumentach KYC i alertach AML. W sektorze finansowym każde takie narzędzie jest jednak usługą ICT w rozumieniu DORA, z rejestrem, strategią wyjścia i testami. Pokazujemy, jak połączyć jedno z drugim.
Artykuł jest dla CIO, osób odpowiedzialnych za ryzyko ICT i compliance w bankach, firmach inwestycyjnych, instytucjach płatniczych i ubezpieczeniowych. DORA stosuje się od 17 stycznia 2025 r., więc nie piszemy o przygotowaniach, tylko o tym, jak wpisać AI w ramy, które już obowiązują. Stan prawny na listopad 2026 r. Artykuł ma charakter informacyjny i nie stanowi porady prawnej.
Zastosowania AI w finansach, które da się obronić przed audytem
Wspólny mianownik: model przygotowuje materiał, a decyzję podejmuje człowiek, który widzi źródła.
Analiza raportów i dokumentów
Sprawozdania finansowe kontrahentów, raporty roczne, prospekty, umowy kredytowe. Model wyciąga wskaźniki i kluczowe zapisy, porównuje okresy, oznacza zmiany w ryzykach i przygotowuje streszczenie z odnośnikami do stron źródłowych. Analityk zaczyna od notatki zamiast od 200 stron PDF.
KYC: ekstrakcja danych z dokumentów
Odpisy z rejestrów, dokumenty założycielskie, struktury właścicielskie, wyciągi. Model rozpoznaje typ dokumentu, wyciąga pola (nazwy, numery, beneficjentów rzeczywistych, daty) do ustrukturyzowanego formularza i wskazuje braki lub niespójności między dokumentami. Pracownik weryfikuje wynik, zanim trafi do systemu.
AML: triaż alertów
Systemy monitorowania transakcji generują dużo alertów, z których większość okazuje się fałszywie dodatnia. LLM może zebrać kontekst alertu (historię klienta, powiązane transakcje, wcześniejsze sprawy) w jedną notatkę i zaproponować priorytet. Decyzja o zamknięciu alertu albo przekazaniu sprawy do GIIF zostaje po stronie analityka, a model nie zamyka alertów samodzielnie.
| Zastosowanie | Dane | AI Act | Nadzór człowieka |
|---|---|---|---|
| Analiza raportów | Głównie dane firm, czasem dane osobowe | Zwykle ryzyko minimalne | Analityk weryfikuje wnioski ze źródłami |
| Ekstrakcja KYC | Dane osobowe klientów i beneficjentów | Zwykle poza załącznikiem III | Pracownik zatwierdza każde pole |
| Triaż alertów AML | Dane transakcyjne i osobowe | Zwykle poza załącznikiem III (monitorowanie AML nie jest tam wymienione) | Analityk decyduje o każdym alercie |
| Ocena zdolności kredytowej osób fizycznych | Dane osobowe, finansowe | Wysokie ryzyko (zał. III pkt 5 lit. b) | Pełne wymogi AI Act od 2 grudnia 2027 r. |
Granica przebiega przy ocenie zdolności kredytowej osób fizycznych oraz ocenie ryzyka i wycenie w ubezpieczeniach na życie i zdrowotnych. To systemy wysokiego ryzyka, dla których obowiązki stosuje się od 2 grudnia 2027 r. po zmianie wprowadzonej rozporządzeniem (UE) 2026/1744. Niezależnie od AI Act decyzje oparte wyłącznie na automatycznym przetwarzaniu podlegają art. 22 RODO. Szerszy kontekst opisujemy w artykule AI a dane firmowe w UE: RODO, AI Act, NIS2 i DORA.
DORA a dostawca modelu AI: rejestr, wyjście, koncentracja
Dla DORA nie ma znaczenia, że usługa nazywa się „AI”. Publiczne API modelu językowego to usługa ICT świadczona przez podmiot trzeci, więc wchodzi w cały reżim zarządzania ryzykiem ICT:
- Rejestr informacji. Umowa z dostawcą modelu, łącznie z jego podwykonawcami, trafia do rejestru umów z zewnętrznymi dostawcami usług ICT.
- Postanowienia umowne. Jeśli usługa wspiera funkcje krytyczne lub istotne, umowa musi zawierać m.in. lokalizację przetwarzania, prawo audytu, warunki wypowiedzenia i wsparcie przy wyjściu. Standardowe warunki publicznych API rzadko to zapewniają.
- Strategia wyjścia. Dostawcy wycofują wersje modeli według własnego harmonogramu. Nowa wersja może inaczej ekstrahować pola i inaczej streszczać. Musisz wiedzieć, jak przeniesiesz proces do innego modelu, zanim to nastąpi.
- Ryzyko koncentracji. Kilku dostawców modeli obsługuje znaczną część rynku, często na infrastrukturze tych samych chmur. Uzależnienie kluczowego procesu od jednego API to ryzyko, które trzeba ocenić i udokumentować.
- Incydenty. Awaria lub wyciek po stronie dostawcy to incydent ICT, który klasyfikujesz i ewentualnie zgłaszasz. Bez dostępu do logów dostawcy ustalenie skali bywa trudne.
Odporność nie wymaga rezygnacji z chmury, ale wymaga planu B. Architekturę opartą na kilku dostawcach omawiamy w artykule o multi-cloud i chmurze hybrydowej.
Testowanie i zarządzanie ryzykiem modeli
DORA wymaga programu testowania odporności operacyjnej obejmującego systemy ICT wspierające funkcje krytyczne. System AI to aplikacja z serwerem inferencyjnym, bazą wektorową i integracjami, więc obejmują go skany podatności, testy scenariuszowe, a w wybranych podmiotach także testy TLPT.
Osobna kwestia to jakość samego modelu. W bankach zarządzanie ryzykiem modeli porządkuje Rekomendacja W KNF. Dla LLM w praktyce oznacza to:
- Zestaw referencyjny. Kilkaset dokumentów z ręcznie zweryfikowanymi wynikami, na których mierzysz trafność ekstrakcji i streszczeń.
- Testy regresji przy każdej zmianie modelu, promptu, kwantyzacji lub wersji oprogramowania serwującego.
- Cytowanie źródeł. Każdy wniosek z odnośnikiem do strony dokumentu, żeby analityk mógł go szybko sprawdzić.
- Monitoring. Odsetek korekt wprowadzanych przez pracowników jako sygnał, że jakość spada.
Te praktyki opisujemy szerzej w artykule o bezpiecznych wdrożeniach modeli AI w modelu MLOps.
Dlaczego dedykowany klaster GPU w polskiej serwerowni
Przy AI w finansach model open-weight na dedykowanym klastrze rozwiązuje kilka problemów DORA naraz. Wersję modelu zmieniasz wtedy, gdy przejdzie Twoje testy, a nie wtedy, gdy dostawca ją wycofa. Strategia wyjścia jest konkretna: wagi modelu, konfiguracja i indeksy są u Ciebie i można je odtworzyć na innym sprzęcie. Dane klientów nie opuszczają Polski, a logi masz pod kontrolą.
Uczciwie trzeba dodać, że dostawca infrastruktury też jest dostawcą usług ICT i trafia do rejestru. Różnica polega na tym, że to jeden podmiot w Polsce, z umową obejmującą prawo audytu, lokalizację i wsparcie przy wyjściu. Przejmujesz też odpowiedzialność za utrzymanie, czyli aktualizacje, wysoką dostępność i monitoring, albo zlecasz je w ramach administracji 24/7. Wybór oprogramowania do serwowania modeli opisujemy w porównaniu Ollama, vLLM, SGLang i NVIDIA NIM, a dostępne konfiguracje sprzętu na stronie serwery GPU.
FAQ: najczęściej zadawane pytania
Czy bank może korzystać z ChatGPT lub innego publicznego API AI?
Może, ale jako z usługi ICT od podmiotu trzeciego: z wpisem do rejestru informacji, oceną ryzyka, odpowiednimi postanowieniami umownymi i strategią wyjścia. Przy funkcjach krytycznych lub istotnych wymagania umowne są wyższe niż standardowe warunki większości publicznych API.
Czy AI do AML jest systemem wysokiego ryzyka według AI Act?
Załącznik III wyłącza z kategorii wysokiego ryzyka systemy służące do wykrywania oszustw finansowych w kontekście oceny zdolności kredytowej, a monitorowanie transakcji AML nie jest tam wymienione wprost. Decyzje wpływające na klienta nadal podlegają RODO, w tym art. 22, oraz przepisom AML.
Czy ocena zdolności kredytowej z użyciem AI jest dozwolona?
Tak, ale to system wysokiego ryzyka. Od 2 grudnia 2027 r. podmiot stosujący musi zapewnić m.in. nadzór człowieka, przechowywanie logów i informowanie klientów, a dostawca systemu musi przejść ocenę zgodności.
Jak DORA wpływa na wybór dostawcy AI?
Wymaga oceny ryzyka dostawcy przed podpisaniem umowy, określonych postanowień umownych, strategii wyjścia i analizy ryzyka koncentracji. W praktyce premiuje rozwiązania, w których model i dane można przenieść bez udziału dostawcy.
Planujesz AI w procesach finansowych i chcesz mieć je od początku zgodne z DORA? Zacznij od audytu DORA, zobacz serwery i klastry GPU w naszej serwerowni Tier III z certyfikatem ISO 27001 i skontaktuj się z nami.