Dlaczego – z perspektywy danych referencyjnych, słowników i audytu regulacyjnego – agent AI nie zastępuje warstwy metadanych, lecz opiera się na niej.
Każdy zarząd, który wierzy, że AI rozwiąże problem zarządzania danymi w organizacji, popełnia błąd na etapie założeń. AI nie zastępuje warstwy metadanych, czyli uporządkowanej wiedzy o tym, jakie dane mamy, co znaczą, skąd pochodzą i kto je zmieniał, ale opiera się na niej. Każda obietnica, że duży model językowy „sam się tego dowie”, zostaje złamana już w pierwszym kontakcie z audytem regulacyjnym, kiedy nie pada pytanie „co macie w danych”, lecz „jak zarządzaliście tymi danymi 13 maja o czternastej siedemnaście”.
W tym artykule pokazuję, dlaczego warstwa metadanych jest niezbędna i co z tego wynika dla architektury danych w instytucji finansowej w 2026 roku.
DLA KOGO TEN ARTYKUŁ
Członkowie zarządów, CDO, menedżerowie Data Governance, dyrektorzy IT i architekci danych w bankach, instytucjach ubezpieczeniowych i innych podmiotach sektora finansowego.
STRESZCZENIE
O tym, dlaczego adopcja AI w organizacji regulowanej powinna zaczynać się od metadanych, nie od modelu. I dlaczego każda inna kolejność kończy się tym samym – pismem z KNF.
Rozwiązania oparte na AI wciąż wzbudzają w środowisku data dwie skrajne reakcje. Jedna szkoła twierdzi, że LLM zwolni nas z obowiązku utrzymywania słowników, dokumentowania lineage’u, czyli rodowodu danych i prowadzenia jednostek BICC – bo „agent się dowie”. Druga trzyma się od AI z daleka, argumentując, że to ryzyko, nie narzędzie. Obie się mylą. Pierwsza nie rozumie, czym jest audyt regulacyjny – druga zakłada, że organizacja regulowana może po prostu przeczekać zmianę.
Houston, mamy problem, czyli jak odpowiedzieć na pytanie audytora KNF o stan danych w konkretnym dniu?
Ta historia zdarzyła się prawdopodobnie w każdym banku. Tylko nie każdy o tym wie – bo zdarza się komuś innemu, w innym kwartale, pod innym pretekstem. Schemat za każdym razem jest taki sam.
Duży polski bank. Osoba z zarządu odpowiedzialna za compliance dostaje pismo z Komisji Nadzoru Finansowego. Sprawa dotyczy incydentu związanego z wyciekiem informacji o osobach zajmujących eksponowane stanowiska polityczne – klientach typu PEP (Politically Exposed Persons). Regulator prosi o szczegółowe wyjaśnienia. Termin: dziesięć dni roboczych.
Pierwsze pytania są banalne – dopóki nie spróbuje się na nie odpowiedzieć. Jak oznaczamy klientów PEP? W których obiektach danych odbywa się to oznaczanie? Jakie algorytmy obowiązywały w dniu incydentu?
Te trzy pytania wystarczą, by uruchomić w organizacji lawinę działań, angażującą co najmniej pięć narzędzi i osiem osób. I wywołać zbiorową amnezję.
Bo w środowisku regulowanym same dane nie wystarczą. Liczy się możliwość odtworzenia ich pochodzenia, zmian, przepływu i kontroli dostępu – w stanie z dnia incydentu. Każde z tych narzędzi i każda z tych osób próbuje odtworzyć inny fragment stanu danych z dnia incydentu.
Krok po kroku:
Zaczynamy od narzędzia do modelowania hurtowni danych
(centralnego repozytorium analitycznego organizacji, w którym łączy się informacje z wielu systemów źródłowych). Bank nie zdążył wdrożyć data catalog, czyli wyszukiwarki wiedzy o danych, pokazującej dla każdego pola: co oznacza, skąd pochodzi, kto z niego korzysta i jakie ma ograniczenia dostępu, więc dokumentacja aktualnej struktury żyje tam, gdzie żyje od dekady: w narzędziu, w którym architekci hurtowni rysują diagramy. Znajdujemy pole KLIENT_VIP z powiązanym słownikiem wartości – czyli zamkniętą listą dopuszczalnych kodów. To typowy przykład danych referencyjnych: stałych zbiorów wartości, do których odwołują się pola w wielu systemach jednocześnie. W słowniku jest osiem kodów, wśród nich kod PEP.
Z hurtowni przechodzimy do repozytorium słowników i metadanych.
I tutaj zatrzymujemy się na pytaniu, na które naprawdę warto znać odpowiedź: jak słownik wyglądał w dniu incydentu? Słowniki zmieniają się w czasie. Tu wchodzi historyzacja – mechanizm, który dla każdej zmiany w słowniku, mapowaniu czy regule zapisuje stan przed i po, wraz z datą i autorem zmiany. Bez historyzacji znamy tylko stan dzisiejszy. Pierwsze pytanie regulatora pozostaje bez odpowiedzi. Wszystkie kolejne – także.
Załóżmy, że słownik mamy odtworzony. Idziemy dalej - do statystyk zawartości pól w hurtowni.
Administrator uruchamia zapytanie i zwraca histogram rozkładu wartości w polu KLIENT_VIP. Okazuje się, że nie wszystkie wartości dopuszczone przez słownik faktycznie występują w danych. To informacja istotna sama w sobie – pokazuje, gdzie słownik rozmija się z rzeczywistością. Audytu jeszcze nie zamyka. Audytu nic jeszcze nie zamyka.
Następne pytanie dotyczy data lineage.
Trzeba ustalić, skąd biorą się kody w polu KLIENT_VIP, przez jakie przekształcenia przechodziły i jak były wyliczane w dniu incydentu. Także tutaj wymiar czasu jest krytyczny: kody przekształceń i słowniki translacji ulegają zmianie, a my potrzebujemy stanu z konkretnej daty.
Idziemy w głąb.
KLIENT_VIP wyliczany jest z pola tymczasowego TMP_KLIENT_WAZNY. TMP_KLIENT_WAZNY budowany jest na podstawie zestawu funkcji flagujących:
sql
CASE
WHEN biz_flag(CUSTOMER_ID)=1 THEN 'BIZ’
WHEN cel_flag(CUSTOMER_ID)=1 THEN 'CEL’
WHEN pep_flag(CUSTOMER_ID)=1 THEN 'PEP’
WHEN spo_flag(CUSTOMER_ID)=1 THEN 'SPO’
WHEN tel_flag(CUSTOMER_ID)=1 THEN 'TEL’
WHEN est_flag(CUSTOMER_ID)=1 THEN 'EST’
ELSE null END
Funkcja ustawia wartość 1 na podstawie pola C114F z tabeli CUSTOMER w data marcie DM_VIPS (data mart to tematyczna wycinka hurtowni – w tym wypadku dotycząca klientów istotnych – zoptymalizowana pod konkretny obszar analityczny).
I tu zaczyna się droga przez mękę.
Regulator nie będzie nam jej skracał. Aby dotrzeć do logiki wyliczania pola C114F, trzeba kolejno: zlokalizować opiekuna danych DM_VIPS w narzędziu Data Governance, skontaktować się z autorem algorytmu (jego nazwisko otrzymujemy od opiekuna danych), sprawdzić w repozytorium GIT stan algorytmu na datę wycieku, potwierdzić – na podstawie pamięci autora – że pole C114F jest pobierane jeden do jednego z pola CLIPEP w tabeli CLIENTS systemu źródłowego.
Cała ta operacja opiera się na fragmentach czyjejś pamięci. To nie jest architektura. To jest folklor.
Po kilku dniach pracy wracamy do KNF z odpowiedzią: wiemy, jak oznaczanie klientów PEP się odbywało i jakie algorytmy przetwarzania obowiązywały w dniu incydentu.
I wtedy padają kolejne pytania.
Jakie role mają dostęp do pól KLIENT_VIP, C114F, CLIPEP oraz do danych osobowych i wrażliwych w hurtowni, data marcie i systemie źródłowym? Kto faktycznie z tych danych korzysta? W jakich raportach, data martach i analizach możemy je zidentyfikować?
Zaczynamy drogę przez mękę od początku. Tym razem z innymi opiekunami danych, innymi autorami algorytmów, innymi commitami w GIT.
Czy w takiej sytuacji poradziłoby sobie jakiekolwiek narzędzie AI?
AI wysyła agentów - czy potrafi odtworzyć stan danych referencyjnych z przeszłości?
Odpowiedź nie jest jednoznaczna. Trzeba rozważyć ją na dwóch płaszczyznach.
Płaszczyzna pierwsza: AI też potrzebuje metadanych.Narzędzie AI – czy to klasyczny agent, czy LLM (Large Language Model – duży model językowy, np. ChatGPT, Claude, Gemini) z dostępem do firmowych zasobów przez RAG (Retrieval-Augmented Generation – technikę, w której model najpierw wyszukuje odpowiednie fragmenty z firmowej bazy wiedzy, a dopiero potem na ich podstawie formułuje odpowiedź) – musi mieć dostęp do informacji o tym, jakie mamy dane, jaka jest zawartość słowników i danych referencyjnych, w jaki sposób dane są wyliczane. Bez uporządkowanych metadanych agent potrafi tylko tyle, ile wyczyta z dostępnego kontekstu. A to za mało, by udzielić odpowiedzi na pytania regulatora.
Płaszczyzna druga: krytyczna jest historyzacja metadanych. Żeby AI wykonało analizę na konkretną datę w przeszłości, musiałoby uruchomić serię agentów rekonstruujących stan słownika, kodu i mapowań na ten dzień.
Biorąc pod uwagę stan rozwoju narzędzi AI w 2026 roku, to drugie wydaje się dziś jeszcze mało realne – i nie z powodu mocy obliczeniowej, lecz z dwóch konkretnych ograniczeń.
Brak natywnego wymiaru czasu w większości repozytoriów metadanych. Kod w GIT można odtworzyć po commitach. Ale słowniki, mapowania, metryczki Data Governance i konfiguracje uprawnień w wielu organizacjach nie mają wbudowanego wersjonowania. Słownik to dla typowej organizacji tabela w bazie, która jest po prostu nadpisywana. Agent AI nie odtworzy tego, czego nikt wcześniej nie zapisał. Żadna ilość mocy obliczeniowej tego nie zmieni.
Halucynacje na nieuporządkowanym kontekście. Jeśli agent łączy fragmenty informacji z kilku źródeł o niespójnych stanach czasowych – wczorajszy słownik, sprzed roku kod, sprzed pół roku opis pola – ryzyko wygenerowania prawdopodobnie brzmiącej, lecz niepoprawnej odpowiedzi rośnie wprost proporcjonalnie do złożoności analizy. W komunikacji z regulatorem to ryzyko nieakceptowalne. Odpowiedź „pewna, ale błędna” jest gorsza niż brak odpowiedzi. Brak odpowiedzi można nadrobić. Błędną odpowiedź – nigdy.
W krajobrazie regulacyjnym, w jakim instytucje finansowe funkcjonują w 2026 roku – DORA stosowana w pełni od stycznia 2025, AI Act wchodzący w pełni 2 sierpnia 2026, RODO niezależnie od obu powyższych – to rozróżnienie przestaje być tylko teorią. Każdy z tych reżimów daje regulatorowi narzędzia, których nie używa się symbolicznie.
O jednym łatwo zapomnieć. AI jest tak dobre, jak kontekst, który mu dostarczymy. Powierzenie zadania audytowego agentowi AI bez bazy metadanych jest jak wysłanie genialnego adwokata na salę sądową bez akt sprawy. Będzie mówił płynnie i z ogromną pewnością siebie, tyle że zmyśli linię obrony.
Witamy w Arkadii: jak wygląda organizacja z uporządkowanymi metadanymi?
Wyobraźmy sobie świat, w którym istnieje jedno główne narzędzie do zarządzania wiedzą o danych w organizacji. Może być odpytywane klasycznymi promptami albo językiem naturalnym wspieranym przez modele LLM.
Zadajemy pierwsze pytanie:
Gdzie znajdziemy definicję klienta PEP i skąd pochodzą dane wyznaczające takiego klienta?
Narzędzie odpowiada od razu. Klient PEP to klient instytucji zajmujący eksponowane stanowisko polityczne. Oznaczenie takich klientów znajdziemy w trzech miejscach: w hurtowni danych – tabela KLIENCI, pole KLIENT_VIP, wartość PEP; w data marcie DM_VIPS – tabela CUSTOMER, pole C114F; w systemie źródłowym – tabela CLIENTS, pole CLIPEP.
Zadajemy drugie pytanie:
Znajdź procesy i raporty uruchomione w dniu incydentu, które wyciągały dane osobowe i wrażliwe z użyciem powyższych pól jako filtrów selekcji.
I teraz cała różnica między scenariuszem „Houston” a Arkadią staje się widoczna. To nie jest różnica w narzędziu. To jest różnica w tym, czy ktoś w organizacji potraktował metadane jak aktywo – czy jak odpad.
Czy Arkadia leży daleko od nas? Data catalog z interfejsem LLM w analizie data lineage i obsłudze audytu.
Arkadia jest bliżej niż się wydaje. Druga część zadania – wyszukanie procesów uruchomionych w dniu incydentu – jest stosunkowo prosta, jeżeli wiemy, czego szukać. Można wykorzystać agentów AI do przeszukania skryptów wykonywanych w tym dniu i sprawdzenia, czy występują w nich pola KLIENT_VIP, C114F, CLIPEP oraz pola zawierające dane osobowe i wrażliwe. To zadanie, które AI w 2026 roku wykonuje dobrze.
Klucz tkwi w pierwszym pytaniu – gdzie znajdziemy definicję klienta PEP i skąd pochodzą dane wyznaczające takiego klienta? Żeby na nie odpowiedzieć – żeby AI w ogóle wiedziało, czego szukać – wystarczy wdrożyć w organizacji dobre narzędzie klasy data catalog. Takie, które komunikuje się z użytkownikiem w języku naturalnym przez LLM, ma funkcję przeglądania statystyk pól, ról dostępu, metryczek Data Governance, słowników i danych referencyjnych, analiz data lineage oraz repozytorium definicji biznesowych.
Zamiast pięciu narzędzi i ośmiu osób ze scenariusza „Houston” – jeden data catalog, w którym znajdujemy pole zawierające poszukiwane treści wraz z całym kontekstem: co to pole oznacza, z jakimi polami źródłowymi i wtórnie przetworzonymi jest powiązane, kto je tworzy, kto z niego korzysta.
Takie definicje wystawione jako baza wiedzy dla agentów AI lub jako baza RAG dla rozwiązań generatywnych radykalnie skracają czas analiz data lineage. Są też nieocenionym źródłem informacji dla analityków, programistów i deweloperów BI – niezależnie od tego, czy w danym momencie obsługują pytanie regulatora, czy budują nowy produkt bankowy.
Ale data catalog ma jedno ograniczenie. Wystawia użytkownikom to, co dostanie z warstwy niższej. Sam nie zbiera, nie historyzuje i nie zarządza metadanymi. Robi to inna warstwa. I to ta warstwa decyduje, czy data catalog ma czym świecić, czy świeci na pusto.
Czy metadane są potrzebne AI? Triada Metastudio + Data Catalog + AI jako architektura referencyjna dla organizacji regulowanej.
Uporządkowane metadane są nie tylko potrzebne. Są jedynym powodem, dla którego AI w środowisku regulowanym ma w ogóle sens.
Muszą być historyzowane, dobrze opisane i aktualne. Dotyczy to wszystkich kategorii metadanych: logów, ról dostępu, metryczek Data Governance, kodów, słowników, danych referencyjnych, mapowań i definicji biznesowych.
W znacznej części do zarządzania takimi metadanymi można wykorzystać Metastudio DRM – aplikację działającą w dużych bankach od ponad dwudziestu lat, której rolą jest centralne zarządzanie słownikami, danymi referencyjnymi i regułami biznesowymi z pełną historyzacją zmian.
W połączeniu z data catalogiem i warstwą AI tworzy ona triadę – architekturę referencyjną dla organizacji regulowanej, w której każda warstwa ma jasno wydzieloną rolę:
- Metastudio DRM – warstwa zbierania, historyzacji i zarządzania metadanymi. Zbiera słowniki, dane referencyjne i reguły biznesowe z pełną kontrolą wersji oraz uprawnień do edycji. To warstwa, w której biznes (a nie tylko IT) może wprowadzać zmiany w słownikach i regułach, z zachowaniem audytu i workflow akceptacji.
- Data Catalog – warstwa publikacji i osadzenia danych w kontekście. Pokazuje nie tylko samo pole, ale też wszystko, co je otacza: definicję biznesową, powiązane pola, statystyki, role z dostępem i informacje o tym, kto i jak z niego korzysta. Wystawia wyszukiwarkę danych, porządkuje informacje przypisane do danych i udostępnia je użytkownikom. Pokazuje, co organizacja ma i jak to się ze sobą łączy.
- AI – warstwa inteligentnego odpytywania. Wspiera procesy wyszukiwania, sięgając do uporządkowanego, sklasyfikowanego repozytorium metadanych w data catalogu. Przekształca pytanie w języku naturalnym w odpowiedź opartą o faktyczny stan metadanych w organizacji.
To jest triada Metastudio + Data Catalog + AI. Każda z tych warstw odpowiada za co innego. Każda jest niezbędna. Próba zastąpienia którejkolwiek z nich samym AI prowadzi wprost do odpowiedzi pewnej, ale błędnej – najgorszego scenariusza w środowisku compliance.
Podsumowanie, czyli trzy wnioski o zarządzaniu metadanymi i historyzacji dla zarządów i komitetów Data Governance.
Pytanie o sens zarządzania metadanymi w dobie AI jest źle postawione. Powinno brzmieć: jak zarządzać metadanymi, aby AI w ogóle mogło dostarczyć wartość – szczególnie tam, gdzie odpowiedź będzie weryfikowana przez KNF, audyt RODO, regulacje DORA czy AI Act?
Trzy wnioski do dyskusji w zarządach i komitetach Data Governance.
Po pierwsze: AI nie zastępuje warstwy metadanych – opiera się na niej. To nie jest stwierdzenie ideologiczne. To stwierdzenie architektoniczne. Każda obietnica, że LLM „sam się tego dowie”, załamuje się w pierwszym kontakcie z audytem regulacyjnym.
Po drugie: historyzacja metadanych przestaje być nice-to-have. Jest kosztem prowadzenia działalności regulowanej. Każda godzina poświęcona na rekonstrukcję stanu danych referencyjnych, słowników i lineage’u na konkretną datę to godzina nieprodukowania odpowiedzi dla regulatora – i ekspozycja organizacji na sankcje liczone w procentach rocznego obrotu, nie w licencjach.
Po trzecie: architektura referencyjna to triada Metastudio + Data Catalog + AI. Każda warstwa pełni inną rolę – zbieranie i wersjonowanie metadanych, ich publikacja i osadzenie w kontekście, wreszcie inteligentne odpytywanie. Próba zastąpienia którejkolwiek z nich samym AI prowadzi wprost do efektu „pewnej, ale błędnej” odpowiedzi – najgorszego z możliwych w środowisku compliance.
Regulator nie pyta “czy macie dane”, lecz “jak nimi zarządzaliście 13 maja o czternastej siedemnaście”. W tym świecie uporządkowane i historyzowane metadane są aktywem. Ich ROI mierzy się w kosztach uniknięcia kar i czasie reakcji – a nie w licencjach na narzędzie. To różnica między aktywem a kosztem. I to różnica, którą każdy CFO rozumie natychmiast.”
Słowniczek pojęć: metadane, data lineage, historyzacja i kluczowe terminy data governance
Poniżej skrótowe definicje pojęć z obszaru zarządzania metadanymi, data governance i compliance regulacyjnego, używanych w artykule.
BICC (Business Intelligence Competency Center)
Wewnętrzna jednostka organizacyjna odpowiedzialna za rozwój i utrzymanie raportowania zarządczego oraz standardów pracy z danymi w firmie.
Wikipedia (tylko EN): https://en.wikipedia.org/wiki/Business_intelligence_competency_center
Compliance
Funkcja w organizacji odpowiedzialna za zgodność działania z przepisami prawa, regulacjami nadzorczymi i wewnętrznymi politykami. W bankach to obszar raportujący zwykle bezpośrednio do zarządu.
Wikipedia: https://pl.wikipedia.org/wiki/Compliance
Commit
Zatwierdzona, opisana zmiana w kodzie zapisana w repozytorium GIT. Każdy commit zawiera autora, datę i opis zmiany, dzięki czemu można odtworzyć stan kodu z dowolnego dnia w przeszłości.
Wikipedia: https://pl.wikipedia.org/wiki/Commit
DORA (Digital Operational Resilience Act)
Rozporządzenie UE o cyfrowej odporności operacyjnej sektora finansowego, stosowane w pełni od 17 stycznia 2025. Wymaga od instytucji finansowych udokumentowanej kontroli nad systemami ICT i dostawcami technologii.
Tekst rozporządzenia w EUR-Lex: https://eur-lex.europa.eu/legal-content/PL/TXT/?uri=CELEX:32022R2554.
Strona DORA na KNF: https://www.knf.gov.pl/dla_rynku/dora
DRM (Data Reference Management)
Kategoria oprogramowania do centralnego zarządzania słownikami, danymi referencyjnymi i regułami biznesowymi w organizacji, z kontrolą wersji i uprawnień. Do tej kategorii należy Metastudio DRM.
GIT (repozytorium GIT)
System kontroli wersji kodu, w którym każda zmiana jest zapisywana jako commit z autorem i datą. Standard branżowy w zespołach deweloperskich.
Wikipedia: https://pl.wikipedia.org/wiki/Git
Master Data Management (MDM)
Dyscyplina i klasa narzędzi zajmująca się utrzymywaniem jednej, spójnej wersji kluczowych danych organizacji (klienci, produkty, dostawcy), niezależnie od liczby systemów, w których te dane występują.
Wikipedia (tylko EN): https://en.wikipedia.org/wiki/Master_data_management
RODO (GDPR)
Rozporządzenie o Ochronie Danych Osobowych, obowiązujące w UE od 2018. Reguluje przetwarzanie danych osobowych, w tym wymóg wykazania, kto, kiedy i na jakiej podstawie miał do nich dostęp.
Tekst rozporządzenia w EUR-Lex (PL): https://eur-lex.europa.eu/legal-content/PL/TXT/?uri=CELEX:32016R0679
Data catalog
Data catalog to centralna wyszukiwarka wiedzy o danych w organizacji, pokazująca dla każdego pola: co oznacza, skąd pochodzi, kto z niego korzysta i jakie ma ograniczenia dostępu.
Wikipedia (EN): https://en.wikipedia.org/wiki/Database_catalog
Data lineage
Data lineage to udokumentowany rodowód danych: zapis tego, z jakiego systemu źródłowego pochodzi dana wartość, przez jakie przekształcenia, mapowania i reguły biznesowe przeszła, zanim trafiła do hurtowni, data martu czy raportu. W środowisku regulowanym pozwala na pytanie audytora „skąd wzięła się ta liczba” odpowiedzieć z pełnym łańcuchem przekształceń, a nie z pamięci autora algorytmu.
Wikipedia (EN): https://en.wikipedia.org/wiki/Data_lineage
Osadzenie w kontekście (kontekstualizacja)
Osadzenie danych w kontekście to pokazanie pola lub zbioru danych nie w izolacji, lecz wraz z całym otoczeniem: definicją biznesową, powiązanymi polami, statystykami, rolami z dostępem, źródłem pochodzenia i informacją, kto i jak z danych korzysta. To podstawowa rola data catalog jako warstwy publikacyjnej.
AI Act
Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2024/1689 z 13 czerwca 2024, pierwsze na świecie kompleksowe ramy prawne dla sztucznej inteligencji. Większość przepisów obowiązuje od 2 sierpnia 2026; zakazy praktyk AI od 2 lutego 2025; obowiązki dla modeli ogólnego przeznaczenia od 2 sierpnia 2025. Wymaga m.in. audytowalności danych zasilających systemy wysokiego ryzyka.
Tekst rozporządzenia w EUR-Lex (PL): https://eur-lex.europa.eu/legal-content/PL/TXT/?uri=CELEX:32024R1689
Workflow akceptacji
Zdefiniowana w narzędziu ścieżka zatwierdzania zmiany przez wyznaczone osoby (np. autor → recenzent → opiekun danych) z zapisem decyzji i komentarzy. Standard dla zmian w słownikach i regułach biznesowych w środowisku regulowanym.
Najczęstsze pytania o metadane, AI, compliance, DORA i AI Act.
Czym różni się Metastudio DRM od klasycznego data catalog?
Data catalog publikuje i kontekstualizuje metadane dla użytkownika końcowego. Metastudio DRM zbiera te metadane u źródła, historyzuje je i zarządza uprawnieniami do ich edycji. Data catalog odpowiada na pytanie „co mamy i jak to działa”. Metastudio DRM odpowiada na pytanie „jak to wyglądało wczoraj, w zeszłym roku, i kto to zmienił”.
Dlaczego historyzacja metadanych jest istotna dla audytu regulacyjnego?
Bo regulator pyta o stan przeszły, nie o stan obecny. Bez historyzacji metadanych odpowiedź na pytanie „jak ten słownik wyglądał w dniu incydentu” wymaga rekonstrukcji ręcznej – wielodniowej i obarczonej ryzykiem błędu.
Czy LLM może zastąpić repozytorium słowników w banku?
Nie. LLM nie ma pamięci stanu metadanych organizacji w czasie. Może odpowiadać o stanie aktualnym (jeśli dostarczymy mu kontekst przez RAG), ale nie odtworzy stanu z przeszłości, jeśli ten stan nie został wcześniej zapisany w wersjonowanym repozytorium.
Jak DORA i AI Act wpływają na wymogi wobec metadanych?
Obie regulacje wymagają od instytucji finansowych udokumentowanej i podlegającej audytowi kontroli nad danymi i systemami ICT. DORA jest stosowana w pełni od 17 stycznia 2025, AI Act dla systemów wysokiego ryzyka – od 2 sierpnia 2026. W obu przypadkach możliwość odtworzenia stanu metadanych na konkretną datę staje się elementem zarządzania ryzykiem regulacyjnym.
Co to jest triada Metastudio + Data Catalog + AI?
Architektura referencyjna dla organizacji, która chce wykorzystać AI w środowisku regulowanym. Metastudio DRM odpowiada za zbieranie i historyzację metadanych. Data Catalog – za ich publikację i kontekstualizację. AI – za inteligentne odpytywanie tej uporządkowanej bazy. Każda warstwa ma inną rolę i nie zastępuje pozostałych.
Jaki jest pierwszy błąd organizacji wdrażających AI do obszaru danych?
Rozpoczynanie od modelu zamiast od metadanych. Bez uporządkowanych słowników, danych referencyjnych i lineage’u AI dostarczy odpowiedzi, których nie da się zweryfikować – a w środowisku regulowanym odpowiedź niezweryfikowana jest gorsza niż brak odpowiedzi.
Kiedy DORA zaczęła obowiązywać w UE?
17 stycznia 2025 r. – od tej daty przepisy rozporządzenia DORA obowiązują bezpośrednio w sektorze finansowym całej Unii Europejskiej.
Kiedy DORA została wdrożona do polskiego prawa?
31 lipca 2025 r. Prezydent RP podpisał tzw. ustawę horyzontalną, dopełniającą proces dostosowawczy. Ustawa weszła w życie 7 sierpnia 2025 r.
W jakim czasie należy zgłosić poważny incydent ICT?
Obowiązują trzy terminy raportowania:
- 4 godziny od sklasyfikowania incydentu (nie później niż 24 godziny od jego wykrycia) na wstępne powiadomienie,
- 72 godziny od powiadomienia wstępnego na sprawozdanie śródokresowe,
- 30 dni od raportu śródokresowego na sprawozdanie końcowe podsumowujące incydent i wyciągnięte wnioski.
Jak często trzeba przeprowadzać testy odporności?
Podstawowe testy, takie jak skanowanie podatności czy testy planów ciągłości działania należy przeprowadzać raz w roku. Zaawansowane testy penetracyjne oparte na wywiadzie o zagrożeniach (TLPT) są wymagane co najmniej raz na 3 lata i obejmują instytucje o istotnym znaczeniu systemowym.
Do kiedy trwa okres tolerancji nadzorczej?
Rok 2026 uznawany jest za koniec okresu tolerancji. Od tego momentu UKNF zaczyna kłaść szczególny nacisk na egzekwowanie pełnej cyfrowej odporności operacyjnej.
Jaki jest termin dla banków objętych Rekomendacją WFD?
31 grudnia 2026 r. to graniczna data utrzymania minimalnego poziomu wskaźnika finansowania długoterminowego dla banków podlegających Rekomendacji WFD.
Ile trwa wdrożenie ram zarządzania ryzykiem ICT?
Standardowo od 6 do 12 miesięcy. Tyle zajmuje sama właściwa faza implementacji ram zarządzania ryzykiem ICT w organizacji.
Praca zbiorowa Sanmargar pod redakcją Rafała Jastrzębskiego.
Rafał Jastrzębski | CEO w Sanmargar Team Sp. z o.o. – ekspert w obszarze zarządzania danymi i metadanymi w instytucjach finansowych. Związany z Sanmargar Team, polskim dostawcą Metastudio DRM – platformy do centralnego zarządzania słownikami, danymi referencyjnymi i regułami biznesowymi, działającej w dużych bankach od ponad dwudziestu lat.
