ISO 42001, NIST AI RMF i AI Act: połącz ich role

Ład AI może łączyć system zarządzania, framework ryzyka i obowiązki prawne. Wyzwanie inżynierskie polega na połączeniu ich bez udawania, że są wymienne. Polityka, raport z ewaluacji i decyzja o klasyfikacji prawnej mogą dotyczyć tej samej usługi AI, ale każde z nich odpowiada na inne pytanie.

ISO/IEC 42001 określa, jak organizacja zarządza AI. AI Risk Management Framework instytutu NIST pomaga zespołom badać ryzyka i zarządzać nimi w ich kontekście. Unijny akt w sprawie sztucznej inteligencji (AI Act) ustanawia obowiązki prawne zależne od systemu, jego przeznaczenia i roli organizacji jako operatora.

Dla CTO użytecznym rezultatem jest jeden łańcuch ładu, który można poddać przeglądowi: zdefiniowany przypadek użycia, odpowiedzialni właściciele, wdrożone zabezpieczenia, dowody z testów, decyzje o wydaniu i monitorowanie. Mapowania między frameworkami powinny wskazywać na ten łańcuch, zachowując wymagania, które nadal wymagają pracy technicznej, prawnej lub związanej z oceną zgodności.

Zrozum, co ustanawia każdy z instrumentów

ISO 42001: uczyń ład powtarzalnym

ISO/IEC 42001 określa wymagania dotyczące ustanowienia, wdrożenia, utrzymywania i ciągłego doskonalenia AIMS. Wymagania dotyczące systemu zarządzania obejmują kontekst organizacji, przywództwo, planowanie, wsparcie, działania operacyjne, ocenę efektów działania i doskonalenie.

Ta struktura ma znaczenie, gdy kilka zespołów buduje lub kupuje rozwiązania AI. Daje podstawę do decydowania, kto zatwierdza wdrożenie, jak przeprowadzane są oceny skutków i ryzyka, jak obsługiwane są zależności od dostawców i jak błędy prowadzą do działań korygujących.

Norma zawiera również zabezpieczenia referencyjne w załączniku A oraz wytyczne wdrożeniowe. Wybór zabezpieczeń opiera się na ryzyku i wymaga udokumentowanego uzasadnienia; przepisanie załącznika do listy kontrolnej nie dowodzi, że system zarządzania działa.

Niezależna jednostka certyfikująca może ocenić AIMS w określonym zakresie. Sama organizacja ISO nie certyfikuje organizacji. Certyfikacja zapewnia potwierdzenie dotyczące systemu zarządzania w jego określonych granicach, a nie nieograniczone twierdzenie, że każdy model czy wynik jest bezpieczny.

NIST AI RMF: zbadaj rzeczywiste ryzyko

NIST AI RMF organizuje pracę nad ryzykiem wokół funkcji Govern, Map, Measure i Manage. Govern ma charakter przekrojowy; funkcje te nie są po prostu czterema kolejnymi fazami projektu.

Cechy wiarygodności obejmują m.in. trafność i niezawodność, bezpieczeństwo użytkowania, bezpieczeństwo i odporność, rozliczalność i przejrzystość, wyjaśnialność i interpretowalność, wzmacnianie prywatności oraz sprawiedliwość przy kontrolowaniu szkodliwych uprzedzeń. Cechy te mogą wymagać kompromisów. Bardziej szczegółowe wyjaśnienia mogą na przykład ujawniać informacje, które wymagają ochrony prywatności.

Wytyczne NIST pomagają zespołom przekształcać ogólne cele w pytania i ewaluacje specyficzne dla przypadku użycia. Obejmują też rozliczalność; ład nie jest domeną zarezerwowaną dla ISO 42001. Nie istnieje program certyfikacji NIST AI RMF porównywalny z certyfikacją systemów zarządzania ISO. Ocena zewnętrzna może wspierać zapewnienie, ale jej zakres i metodyka muszą zostać określone.

AI Act: ustal obowiązki, a nie tylko ryzyka

Akt w sprawie sztucznej inteligencji reguluje określone praktyki, systemy AI i modele AI ogólnego przeznaczenia za pomocą różnych przepisów. O stosowaniu przepisów nie decyduje wyłącznie techniczna ocena ryzyka. Znaczenie mają przeznaczenie, zakres terytorialny, rola operatora i szczegółowe zasady klasyfikacji.

Obowiązki dostawcy różnią się od obowiązków podmiotu stosującego. Model to nie to samo co aplikacja, która go wykorzystuje, a nazwanie oprogramowania „agentem” nie przesądza o jego roli prawnej ani klasyfikacji.

Zacznij od zakresu i stosowania przepisów

Prowadź inwentarz AI na poziomie operacyjnych przypadków użycia, a nie tylko nazw dostawców. Jeden model bazowy może obsługiwać zarówno wewnętrznego asystenta do redagowania tekstów, jak i narzędzie do preselekcji kandydatów do pracy. Te wdrożenia dotyczą różnych osób, mają różne konsekwencje, wymagają różnych zabezpieczeń i mogą wiązać się z różnymi obowiązkami.

Dla każdego przypadku użycia zapisz:

• Przeznaczenie, wspierane decyzje, zakazane zastosowania i lokalizacje wdrożenia.
• Właściciela systemu, właściciela technicznego, użytkowników i osoby, na które system wpływa.
• Dostawców modelu i aplikacji, sposób hostingu i zależności.
• Źródła danych, wyniki, integracje i dozwolone działania.
• Rolę organizacji jako operatora i uzasadnienie tej oceny.
• Klasyfikację, mające zastosowanie obowiązki, datę przeglądu i nierozstrzygnięte pytania.

Organizacja spoza UE może w określonych okolicznościach podlegać zakresowi aktu. Z drugiej strony posiadanie klientów w UE nie uzasadnia przypisywania każdemu produktowi wszystkich możliwych obowiązków. Przeanalizuj faktyczne warunki dotyczące zakresu terytorialnego i roli.

Oddzielaj praktyki zakazane, wymogi dla systemów wysokiego ryzyka, szczególne obowiązki w zakresie przejrzystości i obowiązki dotyczące modeli AI ogólnego przeznaczenia. Nie są to wymienne poziomy jednej inżynierskiej skali wagi. Pozornie mało istotny chatbot może podlegać obowiązkom w zakresie przejrzystości; przypadek użycia o dużym wpływie wymaga bardziej szczegółowej oceny prawnej.

Korzystaj z aktualnego harmonogramu wdrożenia

Przegląd AI Act opublikowany przez Komisję Europejską, według stanu sprawdzonego na 7 października 2026 r., podaje następujący harmonogram:

Zmienione przepisy, rozwiązania przejściowe i konkretny system oceniaj oddzielnie. Nie odkładaj obowiązków, które już mają zastosowanie, tylko dlatego, że istnieje późniejsza data dla systemów wysokiego ryzyka. Datuj ocenę prawną i korzystaj z naszego przewodnika po gotowości na AI Act, aby uzyskać kontekst dotyczący harmonogramu i oceny ról.

Zbuduj jeden łańcuch dowodów, a nie trzy biblioteki dokumentów

Praktyczny łańcuch ładu zaczyna się od przypadku użycia i kończy na zweryfikowanej decyzji:

Przeznaczenie → skutki i ryzyka → wymagania → zabezpieczenia → ewaluacje → zatwierdzenie → monitorowanie.

Każde powiązanie wymaga wystarczającej szczegółowości, aby osoba spoza zespołu wdrożeniowego mogła je zweryfikować. Stwierdzenie „nadzór człowieka wdrożony” jest niewystarczające, jeśli recenzent nie może ustalić, kto może interweniować, co widzi i czy interwencja działa.

Korzystaj z rejestru wymagań, który odróżnia wymaganie źródłowe od jego wdrożenia. Użyteczny minimalny schemat obejmuje źródło i wersję, zakres, treść wymagania lub odniesienie do niego, lokalną interpretację, właściciela zabezpieczenia, powiązane dowody, recenzenta, status i pozostałą lukę.

Traktuj tę tabelę jako pomoc we wdrożeniu, a nie miarodajną mapę równoważności. Relacje są typu wiele-do-wielu: jedna ewaluacja może wspierać kilka wymagań, a jedno wymaganie może wymagać wielu zabezpieczeń i zapisów.

Przed ponownym wykorzystaniem dowodów sprawdź ich zakres, datę, wersję systemu i wniosek. Test jednej konfiguracji modelu nie może automatycznie potwierdzać innej konfiguracji. Polityka korporacyjna dowodzi istnienia udokumentowanej reguły; do wykazania jej stosowania potrzebne są zapisy operacyjne.

Wykorzystaj funkcje NIST do zdefiniowania pracy inżynierskiej

Funkcje NIST zapewniają użyteczny sposób porządkowania pytań wdrożeniowych w ramach AIMS. Powinny dawać konkretne artefakty, a nie tylko wypełnione pola kwestionariusza.

Govern: ustal uprawnienia decyzyjne

Określ, kto jest właścicielem systemu, kto niezależnie przegląda istotne ryzyka i kto może zatwierdzać wyjątki lub wstrzymać wdrożenie. Określ wymagania dotyczące kompetencji i ścieżki eskalacji. Powiąż te odpowiedzialności z istniejącymi procesami bezpieczeństwa, ochrony danych, zakupów i zarządzania incydentami.

Użytecznym rezultatem jest procedura wydania wskazująca wymaganych recenzentów i dowody. Akceptacja ryzyka powinna wskazywać osobę decyzyjną, uzasadnienie, warunki i zdarzenie uruchamiające przegląd, a nie tylko rejestrować status „zaakceptowano”.

Map: opisz kontekst i konsekwencje

Udokumentuj workflow przed wyborem wskaźników. Ustal, gdzie AI wpływa na decyzje, kto ponosi konsekwencje i co się dzieje, gdy wyniki są błędne, niedostępne lub niewłaściwie wykorzystane.

Uwzględnij dające się przewidzieć niewłaściwe użycie i awarie zależności. W przypadku agenta, który może wykonywać działania, zmapuj narzędzia, poświadczenia, dostępne dane, granice zatwierdzania i ścieżki przywracania. W przypadku AI od podmiotów trzecich zapisz, co kontroluje dostawca, a co pozostaje Twoją odpowiedzialnością.

Measure: testuj twierdzenia, które mają znaczenie

Wybieraj ewaluacje powiązane ze zidentyfikowanymi ryzykami. W zależności od przypadku użycia mogą one obejmować trafność wykonania zadania, wyniki w podgrupach, odporność, wycieki danych prywatnych, prompt injection, nieuprawnione działania i zrozumienie wyników przez operatorów.

Dokumentuj pochodzenie zbiorów danych, ich reprezentatywność, warunki testów, wskaźniki, ograniczenia i progi akceptacji. Tam, gdzie to możliwe, mierz całą aplikację: wyszukiwanie kontekstu, prompty, uprawnienia, interfejsy i workflow ludzi mogą zmieniać wyniki, nawet gdy model bazowy pozostaje ten sam.

Manage: wdrażaj postępowanie z ryzykiem i działania następcze

Przekładaj ustalenia na zabezpieczenia, ograniczenia, działania naprawcze lub decyzję o rezygnacji z wdrożenia. Przykłady obejmują ograniczenie uprawnień narzędzi, wymaganie zatwierdzenia dla działań o istotnych skutkach, wykluczenie niewspieranych zastosowań lub zapewnienie niezawodnej ścieżki zastępczej bez AI.

Ustal progi monitorowania i procedury reagowania. Wskaźnik bez właściciela i reguły reagowania to tylko telemetria. Zapisz, które zdarzenia uruchamiają ponowną ocenę, w tym aktualizacje dostawcy, zmienione źródła danych, rozszerzone zastosowania i incydenty.

Uczyń ISO 42001 audytowalnym dzięki zapisom operacyjnym

Jeśli celem jest certyfikacja, określ granice AIMS przed przygotowaniem do audytu zewnętrznego. Zakres może obejmować konkretny produkt, jednostkę biznesową lub zestaw działań w cyklu życia, ale powinien jasno opisywać objęte działania i interfejsy. Wąski zakres nie może być przedstawiany jako zapewnienie obejmujące całą organizację.

Przeprowadź analizę luk w odniesieniu do wymagań dotyczących systemu zarządzania i mających zastosowanie zabezpieczeń. Ustal politykę, cele, metody oceny ryzyka i skutków, udokumentowane zastosowanie zabezpieczeń, odpowiedzialności i procedury operacyjne. Następnie wytwarzaj dowody, że te procesy faktycznie działają.

Użyteczne zapisy obejmują zakończone oceny, przeglądy dostawców, zapisy szkoleń, zatwierdzenia wydań, przeglądy monitorowania, działania korygujące, ustalenia audytów wewnętrznych i decyzje z przeglądów zarządzania. Audyt wewnętrzny i przegląd zarządzania to odrębne działania: pierwszy ocenia zgodność i skuteczność, drugi wspiera kierownictwo w ocenie systemu zarządzania i nadawaniu mu kierunku.

Niezależny proces certyfikacji obejmuje zwykle etapy oceny gotowości i oceny wdrożenia. Uzgodnij zakres i organizację audytu z jednostką certyfikującą, zamiast traktować certyfikację jako złożenie dokumentów. Po certyfikacji kontynuuj monitorowanie, przeglądy wewnętrzne i doskonalenie.

Ani certyfikat, ani ocena według RMF nie zastępują mającej zastosowanie oceny zgodności zgodnie z AI Act. Procedura oceny zgodności zależy od systemu i odpowiednich przepisów; nie każdy system wysokiego ryzyka wymaga tej samej procedury z udziałem strony trzeciej. Wymogi dotyczące deklaracji, rejestracji, oznakowania i zgłaszania również należy sprawdzić dla właściwej roli i systemu.

Przykład: wdrożenie AI w procesie rekrutacji

Założenia przykładowe: pracodawca z UE kupuje aplikację, która tworzy ranking kandydatów do przeglądu przed rozmowami kwalifikacyjnymi. Dostawca dostarcza aplikację, a pracodawca konfiguruje kryteria dla stanowisk i korzysta z rankingów. Ostateczne decyzje o zatrudnieniu podejmują rekruterzy. Przyjmijmy, że przegląd prawny identyfikuje zastosowanie wysokiego ryzyka w obszarze zatrudnienia z załącznika III i wstępnie określa pracodawcę jako podmiot stosujący.

Kwestii tej nie rozstrzyga stwierdzenie, że „ostateczną decyzję podejmuje człowiek”. Ranking może istotnie wpływać na to, kto w ogóle zostanie wzięty pod uwagę. Ocena musi zbadać faktyczny workflow, w tym to, czy rekruterzy rutynowo pomijają kandydatów poniżej progu odcięcia.

Ustal zapis specyficzny dla systemu

Właściciel techniczny zapisuje pola wejściowe, dostępne od dostawcy informacje o logice rankingu, wersję aplikacji, konfigurację, użytkowników i miejsca docelowe eksportu. Dział zakupów zwraca się do dostawcy o instrukcje, ograniczenia, odpowiednie dowody z ewaluacji, powiadomienia o zmianach i wsparcie w realizacji obowiązków organizacji.

Przegląd prawny dokumentuje założenia dotyczące klasyfikacji i roli, w tym to, czy przyszła modyfikacja lub oznaczenie produktu własną marką mogłyby zmienić rolę. Przegląd w zakresie ochrony danych oddzielnie ocenia przetwarzanie danych kandydatów. Ład AI nie zastępuje analizy z zakresu ochrony danych.

Testuj i wdrażaj zabezpieczenia

Korzystając z funkcji Map i Measure z NIST, zespół ocenia reprezentatywne scenariusze rekrutacyjne, zachowanie systemu przy brakujących danych i różnice w wynikach między odpowiednimi grupami, o ile jest to zgodne z prawem i wykonalne. Dokumentuje niepewność i ograniczenia próby, zamiast przedstawiać wskaźnik sprawiedliwości jako dowód, że wszystkie szkodliwe uprzedzenia zniknęły.

Nadzór człowieka obejmuje szkolenie rekruterów, widoczne ograniczenia, ścieżkę przeglądu odrzuconych aplikacji i możliwość wstrzymania rankingu. Zespół testuje, czy recenzenci rozumieją wyniki i mogą je nadpisywać bez przeszkód operacyjnych.

Zabezpieczenia ograniczają dostęp do danych kandydatów i zapobiegają niezatwierdzonym eksportom. Zarządzanie zmianą wymaga ponownej oceny, gdy zmieniają się kryteria rankingu, modele lub sposób przetwarzania danych przez dostawcę.

Utrzymuj trzy wnioski oddzielnie

Zapis AIMS pokazuje, jak działały oceny, przypisanie odpowiedzialności, przegląd dostawcy i procesy zatwierdzania. Zapis RMF wyjaśnia ryzyka kontekstowe, testy, postępowanie z ryzykiem i pozostałą niepewność. Zapis prawny wskazuje mające zastosowanie obowiązki podmiotu stosującego, terminy i pozostałe prace.

Załóżmy, że dostawca nie przekazał wystarczających instrukcji umożliwiających skuteczny nadzór. Zapis wydania powinien pokazywać tę lukę, jej właściciela i decyzję o opóźnieniu lub ograniczeniu wdrożenia – a nie zielony status odziedziczony z certyfikatu ISO pracodawcy.

Wybierz priorytety i utrzymuj dowody po wydaniu

Najpierw nadaj priorytet mającym zastosowanie obowiązkom prawnym i nieakceptowalnym ryzykom operacyjnym. Certyfikacja ISO może przebiegać równolegle z działaniami naprawczymi, ale cel audytowy nie powinien wypierać pilnych zabezpieczeń.

Jeśli zespołom brakuje spójnego przypisania odpowiedzialności i procesów przeglądu, zbuduj podstawy AIMS. Jeśli ład istnieje, ale ewaluacje systemów są słabe, wykorzystaj RMF do poprawy analizy kontekstowej i testów. Jeśli klient wymaga certyfikacji, potwierdź oczekiwany zakres przed zaplanowaniem budżetu.

Unikaj uniwersalnych założeń dotyczących kosztów i czasu trwania. Nakład pracy zależy od liczby systemów, istniejącego ładu, potrzeb w zakresie ewaluacji, przejrzystości dostawców i działań naprawczych. RMF jest dostępny bezpłatnie, ale jego wdrożenie i tak pochłania czas pracowników; certyfikacja ISO wiąże się dodatkowo z kosztami dostępu do normy i oceny zewnętrznej.

Po wydaniu przypisz artefaktom zdarzenia uruchamiające przegląd. Aktualizacja modelu przez dostawcę może unieważnić wyniki ewaluacji; nowe uprawnienie do wykonywania działań może zmienić model zagrożeń; nowy rynek może wymagać ponownej oceny prawnej. Zachowuj poprzednie wersje i decyzje, aby recenzenci mogli odtworzyć, co zostało wówczas zatwierdzone.

Częste błędy obejmują traktowanie mapowań jako zgodności, gromadzenie polityk bez dowodów operacyjnych, akceptowanie deklaracji dostawców bez analizy specyficznej dla wdrożenia oraz rejestrowanie ryzyka rezydualnego bez osoby decyzyjnej. Innym błędem jest mierzenie jakości modelu z pominięciem uprawnień aplikacji i zachowań ludzi.

Secani może wspierać workflow dowodowy, łącząc wymagania, zabezpieczenia, materiały źródłowe, właścicieli, zadania i zweryfikowane decyzje. Zacznij od jednego określonego zakresu, dołącz dowody do tego, co wspierają, i zamień brakujące lub nieaktualne materiały w przypisane zadania. Traktuj sugestie wspierane przez AI jako wersje robocze: człowiek powinien weryfikować mapowania i wnioski, a źródła i uzasadnienie zatwierdzenia powinny być zachowane. Dzięki temu podstawy ładu pozostają możliwe do zweryfikowania, a osąd inżynierski i prawny nie zostaje zastąpiony.

Pytania, które wpływają na wdrożenie

Czy można ponownie wykorzystać istniejące zabezpieczenia?

Tak, o ile ich wdrożenie i dowody obejmują wdrożenie AI. Kontrola dostępu, reagowanie na incydenty i zarządzanie dostawcami często się do tego przyczyniają. Same w sobie nie odpowiadają jednak na pytania o szkodliwe uprzedzenia, przeznaczenie systemu czy skuteczny nadzór człowieka.

Co, jeśli dostawca nie ujawni wewnętrznych szczegółów modelu?

Zapisz to ograniczenie przejrzystości. Szukaj dowodów proporcjonalnych do przypadku użycia, oceń wdrożoną aplikację i ustal, czy potrzebne są zapewnienia umowne, ograniczenia lub alternatywni dostawcy. Brak przejrzystości nie jest automatycznie akceptowalny tylko dlatego, że usługa jest dostępna komercyjnie.

Od czego zespół powinien zacząć?

Wybierz jeden przypadek użycia o istotnych skutkach i zbierz dla niego właściciela, przeznaczenie, ocenę roli, zapis ryzyka, zabezpieczenia, testy i zatwierdzenie. Przeanalizuj luki w odniesieniu do wszystkich trzech instrumentów. To ograniczone ćwiczenie pokaże, czy przed rozszerzeniem zakresu organizacja potrzebuje lepszego ładu, lepszych dowodów technicznych, czy rozstrzygnięcia otwartych kwestii prawnych.