Najpierw funkcja i skutek, potem model
Agent przygotowujący wewnętrzne streszczenie instrukcji i agent podejmujący czynności w procesie kredytowym nie są tym samym przypadkiem. Przed wyborem dostawcy trzeba ustalić, jaką funkcję wspiera agent, czy funkcja jest krytyczna lub istotna, jakie dane przetwarza, które systemy może zmieniać oraz co stanie się po błędnym wyniku lub przerwie w dostępności.
Zewnętrzny model udostępniany przez interfejs programistyczny zwykle wymaga analizy jako usługa technologii informacyjno-komunikacyjnych świadczona przez podmiot trzeci. Ostateczna kwalifikacja zależy od architektury i funkcji. Nie należy jej zastępować samą etykietą „narzędzie AI”.
DORA nie przenosi odpowiedzialności banku na dostawcę
Rozporządzenie (UE) 2022/2554 w sprawie operacyjnej odporności cyfrowej sektora finansowego, czyli DORA, wymaga włączenia ryzyka dostawców usług ICT do systemu zarządzania ryzykiem. Podmiot finansowy pozostaje odpowiedzialny za wykonanie swoich obowiązków także wtedy, gdy korzysta z zewnętrznej technologii.
Przed zawarciem umowy dotyczącej usługi wspierającej funkcję krytyczną lub istotną art. 28 DORA wymaga między innymi oceny ryzyka, zbadania dostawcy, uwzględnienia ryzyka koncentracji i rozpoznania konfliktów interesów. Dla agenta oznacza to analizę całego rozwiązania: modelu, środowiska, integratora, hostingu, podwykonawców i systemów, w których agent wykonuje czynności.
Minimalny pakiet decyzyjny przed uruchomieniem
| Obszar | Pytanie banku | Dowód |
|---|---|---|
| Funkcja | Jaki proces wspiera agent i czy przerwa wpływa na funkcję krytyczną lub istotną? | Opis procesu, klasyfikacja funkcji i analiza wpływu. |
| Dane | Jakie dane trafiają do modelu, gdzie są przetwarzane i kto może je odczytać? | Mapa przepływu danych, lokalizacje, role i podstawy przetwarzania. |
| Dostawcy | Kto dostarcza model, hosting, integrację i narzędzia pomocnicze? | Łańcuch dostawców i podwykonawców wraz z odpowiedzialnością. |
| Kontrola | Co agent może wykonać sam, co jest sprawdzane automatycznie, a co zatwierdza pracownik? | Klasa K, poziom S, matryca uprawnień i przypadki przekazania sprawy. |
| Odporność | Jak proces działa bez dostawcy albo po zmianie modelu? | Plan ciągłości, tryb zastępczy, kopie konfiguracji i plan wyjścia. |
| Testy | Czy rozwiązanie sprawdzono na typowych sprawach, wyjątkach i danych celowo błędnych? | Matryca testów, raport z wyników i decyzja o uruchomieniu. |
| Nadzór | Kto śledzi wyniki, incydenty, zmiany wersji i skargi? | Wskaźniki, zapisy zdarzeń, właściciel agenta i harmonogram przeglądów. |
Umowa musi odpowiadać rzeczywistej architekturze agenta
Ogólna umowa na dostęp do modelu nie wystarcza, gdy agent wykonuje czynności w procesie banku. Warunki umowne powinny obejmować zakres usługi, lokalizacje przetwarzania, ochronę danych, dostęp i audyt, zgłaszanie incydentów, zmiany podwykonawców, poziomy dostępności, pomoc w zakończeniu współpracy oraz usunięcie lub zwrot danych.
Trzeba również sprawdzić, czy dostawca może jednostronnie wycofać wersję modelu albo istotnie zmienić jej zachowanie. Dla agenta zmiana modelu jest zmianą elementu systemu, nawet jeśli interfejs techniczny pozostał taki sam. Powinna uruchamiać ocenę wpływu i testy regresji, czyli sprawdzenie, czy wcześniej działające przypadki nadal kończą się poprawnym wynikiem.
W usługach chmurowych liczy się także możliwość wyjścia
Europejski Bank Centralny w przewodniku dotyczącym zlecania usług chmurowych wyjaśnia oczekiwania nadzorcze związane z DORA i przedstawia dobre praktyki dla banków objętych jego nadzorem. Przewodnik nie ustanawia nowych, prawnie wiążących wymagań, lecz zwraca uwagę między innymi na koncentrację dostawców, monitorowanie usług, bezpieczeństwo danych i plany wyjścia.
Plan wyjścia dla agenta nie może ograniczać się do eksportu historii rozmów. Organizacja potrzebuje konfiguracji narzędzi, zasad kontroli, zestawów testowych, rejestru wersji, danych potrzebnych do odtworzenia oraz procedury przejścia na rozwiązanie zastępcze. Bez tego zmiana dostawcy może oznaczać ponowne projektowanie całego sposobu wykonywania zadania.
Samodzielność agenta musi odpowiadać skutkom błędu
Wysoka sprawność modelu nie jest wystarczającą podstawą do przyznania szerokich uprawnień. Najpierw ustala się klasę skutku K1–K4 i poziom samodzielności S0–S4. W procesach związanych ze znacznymi zobowiązaniami finansowymi, prawami osoby albo funkcją krytyczną domyślny zakres powinien być węższy. Kontrolę i decyzję o uruchomieniu należy oddzielić od zespołu budującego rozwiązanie.
Projekt ADMS 01 nie dopuszcza poziomu S4 dla klasy K4. Poziom S3 wymaga odrębnego sprawdzenia prawa, dodatkowych zabezpieczeń sektorowych, skutecznego nadzoru i automatycznego zatrzymania. Spełnienie prywatnego standardu nie stanowi podstawy prawnej do uruchomienia systemu.
Największe ryzyko pojawia się po udanym pilotażu
Po pierwszych dobrych wynikach organizacja ma skłonność do rozszerzania danych, uprawnień i liczby obsługiwanych spraw bez ponownej oceny. Tymczasem każda taka zmiana może podnieść klasę skutku, zmienić kwalifikację funkcji albo dołączyć nowego dostawcę. Potrzebna jest formalna decyzja o zmianie, testy i aktualizacja dokumentacji.
W banku agent nie jest osobnym projektem technologicznym poza systemem zarządzania. Powinien wejść do istniejących procesów zarządzania ryzykiem ICT, dostawcami, zmianą, incydentami, ciągłością działania, ochroną danych, audytem i zgodnością. ADMS 01 porządkuje elementy właściwe dla agenta, ale nie zastępuje tych procesów ani oceny prawnej.