Generacyjna AI w bankowości: zarządzanie ryzykiem nikt jeszcze nie wie, jak mierzyć

Wyobraź sobie scenę: Twój bank właśnie uruchomił generatywne narzędzie bankowe AI wewnętrznie. Oddany przykład, kontrolowane hosting, brak pamięci między sesjami. Wygodny, bezpieczny i szczerze mniej zdolny niż to, czego używają w domu wieczorem. Następnego dnia, przetwarzają notatki komitetu spotkania na publiczne narzędzie, z ich telefonu osobistego, ponieważ jest szybciej. Nikt niczego nie zabronił. Nikt też niczego nie zatwierdził.

Ten scenariusz może nie być jeszcze twoją rzeczywistością. Będzie.

To jest prawdziwy problem z generacyjną SI w systemach informacji bankowej dzisiaj. Nie algorytmy, nie wskaźniki wydajności, nawet nadchodzące rozporządzenie. To jest kapilarność. I ściślej mówiąc, paradoks, którego mało organizacji oczekiwało: wysiłki w zakresie przestrzegania przepisów czasami powodują dokładnie to, co zostały zaprojektowane, aby zapobiegać. Poprzez oferowanie kontrolowanego, ale funkcjonalnie ograniczonego środowiska, organizacje zmuszają pracowników do działania w cieniu SI, gdzie narzędzia są mocniejsze, mniej ograniczone i całkowicie poza granicami zarządzania.

Jak bankowość zawsze walczyła o nowe technologie

Każda największa fala technologiczna w cyberbezpieczeństwo bankowe ma ten sam wzór. Najpierw ramki, potem sieci, potem sieć, potem chmura. Za każdym razem ta sama sekwencja: wykorzystanie pojawia się w zespołach biznesowych lub informatycznych, zyskuje impet zanim funkcje ryzyka i bezpieczeństwa budują swoją doktrynę, a zarządzanie łapie ruchomy pociąg, czasami lata później.

To nie jest krytyka. To rzeczywistość strukturalna. Organizacje nie mogą w pełni przewidzieć zagrożeń związanych z technologiami, które nie są jeszcze w pełni zrozumiałe. Zespoły biznesowe nie czekają na publikację ram przed znalezieniem skuteczniejszych sposobów pracy.

Różnica polega na prędkości i nieprzezroczystości. Rozmieszczanie chmur w dużym banku zajęło lata. Narzędzie zbudowane na dużym modelu językowym może być zintegrowane z przepływem pracy w ciągu kilku dni, przez każdy zespół z dostępem do API.

W przeciwieństwie do chmury, której obwód może być dobrze odwzorowany, gdy się do niego podejmiesz, zależność wokół modeli językowych jest znacznie trudniejsza do namierzenia. Twoje narzędzie nazywa LLM. To LLM może być zbudowany na kilku modelach trzeciej partii. Dane przechodzące przez nią mogą być użyte do dostrojenia gdzieś w łańcuchu. Albo i nie. Nie zawsze wiesz.

Co DORA i ISO 27005 brakuje w odniesieniu do ogólnego ryzyka bankowego w zakresie ptasiej grypy

DORA, ISO 27005, Ramy bezpieczeństwa cybernetycznego NIST: teksty te zostały zaprojektowane w świecie, w którym zagrożenia, jakkolwiek złożone, pozostawały względnie determinujące. Wrażliwość ma wektor ataku. Incydent ma przyczynę. Spis aktywów mówi ci, co ujawniasz.

W przypadku LLM zachowanie nie jest determinujące. Ten sam sygnał może wytwarzać różne wyjścia w zależności od kontekstu, wersji modelu, parametrów, których nie kontrolujesz. Ocena ryzyka powstania systemu opartego na LLM nie wygląda na ocenę systemu konwencjonalnego. Standardowe kryteria — dostępność, integralność, poufność — nadal mają zastosowanie, ale nie wystarczą do uchwycenia ryzyka, takiego jak halucynacje w procesach decyzyjnych, lub dorozumianego wycieku kontekstu.

DORA Artykuł 28 w sprawie krytycznych dostawców z państw trzecich, zaczyna rozumieć część problemu poprzez rozszerzenie nadzoru na dostawców. Ale dostawca LLM nie jest tradycyjnym dostawcą IT: usługa, którą świadczy jest zasadniczo probabilistyczna, a sposób przetwarzania danych przychodzących nie zawsze jest kontrolowany w tradycyjnym znaczeniu tego słowa.

Nie jest to krytyka osób, które opracowały te teksty. Po prostu rozporządzenie z natury wiąże się z ryzykiem, że ma czas na obserwację i modelowanie. Nadal jesteśmy w fazie obserwacji.

Trzy sposoby zarządzania ryzykiem związanym z bankowością Uogólnioną

W obliczu tej niepewności pokusą jest albo zakazanie (nieskuteczne, wykorzystanie znajduje sposób na obejście), albo czekanie, aż organy regulacyjne opublikują swoje wytyczne (zbyt powolne, dalsze wdrażanie). Jest trzecia ścieżka, mniej spektakularna, ale bardziej operacyjna.

Zacznij od klasyfikacji zastosowań. Nie wszystkie zastosowania wtórnej SI w organizacji bankowej mają taki sam poziom ryzyka. Opracowanie wewnętrznej komunikacji na temat niewrażliwym nie jest tym samym, co wykorzystanie LLM do analizy danych klientów lub tworzenia regulacyjnych elementów sprawozdawczych. Prosta siatka klasyfikacji, przekraczająca czułość danych przetwarzanych względem poziomu automatyzacji produkcji, umożliwia odróżnienie tego, co może swobodnie poruszać się od tego, co wymaga bardziej rygorystyczne ramy zarządzania.

Mapa zależności, nawet nieidealnie. Nie potrzebujesz wyczerpującej mapy, aby uzyskać widoczność. Nawet niekompletny spis narzędzi wywołujących zewnętrzne API LLM — według zespołu, według przypadku użycia, według typu danych — jest lepsze niż nic. Ta mapa będzie zła na początku. Polepszy się. Taka jest zasada.

Stwórz lekką ścieżkę walidacji eksperymentów. Jeśli jedyna droga do użycia narzędzia AI przebiega przez sześciomiesięczny proces walidacji, zespoły będą pracować wokół niego. Zwarcie — kilka jasnych kryteriów, dwutygodniowy przegląd, odizolowana piaskownica — pozwala na odzyskanie widoczności na tym, co się dzieje, a jednocześnie pozwala zespołom wprowadzać innowacje. Zarządzanie poprzez projektowanie, a nie przez zakaz.

Kwestia tempa

To, co mnie uderza, na koniec dnia, nie jest nowością problemu. Jest to różnica prędkości między tym, co organizacje są w stanie nauczyć się, a tempem, w jakim zastosowania stają się zakorzenione.

W poprzednich cyklach ta różnica również istniała. Ale zostało trochę więcej czasu. Teraz, generacyjne narzędzia bankowe AI są wbudowane w krytyczne przepływy pracy w ciągu kilku dni, podczas gdy zespoły zarządzające nadal czytają pierwsze sprawozdania analityczne opublikowane na ten temat.

Nie sądzę, by odpowiedzią było szybsze zarządzanie — są granice strukturalne. Myślę, że odpowiedzią jest zaakceptowanie, że ryzyko będzie niedoskonale kontrolowane przez jakiś czas, i stworzenie mechanizmów, które pozwolą szybkie wykrywanie i korekcja Zamiast udawać, że wszystko jest wyczerpujące.

Jest to dość głęboka zmiana postawy zespołów bezpieczeństwa, których rola od dawna polega na odmawianiu, zanim coś pójdzie nie tak. Ale jest to prawdopodobnie jedyna realistyczna postawa w tym kontekście.

Prawdziwym pytaniem nie jest, czy wasze zespoły już wykorzystują LLM w codziennej pracy. Są. Pytanie brzmi, czy wiesz w jakiś sposób.