Co w praktyce znaczy „przejrzystość algorytmów”
Przejrzystość, wyjaśnialność i zrozumiałość – porządkowanie pojęć
„Przejrzystość algorytmów” dla jednych oznacza dostęp do kodu źródłowego, dla innych – prosty komunikat „dlaczego system podjął taką decyzję”. W praktyce chodzi o kilka nakładających się warstw, których nie da się zamknąć w jednym hasle.
Przejrzystość to możliwość zrozumienia, jak system działa i jakie ma skutki. Nie zawsze wymaga to pełnego ujawnienia całej technologii. Czasem wystarczą: opis celu, głównych kryteriów decyzji, źródeł danych i informacja, kto odpowiada za system.
Wyjaśnialność (explainability) koncentruje się na konkretnych decyzjach: dlaczego ten wniosek kredytowy odrzucono, a inny zaakceptowano; czemu ten kandydat został uszeregowany niżej. To poziom „case by case”.
Zrozumiałość to dostosowanie języka i formy do odbiorcy. Wyjaśnienie napisane pod audytora technicznego będzie bezużyteczne dla klienta banku. Ten sam system wymaga więc kilku wersji komunikacji, żeby mówić o nim „przejrzysty”.
Techniczna przejrzystość a potoczne „otwarty kod”
W świecie technicznym przejrzystość algorytmów bywa mylona z otwartością kodu. Udostępnienie repozytorium nie rozwiązuje problemu, jeśli:
- kod jest skomplikowany i praktycznie nieczytelny dla nikogo poza autorami,
- brakuje dokumentacji danych, parametrów i założeń,
- nie ma śladu decyzyjnego, który wiąże kod z konkretnymi wynikami.
Przejrzystość algorytmów można mieć także przy kodzie zamkniętym, o ile istnieje dobra dokumentacja modeli AI, opis procesu uczenia i wdrażania, a także jasne wyjaśnienie, jak system jest monitorowany i korygowany.
Potoczne oczekiwanie „pokażcie kod” zwykle jest nieskuteczne dla użytkowników i regulatorów. Więcej wnosi zwięzły opis:
- jakie dane wejściowe są używane,
- jakie kryteria decyzji mają kluczowe znaczenie,
- jakie ograniczenia i znane błędy ma model.
Techniczna przejrzystość obejmuje nie tylko algorytm, ale też pipeline: od zbierania danych, przez trening, aż po wdrożenie i monitoring.
Przejrzystość modelu a przejrzystość procesu decyzyjnego
Można mieć bardzo „jasny” model (np. proste drzewo decyzji), a jednocześnie kompletnie nieprzejrzysty proces decyzyjny organizacji. Przykład: bank ma zrozumiały scoring kredytowy, ale wynik modelu jest tylko jednym z kilku czynników, a reszta zasad jest w wewnętrznych procedurach.
Przejrzystość modelu dotyczy:
- architektury (jakiego typu to model, jak się uczy),
- głównych cech używanych w decyzji,
- typowych ograniczeń (np. wrażliwość na jakość danych).
Przejrzystość procesu decyzyjnego to odpowiedzi na pytania:
- jaką rolę ma algorytm w procesie – rekomendacja czy automatyczna decyzja,
- kto może nadpisać decyzję systemu i na jakiej podstawie,
- jak można się od decyzji odwołać,
- jak organizacja reaguje na błędy modelu.
Dla użytkownika istotniejszy jest zwykle cały ślad decyzyjny systemu niż sama architektura modelu. Dlatego przejrzystość algorytmów w praktyce musi objąć także reguły biznesowe, organizację procesu, a nawet politykę firmy.
Explainability vs interpretability – niuans, który ma znaczenie
W literaturze technicznej mowa jest często o dwóch poziomach:
- interpretowalność – model jest z natury zrozumiały (np. regresja liniowa z kilkoma cechami),
- wyjaśnialność post hoc – model jest skomplikowaną „czarną skrzynką” (np. głęboka sieć), ale obok stosuje się metody próbujące wyjaśnić jego działanie.
Interpretowalny model pozwala analitykowi zrozumieć wpływ cech globalnie: można przejrzeć współczynniki czy ścieżki drzewa. Wyjaśnialność post hoc daje raczej lokalne, przybliżone odpowiedzi: „dla tego klienta największy wpływ miały: wiek, liczba zaległości, rodzaj umowy”.
Rozróżnienie jest ważne dla przejrzystości algorytmów, bo od razu wskazuje na kompromis: im bardziej złożony model, tym częściej trzeba używać narzędzi wyjaśnialności, a te z natury upraszczają i mogą wprowadzać w błąd, jeśli są prezentowane bez zastrzeżeń.
Dla kogo ma być przejrzysty algorytm
Ten sam system powinien być inaczej opisywany w zależności od grupy, która ma z niego rozumieć:
- Programista / data scientist – potrzebuje dokumentacji technicznej, metryk, szczegółów danych, kodu, konfiguracji środowisk.
- Prawnik / inspektor ochrony danych – chce poznać podstawę prawną, zakres danych, wpływ na prawa osób, zgodność z regulacjami.
- Regulator / audytor – wymaga dostępu do dokumentacji modeli AI, logów, raportów z testów, analiz ryzyka.
- Użytkownik końcowy – oczekuje krótkich, jasnych wyjaśnień decyzji i informacji, co może zrobić dalej.
Przejrzystość algorytmów jest więc projektowana warstwowo. Nie da się jednym dokumentem zadowolić wszystkich. Kluczowe jest oddzielenie tego, co musi być wytłumaczone szczegółowo (dla audytora), od tego, co ma być przekazane prosto i krótko (dla klienta).
Przejrzystość jako środek, nie cel sam w sobie
Przejrzystość algorytmów nie jest wartością abstrakcyjną. Ma wspierać trzy cele:
- zaufanie – użytkownik widzi, że system działa według jasnych, przewidywalnych zasad,
- kontrola – organizacja i regulator są w stanie zatrzymać, poprawić lub wyłączyć system, gdy coś idzie nie tak,
- odpowiedzialność – wiadomo, kto podjął kluczowe decyzje i kto odpowiada za skutki.
Jeśli przejrzystość algorytmów nie prowadzi do lepszej kontroli i rozliczalności, pozostaje „sztuczna” – dokumenty są, slajdy są, ale w praktyce nikt z tego nie korzysta, a użytkownik nie ma realnej siły, by zakwestionować decyzję.
Dlaczego przejrzystość jest kluczowa w etyce AI i prawie
Zaufanie i legitymizacja władzy algorytmicznej
Algorytmy coraz częściej decydują o dostępie do kredytu, pracy, świadczeń, usług medycznych. Stają się nową infrastrukturą decyzyjną. Gdy decyzję podejmuje człowiek, pytanie „dlaczego?” jest naturalne. Gdy decyduje system, odpowiedź bywa zasłonięta technicznym żargonem.
Przejrzystość algorytmów umożliwia społeczną akceptację: ludzie godzą się, by część władzy decyzyjnej oddać systemom pod warunkiem, że można zrozumieć ich działanie, a w razie potrzeby – je zakwestionować.
Bez przejrzystości pojawia się poczucie arbitralności: „system tak policzył”. To prosta droga do utraty zaufania do instytucji, które na takich systemach się opierają.
Kwestionowanie decyzji i prawo do odwołania
Prawo do odwołania od decyzji ma sens tylko wtedy, gdy wiadomo, co kwestionować. Użytkownik, który słyszy jedynie „decyzja została podjęta automatycznie”, jest w praktyce pozbawiony realnych środków obrony.
Przejrzystość algorytmów w tym obszarze oznacza co najmniej:
- informację, że decyzja została podjęta z użyciem systemu algorytmicznego,
- jasny opis głównych kryteriów, które miały znaczenie,
- dostęp do śladu decyzyjnego systemu (przynajmniej w formie streszczenia dla użytkownika),
- informację, jak zgłosić sprzeciw i domagać się decyzji z udziałem człowieka.
Bez tego „prawo do odwołania” staje się fikcją. Z punktu widzenia etyki AI prawo do wyjaśnienia i możliwość zakwestionowania decyzji to kluczowy wyznacznik, czy system działa fair.
Brak przejrzystości a ryzyko dyskryminacji
Algorytmy, które działają w trybie „czarnej skrzynki”, mogą utrwalać lub wzmacniać istniejące uprzedzenia. Klasyczne przykłady:
- systemy rekrutacyjne preferujące kandydatów z określonych uczelni lub branż,
- modele scoringu kredytowego, które pośrednio dyskryminują ze względu na miejsce zamieszkania, formę zatrudnienia czy płeć,
- algorytmy rekomendujące wyższe składki ubezpieczeniowe dla osób z określonych dzielnic.
Jeśli nie ma przejrzystości danych i logiki działania systemu, trudno wykryć, że takie uprzedzenia i dyskryminacja w AI w ogóle występują. Brakuje podstaw do audytu algorytmicznego i korekty.
Przejrzystość nie gwarantuje braku dyskryminacji, ale tworzy warunki, by ją identyfikować i ograniczać: umożliwia analizę wpływu zmiennych, wyniki testów biasu, wgląd w kryteria odrzucenia wniosków.
Rozliczalność: kto naprawdę odpowiada za decyzję
Bez przejrzystości łatwo zrzucić winę na „algorytm”. Tymczasem w świetle prawa i etyki odpowiedzialność jest zawsze ludzka i organizacyjna. Ktoś model zaprojektował, wybrał dane, zatwierdził do użycia, określił próg ryzyka.
Governance modeli – struktura odpowiedzialności za systemy AI – wymaga, aby:
- było wiadomo, kto zatwierdza modele do produkcji,
- istniały procedury przeglądu i audytu,
- przechowywano ślad decyzyjny systemu (kto, kiedy, jakiej zmiany dokonał),
- dało się odtworzyć, jaką wersją modelu podjęto daną decyzję.
Przejrzystość algorytmów tu oznacza, że w razie sporu można odtworzyć łańcuch zdarzeń: od danych wejściowych, przez parametry modelu, po ostateczną decyzję i interwencje ludzi.
Ekonomiczny wymiar przejrzystości
Przejrzystość algorytmów to nie tylko kwestia etyki. To także bardzo praktyczny element zarządzania ryzykiem prawnym i reputacyjnym. Brak przejrzystości generuje:
- koszty sporów sądowych i interwencji regulatorów,
- ryzyko kar administracyjnych (np. naruszenie RODO, AI Act),
- straty reputacyjne po nagłośnieniu „skandalu algorytmicznego”.
Organizacja, która nie dokumentuje modeli, nie gromadzi logów, nie ma polityki wyjaśniania decyzji, praktycznie nie ma jak się bronić, gdy zarzuci się jej dyskryminację lub naruszenie praw jednostki.
Z drugiej strony dobrze zaprojektowana przejrzystość algorytmów pozwala szybciej reagować na problemy, podejmować decyzje o poprawkach modeli i pokazać regulatorowi, że organizacja działa w sposób odpowiedzialny.
Ramy prawne: co już dziś wymagają przepisy
Przejrzystość i „zrozumiała informacja” w RODO
RODO nie używa wprost pojęcia „przejrzystość algorytmów”, ale de facto wymusza ją na kilku poziomach. Kluczowe są:
- art. 13–15 RODO – obowiązek przekazania osobie, której dane dotyczą, zrozumiałej informacji o przetwarzaniu, w tym logiki stosowanej w zautomatyzowanym podejmowaniu decyzji, a także znaczeniu i przewidywanych konsekwencjach takiego przetwarzania;
- art. 22 RODO – regulacja zautomatyzowanego podejmowania decyzji, w tym profilowania, wywołujących skutki prawne lub podobnie istotne.
Z punktu widzenia przejrzystości algorytmów ważne są trzy elementy:
- obowiązek przekazania informacji jasnym, prostym językiem (bez samego żargonu technicznego),
- ujawnienie przynajmniej ogólnych zasad logiki systemu,
- opis skutków dla osoby – co się stanie w praktyce, gdy model zaklasyfikuje ją w określony sposób.
RODO nie nakazuje publikować kodu ani pełnych parametrów modeli. Wymaga jednak takiego poziomu wyjaśnienia, który pozwoli zorientować się, w jakim celu i na jakiej zasadzie algorytm podejmuje decyzje dotyczące danej osoby.
„Prawo do wyjaśnienia” – mit czy realne uprawnienie
W debacie publicznej często mówi się o „prawie do wyjaśnienia” decyzji algorytmu. W RODO nie ma tego sformułowania wprost. W praktyce prawo to wynika z kombinacji:
- obowiązków informacyjnych (art. 13–15),
- prawa do sprzeciwu i zakwestionowania decyzji (art. 21, 22),
- prawa dostępu do danych i ich korekty.
Granice przejrzystości w świetle tajemnicy przedsiębiorstwa
Regulacje zachęcają do przejrzystości, ale równolegle chronią tajemnicę przedsiębiorstwa. Organizacje często obawiają się, że zbyt daleko idące ujawnianie logiki modeli osłabi ich przewagę konkurencyjną lub ułatwi obejście systemów zabezpieczeń (np. w systemach antyfraudowych).
W praktyce prawo nie wymaga ujawniania „receptury” modelu. Wymaga raczej pokazania efektów i zasadniczych kryteriów, które wpływają na decyzję. Można więc:
- zachować szczegóły implementacyjne jako tajemnicę,
- a jednocześnie dostarczać osobom dotkniętym decyzją opis głównych czynników, progów i możliwych konsekwencji.
Balans polega na tym, by nie budować przejrzystości wyłącznie na poziomie marketingowych ogólników typu „nasz algorytm sprawiedliwie ocenia wszystkich klientów”. Takie komunikaty nie wystarczą ani regulatorowi, ani sądowi, ani użytkownikowi.
Ocena skutków dla ochrony danych (DPIA) jako narzędzie przejrzystości
RODO wprowadza obowiązek przeprowadzenia oceny skutków dla ochrony danych (DPIA) przy operacjach wysokiego ryzyka, często obejmujących zautomatyzowane decyzje. Dobrze przeprowadzona DPIA jest fundamentem przejrzystości „do wewnątrz” organizacji.
Dokument ten powinien obejmować m.in.:
- opis przepływu danych od pozyskania po usunięcie,
- opis logiki modeli i punktów, w których zapadają decyzje,
- ocenę wpływu na prawa i wolności osób,
- plan środków zaradczych, jeśli pojawią się nieakceptowalne ryzyka.
W wielu firmach DPIA traktuje się jak formalność. Tymczasem to jedno z nielicznych miejsc, gdzie całość procesu algorytmicznego jest opisana w jednym dokumencie. Bez tego trudno po czasie odtworzyć, dlaczego system działa tak, a nie inaczej.
AI Act: nowe wymogi przejrzystości dla systemów wysokiego ryzyka
Unijny AI Act wprowadza odrębny zestaw obowiązków dotyczących systemów AI, szczególnie tych zakwalifikowanych jako wysokiego ryzyka (np. scoring kredytowy, rekrutacja, dostęp do usług publicznych). Przejrzystość jest tam jednym z głównych filarów.
Dla systemów wysokiego ryzyka AI Act przewiduje m.in.:
- rozbudowaną dokumentację techniczną modeli,
- rejestrowanie działania systemu (logi),
- obowiązek zapewnienia odpowiednich informacji użytkownikom systemu,
- jasne przypisanie odpowiedzialności za nadzór nad systemem.
Nowością jest nacisk na dokumentowanie całego cyklu życia systemu AI – nie tylko w momencie wdrożenia, ale też podczas aktualizacji, retrainingu, zmiany danych. Przejrzystość ma być procesem ciągłym, a nie jednorazowym raportem.
Oznaczanie treści generowanych przez AI
AI Act i inne inicjatywy regulacyjne (np. kodeksy branżowe) wprowadzają coraz więcej wymogów dotyczących oznaczania treści generowanych przez systemy AI. Dotyczy to m.in. deepfake’ów, chat‑botów, generatorów obrazów.
Tu przejrzystość jest bardzo prosta: użytkownik ma wiedzieć, że nie rozmawia z człowiekiem albo że ogląda treść wygenerowaną syntetycznie. Kluczowe elementy to:
- widoczne oznaczenie interfejsu (np. nazwa bot, AI assistant),
- informacja, czy rozmowa jest nagrywana i analizowana do dalszego trenowania modeli,
- możliwość przełączenia się do kontaktu z człowiekiem, gdy w grę wchodzą ważne decyzje.
Taki poziom przejrzystości nie wymaga ujawniania technicznych detali. Wymaga podstawowej uczciwości wobec użytkownika, aby nie miał złudzeń, z kim (a właściwie z czym) ma do czynienia.
Poziomy przejrzystości: co można „ujawnić” i komu
Przejrzystość wewnętrzna: dla zespołów technicznych i zarządu
Wewnątrz organizacji przejrzystość oznacza przede wszystkim to, że osoby odpowiedzialne za produkt, ryzyko i zgodność rozumieją, jak działają systemy, którymi zarządzają. Nie chodzi o to, by każdy członek zarządu potrafił napisać sieć neuronową, ale by wiedział, od jakich danych i założeń zależy biznesowy wynik modelu.
Podstawowe elementy przejrzystości wewnętrznej to m.in.:
- katalog modeli z opisem celu, danych wejściowych, właściciela biznesowego,
- raporty z walidacji i monitoringu jakości (w języku zrozumiałym również poza działem data science),
- procedury zatwierdzania zmian w modelach, w tym kryteria akceptacji ryzyka.
W praktyce oznacza to, że decyzja „wdrażamy nową wersję modelu scoringowego” ma podstawę w dokumentach, a nie w nieformalnej rozmowie na Slacku. Później, gdy pojawi się kwestionowana decyzja, można się do tych materiałów odwołać.
Przejrzystość zewnętrzna: dla klientów i użytkowników
Dla osób, których dotyczą decyzje, zbyt techniczne wyjaśnienia są bezużyteczne. Potrzebują krótkich komunikatów: co miało wpływ na decyzję, czy mogą coś zmienić i jak się odwołać.
Minimalny zestaw, który można wdrożyć niemal w każdej organizacji:
- krótkie opisy przy formularzach („Twoje dane zostaną użyte do automatycznej oceny ryzyka kredytowego”),
- streszczenia decyzji („Wniosek odrzucono głównie z powodu: brak historii spłaty, nieregularne wpływy na konto”),
- jasna instrukcja ścieżki odwoławczej („Możesz złożyć wniosek o ponowną ocenę przez analityka”).
Praktyczny przykład: bank odrzuca wniosek kredytowy. Zamiast lakonicznego „brak zdolności kredytowej” klient dostaje listę głównych czynników: poziom dochodu, obciążenia innymi kredytami, historia opóźnień. Nie musi znać dokładnej formuły modelu, żeby móc sensownie zareagować.
Przejrzystość „ekspercka”: dla regulatorów i audytorów
Regulator i zewnętrzny audytor muszą zobaczyć więcej niż klient, ale niekoniecznie wszystko. Zazwyczaj potrzebują dostępu do:
- opisu architektury modelu i procesu trenowania,
- statystyk dotyczących jakości modelu (accuracy, recall, błędy krańcowe),
- analiz wpływu na wybrane grupy (testy biasu, rozkłady wyników),
- opisów scenariuszy testowych i warunków, w jakich model może zawodzić.
Takie informacje powinny być dostępne w sposób pozwalający je zweryfikować, a nie tylko „uwierzyć na słowo”. Dlatego logi, arkusze testów i kody eksperymentów stają się elementem „księgowości algorytmicznej”.
Przejrzystość kodu vs. przejrzystość zachowania
Nie zawsze jest sens udostępniać kod. Dla większości odbiorców ważniejsze jest to, jak system zachowuje się w różnych sytuacjach, niż to, czy model ma 12 czy 24 warstwy. Ujawnienie kodu nie rozwiązuje problemu, jeśli nikt poza wąską grupą ekspertów nie jest w stanie go przeanalizować.
Często bardziej użyteczne jest udostępnianie:
- przykładowych przypadków i odpowiedzi systemu,
- statystyk pokazujących zachowanie na różnych grupach użytkowników,
- informacji o granicach działania („system nie nadaje się do oceny osób bez historii kredytowej”).
Takie „przejrzystości behawioralnej” można żądać także od bardzo złożonych modeli, gdzie wyjaśnienie wewnętrznych mechanizmów jest w praktyce niemożliwe.
Techniczne podejścia do wyjaśnialności i ich ograniczenia
Modele z natury bardziej przejrzyste
Najprostsze podejście do wyjaśnialności to używanie takich modeli, które same w sobie są bardziej zrozumiałe. Chodzi o regresję liniową, drzewa decyzyjne, proste modele regułowe.
Ich zaletą jest możliwość bezpośredniego odczytania wpływu zmiennych na wynik. Wadą – ograniczona skuteczność przy złożonych danych (obrazy, tekst, sygnały czasowe) i ryzyko oversimplifikacji. W praktyce często stosuje się hybrydy: głęboki model w tle, ale z dodatkową warstwą regułową, która narzuca granice i pozwala generować zrozumiałe uzasadnienia.
Metody post‑hoc: LIME, SHAP i podobne
Dla złożonych modeli (np. sieci neuronowych) stosuje się techniki post‑hoc, które próbują „wyjaśnić” konkretną decyzję już po jej podjęciu. Dwie najczęściej używane rodziny metod to:
- LIME – lokalne modele liniowe przybliżające zachowanie modelu w okolicy jednego punktu,
- SHAP – wartości przypisujące każdej zmiennej wkład w konkretną predykcję (w oparciu o teorię gier).
Metody te pozwalają pokazać np., że w przypadku danego klienta największy wpływ na decyzję miały dochód, forma zatrudnienia i liczba aktywnych kredytów. To daje materiał do zbudowania zrozumiałego wyjaśnienia dla użytkownika.
Problem w tym, że takie wyjaśnienia są przybliżeniem, a nie wiernym opisem wewnętrznego działania modelu. Mogą być wrażliwe na dobór parametrów i zakłócenia, a przy dużej liczbie zmiennych generować szum zamiast realnego wglądu.
Wizualizacje i „mapy uwagi”
W systemach przetwarzających obrazy lub tekst stosuje się wizualne metody wyjaśniania: heatmapy, mapy uwagi (attention), podświetlanie fragmentów tekstu, które „zdecydowały” o wyniku.
Przykład: system do analizy zdjęć medycznych podświetla obszar płuca, na podstawie którego uznał, że istnieje wysokie prawdopodobieństwo zmiany nowotworowej. Lekarz widzi, na czym „skupił się” model, i może to zestawić ze swoją wiedzą.
Takie wizualizacje pomagają ekspertom, ale mogą być mylące dla laików. Podświetlony fragment niekoniecznie oznacza, że model „rozumie” go tak jak człowiek. To raczej wskazówka, gdzie sygnał był statystycznie istotny w procesie uczenia.
Ograniczenia wyjaśnialności: iluzja zrozumienia
Duża część narzędzi wyjaśnialności tworzy wrażenie zrozumienia, ale niekoniecznie faktyczną kontrolę. Istnieje ryzyko, że organizacje będą traktować kolorowe wykresy czy heatmapy jako „tarcze prawne”, bez realnej refleksji nad tym, czy model nie szkodzi określonym grupom.
Kilka typowych problemów:
- wyjaśnienia są niestabilne – zmiana jednego parametru wejściowego radykalnie zmienia „ważność” cech,
- metody post‑hoc często nie pokazują interakcji między zmiennymi,
- użytkownicy przyjmują wyjaśnienie jako prawdę, choć jest ono jedynie jednym z wielu możliwych opisów.
Wyjaśnialność techniczna powinna być uzupełniona testami etycznymi i prawnymi, a nie je zastępować. Samo posiadanie narzędzia XAI nie oznacza, że system jest zgodny z prawem czy „sprawiedliwy”.
Prostota tam, gdzie to możliwe
W wielu zastosowaniach bardziej opłaca się użyć prostszego, trochę mniej dokładnego modelu, który łatwiej wyjaśnić, niż maksymalnie „wyżyłowanego” modelu, którego zachowanie jest nieprzewidywalne. Zwłaszcza tam, gdzie stawką są poważne konsekwencje dla ludzi.
Strategia „simple where you can, complex where you must” zakłada, że złożone modele rezerwuje się dla tych obszarów, gdzie innego wyjścia nie ma (np. rozpoznawanie obrazów), a w obszarach regulowanych prawnie (np. decyzje kredytowe) priorytetem jest wyjaśnialność, nie tylko maksymalna dokładność.
Przejrzystość danych: skąd się biorą i jak wpływają na decyzje
Źródła danych jako punkt startowy przejrzystości
Nie ma przejrzystych algorytmów bez przejrzystych danych. Każda decyzja algorytmiczna jest wypadkową tego, co i jak zebrano. W praktyce mało kto komunikuje użytkownikom, skąd pochodzą dane używane do trenowania modeli.
Lista podstawowych pytań, na które warto umieć odpowiedzieć:
- czy dane pochodzą tylko z systemów wewnętrznych, czy też są kupowane z zewnątrz,
- czy do trenowania użyto także danych publicznych (np. z portali społecznościowych),
- jak długo dane są przechowywane i kiedy są usuwane lub anonimizowane.
Przykład: firma ubezpieczeniowa korzysta z danych o historii szkód, ale też z zewnętrznej bazy informacji o majątku. Od tego, jak opisze ten proces klientom i regulatorowi, zależy postrzeganie uczciwości jej modeli cenowych.
Dane historyczne i efekt „kopiowania przeszłości”
Modele uczone na danych historycznych mają tendencję do reprodukowania dawnych wzorców, także tych niepożądanych. Jeśli wcześniej firma rzadko zatrudniała kobiety na stanowiskach technicznych, algorytm rekrutacyjny „nauczy się”, że „dobry kandydat” to raczej mężczyzna.
Przejrzystość danych oznacza tu m.in.:
- uciekanie od bezrefleksyjnego używania „pełnej historii” jako złotego standardu,
- dokumentowanie, jakie okresy danych przyjęto i dlaczego,
Selekcja, filtrowanie i „czyszczenie” danych
Dane rzadko trafiają do modelu w surowej postaci. Po drodze są filtrowane, czyszczone, agregowane. Na tym etapie zapada wiele decyzji, które później trudno prześledzić, jeśli nie są dobrze opisane.
Przejrzystość oznacza tu m.in. udokumentowanie:
- jakie rekordy są odrzucane (np. „niekompletne wnioski”, „podejrzenie nadużycia”),
- jakie zmienne są uzupełniane „domyślnymi” wartościami i na jakiej podstawie,
- jak łączone są dane z różnych systemów (klucze, reguły dopasowania),
- jakie reguły wygładzania czy agregacji zastosowano (np. uśrednianie po miesiącach).
Jeśli system rekrutacyjny automatycznie odrzuca wszystkie CV bez pełnych danych kontaktowych, ale formularz ich nie wymusza, powstaje ukryty filtr. Bez dokumentacji trudno później zrozumieć, dlaczego część kandydatów nigdy nie była „widoczna” dla algorytmu.
Zmienne pośrednie i ukryte wskaźniki
Nawet jeśli model formalnie nie używa cech wrażliwych, może je odtwarzać z innych wskaźników. Kod pocztowy, typ szkoły czy marka telefonu często silnie korelują z dochodem, pochodzeniem czy wiekiem.
Przejrzystość danych obejmuje także ocenę, czy:
- nie wprowadzono do modelu „proxy” cech wrażliwych,
- nie stosuje się wskaźników, których znaczenia nikt w organiz