Dokumentacja techniczna: praktyczny przewodnik dla zespołów SaaS

Dokumentacja techniczna systemu AI nie jest podsumowaniem architektury tworzonym na końcu projektu. To kontrolowany pakiet dowodów wyjaśniający przeznaczenie systemu, sposób budowy, używane dane i modele, wyniki, ryzyka, zabezpieczenia oraz zarządzanie zmianami po wydaniu.

Artykuł 11 AI Act wymaga od dostawców systemów AI wysokiego ryzyka przygotowania tej dokumentacji przed wprowadzeniem systemu do obrotu lub oddaniem do użytku, utrzymywania jej aktualności i przedstawienia jej w formie pozwalającej organom oraz jednostkom notyfikowanym ocenić zgodność. Załącznik IV wskazuje minimalną treść. Zespół SaaS powinien więc zbierać dowody produktowe, inżynieryjne, dotyczące danych, bezpieczeństwa, prawa i jakości podczas rozwoju, a nie odtwarzać je podczas audytu.

Obowiązek nie dotyczy automatycznie każdej funkcji AI. Zakres zależy od klasyfikacji systemu i roli firmy. Najpierw udokumentuj oba elementy, a potem dostosuj dokumentację do rzeczywistych obowiązków i ryzyka.

Dlaczego ma to znaczenie

Dobra dokumentacja pokazuje, że testy odpowiadają przeznaczeniu, łączy odpowiedzi dla klientów z kontrolowanymi dowodami i ułatwia ocenę, czy zmiana modelu, danych, progu lub workflow wymaga ponownej analizy. Oceniający otrzymuje spójną historię zamiast zrzutów ekranu bez kontekstu.

Dokumentacja łączy wymagania produktowe, diagramy architektury, model cards, pochodzenie danych, ewaluacje, rejestry ryzyka, testy bezpieczeństwa, nadzór człowieka, logi, incydenty, zatwierdzenia wydań i monitoring po wprowadzeniu na rynek. Centralny indeks może wskazywać te źródła bez ich duplikowania.

Wspiera to również zmieniające się oczekiwania wobec AI governance dostawców SaaS.

Potwierdź zakres

Ustal, czy oprogramowanie jest systemem AI, czy jest systemem wysokiego ryzyka i jaką rolę pełni firma. Podmiot rozwijający i sprzedający system pod własną nazwą może być dostawcą. Firma używająca cudzego systemu może być podmiotem stosującym, ale rebranding, istotna modyfikacja lub zmiana przeznaczenia mogą zmienić analizę.

Wysokie ryzyko może wynikać z art. 6 ust. 1 i załącznika I dla regulowanych produktów lub elementów bezpieczeństwa albo z przypadku użycia w załączniku III na podstawie art. 6 ust. 2. Projekty wytycznych Komisji z maja 2026 r. są pomocne, ale niewiążące.

Rozporządzenie (UE) 2026/1744 zmieniło terminy: sekcje 1, 2 i 3 rozdziału III, w tym art. 11, stosuje się od 2 grudnia 2027 r. do systemów z załącznika III i od 2 sierpnia 2028 r. do systemów z załącznika I. Inne przepisy, umowy lub zobowiązania wobec klientów mogą wymagać podobnych dowodów wcześniej.

Nie myl tego dokumentu z odrębnymi obowiązkami dostawców modeli AI ogólnego przeznaczenia z art. 53 i załącznika XI. Informacje dostawcy modelu są wkładem; dostawca SaaS nadal dokumentuje cały system, integrację, przeznaczenie, zabezpieczenia i ocenione wyniki.

Czego oczekuje załącznik IV

Traktuj go jako mapę pokrycia:

1. Tożsamość i przeznaczenie: dostawca, nazwa, wersja, użytkownicy, cel, forma dostawy, interfejsy, zależności i UI.
2. Rozwój: metody, komponenty zewnętrzne lub wstępnie trenowane, wybór modelu, cele, założenia i decyzje.
3. Architektura: komponenty, interakcje, zasoby obliczeniowe i uzasadnienie wyborów.
4. Dane: źródło, wybór, etykietowanie, czyszczenie, governance, ograniczenia i zbiory treningowe, walidacyjne, testowe lub retrieval.
5. Możliwości i ograniczenia: metryki, dokładność, odporność, cyberbezpieczeństwo, przewidywalne niepożądane wyniki i degradacja.
6. Testy: protokoły, dane, progi, daty, wersje, wyniki, błędy i działania naprawcze.
7. Ryzyko i nadzór: zarządzanie ryzykiem, środki, ryzyko rezydualne, nadzór człowieka i instrukcje.
8. Cykl życia: wersje, logowanie, zmiany, utrzymanie, incydenty i monitoring post-market.
9. Zgodność: normy, specyfikacje, deklaracja zgodności UE i dokumenty jednostki notyfikowanej, jeśli wymagane.

Każde twierdzenie powinno prowadzić do konkretnego dowodu. Odwołanie do raportu, zatwierdzonej metryki, zbioru danych, wersji i ograniczenia jest weryfikowalne; stwierdzenie „system jest odporny” nie jest.

Workflow operacyjny

1. Utwórz kontrolowany indeks

Jedna pozycja na każdy element załącznika IV powinna zawierać wymaganie, ocenę zastosowania, źródło, właściciela, wersję, zatwierdzenie, ostatni przegląd i kolejny trigger. „Nie dotyczy” wymaga uzasadnienia i akceptacji. Kluczowe są kontrola dostępu, historia i stabilne referencje.

2. Przypisz dowody zespołom, które je tworzą

Product odpowiada za cel, użytkowników, kontekst i przewidywalne niewłaściwe użycie. Engineering za architekturę, zależności, wersje i zmiany. Data lub ML za pochodzenie danych, rozwój, ewaluacje i ograniczenia. Security za zagrożenia, dostęp, odporność i podatności. Legal i compliance za klasyfikację, role, mapowanie przepisów i governance dokumentów. Jeden właściciel koordynuje całość bez przepisywania niezweryfikowanych faktów technicznych.

3. Ustal baseline przed testami

Zdefiniuj przeznaczenie i wersję przed akceptacją wyników. Zapisz modele, istotne prompty, źródła retrieval, feature flags, progi, zależności i środowisko. Dla systemów probabilistycznych zachowaj wersję datasetu, metodę, próg akceptacji, datę, odtwarzalne wyniki i ograniczenia.

4. Połącz ryzyka, zabezpieczenia i testy

Każde istotne ryzyko prowadzi do środka ograniczającego, właściciela i dowodu skuteczności. Jeśli zabezpieczeniem jest człowiek, opisz kto sprawdza, jakie ma informacje, czy może odrzucić wynik, jak eskaluje wyjątki i jak wykazuje się wykonanie kontroli.

5. Włącz dokumentację do wydań

Każde istotne wydanie wymaga oceny wpływu na dokumentację. Zmiany celu, modelu, danych, progu, użytkowników, kraju, integracji, nadzoru lub bezpieczeństwa mogą wymagać nowych testów i aktualizacji ryzyk, instrukcji oraz analizy zgodności.

Minimalna lista dowodów

Zespół powinien znaleźć: zatwierdzony opis, rolę i klasyfikację; aktualne diagramy architektury i przepływów z wersjami; rejestr modeli, bibliotek, API i zależności; pochodzenie i governance danych; plany, metryki, progi, wyniki i ograniczenia ewaluacji; ryzyka połączone z kontrolami i akceptacją; dowody nadzoru człowieka; zapisy bezpieczeństwa, odporności, logów, incydentów i monitoringu; instrukcje zgodne z przetestowanym systemem; historię wydań i dokumenty zgodności.

Częste błędy

Pusty szablon compliance tworzy ogólniki bez dowodów. Model card nie opisuje całego workflow SaaS. Dokumenty vendora są wkładem, nie zastępują analizy integracji. Ukrywanie ograniczeń jest mniej obronne niż opisanie ich wraz z zabezpieczeniami. Kalendarz nie wystarczy: wydania, incydenty, nowe dane, nowe użycia i zmiany prawa uruchamiają przegląd. Kwestionariusze klientów, strony produktu, instrukcje, ryzyka i dokumentacja muszą opisywać ten sam system.

Przykład: wspierany przez AI screening kandydatów

Dla funkcji szeregującej aplikacje dokumentacja obejmuje cel, niewspierane użycia, workflow klienta, osoby, dane, logikę rankingu, wersje, oceniane grupy, metryki, progi, kontrolę człowieka, logi, security i monitoring.

Jeśli ewaluacja pokazuje niższy recall dla istotnej grupy, zachowaj wynik, analizę, środek, ponowny test i decyzję o ryzyku rezydualnym. Późniejsza zmiana modelu lub progu powinna ponownie otworzyć powiązane elementy.

FAQ

Czy każda firma SaaS potrzebuje dokumentacji z załącznika IV?

Nie. Artykuł 11 i załącznik IV dotyczą systemów wysokiego ryzyka i głównego obowiązku dostawcy. Proporcjonalny zapis pozostaje jednak przydatny dla governance i klientów.

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

Tak, jeśli są kontrolowane i aktualne, a indeks wykazuje pokrycie. Unikaj rozbieżnych kopii.

Kto powinien odpowiadać?

Wyznaczony owner koordynuje; product, engineering, ML/data, security, legal i compliance pozostają właścicielami swoich dowodów.

Kiedy aktualizować?

Gdy zmieniają się cel, wersje, dane, integracje, użytkownicy, wyniki, ryzyka, zabezpieczenia lub monitoring, przed istotnymi wydaniami i po incydentach.

Czy uproszczony formularz dla MŚP jest dostępny?

Artykuł 11 przewiduje uproszczony formularz. Przed użyciem szablonu sprawdź aktualne oficjalne materiały. Do czasu dostępności właściwego formularza utrzymuj pełną mapę załącznika IV z proporcjonalnymi dowodami.

Źródła

• Rozporządzenie (UE) 2024/1689, zwłaszcza art. 6, 9–17 i 43 oraz załącznik IV.
• Rozporządzenie (UE) 2026/1744 ze zmienionymi terminami.
• Projekt wytycznych Komisji dotyczących klasyfikacji wysokiego ryzyka, maj 2026 r.
• Wytyczne Komisji dla dostawców modeli AI ogólnego przeznaczenia.