Jakość danych — poradnik dla managerów

W 2008 roku obroniłem swoją pracę magisterską zatytułowaną „Ensuring high Data Quality in Data Warehousing” („Zapewnianie wysokiej jakości danych w hurtowniach danych”). Pracowałem już wtedy drugi rok jako programista BI i szukałem ciekawego, „gorącego” tematu. Już wtedy zauważano, że dobry system wspierający decyzje w firmie musi opierać się na poprawnych, dobrze opisanych i skatalogowanych danych, a procesy ładowania danych (ETL) muszą mieć wbudowane mechanizmy zapobiegające ładowaniu złych danych, mogących zaciemnić obraz tego, co się dzieje w firmie.

Okazuje się, że temat jakości danych wraca jak bumerang i w 2026 roku dalej jest na topie. Dzisiaj widzę ten powrót również w kontekście AI. Moi agenci przeczesujący „niusy” branżowe co chwilę wracają do mnie z tematami związanymi z jakością danych. Przykładowo, w BARC „Data, BI & Analytics Trend Monitor 2026” zarządzanie jakością danych wróciło na pierwszą pozycję rankingu 20 trendów data, BI i analytics. Uzyskało 7,9/10 — tyle samo co bezpieczeństwo i prywatność danych.

Hasło „jakość danych” często wraca i wiele osób intuicyjnie rozumie, o co chodzi. Postanowiłem tę wiedzę usystematyzować i zebrać w pigułce 20 lat doświadczeń. Powstał poradnik dla osób, które muszą się zmierzyć z tym tematem, choć nie zajmują się techniczną stroną danych.

1. Czym właściwie jest jakość danych?

Najprościej oceniać jakość przez pytanie: czy dane nadają się do celu, w którym zamierzamy ich użyć? Takie podejście, określane po angielsku jako fitness for purpose, przyjmuje również brytyjski Government Data Quality Framework. Ten sam zbiór może być wystarczający w jednym procesie i zbyt słaby w innym.

Adres klienta bez numeru lokalu pozwoli przypisać sprzedaż do miasta. Przy dostawie przesyłki ten sam brak może uniemożliwić doręczenie. Jakość nie jest więc trwałą etykietą przyklejoną do tabeli. Wynika z relacji między danymi, sposobem użycia i skutkiem ewentualnego błędu.

Firma nie potrzebuje jednakowo doskonałych danych w każdym zakątku systemów. Taki cel pochłonąłby dużo czasu, a jego biznesowa wartość byłaby wątpliwa. Pierwszeństwo powinny mieć informacje wykorzystywane w ważnych decyzjach, raportach i procesach. Dla nich warto ustalić wymagany poziom jakości, osobę odpowiedzialną oraz sposób stałego sprawdzania.

2. Po czym manager może rozpoznać problemy z jakością danych?

Problemy mogą dać o sobie znać także poza formalnym raportem jakości. Widać je podczas spotkań, zamykania miesiąca, obsługi klientów i codziennej pracy z arkuszami. Sygnałem ostrzegawczym są między innymi:

• różne wartości tego samego wskaźnika w dwóch raportach;
• spotkania zaczynające się od ustalenia, która liczba jest prawidłowa;
• ręczne poprawki w Excelu przed każdym użyciem danych;
• regularne uzgadnianie raportów z księgowością;
• puste pola, kody zastępcze i wpisy w rodzaju „brak”;
• kilka nazw tego samego klienta, produktu lub dostawcy;
• informacje docierające już po podjęciu decyzji;
• brak możliwości ustalenia, skąd wzięła się liczba;
• nagła zmiana wyników po migracji systemu albo zmianie procesu;
• odpowiedzi AI oparte na nieaktualnych lub sprzecznych materiałach.

Każdy z tych objawów może mieć również niewinne wyjaśnienie. Uzgodnienie finansowe bywa prawidłową kontrolą, a różnica między raportami może wynikać z innego okresu. Powtarzalność jest ważną wskazówką. Jeżeli zespół co miesiąc wykonuje tę samą ręczną poprawkę, obejście stało się częścią procesu.

Sygnał dla managera: regularne ręczne uzgadnianie raportów może łagodzić skutki błędu, ale nie usuwa przyczyny problemu. Warto policzyć czas poświęcany na takie poprawki i prześledzić drogę danych do źródła.

3. Najważniejsze wymiary jakości danych

Ogólne zdanie „mamy słabe dane” trudno zamienić w działanie. Pomaga rozłożenie jakości na kilka właściwości. Brytyjskie ramy opisują sześć podstawowych wymiarów, a w praktyce managerskiej warto uzupełnić je o jasność znaczenia oraz możliwość prześledzenia pochodzenia.

1. Poprawność mówi, czy wartość odpowiada rzeczywistości. Cena może mieć właściwy format, a mimo to zawierać dodatkowe zero. NIP może przejść kontrolę liczby znaków, choć został przypisany do innej firmy. Sprawdzenie poprawności wymaga wiarygodnego punktu odniesienia.
2. Kompletność określa, czy są wszystkie wymagane informacje. Brak regionu klienta może uniemożliwić przydzielenie go do handlowca, a brak daty realizacji — ocenę terminowości. Wymagane pola powinny wynikać z procesu, ponieważ nie każda luka ma taką samą wagę.
3. Spójność oznacza brak sprzeczności. Jeżeli ten sam klient jest aktywny w CRM, a zamknięty w ERP, trzeba ustalić, który system ma prawo rozstrzygać o statusie i w jakim momencie następuje synchronizacja.
4. Aktualność odpowiada na pytanie, czy dane są dostępne wtedy, gdy są potrzebne. Nocne odświeżanie zapasów może wystarczyć do tygodniowego planowania zakupów, ale będzie zbyt wolne dla sprzedaży podejmującej decyzje co kilka minut.
5. Unikalność wymaga pojedynczej reprezentacji obiektu biznesowego. Klient utworzony osobno przez kilka oddziałów może mieć rozdzieloną historię zakupów, różne limity kredytowe i kilka opiekunów. Ocena duplikatów wymaga uzgodnienia klucza identyfikującego klienta.
6. Zgodność z regułami sprawdza format, zakres i zależności między wartościami. Data zakończenia nie powinna poprzedzać daty rozpoczęcia, a liczba sprzedanych sztuk nie powinna być ujemna. Przejście takiej kontroli potwierdza spełnienie reguły, ale jeszcze nie zgodność z rzeczywistością.
7. Jednoznaczność i zrozumiałość dotyczą wspólnego znaczenia. „Sprzedaż” może oznaczać wartość zamówień, wystawionych faktur albo zaksięgowanego przychodu. Nazwa wskaźnika bez definicji, formuły, okresu i źródła pozostawia miejsce na kilka poprawnych interpretacji.
8. Identyfikowalność pochodzenia pozwala ustalić, skąd przyszły dane, jak zostały zmienione i gdzie trafiły. Tę drogę nazywa się data lineage. Proste objaśnienie IBM obejmuje źródła, przepływ i przekształcenia danych. Dla managera ważna jest możliwość odpowiedzi na pytanie, dlaczego liczba w raporcie wygląda właśnie tak.

Ostatnie dwie właściwości nie należą do sześcioelementowej listy używanej w przywołanych brytyjskich ramach. Uzupełniają ją, bo bez wspólnego znaczenia i znajomości drogi danych trudno wyjaśnić rozbieżność, znaleźć jej przyczynę i ocenić wpływ zmiany.

4. Jak zła jakość danych wpływa na firmę?

Skutki zależą od tego, gdzie dane są używane. Zamiast szukać jednej uniwersalnej kwoty straty, lepiej obserwować mechanizm w poszczególnych obszarach.

Finanse. Błędne przypisanie kosztu zmienia obraz rentowności, a opóźnione dane utrudniają prognozę przepływów. Różne definicje wskaźnika wydłużają uzgodnienia. Kosztem jest zarówno ryzyko błędnego wyniku, jak i czas ludzi poświęcony na jego sprawdzanie.

Sprzedaż. Duplikaty klientów rozdzielają historię kontaktu i zakupów. Brakujące cechy osłabiają segmentację, a niepoprawne przypisanie handlowca zmienia obraz jego wyniku. Obraz procesu sprzedaży wygląda wiarygodnie dopiero wtedy, gdy definicje etapów są wspólne i stosowane w podobny sposób.

Produkcja i logistyka. Nieaktualny stan magazynowy może doprowadzić do obietnicy terminu, którego firma nie dotrzyma. Błędna data albo kod produktu utrudnia ocenę terminowości, dostępności i rentowności zlecenia.

Zarządzanie. Gdy raporty regularnie sobie przeczą, ludzie przestają im ufać. Powstają prywatne arkusze, lokalne definicje i ręczne wersje „właściwego” wyniku. Decyzje mogą wtedy opierać się na doświadczeniu, nawet tam, gdzie firma inwestowała w raportowanie.

AI i automatyzacja. System korzystający z niepełnej lub nieaktualnej bazy wiedzy może podać odpowiedź opartą na niewłaściwym materiale. Jeżeli wynik uruchamia dalsze działania bez przeglądu człowieka, ten sam błąd może zostać powtórzony wiele razy. Skala zależy od architektury, uprawnień i zakresu automatyzacji.

5. Skąd biorą się problemy z jakością danych?

Miejsce, w którym zauważamy błąd, może różnić się od jego źródła. Nieprawidłowa marża jest widoczna na pulpicie zarządczym, choć przyczyna może tkwić w kategorii produktu w ERP, mapowaniu integracji albo definicji kosztu przyjętej kilka lat wcześniej.

Typowe źródła problemów to ręczne wprowadzanie, brak walidacji, niespójne definicje, kilka systemów przechowujących tę samą informację, brak wspólnych identyfikatorów, migracje, pliki i ręczne eksporty, błędy przekształceń oraz zmiany procesu bez aktualizacji raportowania. Osobną grupę tworzą braki organizacyjne: niewskazany właściciel, nieutrzymywane słowniki i poprawianie wyniku na końcu przepływu.

Dlatego zespół powinien prześledzić pełną drogę danych. Warto ustalić, gdzie wartość powstaje, kto może ją zmienić, przez jakie systemy przechodzi i jakie reguły działają po drodze. Raport pokazuje objaw. Diagnoza wymaga cofnięcia się do pierwszego miejsca, w którym wartość stała się błędna albo straciła właściwe znaczenie.

6. Kto odpowiada za jakość danych?

Jakość danych wymaga współpracy biznesu i technologii. Zespół IT potrafi wdrożyć walidację, monitorowanie i bezpieczny przepływ, lecz biznes określa znaczenie pola, sposób użycia oraz akceptowalne ryzyko. Aktualny model odpowiedzialności za dane opisany przez GOV.UK rozdziela role strategiczne, procesowe, opiekuńcze i techniczne.

• Właściciel danych odpowiada za znaczenie, wymagania i akceptowalny poziom jakości w danym obszarze. Podejmuje decyzje, zatwierdza definicje i zapewnia zasoby do naprawy ważnych problemów.
• Właściciel procesu odpowiada za sposób, w jaki dane powstają lub są aktualizowane. Kontroluje zachowania, instrukcje i punkty procesu wpływające na jakość.
• Data Steward prowadzi codzienną opiekę nad definicjami, regułami, dokumentacją i zgłoszeniami. Łączy wiedzę dziedzinową z pracą zespołu technicznego. W polskiej organizacji stanowisko może mieć inną nazwę, a w mniejszej firmie jego zadania może wykonywać ekspert biznesowy.
• IT lub zespół danych przekłada wymagania na walidacje, integracje, testy, monitoring i mechanizmy naprawcze. Dba również o ślad zmian, dostęp i niezawodność przetwarzania.
• Użytkownicy zgłaszają błędy i opisują wpływ na pracę. Stałe poprawianie danych poza systemem nie powinno jednak stawać się ich ukrytym obowiązkiem.

Przykładowy podział można zapisać w prostej macierzy:

Nazwy osób zależą od organizacji. Ważniejsze jest jawne prawo do podjęcia decyzji: kto zatwierdza definicję, kto zmienia proces, kto wdraża regułę i kto reaguje na przekroczenie progu.

7. Nie wszystkie dane są równie ważne

Próba uporządkowania wszystkich tabel i pól jednocześnie szybko rozprasza uwagę. Priorytet powinny otrzymać dane wpływające na decyzje zarządcze, wynik finansowy, raportowanie wymagane w danej branży, automatyzację, informacje przekazywane klientom oraz modele i agentów AI. Wysoką wagę mają też dane obecne w wielu systemach, bo rozbieżność może dotknąć kilku procesów naraz.

Pomaga pojęcie Critical Data Elements, czyli krytycznych elementów danych. Są to pola albo logiczne grupy pól szczególnie ważne dla wskazanego zastosowania. Przykładami mogą być identyfikator klienta, NIP, kod produktu, cena i koszt produktu, status zamówienia, data dostawy oraz saldo należności. Sama nazwa nie czyni pola krytycznym. O wadze decyduje wpływ błędu.

Dobry test brzmi: co stanie się w firmie, jeśli ta wartość będzie niepoprawna, niepełna lub spóźniona przez dzień? Odpowiedź pozwala ustalić kolejność pracy. Pole o umiarkowanej jakości, które nie wpływa na ważną decyzję, może poczekać. Mała liczba błędów w danych sterujących płatnością albo wysyłką może wymagać natychmiastowej reakcji.

8. Jak zmierzyć jakość danych?

Pomiar zaczyna się od reguły, zakresu i progu. Zdanie „adresy mają być kompletne” pozostawia wiele wątpliwości. Reguła „co najmniej 98% aktywnych klientów składających zamówienia w danym miesiącu ma kod pocztowy zgodny z wymaganym formatem” wskazuje populację, okres, sprawdzaną cechę i oczekiwany wynik. Próg powinien odpowiadać ryzyku, a nie ambicji uzyskania idealnej bazy.

W praktyce można śledzić:

• odsetek rekordów z kompletem wymaganych pól;
• liczbę rekordów lub grup uznanych za duplikaty według ustalonego klucza;
• odsetek wartości zgodnych z formatem, zakresem lub słownikiem;
• zgodność tej samej wartości między systemami, przy wspólnym identyfikatorze i momencie porównania;
• czas od powstania danych do ich dostępności w raporcie;
• liczbę ręcznych korekt i zgłoszonych incydentów;
• czas rozwiązania problemu;
• wartość transakcji objętych błędem.

Ostatni miernik pokazuje nominalną wartość transakcji objętych błędem, a nie poniesioną stratę, koszt ani ekspozycję netto. Pięć faktur o łącznej wartości miliona złotych przypisanych do niewłaściwego klienta wymaga innej analizy niż sto brakujących numerów telefonu. Sama liczba błędnych rekordów nie ustala priorytetu.

Miernik powinien łączyć stan danych z konsekwencją biznesową. Do wyniku kompletności warto dodać czas pracy potrzebny na uzupełnienia. Do liczby rozbieżnych faktur — ich wartość, ryzyko księgowe i czas korekty. Trzeba też uważać z interpretacją liczby incydentów: jej wzrost może oznaczać pogorszenie danych albo skuteczniejsze wykrywanie i zgłaszanie.

Punktem odniesienia jest pomiar początkowy wykonany według zapisanej reguły. Kolejne wyniki muszą używać tego samego zakresu i sposobu liczenia. Dzięki temu firma widzi trend, potrafi ocenić zmianę procesu i odróżnia poprawę od przesunięcia definicji.

9. Gdzie powinny działać mechanizmy kontroli?

Skuteczna ochrona ma kilka warstw. Każda wychwytuje inny rodzaj problemu i robi to w innym momencie.

• Przy wprowadzaniu danych działają pola obowiązkowe, listy dozwolonych wartości, sprawdzanie formatu, podpowiedzi i wykrywanie możliwych duplikatów. Wczesna informacja pozwala użytkownikowi poprawić wpis, zanim trafi on dalej.
• W systemie źródłowym potrzebne są reguły biznesowe, słowniki, dane referencyjne, uprawnienia i rejestr zmian. System powinien chronić najważniejsze zależności, które da się jednoznacznie zapisać.
• W integracji i ładowaniu można kontrolować kompletność paczki, sumy kontrolne, zgodność identyfikatorów i reguły dla rekordów. Błędy powinny być rejestrowane, a wadliwe dane — odrzucone, oznaczone albo skierowane do kwarantanny zgodnie z ryzykiem.
• W hurtowni i raportowaniu przydają się testy spójności po przekształceniach, porównania ze źródłem, historia zmian, monitoring aktualności i wykrywanie nietypowych odchyleń.
• Po stronie użytkownika warto pokazywać datę ostatniego odświeżenia, wynik jakości, ostrzeżenie o znanym problemie i prosty kanał zgłoszenia.

Kontrola na końcu nadal jest potrzebna, bo wykrywa błędy transformacji i zestawienia. Zatrzymanie problemu blisko miejsca powstania może jednak ograniczyć jego dalsze skutki. Wtedy wadliwa wartość nie przechodzi przez kolejne raporty, eksporty i decyzje.

10. Co zrobić z błędnymi danymi?

Wykrycie błędu uruchamia decyzję o reakcji. Do wyboru są: blokada zapisu, odrzucenie rekordu, kwarantanna, dopuszczenie z ostrzeżeniem, automatyczna korekta, ręczna weryfikacja oraz świadoma akceptacja ryzyka. Każda odpowiedź ma koszt i powinna być dopasowana do skutku biznesowego.

Brak numeru telefonu może zakończyć się ostrzeżeniem, jeżeli klient wybrał kontakt e-mailowy. Nieprawidłowy numer rachunku zatwierdzonego odbiorcy może uzasadniać zatrzymanie płatności do czasu weryfikacji. Jednoznaczna reguła, ślad zmiany i możliwość jej odwrócenia ograniczają ryzyko automatycznej korekty, lecz o bezpieczeństwie decydują też konkretne zastosowanie i skutek. W innych sytuacjach automat może zamienić widoczny błąd w trudniejszą do wykrycia, pozornie poprawną wartość.

Świadoma akceptacja także bywa racjonalna. Naprawa starych, rzadko używanych danych może kosztować więcej niż korzyść z poprawy. Taka decyzja powinna mieć właściciela, uzasadnienie, określony zakres i termin ponownego przeglądu. W przeciwnym razie „akceptacja” staje się zapomnianym problemem.

11. Naprawianie danych czy naprawianie procesu?

Korekta rekordu przywraca użyteczność bieżących danych. Zmiana słownika, formularza, integracji albo sposobu pracy ogranicza powstawanie kolejnych błędów. Dojrzała reakcja obejmuje oba poziomy, jeśli wpływ uzasadnia koszt.

Wyobraźmy sobie, że controlling co miesiąc poprawia kategorie produktów w Excelu. Raport zostaje zamknięty, lecz następne zasilenie przynosi ten sam zestaw rozbieżności. Źródłem może być nieaktualny słownik, dowolne pole tekstowe przy zakładaniu produktu albo błędne mapowanie w integracji. Dopiero zmiana tego elementu zatrzyma nawrót.

Przydatny cykl ma sześć kroków:

1. wykrycie i zarejestrowanie problemu;
2. ocena wpływu biznesowego;
3. korekta obecnych danych, gdy jest potrzebna;
4. ustalenie pierwszego miejsca powstania błędu;
5. zmiana procesu lub systemu;
6. ponowny pomiar i sprawdzenie, czy problem wraca.

Warto osobno raportować liczbę naprawionych rekordów i liczbę usuniętych przyczyn. Pierwsza miara opisuje wysiłek porządkowy. Druga opisuje aktywność przy usuwaniu źródeł problemów, ale sama nie pokazuje ich wpływu ani unikniętego kosztu. Wynik trzeba oceniać razem z nawrotami, wpływem na biznes lub osobną metodą kosztową.

12. Od czego zacząć — praktyczny plan dla managera

Poniższe siedem kroków pokazuje, jak w ograniczonym zakresie przejść od narzekania na dane do uporządkowanego sposobu pracy, który ma wyraźny związek z decyzją albo wynikiem firmy.

1. Wybierz jeden ważny proces lub raport. Może to być prognoza przepływów, raport marży, obsługa zamówień albo baza wiedzy używana przez asystenta AI. Opisz decyzję, którą ten obszar wspiera, oraz odbiorców wyniku.
2. Wskaż kluczowe dane. Zamiast całego modelu wybierz kilka pól i definicji o największym wpływie. Przy raporcie marży mogą to być kod produktu, przychód, koszt, waluta i okres księgowania.
3. Zdefiniuj reguły jakości. Dla każdego elementu zapisz wymiar, populację, sposób liczenia, próg i częstotliwość kontroli. Ustal także źródło odniesienia, gdy sprawdzasz poprawność względem rzeczywistości.
4. Zmierz stan początkowy i wpływ na biznes. Policz błędy według zapisanej reguły, czas ręcznych poprawek, wartość dotkniętych transakcji i opóźnienia. Nie sumuj tych wielkości w jedną pozornie precyzyjną kwotę bez uzgodnionej metody.
5. Przypisz właścicieli. Wskaż osobę zatwierdzającą definicję i próg, właściciela procesu, osobę prowadzącą zgłoszenia oraz zespół wdrażający kontrolę. Zapisz również sposób eskalacji.
6. Usuń najbardziej kosztowne przyczyny. Wybierz problemy według wpływu, częstotliwości i kosztu reakcji. Popraw dane potrzebne teraz, a następnie zmień miejsce, w którym błąd powstaje.
7. Wprowadź stałe monitorowanie. Powtarzaj pomiar według tej samej reguły, ustaw ostrzeżenia dla progów i omawiaj nawracające problemy z właścicielami. Po ustabilizowaniu pierwszego obszaru można przenieść sposób pracy na następny.

Taki start pozwala zespołowi uzyskać mierzalne rezultaty: skrócić czas uzgodnień, ograniczyć liczbę ręcznych korekt, przyspieszyć dostęp do danych albo zmniejszyć wartość transakcji objętych błędem. Program można rozszerzać dopiero wtedy, gdy pierwszy zakres działa i ma właścicieli.

13. Pułapki w projektach jakości danych

Poniższa lista opisuje powtarzalne pułapki i ich mechanizmy, a nie ranking częstości w firmach.

• Objęcie wszystkich danych. Zakres rośnie szybciej niż zdolność do podejmowania decyzji, a zespół traci z oczu pola ważne dla biznesu.
• Start od zakupu narzędzia. Platforma może uruchamiać reguły i alerty, ale sama nie ustali znaczenia danych, progu ani właściciela.
• Przekazanie całości do IT. Technologia wdroży kontrolę, lecz nie rozstrzygnie samodzielnie, czy status klienta lub definicja marży są prawidłowe dla firmy.
• Brak mierzalnego celu biznesowego. Liczba testów rośnie, a organizacja nadal nie wie, czy skróciła czas uzgodnień albo zmniejszyła ryzyko.
• Poprawki wyłącznie w raporcie lub hurtowni. Wynik wygląda lepiej, ale wadliwe dane nadal zasilają inne zastosowania.
• Brak właściciela biznesowego. Spory o definicje i priorytety pozostają bez decyzji.
• Nieutrzymywane słowniki i reguły. Zmienia się oferta lub proces, a dawna kontrola zaczyna zgłaszać fałszywe alarmy albo przepuszczać nowe błędy.
• Oczekiwanie pełnej poprawności. Zespół poświęca środki na mało ważne pola, zamiast zarządzać ryzykiem według zastosowania.
• Brak obsługi wykrytych problemów. Alerty mnożą się bez wstępnej oceny i skierowania do dalszej obsługi, terminu i osoby odpowiedzialnej, więc użytkownicy przestają na nie reagować.
• Pomijanie systemów źródłowych. Firma stale czyści skutek, choć przyczyna pozostaje w formularzu, instrukcji lub integracji.

14. Czy potrzebne jest specjalistyczne narzędzie?

Na początku można rozważyć środki, które firma już ma: zapytania kontrolne, raport jakości, zapisaną listę reguł, rejestr problemów, właścicieli i alert po przekroczeniu progu, o ile odpowiadają celowi, skali i istniejącemu środowisku. Najważniejsza jest możliwość powtarzalnego wykonania tej samej kontroli oraz zachowania historii wyniku.

Specjalistyczne rozwiązanie zyskuje sens, gdy rośnie liczba źródeł i reguł, kontrole muszą działać stale, a problemy trzeba kierować do wielu właścicieli. Dodatkową wartość mogą wtedy dać profilowanie, katalog i słownik pojęć, śledzenie pochodzenia, zarządzanie danymi referencyjnymi, oceny jakości oraz automatyczne powiadomienia.

Technologie różnią się miejscem zastosowania:

• mechanizmy bazy, takie jak ograniczenia PostgreSQL, pilnują reguł blisko zapisu;
• testy danych w dbt sprawdzają modele po przekształceniach w środowisku analitycznym;
• Great Expectations pozwala zespołom pracującym w Pythonie, SQL i Spark budować zestawy walidacji oraz dokumentację wyników;
• AWS Glue Data Quality łączy reguły i wyniki, a w ścieżce ETL także identyfikację i kwarantannę błędnych rekordów w środowisku AWS;
• Microsoft Purview Data Quality dodaje profilowanie, cykliczne skany, oceny i alerty w ramach wspieranego katalogu.

To przykłady różnych warstw, a nie porównanie dostawców. Każde rozwiązanie ma własny zakres źródeł, limity, koszty i wymagania kompetencyjne. Firma powinna zacząć od celu, reguł i odpowiedzialności, a potem wybrać najmniejszy zestaw funkcji, który obsłuży wymaganą skalę. Narzędzie przyspiesza wykonanie uzgodnionego sposobu pracy; decyzje biznesowe nadal należą do właścicieli danych i procesów.

15. Jakość danych w czasach AI

Problem jakości danych istniał długo przed dzisiejszą falą generatywnej AI. Nowe zastosowania zwiększyły znaczenie aktualności, opisu, pochodzenia i kontroli dostępu, bo system może łączyć wiele źródeł, tworzyć odpowiedzi i — w niektórych architekturach — inicjować dalsze działania.

Przed automatyzacją warto ustalić, jakiej jakości danych wymaga konkretne zastosowanie. Baza wiedzy dla pracowników powinna mieć właściciela, daty obowiązywania dokumentów, kontrolę dostępu i zasady wycofywania starych wersji. Model oceniający zgłoszenia potrzebuje udokumentowanych źródeł, definicji etykiet, testów oraz monitorowania zmian danych. NIST AI RMF Playbook łączy zarządzanie AI między innymi z jakością, dokumentacją, pochodzeniem, rolami, monitoringiem i dostępem do danych.

Możliwość wskazania źródła w odpowiedzi AI ułatwia kontrolę, ale sama obecność linku nie dowodzi prawdziwości. Profil ryzyka generatywnej AI przygotowany przez NIST opisuje konfabulacje, w tym fałszywe lub błędne cytowania wyglądające na uzasadnienie. Użytkownik albo mechanizm weryfikujący powinien porównać twierdzenie z rzeczywistą treścią źródła.

Skala skutku zależy od sposobu wdrożenia. NIST bezpośrednio wskazuje możliwość zwiększania szybkości i skali szkodliwych uprzedzeń przez systemy AI. W przypadku innych błędów znaczenie mają zasięg, uprawnienia, automatyczne wykonanie i zabezpieczenia. Asystent tworzący propozycję dla człowieka niesie inne ryzyko niż agent samodzielnie wysyłający komunikaty albo zmieniający dane w systemie.

AI uwidacznia stare zaniedbania: niejasne definicje, nieaktualne dokumenty, brak właścicieli i nieznane pochodzenie. Jednocześnie wymusza szybszą odpowiedź na pytanie, czy dane są wystarczająco wiarygodne do danego użycia. Model nie poprawia automatycznie jakości materiału, który otrzymał. Potrzebuje tych samych podstaw co raport zarządczy: właściwego źródła, wspólnego znaczenia, aktualności i kontroli.

16. Checklista managera

Przed uruchomieniem większego programu warto odpowiedzieć na dziesięć pytań:

• Czy znamy dane krytyczne dla najważniejszych decyzji i procesów?
• Czy kluczowe wskaźniki mają jednoznaczne definicje, formuły i źródła?
• Czy każda ważna grupa danych ma właściciela biznesowego?
• Czy jakość jest regularnie mierzona według zapisanych reguł?
• Czy najważniejsze błędy są wykrywane automatycznie?
• Czy znamy źródła problemów, które wracają?
• Czy usuwamy przyczyny, a nie poprzestajemy na korekcie rekordów?
• Czy użytkownicy wiedzą, gdzie zgłosić błąd i co dzieje się ze zgłoszeniem?
• Czy dane używane przez AI mają dodatkową kontrolę aktualności, dostępu i pochodzenia?
• Czy potrafimy oszacować czas, ekspozycję i rzeczywisty koszt złej jakości, rozdzielając te miary?

Kilka odpowiedzi „nie” wystarczy, aby wyznaczyć pierwszy zakres. Najlepiej wybrać pytanie związane z ważnym raportem lub procesem i przypisać do niego osobę odpowiedzialną oraz termin pomiaru początkowego.

17. Podsumowanie

Od mojej pracy magisterskiej minęło osiemnaście lat, a podstawowy problem pozostał znajomy: decyzja jest tak wiarygodna, jak dane i definicje, na których się opiera. Zmieniły się narzędzia, liczba źródeł i tempo wykorzystania informacji. AI dołożyła nowe zastosowania oraz możliwość szybkiego powtarzania skutków błędu.

Odpowiedzialność za jakość łączy biznes i IT. Biznes ustala znaczenie, priorytet i akceptowalne ryzyko. Technologia wdraża reguły, monitoruje przepływ i pomaga reagować. Wspólnie trzeba mierzyć stan danych, usuwać przyczyny oraz sprawdzać, czy problem nie wraca.

Pierwszym krokiem może być jeden krytyczny raport, proces albo zestaw pól. Wybieramy najważniejsze dane, zapisujemy reguły, mierzymy stan początkowy, przypisujemy właścicieli i naprawiamy źródła najbardziej kosztownych błędów. Celem są dane wystarczająco wiarygodne do bezpiecznej decyzji, dostępne wtedy, gdy są potrzebne.

Jakość danych przypomina jakość produktu i procesu. Kontrola końcowego wyniku wykrywa część wad. Trwała poprawa pojawia się wtedy, gdy cały sposób pracy wychwytuje błędy możliwie wcześnie, pozwala znaleźć ich źródło i ogranicza ponowne powstawanie.

Źródła i materiały do dalszej lektury

• BARC, „Data, BI & Analytics Trend Monitor 2026”
• UK Government Data Quality Hub, „The Government Data Quality Framework”
• UK Government Data Quality Hub, „Implementing a data quality action plan”
• GOV.UK, „Data ownership model”
• NIST, „AI Risk Management Framework”
• NIST, „Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile”