AI Act trafia do mapy produktu. Najpierw inwentarz, potem dokumentacja

Najbardziej kosztowny moment wdrażania przepisów o sztucznej inteligencji zaczyna się zwykle od prostego pytania: gdzie dokładnie w naszym produkcie działa model? Odpowiedź rzadko mieści się w jednym repozytorium. AI może podpowiadać tekst w panelu, klasyfikować zgłoszenia, ustalać kolejność ofert, oceniać ryzyko nadużycia albo działać w usłudze kupionej od zewnętrznego dostawcy. Jeżeli organizacja nie ma wspólnego inwentarza, nie potrafi nawet ustalić, co wymaga dalszej oceny.

Unijny AI Act obowiązuje etapami. Komisja Europejska i oficjalny AI Act Service Desk publikują harmonogram, który trzeba czytać razem z rolą organizacji i zastosowaniem systemu. Inne obowiązki dotyczą dostawcy modelu, inne podmiotu wdrażającego, importera lub dystrybutora. Część zasad już ma zastosowanie, a kolejne elementy są rozłożone w czasie. Dlatego jedno zdanie w prezentacji, że firma jest zgodna z AI Act, mówi niewiele bez daty, zakresu i wskazania konkretnego systemu.

Inwentarz musi opisywać funkcję, nie tylko nazwę modelu

Lista modeli jest za wąska. Potrzebna jest lista przypadków użycia. Ten sam model językowy może tworzyć robocze podsumowanie dla pracownika albo automatycznie wpływać na decyzję o człowieku. Ryzyko i wymagane zabezpieczenia nie wynikają wyłącznie z nazwy technologii. Zależą od celu, danych wejściowych, użytkownika, odbiorcy wyniku i tego, co dzieje się po jego wygenerowaniu.

Praktyczny rekord inwentarza powinien zawierać właściciela biznesowego i technicznego, wersję modelu, dostawcę, miejsce przetwarzania danych, planowane zastosowanie, zakazane zastosowania, grupy osób dotkniętych wynikiem oraz ścieżkę wyłączenia funkcji. Trzeba też zapisać, czy człowiek widzi wynik przed działaniem i czy ma realne uprawnienie, aby go odrzucić. Sam przycisk zatwierdź nie tworzy sensownego nadzoru, jeśli pracownik nie ma czasu, informacji lub prawa do sprzeciwu.

Dokumentacja powinna podróżować razem ze zmianą produktu

Zespoły często przygotowują dokument zgodności raz, a później rozwijają produkt przez wiele miesięcy. Model dostaje nowe dane, dostawca zmienia wersję, funkcja trafia do innej grupy użytkowników, a próg automatycznej decyzji zostaje przesunięty. Papier zachowuje dawny opis, chociaż działający system jest już inny. Właśnie dlatego obowiązki regulacyjne zaczynają przypominać zwykłe zarządzanie wersją, testami i zmianą zakresu.

Każdy istotny wpis w mapie produktu powinien mieć powiązanie z dowodami. Mogą to być wyniki testów jakości i błędów, analiza danych, opis ograniczeń, scenariusze nadużyć, log zmian, instrukcja dla operatora i plan monitoringu po uruchomieniu. Dokumentacja nie ma udowadniać, że system jest nieomylny. Ma pokazać, jakie pytania zadano, jakie ograniczenia znaleziono i kto podejmuje decyzję, gdy wynik przestaje być wiarygodny.

Etykieta wysokiego ryzyka nie powinna być zgadywanką

AI Act opiera się na podejściu zależnym od ryzyka, ale kategorie z rozporządzenia nie są prostymi nazwami funkcji w backlogu. Zespół produktu nie powinien samodzielnie przypinać etykiety niskiego ryzyka tylko dlatego, że system jest pomocniczy w interfejsie. Jeżeli jego wynik wpływa na zatrudnienie, dostęp do ważnej usługi, edukację, bezpieczeństwo lub inne obszary wskazane w przepisach, konieczna jest dokładna ocena z udziałem prawników, ekspertów domenowych i osób odpowiedzialnych za ochronę danych.

Równie niebezpieczna jest druga skrajność, czyli uznanie każdego generatora tekstu za system wysokiego ryzyka. Nadmierna klasyfikacja zużywa uwagę i może ukryć funkcje naprawdę wrażliwe. Lepszy proces zapisuje przesłanki, niepewności i źródła, a następnie wraca do oceny po zmianie zastosowania. Oficjalny harmonogram i materiały Komisji są punktem wyjścia, nie automatycznym orzeczeniem dla konkretnego produktu.

Dostawca modelu nie przejmuje całej odpowiedzialności

Umowa z dużym dostawcą może dać dokumentację techniczną, opis bezpieczeństwa i warunki użycia. Nie opisze jednak w pełni lokalnego procesu. To organizacja wdrażająca wie, jakie dane trafiają do systemu, jak pracownik rozumie podpowiedź, jaki skutek wywołuje błąd i czy użytkownik potrafi zakwestionować rezultat. Ocena dostawcy i ocena wdrożenia są dwiema częściami tej samej kontroli.

• Zapisz wszystkie użycia AI, również narzędzia kupione przez marketing, HR, obsługę klienta i analitykę.
• Dla każdego użycia określ cel, właściciela, dane, odbiorcę wyniku, skutek błędu i sposób wyłączenia.
• Połącz rekord z testami, ograniczeniami, instrukcją operatora, monitoringiem i procedurą zgłaszania incydentów.
• Ustal zdarzenia wymagające ponownej oceny: nowa wersja modelu, nowa grupa użytkowników, nowe dane lub automatyzacja kolejnego kroku.
• Sprawdź aktualny harmonogram i interpretację z właściwym zespołem prawnym przed premierą, nie dopiero po niej.

Mapa produktu staje się mapą odpowiedzialności

Najbardziej użytecznym skutkiem regulacji może być nie kolejny formularz, lecz koniec anonimowej funkcji AI. Gdy każdy przypadek użycia ma właściciela, opis ograniczeń, wersję, testy i procedurę zatrzymania, łatwiej zarządzać także zwykłym ryzykiem jakościowym. Produkt nie musi czekać na audyt, aby wiedzieć, kto ma zareagować na nagły wzrost błędów.

To nie znaczy, że zgodność da się zamknąć w pięciu polach w systemie zadań. AI Act jest aktem prawnym, a jego zastosowanie zależy od faktów. Dobra mapa produktu robi jednak coś ważnego: zamienia rozproszoną dyskusję w zestaw możliwych do sprawdzenia dowodów. Dzięki temu decyzja o wydaniu funkcji uwzględnia nie tylko to, czy model działa, ale też czy organizacja potrafi wyjaśnić jego rolę, ograniczenia i odpowiedzialność za wynik.