Due diligence dostawcy AI w instytucji finansowej: co sprawdzić poza demem

Demo trwa dwadzieścia minut, dane wejściowe przygotował dostawca, a model odpowiada bezbłędnie. Dwa miesiące później ten sam model dostaje wniosek kredytowy z nietypowym źródłem dochodu i zwraca decyzję, której nikt w banku nie potrafi uzasadnić ani przed klientem, ani przed nadzorem.

To, co dzieje się między tymi dwiema scenami, nazywa się należytą starannością. Demo pokazuje najlepszy możliwy scenariusz na danych, które dostawca sam sobie dobrał. Due diligence odpowiada na zupełnie inne pytanie: co się stanie, gdy scenariusz okaże się najgorszy, a odpowiedzialność i tak zostanie po Twojej stronie.

Krótka odpowiedź: co sprawdzić poza demem

Poza demem sprawdzasz pięć rzeczy, których prezentacja handlowa z definicji nie pokaże: kim dostawca jest jako podmiot (KRS, sprawozdania finansowe, struktura właścicielska, ubezpieczenie), co naprawdę zbudował (własny model czy nakładka na cudze API, pełny łańcuch podwykonawców, lokalizacje przetwarzania), jak działa na Twoich danych (test na Twoim zbiorze, nie na jego przykładach), co jest gotów podpisać (postanowienia wymagane w art. 30 DORA, prawo do audytu, strategia wyjścia) oraz jak odpowie za błąd (limit odpowiedzialności zestawiony ze skalą realnej szkody, tryb reklamacyjny, wyjaśnialność pojedynczej decyzji).

Kolejność ma znaczenie. Dostawcy, który polegnie na warstwie pierwszej i drugiej, nie warto poświęcać czasu na testy jakości modelu. Umowa bez elementów z art. 30 ust. 3 DORA nie nadaje się do podpisania niezależnie od tego, jak dobre są wyniki.

Dlaczego demo niczego nie dowodzi

Demo ma jeden cel: sprawić, żeby system wyglądał na nieomylny. Dane są wyczyszczone, przypadki brzegowe wycięte, a polecenie dla modelu zespół dostawcy szlifował tygodniami. Nikt nie pokaże Ci przykładu, na którym system się przewraca.

Gorzej: demo milczy o warstwie, która w instytucji finansowej rozstrzyga o wszystkim — gdzie fizycznie leżą dane, kto ma do nich dostęp, jak długo przechowywane są zapytania i czy dostawca może z dnia na dzień podmienić model bazowy. Na te pytania odpowiada umowa i dokumentacja architektury, nigdy prezentacja.

Warstwa 1: kim jest ten podmiot

Zanim w ogóle zaczniesz rozmawiać o modelu, zbierz twarde dane rejestrowe. W Polsce większość z nich jest jawna i bezpłatna.

• KRS i Repozytorium Dokumentów Finansowych (ekrs.ms.gov.pl) — pobierz sprawozdania finansowe za ostatnie dostępne lata. Spółka, która podpisuje z Tobą umowę na trzy lata, powinna mieć zaplecze finansowe pozwalające jej te trzy lata przetrwać. Brak sprawozdań mimo ustawowego obowiązku sam w sobie mówi dość o dyscyplinie organizacyjnej.
• Centralny Rejestr Beneficjentów Rzeczywistych — kto naprawdę stoi za spółką i czy łańcuch właścicielski nie kończy się w jurysdykcji, która skomplikuje przekazywanie danych.
• Wykaz podatników VAT (biała lista) i listy sankcyjne — rutyna, której pominięcie potrafi zablokować płatność.
• Polisa odpowiedzialności cywilnej — interesuje Cię realna suma gwarancyjna, a nie zapewnienie „jesteśmy ubezpieczeni“.

Osobno zapytaj o zespół techniczny. Nie o to, ile osób liczy firma, tylko ile z nich realnie utrzymuje ten konkretny system i co się stanie, gdy odejdą dwie.

Warstwa 2: czy to naprawdę ich AI

Sporą część rozwiązań sprzedawanych jako „autorski model“ stanowi warstwa orkiestracji nad publicznym API dużego dostawcy. To samo w sobie nie jest wadą — bywa rozsądną architekturą — ale całkowicie zmienia profil ryzyka i musi zostać ujawnione, bo wszystko to wpisujesz potem do rejestru informacji z art. 28 DORA.

Pytania, które to rozstrzygają:

1. Który model bazowy i w jakiej wersji pracuje na produkcji? Kto jest jego dostawcą i w jakim kraju stoją serwery, na których liczone są odpowiedzi?
2. Jak wygląda pełny łańcuch podwykonawców ICT — hosting, baza wektorowa, monitoring, obsługa zgłoszeń? DORA wymaga, by umowa opisywała warunki podwykonawstwa usług wspierających funkcje krytyczne lub istotne.
3. Czy Twoje zapytania i dokumenty są przechowywane, a jeśli tak — jak długo i czy służą do trenowania modeli? Żądaj tego na piśmie, a nie na stronie internetowej, którą dostawca zmieni bez uprzedzenia.
4. Co się stanie, gdy dostawca modelu bazowego wycofa wersję albo zmieni jej zachowanie? Kto Cię powiadomi i z jakim wyprzedzeniem?
5. Czy dostawca albo którykolwiek z jego podwykonawców figuruje na liście kluczowych zewnętrznych dostawców usług ICT wyznaczonych przez europejskie urzędy nadzoru (EBA, ESMA, EIOPA)? Listy znajdziesz na ich stronach.

Punkt czwarty jest w praktyce zaniedbywany najczęściej. Jeśli umowa nie zobowiązuje dostawcy do powiadomienia o podmianie modelu bazowego, Twój audyt wewnętrzny pewnego dnia zobaczy zmianę rozkładu odpowiedzi, choć po Twojej stronie nikt nie ruszył ani jednej linijki.

Warstwa 3: dowód skuteczności na Twoich danych

Zamiast oglądać demo, przygotuj własny zbiór testowy i zażądaj, żeby dostawca przepuścił go przez system w nadzorowanym środowisku. Zbiór powinien zawierać przypadki typowe, przypadki rzadkie oraz takie, na których Twoi ludzie już kiedyś się przejechali.

Punkt odniesienia ustal, zanim zobaczysz wynik. Jeśli obecny proces oparty na regułach osiąga jakąś skuteczność, model musi ją wyraźnie przewyższyć, żeby uzasadnić koszt wdrożenia i nowe ryzyko operacyjne. Bez punktu odniesienia każda liczba wygląda dobrze.

Zwróć uwagę na asymetrię błędów. W scoringu, wykrywaniu nadużyć czy przeciwdziałaniu praniu pieniędzy fałszywy alarm i przeoczenie kosztują zupełnie co innego: pierwszy zasypuje zespół pracą, drugi kończy się stratą albo postępowaniem nadzorczym. Proś o wyniki rozbite na oba rodzaje błędów, nie o jedną zbiorczą liczbę.

Warstwa 4: czego wymaga DORA

Rozporządzenie (UE) 2022/2554 (DORA) stosuje się od 17 stycznia 2025 r. i to ono wprost nakłada na podmiot finansowy obowiązek należytej staranności wobec dostawcy technologii. Art. 28 ust. 4 wymaga, by przed zawarciem umowy podmiot ocenił, czy usługa wspiera funkcję krytyczną lub istotną, zidentyfikował ryzyka (w tym ryzyko koncentracji), przeprowadził analizę due diligence i ocenił konflikty interesów.

Co z tego wynika dla wyboru dostawcy AI:

• Klasyfikacja funkcji. Rozstrzygnij na samym początku, czy usługa wspiera funkcję krytyczną lub istotną. Od tego zależy, czy stosujesz sam art. 30 ust. 2, czy także znacznie surowszy ust. 3.
• Postanowienia umowne (art. 30). W każdej umowie: opis usługi, wskazanie państw świadczenia usługi i przechowywania danych wraz z obowiązkiem powiadomienia o zmianie, gwarancje dostępności i integralności danych, zwrot danych, poziomy usług, współpraca przy incydentach i z organami nadzoru, prawa wypowiedzenia. Przy funkcji krytycznej lub istotnej dochodzą: mierzalne cele poziomu usług, obowiązki raportowe, plany awaryjne wraz z ich testowaniem, udział w testach penetracyjnych opartych na scenariuszach zagrożeń, nieograniczone prawa dostępu, inspekcji i audytu oraz strategie wyjścia z obowiązkowym okresem przejściowym.
• Rejestr informacji (art. 28 ust. 3). Każda umowa ICT trafia do rejestru raportowanego do KNF. Dostawca, który nie potrafi podać danych potrzebnych do jego wypełnienia — łącznie z podwykonawcami i lokalizacjami — nie jest gotowy na sektor finansowy.
• Ryzyko koncentracji (art. 29). Sprawdź, czy nowy dostawca nie stoi na tej samej chmurze i tym samym modelu bazowym co systemy, które masz już u siebie.
• Strategia wyjścia (art. 28 ust. 8). Musi być udokumentowana i przetestowana. Pytaj konkretnie: w jakim formacie odzyskasz dane, co dzieje się z modelem douczonym na Twoich danych i czy da się go przenieść.

Szczegóły doprecyzowują regulacyjne i wykonawcze standardy techniczne (RTS i ITS) wydane do DORA. Aktualne wersje sprawdzaj bezpośrednio w EUR-Lex i na stronach europejskich urzędów nadzoru — one się zmieniają, a prezentacja dostawcy sprzed roku nie jest źródłem.

Warstwa 5: AI Act, RODO i wymogi krajowe

Załącznik III do rozporządzenia (UE) 2024/1689 (AI Act) zalicza do systemów wysokiego ryzyka między innymi ocenę zdolności kredytowej osób fizycznych (z wyłączeniem wykrywania oszustw finansowych) oraz ocenę ryzyka i ustalanie cen w ubezpieczeniach na życie i zdrowotnych dla osób fizycznych. Jeżeli system z tego załącznika profiluje osoby fizyczne, zawsze jest systemem wysokiego ryzyka.

Uwaga na dwie pułapki. Pierwsza to art. 25 AI Act: jeśli oznaczysz cudzy system własną marką albo istotnie go zmodyfikujesz, sam stajesz się jego dostawcą i przejmujesz komplet obowiązków. Druga to art. 26, który nakłada na podmiot stosujący obowiązki nadzoru ludzkiego, jakości danych wejściowych i przechowywania rejestrów zdarzeń — a art. 86 daje osobie, której decyzja dotyczy, prawo do wyjaśnienia. Dostawca musi Ci technicznie umożliwić wywiązanie się z tych obowiązków i musi to wynikać z umowy, nie z dobrej woli.

Harmonogram stosowania przepisów o systemach wysokiego ryzyka przesunął Digital Omnibus, ostatecznie przyjęty w czerwcu 2026 r.: wymogi dla samodzielnych systemów z załącznika III zaczną obowiązywać 2 grudnia 2027 r., a dla AI wbudowanej w produkty regulowane odrębnymi przepisami UE (załącznik I) — 2 sierpnia 2028 r. Mimo to zweryfikuj aktualne daty w EUR-Lex, zanim oprzesz plan projektu na terminie podanym przez handlowca.

Po stronie danych osobowych i przepisów krajowych: art. 22 RODO ogranicza decyzje opierające się wyłącznie na zautomatyzowanym przetwarzaniu, jeśli wywołują one skutki prawne; art. 28 RODO wymusza umowę powierzenia, a art. 35 — ocenę skutków dla ochrony danych. Art. 70a Prawa bankowego nakazuje bankowi wyjaśnić klientowi ocenę zdolności kredytowej, więc model, którego decyzji nie umiesz uzasadnić, jest problemem prawnym, nie tylko technicznym. Przy powierzaniu czynności obowiązują art. 6a–6d Prawa bankowego, a przy przetwarzaniu w chmurze publicznej lub hybrydowej — komunikat UKNF w tej sprawie, z wymogami klasyfikacji informacji, oceny dostawcy, planu wyjścia i uprzedniego poinformowania KNF. Aktualną treść komunikatu i stanowisk pobierz z knf.gov.pl, bo bywają uzupełniane.

Demo a dowód: czego prezentacja nie zastąpi

Obszar	Co pokazuje demo	Dowód, o który prosisz	Gdzie to utrwalasz
Skuteczność	Wyselekcjonowane przykłady	Wynik na Twoim zbiorze testowym, z podziałem na rodzaje błędów	Raport z testu i kryteria odbioru
Architektura	Ekran aplikacji	Schemat przepływu danych, model bazowy wraz z wersją, lista podwykonawców	Załącznik techniczny do umowy
Lokalizacja danych	„Dane są w UE“	Wskazane państwa przetwarzania i przechowywania oraz obowiązek powiadomienia o zmianie	Umowa, art. 30 ust. 2 DORA
Retencja	Slajd o prywatności	Okres przechowywania zapytań, zakaz wykorzystania do treningu, tryb usunięcia	Umowa powierzenia, art. 28 RODO
Bezpieczeństwo	Logo normy na stronie	Certyfikat z zakresem (np. ISO/IEC 27001, ISO/IEC 42001), raport SOC 2 Type II, raport z testów penetracyjnych	Ocena dostawcy i rejestr informacji
Ciągłość działania	„Mamy 99,9%“	Wartości RTO i RPO, protokół z testu odtworzenia, tryb pracy awaryjnej bez AI	Umowa o gwarantowanym poziomie usług
Audyt	Zapewnienie ustne	Prawo dostępu, inspekcji i audytu dla Ciebie, Twoich audytorów i KNF	Umowa, art. 30 ust. 3 DORA
Zakończenie współpracy	Nie pojawia się	Plan wyjścia, format eksportu, okres przejściowy	Strategia wyjścia, art. 28 ust. 8 DORA
Odpowiedzialność	Wzorzec umowny dostawcy	Limit odpowiedzialności zestawiony z maksymalną szkodą, polisa	Negocjacje umowne

Sygnały ostrzegawcze typowe dla sektora finansowego

„Jesteśmy zgodni z DORA“ — DORA nie przewiduje certyfikacji dostawców. Zgodność jest obowiązkiem podmiotu finansowego, a dostawca może ją najwyżej umożliwić konkretnymi postanowieniami umownymi. Deklaracja zgodności bez wskazania artykułów to chwyt sprzedażowy.

„Nie możemy ujawnić modelu bazowego ze względu na tajemnicę przedsiębiorstwa“ — bez tej informacji nie wypełnisz rejestru informacji ani nie ocenisz ryzyka koncentracji. To dyskwalifikuje.

„Prawo do audytu przyznajemy tylko dużym klientom“ — przy usługach wspierających funkcje krytyczne lub istotne prawo dostępu, inspekcji i audytu wynika wprost z art. 30 ust. 3 DORA i nie podlega handlowej uznaniowości.

„Nasz model ma dokładność 99%“ — bez podanego zbioru testowego, punktu odniesienia i rozbicia na rodzaje błędów. Liczba bez metodologii jest ozdobą slajdu.

Jak ułożyć to w proces

Rozbij weryfikację na bramki, przez które projekt przechodzi po kolei: kwalifikacja rejestrowo-finansowa, kwestionariusz techniczny i łańcuch podwykonawców, test na własnym zbiorze, ocena prawna i negocjacje umowne, wreszcie decyzja komitetu i wpis do rejestru informacji. Każda bramka ma osobę odpowiedzialną i kryterium odrzucenia ustalone z góry, a nie po obejrzeniu wyników.

Zaplanuj realny czas. Zebranie dowodów bezpieczeństwa, przeprowadzenie testu na własnych danych i wynegocjowanie postanowień z art. 30 DORA zajmuje tygodnie, nie dni — a przy funkcji krytycznej dochodzą jeszcze opinie wewnętrzne i obowiązki informacyjne wobec nadzoru. Presja czasowa ze strony dostawcy („oferta ważna do końca kwartału“) jest tu osobnym sygnałem ostrzegawczym.

I rzecz najważniejsza: kryteria wyjścia z pilotażu zapisz, zanim go uruchomisz. Pilotaż bez ustalonego progu sukcesu zawsze kończy się wdrożeniem, bo nikt nie chce przyznać, że trzy miesiące pracy poszły na marne.