1 dzień temu
Algorytm nie staje się zgodny z prawem dlatego, iż zespół techniczny tak ocenia. W sporze z klientem, podczas audytu inwestora albo kontroli organu liczy się możliwość odtworzenia decyzji: po co system wdrożono, na jakich danych pracuje, kto zatwierdził jego użycie i jakie zabezpieczenia faktycznie zastosowano. Dlatego pytanie, jak dokumentować zgodność algorytmów, powinno paść przed uruchomieniem produktu, a nie dopiero po zgłoszeniu incydentu.
Dokumentacja nie jest tu biurokratycznym dodatkiem do kodu. Jest materialnym dowodem governance. Pozwala wykazać rozliczalność na gruncie RODO, przygotować organizację na obowiązki wynikające z AI Act, a także obronić decyzje biznesowe wobec kontrahentów, audytorów i zarządu. Zakres dokumentacji zależy jednak od funkcji systemu, skali ryzyka oraz roli przedsiębiorcy w łańcuchu dostaw AI.
Jak dokumentować zgodność algorytmów od początku
Najczęstszym błędem jest tworzenie jednego, ogólnego dokumentu zatytułowanego „polityka AI”. Taki dokument może wyznaczać zasady organizacyjne, ale nie odpowie na podstawowe pytania dotyczące konkretnego systemu. Inaczej należy udokumentować model, który porządkuje zgłoszenia serwisowe, inaczej narzędzie oceniające zdolność kredytową, a jeszcze inaczej rozwiązanie wspierające rekrutację lub wykrywanie nadużyć.
Punktem wyjścia powinien być rejestr systemów algorytmicznych. Nie chodzi wyłącznie o rozwiązania nazwane przez dostawcę sztuczną inteligencją. Rejestr powinien objąć każdy system, który na podstawie danych generuje rekomendację, klasyfikację, ranking, prognozę albo decyzję wpływającą na klienta, pracownika, kontrahenta lub uczestnika rynku.
Dla każdego systemu warto stworzyć kartę systemu. Powinna ona wskazywać właściciela biznesowego i technicznego, cel użycia, użytkowników, osoby dotknięte wynikiem działania, źródła danych, dostawcę technologii, środowisko wdrożenia oraz datę zatwierdzenia. Już na tym etapie należy opisać, czy wynik algorytmu ma charakter wyłącznie pomocniczy, czy faktycznie przesądza o decyzji.
To rozróżnienie ma szczególne znaczenie przy RODO. o ile przetwarzanie prowadzi do decyzji wywołującej wobec osoby skutki prawne lub podobnie istotnie na nią wpływającej, trzeba ocenić zastosowanie art. 22 RODO. Deklaracja, iż „człowiek jest w procesie”, nie wystarcza. Dokumentacja powinna pokazywać, iż człowiek ma realną kompetencję do zakwestionowania wyniku, dostęp do informacji potrzebnych do oceny sprawy i odpowiedni czas na podjęcie decyzji.
Klasyfikacja ryzyka nie może być jednorazowa
Kolejnym krokiem jest kwalifikacja prawna zastosowania. W odniesieniu do systemów AI należy przede wszystkim ustalić rolę przedsiębiorcy – czy jest dostawcą, podmiotem stosującym, importerem, dystrybutorem czy podmiotem, który istotnie modyfikuje system. Od tej roli zależy zakres obowiązków wynikających z rozporządzenia AI Act.
Następnie trzeba ocenić, czy dane zastosowanie jest zakazane, kwalifikuje się jako system wysokiego ryzyka, podlega obowiązkom przejrzystości czy pozostaje poza tymi kategoriami. Ocena nie powinna ograniczać się do odpowiedzi „tak” albo „nie”. W aktach compliance należy zapisać stan faktyczny, przyjęte przesłanki, analizowane przepisy, źródła informacji od dostawcy oraz osobę, która zatwierdziła kwalifikację.
To istotne również dlatego, iż klasyfikacja może się zmienić. Ten sam model językowy używany do streszczania dokumentów wewnętrznych może generować ograniczone ryzyko. o ile jednak zacznie automatycznie selekcjonować kandydatów do pracy lub rekomendować odmowę świadczenia, zmienia się nie tylko kontekst biznesowy, ale też ocena prawna. Rejestr powinien więc przewidywać datę kolejnego przeglądu oraz zdarzenia, które wymuszają ponowną ocenę: zmianę celu, danych, modelu, dostawcy, grupy użytkowników lub sposobu podejmowania decyzji.
Dowód zgodności obejmuje dane, model i proces decyzyjny
Dobrze prowadzona dokumentacja łączy perspektywę techniczną, prawną i operacyjną. Sam opis architektury nie wykaże zgodności z zasadą minimalizacji danych. Z kolei opinia prawna bez informacji o wersji modelu, progach decyzyjnych i wynikach testów nie pozwoli ustalić, co organizacja rzeczywiście wdrożyła.
W praktyce pakiet dowodowy dla systemu o podwyższonym znaczeniu powinien obejmować co najmniej:
- opis celu, funkcjonalności, ograniczeń oraz przewidywalnego sposobu użycia;
- mapę przepływu danych, podstawy prawne przetwarzania, okresy retencji i ocenę jakości danych;
- dokumentację modelu, w tym wersję, dostawcę, parametry konfiguracji oraz zakres możliwych zmian;
- wyniki testów dokładności, błędów, odporności, dyskryminacji i bezpieczeństwa adekwatne do zastosowania;
- opis nadzoru człowieka, procedur eskalacji, obsługi reklamacji i możliwości odwrócenia skutków błędnej decyzji;
- rejestr zmian, incydentów, odstępstw od procedury oraz decyzji zatwierdzających.
Lista nie jest uniwersalnym formularzem. Algorytm rekomendujący produkty w sklepie internetowym nie wymaga takiej samej głębokości testów jak system wspierający ocenę ryzyka ubezpieczeniowego. Z drugiej strony choćby pozornie nieistotny mechanizm może rodzić wysokie ryzyko, gdy działa na dużą skalę, wykorzystuje dane szczególnych kategorii albo dotyka osób w słabszej pozycji negocjacyjnej.
RODO: rozliczalność wymaga śladu audytowego
W obszarze danych osobowych centralną zasadą jest rozliczalność. Administrator powinien nie tylko przestrzegać zasad przetwarzania, ale też umieć to wykazać. W przypadku algorytmów oznacza to konieczność zachowania śladu audytowego: jaka wersja systemu przetwarzała dane, jakie dane wejściowe wykorzystano, kto otrzymał wynik oraz czy i jak człowiek ingerował w decyzję.
Nie oznacza to obowiązku przechowywania każdego technicznego logu bez ograniczeń. Retencja musi być uzasadniona celem, proporcjonalna i zgodna z zasadą minimalizacji. Organizacja powinna jednak ustalić, które zdarzenia są dowodowo istotne. Zwykle będą to decyzje wpływające na prawa lub interesy osób, zmiany modeli, wyjątki od standardowej ścieżki i incydenty bezpieczeństwa.
Jeżeli wdrożenie może powodować wysokie ryzyko naruszenia praw i wolności osób fizycznych, należy przeanalizować obowiązek przeprowadzenia oceny skutków dla ochrony danych, czyli DPIA. Dokument nie powinien być kalką z poprzedniego projektu. Musi odnosić się do konkretnego celu, kategorii danych, skali przetwarzania, ryzyka błędów i środków ograniczających ryzyko. Warto przy tym powiązać DPIA z kartą systemu oraz rejestrem ryzyk, zamiast utrzymywać trzy wzajemnie sprzeczne wersje opisu tego samego narzędzia.
AI Act a dokumentacja techniczna dostawcy
W przypadku systemów wysokiego ryzyka AI Act przewiduje rozbudowane wymogi dotyczące zarządzania ryzykiem, jakości danych, dokumentacji technicznej, rejestrowania zdarzeń, przejrzystości, nadzoru człowieka oraz dokładności, odporności i cyberbezpieczeństwa. Dokumentacja techniczna ma umożliwiać ocenę zgodności systemu z wymaganiami rozporządzenia. Nie może więc ograniczać się do marketingowego opisu produktu.
Dla przedsiębiorcy korzystającego z zewnętrznego narzędzia kluczowa jest umowa z dostawcą. Należy ustalić, jakie informacje i materiały dostawca przekaże, jak będzie informował o zmianach modelu, czy umożliwi audyt, jak obsłuży incydent oraz kto ponosi odpowiedzialność za konfigurację w środowisku klienta. Brak dostępu do kodu źródłowego nie zwalnia podmiotu stosującego z udokumentowania własnej oceny i sposobu korzystania z systemu.
Szczególnej ostrożności wymagają systemy oparte na modelach ogólnego przeznaczenia. W takim przypadku część informacji o treningu lub architekturze może pozostawać poza kontrolą użytkownika. Rozsądnym rozwiązaniem jest udokumentowanie granic wiedzy organizacji, pozyskanie deklaracji i materiałów od dostawcy oraz wdrożenie testów odnoszących się do własnego przypadku użycia. Nie należy udawać pełnej wyjaśnialności, jeżeli dostawca jej nie zapewnia.
Dokumentacja musi działać po wdrożeniu
Największą wartość mają dokumenty, które aktualizują się wraz z produktem. Warto połączyć proces compliance z cyklem wytwórczym: wymagać oceny ryzyka przed wdrożeniem, zatwierdzenia przed produkcją, rejestru zmian przy każdej istotnej modyfikacji oraz okresowego przeglądu po uruchomieniu.
Dobrą praktyką jest wyznaczenie właściciela każdego systemu oraz ustalenie, kto odpowiada za dane, cyberbezpieczeństwo, ocenę prawną i decyzję biznesową. Rozproszona odpowiedzialność często prowadzi do sytuacji, w której każdy dział zakłada, iż dokumentację prowadzi ktoś inny. Governance działa dopiero wtedy, gdy obowiązki są przypisane do konkretnych ról, terminów i kryteriów akceptacji.
Należy też rozdzielić dokumenty przeznaczone dla organu, użytkownika, audytora i zespołu technicznego. Przejrzystość wobec osoby, której dotyczy decyzja, nie wymaga ujawnienia tajemnicy przedsiębiorstwa ani pełnej specyfikacji modelu. Nie może jednak być pozorna. Osoba powinna otrzymać zrozumiałą informację o tym, iż system jest używany, jakie ma znaczenie dla sprawy oraz jak może zakwestionować wynik, gdy jest to wymagane przez prawo lub uzasadnione charakterem procesu.
W praktyce najlepszym testem dokumentacji jest proste pytanie: czy niezależna osoba, która nie uczestniczyła w projekcie, potrafi po kilku miesiącach odtworzyć podstawę działania systemu i ocenić, czy przez cały czas wolno go używać w tym samym celu? o ile odpowiedź brzmi „nie”, organizacja nie ma jeszcze dokumentacji zgodności, ale jedynie zbiór plików.
