ISO 42001 Annex A: przegląd zabezpieczeń

Załącznik A do normy ISO/IEC 42001:2023 to normatywny katalog 38 zabezpieczeń referencyjnych w 9 obszarach (od A.2 do A.10), z którego organizacje za pomocą Deklaracji stosowania (SoA) wybierają, w oparciu o ryzyko, środki istotne dla siebie. Zabezpieczenia obejmują cały zakres: od ram polityki AI, przez role, zasoby, cykl życia i zarządzanie danymi, aż po odpowiedzialne użytkowanie i relacje ze stronami trzecimi.

Załącznik A działa przy tym podobnie jak Załącznik A do ISO/IEC 27001 w połączeniu z ISO 27002: każdy obszar ma cel („To …”) i listę zabezpieczeń, które razem pozwalają go osiągnąć. Powiązane wytyczne wdrożeniowe znajdują się w informacyjnym Załączniku B.

Trzy szybkie odpowiedzi:

• Ile? 9 obszarów, 38 zabezpieczeń. Rozbieżne liczby (39, 42 zabezpieczenia; 10 domen) wynikają z konwencji liczenia; kanoniczna liczba to 9/38.
• Obowiązkowe? Nie z automatu. Wybór odbywa się w oparciu o ryzyko poprzez SoA. Każde zabezpieczenie jest oznaczane jako mające zastosowanie lub niemające zastosowania, w obu przypadkach z uzasadnieniem.
• Dlaczego to ważne? Załącznik A to operacyjny rdzeń, w którym w punkcie 8 (Działania operacyjne) nadzór nad AI przybiera konkretną formę. Podczas audytu stanowi główną podstawę doboru próby.

Przegląd 9 obszarów zabezpieczeń

Poniższa tabela zestawia wszystkie obszary Załącznika A wraz z celem i typowym przykładowym działaniem.

Od A.2 do A.5: nadzór, organizacja, zasoby i ocena skutków

A.2 (Policies related to AI) obejmuje samą politykę AI jako kierunek zatwierdzony przez kierownictwo (A.2.2), jej spójność z innymi politykami (A.2.3) oraz jej regularny przegląd (A.2.4). U operatora agentów polityka AI powinna wprost obejmować poziomy autonomii (tylko odczyt / rekomendowanie / działanie po zatwierdzeniu / działanie autonomiczne), granice korzystania z narzędzi, zasady eskalacji i human-in-the-loop, dywersyfikację dostawców modeli oraz zakazane zastosowania (np. brak autonomicznego doradztwa prawnego).

A.3 (Internal organisation) reguluje role i odpowiedzialności w obszarze AI z rozdziałem obowiązków (A.3.2) oraz kanał zgłaszania zastrzeżeń (A.3.3). ISO 42001 nie narzuca stałego tytułu „AI Officer”; w organizacjach z sektora MŚP w regionie DACH (Niemcy, Austria, Szwajcaria) rolę menedżera AIMS często łączy się z funkcją CISO lub inspektora ochrony danych.

A.4 (Resources for AI systems) wymaga dokumentowania zasobów (A.4.2), zasobów danych (A.4.3), narzędzi (A.4.4), zasobów systemowych i obliczeniowych (A.4.5) oraz zasobów ludzkich (A.4.6). Dla deployerów agentów A.4.2 oznacza rejestr AI/agentów, w którym każdy produkcyjny agent figuruje wraz z celem, właścicielem, zależnościami od modeli, źródłami danych i klasą ryzyka. To najważniejszy artefakt przy doborze próby w audycie.

A.5 (Assessing impacts of AI systems) definiuje proces oceny skutków (A.5.2), jego dokumentowanie (A.5.3) oraz ocenę skutków dla osób i grup osób (A.5.4) i skutków społecznych (A.5.5). Te cztery zabezpieczenia stanowią operacyjną kotwicę dla normy towarzyszącej ISO/IEC 42005:2025. Funkcjonalnie pokrywają się z DPIA z art. 35 RODO i z FRIA z art. 27 AI Act, ale ich nie zastępują.

Od A.6 do A.10: cykl życia, dane, informacje, użytkowanie, strony trzecie

A.6 (AI system lifecycle) to najobszerniejszy obszar: od celów cyklu życia (A.6.1.2), przez odpowiedzialne projektowanie (A.6.1.3), specyfikację wymagań (A.6.2.2), dokumentację projektową (A.6.2.3), weryfikację i walidację (A.6.2.4), wdrożenie (A.6.2.5), eksploatację i monitorowanie (A.6.2.6) oraz dokumentację techniczną (A.6.2.7), aż po rejestrowanie zdarzeń (A.6.2.8). To ostatnie ustanawia wyraźny obowiązek rejestrowania zdarzeń, który funkcjonalnie biegnie równolegle do art. 12 AI Act (rejestrowanie zdarzeń w systemach AI wysokiego ryzyka). Jednocześnie A.6.2.8 jest we wdrożeniach agentów zabezpieczeniem, dla którego najczęściej brakuje wystarczających dowodów, ponieważ zwykle loguje się tylko wywołania narzędzi, a nie dane wejściowe modelu, ślady rozumowania czy zdarzenia przejęcia kontroli przez człowieka.

A.7 (Data for AI systems) zakotwicza zarządzanie danymi: dane do rozwoju i doskonalenia (A.7.2), pozyskiwanie (A.7.3), jakość (A.7.4), proweniencja/pochodzenie (A.7.5) i przygotowanie (A.7.6). A.7 jest punktem odniesienia dla powiązania z serią ISO/IEC 5259 i koncepcyjnie nawiązuje do art. 10 AI Act. Ważne: A.7 ma zastosowanie także wtedy, gdy korzysta się wyłącznie z modeli bazowych zewnętrznych dostawców. Obszar ten obejmuje dane do retrievalu/RAG, szablony promptów i zbiory danych ewaluacyjnych.

A.8 (Information for interested parties) obejmuje dokumentację systemu i informacje dla użytkowników, takie jak model cards (A.8.2), raportowanie zewnętrzne (A.8.3), komunikację o incydentach (A.8.4) i informowanie interesariuszy (A.8.5). A.8.2 ściśle odpowiada art. 13 AI Act (przejrzystość / instrukcja obsługi), a A.8.4 art. 73 (zgłaszanie poważnych incydentów) oraz obowiązkom deployera z art. 26.

A.9 (Use of AI systems) obejmuje procesy odpowiedzialnego użytkowania (A.9.2), odpowiadające im cele (A.9.3) oraz zamierzone użycie (A.9.4). A.9.4 ma kluczowe znaczenie dla deployerów: jeśli agent jest eksploatowany poza zamierzonym użyciem zadeklarowanym przez dostawcę, deployer (w AI Act: podmiot stosujący) może na podstawie art. 25 ust. 1 AI Act sam zostać uznany za dostawcę, np. gdy zmiana przeznaczenia sprawia, że system dotąd niezaklasyfikowany jako system wysokiego ryzyka staje się systemem AI wysokiego ryzyka (lit. c). Taka sytuacja powinna automatycznie uruchamiać nową ocenę skutków zgodnie z A.5.

A.10 (Third-party & customer relationships) reguluje podział odpowiedzialności w łańcuchu wartości (A.10.2), relacje z dostawcami (A.10.3) i klientami (A.10.4). Dla deployerów, którzy opierają się na modelach bazowych lub platformach agentowych zewnętrznych dostawców, A.10.3 dokumentuje umowny i operacyjny podział ról między dostawcą a deployerem, w tym due diligence w zakresie certyfikacji, ochrony danych i wersjonowania modeli.

Jak Załącznik A jest powiązany z SoA

Załącznika A nie wdraża się w całości z automatu, lecz wybiera się z niego zabezpieczenia poprzez Deklarację stosowania (SoA). Punkt 6.1.3 wymaga SoA, a podczas audytu ISO 42001 jest ona najczęściej sprawdzanym dokumentem. W SoA przy każdym zabezpieczeniu znajdują się:

1. Odniesienie do zabezpieczenia i jego tytuł (np. A.6.2.8 Rejestrowanie zdarzeń)
2. Decyzja o zastosowaniu (ma zastosowanie / nie ma zastosowania)
3. Uzasadnienie (ryzyko, na które odpowiada zabezpieczenie, lub powód wyłączenia)
4. Status wdrożenia (planowane / w toku / wdrożone / monitorowane)
5. Odwołanie do dowodów (polityka, procedura, zapis, system)
6. Właściciel

Najczęstszym ustaleniem niezgodności w praktyce audytowej w latach 2024–2026 są wyłączenia bez uzasadnienia opartego na ryzyku („n/a” ze standardowym jednozdaniowym komentarzem). Typowe są również: oznaczenie zabezpieczenia jako mającego zastosowanie bez utrzymywania dokumentu, na którym się opiera (np. A.4.2 „applicable” bez rzeczywistego rejestru zasobów), oraz statyczna SoA, której nie aktualizuje się przy nowych agentach lub zmianie modelu.

Konkretny przykład wdrożenia: agent obsługi klienta

Średniej wielkości deployer (ok. 800 pracowników) eksploatuje agenta obsługi klienta opartego na modelu bazowym zewnętrznego dostawcy, połączonego przez RAG z wewnętrzną bazą wiedzy. Logika SoA dla krytycznych zabezpieczeń:

• A.4.2 ma zastosowanie: wpis w rejestrze AI/agentów z celem „wsparcie pierwszej linii”, właściciel: kierownik obsługi klienta, udokumentowana zależność od modelu, klasa ryzyka „średnia”.
• A.5.2–A.5.5 mają zastosowanie: agent kontaktujący się z klientami i wpływający na osoby; AISIA z analizą praw podstawowych i prywatności.
• A.6.2.8 ma zastosowanie: logowanie promptu i instrukcji systemowej, identyfikatora i wersji modelu, wywołań narzędzi, zapytań wyszukiwawczych i identyfikatorów dokumentów, danych wyjściowych, zdarzeń przejęcia kontroli przez człowieka i eskalacji. Okres przechowywania: z reguły 6 miesięcy lub okres wynikający z wymogów sektorowych, w zależności od tego, który jest dłuższy, z uzasadnieniem w SoA.
• Zabezpieczenia A.6 dotyczące rozwoju (np. trenowanie modeli): możliwe częściowe wyłączenie, ponieważ organizacja nie prowadzi własnych prac rozwojowych. Uzasadnienie: „Organizacja nie rozwija modeli AI; wszystkie modele pochodzą od zewnętrznych dostawców i są objęte A.10.3.”
• Mierzalny cel (punkt 6.2): „≥ 90% dokładności na zbiorze ewaluacyjnym typu gold standard, pomiar w kroczącym oknie 30 dni, raportowanie miesięczne.”

Taki wybór wytrzyma audyt, ponieważ każde włączenie i każde wyłączenie ma przejrzyste uzasadnienie oparte na ryzyku, a za każdym „applicable” stoi rzeczywisty artefakt.

Uwaga: Ten artykuł służy orientacji merytorycznej i nie stanowi porady prawnej. Przyporządkowania do RODO, AI Act i konkretnych numerów artykułów (np. art. 12, 13, 25, 35, 73) należy przed wiążącym wdrożeniem uzgodnić z Twoim działem prawnym.

Dla agencji i decydentów B2B

Firma, która korzysta z agentów AI w środowisku produkcyjnym, nie potrzebuje „certyfikowanej AI”: ISO 42001 certyfikuje system zarządzania (AIMS), a nie pojedynczy model. Najszybsza droga do gotowości audytowej prowadzi przez trzy dźwignie: kompletny rejestr AI/agentów (A.4.2), solidne rejestrowanie zdarzeń dla każdego agenta (A.6.2.8) oraz aktualną SoA z uzasadnieniami opartymi na ryzyku. Blck Alpaca pomaga firmom i agencjom w całej Europie wdrażać zabezpieczenia z Załącznika A w odchudzonej formie i w sposób odporny na audyt, w integracji z istniejącymi systemami ISO 27001/9001 i z uwzględnieniem pokrywających się obowiązków z AI Act. Dzięki temu katalog zabezpieczeń staje się sterowalnym systemem nadzoru, a nie zbiorem dokumentów.