Szybka odpowiedź

Data governance dla AI to zestaw zasad, ról i kontroli, które mówią, kto jest właścicielem danych, kto może ich używać, jak dba się o ich jakość i czego system AI nigdy nie powinien dostać. Opiera się na czterech filarach: jakości danych, kontroli dostępu, pochodzeniu (lineage) i odpowiedzialności. Wdraża się je etapami, zaczynając od jednego zastosowania AI, a nie od programu dla całej firmy.

Dlaczego AI potrzebuje data governance?

Bo AI nie naprawia złych danych, tylko się na nich uczy albo z nich odpowiada. Jeśli w źródłach są duplikaty, błędy, nieaktualne wersje dokumentów czy dane, które nigdy nie powinny opuścić działu kadr, model powtórzy to z dużą pewnością siebie.

Data governance (ład danych) to ramy decyzyjne nad danymi: polityki, właścicielstwo i rozliczalność. To nie jest projekt serwerowy ani wybór bazy danych. Przed tym, jak firma zaufa swojemu AI, musi zaufać swoim danym.

W klasycznej analityce pracuje się głównie na danych ustrukturyzowanych: sprzedaż, stany magazynowe, tabele w hurtowni. AI, zwłaszcza modele językowe i systemy RAG, sięga też po dane nieustrukturyzowane: maile, umowy, PDF-y, skany, notatki ze spotkań, zapisy czatów. Tam zwykle nie ma właściciela, wersjonowania ani klasyfikacji, a to właśnie stamtąd system będzie brał odpowiedzi.

Jakie ryzyka pojawiają się bez zasad?

Trzy najczęstsze:

  • Wyciek przez nieoczekiwany kanał. Dane, które trafiły do treningu, dostrajania albo bazy wiedzy, mogą wrócić w odpowiedzi do osoby, która nie powinna ich zobaczyć. OWASP w edycji 2026 swojej listy ryzyk dla aplikacji LLM zaleca m.in. klasyfikację i czyszczenie danych osobowych już przy ładowaniu oraz autoryzację przed wyszukiwaniem, a nie po nim (OWASP GenAI Security Project, 2026).
  • Utrwalenie historycznej stronniczości. Głośny przykład opisano w Science: algorytm używany w amerykańskiej opiece zdrowotnej przewidywał potrzeby zdrowotne na podstawie historycznych kosztów leczenia, przez co systematycznie zaniżał potrzeby czarnoskórych pacjentów (Obermeyer i in., Science, 2019). Dane były "poprawne", ale odzwierciedlały nierówny dostęp do opieki.
  • Brak odpowiedzi na pytanie "skąd to wiesz?". Gdy klient, audytor albo regulator zapyta, na jakich danych oparto decyzję, bez dokumentacji pochodzenia nie ma czego pokazać.

Jakie są cztery filary data governance dla AI?

To jakość danych, kontrola dostępu i bezpieczeństwo, pochodzenie danych oraz odpowiedzialność. Każdy filar ma swoje kontrole, które da się wdrożyć i sprawdzić.

FilarNa jakie pytanie odpowiadaKluczowe kontrolePrzykładowy dowód dla audytu
Jakość danychCzy dane są kompletne, poprawne i aktualne?Automatyczne testy kompletności i spójności, deduplikacja, harmonogram odświeżaniaRaport jakości zbioru z progami i datą ostatniego przeglądu
Dostęp i bezpieczeństwoKto może zobaczyć, zmienić lub użyć danych w AI?Klasyfikacja wrażliwości, dostęp oparty na rolach, szyfrowanie, maskowanie, logi dostępuMacierz uprawnień i logi odczytów
Pochodzenie (lineage)Skąd są dane i co się z nimi działo?Rejestr źródeł, zapis transformacji, powiązanie zbiorów z modelamiDiagram przepływu danych i wersje zbiorów
OdpowiedzialnośćKto decyduje i kto odpowiada za błąd?Właściciel i steward każdego zbioru, ścieżka eskalacji, przeglądyRejestr właścicieli i decyzji

Filar 1: jakość danych

Ten filar dba o to, żeby AI uczyło się i odpowiadało na podstawie wiarygodnych informacji. W praktyce oznacza to ustalenie progów jakości przed dopuszczeniem zbioru do użycia w AI, a nie ocenę "na oko" po wdrożeniu.

Kluczowe kontrole:

  • automatyczne testy kompletności, poprawności formatów i spójności między systemami,
  • systematyczne usuwanie duplikatów i poprawianie błędów (w dokumentach: usuwanie starych wersji tej samej procedury),
  • osoba odpowiedzialna za metryki jakości danego zbioru,
  • harmonogram odświeżania, żeby AI nie odpowiadało z cennika sprzed dwóch lat.

Jak przygotować same dane (czyszczenie, ekstrakcja z PDF-ów i skanów, podział na fragmenty), opisujemy szczegółowo w artykule jak przygotować dane pod AI.

Filar 2: kontrola dostępu i bezpieczeństwo

Ten filar określa, kto może używać których danych i jak są chronione. Najważniejsza zasada dla AI: system nie może dać użytkownikowi więcej, niż ten użytkownik mógłby zobaczyć bez AI.

Kluczowe kontrole:

  • klasyfikacja wrażliwości, na przykład: publiczne, wewnętrzne, poufne, ściśle poufne (dane osobowe szczególnych kategorii, tajemnica przedsiębiorstwa),
  • uprawnienia per zespół lub rola: podgląd, edycja, użycie w AI,
  • szyfrowanie, maskowanie lub pseudonimizacja danych wrażliwych,
  • logowanie dostępu, żeby dało się odtworzyć, kto i kiedy sięgnął po dane.

W systemach RAG ten filar przekłada się na wyszukiwanie świadome uprawnień: dokumenty i fragmenty filtruje się po prawach użytkownika już w zapytaniu do indeksu. Piszemy o tym w artykule o bezpiecznym RAG i uprawnieniach do danych.

Osobna decyzja to miejsce przetwarzania. Gdy dane nie mogą opuścić firmy, model i wyszukiwarkę uruchamia się na własnej infrastrukturze. Tak działa nasza agentowa baza wiedzy: lokalne modele na własnych GPU, bez wysyłania dokumentów do zewnętrznych API.

Filar 3: pochodzenie danych (lineage)

Lineage (pochodzenie danych) to udokumentowana ścieżka danych: z jakiego źródła pochodzą, jakie przeszły transformacje i do którego modelu lub indeksu trafiły. Bez tego nie da się ani wyjaśnić decyzji AI, ani szybko naprawić błędu u źródła.

Kluczowe kontrole:

  • rejestr źródeł danych z datą pobrania i wersją,
  • zapis operacji: OCR, ekstrakcja tabel, czyszczenie, podział na fragmenty, embeddingi,
  • powiązanie zbiorów z modelami i indeksami, które z nich korzystają,
  • analiza wpływu: co się zmieni w AI, jeśli zmieni się źródło.

W systemach z odpowiedziami z dokumentów lineage widać na zewnątrz: każda odpowiedź w naszej bazie wiedzy ma przypisy do konkretnych fragmentów źródeł, a warstwa obserwowalności zapisuje każdy krok przetwarzania (Bazy wiedzy). Użytkownik może sprawdzić źródło, a zespół techniczny odtworzyć, dlaczego system odpowiedział tak, a nie inaczej.

Filar 4: odpowiedzialność i właścicielstwo

Ten filar przypisuje konkretne osoby do danych na każdym etapie ich życia. Najczęstsza przyczyna utknięcia projektu AI na danych nie jest techniczna: trzy działy mają trzy wersje bazy klientów i nikt nie ma mandatu, żeby rozstrzygnąć, która jest prawdziwa.

NIST AI Risk Management Framework ujmuje to w funkcji GOVERN: role, odpowiedzialności i linie komunikacji związane z zarządzaniem ryzykiem AI mają być udokumentowane i jasne dla ludzi oraz zespołów w całej organizacji (NIST AI 100-1).

RolaZa co odpowiadaTypowy błąd
Właściciel danych (biznes)Cel użycia, kto ma dostęp, akceptacja użycia w AIWłaściciel "z nazwy", bez czasu i mandatu
Steward danychJakość na co dzień, metryki, poprawkiRola przypisana IT, które nie zna znaczenia danych
IT i bezpieczeństwoUprawnienia, szyfrowanie, logi, wykluczeniaKontrola tylko na poziomie aplikacji, nie indeksu
Inspektor ochrony danych (IOD)Podstawy prawne, DPIA, rejestr czynnościWłączenie po wdrożeniu zamiast na starcie
Zespół międzydziałowyPolityki, spory o dane, priorytetyBrak spotkań po pierwszym wdrożeniu

Co mówią RODO i AI Act o danych w systemach AI?

RODO dotyczy każdego systemu AI, który przetwarza dane osobowe, a AI Act stawia szczegółowe wymogi dotyczące danych systemom wysokiego ryzyka. Dla większości firm w Polsce to RODO jest dziś praktycznym punktem odniesienia.

Z RODO wynikają wprost zasady, które data governance musi przełożyć na kontrole: minimalizacja danych, prawidłowość, ograniczenie celu i przechowywania (art. 5), uwzględnienie ochrony danych w fazie projektowania (art. 25), bezpieczeństwo przetwarzania (art. 32) i ocena skutków dla ochrony danych przy przetwarzaniu wysokiego ryzyka (art. 35) (RODO). Raport o ryzykach prywatności w modelach LLM, przygotowany na zlecenie Europejskiej Rady Ochrony Danych (EROD), wskazuje dla systemów RAG m.in. kontrolę dostępu, anonimizację lub pseudonimizację danych osobowych oraz logi dostępu i zmian (EDPB, 2025).

AI Act w art. 10 wymaga, żeby zbiory treningowe, walidacyjne i testowe systemów wysokiego ryzyka podlegały praktykom zarządzania danymi, obejmującym m.in. pochodzenie danych, operacje przygotowania (adnotacje, etykietowanie, czyszczenie) i badanie pod kątem możliwej stronniczości (rozporządzenie (UE) 2024/1689). Po zmianie rozporządzeniem (UE) 2026/1744 obowiązki dla systemów wysokiego ryzyka z załącznika III stosuje się od 2 grudnia 2027 r. (rozporządzenie (UE) 2026/1744). Termin się przesunął, ale cztery filary opisane wyżej to dokładnie ta dokumentacja, o którą zapyta audytor.

Jak wdrożyć data governance dla AI krok po kroku?

Skupieniem, a nie perfekcją. Najlepiej działa podejście "jedno zastosowanie na raz":

  1. Określ zakres. Wybierz jedno zastosowanie AI. Spisz dane, których potrzebuje, oceń obecne kontrole i znajdź luki we właścicielstwie.
  2. Ustal właścicieli. Przypisz właściciela i stewarda do każdego zbioru. Zdefiniuj ścieżkę eskalacji i minimalne standardy jakości.
  3. Spisz wykluczenia. Lista danych, które nigdy nie trafią do systemu AI (na przykład dane o zdrowiu pracowników, hasła, dane kart płatniczych), ustalona przed wdrożeniem, a nie po incydencie.
  4. Wdroż kontrole. Automatyczne testy jakości, dostęp oparty na rolach, logowanie, zapis pochodzenia danych.
  5. Zbuduj nawyki. Przeszkol zespoły z zasad i włącz dbanie o dane do celów osób, które za nie odpowiadają.
  6. Skaluj. Przenieś wnioski na kolejne zastosowanie, popraw polityki, rozszerzaj zakres stopniowo.

Jakich błędów unikać?

Pięć pułapek, które widać najczęściej:

  • Governance jako jednorazowy projekt. Dane i przepisy się zmieniają. Zaplanuj przegląd co kwartał.
  • Governance tylko w IT. Bez biznesu, prawnika i IOD powstaną zasady, których nikt nie stosuje.
  • Przeinżynierowanie na starcie. Zacznij od właścicielstwa i dostępu, zaawansowane narzędzia dołóż później.
  • Pominięcie danych nieustrukturyzowanych. Dokumenty, maile i skany to główne paliwo modeli językowych i najsłabiej pilnowana część danych.
  • Brak pętli zwrotnej. Użytkownicy muszą mieć prosty sposób, żeby zgłosić złą odpowiedź AI, a zespół musi umieć przejść od tej odpowiedzi do źródła danych.

Od czego zacząć w tym tygodniu?

Nie potrzebujesz idealnego ładu danych, żeby zacząć. Potrzebujesz wystarczającego ładu wokół pierwszego zastosowania i zobowiązania, że będziesz go poprawiać:

  • wybierz pierwsze zastosowanie AI,
  • zmapuj potrzebne dane i ich źródła,
  • przypisz właściciela do każdego zbioru,
  • ustal, kto ma dostęp do informacji wrażliwych i czego AI nie dostanie,
  • określ standardy jakości i osobę, która ich pilnuje,
  • dokumentuj decyzje,
  • po wdrożeniu sprawdź, co zadziałało, i popraw zasady.

Dobrze zarządzane dane nie tylko zmniejszają ryzyko. Przyspieszają kolejne wdrożenia, bo każde następne zaczyna się od gotowej mapy, właścicieli i kontroli. Jeśli myślisz o tym, jak bezpiecznie podejść do kolejnych warstw systemu AI, zobacz nasz przegląd OWASP Top 10 dla aplikacji LLM.

Źródła