Jak wdrożyć AI Act? 16 przewodników AESIA w praktyce

Hiszpańska Agencja Nadzoru nad Sztuczną Inteligencją (AESIA) wydała 16 przewodników, które tłumaczą, jak stosować AI Act w praktyce – od oceny zgodności, przez zarządzanie ryzykiem, po dokumentację techniczną. Nie są one wiążące prawnie. Są za to najbardziej konkretnym materiałem, jaki dotąd opublikował którykolwiek europejski organ nadzoru nad AI.

Przewodniki trafiają w dobry moment. Unijne rozporządzenie Digital Omnibus on AI przesunęło najcięższe obowiązki dotyczące systemów wysokiego ryzyka na 2 grudnia 2027 r., a polska Komisja Rozwoju i Bezpieczeństwa Sztucznej Inteligencji dopiero się organizuje. To okno czasowe, w którym można spokojnie uporządkować kwestie zgodności z AI Act, zamiast robić to pod presją terminu.

Najważniejsze wnioski

• AESIA opublikowała 16 dokumentów po AI Act: dwa przewodniki wprowadzające, trzynaście przewodników technicznych oraz jedną instrukcję korzystania z checklist.
• Przewodniki nie są aktem prawnym. To wytyczne wypracowane w hiszpańskiej piaskownicy regulacyjnej w zakresie AI – niewiążące, ale merytorycznie najbliższe temu, czego oczekuje organ nadzoru.
• Obowiązki dotyczące samodzielnych systemów wysokiego ryzyka z załącznika III do AI Act stosuje się od 2 grudnia 2027 r., a te dotyczące systemów AI w produktach z załącznika I Act Act – od 2 sierpnia 2028 r. (Digital Omnibus on AI).
• Od 2 sierpnia 2026 r. stosuje się już wymogi w zakresie przejrzystości z art. 50 AI Act: oznaczanie treści syntetycznych, informowanie o kontakcie z AI, ujawnianie deepfake’ów.
• W Polsce nadzór przejmie KRiBSI, powołana ustawą o systemach sztucznej inteligencji, która weszła w życie 11 sierpnia 2026 r.
• Największa wartość przewodników: małe zespoły compliance dostają gotową strukturę pracy i nie muszą wymyślać jej od zera.

Czym są przewodniki AESIA i gdzie je znaleźć?

To zestaw 16 dokumentów przygotowanych przez hiszpański organ nadzoru nad sztuczną inteligencją. Powstały one jako produkt uboczny hiszpańskiej piaskownicy regulacyjnej w zakresie AI: przez cały 2025 r. uczestniczące w niej firmy pracowały z ekspertami agencji nad realnymi problemami wdrożeniowymi. Przewodniki są zapisem ustaleń z tej współpracy.

Wszystkie są dostępne bezpłatnie na stronie AESIA po hiszpańsku i po angielsku. Sam organ formułuje ich cel wprost: mają wspierać wdrażanie i przestrzeganie europejskich przepisów o sztucznej inteligencji.

Podział jest trójstopniowy:

• przewodniki 1 i 2 (wprowadzające) – podstawowe pojęcia AI Act i praktyczne przykłady ułatwiające ich zrozumienie,
• przewodniki 3–15 (techniczne) – po jednym na każdy wymóg dotyczący systemów wysokiego ryzyka: ocena zgodności, jakość, ryzyko, nadzór człowieka, dane, przejrzystość, dokładność, solidność, cyberbezpieczeństwo, rejestry, monitorowanie po wprowadzeniu do obrotu, incydenty, dokumentacja,
• przewodnik 16 (do samooceny) – instrukcja korzystania z checklist dołączonych do pakietu jako osobny plik.

Rozbicie na 16 dokumentów zamiast jednego opasłego tomu było dobrą decyzją. Do przewodnika o cyberbezpieczeństwie sięga się inaczej niż do przewodnika o dokumentacji technicznej – i zwykle sięga po nie kto inny.

Czy przewodniki AESIA są wiążące dla polskich firm?

Nie. Przewodniki nie są aktem prawnym ani nawet wytycznymi skierowanymi do polskiego rynku. To dokumenty hiszpańskiego organu, które nie tworzą obowiązków po stronie podmiotów działających w Polsce. Wiążące są wyłącznie AI Act i przepisy krajowe.

Przewodniki mają jednak spore znaczenie praktyczne. Po pierwsze, wydał je organ nadzoru, a nie kancelaria czy firma doradcza. Po drugie, europejskie organy nadzorcze mają silną skłonność do przejmowania rozwiązań wypracowanych przez odpowiedniki z innych państw. Ten mechanizm znamy dobrze z RODO – wytyczne jednego organu potrafiły ukształtować praktykę w całej Unii.

W Polsce nadzór nad rynkiem AI ma sprawować Komisja Rozwoju i Bezpieczeństwa Sztucznej Inteligencji (KRiBSI), powołana ustawą o systemach sztucznej inteligencji. Ustawa weszła w życie 11 sierpnia 2026 r. Przewodniczącego komisji Sejm ma powołać w ciągu dwóch miesięcy, a pełny skład ma być gotowy w ciągu trzech miesięcy – realnie oznacza to rozpoczęcie prac na przełomie października i listopada 2026 r.

KRiBSI nie ma jeszcze własnego dorobku interpretacyjnego. Dopóki go nie zbuduje, materiał AESIA jest najlepszym dostępnym punktem odniesienia. Z jednym zastrzeżeniem, które trzeba postawić uczciwie: rekomendacje z przewodników nie przełożą się jeden do jednego na realia konkretnej organizacji. To wsparcie metodyczne, nie gotowa dokumentacja do podpisu.

Ile czasu zostało na wdrożenie AI Act?

Więcej, niż zakładano jeszcze rok temu. Rozporządzenie (UE) 2026/1744, zwane Digital Omnibus on AI, zostało opublikowane 24 lipca 2026 r. i weszło w życie trzy dni później. Zmieniło terminy stosowania AI Act, ale go nie zawiesiło.

Aktualny harmonogram przedstawia się następująco:

• 2 lutego 2025 r. – zakazane praktyki AI oraz obowiązek zapewnienia kompetencji w zakresie AI (art. 4).
• 2 sierpnia 2025 r. – obowiązki dostawców modeli AI ogólnego przeznaczenia (GPAI).
• 2 sierpnia 2026 r. – obowiązki przejrzystości z art. 50: informowanie o kontakcie z systemem AI, maszynowo odczytywalne oznaczanie treści syntetycznych, ujawnianie deepfake’ów, informowanie o rozpoznawaniu emocji. Dla systemów wprowadzonych do obrotu przed tą datą przewidziano okres przejściowy na oznaczanie – do 2 grudnia 2026 r.
• 2 grudnia 2027 r. – wymogi dla samodzielnych systemów wysokiego ryzyka z załącznika III (art. 6 ust. 2), łącznie z obowiązkami podmiotów stosujących.
• 2 sierpnia 2028 r. – wymogi dla AI wbudowanej w produkty objęte unijnym prawodawstwem harmonizacyjnym z załącznika I (art. 6 ust. 1).

Powód przesunięcia podano wprost: opóźnienia w wyznaczaniu krajowych organów nadzoru zagrażały skutecznemu stosowaniu przepisów. Polska jest tego podręcznikowym przykładem.

Wniosek dla planowania: przewodniki AESIA opisują głównie wymogi, które zaczną obowiązywać w grudniu 2027 r. Kto potraktuje przesunięcie jako powód do odłożenia tematu, straci dokładnie ten czas, który regulator właśnie przyznał. Zarządzanie ryzykiem, dokumentacja techniczna i system zarządzania jakością to procesy, których nie buduje się w kwartał.

Przewodniki 1 i 2: podstawy i przykłady

Przewodnik 1 wprowadza w zakres stosowania AI Act oraz wyjaśnia podział systemów AI na cztery kategorie ryzyka: systemy zakazane, wysokiego ryzyka, objęte obowiązkami przejrzystości oraz pozostałe. Omawia też różnicę między dostawcą systemu AI a podmiotem stosującym. To rozróżnienie w praktyce przesądza o tym, które obowiązki ciążą na konkretnej organizacji.

Osobne miejsce zajęły modele AI ogólnego przeznaczenia (GPAI), w tym duże modele językowe. Ich dostawcy muszą przede wszystkim:

• zapewnić przejrzystość działania modelu,
• opracować dokumentację techniczną,
• przestrzegać przepisów o prawie autorskim,
• ocenić i ograniczyć ryzyka związane z wykorzystaniem modelu,
• zgłaszać poważne incydenty.

Jeśli model uczy się na danych osobowych albo je przetwarza w trakcie eksploatacji, oprócz AI Act stosuje się RODO. O tym, jak dobrać w takiej sytuacji podstawę prawną przetwarzania przy wykorzystaniu AI, piszemy osobno.

Przewodnik 2 jest znacznie ciekawszy, bo w całości praktyczny. AESIA buduje w nim zestaw przykładów, do których wraca w każdym kolejnym dokumencie. To jeden z lepszych pomysłów redakcyjnych w całym pakiecie: czytelnik nie musi za każdym razem wchodzić w nowy kontekst.

Przykłady systemów AI wysokiego ryzyka, którymi posługuje się AESIA:

• Biometryczny system rejestracji czasu pracy – kamery lub czujniki rozpoznają pracownika i zapisują wejścia oraz wyjścia bez jego udziału.
• System wspierający decyzje o awansach – analizuje wyniki, kompetencje i inne zmienne, a następnie rekomenduje osoby do awansu.
• System przewidujący ryzyko wykluczenia społecznego – w administracji publicznej wspiera kwalifikację do świadczeń na podstawie dochodu, wykształcenia lub miejsca zamieszkania.
• Inteligentna pompa insulinowa – monitoruje poziom glukozy, analizuje dane zdrowotne i wylicza dawkę insuliny.
• System wykrywania fałszywych zgłoszeń – ocenia prawdopodobieństwo, że zgłoszenie przestępstwa jest nieprawdziwe.

Dwa pierwsze przykłady dotyczą obszaru HR i to one najczęściej okażą się realne dla polskich firm. Warto je zestawić z tym, co o zautomatyzowanym podejmowaniu decyzji mówi art. 22 RODO – oba reżimy stosuje się równolegle, a nie zamiennie. Szerzej piszemy o tym w tekście o relacji AI Act i RODO.

Przewodnik 2 wyjaśnia też pojęcia, które w AI Act wydają się oczywiste, a w praktyce takie nie są: różnicę między danymi treningowymi, testowymi i walidacyjnymi, znaczenie „istotnej zmiany" systemu, przeznaczenie systemu AI oraz różnicę między wprowadzeniem do obrotu a udostępnieniem na rynku.

Przewodnik 3: ocena zgodności systemu AI

Ocena zgodności to proces weryfikacji, czy system AI wysokiego ryzyka spełnia wymogi z sekcji 2 rozdziału III AI Act. Definicję zawiera art. 3 pkt 20 AI Act.

Przewodnik 3 opisuje kryteria prawidłowej oceny i dwie drogi jej przeprowadzenia – samobadanie albo badanie przez jednostkę notyfikowaną. Reguła praktyczna jest prosta: dla większości systemów wysokiego ryzyka wystarczy samobadanie. Przy systemach korzystających z biometrii częściej pojawi się konieczność zaangażowania jednostki notyfikowanej.

Najważniejsza teza przewodnika 3 dotyczy jednak czegoś innego. Ocena zgodności to wynik pracy wykonywanej przez cały cykl życia systemu, a nie jednorazowy test przed wdrożeniem. Kto pracował przy RODO, rozpozna ten schemat natychmiast – to ta sama logika co przy analizie ryzyka, która też nie kończy się na jednym dokumencie.

AESIA wskazuje trzy elementy, na których opiera się cała ocena: system zarządzania jakością, dokumentacja techniczna i zarządzanie ryzykiem. Osobno omawia narzędzia pomocnicze – normy zharmonizowane i wspólne specyfikacje – które pozwalają wykazać zgodność szybciej, bo dzięki nim system korzysta z domniemania zgodności.

Przewodniki 4 i 5: jakość i ryzyko

System zarządzania jakością jest obowiązkowy dla systemów wysokiego ryzyka na podstawie art. 17 AI Act. Przewodnik 4 rozbiera każdy element tego przepisu, korzystając z przykładów wprowadzonych wcześniej.

Akcent pada nie tylko na procedury, lecz także na przygotowanie personelu i monitorowanie systemu po wprowadzeniu na rynek. Rola producenta nie kończy się w momencie wypuszczenia produktu. Jeden wniosek z tego przewodnika jest wyraźniejszy niż pozostałe: regulator ocenia procesy organizacyjne, nie elegancję rozwiązania technicznego. System doskonały inżyniersko, ale wdrożony w organizacji bez procedur będzie niezgodny z prawem.

Przewodnik 5 dotyczy art. 9 AI Act, zgodnie z którym dla systemów wysokiego ryzyka ustanawia się, wdraża, dokumentuje i obsługuje system zarządzania ryzykiem. AESIA zauważa, że podejście przeniesione ze „zwykłych” systemów IT tutaj nie wystarczy. Katalog zagrożeń jest inny:

• dyskryminacja algorytmiczna,
• błędne decyzje wpływające na sytuację konkretnych osób,
• naruszenia praw podstawowych,
• brak przejrzystości działania modelu,
• błędy wynikające z jakości danych treningowych,
• skutki społeczne działania systemu.

Sam proces sprowadza się do ośmiu powiązanych kroków: zrozumienie kontekstu działania systemu, identyfikacja zagrożeń, określenie prawdopodobieństwa i skutków, ocena poziomu ryzyka, ustalenie apetytu na ryzyko, wdrożenie środków ograniczających, monitorowanie ich skuteczności i stała aktualizacja oceny.

Jeśli w organizacji funkcjonuje już metodyka analizy ryzyka na potrzeby RODO albo zarządzania ryzykiem zgodnie z NIS 2, nie trzeba budować kolejnej od zera. Punktem wyjścia może być nasz bezpłatny kalkulator analizy ryzyka, rozszerzony o zagrożenia specyficzne dla AI. Digital Omnibus on AI poszedł zresztą w tę samą stronę: ocena skutków dla praw podstawowych (FRIA) może odsyłać do odpowiednich części oceny skutków dla ochrony danych. Metodykę szacowania ryzyka i wyważania interesów omawiamy na szkoleniu: DPIA i analiza ryzyka, a przy złożonych procesach wspieramy klientów w ramach analizy ryzyka RODO.

Przewodnik 6: nadzór nad systemem AI

Na czym polega nadzór człowieka nad systemem AI? Nie na klikaniu „zatwierdź”. Przewodnik 6 jest w tej sprawie bardzo stanowczy: nadzór polega na rozumieniu systemu, skutecznym monitorowaniu go, wykrywaniu błędów, kwestionowaniu rekomendacji oraz na realnej zdolności zatrzymania lub skorygowania jego działania.

AESIA sporo miejsca poświęca zjawisku automation bias, czyli nadmiernemu poleganiu na rekomendacjach maszyny, oraz rozróżnieniu między human-in-the-loop a human-on-the-loop. Najlepiej pokazuje to na pompie insulinowej. Ponieważ natychmiastowe wykonanie decyzji systemu mogłoby zagrozić zdrowiu pacjenta, system musi być zaprojektowany w modelu „człowiek w pętli”: gdy proponuje kolejną dawkę, lekarz prowadzący weryfikuje ją lub koryguje na podstawie parametrów krwi i dopiero wtedy dawka może zostać podana.

Osobny wątek dotyczy konstrukcji interfejsu. Nadzór staje się pozorny, jeśli interfejs nie daje człowiekowi tego, czego potrzebuje on do oceny.

Przewodnik 6 wskazuje typowe błędy, które przekreślają realny nadzór:

• człowiek nie ma technicznej możliwości zatrzymania systemu,
• otrzymuje samą rekomendację, bez uzasadnienia i przesłanek,
• decyzje wykonują się automatycznie, bez punktu kontrolnego,
• osoba sprawująca nadzór nie ma kompetencji do oceny wyniku,
• organizacja wywiera presję na szybkie akceptowanie rekomendacji.

Ostatni punkt jest najtrudniejszy do naprawienia, bo nie leży po stronie technologii. To ten sam problem, który obserwujemy przy shadow AI: kultura pracy wyprzedza procedury. Podobnie jest przy ryzyku ukrytym w treści promptu – pracownik nie widzi problemu, dopóki nikt mu go nie pokaże.

Przewodniki 7–9: dane, przejrzystość i dokładność

Przewodnik 7 stawia tezę, którą warto zapamiętać: jakość systemu nigdy nie będzie wyższa niż jakość danych, na których go zbudowano. Dostawca musi wiedzieć, skąd dane pochodzą, jakie mają ograniczenia, jakie ryzyka generują i jak wpływają na wyniki systemu.

Ilustracją jest system rekomendujący awanse. Analizuje historię zatrudnienia, wyniki pracy, wcześniejsze awanse i oceny okresowe. Jeśli organizacja częściej awansowała określone grupy pracowników, model odtworzy ten wzorzec i będzie preferował właśnie te grupy. Droga do zarzutu dyskryminacji jest wtedy bardzo krótka. Mechanizm jest zresztą ten sam, który opisujemy przy profilowaniu na gruncie RODO.

Najtrafniejsza konkluzja tego przewodnika ociera się o frazes, ale broni się w praktyce: słaby model na dobrych danych da się ulepszyć, dobrego modelu wytrenowanego na złych danych – raczej nie.

Przewodnik 8 porządkuje przejrzystość. Nie oznacza ona ujawnienia kodu źródłowego ani szczegółów technicznych modelu. Chodzi o przekazanie informacji pozwalających zrozumieć, do czego system służy, jak go używać, jakie ma ograniczenia, jakie zagrożenia wiążą się z korzystaniem z niego i kiedy nie należy ufać jego wynikom. Kluczowym dokumentem jest instrukcja obsługi.

Zależność między przewodnikami 6 i 8 jest bezpośrednia. Brak informacji o ograniczeniach systemu uniemożliwia skuteczny nadzór człowieka, bo nadzorujący nie wie wtedy, czego szukać. Przejrzystość nie jest tu obowiązkiem dokumentacyjnym, tylko warunkiem wykonalności innych obowiązków.

Przewodnik 9 dotyczy dokładności i zawiera rozróżnienie, które łatwo przeoczyć: dokładność osiągana podczas trenowania modelu to nie to samo co dokładność utrzymywana w eksploatacji. System powinien utrzymywać deklarowany poziom przez cały cykl życia. Osobno omówiono overfitting, czyli przeuczenie modelu – świetne wyniki na danych treningowych i słabe na nowych.

Przewodnik 10: solidność a dokładność

Dokładność odpowiada na pytanie, jak często system daje poprawny wynik. Solidność odpowiada na inne: czy system zachowuje się prawidłowo, gdy coś pójdzie nie tak. AESIA definiuje solidność jako zdolność do minimalizowania niepożądanych zachowań, wykrywania sytuacji wykraczających poza przewidziane warunki działania i unikania błędnych decyzji wpływających na bezpieczeństwo lub prawa podstawowe.

Wróćmy do pompy insulinowej: solidny system powinien powstrzymać się od generowania kolejnych decyzji, gdy brakuje danych albo gdy czujnik uległ uszkodzeniu. Jego zadaniem jest wykryć anomalię, zasygnalizować ją użytkownikowi i uruchomić mechanizm awaryjny.

Najcenniejsze spostrzeżenie przewodnika 10 dotyczy natury awarii. Zwykły system IT po prostu przestaje działać – i to jest sygnał czytelny dla każdego. System AI potrafi dalej generować odpowiedzi i instrukcje, których wiarygodność jest już żadna. Awaria jest cicha – i dlatego groźniejsza.

Przewodnik 11: cyberbezpieczeństwo systemów AI

Klasyczne podejście do bezpieczeństwa tutaj nie wystarcza, bo atakujący chcą czegoś innego. Przewodnik 11 zestawia to wprost. W klasycznym systemie IT celem jest zwykle przejęcie lub zaszyfrowanie danych, przejęcie konta albo wyłączenie usługi. W systemach AI napastnicy próbują zmienić sposób „myślenia” modelu, wpłynąć na proces uczenia, manipulować predykcjami albo odtworzyć dane treningowe.

AESIA omawia m.in. zatruwanie danych treningowych (data poisoning), ataki omijające zabezpieczenia modelu (evasion attack) oraz odtwarzanie danych treningowych (model inversion) i kopiowanie samego modelu (model extraction). Przykłady znów pochodzą z wcześniejszych przewodników:

• Inteligentna pompa insulinowa – manipulacja danymi z czujników, zakłócenie komunikacji urządzenia, błędne dawkowanie, utrata dostępności systemu.
• Biometryczny system rejestracji czasu pracy – obejście mechanizmów identyfikacji, przejęcie danych biometrycznych, fałszywe identyfikacje, nieuprawniony dostęp do zasobów.

Środki zaradcze przewodnik 11 dzieli na organizacyjne (planowanie bezpieczeństwa już na etapie projektowania, wyznaczenie osób odpowiedzialnych, udział ekspertów ochrony danych i cyberbezpieczeństwa, dokumentowanie zagrożeń, regularne przeglądy, szkolenia personelu) oraz techniczne (automatyczne testy bezpieczeństwa, kontrola dostępu, ochrona modeli, monitorowanie infrastruktury, bezpieczne aktualizacje, testy odporności na ataki).

Lista jest znajoma dla każdego, kto wdrażał środki z art. 32 RODO albo pracował przy przygotowaniu do NIS 2. Różnica leży w przedmiocie ochrony: chronimy nie tylko dane, lecz także model i proces jego uczenia. Jeśli budujesz ten obszar od podstaw, zacznij od przeglądu zabezpieczeń technicznych i organizacyjnych, a dopiero potem nakładaj na nie wymogi specyficzne dla AI.

Przewodniki 12–14: logi, monitorowanie i incydenty

Przewodnik 12 dotyczy rejestrowania zdarzeń. Teza jest kategoryczna: bez logów system nie przejdzie testu rozliczalności, przejrzystości ani audytowalności. Jeśli nie da się odtworzyć, dlaczego system podjął taką, a nie inną decyzję, organizacja nie wykaże zgodności z AI Act.

AESIA definiuje log jako zapis zdarzeń zachodzących podczas korzystania z systemu. Może on obejmować informacje o uruchomieniu modelu, danych wejściowych, wynikach działania, interwencji człowieka, błędach systemu, zmianach konfiguracji i incydentach bezpieczeństwa. Lista nie jest zamknięta – zakres należy dopasować do konkretnego systemu. Osobno podkreślono konieczność zabezpieczenia logów przed usunięciem i modyfikacją.

Przewodnik 13 dotyczy nadzoru po wprowadzeniu systemu na rynek i sprowadza się do pięciu pytań, które trzeba zadawać cyklicznie:

• Czy model nadal działa poprawnie?
• Czy nie spadł parametr dokładności?
• Czy pojawiły się nowe ryzyka?
• Czy użytkownicy zgłaszają problemy?
• Czy konieczne są działania naprawcze?

AESIA proponuje dwa tryby: monitoring ciągły (wskaźniki wydajności, alerty, bezpieczeństwo, anomalie) oraz monitoring okresowy w formie przeglądów (skuteczność modelu, zmiany ryzyka, zgodność z AI Act, zasadność aktualizacji).

Przewodnik 14 opisuje identyfikację i obsługę poważnych incydentów. Perspektywa AESIA przypomina podejście organów nadzorczych na gruncie RODO: najgroźniejszy nie jest sam incydent, lecz brak wiedzy o nim albo brak reakcji.

Akurat ten dokument wypada najsłabiej w całym pakiecie. Wracają w nim pompa insulinowa i system oceniający ryzyko wykluczenia społecznego, ale przykłady służą zilustrowaniu etapów postępowania, a nie odpowiedzi na pytanie, które w praktyce sprawia najwięcej kłopotu: czy ten konkretny incydent jest poważny, a więc wymaga zgłoszenia? Szerszy katalog przykładów byłby tu znacznie bardziej użyteczny. Ten sam problem znamy z klasyfikacji naruszeń ochrony danych, gdzie dopiero kalkulator wagi naruszenia daje jakikolwiek zobiektywizowany punkt odniesienia.

Przewodniki 15 i 16: dokumentacja techniczna i checklisty

Dokumentacja techniczna jest głównym dowodem zgodności z AI Act. Pozwala prześledzić cykl życia systemu, zrozumieć jego działanie i ocenić, czy wymogi rozporządzenia zostały faktycznie spełnione.

Przewodnik 15 działa jak instrukcja budowy dokumentacji. Rozkłada na czynniki pierwsze załącznik IV do AI Act i pokazuje, gdzie w strukturze dokumentacji umieścić  efekty pracy wykonanej zgodnie z wcześniejszymi przewodnikami. To najbardziej „spinający” dokument w pakiecie.

Dwie rzeczy warto z niego wynieść osobno. Dokumentację trzeba przechowywać przez 10 lat od wprowadzenia systemu AI na rynek. Żeby to było wykonalne, potrzebne są mechanizmy archiwizacji, kontroli wersji, ochrony integralności i ochrony przed utratą danych – wdrażane od razu, nie w dziewiątym roku.

Przewodnik 16 to instrukcja korzystania z checklist dołączonych do pakietu jako osobny plik. Pozwala sprawdzić, czy obowiązki opisane w przewodnikach 3–15 zostały wykonane. W praktyce jest to narzędzie samooceny oparte wprost na wymogach AI Act – i najlepszy punkt startu, jeśli ktoś nie ma czasu na lekturę całości.

Od czego zacząć wdrożenie AI Act?

Zanim sięgniesz po przewodniki, ustal punkt wyjścia. Kolejność ma znaczenie – większość materiału AESIA dotyczy systemów wysokiego ryzyka, a duża część organizacji żadnego takiego systemu nie ma.

1. Zinwentaryzuj systemy AI faktycznie używane w organizacji, łącznie z narzędziami wdrożonymi przez działy bez wiedzy IT.
2. Ustal rolę: jesteś dostawcą systemu AI czy podmiotem stosującym (a może jednym i drugim).
3. Zaklasyfikuj każdy system: zakazany, wysokiego ryzyka, objęty obowiązkami przejrzystości, pozostały.
4. Sprawdź obowiązki z art. 50 AI Act, które obowiązują już od 2 sierpnia 2026 r. – dotyczą także systemów niebędących systemami wysokiego ryzyka.
5. Zweryfikuj, czy pracownicy mają kompetencje w zakresie AI wymagane przez art. 4.
6. Dla systemów wysokiego ryzyka przejdź checklistę z przewodnika 16 i wypisz luki.
7. Sprawdź, czy istniejąca analiza ryzyka i DPIA dają się rozszerzyć, zamiast budować proces od zera.
8. Ustal właściciela tematu po stronie organizacji – bez tego harmonogram do grudnia 2027 r. nie ruszy.
9. Zaplanuj przegląd cykliczny, a nie jednorazowy projekt.

Punkt pierwszy bywa lekceważony, a to on najczęściej wywraca harmonogram. Inwentaryzacja niemal zawsze ujawnia narzędzia, o których dział compliance nie wiedział.

Punkt siódmy zwykle przynosi najwięcej oszczędności. Organizacje, które prowadzą już pre-DPIA i pełne oceny skutków, mają połowę pracy metodycznej za sobą – brakuje im tylko warstwy specyficznej dla AI. Tam, gdzie ocen jest dużo, a wykonuje je jedna osoba, sensowne bywa wsparcie z zewnątrz w formie outsourcingu funkcji IOD.

Punkt czwarty warto sprawdzić już teraz, bo termin minął. Jeśli organizacja generuje treści, prowadzi chatbota albo publikuje materiały tworzone przez AI, obowiązki przejrzystości stosuje się od 2 sierpnia 2026 r. – niezależnie od przesunięcia wymogów dla systemów wysokiego ryzyka.

Przy systemach przetwarzających dane osobowe zacznij od bezpłatnej checklisty zgodności AI z RODO. Jeśli inwentaryzacja pokaże, że systemów jest więcej niż kilka albo że któryś kwalifikuje się jako system wysokiego ryzyka, sensowniej jest ułożyć całość jako proces – tym zajmujemy się w ramach zarządzania zgodnością z AI.

Komu przewodniki AESIA przydadzą się najbardziej?

Przede wszystkim organizacjom bez rozbudowanego zespołu compliance. Duża kancelaria czy korporacja z własnym działem AI governance wypracuje metodykę samodzielnie. Firma, w której jedna osoba zajmuje się tematem AI oprócz pięciu innych obowiązków, dostaje tu gotową strukturę pracy – i to jest największa wartość tego pakietu.

Przewodniki są przy tym wygodne w użyciu: napisane przejrzyście, z gęstą siecią odsyłaczy wewnętrznych oraz z odesłaniami do konkretnych zagadnień. Korzysta się z nich lepiej niż z typowego dokumentu regulacyjnego.

Czy zapewnią zgodność ze wszystkimi wymogami AI Act? Niekoniecznie. Pozostają dokumentami stosunkowo abstrakcyjnymi, a przełożenie ich na realia konkretnej organizacji i konkretnego systemu to praca, której nikt za czytelnika nie wykona. Ale jako punkt wyjścia i rama porządkująca chaos wdrożeniowy – trudno dziś o coś lepszego.

FAQ – najczęściej zadawane pytania

Czy przewodniki AESIA obowiązują w Polsce?

Nie. Przewodniki AESIA nie są aktem prawnym, lecz niewiążącymi wytycznymi hiszpańskiego organu nadzoru. Nie tworzą obowiązków dla podmiotów działających w Polsce. Mają jednak walor merytoryczny i mogą stanowić punkt odniesienia, dopóki KRiBSI nie wypracuje własnego dorobku interpretacyjnego.

Ile przewodników do AI Act wydała AESIA?

Szesnaście. Dwa mają charakter wprowadzający, trzynaście dotyczy wymogów technicznych stawianych systemom AI wysokiego ryzyka, a jeden jest instrukcją korzystania z checklist samooceny. Do pakietu dołączono osobny plik z checklistami i przykładami. Wszystkie dokumenty są dostępne bezpłatnie na stronie AESIA po hiszpańsku i po angielsku.

Od kiedy stosuje się wymogi AI Act dla systemów wysokiego ryzyka?

Od 2 grudnia 2027 r. dla samodzielnych systemów z załącznika III do AI Act oraz od 2 sierpnia 2028 r. dla AI wbudowanej w produkty objęte unijnym prawodawstwem harmonizacyjnym wymienionym w załączniku I do AI Act. Terminy przesunęło rozporządzenie (UE) 2026/1744 (Digital Omnibus on AI). Pozostałe obowiązki – zakazane praktyki, kompetencje w zakresie AI, wymogi wobec modeli GPAI i przejrzystość z art. 50 – stosuje się już teraz.

Kto nadzoruje przestrzeganie AI Act w Polsce?

Komisja Rozwoju i Bezpieczeństwa Sztucznej Inteligencji (KRiBSI), powołana ustawą o systemach sztucznej inteligencji, która weszła w życie 11 sierpnia 2026 r. To niezależny organ kolegialny obsługiwany przez Ministerstwo Cyfryzacji. Rozpatruje skargi, prowadzi piaskownice regulacyjne i wydaje opinie. Pełny skład ma zostać powołany do listopada 2026 r.

Czy analiza ryzyka z RODO wystarczy do spełnienia wymogów AI Act?

Nie wystarczy, ale jest dobrym punktem wyjścia. AI Act wymaga uwzględnienia zagrożeń nieobecnych w klasycznej analizie: dyskryminacji algorytmicznej, błędów wynikających z niskiej jakości danych treningowych, braku przejrzystości modelu i skutków społecznych. Ocena skutków dla praw podstawowych (FRIA) może natomiast odsyłać do odpowiednich części oceny skutków dla ochrony danych (DPIA).

Czy AI Act dotyczy firm, które tylko korzystają z narzędzi AI?

Tak. AI Act odróżnia dostawcę systemu AI od podmiotu stosującego i nakłada obowiązki na każdego z nich. Podmiot stosujący odpowiada m.in. za zapewnienie nadzoru człowieka, używanie systemu zgodnie z instrukcją i kompetencje personelu. Uwaga: modyfikacja cudzego systemu lub wprowadzenie go pod własną marką może przenieść na organizację obowiązki dostawcy.