Polityka użycia ChatGPT w finansach: jak napisać ją tak, by przeszła compliance i działała w praktyce

Jakie ryzyka compliance pojawiają się przy użyciu ChatGPT w finansach i jak je nazwać w polityce?

W finansach ryzyka compliance przy użyciu ChatGPT wynikają głównie z tego, że dane i treści mogą opuszczać kontrolowane środowisko organizacji, a model może generować odpowiedzi, które wyglądają wiarygodnie, ale nie są zgodne z prawem, regulacjami albo wewnętrznymi procedurami. W polityce warto nazywać ryzyka tak, by dało się je przypisać do właściciela, kontroli i mierzalnych wymagań (np. zakazów, obowiązków weryfikacji, ograniczeń danych).

• Ryzyko ujawnienia informacji poufnych i tajemnic prawnie chronionych (np. tajemnicy bankowej, informacji stanowiących tajemnicę przedsiębiorstwa) – gdy użytkownik wprowadza do ChatGPT dane klienta, transakcji, portfela, raportów wewnętrznych lub treści umów.
• Ryzyko naruszenia ochrony danych osobowych (RODO) – gdy do narzędzia trafiają dane osobowe lub możliwe do zidentyfikowania, a organizacja nie ma podstawy, umowy powierzenia/roli podmiotów, analizy transferów i kontroli retencji; w polityce zwykle łączy się to z zasadą „no PII” oraz klasyfikacją danych.
• Ryzyko niezgodności regulacyjnej treści (comms/marketing/informacja dla klienta, rekomendacje, raporty) – gdy odpowiedzi modelu prowadzą do treści wprowadzających w błąd, niespełniających wymogów disclosure, zasad rzetelnej informacji, albo sugerują doradztwo/rekomendację bez wymaganych podstaw i zatwierdzeń.
• Ryzyko nierzetelności i „halucynacji” (brak ścieżki audytowej) – model może tworzyć błędne uzasadnienia, cytaty czy dane; w polityce ujmuje się to jako obowiązek niezależnej weryfikacji oraz zakaz opierania decyzji finansowych/raportowych wyłącznie na wynikach modelu.
• Ryzyko praw własności intelektualnej i licencyjne – gdy generowane treści naruszają cudze prawa (np. nieuprawnione zapożyczenia) albo gdy do promptów trafiają materiały licencjonowane; w polityce wskazuje się zasady cytowania, weryfikacji pochodzenia i zakaz wprowadzania chronionych treści bez uprawnień.
• Ryzyko konfliktu z politykami bezpieczeństwa informacji (outsourcing narzędzi, „shadow IT”, brak kontroli dostępu) – użycie publicznych kont, nieautoryzowanych integracji, udostępnianie historii czatów; w polityce nazywa się to jako wymaganie użycia wyłącznie zatwierdzonych instancji, kont firmowych i kontroli dostępu.

Praktycznie, nazwy ryzyk w polityce powinny być spójne z rejestrem ryzyk i klasyfikacją informacji w organizacji (np. „Ryzyko RODO”, „Ryzyko tajemnicy bankowej”, „Ryzyko komunikacji regulowanej”, „Ryzyko IP”), bo wtedy łatwo przypisać im konkretne zakazy (jakie dane nie mogą trafić do narzędzia), obowiązki (weryfikacja, zatwierdzenia) i wymagane zabezpieczenia (zatwierdzone środowisko, logowanie, retencja).

Jak sklasyfikować dane finansowe pod kątem tego, co wolno wklejać do narzędzi AI, a czego nie?

Klasyfikację warto oprzeć na dwóch osiach: identyfikowalność (czy dane pozwalają wskazać osobę/klienta/kontrahenta lub konkretną transakcję) oraz wrażliwość biznesowa (czy ujawniają wyniki, marże, płynność, plany, ekspozycje ryzyka itp.). Z punktu widzenia polityki użycia narzędzi AI kluczowe jest, czy dane są już publiczne, czy są wewnętrzne, oraz czy zawierają dane osobowe lub tajemnicę przedsiębiorstwa. Im wyższa identyfikowalność i wrażliwość, tym większe ograniczenia i tym bardziej zasadne jest stosowanie anonimizacji, agregacji lub zakaz wklejania do narzędzi zewnętrznych.

Praktycznie najczytelniej działa podział na cztery kategorie, które można mapować na reguły „wolno/warunkowo/nie wolno”:

Jeżeli masz wątpliwość, potraktuj dane jak kategorię wyższą: usuń identyfikatory (nazwy, numery umów, NIP/REGON, numery rachunków, ID transakcji), przekształć liczby w zakresy lub wartości względne (np. procenty zamiast kwot), ogranicz szczegóły transakcyjne i stosuj minimalizację danych. Taka klasyfikacja ma działać jako prosty filtr: do zewnętrznych narzędzi AI trafiają wyłącznie dane publiczne lub zanonimizowane i uogólnione, a wszystko co poufne, osobowe lub objęte tajemnicą – pozostaje poza nimi, chyba że używasz środowiska formalnie dopuszczonego do takiego przetwarzania.

Jakie zastosowania ChatGPT w finansach są zwykle bezpieczne i dają realną wartość?

Za „zwykle bezpieczne” uznaje się te zastosowania, w których ChatGPT nie otrzymuje ani nie wytwarza treści stanowiących dane poufne, dane osobowe, informacje cenotwórcze lub rekomendacje inwestycyjne, a jego wynik jest traktowany jako pomoc robocza (draft), podlegająca weryfikacji przez człowieka i obowiązującym procedurom. Najwięcej wartości daje tam, gdzie automatyzuje pracę na tekście i strukturze, a nie podejmuje decyzji finansowych.

• Redakcja i standaryzacja dokumentów na bazie zatwierdzonych szablonów (np. doprecyzowanie języka procedur, streszczenia polityk, ujednolicenie formatów raportów) – pod warunkiem używania materiałów pozbawionych wrażliwych danych i pracy na zatwierdzonych wzorcach.
• Wsparcie w interpretacji i porządkowaniu wymagań wewnętrznych (np. checklisty kontrolne, mapowanie procesu, lista pytań do audytu, propozycja kryteriów kontroli) – z wyraźnym rozdzieleniem: model pomaga uporządkować wiedzę, ale nie „zatwierdza” zgodności.
• Pomoc w analizie materiałów szkoleniowych i komunikacji (np. tworzenie FAQ dla pracowników, scenariusze szkoleń, przykłady poprawnych i błędnych zachowań) – bez odnoszenia się do konkretnych klientów, transakcji czy wyników finansowych.
• Praca na danych syntetycznych lub zanonimizowanych (np. generowanie przykładowych rekordów, opis logiki kontroli, pseudokod, test cases do walidacji reguł) – realnie przyspiesza projektowanie i testowanie, o ile nie przenosi się do modelu danych źródłowych.

W praktyce największy zwrot daje wykorzystanie ChatGPT jako „asystenta redakcyjno-analitycznego” do przyspieszania tworzenia szkiców, streszczeń i list kontrolnych. Bezpieczeństwo rośnie, gdy wejście (prompt) ogranicza się do informacji ogólnych lub już publicznych/zaakceptowanych, a wyjście jest formalnie weryfikowane, wersjonowane i zatwierdzane tak jak każdy inny dokument w finansach.

Jakie zastosowania powinny być wprost zakazane, bo prawie zawsze łamią zasady bezpieczeństwa?

W finansach warto wprost zakazać takich użyć ChatGPT, które z definicji wymagają wynoszenia danych chronionych poza kontrolowane środowisko, obchodzą autoryzację lub prowadzą do nieaudytowalnych decyzji. To nie są „ryzykowne przypadki” do oceny ad hoc, tylko scenariusze, w których naruszenie tajemnicy, RODO, wymogów nadzorczych lub polityk bezpieczeństwa jest praktycznie pewne.

• Wprowadzanie do modelu danych poufnych lub wrażliwych (np. dane klientów, dane transakcyjne, informacje o rachunkach, dokumenty KYC/AML, dane zdrowotne, dane z postępowań, treści objęte tajemnicą bankową/ubezpieczeniową, niepubliczne informacje o emitentach) oraz jakiekolwiek dane uwierzytelniające (hasła, tokeny, klucze API, kody MFA).
• „Kopiuj–wklej” dokumentów regulowanych i wewnętrznych do narzędzia, które nie jest zatwierdzone do takiego przetwarzania (np. umowy, wnioski kredytowe, reklamacje, raporty ryzyka, audyty, korespondencja z nadzorem, polityki i procedury), zwłaszcza gdy zawierają identyfikatory osób lub informacje o kontrolach bezpieczeństwa.
• Używanie ChatGPT do obejścia kontroli bezpieczeństwa lub ograniczeń dostępu, w tym: generowanie/pozyskiwanie instrukcji włamania, omijania DLP, socjotechniki, tworzenia phishingu, „promptowania” w celu wydobycia danych, a także proszenie o streszczenia/wnioski na podstawie materiałów, których użytkownik nie ma uprawnień przetwarzać.
• Automatyczne podejmowanie decyzji o skutkach regulacyjnych lub klientowskich bez nadzoru i audytu (np. decyzje kredytowe, scoring, rekomendacje inwestycyjne, klasyfikacja sankcyjna/AML, decyzje o odmowie usługi), gdy wynik modelu staje się rozstrzygający lub nie da się odtworzyć podstaw decyzji i wykazać kontroli.

Wspólny mianownik tych zakazów: przenoszą ryzyko poza akceptowalny poziom, bo wymagają ujawnienia danych chronionych, naruszają zasady „need-to-know” albo tworzą niekontrolowany proces decyzyjny, którego nie da się obronić przed compliance, audytem i nadzorem.

Jak opisać anonimizację i minimalizację danych tak, żeby użytkownik umiał to wykonać?

W polityce opisz te dwa obowiązki jako proste, wykonywalne kroki przed wklejeniem czegokolwiek do ChatGPT: minimalizacja danych (podaj tylko to, co jest niezbędne do uzyskania odpowiedzi) oraz anonimizacja (usuń lub trwale zastąp identyfikatory tak, aby nie dało się zidentyfikować osoby ani podmiotu na podstawie treści). Podkreśl, że „anonimizacja” to nie to samo co „zamazanie” jednego pola — zwykle trzeba usunąć cały zestaw danych, które razem pozwalają na identyfikację.

Żeby użytkownik umiał to wykonać, dodaj do polityki jednoznaczną instrukcję: 1) Usuń dane identyfikujące, 2) Zastąp je neutralnymi znacznikami, 3) Zostaw tylko informacje merytoryczne potrzebne do zadania. Użytkownik powinien wiedzieć, że identyfikatorami są nie tylko imię i nazwisko, ale też numery, loginy i unikatowe atrybuty transakcji oraz dokumentów.

• Minimalizacja (co zostawić): cel zapytania, rodzaj produktu/usługi, ogólne parametry (np. przedział kwot, typ ryzyka, warianty scenariuszy), opis procesu lub problemu. Czego nie wklejać: pełnych dokumentów, całych maili/czatów, dumpów z systemów, szczegółów „na wszelki wypadek”.
• Anonimizacja (co usuwać lub zastępować): imię/nazwisko, nazwy firm/oddziałów, adresy, e-maile, telefony, PESEL/NIP/REGON, numery dokumentów, numery kont (IBAN), numery kart, identyfikatory klienta/użytkownika, sygnatury spraw, numery polis/wniosków/umów, numery transakcji, numery szkód/zgłoszeń, dokładne daty i godziny zdarzeń, konkretne lokalizacje, a także rzadkie kombinacje cech (np. „jedyny klient w danym mieście z takim produktem”), które mogą pośrednio identyfikować. Stosuj podstawienie typu [KLIENT_1], [FIRMA_A], [UMOWA_X], [DATA_MIESIĄC_YYYY-MM], [KWOTA_PRZEDZIAŁ_10-20k].
• Test poprawności (kontrola przed wysłaniem): przeczytaj treść i odpowiedz sobie: „Czy osoba znająca sprawę, system lub rynek mogłaby rozpoznać klienta/podmiot po tych szczegółach?” Jeśli tak — usuń kolejne szczegóły (zwłaszcza identyfikatory, daty, miejsca, unikatowe wartości) lub uogólnij je do przedziałów.

Warto doprecyzować w polityce, że pseudonimizacja (np. zamiana nazwiska na inicjały lub pozostawienie numeru sprawy) nie jest anonimizacją — nadal może umożliwiać identyfikację. Dlatego instrukcja powinna wymagać usuwania także identyfikatorów pośrednich i unikatowych numerów, a przy kwotach/danych czasowych preferować przedziały i uogólnienia zamiast wartości dokładnych.

Jak wymusić weryfikację wyników, żeby uniknąć błędów w raportach i decyzjach finansowych?

Wymuszenie weryfikacji oznacza, że wynik wygenerowany przez ChatGPT nie może trafić do raportu, modelu finansowego ani decyzji (np. rezerwy, wyceny, prognozy) bez udokumentowanej kontroli przez człowieka oraz odtworzenia obliczeń na danych źródłowych. W praktyce trzeba zaprojektować proces tak, aby „brak weryfikacji” blokował publikację lub użycie wyniku.

Najpewniejszy sposób to zasada: ChatGPT może służyć do szkicu, streszczenia i wskazania potencjalnych kroków, ale liczby muszą być przeliczone w narzędziu kontrolowanym (arkusz, system finansowo-księgowy, BI) na zatwierdzonych źródłach danych, a każda wartość w raporcie musi mieć ślad pochodzenia (link do raportu źródłowego, zapytanie, numer wersji pliku, data). Dla treści opisowych (np. komentarz zarządczy) weryfikacja polega na sprawdzeniu zgodności z danymi i definicjami KPI oraz eliminacji kategorycznych stwierdzeń bez oparcia w źródłach.

• Reguły „stop-the-line”: zablokuj użycie wyniku, jeśli brak jest wskazanego źródła danych, daty pozyskania, zakresu (okres, waluta, jednostka) i osoby zatwierdzającej; w raportach wymagaj przypisu/odnośnika do źródła dla każdej kluczowej liczby.
• Niezależne przeliczenie i testy spójności: każdą liczbę z ChatGPT przelicz od zera na danych źródłowych; dodatkowo wykonaj proste testy (sumy kontrolne, zgodność znaków +/- , zgodność walut i kursów, porównanie z poprzednim okresem, zgodność z bilansem/rachunkiem wyników, tolerancje odchyleń).
• Weryfikacja merytoryczna i definicyjna: sprawdź, czy ChatGPT nie zmienił definicji KPI (np. EBITDA, FCF), zakresu konsolidacji, klasyfikacji kosztów/przychodów ani zasad rachunkowości; wymagaj jawnego zapisania użytej definicji i założeń.
• Dowód weryfikacji: utrwal w materiale roboczym (np. w arkuszu lub w systemie obiegu) krótki log: co zweryfikowano, jakim źródłem, jakie wyszły różnice i kto zatwierdził; bez tego wynik traktuj jako „niezweryfikowany” i niedopuszczony do użycia.

Jakie wymagania audytowe i logowanie aktywności warto wprowadzić, żeby dało się to obronić w kontroli?

W kontroli kluczowe jest wykazanie rozliczalności: kto, kiedy, w jakim celu i na jakiej podstawie użył narzędzia, oraz czy organizacja miała możliwość wykrycia nadużyć i odtworzenia przebiegu zdarzeń. Dlatego wymagania audytowe powinny obejmować zarówno kompletność śladu audytowego (wystarczająco szczegółowego), jak i jego wiarygodność (odporność na manipulację), a także spójność z polityką retencji, dostępów i reagowania na incydenty.

Minimalny zestaw zdarzeń do logowania obejmuje: uwierzytelnienie i autoryzację (logowanie, nieudane próby, zmiany uprawnień), użycie funkcji krytycznych (wysyłka promptu, pobranie odpowiedzi, użycie wtyczek/narzędzi, eksport/udostępnienie wyników), zdarzenia administracyjne (zmiany konfiguracji, integracji, zasad DLP/filtrów, wyłączenie logowania), oraz zdarzenia związane z danymi (klasyfikacja wprowadzonego tekstu, oznaczenie naruszenia reguł, blokada/zezwolenie na operację). W logach powinny znaleźć się metadane umożliwiające korelację: identyfikator użytkownika i konta/tenant, rola, identyfikator sesji/urządzenia, znacznik czasu z synchronizacją, adres źródłowy, identyfikator aplikacji/endpointu oraz identyfikator rekordu rozmowy lub transakcji w systemie pośredniczącym.

Żeby ślad audytowy dało się obronić, logi muszą być nieedytowalne dla użytkowników końcowych i możliwie odporne na modyfikację także dla administratorów operacyjnych (np. poprzez rozdział ról, centralne składowanie, kontrolę integralności). Istotne jest również zapewnienie ciągłości logowania: monitorowanie luk w logach, alarmowanie przy braku zdarzeń, oraz mechanizmy wykrywania prób obejścia (np. użycie nieautoryzowanych kanałów). Kontrola często weryfikuje, czy logowanie obejmuje także działania uprzywilejowane i czy istnieje proces przeglądu zdarzeń, a nie tylko ich gromadzenie.

W kontekście treści rozmów należy rozróżnić „logowanie aktywności” od „przechowywania treści”. Z perspektywy audytu zwykle wystarcza przechowywanie metadanych i skrótów/identyfikatorów, a pełną treść promptów i odpowiedzi utrzymywać tylko, gdy jest to uzasadnione ryzykiem i potrzebą dowodową. Jeśli treści są przechowywane, należy wdrożyć minimalizację (np. maskowanie danych wrażliwych), szyfrowanie, ścisłe uprawnienia dostępu oraz jasno określony czas retencji. W przeciwnym razie organizacja generuje nieproporcjonalne ryzyko i obowiązki dowodowe.

Retencja i dostęp do logów powinny wynikać z wymagań regulacyjnych, wewnętrznych polityk oraz realnego czasu wykrycia i dochodzenia incydentów. W praktyce kontrola oczekuje, że: logi są przechowywane wystarczająco długo, aby odtworzyć zdarzenia (w tym po wykryciu opóźnionym), dostęp do nich jest ograniczony i ewidencjonowany, a procedury przewidują ich wykorzystanie w dochodzeniu. Równie ważne jest, aby istniała możliwość szybkiego wyszukania i odtworzenia sekwencji działań dla konkretnego użytkownika, sprawy lub dokumentu (korelacja między systemami, np. IdP, DLP, proxy, SIEM).

Wymagania audytowe warto domknąć procedurą przeglądu i raportowania: kto i jak często analizuje zdarzenia, jakie są progi alertów (np. masowe wklejanie tekstu, częste blokady reguł, nietypowe godziny, wzrost użycia funkcji eksportu), jak dokumentowane są wyniki i działania korygujące. W kontroli pomaga też posiadanie gotowych scenariuszy dowodowych: przykładowy raport aktywności dla wybranego okresu, historia zmian konfiguracji oraz wykaz ról i uprawnień wraz z potwierdzeniem przeglądów dostępu.

Jak wdrożyć politykę w praktyce: szkolenia, kontrola, wyjątki i konsekwencje?

Wdrożenie polityki ma sens tylko wtedy, gdy przekłada się na codzienne zachowania użytkowników i jest mierzalne. W praktyce oznacza to połączenie trzech elementów: zrozumienia zasad (szkolenia i komunikacja), wykrywania i korygowania odchyleń (kontrola), oraz z góry opisanego trybu postępowania w sytuacjach niestandardowych (wyjątki) wraz z konsekwencjami naruszeń. Każdy z tych elementów powinien mieć właściciela (kto odpowiada), ślad dowodowy (co dokumentujemy) i rytm (kiedy weryfikujemy).

Szkolenia powinny uczyć nie tylko „co wolno, a czego nie”, ale także jak bezpiecznie pracować z narzędziem w typowych scenariuszach finansowych (np. streszczanie własnych notatek, poprawa stylu, tworzenie szkiców), oraz jak rozpoznawać ryzyka (wrażliwe dane, tajemnica bankowa/ubezpieczeniowa, dane klientów, dane transakcyjne, informacje poufne). Minimalnym standardem jest szkolenie wstępne przed uzyskaniem dostępu lub przed pierwszym użyciem oraz szkolenia odświeżające po zmianach w polityce lub po incydentach. Dla compliance kluczowe jest potwierdzenie ukończenia i zrozumienia zasad (rejestr uczestników, test wiedzy lub oświadczenie), a dla jakości wdrożenia — dostęp do krótkich instrukcji „jak postępować” w narzędziach pracy.

Kontrola powinna być zaprojektowana tak, by wykrywać zarówno naruszenia, jak i „szare strefy” (np. wprowadzanie do promptów fragmentów dokumentów, które użytkownik błędnie uznaje za neutralne). Z perspektywy operacyjnej zwykle łączy się kontrole prewencyjne (ograniczenia dostępu, blokady, zatwierdzanie użycia w określonych procesach) z kontrolami detekcyjnymi (monitoring, audyty próbkowe, przeglądy logów lub zapisów pracy w ramach dozwolonych narzędzi). Ważne jest ustalenie, co dokładnie jest monitorowane, przez kogo, jak długo przechowywane są dowody oraz jak przebiega eskalacja w przypadku stwierdzenia niezgodności, tak aby mechanizm był proporcjonalny i możliwy do obrony w audycie.

Wyjątki muszą być sformalizowane, bo w finansach realne są sytuacje, w których standardowa reguła blokuje działanie, ale ryzyko da się opanować dodatkowymi zabezpieczeniami. Polityka powinna określać: kiedy wyjątek jest dopuszczalny, kto go zatwierdza (zwykle właściciel procesu wraz z compliance/bezpieczeństwem), na jaki czas, w jakim zakresie (konkretne zadanie, zespół, narzędzie), oraz jakie warunki muszą być spełnione (np. anonimizacja danych, praca na danych syntetycznych, dodatkowa weryfikacja wyniku, praca w środowisku firmowym). Każdy wyjątek powinien kończyć się zapisem w rejestrze wyjątków i przeglądem po okresie obowiązywania, aby wyjątki nie stały się „nowym standardem” bez oceny ryzyka.

Konsekwencje naruszeń powinny być z góry opisane i stopniowalne, aby były skuteczne, a jednocześnie sprawiedliwe i zgodne z prawem pracy oraz procedurami wewnętrznymi. Polityka powinna jasno rozróżniać naruszenia nieumyślne (np. błąd wynikający z niezrozumienia) od rażących lub umyślnych (np. świadome wprowadzanie danych klienta do niedozwolonego narzędzia), bo sposób reakcji będzie inny. Standardem jest powiązanie konsekwencji z procesem: zgłoszenie incydentu, zabezpieczenie dowodów, ocena ryzyka i wpływu, działania naprawcze (w tym ponowne szkolenie), a w razie potrzeby zastosowanie środków dyscyplinarnych zgodnie z regulaminem i obowiązującymi przepisami. Kluczowe jest, aby użytkownicy wiedzieli, że organizacja egzekwuje zasady konsekwentnie, a jednocześnie zapewnia bezpieczny kanał zgłaszania wątpliwości i potencjalnych naruszeń bez karania za samo zgłoszenie w dobrej wierze.

Ewaluacja multimodalna: jak testować modele, które czytają obrazy, wykresy i skany umów 23 kwietnia 2026

Jak nie zepsuć korelacji: Pearson vs Spearman vs Kendall na przykładach biznesowych 21 kwietnia 2026