Automatyzacja AI w finansach i u dostawców ICT: uporządkuj odpowiedzi i dowody

Najłatwiejszy do sprawdzenia początek automatyzacji AI w finansach to praca na dokumentacji: wyszukanie dowodu kontroli, przygotowanie szkicu odpowiedzi na ankietę i wskazanie braków w informacjach o dostawcy. Każdy z tych procesów można ograniczyć do konkretnych źródeł oraz osób zatwierdzających. Wynik da się porównać z pracą ręczną.

W instytucji finansowej problemem bywa rozproszenie wiedzy między umową, rejestrem dostawców, systemem zgłoszeń i dokumentami bezpieczeństwa. U dostawcy ICT podobny problem pojawia się po otrzymaniu kolejnej ankiety klienta. Długi formularz nie oznacza, że odpowiedzi wolno wygenerować z pamięci modelu. Deklaracja o działającej kontroli wymaga aktualnego dowodu.

Ten materiał dotyczy dokumentacji, ryzyka dostawców i procedur wewnętrznych. Nie przedstawia automatycznej oceny zdolności kredytowej, decyzji inwestycyjnych ani pełnego programu wdrożenia DORA. Wymogi są oznaczone źródłami; proponowany sposób organizacji pracy jest zaleceniem autora.

Jeden proces, dwie perspektywy

Po stronie instytucji finansowej asystent może kompletować informacje potrzebne do oceny usługi ICT: opis zakresu, funkcję wspieraną przez usługę, lokalizację przetwarzania, podwykonawców i właściciela umowy. Może pokazywać, gdzie dokumenty nie odpowiadają na pytania. Ostateczna ocena ryzyka i akceptacja dostawcy pozostają u właściwych osób.

Po stronie dostawcy ICT przydatny jest szkic odpowiedzi na ankietę klienta, oparty wyłącznie na zatwierdzonych dokumentach. Każda odpowiedź powinna wskazywać dowód, jego zakres i datę. Jeżeli pytanie dotyczy wszystkich usług, a dokument obejmuje jedną usługę, asystent ma pokazać tę różnicę. Rozszerzenie deklaracji bez podstawy tworzy problem kontraktowy.

W obu przypadkach zaczynaj od odczytu i szkicu. Samodzielna wysyłka do klienta, zmiana rejestru lub akceptacja ryzyka to oddzielne operacje. Nadaj im własne uprawnienia oraz zasady zatwierdzania dopiero wtedy, gdy jest uzasadniona potrzeba. Dodawanie autonomii nie powinno zastępować naprawy niespójnych źródeł.

DORA: odpowiedzialności nie przekazuje się modelowi

DORA stosuje się do określonych podmiotów finansowych z uwzględnieniem zakresu i wyjątków. Podmiot finansowy pozostaje odpowiedzialny za spełnienie swoich obowiązków także wtedy, gdy korzysta z zewnętrznych usług ICT. Artykuł 28 obejmuje zarządzanie ryzykiem dostawców, ocenę przed zawarciem umowy oraz rejestr informacji o ustaleniach umownych dotyczących usług ICT. [1]

Artykuł 30 opisuje wymagane elementy umów, w tym zakres usług, lokalizacje, ochronę danych, dostęp i zwrot danych, pomoc przy incydentach oraz prawa rozwiązania umowy. Usługi wspierające funkcje krytyczne lub istotne mają dodatkowe wymagania. Nie należy stosować tej samej oceny do każdej usługi bez rozpoznania jej roli w działalności klienta. [1]

Dostawca, który sprzedaje usługę bankowi, nie staje się przez sam ten fakt instytucją finansową. Może jednak podlegać wymaganiom umownym klienta, a wyznaczeni krytyczni dostawcy ICT mają odrębne ramy nadzoru. Dlatego odpowiedź „mamy DORA” jest zbyt ogólna. Trzeba wskazać podmiot, usługę, rolę i konkretny wymóg.

RODO nadal wymaga oceny danych osobowych, celu, podstawy, powierzenia i bezpieczeństwa. [2] AI Act wymaga oceny przeznaczenia systemu: wyszukiwanie procedur jest innym zastosowaniem niż ocena zdolności kredytowej osoby fizycznej lub określona ocena ryzyka i ceny w ubezpieczeniach na życie oraz zdrowotnych. Nie każdy chatbot finansowy jest systemem wysokiego ryzyka. [3]

NIS2 może obejmować określone podmioty i usługi ICT. W sektorze finansowym istotna jest także relacja z DORA jako regulacją sektorową. Sprawdź zakres działalności, rolę i krajową implementację zamiast sumować obowiązki obu aktów z przypadkowej checklisty. [4]

Ustal źródło każdej deklaracji

Ankieta bezpieczeństwa często miesza opis polityki, stan techniczny i zobowiązanie umowne. To trzy różne rzeczy. Polityka wykonywania kopii nie potwierdza, że ostatnia kopia konkretnego systemu się powiodła. Raport z jednego testu odtworzeniowego nie dowodzi, że wszystkie usługi można odtworzyć w takim samym czasie.

Przy każdej odpowiedzi zapisuj rodzaj dowodu, usługę, zakres, datę i właściciela. Brak powinien prowadzić do zadania wyjaśniającego. Starszy dowód można oznaczyć do przeglądu zgodnie z zasadami organizacji; nie istnieje jedna uniwersalna data ważności wszystkich dokumentów bezpieczeństwa. Nie pozwalaj modelowi dopisywać certyfikatów, audytów ani terminów, których nie ma w źródle.

Warto wprowadzić statusy: potwierdzone w źródle, wymagające wyjaśnienia i poza zakresem. Status opisuje stan wiedzy. Nie zastępuje decyzji o akceptacji ryzyka. Osoba zatwierdzająca widzi wtedy, które odpowiedzi może wysłać, a które wymagają kontaktu z właścicielem kontroli.

Dane, role i prawa do działania

Ta tabela jest proponowaną macierzą operacyjną. Uzgodnij ją przed udostępnieniem dokumentów i narzędzi.

Nie udostępniaj asystentowi sekretów, pełnych danych transakcyjnych lub całego środowiska klienta tylko dlatego, że istnieje wygodny konektor. Dla ankiety zwykle potrzebny jest zatwierdzony opis kontroli i dowód w odpowiednim zakresie. Raport z testu penetracyjnego może zawierać informacje, których nie wolno przekazać każdemu odbiorcy.

Ograniczenia muszą działać również w wyszukiwaniu i indeksie dokumentów. Pracownik jednego klienta nie może uzyskać dokumentu innego klienta przez pytanie sformułowane w inny sposób. Weryfikacja dostępu powinna następować przed przekazaniem materiału do modelu. Filtr w samym tekście polecenia jest za słabym mechanizmem.

API i MCP z kontrolą poza modelem

Zaprojektuj mały zestaw operacji: odczyt zatwierdzonego dokumentu, odczyt określonych pól rejestru, utworzenie projektu odpowiedzi lub zgłoszenia. Każde narzędzie powinno sprawdzać rolę, zakres danych i parametry. Uprawnienia konta technicznego mają odpowiadać temu zestawowi. Model nie powinien móc rozszerzać ich przez kolejne polecenie.

Dokument dostawcy lub ankieta może zawierać instrukcję nakłaniającą do ujawnienia danych, zignorowania ograniczeń lub wywołania narzędzia. To przykład prompt injection opisywanego przez OWASP. [5] Dokument pozostaje materiałem wejściowym, nawet gdy używa słów „administrator” lub „pilne polecenie”. Kontrola aplikacji musi odrzucić operację poza zakresem.

Przed zapisem pokaż różnicę między bieżącą a proponowaną wartością. Dla zapisu zastosuj klucz idempotencji obsługiwany przez komponent wykonawczy, żeby ponowienie po błędzie sieci nie tworzyło kolejnych zadań. Sam identyfikator korelacyjny nie blokuje duplikatów. Te rozwiązania są zaleceniami projektowymi. Ich sens polega na ograniczeniu skutków błędu i możliwości odtworzenia zdarzenia, a nie na samej liczbie zabezpieczeń.

Umowa i zależności przed uruchomieniem

Ustal cały łańcuch przetwarzania: aplikację, model, indeks dokumentów, logi oraz ewentualnych podwykonawców. Sprawdź lokalizacje, wykorzystanie danych przez dostawców, retencję, obowiązki przy zmianie usługi i dostępność dowodów. Regionalna lokalizacja jednego komponentu nie opisuje automatycznie całej usługi.

Jeżeli rozwiązanie wspiera funkcję krytyczną lub istotną w rozumieniu DORA, potrzebna jest ocena odpowiednich dodatkowych wymagań umownych i operacyjnych. [1] Sam fakt dodania AI do narzędzia nie przesądza tej kwalifikacji. Ważne jest, co przestanie działać w instytucji finansowej, gdy narzędzie lub jego dostawca będzie niedostępny.

W opisie usługi wskaż ręczny sposób obsługi, procedurę incydentu oraz eksport danych. Nie obiecuj nieograniczonej autonomii, gwarantowanej zgodności ani określonej retencji, jeżeli nie potwierdza ich rzeczywista konfiguracja i umowa. Takie obietnice trafiają później do ankiet następnego klienta i zaczynają żyć własnym życiem.

Wymagania, działania i szkolenia

Pulsar GRC jest rozwijany we wczesnym dostępie jako wsparcie pracy na dokumentach klienta, wymaganiach, kontrolach, ryzykach, działaniach i dowodach. W tym obszarze przydatny jest związek: pytanie klienta, wymaganie, kontrola, dowód i właściciel. Dostępność potrzebnych funkcji oraz zakres integracji trzeba potwierdzić przed wdrożeniem.

Zmianowo/CrewShift rozwija szkolenia i testy na podstawie dokumentów, z zatwierdzaniem przez człowieka. Może wesprzeć przygotowanie personelu do zmienionej procedury obsługi incydentu lub oceny dostawcy po potwierdzeniu zakresu. Wynik testu nie stanowi oficjalnej kwalifikacji ani samodzielnego dowodu, że pracownik potrafi obsłużyć realne zdarzenie.

Odpowiedzialność pozostaje jasna: właściciel kontroli potwierdza stan, osoba uprawniona akceptuje odpowiedź, a zespół techniczny odpowiada za uzgodnioną konfigurację. Produkt pomaga uporządkować pracę. Nie ma prawa zamienić brakującego dowodu w spełnione wymaganie.

Pilotaż: jedna ankieta i jeden zakres usług

Proponuję zacząć od jednej zakończonej wcześniej ankiety, kilkudziesięciu pytań i dokumentacji jednej usługi. To propozycja organizacyjna, nie wymóg DORA. Przygotuj poprawne odpowiedzi referencyjne i zaznacz pytania, które wymagały wyjaśnień. Usuń dane, których nie potrzebuje proces, oraz informacje objęte ograniczeniami udostępniania.

Sprawdź wynik na pytaniu bez dowodu, dokumencie nieaktualnym, dwóch sprzecznych opisach oraz żądaniu informacji spoza uprawnień użytkownika. Oceniaj poprawność odniesienia i zgodność zakresu deklaracji. Jeżeli odpowiedź brzmi „tak”, ale źródło opisuje tylko plan wdrożenia, oznacz ją jako błąd istotny.

Mierz czas przygotowania razem z korektą, odsetek odpowiedzi zaakceptowanych bez zmiany, liczbę braków poprawnie wykrytych i nieuprawnione operacje. Spadek czasu samego generowania nie pomaga, gdy przegląd trwa dłużej. NIST AI 600-1 może wesprzeć dobór ryzyk do oceny; jest dobrowolnym materiałem, nie certyfikatem zgodności. [6]

Koszt utrzymania źródeł

Do kalkulacji dolicz pracę właścicieli dokumentów. Po zmianie lokalizacji, podwykonawcy lub zakresu usługi ktoś musi uaktualnić zatwierdzony opis. Jeżeli stare źródło zostaje w indeksie, asystent może szybko przygotować odpowiedź, która była poprawna miesiąc wcześniej. Skrócenie czasu generowania ukrywa wtedy wzrost ryzyka.

Właściciel usługi powinien wskazać zdarzenia wymagające przeglądu: nowy kontrakt, zmiana konfiguracji, istotny incydent lub wynik testu pokazujący nieskuteczność kontroli. Koordynator dokumentacji ustala, które odpowiedzi wymagają aktualizacji i czy należy poinformować odbiorców. To proponowany sposób organizacji, który trzeba dopasować do umów oraz procedur.

Sprawdź również koszt wyjaśniania wyjątków. Zestaw pięć pytań obsłużonych automatycznie z jednym trudnym pytaniem, które wymaga dwóch godzin pracy ekspertów. Dopiero suma czasu pokazuje wartość procesu. Sensownym wynikiem pilotażu może być lepsza identyfikacja braków, nawet gdy oszczędność czasu jest mniejsza od oczekiwanej. Nie przedstawiaj tego jako potwierdzonej redukcji kosztów, dopóki nie masz pomiaru.

Fikcyjny przykład dostawcy dla sektora finansowego

W poniższym fikcyjnym scenariuszu firma ICT otrzymuje ankietę dotyczącą jednej usługi. Ma politykę kopii zapasowych, raport odtworzenia oraz opis podwykonawców. Asystent znajduje dowody i przygotowuje szkic. Dwa pytania dotyczą obszarów, których dokumenty nie obejmują. Zamiast odpowiedzi pozytywnej powstają dwa zadania do właścicieli kontroli.

Osoba odpowiedzialna za bezpieczeństwo sprawdza zakres, prawnik ocenia zobowiązania, a właściciel usługi zatwierdza finalną odpowiedź. Dopiero wtedy dokument trafia do klienta. Nie jest to wynik wdrożenia Brillnet. Przykład pokazuje strukturę pracy i momenty, w których człowiek podejmuje decyzję.

Incydent i wyjście z usługi

Po nieuprawnionym odczycie lub zapisie zatrzymaj dotkniętą integrację, zachowaj potrzebne logi i sprawdź zasięg zdarzenia. Właściwa osoba uruchamia ocenę według procedur organizacji, obowiązków umownych i stosowanych przepisów. DORA, RODO i NIS2 mają własne zakresy oraz zasady; nie każde zdarzenie uruchamia wszystkie tryby. [1][2][4]

Przed startem uzgodnij eksport dokumentów, odpowiedzi, powiązań i dowodów. Sprawdź, czy po odłączeniu modelu nadal można korzystać z zatwierdzonych zapisów. Określ odwołanie kont technicznych, obsługę kopii oraz potwierdzenie zakończenia. Wyjście jest częścią projektu, a nie zadaniem odkładanym do chwili rozwiązania umowy.

Opisz proces, który ma się poprawić

Brillnet ustala przed uruchomieniem zakres narzędzi, role, dane i warunki wyjścia. Do rozmowy przygotuj przykładową ankietę bez informacji poufnych, listę źródeł i czas potrzebny na odpowiedź. Wskaż także osobę, która ma prawo zatwierdzić deklaracje. Te informacje pozwalają ocenić sens oraz koszt automatyzacji.

Prześlij opis procesu do Brillnet. Dla powiązania wymagań i dowodów sprawdź Pulsar GRC, a dla szkoleń z procedur Zmianowo. Wdrożenie ma sens wtedy, gdy zmniejsza łączny wysiłek i zachowuje wiarygodność odpowiedzi.

Źródła

Zweryfikowano 2 października 2026 r. Zakres regulacji i wymogi szczegółowe należy ocenić dla podmiotu i usługi. Pilotaż oraz przykład są propozycjami autora.

1. DORA — rozporządzenie (UE) 2022/2554, art. 2, 28–31 i 64. EUR-Lex; dostęp: 2026-10-02.
2. RODO — rozporządzenie (UE) 2016/679, art. 5, 6, 28 i 32–35. EUR-Lex; dostęp: 2026-10-02.
3. AI Act: przeznaczenie i klasyfikacja systemów oraz aktualny tekst skonsolidowany rozporządzenia (UE) 2024/1689. Komisja Europejska i EUR-Lex; dostęp: 2026-10-02.
4. NIS2 — dyrektywa (UE) 2022/2555, art. 2, 4, 21 i 23 oraz załączniki. EUR-Lex; dostęp: 2026-10-02.
5. OWASP LLM01:2025 — Prompt Injection. OWASP GenAI Security Project; dostęp: 2026-10-02.
6. NIST AI 600-1 — Generative Artificial Intelligence Profile. NIST; dostęp: 2026-10-02. Dobrowolne wskazówki, nie prawo UE.