Kiedy dokumentacja techniczna ma zastosowanie i co robić dalej

Dokumentacja techniczna jest konkretnym obowiązkiem AI Act, gdy firma jest dostawcą systemu wysokiego ryzyka. Artykuł 11 wymaga przygotowania jej przed wprowadzeniem systemu do obrotu lub oddaniem do użytku, aktualizowania oraz zapewnienia jasności pozwalającej organom i jednostkom notyfikowanym ocenić zgodność. Załącznik IV określa minimalną treść.

Nie każda firma SaaS korzystająca z API AI potrzebuje więc pełnej dokumentacji. Odpowiedź zależy od granicy systemu, roli firmy i klasyfikacji. Nawet bez bezpośredniego obowiązku proporcjonalny zapis wspiera zarządzanie produktem, ocenę dostawców, klientów, incydenty i ponowną ocenę.

Potwierdź system, rolę i klasyfikację

Opisz cały system: przeznaczenie, użytkowników, osoby objęte wpływem, dane wejściowe i wyjściowe, integracje, kontekst oraz znaczenie wyniku. Model zewnętrzny może być tylko jednym składnikiem produktu SaaS.

Następnie ustal rolę. Podmiot rozwijający system wysokiego ryzyka i sprzedający go pod własną nazwą jest zwykle dostawcą; klient może być podmiotem stosującym. Zmiana marki, istotna modyfikacja lub nowe przeznaczenie mogą przesunąć odpowiedzialność. Oceń dwie główne ścieżki art. 6: produkty regulowane z załącznika I i zastosowania z załącznika III. Zobacz przewodnik dla dostawców SaaS.

Kiedy stosuje się art. 11

Artykuł 11 i załącznik IV dotyczą dokumentacji systemów wysokiego ryzyka i nakładają podstawowy obowiązek na dostawcę. Po rozporządzeniu (UE) 2026/1744 zasady dla systemów z załącznika III stosuje się od 2 grudnia 2027 r., a dla systemów w produktach z załącznika I od 2 sierpnia 2028 r.

Nie należy czekać. Prawo sektorowe, ochrona danych, umowy, bezpieczeństwo i kontrole klientów już mogą wymagać podobnych dowodów. Wczesne działanie zapobiega odtwarzaniu wersji, danych, testów i decyzji.

Jeżeli system nie jest wysokiego ryzyka lub firma jest tylko podmiotem stosującym, pełny zestaw może nie być wymagany. Zapisz jednak decyzję, fakty, recenzenta i wyzwalacze ponownej oceny. Nowe wrażliwe przeznaczenie, istotna zmiana modelu lub danych, nowy rynek albo większy wpływ na ludzi powinny ponownie otworzyć analizę.

Minimalny zakres

Załącznik IV wymaga co najmniej:

1. Tożsamości, przeznaczenia, wersji, użytkowników i warunków działania.
2. Rozwoju, architektury, komponentów i decyzji projektowych.
3. Pochodzenia danych, walidacji, testów i ograniczeń wydajności.
4. Ryzyk, kontroli, nadzoru człowieka, logów i eskalacji.
5. Odporności, cyberbezpieczeństwa i przewidywalnych niepożądanych wyników.
6. Zmian, incydentów i monitorowania po wprowadzeniu do obrotu.
7. Norm, ścieżki oceny zgodności i zatwierdzeń.
8. Powiązania każdego twierdzenia z kontrolowanym dowodem.

Dokumentacja może być indeksem prowadzącym do kontrolowanych zapisów. Stabilne łącza, uprawnienia, wersje i retencja są ważniejsze od liczby stron.

Praktyczny proces

1. Zatwierdź zakres: zapisz identyfikator, cel, granicę, rolę, klasyfikację i założenia.
2. Utwórz indeks załącznika IV: dodaj źródło, właściciela, wersję, status, recenzenta i wyzwalacz aktualizacji.
3. Pozostaw dowód u faktycznego właściciela: produkt odpowiada za cel, inżynieria za architekturę, dane lub ML za oceny, bezpieczeństwo za zabezpieczenia, compliance za mapowanie.
4. Najpierw zamknij krytyczne luki: klasyfikację, wydajność, ryzyka, nadzór i zatwierdzenie wydania.
5. Powiąż zmiany: cel, modele, dane, progi, użytkownicy, integracje lub kontrole powinny uruchamiać aktualizacje i ewentualne ponowne testy.
6. Przetestuj wyszukiwanie: niezależny recenzent powinien prześledzić twierdzenie o wydajności, kontrolę, ścieżkę nadzoru i wydanie do dowodów.

Lista kontrolna dokumentacji technicznej zawiera szczegółową strukturę. Odpowiedzi dla klientów muszą odpowiadać kontrolom AI oczekiwanym przez nabywców.

Typowe błędy

• Rozpoczynanie od szablonu przed ustaleniem zakresu i dowodów.
• Dokumentowanie modelu zamiast całego systemu.
• Traktowanie materiałów dostawcy jako dowodu własnej konfiguracji.
• Brak ponownej oceny wniosku o niskim ryzyku.
• Prowadzenie dokumentacji audytowej oddzielnie od wydań i zmian.

Przykład: wspomagana selekcja kandydatów

Dla funkcji porządkującej podania zespół musi określić cel, dostawcę, granicę i klasyfikację z załącznika III. Jeśli dostarcza system wysokiego ryzyka, dokumentacja obejmuje wersje produkcyjne, dane, proces klienta, oceny grup, metryki, ograniczenia, przegląd człowieka, logowanie, bezpieczeństwo i monitoring. Zmiana modelu lub progu musi ponownie otworzyć powiązane zapisy.

FAQ

Kiedy obowiązek dotyczy zespołów SaaS?

Artykuł 11 dotyczy dostawców systemów wysokiego ryzyka. Potwierdź granicę, rolę i klasyfikację przed uznaniem pełnej dokumentacji za obowiązek prawny.

Co udokumentować najpierw?

Przeznaczenie, granicę, rolę, klasyfikację, wersję produkcyjną, architekturę, ryzyka, oceny, kontrole, instrukcje i właścicieli.

Czy można użyć dokumentów inżynieryjnych?

Tak. Odwołuj się do aktualnych, kontrolowanych źródeł i wskaż w indeksie, który wymóg i wersję pokrywają.

Źródła

• Rozporządzenie (UE) 2024/1689, art. 6 i 11 oraz załączniki I, III i IV.
• Rozporządzenie (UE) 2026/1744 o dokumentacji i datach stosowania.
• Komisja Europejska, „AI Act”, aktualny harmonogram wdrażania.