Model data governance dla produktów AI

Data governance dla produktu AI nie powinien być osobnym programem katalogowania danych. Ma działać jak warstwa sterująca produktem: określa, jakie dane mogą zasilać konkretną funkcję, jaki poziom jakości jest wystarczający, kto akceptuje odstępstwo i jak wycofać wynik zbudowany na wadliwym zbiorze. Katalog bez progów, właścicieli i bramki wdrożeniowej opisuje ryzyko, ale nim nie zarządza.

Governance musi być zależny od celu. Ten sam brak danych może być mało istotny w narzędziu porządkującym dokumenty i niedopuszczalny w systemie wpływającym na dostęp do usługi. Dlatego jakość, reprezentatywność, retencja oraz prawa użycia należy łączyć z zamierzonym zastosowaniem, populacją i kosztem błędu. Dopiero wtedy zespół może wybrać kontrolę i miernik.

Zacznij od decyzji produktowej

Dla każdej funkcji AI trzeba opisać decyzję lub działanie, które wspiera, dozwolonych użytkowników, osoby dotknięte wynikiem, warunki użycia oraz możliwe szkody. Dokument powinien rozróżniać dane treningowe, walidacyjne, testowe, dane wejściowe w produkcji, feedback oraz dane generowane przez system. Każda z tych kategorii ma inny cykl życia i właściciela.

Zespół ustala minimalne wymagania przed pozyskaniem zbioru: zakres populacji, okres, dopuszczalne źródła, wymaganą świeżość, zasady etykietowania oraz przypadki, których system nie może obsługiwać. Jeżeli danych nie da się uzyskać zgodnie z prawem lub na odpowiednim poziomie jakości, właściwą decyzją może być zmiana funkcji albo rozwiązanie bez AI.

Udokumentuj pochodzenie i prawa użycia

Każdy zbiór potrzebuje lineage od źródła przez transformacje do modelu i wydania. Rekord powinien zawierać dostawcę, sposób pozyskania, cel, podstawę lub warunki użycia, licencję, ograniczenia geograficzne, retencję, klasyfikację wrażliwości i właściciela. Pole „publiczne dane” nie wyjaśnia, czy wolno je kopiować, trenować na nich model, udostępniać pochodne ani przetwarzać dane osobowe.

Lineage musi zachować wersję kodu transformacji i parametrów, nie tylko nazwy tabel. W razie incydentu organizacja powinna ustalić, które modele, eksperymenty i odpowiedzi korzystały z wadliwego rekordu lub źródła. NIST AI RMF 1.0 wskazuje pochodzenie danych treningowych jako mechanizm wspierający przejrzystość i odpowiedzialność oraz wymaga zarządzania ryzykiem w całym cyklu życia.

Wprowadź kontrakty danych i właścicieli

Kontrakt danych opisuje schemat, znaczenie pól, dozwolone wartości, aktualność, sposób obsługi braków, reguły zmiany oraz oczekiwany poziom usługi. Producent danych odpowiada za publikowany kontrakt i informowanie o zmianach; właściciel produktu AI określa, czy dane są odpowiednie dla zastosowania; steward rozstrzyga definicje i jakość; bezpieczeństwo oraz privacy kontrolują dostęp i zgodność.

Zmiana niezgodna z kontraktem powinna zatrzymać pipeline lub skierować wydanie do jawnej akceptacji. Automatyczne uzupełnienie braków nie może maskować awarii źródła. Zespół musi rozróżnić wartość rzeczywiście zerową, nieznaną i niedostępną z powodu błędu. Dla krytycznych cech warto posiadać alternatywne źródło albo bezpieczny tryb degradacji.

Mierz jakość względem zastosowania

Nie istnieje jeden wskaźnik jakości zbioru. Produkt może wymagać poprawności, kompletności, spójności, aktualności, unikalności, reprezentatywności i stabilności rozkładu w różnych proporcjach. Dla każdej cechy należy wskazać metodę pomiaru, próg, częstotliwość, właściciela i działanie po przekroczeniu. Próg powinien wynikać z wpływu na zachowanie systemu, nie z estetyki dashboardu.

ISO/IEC 5259-1:2024, opublikowana 2 lipca 2024 roku, ustanawia wspólne pojęcia i kontekst oceny jakości danych dla analityki oraz uczenia maszynowego. W praktyce miary zbioru trzeba połączyć z miarami systemu. Niewielka zmiana rozkładu może być obojętna dla jednego modelu, a krytyczna dla innego. Test wpływu powinien obejmować segmenty, przypadki graniczne i zamierzone środowisko użycia.

Egzekwuj dostęp przed pipeline’em

Kontrola dostępu ma działać na źródle, w warstwie przetwarzania, magazynie cech, środowisku eksperymentalnym i logach. Role powinny wynikać z zadania, a dostęp uprzywilejowany mieć termin i właściciela. Kopia danych pobrana do notebooka lub systemu etykietowania pozostaje w zakresie governance, nawet jeśli nie znajduje się już w głównej platformie.

Minimalizacja jest kontrolą architektoniczną. Jeżeli model potrzebuje kategorii wieku, nie powinien automatycznie otrzymywać pełnej daty urodzenia. Zespół powinien oddzielać identyfikatory, dane szczególnej kategorii i informacje używane tylko do testów biasu. Eksport, syntetyzowanie i udostępnianie dostawcy wymagają zapisania celu, zakresu oraz sposobu usunięcia.

Wersjonuj zbiór razem z modelem

Wydanie produktu powinno wskazywać niezmienny identyfikator zbioru, kod transformacji, konfigurację cech, model, testy i zaakceptowane wyjątki. Dzięki temu wynik można odtworzyć, porównać i wycofać. „Najnowsze dane” nie są wersją, ponieważ źródło może zmienić się między treningiem a audytem.

Artykuł 10 AI Act ustanawia wymagania dotyczące governance zbiorów treningowych, walidacyjnych i testowych dla systemów wysokiego ryzyka. Obejmują one między innymi wybór danych, pozyskanie, przygotowanie, założenia, dostępność, adekwatność i analizę możliwych biasów. Nie należy przedstawiać tego przepisu jako obowiązku identycznego dla każdego produktu AI; jest jednak użytecznym wzorcem artefaktów, które umożliwiają kontrolę wydania.

Monitoruj dane po wdrożeniu i reaguj

Monitoring powinien wykrywać opóźnione źródła, zmianę schematu, wzrost braków, nieoczekiwane kategorie, drift rozkładu, utratę reprezentatywności oraz naruszenie reguł dostępu. Alert musi wskazywać dotknięty produkt i decyzję, a nie tylko tabelę. Właściciel określa, czy zatrzymać ingest, przełączyć się na poprzednią wersję, ograniczyć funkcję czy zaakceptować krótkotrwałą degradację.

Incydent danych wymaga możliwości ustalenia zakresu: które modele i wyniki powstały z wadliwego materiału, kto je otrzymał i czy decyzje trzeba ponownie ocenić. Koncepcja profilu Data Governance and Management NIST łączy działania governance z ryzykiem prywatności, cyberbezpieczeństwa i AI oraz podkreśla potrzebę oceny jakości w kontekście użycia. Dokument jest concept paper, a nie finalnym standardem, ale jego wspólny model ryzyka pomaga uniknąć trzech odrębnych procesów dla tych samych danych.

Zarząd powinien otrzymywać miary prowadzące do decyzji: pokrycie krytycznych zbiorów właścicielami i kontraktami, wiek wyjątków, czas od wykrycia do ustalenia lineage, liczbę wydań z niepełnym dowodem, częstotliwość incydentów jakości oraz czas bezpiecznego rollbacku. Sukcesem nie jest liczba wpisów w katalogu. Jest nim zdolność zatrzymania złych danych przed wpływem na ludzi i usługę.