W drugiej części artykułu omówiono relacje między obowiązkiem współpracy przedsiębiorcy z organem nadzoru a ochroną tajemnicy przedsiębiorstwa oraz komunikacji z profesjonalnym pełnomocnikiem. Poufny charakter informacji nie wyłącza sam przez się obowiązku ich przekazania, ale wpływa na zakres i sposób ingerencji organu. Szczególnego znaczenia zasada ta nabiera w przypadku najbardziej wrażliwych elementów technologii AI.
Najbardziej spektakularnym uprawnieniem organu jest możliwość uzyskania dostępu do kodu źródłowego systemu wysokiego ryzyka. Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2024/1689 z 13.6.2024 r. w sprawie ustanowienia zharmonizowanych przepisów dotyczących sztucznej inteligencji oraz zmiany rozporządzeń (WE) nr 300/2008, (UE) nr 167/2013, (UE) nr 168/2013, (UE) 2018/858, (UE) 2018/1139 i (UE) 2019/2144 oraz dyrektyw 2014/90/UE, (UE) 2016/797 i (UE) 2020/1828 (akt w sprawie sztucznej inteligencji) (Dz.Urz. UE L z 2024 r., s. 168; dalej: AIAct) podchodzi jednak do tego instrumentu ze szczególną ostrożnością.
Zgodnie z art. 74 ust. 13 AIAct organ nadzoru rynku uzyskuje dostęp do kodu źródłowego na podstawie uzasadnionego żądania i wyłącznie wtedy, gdy łącznie spełnione są dwa warunki. Po pierwsze, dostęp do kodu musi być konieczny do oceny zgodności systemu AI wysokiego ryzyka z wymaganiami rozdziału III sekcji 2 AIAct, a więc przede wszystkim art. 8–15 AIAct. Po drugie, procedury testowania, audytu i weryfikacji przeprowadzone na podstawie danych i dokumentacji dostarczonych przez dostawcę musiały zostać wcześniej wyczerpane albo okazać się niewystarczające. Nie jest to zatem zwykłe uprawnienie informacyjne.
Kod źródłowy został przez prawodawcę unijnego objęty swoistą zasadą ultima ratio. Sekwencja postępowania powinna wyglądać zasadniczo następująco: dokumentacja – dane – testowanie lub audyt – weryfikacja – dopiero w razie niewystarczalności tych środków dostęp do kodu. Z tego względu żądanie kodu źródłowego skierowane już na początku kontroli powinno wymagać szczególnie starannego uzasadnienia. Organ powinien wykazać nie tylko związek kodu z przedmiotem kontroli, ale również spełnienie obu przesłanek z art. 74 ust. 13 AIAct. Warto przy tym zwrócić uwagę, że art. 78 ust. 1 lit. a AIAct wymienia kod źródłowy expressis verbis wśród informacji, których poufność powinna być chroniona. Jest to jednoznaczny sygnał, że prawodawca dostrzega jego szczególną wartość gospodarczą.
Kod źródłowy nie zawsze odpowie na pytanie organu
Z technicznego punktu widzenia istnieje dodatkowa trudność. W przypadku nowoczesnych systemów AI wgląd w sam kod źródłowy może mieć znacznie mniejszą wartość wyjaśniającą niż w przypadku klasycznego oprogramowania.
Zachowanie modelu może zależeć przede wszystkim od danych treningowych, wag modelu, procesu fine-tuningu, warstwy systemowych instrukcji, mechanizmów retrieval-augmented generation, konfiguracji bezpieczeństwa, parametrów inferencji lub sposobu integracji systemu z procesem biznesowym. Z tego względu art. 74 ust. 12 AIAct jest w praktyce co najmniej równie ważny jak art. 74 ust. 13 AIAct. Organ uzyskuje dostęp nie tylko do dokumentacji, ale również do zbiorów treningowych, walidacyjnych i testowych, a w odpowiednich przypadkach poprzez API lub inne narzędzia umożliwiające zdalne badanie systemu. Prowadzi to do istotnego wniosku praktycznego: przedmiotem kontroli nie będzie „algorytm” rozumiany jako jeden artefakt, lecz cały ekosystem dowodów zgodności systemu AI.
Znaczenie mogą mieć repozytoria kodu, ale równie istotne mogą być dataset cards, model cards, logi zmian, historia wersji, raporty walidacyjne, rejestry incydentów, dokumentacja wyboru danych, wyniki testów bias, dokumentacja nadzoru człowieka czy raporty z monitorowania po wprowadzeniu systemu do obrotu.
Dane treningowe i tajemnice osób trzecich
Szczególnie problematyczny może być obowiązek udostępnienia zbiorów danych.
Po pierwsze, zbiory treningowe, walidacyjne i testowe mogą same stanowić tajemnicę przedsiębiorstwa. Ich zebranie, oczyszczenie, anotacja lub struktura mogą wymagać znacznych inwestycji i stanowić źródło przewagi konkurencyjnej.
Po drugie, przedsiębiorca nie zawsze jest właścicielem wszystkich informacji zawartych w zbiorze. Dane mogą pochodzić od kontrahentów, dostawców danych, klientów lub innych uczestników łańcucha dostaw AI.
Po trzecie, mogą zawierać dane osobowe.
Obowiązek współpracy z organem nie może więc być analizowany wyłącznie z perspektywy relacji Komisja – kontrolowany. Udostępnienie materiałów może oddziaływać na prawa wielu innych podmiotów. AIAct dostrzega złożoność łańcucha wartości AI również w innych przepisach. Art. 25 AIAct reguluje odpowiedzialność podmiotów uczestniczących w łańcuchu wartości, natomiast motywy rozporządzenia wielokrotnie podkreślają konieczność zapewnienia wymiany informacji potrzebnej dla zachowania zgodności przy jednoczesnym poszanowaniu praw własności intelektualnej i tajemnic przedsiębiorstwa. Z perspektywy przedsiębiorcy szczególnego znaczenia nabierają zatem umowy z dostawcami technologii. Klauzula stanowiąca jedynie, że „strony zachowują informacje w poufności”, może być niewystarczająca. Umowa powinna umożliwiać wykonanie prawnego obowiązku przekazania określonych informacji regulatorowi, określać procedurę powiadomienia dostawcy oraz wskazywać sposób współpracy przy żądaniach dotyczących technologii lub dokumentacji należącej do podmiotu trzeciego.
NDA nie może zablokować regulatora
Przedsiębiorca nie może skutecznie przeciwstawić Komisji Rozwoju i Bezpieczeństwa Sztucznej Inteligencji postanowienia umownego, zgodnie z którym zobowiązał się wobec kontrahenta do nieujawniania informacji. Umowa prywatnoprawna nie może wyłączyć obowiązku wynikającego z bezpośrednio stosowanego AIAct albo ustawy.
Nie oznacza to jednak, że umowa o zachowaniu poufności (NDA) pozostaje bez znaczenia. Przeciwnie – może być istotnym dowodem wskazującym, że podmiot podejmował działania wymagane przez art. 11 ust. 2 ustawy z 16.4.1993 r. o zwalczaniu nieuczciwej konkurencji (t.j. Dz.U. z 2026 r. poz. 85) dla utrzymania określonych informacji w poufności. Dobre NDA powinno również przewidywać wyjątek dotyczący ujawnienia wymaganego prawem lub wiążącym żądaniem organu, połączony – gdy jest to prawnie dopuszczalne – z obowiązkiem poinformowania właściciela informacji i podjęcia środków pozwalających ograniczyć zakres ujawnienia.
Dane osobowe – doświadczenia z kontroli RODO
Drugą warstwą problemu jest ochrona danych osobowych. Kontrola systemu AI może prowadzić do udostępnienia Komisji danych znajdujących się w zbiorach treningowych, logach, historii zapytań, zapisach działania operatorów lub wynikach generowanych przez system.
Sam fakt, że materiały zawierają dane osobowe, nie wyłącza możliwości ich przekazania właściwemu organowi. Przetwarzanie odbywające się w wykonaniu obowiązku prawnego lub w ramach kompetencji władzy publicznej posiada odrębne podstawy prawne.
Nie oznacza to jednak, że RODO przestaje mieć zastosowanie. W szczególności nadal istotne pozostają zasady celowości, minimalizacji, ograniczenia przechowywania, integralności i poufności z art. 5 ust. 1 RODO. W podobnym kierunku zmierza zresztą art. 78 ust. 2 AIAct, wymagający, aby organ żądał wyłącznie danych ściśle koniecznych oraz usuwał zebrane dane, gdy przestają być niezbędne dla celu, w którym zostały uzyskane.
Doświadczenie stosowania RODO może być tutaj szczególnie wartościowe. W praktyce kontroli ochrony danych od dawna występuje problem przekazywania organowi materiałów zawierających zarówno dane osobowe, jak i informacje poufne przedsiębiorstwa lub jego kontrahentów. AIAct przenosi ten problem na znacznie bardziej techniczny poziom.
W RODO przedmiotem kontroli często była baza danych i proces jej przetwarzania. W AIAct przedmiotem kontroli może być jednocześnie baza, model, kod, proces decyzyjny i dokumentacja organizacyjna.
Logi jako centralny materiał dowodowy
Szczególną rolę w kontroli mogą odgrywać logi. Art. 12 AIAct wymaga, aby systemy wysokiego ryzyka technicznie umożliwiały automatyczne rejestrowanie zdarzeń w okresie ich działania. Art. 19 AIAct nakłada z kolei na dostawców obowiązek przechowywania automatycznie generowanych logów pozostających pod ich kontrolą przez okres odpowiedni do przeznaczenia systemu, co najmniej przez sześć miesięcy, chyba że inne przepisy przewidują inaczej. Odpowiednie obowiązki dotyczą także podmiotów stosujących – art. 26 AIAct.
Logi mogą pozwolić organowi odtworzyć rzeczywiste zachowanie systemu, sposób jego wykorzystania, przypadki interwencji człowieka, błędy, anomalie lub zdarzenia wpływające na bezpieczeństwo.
Jednocześnie log może zawierać niezwykle szeroki zakres informacji: dane osobowe, treść zapytań klientów, informacje o pracownikach, nazwy kontrahentów, parametry infrastruktury, identyfikatory techniczne czy fragmenty informacji poufnych.
Dlatego możliwość uzyskania dostępu do logów nie powinna automatycznie oznaczać prawa do pozyskania całej historii działania systemu. Także tutaj obowiązuje art. 78 ust. 2 AIAct. Jeżeli przedmiot kontroli może zostać zweryfikowany na podstawie logów z konkretnego okresu, określonej klasy zdarzeń albo określonych pól, żądanie pełnego eksportu logów za kilka lat może być nieproporcjonalne.
Ochrona tajemnicy przedsiębiorstw
Praktycznym problemem charakterystycznym dla współczesnych systemów AI jest to, że kontrolowany podmiot nie zawsze jest właścicielem technologii.
Podmiot stosujący może korzystać z systemu SaaS dostarczanego przez zewnętrzną spółkę. Dostawca aplikacji może wykorzystywać model ogólnego przeznaczenia pochodzący od jeszcze innego podmiotu. Model może działać w infrastrukturze chmurowej kolejnego kontrahenta. Powstaje więc łańcuch, w którym informacje potrzebne do kontroli znajdują się u kilku podmiotów i mogą stanowić tajemnicę każdego z nich.
AIAct częściowo odpowiada na ten problem. Art. 75 ust. 3 AIAct przewiduje mechanizm współpracy z AI Office w sytuacji, gdy krajowy organ nadzoru nie może zakończyć badania systemu wysokiego ryzyka z uwagi na brak dostępu do informacji dotyczących modelu ogólnego przeznaczenia. Organ może wówczas skierować uzasadnione żądanie do AI Office, które zapewnia dostęp do informacji istotnych dla oceny zgodności. Jest to kolejny argument przeciwko koncepcji, zgodnie z którą kontrolowany powinien za wszelką cenę sam pozyskać od kontrahenta i ujawnić organowi całość jego technologicznego know-how. System nadzoru przewiduje mechanizmy współpracy pomiędzy regulatorami właśnie dlatego, że współczesny łańcuch AI jest wielopodmiotowy.
W czwartej części artykułu
Granice uprawnień organu to tylko jedna strona kontroli. Równie istotne jest odpowiednie przygotowanie przedsiębiorcy do reagowania na żądania dotyczące poufnych danych i technologii. W ostatniej części artykułu przedstawione zostaną zasady stopniowania ingerencji, sposób reakcji na żądanie Komisji oraz rozwiązania organizacyjne, które pozwalają przygotować przedsiębiorstwo do kontroli systemu AI jeszcze przed jej wszczęciem.
Kontrola systemu AI a tajemnica przedsiębiorstwa:
dr Mirosław Sanek – Lider Działu RODO w kancelarii MKZPartnerzy, ekspert z zakresu ochrony danych osobowych, compliance oraz cyfrowej transformacji. Pełnił funkcję zastępcy Prezesa Urzędu Ochrony Danych Osobowych.
Artykuł pochodzi z Systemu Legalis. Bądź na bieżąco, polub nas na Facebooku →
