Jak zbudować fintech oparty o AI i dane
Obiecałem wtedy, że w kolejnym „odcinku” zajmę się dokumentacją, zarówno wewnętrzną, jak i zewnętrzną (względem klienta). Jest to część transformacji, której niestety nie unikniemy, tak jak przy okazji każdej większej implementacji. Dobra wiadomość jest taka, że część procesów da się też zautomatyzować, choć dla wielu instytucji będzie to z pewnością obszar, któremu nie poświęcą pierwszych „pięciu minut”, tym bardziej, że automatyzacja polityk i procedur to tematyka rozwojowa.
AI & Data Governance – niezbędne zmiany w dokumentacji
Budowanie AI & Data Governance, które stanowi trzon dla instytucji chcącej być prawdziwie #fintech i #datadriven, musi wiązać się ze zmianami w zakresie dokumentacji. Zasadniczo możemy przyjąć, że zmiany będą dotykać następujących obszarów tematycznych:
1. Dokumentów organizacyjnych, w tym struktury organizacyjnej i regulaminów.
2. Dokumentów stricte biznesowych – powiązanych z oferowanymi produktami i usługami – co obejmuje m.in.:
polityki,
procedury,
instrukcje,
karty produktów,
dokumenty klientowskie – regulaminy, umowy, zgody i oświadczenia.
3. Dokumenty związane z ryzykiem, w szczególności operacyjnym oraz ICT, ale także ryzykami produktowymi, jak ryzyko kredytowe.
4. Dokumenty techniczne będące częścią aspektów infrastrukturalnych związanych z wykorzystaniem #ai oraz przetwarzaniem danych.
5. Dokumenty wynikające z przepisów o ochronie danych (nie tylko RODO, ale także Data Governance Act czy Prawo bankowe).
6. Dokumenty stricte pod rozwiązania oparte o sztuczną inteligencję oraz dane i związane m.in. z takimi procesami jak analityka danych czy data science – warto zwrócić tutaj na karty danych.
7. Dokumenty związane z bezpieczeństwem, zarówno fizycznym, jak i cyberbezpieczeństwem.
8. Dokumentacja związana z poszczególnymi systemami, w tym transakcyjnymi czy do obsługi procesów związanych z przeciwdziałaniem praniu pieniędzy i finansowania terroryzmu #aml czy #fraud.
9. Dokumenty strategiczne, związane z zapewnieniem ciągłości działania czy planami awaryjnymi, jak również mapy procesów czy zasobów.
10. Dokumenty w zakresie outsourcingu, które celowo „wyrzuciłem” z innych kategorii, bowiem mają szczególne znaczenie w kontekście zmian.
11. Dokumenty o charakterze kadrowym, które również mają znaczenie dla skutecznego i efektywnego działania ram AI & Data Governance.
Lista jest oczywiście jedynie ogólnym wykazem najważniejszych obszarów, ale gdybyśmy przyjrzeli się poszczególnym komponentom, to okaże się, że lista jest wyjątkowo długa i obejmuje także te miejsca, które nie wydawały się nam oczywiste pod kątem wykorzystania #ai.
Dlatego rekomendowanym, także przeze mnie, rozwiązaniem jest najpierw przyjrzenie się obszarom, w których pojawiają się lub mogą pojawić się dane (nie tylko analityczne, ale i operacyjne), a następnie zmapowanie (wylistowanie) tych dokumentów, które będą rzeczywiście dotknięte przyszłymi zmianami.
Czytaj także: Przepis na fintech oparty na AI i danych
Zadania dla zespołu projektowego data governance
Oczywiście zakres zmian, które będziemy planowali w dokumentacji będzie uzależniony od modelu wdrażania zasad AI & Data Governance, a więc nie można tutaj zaproponować jednego rozwiązania (one-size-fits-all). Do wszystkich zmian należy podejść indywidualnie. Zakładając jednak, że chcemy wdrożyć rozwiązania typu #datamesh, właściciele tych obszarów (i danych) powinni dokonać oceny dokumentacji, która powinna zostać poddana modyfikacjom, a następnie ustalić zakres wprowadzanych zmian. Niestety, zadanie niełatwe i bez wsparcia ekspertów z zakresu data governance oraz ochrony danych może być trudno. Warto więc postarać się o powołanie zespołu projektowego, który będzie kolektywnie dysponował odpowiednimi kompetencjami.
W kontekście zmian w dokumentacji musimy pamiętać o kilku ważnych kwestiach, które mogą nam umknąć, gdy wpadniemy w wir ekscytujących zmian związanych z transformacją. Należą do nich:
1. Konieczność uwzględnienia perspektywy globalnej i lokalnej, które będą nam wyznaczały kierunek zmian. Przykładowo, jeżeli mamy globalną politykę #ai lub #data, to zmiany lokalne muszą być spójne – na ile to możliwe z takim globalnym podejściem, przy czym globalny oznacza tutaj – dla całej organizacji, jak i dla np. grupy kapitałowej.
2. Zmiany dokumentacyjne obejmować będą zarówno:
sferę stricte regulacyjną – np. ustawa o usługach płatniczych, ustawa o obrocie instrumentami finansowymi czy prawo bankowe, ale i rekomendacje UKNF czy wytyczne EBA;
sferę związaną z ochroną danych i ich udostępnianiem oraz
sferę biznesową,
co oznacza, że musimy zapewnić spójność na wielu polach.
3. Musimy przewidywać konsekwencje zmian w dokumentacji – czasem niepozorna zmiana może mieć poważne konsekwencje w innych obszarach.
4. Sama zmiana i jej akceptacja (uzgodnienie) oraz wdrożenie to za mało – ludzie, którzy będą dotknięci zmianami muszą mieć ich świadomość i rozumieć treść oraz powody – dlatego tak ważne jest ich przeszkolenie.
5. Dokumenty będą pisane inaczej w zależności od odbiorcy; komunikat będzie sformułowany inaczej dla klienta będącego konsumentem, inaczej dla pracownika linii biznesowej, a jeszcze inaczej dla osoby technicznej, która odpowiada za rozwiązania o takim charakterze; zrozumienie dokumentacji ma istotne znaczenie w kontekście wyzwań jakie stoją przed organizacją w kontekście transformacji, więc warto się nad tym pochylić.
6. Dokumenty muszą mieć swoich właścicieli, którzy będą odpowiadali za ich jakość oraz aktualność; jest to szczególnie ważne przy dynamicznie zmieniającym się otoczeniu prawno-regulacyjnym, jak i rozwiązaniach technicznych.
Wyznaczenie zasad odpowiedzialności i wyposażenie w odpowiednie narzędzia do komunikacji
Ilość i jakość informacji zawartych w dokumentach będzie się oczywiście różnić w zależności od poziomu intensywności stosowania rozwiązań opartych o #ai i #dane, ale w przypadku, gdy poważnie myślimy o budowaniu fintechu #datadriven, w praktycznie każdym obszarze znajdziemy jakiś „danowy” element, który można lub trzeba dopracować.
Dlatego wspomniane przeze mnie mapowanie obszarów oraz polityk i procedur ma tutaj kolosalne znaczenie. Szczególnie jeżeli chcemy podejść do tego mądrze. Warto przy tym pamiętać, co podkreślałem w części pierwszej, że najważniejsze jest wyznaczenie zasad odpowiedzialności i wyposażenie w odpowiednie narzędzia do komunikacji. Zasady te powinny korelować z „papierem”, który ma znaczenie nie tylko dla samych interesariuszy, ale także dla szeroko rozumianego obszaru #compliance, a więc i organów nadzorczych oraz regulacyjnych.
Wiele z dokumentów, które będziemy tworzyć lub modyfikować podlega przecież regularnym kontrolom, np. w obszarze modeli wewnętrznych, systemów oceny zdolności kredytowej czy systemu zarządzania ryzykiem, a więc zapewnienie odpowiedniej jakości ma tutaj znaczenie.
Oczywiście, także i wewnętrzne instrukcje dla użytkowników powinny spełniać określone standardy, tym bardziej, że to one będą „najbliższe” użytkownikom systemów #ai. Pozostają także kwestie związane z dokumentami kierowanymi do klientów, które mogą też podlegać określonym wymogom, np. wynikającym ze stanowisk UKNF czy projektowanych aktów prawnych (np. zasady przejrzystości z art. 13 i 52 projektu rozporządzenia w sprawie AI).
Na koniec o dokumentacji technicznej, która w świetle zmian jakie szykują się na bazie AI Act oraz Data Governance Act, mogą być całkiem sporym wyzwaniem. Zasady przygotowywania dokumentacji określać będą liczne akty, załączniki do nich, stanowiska, regulacje i normy ISO, które w kontekście AI & Data Governance i etycznej oraz odpowiedzialnej #sztucznainteligencja będą miały ogromne przełożenie.
I jeszcze jedna sprawa. Pamiętajmy, że zmiany w dokumentacji mają ułatwić nam życie i usprawnić procesy w zakresie wymiany danych, a nie być kolejną porcją biurokracji. Dlatego tak ważne jest wykrywanie zależności, eliminowanie zbędnych procesów i jasna komunikacja.
Dr Michał Nowakowski,
prezes Zarządu Polskiej Organizacji Niebankowych Instytucji Płatności (PONIP).
Poglądy i opinie wyrażone w niniejszym artykule stanowią wyłącznie osobiste poglądy autora i nie mogą być utożsamiane z poglądami lub opiniami instytucji, z którą autor jest lub był związany.
