Systemy AI wysokiego ryzyka muszą prowadzić kompletny plik techniczny przed wprowadzeniem do obrotu w UE. Art. 11 i Annex IV precyzują dokładnie, co należy uwzględnić — od architektury systemu, przez zarządzanie danymi do trenowania, po plany nadzoru posprzedażowego.

Co to jest Plik Techniczny?

Dokumentacja techniczna — powszechnie nazywana „plikiem technicznym" — to główny pakiet dowodowy demonstrujący, że system AI wysokiego ryzyka spełnia wszystkie wymogi EU AI Act. Nakazany przez Art. 11 i ustrukturyzowany przez Annex IV, musi być sporządzony przed wprowadzeniem systemu do obrotu w UE i aktualizowany przez cały cykl życia systemu.

Plik techniczny nie jest przekazywany centralnie. Dostawca go przechowuje i przedstawia na żądanie organom nadzoru rynku i jednostkom notyfikowanym. To model pull: organy przychodzą do Ciebie; musisz być gotowy do przekazania kompletnego, spójnego pakietu, a nie improwizowanego stosu plików zebranych pod presją.

Art. 11 nakłada na dostawców trzy obowiązki:

  1. Sporządzić przed wprowadzeniem do obrotu lub oddaniem do użytku.
  2. Aktualizować — jakakolwiek istotna zmiana systemu wymaga aktualizacji pliku i ponownej oceny zgodności.
  3. Udostępniać właściwym organom i jednostkom notyfikowanym na żądanie, w określonym terminie (zazwyczaj 10 dni roboczych na podstawie krajowych zasad nadzoru rynku).

Standard dla „aktualności" jest funkcjonalny: plik techniczny musi odzwierciedlać system faktycznie wdrożony, nie system pierwotnie zaprojektowany. Jeżeli aktualizacja modelu zmienia charakterystyki wydajności, progi dokładności lub dane do trenowania, plik musi zostać odpowiednio zaktualizowany.


Kto Potrzebuje Dokumentacji Technicznej?

Dokumentacja techniczna na podstawie Art. 11 i Annex IV jest obowiązkowa dla dostawców:

Dokumentacja techniczna nie jest wymagana dla:

Jeżeli jesteś podmiotem wdrażającym (nie dostawcą), nie jesteś zobowiązany do przygotowania pliku technicznego. Jednak podmioty wdrażające muszą prowadzić logi użycia systemu (Art. 26 ust. 5), a dostawcy są uprawnieni do korzystania z tych logów przy aktualizacji dokumentacji technicznej lub obsłudze zgłoszeń incydentów.


14 Elementów Annex IV

Annex IV określa minimalne treści pliku technicznego. Nie ma sztywnego formatu — dostawcy mogą organizować dokumentację według własnego uznania — ale wszystkie 14 elementów musi być obecnych i merytorycznych. Wpisy tick-box bez potwierdzających dowodów nie spełniają Annex IV.

# Element Annex IV Co musi zawierać
1 Ogólny opis Nazwa systemu, identyfikator wersji, zamierzone przeznaczenie, zamierzeni użytkownicy, rynki geograficzne, nazwa i adres dostawcy, ewentualny upoważniony przedstawiciel
2 Komponenty systemu Wymagania sprzętowe, komponenty oprogramowania, użyte modele lub biblioteki stron trzecich, przegląd metodologii trenowania, podejście algorytmiczne (np. uczenie nadzorowane, uczenie ze wzmocnieniem, architektura transformera)
3 Specyfikacje projektowe Architektura systemu, diagramy przepływu danych, kluczowe decyzje projektowe i ich uzasadnienie, dokonane kompromisy (np. dokładność a wyjaśnialność), format wyjściowy i jak wyjścia są wprowadzane do decyzji niższego szczebla
4 Dane do trenowania, walidacji i testowania Zestawy danych używane na każdym etapie, źródła danych, procedury zarządzania danymi, właściwości statystyczne zestawów danych (rozmiar, rozkład, pokrycie), protokoły przetwarzania i wstępnego przetwarzania danych, środki podjęte w celu wykrycia i usunięcia błędów zestawu danych
5 Dokumentacja zarządzania ryzykiem Kompletny system zarządzania ryzykiem Art. 9: zidentyfikowane ryzyka dla zdrowia, bezpieczeństwa i praw podstawowych; szacowanie i ocena ryzyka; przyjęte środki ograniczania ryzyka; zaakceptowane ryzyka rezydualne; podstawa do akceptacji ryzyk rezydualnych
6 Zmiany cyklu życia Opis wszystkich istotnych modyfikacji dokonanych po wdrożeniu początkowym, ich charakter i zakres, jak ponownie oceniano zgodność po każdej zmianie, historia wersji z datami
7 Środki nadzoru człowieka Jak wdrażane są wymagania Art. 14: mechanizmy nadpisania i zatrzymania, interfejsy umożliwiające ludzkim operatorom monitorowanie wyników, wymagania dotyczące szkolenia lub kwalifikacji operatorów, udokumentowane procedury interwencji człowieka
8 Procedury walidacji i testowania Stosowane metryki wydajności (dokładność, precyzja, recall, F1, AUC, metryki sprawiedliwości), opisy zestawów danych testowych, warunki i środowisko testowe, metodologia testowania uprzedzeń i wyniki, testowanie odporności i stresowe, wydajność out-of-distribution
9 Środki cyberbezpieczeństwa Środki techniczne przeciwko kradzieży modelu, zatruwaniu danych, atakom adversarialnym, wstrzykiwaniu podpowiedzi (dla systemów opartych na LLM), kontrole dostępu, szyfrowanie w tranzycie i w spoczynku, procedury zarządzania podatnościami
10 Monitorowanie uprzedzeń i dokładności Bieżące procedury monitorowania po wdrożeniu, progi dokładności, poniżej których system uruchamia przegląd, benchmarki wydajności w podziale na grupy demograficzne gdzie istotne, procedury reagowania na wykryty dryfting lub uprzedzenia
11 Instrukcje użytkowania Dokument skierowany do podmiotów wdrażających Art. 13: zamierzone przeznaczenie i przypadki użycia, charakterystyki i ograniczenia wydajności, znane ograniczenia, wymagania dotyczące konserwacji i aktualizacji, obowiązki logowania dla podmiotów wdrażających, punkt kontaktowy do zgłaszania incydentów
12 Plan nadzoru posprzedażowego Projekt systemu monitorowania Art. 72: dane zbierane od podmiotów wdrażających, częstotliwość cykli monitorowania, progi uruchamiające przegląd lub aktualizację, procedura zgłaszania poważnych incydentów (Art. 73), procedura przekazywania danych monitorowania z powrotem do zarządzania ryzykiem
13 Opis interfejsów API i punkty integracji, formaty i ograniczenia danych wejściowych, formaty wyjściowe i ich semantyka, integracja z innymi systemami lub komponentami, kompatybilność wersji
14 Zharmonizowane normy i wspólne specyfikacje Lista zastosowanych zharmonizowanych norm (np. ISO/IEC 42001:2023, normy EN w ramach programu standaryzacji EU AI Act), przyjęte wspólne specyfikacje na podstawie Art. 41, zakres zastosowania każdej normy, wszelkie odchylenia i ich uzasadnienie

Praktyczna uwaga dotycząca elementu 4 (dane do trenowania): Annex IV nie wymaga publicznego ujawnienia zestawów danych ani organom domyślnie. Wymaga, aby dokumentacja istniała i mogła zostać udostępniona. Dla zastrzeżonych zestawów danych opis procedur zarządzania danymi, podsumowania statystyczne i wyniki testowania uprzedzeń zazwyczaj spełniają wymaganie bez ujawniania wrażliwych danych komercyjnych.

Praktyczna uwaga dotycząca elementu 14 (normy): Na połowę 2026 r. program standaryzacji EU AI Act jest nadal w toku. ISO/IEC 42001 (systemy zarządzania AI) jest dostępny i szeroko stosowany. Dostawcy powinni monitorować europejską pracę standaryzacyjną w ramach CEN/CENELEC JTC 21 i aktualizować tę sekcję w miarę publikowania zharmonizowanych norm w Dzienniku Urzędowym.


Deklaracja Zgodności UE (Art. 47)

Deklaracja Zgodności UE (EU DoC) to odrębny obowiązkowy dokument — nie jest częścią pliku technicznego, ale się na niego powołuje. EU DoC to formalne oświadczenie dostawcy, że system AI spełnia wszystkie mające zastosowanie wymogi EU AI Act.

Ważna EU DoC musi zawierać:

EU DoC musi być przechowywana przez 10 lat po wprowadzeniu do obrotu i udostępniana na żądanie. Towarzyszy oznakowaniu CE (patrz poniżej).

Dla systemów AI wbudowanych w produkty Annex I, EU DoC może być połączona z deklaracją zgodności wymaganą na podstawie odpowiedniego prawodawstwa sektorowego, pod warunkiem że zawiera wszystkie elementy wymagane przez oba akty prawne.


Oznakowanie CE (Art. 48)

Systemy AI wysokiego ryzyka wprowadzane do obrotu w UE muszą nosić oznakowanie CE, które sygnalizuje zgodność z EU AI Act i wszelkimi innymi mającymi zastosowanie unijnymi przepisami zharmonizowanymi obejmującymi ten sam produkt.

Wyjątki: Systemy AI w kategoriach Annex III wdrożone przez organy publiczne do własnego użytku wewnętrznego są zwolnione z wymagań dotyczących oznakowania CE. Podlegają wszystkim innym obowiązkom — dokumentacji technicznej, zarządzaniu ryzykiem, nadzorowi człowieka, rejestracji — ale nie muszą afiszować oznakowania CE.

Oznakowanie CE musi być afiszowane przed wprowadzeniem systemu do obrotu w UE. Musi być widoczne, czytelne i nieusuwalne. Tam, gdzie fizyczna natura systemu nie pozwala na bezpośrednie afiszowanie oznaczenia, może ono pojawiać się na opakowaniu lub w instrukcji użytkowania.

Gdy system AI wysokiego ryzyka jest składnikiem produktu Annex I wymagającego już oznakowania CE na podstawie prawodawstwa sektorowego (np. wyroby medyczne, maszyny), oznakowanie CE obejmuje zgodność zarówno z prawodawstwem sektorowym, jak i EU AI Act. Dostawcy powinni wyraźnie dokumentować, które procedury oceny zgodności podpierają oznakowanie CE.


Praktyczna Lista Kontrolna: Minimalny Plik Techniczny

Przed wprowadzeniem jakiegokolwiek systemu AI wysokiego ryzyka do obrotu w UE sprawdź, czy te 10 elementów jest kompletnych i popartych dowodami:

Ta lista kontrolna obejmuje minimum. Dobrze przygotowany plik techniczny pójdzie dalej — szczególnie w metodologii testowania uprzedzeń, kartach modeli dla modeli składowych i dowodach na to, że proces zarządzania ryzykiem jest iteracyjny, a nie jednorazowy.


Jak to łączy się z Akademią EU AI Act

Poziom Pro Akademii EU AI Act zawiera gotowe do użycia szablony dokumentacji technicznej obejmujące wszystkie 14 elementów Annex IV, w tym:

Szablony te są przeznaczone do dostosowania do Twojego konkretnego systemu — są punktami wyjścia z merytorycznymi treściami, a nie pustymi formularzami.

Powiązane strony:

Official AI Act Compliance Deadline Calendar

Updated · Sources: Regulation (EU) 2024/1689 and the 2026 Digital Omnibus on AI.

Obligation Applies to Original date New date Status Countdown Legal basis
Prohibited Practices (Art. 5) All providers and deployers active AI Act Art. 5
GPAI Rules (Chapter 5) GPAI model providers active AI Act Art. 51-56
High-risk AI — Annex III (standalone) Providers of standalone Annex III systems deferred AI Omnibus 2026 Art. 6(2)
High-risk AI — Annex I (embedded) AI embedded in Annex I regulated products deferred AI Omnibus 2026 Art. 6(1)
AI-Generated Content Marking Providers of generative GPAI systems active AI Act Art. 50(2)
Regulatory Sandboxes National competent authorities active AI Act Art. 57

Download JSON · CC BY 4.0

Frequently Asked Questions

Dostawca systemu AI wysokiego ryzyka jest wyłącznie odpowiedzialny za przygotowanie i prowadzenie dokumentacji technicznej. Podmioty wdrażające nie są zobowiązane do jej przygotowywania, ale muszą prowadzić logi dostępu i może być konieczne ich dostarczenie dostawcom do celów sprawozdawczych.

Dokumentacja techniczna musi być przechowywana przez 10 lat po wprowadzeniu systemu AI do obrotu lub oddaniu do użytku w UE (Art. 18). Dla systemów AI wbudowanych w produkty podlegające prawodawstwu Annex I, jeżeli jest ona dłuższa, stosuje się okres przechowywania z prawodawstwa dotyczącego produktu.

Nie — dokumentacja techniczna nie jest centralnie przekazywana. Musi być przechowywana przez dostawcę i udostępniana organom nadzoru rynku i jednostkom notyfikowanym na żądanie. Rejestracja w unijnej bazie danych AI (Art. 71) jest obowiązkowa, ale pełny plik techniczny pozostaje u dostawcy.

Formalny dokument podpisany przez dostawcę stwierdzający, że system AI spełnia wymogi EU AI Act. Musi zawierać nazwę systemu, wersję, tożsamość dostawcy, listę spełnionych wymogów, zastosowaną procedurę oceny zgodności i odniesienie do odpowiednich zharmonizowanych norm. Towarzyszy oznakowaniu CE.

Stay ahead of AI Act changes

Get compliance alerts when deadlines or obligations change.

No spam. One-click unsubscribe.