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:
- Sporządzić przed wprowadzeniem do obrotu lub oddaniem do użytku.
- Aktualizować — jakakolwiek istotna zmiana systemu wymaga aktualizacji pliku i ponownej oceny zgodności.
- 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:
- Systemów AI wysokiego ryzyka wymienionych w Annex III — samodzielnych systemów w takich obszarach jak kategoryzacja biometryczna, rekrutacja, scoring kredytowy, zarządzanie infrastrukturą krytyczną, edukacja, egzekwowanie prawa, migracja i kontrola graniczna oraz wymiar sprawiedliwości (z zastrzeżeniem filtra znaczącego ryzyka Art. 6 ust. 3)
- Systemów AI działających jako składniki bezpieczeństwa w produktach regulowanych przez Annex I — AI wbudowanego w wyroby medyczne, maszyny, pojazdy, sprzęt lotniczy i podobne produkty regulowane istniejącym unijnym prawodawstwem dotyczącym bezpieczeństwa produktów
Dokumentacja techniczna nie jest wymagana dla:
- Systemów AI minimalnego ryzyka (chatboty, filtry spamu, silniki rekomendacji poza kategoriami wysokiego ryzyka)
- Systemów AI podlegających wyłącznie obowiązkom przejrzystości na podstawie Art. 50 (np. ujawnienia deepfake, ujawnienia rozpoznawania emocji gdzie nie jest wysokiego ryzyka)
- Dostawców modeli AI ogólnego przeznaczenia (GPAI) — mają odrębne obowiązki dokumentacyjne na podstawie Art. 53, w tym dokumentację techniczną samego modelu, ale nie format Annex IV zaprojektowany dla wdrożonych systemów wysokiego ryzyka
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ć:
- Nazwę i adres dostawcy (i upoważnionego przedstawiciela, jeżeli dotyczy)
- Nazwę systemu AI, wersję, numer seryjny lub partii, jeżeli dotyczy
- Oświadczenie o zgodności systemu z EU AI Act
- Zastosowaną procedurę oceny zgodności: Annex VI (kontrola wewnętrzna / samoocena) dla większości systemów Annex III lub Annex VII (ocena przez stronę trzecią przez jednostkę notyfikowaną) dla AI kategoryzacji biometrycznej i AI stosowanego w infrastrukturze krytycznej wymagającego zaangażowania strony trzeciej
- Lista opieranych zharmonizowanych norm lub wspólnych specyfikacji
- Podpis upoważnionego przedstawiciela dostawcy z datą i miejscem
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:
- [ ] Opis systemu i kontrola wersji — nazwa, wersja, udokumentowane zamierzone przeznaczenie; istnieje dziennik zmian
- [ ] Diagram architektury — diagram przepływu danych i komponentów pokazujący wszystkie elementy sprzętowe, programowe i stron trzecich
- [ ] Inwentarz danych do trenowania i zapis zarządzania — zestawy danych skatalogowane ze źródłem, rozmiarem, podziałami i udokumentowanymi procedurami jakości danych
- [ ] Ocena ryzyka (zgodnie z Art. 9) — zidentyfikowane ryzyka, środki ograniczające i zaakceptowane ryzyka rezydualne udokumentowane i zaakceptowane
- [ ] Wyniki testowania uprzedzeń — udokumentowana metodologia testowania; wyniki w podziale na odpowiednie grupy demograficzne tam, gdzie dotyczy
- [ ] Metryki dokładności na reprezentatywnym zestawie testowym — metryki wydajności udokumentowane z warunkami testowania; zdefiniowane progi
- [ ] Dokument procedury nadzoru człowieka — opisane mechanizmy nadpisania; udokumentowane wymagania operatorów (szkolenie, kwalifikacje)
- [ ] Ocena cyberbezpieczeństwa — ocenione znane wektory ataku; udokumentowane techniczne środki zaradcze
- [ ] Instrukcje użytkowania (skierowane do podmiotów wdrażających) — kompletny dokument Art. 13, w tym ograniczenia, obowiązki logowania i kontakt do zgłaszania incydentów
- [ ] Plan nadzoru posprzedażowego — zakres zbierania danych, częstotliwość monitorowania, progi uruchamiające przegląd i procedura zgłaszania incydentów
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:
- Ustrukturyzowany skoroszyt XLSX z jedną zakładką na element Annex IV, wstępnie wypełniony podpowiedziami i przykładowymi wpisami
- Szkielet pliku technicznego DOCX gotowy do edycji
- Arkusz oceny ryzyka zgodny z iteracyjnym procesem Art. 9
- Szablon zapisu zarządzania danymi obejmujący zestawy danych do trenowania, walidacji i testowania
- Szablon planu nadzoru posprzedażowego zgodny z Art. 72
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:
- Annex III — Kategorie AI wysokiego ryzyka i obowiązki
- Procedury oceny zgodności (Annex VI i VII)
- Akademia EU AI Act — szablony i szkolenia
- Narzędzia — Selektor oceny zgodności
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
AI Act meets DORA and NIS2
Is your organisation subject to both the AI Act and DORA? The two regulations intersect on the operational resilience of financial AI systems. Our sister site regulation-dora.eu covers DORA in depth.
Explore regulation-dora.eu ↗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.