AI Act w organizacji: kluczowe założenia, obowiązki prawne, kategorie systemów AI i harmonogram wdrożenia

Czym jest AI Act i dlaczego ma znaczenie dla organizacji

AI Act to unijne rozporządzenie ustanawiające wspólne zasady dotyczące sztucznej inteligencji — formalnie rozporządzenie Parlamentu Europejskiego i Rady (UE) 2024/1689. Określa warunki wprowadzania systemów AI do obrotu, oddawania ich do użytku oraz wykorzystywania. Jego celem jest ochrona zdrowia, bezpieczeństwa i praw podstawowych, przy jednoczesnym wspieraniu rozwoju godnej zaufania sztucznej inteligencji. Nie jest dobrowolnym standardem ani zbiorem zaleceń etycznych. Jako rozporządzenie jest bezpośrednio stosowane w państwach UE, choć poszczególne przepisy zaczynają być stosowane etapami.

Znaczenie tej regulacji wykracza poza branżę technologiczną. Organizacja nie musi tworzyć własnej sztucznej inteligencji, aby podlegać AI Act. Przepisy mogą dotyczyć również przedsiębiorstwa lub instytucji korzystającej z gotowego narzędzia, usługi chmurowej czy funkcji AI udostępnionej w już używanym oprogramowaniu. Zakup rozwiązania od zewnętrznego dostawcy nie oznacza więc, że ocena zgodności pozostaje wyłącznie po jego stronie. Jednocześnie sam fakt korzystania z AI nie powoduje, że każdą organizację obejmuje identyczny zestaw wymagań.

Podstawowe znaczenie ma ustalenie, czym w rozumieniu rozporządzenia jest system AI. To system maszynowy zaprojektowany do działania z różnym poziomem autonomii, który na podstawie otrzymanych danych wejściowych wnioskuje, jak generować wyniki — na przykład predykcje, treści, zalecenia lub decyzje wpływające na środowisko fizyczne albo wirtualne. Może również wykazywać zdolność adaptacji po wdrożeniu, ale nie jest to warunek konieczny. Definicja nie ogranicza się zatem do chatbotów i narzędzi generujących tekst. Nie obejmuje też automatycznie każdego programu wykonującego obliczenia lub automatyzującego zadania.

W ocenie zakresu regulacji rekomendujemy kierować się rzeczywistym sposobem działania rozwiązania, a nie wyłącznie jego nazwą handlową czy deklaracją marketingową producenta. Istotne są także przeznaczenie systemu, kontekst jego wykorzystania i rola organizacji. AI Act opiera się przede wszystkim na podejściu uwzględniającym ryzyko: wymagania są różnicowane zależnie od potencjalnego wpływu zastosowania AI na ludzi. Nie należy więc utożsamiać poziomu zaawansowania technologicznego narzędzia z poziomem ryzyka prawnego.

Z perspektywy zarządu AI Act ma znaczenie dla wyboru technologii, budżetowania projektów i dopuszczalności określonych zastosowań. Dla zespołów prawnych, compliance, ochrony danych i IT stanowi wspólny punkt odniesienia do oceny, na jakich warunkach organizacja może korzystać z danego rozwiązania. Rekomendujemy traktować tę regulację jako zagadnienie zarządcze, a nie wyłącznie techniczne: korzyści z automatyzacji trzeba oceniać łącznie z wpływem na pracowników, klientów i inne osoby. Pozwala to ograniczyć ryzyko inwestowania w rozwiązania, których zamierzony sposób wykorzystania okaże się niedopuszczalny lub będzie wymagał istotnych zmian organizacyjnych.

Klasyfikacja systemów AI: zakazane, wysokiego ryzyka i pozostałe (z przykładami)

O kwalifikacji systemu AI nie decyduje sama technologia ani nazwa produktu, lecz przede wszystkim jego przeznaczenie i kontekst zastosowania. Narzędzie wspierające redagowanie ogłoszeń o pracę należy oceniać inaczej niż rozwiązanie analizujące CV i szeregujące kandydatów. Dlatego rekomendujemy klasyfikowanie konkretnych zastosowań, a nie przypisywanie jednej kategorii wszystkim narzędziom AI wykorzystywanym w organizacji.

Podstawę oceny stanowią przede wszystkim art. 5, 6 i 50 oraz załączniki I i III do rozporządzenia (UE) 2024/1689, czyli AI Act. Praktyczny podział obejmuje zakazane praktyki, systemy wysokiego ryzyka oraz pozostałe rozwiązania. W tej ostatniej grupie trzeba dodatkowo rozróżnić zastosowania objęte szczególnymi wymogami przejrzystości i te, których takie wymogi nie dotyczą.

Zakazane praktyki AI — zastosowania uznane za niedopuszczalne. Prawnie precyzyjniej jest mówić o zakazanych praktykach niż o „zakazanych systemach”: zakaz dotyczy określonego sposobu wykorzystania AI. Przykładem jest wnioskowanie o emocjach pracowników na podstawie danych biometrycznych w miejscu pracy, z wyjątkiem zastosowań uzasadnionych względami medycznymi lub bezpieczeństwa. Do tej grupy należy również nieukierunkowane pozyskiwanie wizerunków twarzy z internetu lub nagrań monitoringu w celu tworzenia albo rozbudowy baz danych służących rozpoznawaniu twarzy. Nie są to zastosowania, które można dopuścić wyłącznie przez ustanowienie dodatkowego nadzoru.

Systemy AI wysokiego ryzyka — dozwolone, lecz podlegające zaostrzonym wymaganiom. Do tej kategorii prowadzą dwie główne ścieżki. Pierwsza obejmuje AI będącą produktem lub elementem bezpieczeństwa produktu objętego przepisami wskazanymi w załączniku I, jeżeli produkt wymaga oceny zgodności przez stronę trzecią. Przykładem może być oprogramowanie diagnostyczne będące wyrobem medycznym, o ile spełnia te warunki. Druga ścieżka dotyczy zastosowań wymienionych w załączniku III, m.in. w rekrutacji, edukacji i dostępie do określonych usług.

Typowe przykłady z drugiej grupy to AI oceniająca kandydatów do pracy, system oceny zdolności kredytowej osób fizycznych oraz rozwiązanie decydujące o przyjęciu do instytucji edukacyjnej. Nie każde narzędzie używane przez dział HR, bank czy szkołę jest jednak automatycznie systemem wysokiego ryzyka. Znaczenie ma konkretna funkcja. Art. 6 ust. 3 przewiduje ograniczone wyłączenie dla niektórych systemów z załącznika III, które nie stwarzają znaczącego ryzyka, w tym nie wpływają istotnie na wynik decyzji. Nie można jednak z niego korzystać, jeżeli system objęty tym załącznikiem profiluje osoby fizyczne.

Pozostałe systemy objęte wymogami przejrzystości — istotne jest ujawnienie udziału AI. Przykładem jest chatbot obsługi klienta, który odpowiada na pytania o ofertę. Co do zasady osoba korzystająca z takiego rozwiązania powinna wiedzieć, że rozmawia z AI, chyba że wynika to w sposób oczywisty z okoliczności. Szczególne wymogi dotyczą również treści syntetycznych, w tym deepfake’ów, czyli wygenerowanych lub zmanipulowanych materiałów przypominających autentyczne osoby, obiekty lub zdarzenia. Przejrzystość nie stanowi przy tym odrębnej, rozłącznej kategorii ryzyka: odpowiednie wymogi mogą dotyczyć także systemów wysokiego ryzyka.

Pozostałe zastosowania, często określane jako minimalnego ryzyka. Mogą to być filtry antyspamowe lub narzędzia prognozujące zapotrzebowanie na zapasy, jeżeli ich funkcje nie spełniają przesłanek kategorii regulowanych szczególnie. Określenie „minimalne ryzyko” ma charakter opisowy — nie oznacza braku wszelkich obowiązków prawnych ani braku ryzyka biznesowego.

Osobno należy odróżnić model AI ogólnego przeznaczenia (GPAI) od systemu wykorzystującego taki model. Model zdolny do wykonywania wielu różnych zadań może stanowić podstawę zarówno asystenta redakcyjnego, jak i rozwiązania do oceny kandydatów. Sam fakt wykorzystania generatywnej AI nie przesądza więc o kategorii ryzyka gotowego systemu.

3. Zakazane praktyki AI: ryzyka, konsekwencje i praktyczne scenariusze

Zakazanej praktyki AI nie można zalegalizować samą zgodą osoby, nadzorem człowieka ani dodatkową dokumentacją. Jeżeli zastosowanie spełnia przesłanki zakazu określonego w art. 5 rozporządzenia w sprawie sztucznej inteligencji i nie mieści się w przewidzianym prawem wyjątku, organizacja musi z niego zrezygnować. Rekomendujemy zatem ocenę konkretnej funkcji i sposobu jej wykorzystania, a nie wyłącznie nazwy produktu czy deklarowanej przez dostawcę kategorii ryzyka.

Rozpoznawanie emocji pracowników lub uczestników edukacji. Przykładowy scenariusz to narzędzie analizujące obraz z kamer podczas spotkań, aby przypisywać pracownikom frustrację, entuzjazm lub znudzenie. Wnioskowanie o emocjach na podstawie danych biometrycznych w miejscu pracy i instytucjach edukacyjnych jest co do zasady zakazane. Wyjątki dotyczą względów medycznych lub bezpieczeństwa — nie zwykłej oceny produktywności czy jakości obsługi. Należy przy tym odróżniać takie rozwiązania od analizy wydźwięku tekstowych ankiet: nie każda analiza opinii jest rozpoznawaniem emocji w rozumieniu AI Act.

Manipulacja oraz wykorzystywanie podatności na zagrożenia. Ryzykowny scenariusz to asystent sprzedażowy, który wykorzystuje trudną sytuację ekonomiczną klienta, aby skłonić go do zobowiązania grożącego poważną szkodą finansową. AI Act obejmuje zakazem określone techniki podprogowe, celowo manipulacyjne lub wprowadzające w błąd, a także wykorzystywanie podatności wynikającej z wieku, niepełnosprawności lub szczególnej sytuacji społecznej bądź ekonomicznej. Nie każda personalizacja lub perswazja jest jednak zakazana. Znaczenie mają ustawowe przesłanki dotyczące istotnego zniekształcenia zachowania oraz spowodowania lub uzasadnionego prawdopodobieństwa spowodowania poważnej szkody; przy technikach manipulacyjnych istotne jest również ograniczenie zdolności do świadomego podjęcia decyzji.

Scoring społeczny prowadzący do nieuzasadnionego gorszego traktowania. Wyobraźmy sobie system, który przez dłuższy czas ocenia zachowania pracowników poza pracą i na tej podstawie ogranicza im dostęp do świadczeń pracowniczych. Zakaz może znaleźć zastosowanie, gdy ocena osób lub grup na podstawie zachowania społecznego albo znanych, wywnioskowanych czy przewidywanych cech osobistych prowadzi do krzywdzącego lub niekorzystnego traktowania w niezwiązanym kontekście. Obejmuje także takie traktowanie, które jest nieuzasadnione lub nieproporcjonalne wobec zachowania i jego wagi. Nie oznacza to zakazu każdego systemu punktowego — decydują podstawa oceny, kontekst i skutki jej wykorzystania.

Tworzenie baz rozpoznawania twarzy i wnioskowanie o cechach wrażliwych. Niedopuszczalne jest tworzenie lub rozbudowywanie baz danych służących rozpoznawaniu twarzy przez nieukierunkowane pozyskiwanie wizerunków z internetu lub nagrań monitoringu. Publiczna dostępność zdjęcia nie usuwa tego zakazu. Osobny zakaz dotyczy kategoryzacji biometrycznej osób w celu wywnioskowania m.in. ich poglądów politycznych, przynależności związkowej, przekonań religijnych lub orientacji seksualnej. Przykładem byłoby narzędzie przypisujące klientom takie cechy na podstawie wyglądu twarzy w celu segmentacji odbiorców. Wąskich wyłączeń przewidzianych w przepisach nie należy traktować jako ogólnego zezwolenia na podobne analizy.

Katalog obejmuje również ocenę ryzyka popełnienia przestępstwa opartą wyłącznie na profilowaniu osoby lub ocenie jej cech osobowości. Należy ją odróżnić od dopuszczonego pod określonymi warunkami wspierania oceny człowieka opartej na obiektywnych, sprawdzalnych faktach bezpośrednio związanych z działalnością przestępczą. Szczególne ograniczenia dotyczą też zdalnej identyfikacji biometrycznej w czasie rzeczywistym w przestrzeni publicznej do celów ścigania przestępstw. Przewidziane tu wyjątki są ściśle określone i obwarowane dodatkowymi warunkami; nie stanowią ogólnej podstawy do wdrażania rozpoznawania twarzy.

Konsekwencje wykraczają poza karę finansową. Za naruszenie zakazów z art. 5 AI Act przewiduje administracyjne kary do 35 mln euro, a w przypadku przedsiębiorstwa — do 7% całkowitego rocznego światowego obrotu z poprzedniego roku obrotowego, przy zastosowaniu wyższego limitu. Dla MŚP, w tym przedsiębiorstw typu start-up, obowiązuje niższy z tych dwóch limitów. Są to pułapy maksymalne, a nie automatyczna wysokość kary. Organizacja musi ponadto uwzględnić ryzyko nakazu zaprzestania praktyki, kosztów zmiany rozwiązania, roszczeń osób poszkodowanych oraz utraty zaufania pracowników i klientów.

W naszej ocenie najważniejsza granica decyzyjna jest prosta: brak zakazu nie oznacza jeszcze pełnej zgodności, ale stwierdzony zakaz wyklucza dane zastosowanie. Zapewnienie dostawcy, że narzędzie jedynie „wspiera decyzje”, nie wystarcza, jeśli jego rzeczywista funkcja odpowiada zakazanej praktyce. W razie takiego podejrzenia rekomendujemy wstrzymanie wykorzystania spornej funkcjonalności do czasu wyjaśnienia jej kwalifikacji prawnej.

4. Obowiązki prawne przy wdrażaniu i wykorzystywaniu AI: kto za co odpowiada (dostawca vs użytkownik)

Zakup systemu AI nie przenosi całej odpowiedzialności za jego wykorzystanie na dostawcę. AI Act rozdziela obowiązki według roli organizacji, kategorii systemu oraz jego przeznaczenia. Rekomendujemy więc odróżniać zgodność samego rozwiązania od zgodności sposobu, w jaki firma wykorzystuje je w swoim procesie. Zapewnienie producenta, że narzędzie spełnia wymagania rozporządzenia, nie zastępuje oceny obowiązków po stronie organizacji.

Dostawca a podmiot stosujący — najważniejsze rozróżnienie

Dostawcą jest podmiot, który opracowuje system AI lub zleca jego opracowanie, a następnie wprowadza go do obrotu albo oddaje do użytku pod własną nazwą lub znakiem towarowym. Nie musi to być zatem firma sprzedająca oprogramowanie: organizacja tworząca rozwiązanie na własne potrzeby również może pełnić tę rolę. Z kolei podmiot stosujący, określany po angielsku jako deployer, wykorzystuje system pod swoją kontrolą, poza osobistą działalnością pozazawodową. W kontekście firmowym „użytkownikiem” jest więc zazwyczaj organizacja, a nie wyłącznie pracownik obsługujący narzędzie. Jedna organizacja może być jednocześnie dostawcą i podmiotem stosującym.

Za co odpowiada dostawca systemu wysokiego ryzyka?

Najszerszy zestaw obowiązków dotyczy dostawców systemów wysokiego ryzyka. Obejmuje zapewnienie zgodności z wymaganiami dotyczącymi m.in. zarządzania ryzykiem, danych, dokumentacji technicznej, rejestrowania zdarzeń, nadzoru człowieka, dokładności, odporności i cyberbezpieczeństwa. Dostawca musi również posiadać system zarządzania jakością, przeprowadzić właściwą ocenę zgodności, sporządzić deklarację zgodności UE oraz zapewnić oznakowanie CE i rejestrację w zakresie wymaganym przepisami. Obowiązki nie kończą się na wdrożeniu: obejmują także monitorowanie po wprowadzeniu do obrotu, działania naprawcze oraz zgłaszanie poważnych incydentów.

Za co odpowiada organizacja stosująca system wysokiego ryzyka?

Podmiot stosujący ma zapewnić korzystanie z systemu zgodnie z instrukcją oraz powierzyć nadzór osobom posiadającym odpowiednie kompetencje, przeszkolenie i uprawnienia. Jeżeli kontroluje dane wejściowe, powinien zapewnić ich adekwatność i wystarczającą reprezentatywność względem przeznaczenia systemu. Do jego obowiązków należą również monitorowanie działania i przechowywanie automatycznie generowanych rejestrów zdarzeń pozostających pod jego kontrolą — co do zasady przez co najmniej sześć miesięcy, chyba że właściwe przepisy stanowią inaczej. W sytuacjach wskazanych w rozporządzeniu konieczne są powiadomienia o ryzyku lub poważnym incydencie, a także zawieszenie stosowania systemu.

Dodatkowe wymagania zależą od kontekstu. Przykładowo pracodawca przed wykorzystaniem systemu wysokiego ryzyka w miejscu pracy musi poinformować przedstawicieli pracowników oraz pracowników, których system będzie dotyczył. Wybrane podmioty stosujące mają również obowiązek przeprowadzenia oceny wpływu na prawa podstawowe. Nie jest to jednak obowiązek każdej firmy korzystającej z AI.

Kiedy użytkownik przejmuje obowiązki dostawcy?

AI Act przewiduje taką zmianę roli m.in. przy istotnej modyfikacji systemu wysokiego ryzyka albo zmianie przeznaczenia systemu, która powoduje zakwalifikowanie go jako systemu wysokiego ryzyka. Znaczenie może mieć również oznaczenie istniejącego systemu wysokiego ryzyka własną nazwą lub znakiem towarowym. Nie każda konfiguracja narzędzia oznacza zmianę roli, jednak dostosowanie rozwiązania do nowego procesu wymaga oceny, czy organizacja nie przejmuje szerszych obowiązków.

Kompetencje i przejrzystość — nie tylko przy wysokim ryzyku

Artykuł 4 AI Act wymaga od dostawców i podmiotów stosujących podejmowania środków zapewniających odpowiedni poziom kompetencji w zakresie AI u osób zajmujących się jego obsługą i wykorzystaniem w ich imieniu. Zakres przygotowania powinien odpowiadać wiedzy tych osób, zastosowaniu systemu i potencjalnym skutkom jego użycia. Rozporządzenie nie narzuca jednego obowiązkowego certyfikatu szkoleniowego. Odrębne obowiązki przejrzystości przewidziano w art. 50: przykładowo dostawca systemu prowadzącego interakcję z człowiekiem powinien zapewnić informację o kontakcie z AI, chyba że jest to oczywiste w danych okolicznościach. Podmiot wykorzystujący AI do tworzenia deepfake’ów ma natomiast obowiązki ujawniania sztucznego pochodzenia lub manipulacji treści, z uwzględnieniem ustawowych wyjątków.

W relacji z dostawcą rekomendujemy jasno uzgodnić dostęp do instrukcji, informacji o ograniczeniach systemu, rejestrów zdarzeń i wsparcia przy incydentach. Umowa może porządkować współpracę, ale nie znosi obowiązków przypisanych organizacji przez prawo. Podstawę tego podziału stanowią w szczególności art. 3–4, 16, 25–27 i 50 rozporządzenia w sprawie sztucznej inteligencji.

5. Automatyczne podejmowanie decyzji i profilowanie: ograniczenia i wymogi organizacyjne

O dopuszczalności automatyzacji nie przesądza sama zgodność systemu z AI Act. Istotne jest również to, jak organizacja wykorzystuje jego wyniki i jakie skutki wywołuje to dla konkretnej osoby. Inaczej należy ocenić narzędzie porządkujące dokumenty, a inaczej system automatycznie odrzucający kandydatów do pracy lub odmawiający udzielenia kredytu. Rekomendujemy rozróżniać sytuacje, w których AI wspiera ocenę człowieka, od tych, w których faktycznie rozstrzyga sprawę.

Profilowanie oznacza zautomatyzowane przetwarzanie danych osobowych służące ocenie określonych cech osoby, np. jej sytuacji ekonomicznej, wydajności pracy, preferencji czy wiarygodności. Nie musi kończyć się podjęciem decyzji. Z kolei automatyczne podejmowanie decyzji może występować bez profilowania, np. gdy system stosuje prostą regułę kwalifikującą osobę do określonego świadczenia. Oba mechanizmy mogą działać także bez wykorzystania AI — dlatego nie należy utożsamiać ich wyłącznie z systemami objętymi AI Act.

Podstawowe ograniczenie wynika z art. 22 RODO: co do zasady niedopuszczalne jest poddawanie osoby decyzji opartej wyłącznie na zautomatyzowanym przetwarzaniu, w tym profilowaniu, jeżeli wywołuje ona wobec niej skutki prawne lub w podobny sposób istotnie na nią wpływa. Znaczenie mają więc łącznie sposób podejmowania decyzji i jej konsekwencje. Automatyczna rekomendacja produktu nie jest z tego powodu traktowana tak samo jak automatyczna odmowa zatrudnienia.

Od tej zasady istnieją wyjątki: decyzja może być niezbędna do zawarcia lub wykonania umowy, dozwolona przepisami prawa Unii lub państwa członkowskiego przewidującymi odpowiednie zabezpieczenia albo oparta na wyraźnej zgodzie osoby. Sama oszczędność czasu lub kosztów nie dowodzi niezbędności automatyzacji. Przy wyjątku umownym i wyraźnej zgodzie organizacja musi zapewnić co najmniej możliwość uzyskania interwencji człowieka, przedstawienia własnego stanowiska i zakwestionowania decyzji. W przypadku wyjątku ustawowego zabezpieczenia muszą wynikać z odpowiednich przepisów. Decyzje oparte na szczególnych kategoriach danych, np. dotyczących zdrowia, podlegają dodatkowym ograniczeniom.

Udział człowieka musi być rzeczywisty, a nie sprowadzać się do zatwierdzenia wyniku. Jeżeli rekruter bez samodzielnej oceny akceptuje każdą rekomendację odrzucenia kandydata, samo kliknięcie przycisku nie usuwa ryzyka zastosowania art. 22 RODO. Osoba weryfikująca powinna rozumieć ograniczenia narzędzia, mieć dostęp do informacji potrzebnych do oceny sprawy oraz uprawnienie do zmiany rozstrzygnięcia. Potrzebuje również czasu na analizę — procedura wymagająca zatwierdzania setek wyników w krótkim terminie może podważać realność nadzoru.

AI Act uzupełnia tę perspektywę wymogami nadzoru człowieka nad systemami wysokiego ryzyka. Nie oznacza to jednak, że każdy wynik takiego systemu wymaga ręcznego zatwierdzenia. Nadzór powinien odpowiadać ryzyku i sposobowi wykorzystania rozwiązania, umożliwiając właściwą interpretację wyników, ich pominięcie lub zmianę oraz interwencję w działanie systemu. Szczególne znaczenie ma ograniczanie nadmiernego zaufania do rekomendacji algorytmu.

Na poziomie organizacyjnym rekomendujemy jasno określić, kto odpowiada za rozstrzygnięcie, kiedy wymagana jest samodzielna ocena człowieka i jak osoba zainteresowana może zakwestionować decyzję. Dokumentacja powinna pozwalać odtworzyć rolę systemu, zakres przeprowadzonej weryfikacji i uzasadnienie ostatecznego wyniku. Informacja przekazywana osobie nie powinna ograniczać się do stwierdzenia „tak zdecydował algorytm”. Organizacja potrzebuje zrozumiałego wyjaśnienia oraz procedury ponownej oceny, która nie polega jedynie na ponownym uruchomieniu tego samego mechanizmu.

6. AI Act a RODO: dane osobowe w projektach AI, Privacy by Design/Default oraz DPIA

Zgodność z AI Act nie zastępuje zgodności z RODO. Obie regulacje mają odrębne zakresy: AI Act ustanawia wymagania dotyczące systemów sztucznej inteligencji, natomiast RODO chroni osoby fizyczne w związku z przetwarzaniem ich danych. Jeżeli projekt AI obejmuje dane osobowe, organizacja musi uwzględnić oba reżimy prawne. Brak kwalifikacji systemu jako systemu wysokiego ryzyka według AI Act nie oznacza, że przetwarzanie danych jest obarczone niskim ryzykiem w rozumieniu RODO.

Dane osobowe to nie tylko zbiory treningowe. Mogą znajdować się również w poleceniach kierowanych do modelu, załączanych dokumentach, historii rozmów, rejestrach działania systemu oraz wygenerowanych odpowiedziach. Rekomendujemy analizowanie całego przepływu informacji — od pozyskania danych po ich usunięcie. Samo usunięcie imienia i nazwiska nie przesądza o anonimowości: opis stanowiska, zdarzenia lub sytuacji zdrowotnej może nadal pozwalać na identyfikację osoby. Dane pseudonimizowane, które można ponownie przypisać osobie przy użyciu dodatkowych informacji, pozostają danymi osobowymi.

Dla każdego celu przetwarzania należy określić odpowiednią podstawę z art. 6 RODO, a przy szczególnych kategoriach danych, np. dotyczących zdrowia, także właściwą przesłankę z art. 9. Zgoda nie jest rozwiązaniem uniwersalnym, a publiczna dostępność danych nie oznacza dowolności ich wykorzystania. Użycie dokumentacji klienta do obsługi jego sprawy i wykorzystanie jej do trenowania modelu to różne cele, których dopuszczalność trzeba ocenić. Nadal obowiązują zasady minimalizacji danych, ograniczenia celu i czasu przechowywania, przejrzystości oraz realizacji praw osób.

W przypadku zewnętrznej usługi AI istotne jest ustalenie, czy usługodawca przetwarza dane wyłącznie na polecenie organizacji, czy również we własnych celach. Od tego zależą role stron i wymagania umowne, w tym ewentualna umowa powierzenia z art. 28 RODO. Trzeba także zweryfikować zasady wykorzystywania treści do trenowania modeli, udział podwykonawców oraz ewentualne przekazywanie danych poza Europejski Obszar Gospodarczy. Deklaracja „nie trenujemy na danych klienta” nie rozstrzyga wszystkich tych kwestii.

Privacy by Design oznacza ochronę danych już na etapie projektowania. Zgodnie z art. 25 RODO zabezpieczenia powinny wynikać z celu, zakresu i ryzyka przetwarzania, a nie być dodatkiem po uruchomieniu rozwiązania. W projekcie AI może to oznaczać ograniczenie danych przekazywanych modelowi, oddzielenie środowisk testowych od produkcyjnych oraz kontrolę dostępu do dokumentów i odpowiedzi. Przykładowo asystent korzystający z firmowej bazy wiedzy powinien respektować uprawnienia użytkownika, zamiast ujawniać informacje ze wszystkich dostępnych technicznie źródeł.

Privacy by Default to ochrona danych w ustawieniach domyślnych. Bez dodatkowych działań użytkownika system powinien przetwarzać wyłącznie dane niezbędne do konkretnego celu — pod względem ich zakresu, dostępności i okresu przechowywania. Rekomendujemy więc ograniczanie domyślnego zapisu treści rozmów i wyłączanie niepotrzebnego udostępniania danych, zamiast pozostawiania tych decyzji każdemu pracownikowi.

DPIA, czyli ocena skutków dla ochrony danych, jest wymagana, gdy przetwarzanie może powodować wysokie ryzyko naruszenia praw lub wolności osób — zgodnie z art. 35 RODO. Samo zastosowanie AI nie powoduje automatycznie takiego obowiązku. Znaczenie mają m.in. charakter danych, skala operacji, zakres oceny osób oraz kontekst wykorzystania technologii. Ocenę należy przeprowadzić przed rozpoczęciem przetwarzania objętego tym obowiązkiem; pilotaż na rzeczywistych danych nie jest z niego automatycznie zwolniony.

DPIA obejmuje opis przetwarzania, ocenę jego niezbędności i proporcjonalności, analizę ryzyka dla osób oraz środki ograniczające to ryzyko. Odpowiedzialność spoczywa na administratorze, który zasięga opinii inspektora ochrony danych, jeżeli został on wyznaczony. Dokumentacja dostawcy AI może wspierać ocenę, ale nie zastępuje analizy konkretnego zastosowania w organizacji. Jeżeli mimo planowanych zabezpieczeń pozostaje wysokie ryzyko, przed rozpoczęciem przetwarzania konieczne są uprzednie konsultacje z organem nadzorczym na podstawie art. 36 RODO.

7. Jak dostosować istniejące rozwiązania IT i procedury do AI Act (plan działań i kontrola zgodności)

Dostosowanie organizacji do AI Act rekomendujemy prowadzić jako wspólny projekt biznesu, IT, działu prawnego i compliance, z udziałem inspektora ochrony danych tam, gdzie przetwarzane są dane osobowe. Punktem wyjścia nie powinien być zakup nowego narzędzia, lecz ustalenie, gdzie AI już działa, w jakim celu jest wykorzystywana i jakie obowiązki dotyczą konkretnego zastosowania. Sama deklaracja producenta o zgodności produktu nie zastępuje oceny sposobu jego używania w organizacji.

Krok 1. Zinwentaryzować systemy i ich zastosowania. Przegląd powinien objąć nie tylko projekty oficjalnie wdrożone przez IT, lecz także funkcje AI uruchomione w dotychczasowym oprogramowaniu, integracje z usługami zewnętrznymi oraz narzędzia używane samodzielnie przez pracowników. Rekomendujemy utworzenie wewnętrznego rejestru zawierającego cel wykorzystania, dostawcę, wersję rozwiązania, właściciela biznesowego, grupy użytkowników, kategorie danych i opis wpływu wyników AI na proces. Ten sam produkt może wymagać odmiennej oceny w różnych zastosowaniach.

Krok 2. Przeprowadzić analizę luk. Dla każdego zastosowania należy udokumentować kwalifikację rozwiązania jako systemu AI, kategorię ryzyka, rolę organizacji oraz właściwe wymagania. W przypadku istniejących systemów trzeba również sprawdzić zastosowanie przepisów przejściowych — wcześniejsze wdrożenie nie oznacza automatycznego wyłączenia spod regulacji. Następnie należy porównać wymagania z rzeczywistą konfiguracją i procedurami. Wynikiem powinna być lista braków, a przy każdym z nich: osoba odpowiedzialna, priorytet, termin usunięcia i dowód wykonania. Praktyki zakazane wymagają zaprzestania, a nie akceptacji ryzyka przez kierownictwo.

Krok 3. Dopasować zabezpieczenia techniczne do ustalonych wymagań. W zależności od systemu i obowiązków organizacji prace mogą obejmować ograniczenie uprawnień, konfigurację rejestrowania zdarzeń, mechanizmy nadzoru człowieka, komunikaty o interakcji z AI oraz możliwość zatrzymania procesu. Nie każdy system wymaga identycznych zabezpieczeń. W przypadku logów trzeba określić zakres, dostęp i okres przechowywania zgodny z właściwymi przepisami, zamiast bezterminowo gromadzić wszystkie dane. Skuteczność zmian należy sprawdzić na reprezentatywnych scenariuszach, w tym na błędnych wynikach i sytuacjach wymagających interwencji.

Krok 4. Zaktualizować procedury zakupowe, operacyjne i zarządzania zmianą. Rekomendujemy włączenie oceny AI do istniejącego procesu zatwierdzania oprogramowania. Od dostawcy warto pozyskać instrukcje, informacje o ograniczeniach i dokumenty wymagane dla danego rozwiązania, a w umowie określić zasady informowania o aktualizacjach oraz współpracy przy incydentach. Zmiana modelu, przeznaczenia lub sposobu integracji powinna uruchamiać ponowną ocenę; w określonych przypadkach może również zmienić rolę prawną organizacji. Procedura incydentowa powinna wskazywać osobę podejmującą decyzję o wstrzymaniu użycia oraz ścieżkę ustalenia, czy konieczne jest zgłoszenie dostawcy lub właściwemu organowi.

Krok 5. Przygotować pracowników do przypisanych zadań. Obowiązek zapewniania odpowiedniego poziomu kompetencji w zakresie AI wymaga uwzględnienia wiedzy personelu, kontekstu użycia i osób, na które system oddziałuje. Rekomendujemy odrębne przygotowanie użytkowników, administratorów i osób sprawujących nadzór. Praktyczne ćwiczenia powinny obejmować rozpoznawanie błędów, weryfikację wyników oraz zgłaszanie nieprawidłowości. Dokumentacja szkoleń pomaga wykazać podjęte działania, ale sam certyfikat uczestnictwa nie potwierdza zgodności systemu z AI Act.

Kontrola zgodności powinna opierać się na dowodach, nie wyłącznie na zatwierdzonej polityce. Przed zatwierdzeniem dalszego używania systemu po dostosowaniu rekomendujemy sprawdzić:

• Czy istnieje aktualna ocena zastosowania, ze wskazaniem obowiązków i uzasadnieniem kwalifikacji?
• Czy wymagane zabezpieczenia przetestowano, a wyniki i usunięcie wykrytych braków udokumentowano?
• Czy osoby odpowiedzialne za obsługę, nadzór i incydenty mają odpowiednie kompetencje oraz uprawnienia?
• Czy ustalono częstotliwość przeglądów oraz zdarzenia wymagające ponownej oceny?

Przeglądy warto powiązać z wagą zastosowania, aktualizacjami systemu i zgłoszonymi problemami. Kierownictwo powinno otrzymywać informacje o nierozwiązanych niezgodnościach, opóźnionych działaniach naprawczych i skuteczności zabezpieczeń. Wewnętrzna akceptacja biznesowa nie zastępuje wymaganej prawem oceny zgodności ani nie legalizuje niespełnienia obowiązków.

8. Harmonogram wdrażania regulacji: kamienie milowe i działania do podjęcia teraz

AI Act nie ustanawia jednej daty rozpoczęcia wszystkich obowiązków. Harmonogram organizacji trzeba powiązać z kategorią systemu, rolą firmy oraz datą wprowadzenia rozwiązania do obrotu lub oddania go do użytku. Rekomendujemy oddzielenie terminów prawnych od wewnętrznych terminów gotowości — zakończenie prac dokładnie w dniu rozpoczęcia stosowania przepisów nie pozostawia czasu na usunięcie niezgodności.

Podstawą poniższego harmonogramu są art. 113 oraz przepisy przejściowe art. 111 rozporządzenia (UE) 2024/1689. Przy zatwierdzaniu planu należy sprawdzić aktualne brzmienie aktu i ewentualne zmiany legislacyjne. Same zapowiedzi przesunięcia terminów nie zmieniają obowiązków organizacji.

1 sierpnia 2024 r. — wejście AI Act w życie. Ta data rozpoczęła okres stopniowego wdrażania regulacji, ale nie oznaczała jeszcze stosowania wszystkich jej wymagań. W planowaniu zgodności należy więc rozróżniać wejście rozporządzenia w życie od rozpoczęcia stosowania poszczególnych przepisów.

2 lutego 2025 r. — zakazane praktyki i kompetencje w zakresie AI. Od tej daty stosuje się rozdziały I i II, w tym zakazy określone w art. 5 oraz art. 4 dotyczący zapewniania odpowiedniego poziomu kompetencji personelu i innych osób obsługujących systemy AI w imieniu dostawcy lub podmiotu stosującego. Tych działań nie należy odkładać do ogólnego terminu stosowania rozporządzenia. Zakres przygotowania zespołów powinien odpowiadać ich wiedzy, zadaniom i kontekstowi wykorzystania AI; przepis nie ustanawia obowiązku uzyskania jednego określonego certyfikatu.

2 sierpnia 2025 r. — kolejny etap, obejmujący modele AI ogólnego przeznaczenia. Rozpoczyna się stosowanie m.in. rozdziału V dotyczącego modeli ogólnego przeznaczenia, określanych jako GPAI, oraz przepisów o zarządzaniu i nadzorze na poziomie regulacyjnym. Obowiązków dostawcy takiego modelu nie należy automatycznie przypisywać firmie, która jedynie korzysta z opartej na nim usługi. Dla modeli wprowadzonych do obrotu przed tą datą przewidziano odrębny okres przejściowy.

2 sierpnia 2026 r. — ogólny termin rozpoczęcia stosowania AI Act. Obejmuje on w szczególności obowiązki dotyczące systemów wysokiego ryzyka wskazanych w załączniku III, z uwzględnieniem zasad klasyfikacji i przepisów przejściowych, a także obowiązki przejrzystości z art. 50. Dla organizacji jest to istotny termin m.in. przy planowaniu wdrożeń AI w rekrutacji oraz rozwiązań komunikujących się bezpośrednio z ludźmi lub generujących określone treści syntetyczne.

2 sierpnia 2027 r. — szczególna grupa systemów wysokiego ryzyka i starsze modele GPAI. Zgodnie z harmonogramem rozporządzenia od tej daty stosuje się art. 6 ust. 1 i odpowiadające mu obowiązki dotyczące systemów powiązanych z produktami objętymi wskazanym prawodawstwem harmonizacyjnym UE. Nie jest to dodatkowy rok dla wszystkich systemów wysokiego ryzyka. Do tego dnia dostawcy modeli GPAI wprowadzonych do obrotu przed 2 sierpnia 2025 r. mają również dostosować je do właściwych wymagań.

Istniejące rozwiązania wymagają osobnej oceny terminów. W przypadku systemów wysokiego ryzyka wprowadzonych do obrotu lub oddanych do użytku przed 2 sierpnia 2026 r. znaczenie ma m.in. to, czy od tej daty podlegają istotnym zmianom w projekcie. Art. 111 przewiduje także szczególne zasady dla wybranych systemów. Sama wcześniejsza data zakupu nie stanowi zatem wystarczającej podstawy do uznania rozwiązania za bezterminowo zwolnione z wymagań.

Na poziomie zarządczym rekomendujemy przyjęcie czterech najbliższych kamieni milowych:

• Niezwłocznie: potwierdzić realizację obowiązków, których termin już upłynął, ze szczególnym uwzględnieniem zakazanych praktyk i kompetencji personelu.
• Przy zatwierdzaniu harmonogramu: przypisać każdemu rozwiązaniu właściwy termin prawny, właściciela działań i uzasadnienie ewentualnego zastosowania przepisów przejściowych.
• Przed właściwą datą stosowania wymagań: wyznaczyć wewnętrzny przegląd gotowości, pozostawiając czas na poprawki oraz uzyskanie potrzebnych informacji od dostawców.
• Przy każdej istotnej zmianie rozwiązania: ponownie ocenić wpływ zmiany na klasyfikację, obowiązki i możliwość dalszego korzystania z okresu przejściowego.

Za wykonanie kamienia milowego warto uznawać dopiero potwierdzony rezultat, nie samo rozpoczęcie prac: zatwierdzoną ocenę terminów, udokumentowane przygotowanie personelu lub zamknięcie wskazanych braków. Tak skonstruowany harmonogram pozwala zarządowi ocenić rzeczywistą gotowość organizacji, zamiast polegać wyłącznie na deklarowanym postępie projektu.

Pomóżmy Maćkowi wrócić do życia – wspieramy męża naszej trenerki 05 października 2026