4 godzin temu
Co adekwatnie zostało odroczone?
Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2026/1744 z 8 lipca 2026 r. w sprawie zmiany rozporządzeń (UE) 2024/1689, (UE) 2018/1139 i (UE) 2023/1230 w odniesieniu do uproszczenia wdrażania zharmonizowanych przepisów dotyczących sztucznej inteligencji (akt zbiorczy prawa cyfrowego dotyczący AI) (Dz.Urz. UE L z 2026 r., s. 1744 ) przesunęło stosowanie przepisów rozdziału III sekcji 1–3 rozporządzenia 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. 1689; dalej: AI Act) dotyczących systemów wysokiego ryzyka, z wyjątkiem art. 6 ust. 5 AI Act. Dla systemów klasyfikowanych na podstawie art. 6 ust. 2 AI Act i załącznika III nową datą jest 2.12.2027 r., a dla systemów związanych z produktami, o których mowa w art. 6 ust. 1 AI Act i załączniku I – 2.8.2028 r. Zmiana wynika z art. 1 pkt 40 rozporządzenia 2026/1744, zmieniającego art. 113 AI Act.
Nie przesunięto jednak całego AI Act. Od 2.8.2026 r. stosuje się m.in. obowiązki przejrzystości z art. 50 AI Act. Równolegle zastosowanie zachowują przepisy RODO, krajowe przepisy dotyczące nadzoru nad AI – w szczególności ustawa z 3.7.2026 r. o systemach sztucznej inteligencji (Dz.U. z 2026 r. poz. 1003) – oraz regulacje sektorowe.
Najpierw proces i zastosowanie
Wdrożenia często zaczynają się od wyboru narzędzia. Biznes chce Copilota, HR testuje system do rekrutacji, sprzedaż uruchamia agenta, a dopiero później pojawia się pytanie o compliance. Tymczasem ten sam model może służyć zarówno do przygotowania roboczego podsumowania, jak i do wpływania na decyzję dotyczącą konkretnej osoby.
Dlatego pierwszym etapem powinno być zidentyfikowanie procesów i konkretnych przepływów pracy. Kto uruchamia sztuczną inteligencję? Jakie dane do niej trafiają? Do czego wykorzystywany jest wynik? Czy prowadzi do kolejnych działań automatycznych? Dopiero wtedy można prawidłowo określić rolę organizacji, kategorię ryzyka oraz wymogi RODO, poufności czy cyberbezpieczeństwa.
Tak można też znaleźć Shadow AI, czyli korzystanie z narzędzi AI poza wiedzą lub kontrolą organizacji: publiczne chatboty, prywatne konta czy automatyzacje poza oficjalnym nadzorem. Istotny przypadek użycia powinien mieć, zgodnie ze stosowaną przeze mnie metodyką, Właściciela Procesu, który odpowiada za cel biznesowy, sposób wykorzystania AI i rezultat procesu, oraz Właściciela Zasobu, który odpowiada za techniczną stronę systemu, jego konfigurację i utrzymanie.
Samo użycie systemu w obszarze z załącznika III nie zawsze kończy analizę. Art. 6 ust. 3 AI Act przewiduje możliwość uznania niektórych takich systemów za niestwarzające wysokiego ryzyka, jeżeli nie stwarzają znaczącego ryzyka szkody dla zdrowia, bezpieczeństwa lub praw podstawowych i nie wpływają istotnie na wynik decyzji. Wyjątek nie obejmuje jednak profilowania osób fizycznych. Zasady te doprecyzowuje również art. 6 ust. 4 AI Act.
Klasyfikacja powinna więc dotyczyć konkretnego celu i sposobu użycia. Szczególną ostrożność warto zachować w HR. Prezes UODO w komunikacie z 16.7.2026 r. wskazującym na potrzebę uregulowania stosowania systemów AI w zatrudnieniu, zwrócił uwagę na ryzyko dyskryminacji kandydatów i pracowników. [4] Przesunięcie reżimu high-risk nie wyłącza obowiązków RODO, prawa pracy czy zakazu dyskryminacji.
Ocena szans i ryzyk – dwa silniki jednego wdrożenia
Compliance nie powinno zaczynać się wyłącznie od pytania, co może pójść źle. Najpierw warto ustalić, jaki problem ma rozwiązać AI i po czym poznamy, iż wdrożenie się opłaca: czy skraca czas działania, poprawia jakość albo ogranicza powtarzalną pracę?
W książce „Wdrażanie AI w organizacji. Analiza prawna, ocena ryzyka i metodyka zapewnienia zgodności” opisuję takie podejście jako Podwójny Silnik w ramach analizy ryzyka i wpływu AI, którą nazywam z kolei ARIA – AI Risk & Impact Assessment. Jeden jego element koncentruje się na identyfikacji wartości biznesowej, drugi na ocenie ryzyk i możliwych szkód.
Dopiero zestawienie obu perspektyw daje podstawę do decyzji. Czasem trzeba z projektu zrezygnować. Częściej można zmienić workflow, ograniczyć dane lub autonomię systemu albo dodać etap weryfikacji. Wtedy compliance porządkuje innowację, zamiast ją blokować.
Przejrzystość trzeba przełożyć na proces
Jednym z obowiązków, który należy przełożyć bezpośrednio na sposób działania systemu i organizacji, jest obowiązek określony w art. 50 AI Act. Obejmuje on kilka różnych wymagań, które łatwo błędnie sprowadzić do jednego hasła „oznaczania treści AI”.
Dostawcy systemów bezpośrednio wchodzących w interakcję z człowiekiem mają zasadniczo zapewnić informację o kontakcie ze sztuczną inteligencją. Natomiast dostawcy systemów generujących lub manipulujących określone treści syntetyczne mają zapewnić ich maszynową wykrywalność. Podmioty stosujące mają odrębne obowiązki, które pojawiają się m.in. przy rozpoznawaniu emocji, kategoryzacji biometrycznej, deepfake i określonych tekstach dotyczących spraw interesu publicznego. Zakres tych obowiązków wynika z art. 50 AI Act i został dodatkowo omówiony w wytycznych Komisji Europejskiej (Guidelines on transparency obligations for providers and deployers of AI systems) z 20.7.2026 r. Dla określonych systemów objętych art. 50 ust. 2 AI Act, wprowadzonych do obrotu przed 2.8.2026 r., art. 111 ust. 4 AI Act przewiduje termin dostosowania do 2.12.2026 r.
Techniczne oznaczenie treści po stronie dostawcy nie zastępuje informacji, którą podmiot stosujący powinien przekazać człowiekowi.
Przejrzystość trzeba zatem przełożyć na interfejs i workflow, czyli przebieg pracy z wykorzystaniem AI. Chatbot powinien wyświetlić informację we adekwatnym momencie. Proces publikacyjny powinien rozpoznawać materiały wymagające disclosure, czyli poinformowania odbiorcy o wykorzystaniu AI w przypadkach, w których wymaga tego AI Act. jeżeli organizacja korzysta z wyjątku opartego na human review, czyli weryfikacji treści przez człowieka, lub kontroli redakcyjnej, kontrola człowieka powinna być rzeczywista.
Człowiek w pętli i kompetencje AI
Jeśli system przedstawia gotową rekomendację, a pracownik nie ma czasu, materiału źródłowego albo realnej możliwości odejścia od wyniku, jego obecność w procesie może być czysto formalna. Kierunek orzecznictwa TSUE w sprawach C-634/21, SCHUFA Holding (Scoring), oraz C-203/22, Dun & Bradstreet Austria pokazuje znaczenie rzeczywistego wpływu człowieka oraz możliwości zrozumienia i zakwestionowania wyniku zautomatyzowanego procesu.
Rolę człowieka warto więc zaprojektować. Operator powinien wiedzieć, kiedy wynik zaakceptować, zweryfikować, odrzucić lub eskalować. Przy bardziej istotnych zastosowaniach potrzebne mogą być też: tryb ręczny i możliwość szybkiego zatrzymania działania. Taki Human-in-the-Loop działa jednak tylko wtedy, gdy człowiek ma czas i wiedzę, aby z tych uprawnień skorzystać.
Warto podobnie podejść do art. 4 AI Act dotyczącego kompetencji AI. Dostawcy i podmioty stosujące przez cały czas mają podejmować środki wspierające rozwój kompetencji osób korzystających z AI w ich imieniu. Nie muszą natomiast gwarantować określonego poziomu AI literacy każdej osobie. Takie brzmienie art. 4 AI Act wynika ze zmian wprowadzonych rozporządzeniem (UE) 2026/1744. Przemawia to za szkoleniami i instrukcjami zależnymi od roli i ryzyka.
Dostawca nie rozwiązuje za nas compliance
Komisja dysponuje uprawnieniami do egzekwowania obowiązków dostawców modeli AI ogólnego przeznaczenia (GPAI), w tym do nakładania kar. Obowiązki dostawców GPAI oraz kompetencje Komisji określają m.in. art. 53–55 i 88–94 AI Act. Zagadnienia te omawiają również wytyczne Komisji Europejskiej. Uprawnienia wykonawcze Komisji stosuje się od 2.8.2026 r. Dla organizacji korzystającej z takich modeli nie oznacza to jednak, iż zgodność przychodzi razem z licencją.
Trzeba przez cały czas ustalić, na jakich danych system pracuje, czy dostawca trenuje na danych klienta, jaka jest retencja, jak informuje o zmianach i jak bezpiecznie wyjść z usługi. Takie due diligence dostawcy warto powtarzać przy istotnych zmianach usługi. Przy rozwijaniu własnych rozwiązań lub istotnych modyfikacjach trzeba także ponownie ocenić własną rolę prawną.
Teczka Obronna – dokumentacja tworzona razem z wdrożeniem
AI compliance powinno pozwolić odtworzyć, dlaczego system dopuszczono do użycia, kto podjął decyzję, jakie ryzyka zidentyfikowano i jakie zabezpieczenia zastosowano.
W mojej metodyce taki uporządkowany materiał nazywam Teczką Obronną. Łączy ona opis procesu i celu, klasyfikację, ARIA, odpowiednie elementy DPIA (Data Protection Impact Assessment) lub FRIA (Fundamental Rights Impact Assessment), due diligence dostawcy, wyniki testów, szkolenia, logi i historię istotnych zmian. Chodzi o możliwość wykazania logicznego ciągu decyzji przy kontroli, skardze, incydencie albo sporze.
Podsumowanie
Przesunięcie części obowiązków wysokiego ryzyka daje organizacjom potrzebny czas. Najlepiej wykorzystać go w kolejności, która odpowiada logice wdrożenia: od zmapowania rzeczywistego wykorzystania AI i opisania najważniejszych workflow, przez przypisanie odpowiedzialności, klasyfikację zastosowań i równoległą ocenę korzyści oraz ryzyk, po przejrzystość, kompetencje użytkowników, realny nadzór człowieka, uporządkowanie relacji z dostawcami i budowanie materiału dowodowego.
Dobrze przygotowana organizacja powinna być w stanie odpowiedzieć: gdzie AI działa, w jakim celu, na jakich danych, kto odpowiada za proces i technologię, jaki jest wpływ na człowieka, jakie ograniczenia zostały ustawione oraz po czym poznamy, iż system przestał działać zgodnie z założeniami. Wartość dodatkowego czasu będzie więc zależała od tego, czy organizacja potrafi nie tylko odpowiedzieć na te pytania, ale także pokazać dowody stojące za podjętymi decyzjami.
Adwokat Paweł Mielniczek, doktor nauk prawnych, architekt systemów zarządzania AI. Łączy innowacje technologiczne z rygorem regulacyjnym (AI Act, RODO, NIS2). Przekłada zawiłe przepisy na konkretne rozwiązania biznesowe, udowadniając, iż mądry compliance nie hamuje rozwoju, ale buduje rynkową przewagę. Założyciel firmy doradczo-technologicznej Get Compliant. Jako AI Officer doradza organizacjom we wdrażaniu sztucznej inteligencji i optymalizacji procesów (BPO) dzięki autonomicznych agentów AI, gwarantując ich pełne bezpieczeństwo prawne i operacyjne. Twórca autorskiej „metodyki 16 kroków” oraz innowacyjnego protokołu oceny ryzyka ARIA (AI Risk and Impact Assessment). Wiodący audytor normy ISO 42001 i redaktor Vademecum AI Officera. Z powodzeniem chronił klientów w precedensowych sytuacjach kryzysowych, w tym postępowaniach sądowych i sądowo-administracyjnych. Unikalne doświadczenie zdobywał pracując w strukturach NATO w USA, Biurze ONZ w Genewie oraz polskim UODO. Ceniony instruktor o globalnym zasięgu. Jego praktyczne kursy z obszaru prawa, zarządzania ryzykiem i AI (dostępne m.in. na platformach Coursera i Udemy) ukończyły już dziesiątki tysięcy profesjonalistów na całym świecie.
