EU AI Act w pigułce: jak sklasyfikować system i przygotować dokumentację?

Krótkie przypomnienie: czym jest EU AI Act i kogo dotyczy

Definicja systemu AI w EU AI Act – szeroka siatka

EU AI Act przyjmuje szeroką definicję „systemu AI”. To nie tylko głębokie sieci neuronowe czy modele generatywne. System AI to każdy system oparty na podejściach obliczeniowych wymienionych w akcie (m.in. uczenie maszynowe, logika, metody statystyczne), który generuje wyniki – treść, przewidywania, rekomendacje lub decyzje – wpływające na środowisko, w którym jest wdrażany.

W praktyce oznacza to, że jako system AI mogą zostać zakwalifikowane:

• klasyczne modele ML (regresja logistyczna, drzewa decyzyjne, XGBoost, sieci neuronowe),
• systemy eksperckie oparte na regułach, jeśli na wejściu przetwarzają dane i generują zalecenia lub decyzje,
• proste klasyfikatory, scoringi, systemy rekomendacyjne, jeśli ich wynik realnie wpływa na decyzje wobec ludzi lub zasobów,
• kompozycje usług chmurowych (np. API rozpoznawania obrazu + scoring ryzyka), jeśli są zintegrowane w jeden proces decyzyjny.

Jeśli algorytm tylko sortuje listę w interfejsie albo drukuje raport bez wpływu na decyzje wobec osób czy zasobów, można rozważać klasyfikację jako narzędzie pomocnicze o minimalnym ryzyku. Gdy jednak wynik algorytmu jest podstawą przyznania kredytu, odrzucenia kandydata, skierowania pacjenta – mówimy o systemie AI w pełnym znaczeniu aktu.

Punkt kontrolny: jeśli cokolwiek w Twoim produkcie „uczy się” na danych lub automatycznie ustala wynik na podstawie reguł czy modeli, zakładaj, że to system AI i doprecyzowuj dalej, zamiast próbować wykazać, że „to tylko kalkulator”.

Zakres geograficzny i podmiotowy – kto podlega regulacji

EU AI Act ma zastosowanie nie tylko do firm z siedzibą w UE. Podstawowe kryterium to miejsce użycia systemu i wpływ na osoby w Unii. Podlegasz regulacji, jeśli:

• dostarczasz (tworzysz, rozwijasz) system AI i wprowadzasz go do obrotu w UE (sprzedaż, licencja, udostępnienie SaaS),
• używasz systemu AI na terytorium UE – niezależnie od tego, gdzie jest hostowany i gdzie ma siedzibę dostawca,
• importujesz lub dystrybuujesz system AI w UE (np. jako reseller, integrator),
• system AI działa poza UE, ale jego wynik wpływa na osoby w UE (np. scoring kredytowy dla klientów z Polski generowany w systemie hostowanym w USA).

Z punktu widzenia audytu kluczowe jest, że odpowiedzialność jest rozproszona. Inne obowiązki ma dostawca (twórca systemu), inne użytkownik (organizacja wykorzystująca system w procesach), a jeszcze inne importer i dystrybutor. Brak świadomości własnej roli to typowy sygnał ostrzegawczy przy pierwszych przeglądach compliance.

Dostawca a użytkownik – jak rozróżnić role

Dostawca (provider) to podmiot, który rozwija system AI lub zleca jego rozwój pod własną marką i wprowadza go do obrotu lub oddaje do użytku pod swoją nazwą. To może być:

• software house tworzący produkt AI i sprzedający licencje,
• firma produktowa oferująca SaaS z komponentami AI,
• duża organizacja budująca wewnętrzny system AI i „oddająca do użytku” jednostkom biznesowym.

Użytkownik (deployer) to podmiot, który wykorzystuje system AI w swojej działalności zawodowej. Może nie mieć żadnego wpływu na architekturę, ale decyduje, jak system jest stosowany w konkretnym procesie (np. bank używający zewnętrznego systemu scoringowego).

Ta różnica jest kluczowa dla obowiązków. Dostawca odpowiada za zaprojektowanie systemu zgodnie z wymogami (zarządzanie ryzykiem, dane treningowe, dokumentacja techniczna, testy), użytkownik – za odpowiedni sposób stosowania systemu, nadzór ludzki, interpretację wyników, szkolenie personelu i spełnienie wymogów informacyjnych wobec osób, których dotyczą decyzje.

Punkt kontrolny: jeśli jesteś firmą, która zarówno tworzy system AI, jak i stosuje go wewnętrznie, pełnisz podwójną rolę – dostawcy i użytkownika. Wymagania obu ról muszą znaleźć odzwierciedlenie w politykach i dokumentacji.

Wprowadzenie do obrotu i oddanie do użytku – moment startu obowiązków

Dwa pojęcia wyznaczają „moment zero” dla obowiązków z EU AI Act:

• wprowadzenie do obrotu – pierwsze udostępnienie systemu AI na rynku UE (sprzedaż, wynajem, udostępnienie SaaS), niezależnie od tego, czy jest odpłatny,
• oddanie do użytku – pierwsze zastosowanie systemu przez użytkownika do konkretnych celów w środowisku rzeczywistym (nie w testach wewnętrznych).

Do momentu testów pilotażowych wewnątrz organizacji możesz stosować bardziej elastyczne praktyki, ale z chwilą pierwszego realnego użycia wobec osób lub procesów istotnych biznesowo wchodzisz w strefę pełnych wymogów. Próby „przeciągania” fazy testów latami to sygnał ostrzegawczy dla audytora.

Minimum odpowiedzialnego działania to jasne udokumentowanie daty wprowadzenia do obrotu/oddania do użytku oraz stanu zgodności na ten dzień. Bez tego trudno wykazać, że system był przygotowany zgodnie z wymogami w odpowiednim momencie.

Minimalny poziom wiedzy: product owner, prawnik, lider techniczny

EU AI Act nie wymaga, by każdy w organizacji znał cały tekst rozporządzenia, ale trzy role muszą mieć minimum wspólnego słownika i rozumienia:

• Product owner – rozumie kategorie ryzyka, wie, czym jest system wysokiego ryzyka, potrafi wskazać główne scenariusze użycia i ich wpływ na ludzi oraz biznes.
• Prawnik / compliance – zna strukturę aktu, potrafi pracować z załącznikiem III, rozróżnia obowiązki dostawcy i użytkownika, umie przełożyć wymogi na polityki i procedury.
• Lider techniczny – rozumie, jakie informacje o architekturze, danych, testach i monitoringu są potrzebne do dokumentacji technicznej i audytu.

Jeżeli te trzy role nie rozmawiają ze sobą w jednym języku, dokumentacja techniczna zwykle jest niekompletna: nie odpowiada na pytania regulatora albo nadmiernie skupia się na szczegółach technicznych bez opisu ryzyka i wpływu. Minimum to wspólny warsztat, podczas którego zespół razem klasyfikuje system i uzupełnia kartę systemu AI.

Jeśli nie potrafisz w jednym zdaniu określić, czy Twoja organizacja jest w danym projekcie dostawcą, czy użytkownikiem, dalsze prace nad zgodnością będą chaotyczne. Najpierw nazwanie roli, potem klasyfikacja – to pierwsza linia obrony przy audycie.

Mapa kategorii ryzyka: od zakazanych po minimalne

Cztery poziomy ryzyka – logiczny lejek klasyfikacyjny

EU AI Act opiera się na koncepcji ryzyka związanego z zastosowaniem systemu, a nie z technologią jako taką. Ten sam typ modelu może być systemem wysokiego ryzyka lub minimalnego ryzyka, zależnie od celu i kontekstu użycia. Klasyfikacja odbywa się w czterech krokach:

1. Czy system jest zakazany (prohibited) – jeśli tak, prace nad wdrożeniem muszą zostać przerwane lub koncepcja zmieniona.
2. Jeśli nie jest zakazany, czy wchodzi w którykolwiek z obszarów wysokiego ryzyka (high-risk) z załącznika III?
3. Jeśli nie jest wysokiego ryzyka, czy wchodzi w kategorię ograniczonego ryzyka (limited risk) – głównie wymogi przejrzystości?
4. Jeśli żadna z powyższych kategorii nie pasuje, pozostaje kategoria minimalnego ryzyka (minimal risk).

Ten „lejek” jest podstawą matrycy klasyfikacyjnej. Dobrze zbudowana procedura wymusza przejście przez każde pytanie w tej kolejności. Pomijanie etapu pierwszego lub drugiego (zakazane i wysokie ryzyko) to najczęstszy błąd, który prowadzi do błędnego określenia poziomu obowiązków.

Zakazane praktyki AI – co odpada z góry

Zakazane systemy AI to niewielka, ale bardzo wrażliwa grupa zastosowań. Przez pryzmat audytu liczy się nie tyle technologia, co efekt i intencja. Przykładowe zakazane praktyki to:

• systemy wykorzystujące podprogowe techniki manipulacyjne, które zniekształcają zachowanie użytkownika w sposób powodujący lub mogący spowodować szkodę,
• systemy wykorzystujące słabości określonych grup (wiek, niepełnosprawność, sytuacja społeczna) w celu manipulacji,
• social scoring – systemy oceniające osoby fizyczne na podstawie ich zachowań lub cech, które prowadzą do niesprawiedliwego traktowania w innych kontekstach i mają znaczące negatywne skutki,
• niektóre formy zdalnej biometrycznej identyfikacji „real-time” w przestrzeni publicznej do celów egzekwowania prawa (z wyjątkami ściśle zdefiniowanymi w akcie).

Jeśli którykolwiek z opisów choć częściowo pasuje do Twojej koncepcji systemu, to silny sygnał ostrzegawczy. Minimum to konsultacja z działem prawnym i etycznym przed wejściem w etap prototypowania. Próba „przemycenia” funkcji social scoringu jako modułu pobocznego jest praktycznie nie do obrony przy kontroli.

Systemy wysokiego ryzyka – powiązanie z załącznikiem III

System wysokiego ryzyka to niekoniecznie system „niebezpieczny”, ale taki, który może znacząco wpływać na zdrowie, bezpieczeństwo, prawa podstawowe lub dostęp do kluczowych usług. EU AI Act w załączniku III wymienia obszary zastosowań, m.in.:

• infrastruktura krytyczna (np. zarządzanie ruchem, sieci energetyczne),
• edukacja i szkolenia zawodowe (np. systemy oceny, selekcji),
• zatrudnienie, HR, dostęp do samozatrudnienia (systemy rekrutacyjne, scoring kandydatów),
• dostęp do usług i świadczeń publicznych oraz prywatnych o istotnym znaczeniu (np. scoring kredytowy, ubezpieczenia, świadczenia społeczne),
• opieka zdrowotna i opieka społeczna (diagnoza wspomagana AI, triage, narzędzia wspierające leczenie),
• wymiar sprawiedliwości i systemy egzekwowania prawa (z wyjątkiem zakazanych),
• zarządzanie migracją, kontrola granic, azyl.

Kluczowe jest, że klasyfikacja opiera się na obszarze zastosowania, a nie branży. Ten sam bank może mieć system AI wysokiego ryzyka (scoring kredytowy) i minimalnego ryzyka (system rekomendacji artykułów na blogu). Pytanie brzmi: czy wynik działania systemu jest podstawą decyzji wpływającej na prawa i możliwości konkretnej osoby?

Punkt kontrolny: jeśli system decyduje (lub stanowi główną podstawę decyzji) o dostępie do pracy, edukacji, kredytu, świadczeń, opieki medycznej – klasyfikacja wysokiego ryzyka jest najczęściej właściwą hipotezą startową.

Systemy ograniczonego ryzyka – wymogi przejrzystości

Systemy ograniczonego ryzyka to te, które nie spełniają kryteriów wysokiego ryzyka, ale mogą wprowadzać użytkownika w błąd lub wpływać na jego decyzje, jeśli użytkownik nie jest świadomy, że ma do czynienia z AI. Typowe przypadki to:

• chatboty, które symulują rozmowę z człowiekiem w obsłudze klienta,
• systemy generujące treści (tekst, obraz, wideo) prezentowane użytkownikowi w sposób mogący sugerować, że są „naturalne” lub „prawdziwe”,
• systemy deepfake wykorzystywane w tworzeniu treści (z zastrzeżeniami dotyczącymi dezinformacji i innych regulacji).

W tej kategorii głównym wymogiem są obowiązki przejrzystości: jasne informowanie użytkowników, że korzystają z systemu AI, oraz – w przypadku generatywnych systemów treści – oznaczanie treści jako wygenerowanych przez AI, jeśli może to mieć znaczenie dla odbiorcy.

Jeśli Twoja aplikacja jest „only UX improvement”, ale użytkownik podejmuje decyzje na podstawie jej wyników, brak informacji o użyciu AI może być poważną luką compliance. Minimum to widoczny komunikat, odpowiednie zapisy w regulaminie i przeszkolenie personelu, jak tę informację komunikować.

Systemy minimalnego ryzyka – co znaczy „brak dodatkowych wymogów”

Kategoria minimalnego ryzyka obejmuje większość dzisiejszych zastosowań AI: filtry spamowe, systemy rekomendacji filmów, narzędzia do personalizacji treści marketingowych, narzędzia analityczne niepowiązane bezpośrednio z decyzjami wobec osób. Formalnie EU AI Act nie nakłada na te systemy dodatkowych wymogów ponad ogólne przepisy (RODO, prawo konsumenckie itp.).

Jednak „brak dodatkowych wymogów” nie znaczy, że można zignorować ryzyko. Zdrowe minimum compliance to:

• wewnętrzna klasyfikacja systemu i krótki opis, dlaczego uznano go za minimalnego ryzyka,
• podstawowa dokumentacja: cel, dane wejściowe/wyjściowe, ograniczenia, potencjalne ryzyka nadużyć,
• prosty mechanizm zgłaszania błędów lub nadużyć przez użytkowników,
• monitoring podstawowych wskaźników działania (np. błędy klasyfikacji, liczba skarg).

Matryca klasyfikacyjna: jak przełożyć przepisy na konkretne pytania

Suche kategorie ryzyka są przydatne dopiero wtedy, gdy zamienią się w prosty zestaw pytań, który można przejść razem z zespołem. Dobrze zbudowana matryca klasyfikacyjna działa jak checklista audytowa – jeśli każde pytanie ma jasną odpowiedź i uzasadnienie, decyzja o poziomie ryzyka jest obroniona.

Kluczowe pytania w procesie klasyfikacji systemu

Podstawą jest krótka sesja warsztatowa, w której uczestniczą minimum product owner, prawnik i lider techniczny. Punkt po punkcie system trzeba „przepuścić” przez zestaw pytań:

• Cel biznesowy: jaki konkretny problem rozwiązuje system i jaka decyzja lub działanie jest jego wynikiem?
• Adresaci: na kogo wpływa wynik systemu (klienci indywidualni, pracownicy, partnerzy, ogół użytkowników)?
• Rodzaj decyzji: czy wynik systemu jest:
  • bezpośrednią decyzją wobec osoby (np. przyznanie/odmowa świadczenia),
  • główną podstawą decyzji człowieka (np. rekomendacja kredytowa w workflow analityka),
  • wyłącznie wsparciem informacyjnym bez formalnych skutków (np. rekomendacja treści na portalu)?
• Skutki błędu: co się stanie, jeśli system się pomyli – jaka jest skala szkody dla pojedynczej osoby i dla grupy?
• Obowiązki prawne: czy decyzja, którą wspiera system, jest objęta szczególnymi regulacjami (prawo pracy, prawo bankowe, świadczenia społeczne, opieka medyczna)?
• Konkretny obszar z załącznika III: czy którakolwiek z kategorii wysokiego ryzyka opisuje decyzję, dla której używany jest system?
• Stopień autonomii: czy człowiek może realnie skorygować wynik systemu, czy decyzje zapadają automatycznie?

Każde pytanie wymaga krótkiego komentarza w karcie systemu AI – jedno zdanie często nie wystarcza. Sygnałem ostrzegawczym jest sytuacja, w której zespół nie potrafi wskazać, czy system jest podstawą decyzji, czy tylko „podpowiedzią”. Brak jasności w tym punkcie zwykle kończy się niedoszacowaniem poziomu ryzyka.

Jeżeli po przejściu pytań większość odpowiedzi wskazuje na wpływ na dostęp do usług, pracy, edukacji lub zdrowia – bezpieczniej przyjąć hipotezę wysokiego ryzyka i ewentualnie ją obniżyć po dokładnej analizie prawnej, niż odwrotnie.

Dokumentowanie decyzji klasyfikacyjnej

Sama decyzja „system X jest wysokiego / ograniczonego / minimalnego ryzyka” bez uzasadnienia w dokumentacji to proszenie się o problemy przy audycie. Minimum to krótki moduł w karcie systemu:

• Opis scenariusza użycia – 3–4 zdania opisujące, kto, kiedy i w jakim celu używa systemu.
• Mapa decyzji – wskazanie, która decyzja biznesowa jest wspierana i jaka jest rola systemu (automatyczna, rekomendacyjna, informacyjna).
• Odniesienie do przepisów – konkretne wskazanie, czy i jak system wpisuje się w któryś punkt załącznika III, lub dlaczego nie.
• Ocena skutków błędów – krótka analiza, jakie typowe błędy może popełnić system i jakie to rodzi skutki dla osób.
• Wniosek z klasyfikacji – jednoznaczne stwierdzenie kategorii ryzyka wraz z datą i wskazaniem osób, które ją zatwierdziły.

Punkt kontrolny: brak podpisu lub wyraźnego wskazania właściciela decyzji klasyfikacyjnej powoduje, że przy incydencie trudno ustalić odpowiedzialność i ścieżkę decyzyjną. Jeżeli nie wiadomo, kto podjął decyzję, przy audycie zakłada się często, że nie została podjęta w sposób należyty.

Jeśli dokumentację klasyfikacji da się streścić w jednym zdaniu, zwykle oznacza to, że nie przeanalizowano wystarczająco dobrze kontekstu użycia. Odwracanie tej decyzji na etapie inspekcji jest kosztowne i mało wiarygodne.

Minimalny zestaw dokumentów dla systemu AI

Niezależnie od kategorii ryzyka, dojrzałe podejście do EU AI Act wymaga pewnego „trzonu” dokumentacyjnego. Różni się poziom szczegółowości, ale struktura pozostaje podobna.

Karta systemu AI: jeden dokument, który spina wszystko

Karta systemu AI to centralny dokument opisujący dany system w sposób zrozumiały zarówno dla biznesu, jak i audytora technicznego. Dobrą praktyką jest utrzymywanie jednej karty na każdy logicznie odrębny system (a nie na każdy model).

Podstawowe sekcje karty systemu AI obejmują:

• Tożsamość systemu – nazwa, wersja, właściciel biznesowy, właściciel techniczny, główny kontakt z obszaru prawa/compliance.
• Opis zastosowania – krótki opis funkcjonalny, lista głównych przypadków użycia, kanały, w których system działa (np. aplikacja mobilna, panel pracowniczy).
• Rola organizacji – jasne wskazanie, czy w tym projekcie organizacja występuje jako dostawca, użytkownik, czy w obu rolach; rozpisanie tego dla różnych rynków, jeśli to potrzebne.
• Klasyfikacja ryzyka – wynik procesu klasyfikacji wraz z uzasadnieniem, odniesieniami do załącznika III i do innych przepisów sektorowych.
• Opis danych – źródła danych, typy danych (w tym dane osobowe, dane wrażliwe), sposób pozyskania, główne transformacje, zasady retencji.
• Opis architektury – uproszczony schemat przepływu danych: wejście → przetwarzanie (w tym model AI) → wyniki → systemy downstream.
• Mechanizmy nadzoru i kontroli – sposób monitorowania działania systemu, rola człowieka w pętli, mechanizmy eskalacji i blokady.
• Historia zmian – wersjonowanie karty i głównych zmian w systemie wraz z datami zatwierdzeń.

Dla systemu minimalnego ryzyka część sekcji będzie bardzo krótka, ale sama ich obecność porządkuje odpowiedzialności. Sygnał ostrzegawczy: jeśli zespół nie jest w stanie w ciągu godziny wypełnić szkicu karty systemu, prawdopodobnie nie ma wspólnego obrazu tego, co buduje.

Jeżeli karta systemu jest aktualizowana regularnie przy kolejnych releasach, staje się naturalnym punktem odniesienia przy każdej dyskusji o ryzyku i zmianach funkcji. W przeciwnym razie zamienia się w „papier do audytu”, który szybko traci związek z rzeczywistością.

Dokumentacja techniczna: co musi umieć znaleźć audytor

W systemach wysokiego ryzyka dokumentacja techniczna jest obowiązkiem formalnym, ale nawet przy niższych kategoriach dobrze mieć minimalny standard. Z perspektywy audytora kluczowe jest, żeby dokumentacja była na tyle kompletna, by możliwe było odtworzenie logiki działania systemu i procesu jego wytworzenia.

Podstawowe elementy dokumentacji technicznej obejmują:

• Opis modeli – jaki typ modeli jest używany (np. model językowy, model klasyfikacyjny), czy jest to model własny, czy model dostarczony przez podmiot trzeci, w jakiej wersji.
• Pipeline treningowy – opis procesu tworzenia lub dostrajania modelu: preprocessing danych, podział na zbiory treningowe/walidacyjne/testowe, ewentualna augmentacja.
• Parametry i konfiguracja – kluczowe parametry, wersje bibliotek, frameworków, konfiguracja środowisk (przynajmniej na poziomie umożliwiającym replikację).
• Procedury walidacji i testów – jakie testy są wykonywane (funkcjonalne, jakościowe, bezpieczeństwa, bias/fairness), jakie metryki są używane i jakie progi akceptacji przyjęto.
• Mechanizmy nadzoru produkcyjnego – jak monitorowane jest zachowanie modelu po wdrożeniu, jakie alerty są ustawione, kto jest odpowiedzialny za reakcję.
• Bezpieczeństwo i dostęp – w jaki sposób kontrolowany jest dostęp do modeli, danych treningowych i danych produkcyjnych, jak działają mechanizmy logowania i audytu.

Punkt kontrolny: jeżeli dokumentacja techniczna istnieje wyłącznie w formie kodu i komentarzy w repozytorium, a brak jest opisowych materiałów, audyt staje się praktycznie niemożliwy dla osób spoza zespołu deweloperskiego. To typowy powód przedłużania inspekcji i żądania dodatkowych wyjaśnień przez regulatora.

Jeśli zespół techniczny potrafi w ciągu krótkiego spotkania pokazać, gdzie w dokumentacji opisane są dane, pipeline, testy i monitorowanie, to dobry wskaźnik, że dokumentacja nie jest tylko formalnością, ale realnym narzędziem pracy.

Rejestr systemów AI: widok z poziomu całej organizacji

Pojedyncza karta systemu porządkuje jeden projekt, ale z perspektywy zgodności kluczowy jest widok globalny: lista wszystkich systemów AI, ich kategorii ryzyka i właścicieli. Taki rejestr może być prostym arkuszem lub dedykowanym narzędziem, o ile spełnia kilka kryteriów.

• Kompletność – obejmuje zarówno systemy w produkcji, jak i w fazie pilotażu lub proof-of-concept, jeśli mają kontakt z danymi rzeczywistymi.
• Podstawowe metadane – nazwa, dział odpowiedzialny, rola organizacji (dostawca/użytkownik), kategoria ryzyka, status (planowany, w budowie, w testach, produkcja, wycofany).
• Powiązanie z dokumentacją – link do karty systemu, dokumentacji technicznej, oceny wpływu na prywatność lub prawa podstawowe (jeśli wykonano).
• Daty przeglądów – informacja kiedy ostatnio aktualizowano klasyfikację ryzyka i kiedy planowany jest kolejny przegląd.

Sygnał ostrzegawczy: jeśli organizacja nie potrafi w rozsądnym czasie wygenerować listy wszystkich systemów AI, trudno mówić o realnym zarządzaniu ryzykiem – to raczej zbiór indywidualnych inicjatyw niż kontrolowane portfolio.

Jeżeli rejestr jest częścią standardowego procesu inicjowania projektów IT lub produktowych, łatwiej wychwycić sytuacje, gdy nowy system powinien wejść w kategorię wysokiego ryzyka i wymaga pełnego zestawu wymogów EU AI Act.

Różnice w obowiązkach: dostawca vs użytkownik systemu AI

Jednym z najczęstszych błędów organizacji jest założenie, że „dostawca wszystko załatwi”. EU AI Act jasno rozdziela obowiązki pomiędzy dostawcę (provider) i użytkownika (deployer), a w praktyce wiele podmiotów pełni obie role równocześnie w różnych projektach.

Obowiązki dostawcy systemu AI

Dostawca to podmiot, który wprowadza system AI do obrotu lub oddaje go do użytku pod własnym imieniem lub znakiem towarowym. W systemach wysokiego ryzyka zakres obowiązków jest najszerszy, ale nawet przy niższych kategoriach istnieją minimalne oczekiwania.

Kluczowe obszary odpowiedzialności dostawcy obejmują:

• Projekt i rozwój – zapewnienie, że system jest projektowany zgodnie z zasadami zarządzania ryzykiem, bezpieczeństwa, jakości danych i nadzoru człowieka.
• Pełna dokumentacja techniczna – przygotowanie i utrzymywanie dokumentacji umożliwiającej ocenę zgodności systemu z wymogami EU AI Act.
• System zarządzania jakością – przy systemach wysokiego ryzyka wdrożenie formalnego systemu (procedury, role, rejestry), który obejmuje cały cykl życia systemu.
• Instrukcje i informacje – przekazanie użytkownikowi jasnych instrukcji użytkowania, ograniczeń systemu, wymagań dotyczących danych wejściowych oraz wymogów dla nadzoru człowieka.
• Monitorowanie po wdrożeniu – plan monitorowania, zbierania informacji zwrotnych od użytkowników oraz reagowania na incydenty i poważne awarie.

Punkt kontrolny: jeśli w organizacji nie ma jasno wyznaczonego właściciela systemu zarządzania jakością dla systemów wysokiego ryzyka, obowiązki dostawcy najczęściej realizowane są fragmentarycznie i reaktywnie. To wprost przekłada się na słabe wyniki audytów i nadmiar pracy ad hoc.

Jeżeli w umowach z klientami pojawiają się zapisy „system jest zgodny z EU AI Act”, ale brak wewnętrznego systemu jakości, który tę zgodność wspiera, jest to wyraźny sygnał ostrzegawczy dla działu prawnego.

Obowiązki użytkownika systemu AI

Użytkownik to podmiot stosujący system AI pod swoją odpowiedzialnością. Nawet jeśli używa rozwiązania dostarczonego przez zewnętrznego dostawcę „as is”, nie może przerzucić wszystkich obowiązków na stronę trzecią. Zakres odpowiedzialności zależy od kategorii ryzyka, ale rdzeń obowiązków pojawia się w większości scenariuszy.

• Właściwe wdrożenie – używanie systemu zgodnie z instrukcjami dostawcy, w zadeklarowanym zakresie i z deklarowanymi typami danych.
• Dobór kontekstu użycia – upewnienie się, że system nie jest wykorzystywany w obszarach wykraczających poza deklarowane zastosowania, szczególnie jeśli mogłoby to podnieść kategorię ryzyka.
• Szkolenie użytkowników końcowych – przygotowanie osób korzystających z systemu (np. rekruterów, lekarzy, analityków kredytowych) do interpretacji wyników i reagowania na błędy.
• Monitorowanie działania – zbieranie informacji o błędach, skargach użytkowników, nietypowych wynikach, a następnie przekazywanie ich dostawcy i podejmowanie działań korygujących.

• Reagowanie na incydenty – opracowanie wewnętrznej procedury zgłaszania poważnych incydentów (np. istotne błędy decyzyjne, naruszenia praw podstawowych) oraz ich dokumentowania na potrzeby kontaktu z dostawcą i – w systemach wysokiego ryzyka – ewentualnego raportowania do organów.
• Przegląd adekwatności systemu w czasie – cykliczna ocena, czy system nadal spełnia potrzeby biznesowe, wymogi prawne oraz wewnętrzne standardy etyczne, szczególnie po zmianach modeli lub danych.

Punkt kontrolny: jeżeli organizacja traktuje system AI jak zwykłe narzędzie „plug-and-play”, bez przypisania właściciela biznesowego i procesu monitorowania, w praktyce porzuca obowiązki użytkownika. Jeżeli dział operacyjny dowiaduje się o poważnych błędach tylko z indywidualnych skarg, brak jest podstawowego mechanizmu wczesnego ostrzegania.

Jeśli użytkownik ma jasno opisaną procedurę wdrażania, monitorowania i wycofywania systemu AI, łatwiej powiązać codzienną praktykę z wymaganiami EU AI Act i obronić się przed zarzutem „pozostawienia systemu samemu sobie”.

Umowy i podział odpowiedzialności: jak nie zostać z luką w zgodności

Przy systemach dostarczanych przez podmioty trzecie kluczowa staje się warstwa kontraktowa. Nawet najlepsza dokumentacja po stronie dostawcy nie zastąpi jasnego ustalenia, kto za co odpowiada w całym cyklu życia systemu.

W umowach i aneksach dotyczących systemów AI warto wprost uregulować:

• Dostęp do dokumentacji – jakie elementy dokumentacji technicznej i oceny ryzyka dostawca udostępnia użytkownikowi, w jakiej formie i z jaką częstotliwością są aktualizowane.
• Zakres deklarowanej zgodności – czy deklaracja „zgodności z EU AI Act” dotyczy konkretnej kategorii ryzyka, wersji systemu, określonych scenariuszy użycia.
• Zmiany modeli i funkcji – sposób informowania o releasach, zmianach w modelach, metrykach jakości, znanych ograniczeniach (model cards, release notes), wraz z terminami powiadomień.
• Incydenty i skargi – czas reakcji na zgłoszenia użytkownika, obowiązek wspólnej analizy zdarzeń poważnych oraz sposób dzielenia się logami i danymi technicznymi.
• Współpraca przy audytach – zasady udziału dostawcy w audytach regulatora lub audytach wewnętrznych użytkownika, w tym tryb dostarczania materiałów dowodowych.
• Warunki wycofania systemu – minimalne terminy wypowiedzenia, tryb migracji danych, zapewnienie ciągłości działania krytycznych procesów.

Sygnał ostrzegawczy: zapis „dostawca gwarantuje pełną zgodność z wszelkimi mającymi zastosowanie przepisami” bez doprecyzowania, jakie obowiązki biorą na siebie strony, zwykle nie ma większej wartości operacyjnej. W praktyce prowadzi do przerzucania winy po incydencie zamiast do planowego zarządzania ryzykiem.

Jeżeli przed podpisaniem umowy powstaje choćby uproszczona macierz „obowiązek – dostawca – użytkownik – wspólny”, ryzyko luk w zgodności znacząco spada. Jeżeli takiej macierzy brak, dział zgodności będzie później nadrabiał zaległości pod presją czasu i incydentów.

System wysokiego ryzyka: praktyczny „minimum compliance”

Dla systemów zakwalifikowanych jako wysokiego ryzyka EU AI Act przewiduje najbardziej rozbudowany zestaw obowiązków. W praktyce wiele organizacji potrzebuje wersji „minimum, które pozwala przejść audyt”, a dopiero później rozwija dojrzalszy system zarządzania.

Przy systemie wysokiego ryzyka rozsądne minimum obejmuje:

• Formalną klasyfikację i uzasadnienie – udokumentowaną analizę, dlaczego system wpada do konkretnej kategorii z załącznika III (lub dlaczego nie), wraz z przeglądem przez dział prawny.
• System zarządzania jakością – zestaw procedur obejmujących projektowanie, rozwój, testowanie, wdrożenie, monitorowanie i wycofanie, z przypisaniem ról i odpowiedzialności.
• Kompletną dokumentację techniczną – w formacie pozwalającym na przedstawienie jej organom nadzoru oraz jednostkom oceniającym zgodność (jeśli dotyczy).
• Procedurę oceny ryzyka i praw podstawowych – opis kroków identyfikacji, oceny, mitygacji i akceptacji ryzyk, z jasnym śladem decyzji i ich uzasadnienia.
• Mechanizmy nadzoru człowieka – zdefiniowane punkty, w których człowiek może skorygować, zakwestionować lub nadpisać wynik systemu; kryteria eskalacji przypadków nietypowych.
• Plan monitorowania po wdrożeniu – progi alarmowe, zestaw metryk, sposób zbierania danych o błędach oraz harmonogram regularnych przeglądów.
• Procedurę zgłaszania poważnych incydentów – wraz z kryteriami uznania incydentu za „poważny” w rozumieniu AI Act i mapą odpowiedzialności za raportowanie zewnętrzne.

Punkt kontrolny: jeśli na pytanie „gdzie jest opisana procedura zgłaszania poważnych incydentów?” odpowiedź brzmi „w sumie reagujemy ad hoc”, system nie spełnia minimalnych oczekiwań dla wysokiego ryzyka. Jeżeli z kolei wszystkie procedury istnieją, ale nikt w zespole operacyjnym nie potrafi ich streścić, oznacza to compliance jedynie „na papierze”.

Jeżeli system wysokiego ryzyka ma jasno określone, proste minimum operacyjne (kto co robi, kiedy, w jakim narzędziu), jego właściciel potrafi bronić się przed zarzutem zaniedbania. Jeżeli tego minimum brak, każdy incydent będzie interpretowany jako dowód braku nadzoru.

Systemy ogólnego przeznaczenia i GAI: dodatkowe wyzwania

Modele ogólnego przeznaczenia (GPAI), w tym generatywne, wprowadzają dodatkową warstwę złożoności. Często są wykorzystywane jako komponenty innych systemów, co komplikuje przypisanie odpowiedzialności i klasyfikację ryzyka.

Przy korzystaniu z modeli GPAI (np. API modelu językowego) warto przejść przez uproszczony zestaw pytań kontrolnych:

• Rola modelu w procesie – czy generatywny komponent podejmuje decyzje automatycznie, czy tylko wspiera człowieka (np. sugeruje tekst, szkic decyzji, podsumowanie)?
• Stopień automatyzacji – czy wynik modelu jest zawsze przeglądany przez człowieka, czy tylko w określonych przypadkach (np. powyżej progów ryzyka, przy niskiej pewności modelu)?
• Rodzaj danych wejściowych – czy system operuje na danych wrażliwych, dotyczących osób fizycznych, czy raczej na treściach ogólnych?
• Potencjalne skutki błędów – czy błąd modelu może skutkować naruszeniem praw jednostki, decyzją administracyjną, finansową, zdrowotną, czy raczej stratą czasu lub reputacji?
• Kontrola treści wyjściowych – jakie istnieją zabezpieczenia przed generowaniem treści szkodliwych, dyskryminujących, wprowadzających w błąd (filtry, reguły, drugi model moderacyjny)?

Sygnał ostrzegawczy: stwierdzenie „to tylko asystent oparty o GPT, nie trzeba go klasyfikować” zwykle oznacza, że organizacja nie przeanalizowała, w jakich dokładnie procesach asystent jest wykorzystywany. Ten sam model użyty w obsłudze helpdesku i w procesie oceny wiarygodności kredytowej to dwa zupełnie różne profile ryzyka.

Jeżeli komponent generatywny ma jasno zdefiniowaną rolę i granice (np. „tworzy sugestie, ale nie może samodzielnie zatwierdzić decyzji”), łatwiej utrzymać go w niższej kategorii ryzyka. Jeśli granice są rozmyte, w trakcie audytu trudno obronić tezę o „pomocniczym” charakterze systemu.

Ocena wpływu na prawa podstawowe: kiedy i jak ją przeprowadzić

W wielu przypadkach, szczególnie przy wysokim ryzyku, konieczna lub silnie rekomendowana staje się formalna ocena wpływu na prawa podstawowe (fundamental rights impact assessment). Dobrze zaprojektowany proces nie musi być rozbudowany – musi być przede wszystkim konkretny.

Praktyczny szkielet takiej oceny może obejmować:

• Identyfikację kategorii osób – kto jest dotknięty działaniem systemu (klienci, kandydaci do pracy, obywatele, pracownicy wewnętrzni)?
• Mapę decyzji – jakie decyzje wspiera lub podejmuje system (np. przyjęcie/odrzucenie wniosku, przydział priorytetu, ocena ryzyka) oraz jakie prawa mogą być dotknięte (równe traktowanie, prawo do prywatności, prawo do skutecznego środka odwoławczego).
• Scenariusze nadużyć – w jaki sposób system mógłby zostać wykorzystany poza zamierzonym celem, w tym przez osoby wewnątrz organizacji (function creep).
• Środki mitygacji – zastosowane ograniczenia (np. brak użycia określonych danych, obowiązkowa weryfikacja decyzji przez człowieka, dodatkowe przeglądy przypadków z grup chronionych).
• Ocena rezydualna – jakie ryzyko pozostaje po wdrożeniu środków mitygacji i kto zaakceptował tę ocenę (z datą i uzasadnieniem).

Punkt kontrolny: jeżeli dokument „ocena wpływu na prawa podstawowe” powstaje dopiero na etapie końcowym, jako ćwiczenie biurowe przed audytem, zwykle nie odzwierciedla rzeczywistych decyzji projektowych. Jeżeli natomiast jest aktualizowany przy każdej istotnej zmianie funkcji lub danych, staje się realnym narzędziem kontroli.

Jeśli właściciel biznesowy potrafi na podstawie tej oceny wyjaśnić, dlaczego system nie używa konkretnych atrybutów (np. danych o niepełnosprawności), to znak, że dokument nie jest tylko formalnością. Jeśli nie, audytorzy szybko wychwycą niespójności między praktyką a deklaracjami.

Monitoring po wdrożeniu: od metryk technicznych do wskaźników ryzyka

Sam fakt przejścia przeglądów przedwdrożeniowych nie gwarantuje utrzymania zgodności w czasie. Kluczowe jest powiązanie monitoringu technicznego z monitorowaniem ryzyk prawnych i operacyjnych.

Przy projektowaniu monitoringu warto wyszczególnić co najmniej trzy warstwy:

• Metryki techniczne – stabilność modeli (accuracy, recall, precision, RMSE itd.), drift danych, liczba błędów aplikacyjnych, czasy odpowiedzi.
• Metryki biznesowe – wpływ na wskaźniki procesowe (np. czas obsługi, odsetek odrzuconych wniosków, liczba odwołań od decyzji), w podziale na istotne segmenty użytkowników.
• Wskaźniki ryzyka i zgodności – liczba skarg formalnych, poważnych incydentów, zgłoszeń do działu compliance, odsetek przypadków skorygowanych przez człowieka.

Sygnał ostrzegawczy: system raportuje tylko „accuracy na zbiorze walidacyjnym”, a brak jest jakichkolwiek wskaźników dotyczących wpływu na użytkowników lub liczby odwołań od decyzji. Taki monitoring pokazuje jedynie kondycję modelu, nie zaś to, czy system zachowuje się w granicach akceptowalnego ryzyka.

Jeżeli raport z monitoringu można w prosty sposób połączyć z kartą systemu i oceną ryzyka (np. widać, że wzrost odsetka skarg z danego regionu koreluje z aktualizacją modelu), organizacja ma realny mechanizm uczenia się. Jeżeli raporty są rozproszone i nikt ich nie składa w całość, kolejne problemy będą powtarzać się w różnych projektach.

Zmiany w systemie AI: kiedy aktualizować klasyfikację i dokumentację

Większość systemów AI nie jest statyczna – modele są dostrajane, dane się zmieniają, pojawiają się nowe funkcje. Z perspektywy EU AI Act istotne jest rozróżnienie między zmianą czysto techniczną a „istotną modyfikacją”, która może wymagać ponownej oceny zgodności.

Przy każdej zmianie warto przejść przez krótką listę kontrolną:

• Zmiana celu lub kontekstu użycia – czy system jest używany w nowym procesie biznesowym, nowym kraju, nowej grupie użytkowników?
• Zmiana danych wejściowych – czy dodano nowe typy danych (szczególnie wrażliwych) lub zmieniono źródła danych w sposób, który może wpłynąć na profil ryzyka?
• Zmiana modeli – czy zmienił się typ modelu (np. przejście z klasycznego modelu na duży model językowy), architektura lub główne hiperparametry w sposób wpływający na zachowanie systemu?
• Zmiana interfejsu dla użytkownika – czy użytkownik otrzymuje inną formę wyjaśnień, inne komunikaty ostrzegawcze, inne opcje odwołania od decyzji?
• Wpływ na ryzyka zidentyfikowane wcześniej – czy zmiana zwiększa prawdopodobieństwo wystąpienia któregoś z wcześniej zidentyfikowanych ryzyk lub wprowadza nowe ryzyka materialne?

Punkt kontrolny: jeśli releasy systemu są częste, a dokumentacja (karta systemu, dokumentacja techniczna, ocena ryzyka) jest aktualizowana rzadko lub nigdy, prędzej czy później pojawi się rozjazd między tym, co opisane, a tym, co działa w produkcji. To pierwszy punkt zaczepienia dla audytorów i regulatorów.

Jeżeli każda istotna zmiana przechodzi przez prostą bramkę: „czy wymaga aktualizacji klasyfikacji, dokumentacji, oceny ryzyka?”, system ewoluuje kontrolowanie. Jeżeli bramki brak, klasyfikacja z czasu pierwszego wdrożenia staje się po kilku releasach bezwartościowa.

Najczęściej zadawane pytania (FAQ)

Co to jest system AI w rozumieniu EU AI Act?

EU AI Act traktuje jako system AI niemal każdy system obliczeniowy, który na podstawie danych generuje wynik wpływający na rzeczywistość: treść, rekomendację, przewidywanie lub decyzję. W tej definicji mieszczą się zarówno klasyczne modele ML (np. regresja logistyczna, drzewa, sieci neuronowe), jak i systemy eksperckie oparte na regułach czy scoringi ryzyka, jeżeli ich wyjście realnie wpływa na ludzi lub zasoby.

Jeśli algorytm tylko sortuje listę w UI albo drukuje raport bez wpływu na decyzje wobec osób czy zasobów, może zostać potraktowany jako narzędzie o minimalnym ryzyku. Punkt kontrolny: jeśli komponent „uczy się” na danych lub automatycznie ustala wynik na podstawie reguł czy modeli, zakładaj, że to system AI i doprecyzuj klasyfikację, zamiast próbować dowodzić, że „to tylko kalkulator”.

Kogo dotyczy EU AI Act i czy obejmie firmę spoza UE?

EU AI Act dotyczy podmiotów w zależności od miejsca użycia systemu i wpływu na osoby w UE, a nie tylko od siedziby firmy. Podlegasz regulacji, jeśli tworzysz lub dostarczasz system AI na rynek UE (sprzedaż, licencja, SaaS), używasz systemu AI na terytorium UE, importujesz lub dystrybuujesz system AI w UE albo gdy system działa poza UE, ale jego wyniki dotyczą osób w Unii (np. zdalny scoring klientów z Polski).

Dla audytora sygnałem ostrzegawczym jest przekonanie, że „jesteśmy poza UE, więc nas to nie dotyczy”. Punkt kontrolny: jeśli jakakolwiek decyzja generowana przez Twój system dotyczy osoby przebywającej w UE, przygotuj się na stosowanie EU AI Act, niezależnie od lokalizacji serwerów czy spółki matki.

Jak odróżnić w EU AI Act rolę dostawcy (provider) od użytkownika (deployer)?

Dostawca to podmiot, który rozwija system AI (samodzielnie lub na zlecenie), wprowadza go do obrotu lub oddaje do użytku pod własną marką. To może być software house sprzedający produkt, firma SaaS z komponentami AI albo duża organizacja, która buduje system dla własnych jednostek biznesowych. Użytkownik to organizacja, która stosuje gotowy system AI w swoich procesach zawodowych, decydując o konkretnych scenariuszach użycia i nadzorze.

Obowiązki są różne: dostawca odpowiada za projekt, zarządzanie ryzykiem, dane treningowe, dokumentację techniczną i testy, a użytkownik za sposób wdrożenia, nadzór ludzki, interpretację wyników, szkolenie personelu i informowanie osób, których dotyczą decyzje. Punkt kontrolny: jeśli tworzysz system i sam go wykorzystujesz, pełnisz podwójną rolę (dostawca + użytkownik) i Twoje polityki muszą obejmować oba zestawy wymagań.

Od kiedy zaczynają się obowiązki z EU AI Act dla mojego systemu?

Kluczowe są dwa momenty: „wprowadzenie do obrotu” oraz „oddanie do użytku”. Wprowadzenie do obrotu to pierwsze udostępnienie systemu AI na rynku UE (sprzedaż, licencja, wynajem, SaaS), niezależnie od tego, czy jest odpłatny. Oddanie do użytku to pierwsze realne zastosowanie systemu przez użytkownika do konkretnych celów w środowisku produkcyjnym, a nie w testach wewnętrznych lub eksperymentalnych sandboxach.

Do etapu testów pilotażowych możesz mieć większą elastyczność, ale od pierwszego użycia wobec prawdziwych osób lub procesów istotnych biznesowo system powinien być zgodny z wymogami. Sygnał ostrzegawczy to „wieczny pilot”, który trwa miesiącami lub latami tylko po to, aby uniknąć formalnej odpowiedzialności. Minimum to udokumentowana data wprowadzenia/oddania do użytku i opis stanu zgodności na ten dzień.

Jak sklasyfikować system według poziomów ryzyka w EU AI Act?

Klasyfikację prowadzi się w formie logicznego lejka, bazując na zastosowaniu, a nie na samej technologii. Krok po kroku należy odpowiedzieć: czy system jest zakazany; jeśli nie – czy jest wysokiego ryzyka (obecny w obszarach z załącznika III); jeśli nie – czy podlega wymogom ograniczonego ryzyka (głównie przejrzystość); jeśli żaden z tych poziomów nie pasuje, system zwykle trafia do kategorii minimalnego ryzyka.

Ten schemat wymusza przejście przez wszystkie pytania w ustalonej kolejności. Najczęstszy błąd to „przeskakiwanie” od razu do stwierdzenia, że system jest niskiego ryzyka, bez sprawdzenia, czy nie wchodzi w zakres zakazów lub wysokiego ryzyka. Punkt kontrolny: każda macierz klasyfikacyjna powinna zaczynać się od pytania o praktyki zakazane i listę przypadków z załącznika III, dopiero potem przechodzić do oceny ograniczonego i minimalnego ryzyka.

Jakie systemy AI są zakazane przez EU AI Act?

EU AI Act zakazuje wąskiej, ale szczególnie wrażliwej grupy zastosowań, w których liczy się efekt i intencja użycia. Chodzi m.in. o systemy wykorzystujące podprogowe techniki manipulacyjne, które mogą zniekształcać zachowanie użytkownika i prowadzić do szkody, a także systemy, które żerują na słabościach określonych grup (dzieci, osoby w trudnym położeniu) w celu wpływania na ich decyzje. W tym obszarze analiza ryzyka musi być szczególnie precyzyjna.

Jeżeli projektujesz system, który ma wpływać na zachowania użytkowników, np. w kontekście zdrowia, finansów czy dzieci, pierwszym krokiem jest sprawdzenie, czy nie wchodzisz w obszar zakazany. Sygnał ostrzegawczy: modele „growth hackingowe”, które celowo wykorzystują mechanizmy uzależniające lub presję, bez żadnych zabezpieczeń, często zbliżają się do granicy zakazów.

Jakie role w organizacji muszą znać podstawy EU AI Act?

Minimalny zestaw ról, które powinny mieć wspólny słownik i rozumienie EU AI Act, to: product owner, prawnik/compliance oraz lider techniczny. Product owner musi rozumieć kategorie ryzyka i scenariusze użycia, prawnik zna strukturę aktu i przekłada ją na polityki oraz umowy, a lider techniczny wie, jakie informacje o architekturze, danych, testach i monitoringu są potrzebne do dokumentacji technicznej i audytu.

Jeżeli te trzy role nie komunikują się wspólnie, dokumentacja jest zwykle niepełna – albo zbyt techniczna, albo zbyt prawna, bez opisu rzeczywistego wpływu systemu. Punkt kontrolny: zorganizuj wspólny warsztat, w trakcie którego zespół klasyfikuje system, przypisuje role (dostawca/użytkownik) i wypełnia kartę systemu AI; brak takiego ćwiczenia na starcie to sygnał ostrzegawczy przy każdym audycie zgodności.

Bibliografia i źródła

• Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (AI Act). Official Journal of the European Union (2024) – Pełny tekst EU AI Act: definicje, role, obowiązki, załączniki
• Proposal for a Regulation laying down harmonised rules on artificial intelligence (Artificial Intelligence Act) COM(2021) 206 final. European Commission (2021) – Uzasadnienie regulacji, cele, kontekst ryzyka i zakres podmiotowy
• AI Act: first regulation on artificial intelligence. European Parliament (2024) – Przegląd struktury aktu, kategorie ryzyka, systemy zakazane i wysokiego ryzyka
• ISO/IEC 22989:2022 Artificial intelligence — Concepts and terminology. ISO (2022) – Standard terminologiczny AI, pomocny przy definiowaniu systemu AI
• OECD Framework for the Classification of AI Systems. OECD (2022) – Metody klasyfikacji systemów AI wg celu, kontekstu i wpływu na ludzi
• Ethics Guidelines for Trustworthy AI. European Commission High-Level Expert Group on AI (2019) – Zalecenia etyczne, nadzór ludzki, rola użytkownika i dostawcy