Zasady odpowiedzialnej AI łatwo spisać. Trudniej pokazać, że zmieniają decyzje o konkretnych systemach. IEEE 2863 podpowiada, jak nadzorować AI, a ISO/IEC 42001 daje system, w którym ten nadzór da się osadzić i sprawdzić.
W skrócie
- IEEE 2863 zawiera zalecenia dla organu nadzoru, ISO/IEC 42001 wymagania dla systemu zarządzania AI. Te dokumenty się uzupełniają (więcej).
- Każdy z ośmiu procesów IEEE ma punkty wejścia w klauzulach 4–10 i w Annex A ISO/IEC 42001 (więcej).
- Mapowanie wskazuje, gdzie szukać. Nie dowodzi zgodności (więcej).
- Postanowienia IEEE trafiają do deklaracji stosowania jako uszczegółowienie zabezpieczeń z Annex A albo jako własne zabezpieczenia organizacji (więcej).
- Audytor szuka śladu decyzji i dowodu skuteczności. Sygnał słabości nie jest automatycznie niezgodnością (więcej).
Wprowadzenie
IEEE 2863-2026 (IEEE Recommended Practice for Organizational Governance of Artificial Intelligence) i ISO/IEC 42001:2023 można stosować łącznie, bo pełnią różne funkcje. ISO/IEC 42001 określa wymagania dla systemu zarządzania AI (AIMS) i jest podstawą certyfikacji. IEEE 2863 zawiera zalecenia dla organu sprawującego nadzór nad AI: dwie zasady nadrzędne, piętnaście zasad stosowanych zależnie od kontekstu, jeden proces nadrzędny i siedem procesów wspierających. Postanowienia IEEE można włączyć do AIMS na dwa sposoby: jako uszczegółowienie istniejących zabezpieczeń z tabeli A.1 albo jako własne zabezpieczenia organizacji, które ISO/IEC 42001 dopuszcza w A.1 z odesłaniem do klauzuli 6.1.3. Samo mapowanie IEEE na ISO nie dowodzi zgodności. Audytor ocenia, czy przyjęte mechanizmy działają, na podstawie decyzji, zapisów i wyników. IEEE 2863 staje się kryterium audytu dopiero wtedy, gdy organizacja przyjmie jego postanowienia jako własne zobowiązania. Opracowanie: Dariusz Rycek, Centre of Excellence (COE) i Centrum Certyfikacji QSCert.
Zarząd, który zatwierdził politykę AI, ma zwykle spisane wartości: bezpieczeństwo, uczciwość, przejrzystość. Pytanie audytowe brzmi jednak inaczej. Czy da się prześledzić drogę od zasady do decyzji o konkretnym systemie AI, a potem do dowodu, że przyjęte środki działają?
Na to pytanie odpowiadają razem dwa dokumenty. IEEE 2863 we wprowadzeniu wymienia ISO/IEC 42001 wśród norm uzupełniających. W punktach 4.7 i 4.9.2 opisuje nadzór nad cyklem życia AI jako ciągły cykl planuj, wykonaj, sprawdź, działaj (PDCA), z odesłaniem właśnie do ISO/IEC 42001.
Samą architekturę IEEE 2863 omówiliśmy we wpisie o nadzorze nad AI według IEEE 2863. Tutaj interesuje nas styk: gdzie zalecenia IEEE trafiają w AIMS, jak zapisać je w deklaracji stosowania (SoA) i co z tego ma zobaczyć audytor.
Co IEEE 2863 dodaje do AIMS?
IEEE 2863 dodaje do AIMS warstwę nadzoru: zasady, priorytety i decyzje organu odpowiedzialnego za AI. ISO/IEC 42001 dostarcza mechanizmów, które te decyzje przekładają na ocenę ryzyka, ocenę wpływu, zabezpieczenia i dowody. Pierwszy dokument mówi, co organizacja chce chronić i kto rozstrzyga. Drugi pokazuje, jak to zorganizować i zweryfikować.
Governance i zarządzanie: dwie funkcje w jednej organizacji
IEEE w punkcie 4.3 odróżnia governance od zarządzania. Governance wyznacza kierunek, apetyt na ryzyko, strukturę decyzji i rozliczalność oraz nadzoruje ich realizację. Zarządzanie wdraża przyjęte zasady i procesy. Uwaga do 4.3 wyłącza z zakresu IEEE szczegóły wdrożenia wytycznych dla konkretnych systemów i kontekstów, uznając je za funkcję zarządzania. To naturalny punkt styku z AIMS.
Porównanie funkcji dokumentów
Charakter, adresat i rola obu dokumentów w organizacji.
| Wymiar | ISO/IEC 42001:2023 | IEEE 2863-2026 |
|---|---|---|
| Charakter | Wymagania dla systemu zarządzania AI („shall”) | Zalecane praktyki governance AI („should”) |
| Punkt ciężkości | Ustanowienie, działanie, ocena i doskonalenie AIMS | Zasady, priorytety i decyzje nadzorcze |
| Główny adresat | Najwyższe kierownictwo i role w AIMS | Organ sprawujący nadzór i role realizujące jego decyzje |
| Konstrukcja | Klauzule 4–10, zabezpieczenia w Annex A, wytyczne w Annex B | Zasady 2 + 15, procesy 1 + 7, studia przypadków w Annex A |
| Weryfikacja | Podstawa audytu i certyfikacji AIMS | Kryterium dopiero po przyjęciu postanowień przez organizację |
| Relacja z prawem | Wspiera uporządkowane zarządzanie obowiązkami | Stosowanie nie oznacza zgodności z prawem (4.8) |
Organ nadzoru w rozumieniu IEEE nie musi być osobnym komitetem AI. IEEE w 4.9 dopuszcza delegowanie dostosowań do rady ds. governance AI lub wyznaczonego personelu, pod warunkiem zachowania nadzoru nad całością. Skalę stosowania wiąże z intensywnością działań AI, niezależnie od wielkości organizacji. W małej firmie rolę organu nadzoru pełni zwykle zarząd.
Nie jest też trafna teza, że ISO/IEC 42001 dotyczy wyłącznie procedur, a etykę wnosi dopiero IEEE. ISO obejmuje odpowiedzialne rozwijanie AI (A.6.1.2) i odpowiedzialne używanie AI (grupa A.9). IEEE opisuje bardziej bezpośrednio zasady, dylematy i działania organu nadzoru.
Architektura IEEE 2863 w skrócie
IEEE wyróżnia dwie zasady nadrzędne (5.1): unikanie szkody (Do No Harm) i ochronę praw człowieka (Protect Human Rights). Piętnaście zasad drugiego poziomu (5.2) stosuje się zależnie od kontekstu; IEEE w 4.9.1 zaleca ustalać ich priorytet dla każdego systemu i rozstrzygać napięcia między nimi. Procesy tworzą dwa poziomy: proces nadrzędny nadzoru nad cyklem życia i zgodnością (6.1) z pięcioma etapami oraz siedem procesów wspierających (6.2–6.8), które organ nadzoru dobiera do ryzyka, skali zastosowania i obaw interesariuszy.
Osiem procesów IEEE na mapie ISO/IEC 42001
Każdy proces IEEE ma w ISO/IEC 42001 punkty wejścia: klauzule systemowe i zabezpieczenia z tabeli A.1. Poniższe zestawienie jest autorską analizą tematyczną COE, nie oficjalną tabelą zgodności IEEE ani ISO. Polskie nazwy procesów to robocze tłumaczenie.
Osiem procesów IEEE 2863 na mapie ISO/IEC 42001
Punkty wejścia w klauzulach i zabezpieczeniach Annex A oraz przykładowe dowody.
| Proces IEEE 2863 | Punkty wejścia w ISO/IEC 42001 | Przykładowe dowody |
|---|---|---|
| 6.1Nadzór nad cyklem życia i zgodnościąAI Life Cycle Oversight and Conformance | 5.15.36.1.2–6.1.46.38.1–8.49.1A.5A.6.2.4–A.6.2.6A.9.4 | Próg objęcia nadzorem, decyzje o uruchomieniu, zmianie i wycofaniu, warunki dopuszczenia, monitorowanie działania |
| 6.2AudytAuditing | 9.1–9.310.2 | Program audytów, niezależność od zespołu systemu, śledzenie ustaleń, rozdzielenie audytu AIMS od oceny systemu |
| 6.3Nadzór etycznyEthics oversight | 5.1–5.36.1.48.4A.2A.3.2–A.3.3A.5 | Mandat funkcji etycznej, waga rekomendacji, rejestr dylematów, kanał zgłaszania obaw bez odwetu |
| 6.4Reagowanie na incydentyIncident response | 7.48.19.110.2A.6.2.8A.8.3A.8.4 | Kryteria eskalacji, uprawnienie do zatrzymania systemu, ćwiczenia, rejestr incydentów i zdarzeń potencjalnie szkodliwych |
| 6.5Zarządzanie łańcuchem wartościValue chain management | 8.1A.7.5A.9A.10.2–A.10.4 | Pochodzenie modeli i danych, podział odpowiedzialności, ocena dostawców, przepływ informacji w obie strony |
| 6.6Identyfikacja i angażowanie interesariuszyStakeholder identification and engagement | 4.26.1.47.48.4A.5A.8.3 | Mapa osób dotkniętych skutkami, konsultacje, skargi, informacja zwrotna |
| 6.7Ocena własności intelektualnejIntellectual property assessment | 4.26.1.2–6.1.38.1–8.3A.4A.7A.10 | Rejestr praw do danych, modeli i komponentów, przegląd licencji, ponowna ocena po zmianie |
| 6.8Red teamingRed teaming | 6.1.2–6.1.38.1–8.39.1A.5A.6.2.4 | Autoryzowany zakres prób, niezależność zespołu, raport do organu nadzoru, decyzja o reakcji, ponowny test |
Autorska analiza tematyczna COE. Nie jest oficjalną tabelą zgodności IEEE ani ISO. Powiązania wskazują, gdzie szukać, i nie oznaczają równoważności wymagań.
Autorskie zestawienie relacji między IEEE 2863-2026 i ISO/IEC 42001:2023. Powiązania mają charakter analityczny; nie oznaczają równoważności wymagań ani potwierdzenia zgodności ALT: IEEE 2863 i ISO/IEC 42001: zasady i procesy nadzoru połączone z ryzykiem, oceną wpływu, zabezpieczeniami i dowodami skuteczności AIMS
Kilka procesów prowadzi do tych samych klauzul i to jest zamierzone. Jedna ocena wpływu może objąć prywatność, dyskryminację i dobrostan. Jedna zasada może z kolei wymagać kilku procesów, zabezpieczeń i właścicieli. Relacja nie jest jeden do jednego.
Gdzie mapowanie przestaje być zgodnością
Mapowanie odpowiada na pytanie, gdzie szukać. Nie odpowiada na pytanie, czy coś działa. Wpisanie numeru zabezpieczenia obok procesu IEEE niczego nie dowodzi, dopóki organizacja nie pokaże decyzji, zapisów i wyników.
W audycie certyfikacyjnym kryterium stanowią wymagania ISO/IEC 42001 i zobowiązania, które organizacja przyjęła sama. IEEE 2863 nie jest kryterium audytu certyfikacyjnego, chyba że organizacja włączyła jego postanowienia do własnej polityki, procesów lub deklaracji stosowania. Wtedy audytor sprawdza ich realizację tak samo jak każdego innego zobowiązania.
Korzyści z połączenia IEEE 2863 i ISO/IEC 42001
Największa korzyść to ciągłość śladu: od zasady przez decyzję o systemie do dowodu skuteczności. ISO/IEC 42001 zapewnia rygor systemowy, IEEE 2863 nadaje mu treść nadzorczą. Razem pozwalają odpowiedzieć zarządowi i audytorowi na to samo pytanie tymi samymi dokumentami.
Zarząd zyskuje język decyzji. IEEE w 4.9.1 proponuje pytania do ustalania priorytetów zasad: co system ma robić, na kogo wpływa, jakie niesie ryzyka i korzyści, jak prawdopodobna i dotkliwa jest szkoda, czego oczekują interesariusze. Te pytania dobrze zasilają ocenę ryzyka (6.1.2) i ocenę wpływu (6.1.4) w AIMS.
Pełnomocnik AIMS zyskuje uzupełnienie obszarów, które w wielu systemach są opisane ogólnie: red teaming wykraczający poza test penetracyjny, własność intelektualną jako proces w całym cyklu życia, łańcuch wartości i wycofanie systemu. IEEE w 6.1.9 zaleca m.in. archiwizację wycofanego wydania i jego danych oraz ocenę ryzyk, które pozostają po wycofaniu.
Organizacja zyskuje jeden system zamiast dwóch równoległych. IEEE w 4.9 zaleca, aby organ nadzoru zdecydował, jak włączyć jego postanowienia do istniejących procedur zarządzania ryzykiem i oceny wpływu. AIMS jest do tego naturalnym miejscem.
Zastosowanie praktyczne: IEEE 2863 w AIMS i deklaracji stosowania
IEEE 2863 trafia do AIMS przez proces postępowania z ryzykiem AI (6.1.3) i deklarację stosowania. Najpierw sprawdza się, czy potrzebę zaspokoi uszczegółowienie istniejącego zabezpieczenia z tabeli A.1. Własne zabezpieczenie dodaje się wtedy, gdy służy zarządzaniu i identyfikowalności, a nie mnożeniu wierszy.
Własne zabezpieczenia w deklaracji stosowania AIMS
ISO/IEC 42001 zostawia tu wyraźną przestrzeń. Annex A w punkcie A.1 zaznacza, że nie wszystkie zabezpieczenia z tabeli A.1 muszą być stosowane, a organizacja może projektować i wdrażać własne, z odesłaniem do 6.1.3. Klauzula 6.1.3 wymaga ustalenia, czy potrzebne są zabezpieczenia wykraczające poza Annex A, oraz sporządzenia deklaracji stosowania z uzasadnieniem włączenia i wyłączenia zabezpieczeń. Uwaga do tej klauzuli wskazuje, że takie zabezpieczenia organizacja może zaprojektować sama albo zaczerpnąć z istniejących źródeł. IEEE 2863 jest właśnie takim źródłem.
Poniższe identyfikatory GOV-AI to propozycje autorskie COE. Nie są numerami zabezpieczeń IEEE ani ISO.
Propozycje GOV-AI do deklaracji stosowania AIMS
Zabezpieczenia inspirowane IEEE 2863. Najpierw sprawdź, czy wystarczy uszczegółowienie istniejącego zabezpieczenia z tabeli A.1.
| Propozycja (autorska) | Ryzyko i treść zabezpieczenia | Najpierw sprawdź w tabeli A.1 | Właściciel, dowód i miernik |
|---|---|---|---|
| GOV-AI-01 Decyzje o konflikcie zasad | Ryzyko: Optymalizacja biznesowa kosztem praw osób.Zabezpieczenie: Dokumentować istotne konflikty zasad, rozważone warianty i uzasadnione rozstrzygnięcie przed uruchomieniem lub zmianą systemu | A.5.2–A.5.4A.6.1.2 | Właściciel: Sponsor systemuDowód: karta decyzji zatwierdzona przez uprawnioną rolęMiernik: odsetek istotnych dylematów rozstrzygniętych przed decyzjąInspiracja: IEEE 4.9.1, 5, 6.3 |
| GOV-AI-02 Niezależna ocena etyczna | Ryzyko: Konflikt interesów i pomijanie szkód.Zabezpieczenie: Zapewnić opinię niezależną od zespołu projektu i określić prawo eskalacji | A.3.2A.3.3 | Właściciel: Organ nadzoruDowód: mandat i zapis działań po opiniiMiernik: liczba zaległych działań i czas eskalacjiInspiracja: IEEE 6.3 |
| GOV-AI-03 Próby podważające założenia | Ryzyko: Niewykryte nadużycia i szkody.Zabezpieczenie: Dla wybranych systemów przeprowadzać niezależne, autoryzowane próby i sprawdzać skuteczność napraw | A.6.2.4 | Właściciel: Właściciel ryzykaDowód: zakres, raport, decyzja, ponowny testMiernik: odsetek krytycznych ustaleń zamkniętych przed wdrożeniemInspiracja: IEEE 6.8 |
| GOV-AI-04 Pochodzenie i prawa | Ryzyko: Nieuprawnione użycie danych lub komponentów.Zabezpieczenie: Utrzymywać ewidencję pochodzenia, licencji i warunków użycia; przeglądać ją po każdej zmianie | A.4.2–A.4.4A.7.5A.10.3 | Właściciel: Właściciel systemu z funkcją prawnąDowód: rejestr i zatwierdzenie zmianMiernik: odsetek istotnych komponentów z potwierdzoną ocenąInspiracja: IEEE 6.5, 6.7 |
| GOV-AI-05 Zatrzymanie i naprawa szkód | Ryzyko: Kontynuowanie szkodliwego działania.Zabezpieczenie: Ustalić progi eskalacji, uprawnienie do zatrzymania, tryb zastępczy i zasady kontaktu z osobami dotkniętymi skutkami | A.6.2.6A.6.2.8A.8.3A.8.4 | Właściciel: Właściciel operacyjnyDowód: przećwiczony scenariusz i zapis decyzjiMiernik: czas od potwierdzenia zdarzenia do ograniczenia skutkówInspiracja: IEEE 6.4 |
Identyfikatory GOV-AI to propozycje autorskie COE, nie numery zabezpieczeń IEEE ani ISO.
Dla każdej pozycji deklaracja stosowania powinna wskazywać przyczynę doboru, powiązane ryzyko i wymagania stron, odniesienie do istniejących zabezpieczeń, właściciela oraz sposób oceny skuteczności. Nie ma potrzeby przepisywania całego IEEE do SoA. Zobowiązaniem organizacji staje się dopiero mechanizm, który sama przyjęła.
GOV-AI-05 dobrze zestawić z procesem opisanym we wpisie o reagowaniu na incydenty AI według ISO/IEC 42001. IEEE w 6.4.4 zaleca m.in. upoważnienie właściwych osób do wyłączenia systemu, a dla systemów krytycznych w 5.2.4.2 uznaje za uzasadniony „kill switch”. Pokrewny temat dla systemu zarządzania bezpieczeństwem informacji, czyli zabezpieczenia AI w deklaracji stosowania ISO/IEC 27001, omówiliśmy we wpisie o kontrolkach AI w SZBI w świetle ISO/IEC 27090.
Jakie dowody powinien zobaczyć audytor
Audytor ocenia AI governance po śladach decyzji, nie po deklaracjach. Szuka przykładu, w którym zasada lub ocena wpływu zmieniła decyzję o systemie, oraz dowodu, że przyjęte zabezpieczenie zadziałało. Poniższe pytania to autorski zestaw roboczy.
Pytania audytowe i dowody
Autorski zestaw roboczy. Sygnał słabości nie jest automatycznie niezgodnością.
| Pytanie audytora | Dowód do sprawdzenia | Co może sygnalizować słabość |
|---|---|---|
| Od jakiego progu nowa inicjatywa AI trafia pod nadzór? | Zatwierdzone kryterium progu i przykład jego zastosowania | Systemy AI uruchomione obok procesu, bez rejestracji |
| Która decyzja o AI zmieniła się wskutek oceny wpływu? | Wersje oceny, protokół, zmienione kryteria dopuszczenia | Ocena sporządzona po faktycznym uruchomieniu |
| Jak rozstrzygnięto konflikt przejrzystości z ochroną informacji? | Uzasadnienie zakresu informacji dla różnych odbiorców | Ogólne powołanie się na tajemnicę bez oceny potrzeb odbiorców |
| Kto może zatrzymać system i czy umie to zrobić? | Uprawnienia, zapis ćwiczenia, dostępny tryb zastępczy | Odpowiedzialność przypisana bez uprawnień technicznych |
| Kto reprezentuje osoby, które nie są klientami, a ponoszą skutki? | Mapa interesariuszy, konsultacje, informacja zwrotna | Pominięcie osób ocenianych lub klasyfikowanych przez system |
| Co uruchamia ponowną ocenę systemu? | Kryteria zmian: model, dane, zastosowanie, użytkownicy, wyniki | Brak ponownej oceny po zmianie kontekstu |
| Jak red teaming wpłynął na dopuszczenie do użycia? | Raport, decyzja o ryzyku, poprawki, ponowny test | Raport bez właściciela i bez reakcji na ustalenia |
| Czy incydent AI musi być cyberatakiem? | Klasyfikacja zdarzeń i scenariusze szkód | Brak obsługi dyskryminacji lub szkodliwych rekomendacji |
Sygnał słabości nie jest automatycznie niezgodnością. Niezgodność wymaga wskazania konkretnego, mającego zastosowanie wymagania ISO/IEC 42001 lub zobowiązania organizacji oraz obiektywnego dowodu, że nie zostało spełnione. Brak komitetu etycznego czy osobnego red teamu sam w sobie nie uzasadnia niezgodności z ISO/IEC 42001.
Dwie granice warto mieć na uwadze. Audyt ocenia procesy, nie ludzi. Audyt systemu zarządzania nie zastępuje też technicznej oceny bezpieczeństwa, jakości ani legalności każdego systemu AI.
Przykład autorski: asystent RAG wspierający audyt
To przykład autorski COE, nie studium przypadku z IEEE. Organizacja używa asystenta opartego na wyszukiwaniu w korpusie dokumentów (RAG), aby szybciej odnajdywać wymagania i przygotowywać propozycje ustaleń audytowych. Ryzyko: odpowiedź oparta na nieaktualnym wydaniu normy lub na niepełnym kontekście trafia do ustalenia wobec klienta.
Zasady IEEE pomagają nazwać problem: unikanie szkody, kompetencje, nadzór człowieka, przejrzystość i rozliczalność. IEEE w 5.2.3.4 f) wprost wskazuje podatność systemów AI na wstrzykiwanie poleceń, manipulację przez pobierane treści i zatruwanie korpusu, czyli zagrożenia typowe dla RAG. Szerzej opisaliśmy je we wpisie o zagrożeniach systemów AI według ISO/IEC 27090. Procesy 6.1, 6.7 i 6.8 kierują uwagę na wersje korpusu, prawa do wykorzystania treści, ocenę przed wdrożeniem oraz próby z pytaniami wieloznacznymi, sprzecznymi dokumentami i żądaniem nieistniejących wymagań.
W AIMS przekłada się to na ocenę ryzyka i wpływu, właściciela systemu, proces pochodzenia danych (A.7.5), weryfikację i walidację (A.6.2.4) oraz rejestrowanie zdarzeń (A.6.2.8). Przykładowe zabezpieczenie: każda propozycja ustalenia wskazuje wydanie i punkt źródła i przed użyciem wymaga weryfikacji przez kompetentnego audytora. Dowody to wyniki testów, rejestr wersji korpusu, próbka zweryfikowanych odpowiedzi i decyzja dopuszczająca. Progi skuteczności dobiera organizacja do zastosowania; IEEE ich nie narzuca.
Dwa zalecenia IEEE do dyskusji w MŚP
Pierwsze to jawność nadzoru etycznego. IEEE w 6.3.4 c) zaleca publiczne ujawnienie istnienia, składu i poziomu aktywności rady, komitetu lub doradców ds. etyki. Dla dużej organizacji to element wiarygodności. Dla MŚP z jednoosobowym doradcą albo funkcją zleconą na zewnątrz to decyzja nieoczywista. Warto podjąć ją świadomie i zapisać uzasadnienie zakresu ujawnienia.
Drugie to niezależność red teamu. IEEE w 6.8.3 wskazuje, że zespół red team powinien być niezależny od zespołów inżynierskich i zarządczych odpowiedzialnych za system i raportować bezpośrednio do organu nadzoru, aby ograniczyć konflikt interesów i myślenie grupowe. W małej organizacji niezależność można zapewnić przez stronę zewnętrzną lub osobę spoza zespołu systemu. Kluczowy jest kanał raportowania do zarządu i decyzja o reakcji na ustalenia.
Kontekst regulacyjny UE
IEEE 2863 zakłada, że organizacja przestrzega prawa, i w 4.8 zastrzega, że stosowanie jego zaleceń nie oznacza zgodności z wymaganiami regulacyjnymi. Certyfikat ISO/IEC 42001 również nie jest oceną zgodności z AI Act, czyli Rozporządzeniem (UE) 2024/1689. Domniemanie zgodności dla części obowiązków dostawców systemów wysokiego ryzyka daje zharmonizowana EN 18286, przywołana w Dzienniku Urzędowym UE 14.10.2026, i to tylko w zakresie wskazanym w jej załączniku ZA. ISO/IEC 42001 takiego skutku nie ma. Różnice opisaliśmy we wpisie o EN 18286 i ISO/IEC 42001 w kontekście domniemania zgodności.
Podsumowanie
IEEE 2863 i ISO/IEC 42001 nie konkurują ze sobą. IEEE mówi organowi nadzoru, jakie zasady i procesy przyjąć. ISO/IEC 42001 wymaga systemu, w którym te wybory zostawiają ślad w ocenie ryzyka i wpływu, w deklaracji stosowania i w dowodach skuteczności. Mapowanie jest punktem startu, nie dowodem zgodności.
Jeżeli budujesz lub rozwijasz system zarządzania AI według ISO/IEC 42001, zacznij od jednego systemu AI i jednej decyzji: sprawdź, czy da się ją prześledzić od zasady do dowodu. W kolejnym wpisie serii przyjrzymy się generatywnej AI w firmie w świetle studium przypadku z IEEE 2863.
Bibliografia:
- IEEE Std 2863-2026. IEEE Recommended Practice for Organizational Governance of Artificial Intelligence. IEEE Standards Association. standards.ieee.org
- ISO/IEC 42001:2023. Information technology — Artificial intelligence — Management system. ISO/IEC. ISO.org
- ISO. ISO/IEC 42001 explained. ISO.org
- Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2024/1689 z dnia 13 czerwca 2024 r. w sprawie ustanowienia zharmonizowanych przepisów dotyczących sztucznej inteligencji (akt w sprawie sztucznej inteligencji). EUR-Lex
Dodaj tu swój tekst nagłówka
Nie. IEEE 2863-2026 jest dokumentem typu Recommended Practice i formułuje zalecenia, a nie wymagania. Certyfikacji podlega system zarządzania AI według ISO/IEC 42001. Postanowienia IEEE mogą być oceniane w audycie tylko wtedy, gdy organizacja przyjęła je jako własne zobowiązania.
Najpierw sprawdza się, czy zalecenie można zrealizować przez uszczegółowienie zabezpieczenia z tabeli A.1 ISO/IEC 42001. Jeżeli nie, organizacja może dodać własne zabezpieczenie, bo norma dopuszcza to w A.1 i w klauzuli 6.1.3. W deklaracji warto zapisać przyczynę doboru, powiązane ryzyko, właściciela i sposób oceny skuteczności.
Sam w sobie nie. Niezgodność wymaga wskazania konkretnego wymagania ISO/IEC 42001 lub zobowiązania organizacji i obiektywnego dowodu jego niespełnienia. Audytor sprawdzi natomiast, czy role, zgłaszanie obaw i ocena wpływu działają w sposób adekwatny do ryzyka.
Nie. Taka tabela pokazuje, w których klauzulach i zabezpieczeniach szukać realizacji zaleceń. Zgodność potwierdzają dopiero zapisy, decyzje i wyniki, które dowodzą, że przyjęte mechanizmy działają w praktyce.
Nie. IEEE 2863 sam zastrzega, że stosowanie jego zaleceń nie oznacza zgodności z wymaganiami prawnymi, a certyfikat ISO/IEC 42001 nie jest oceną zgodności z AI Act. Oba dokumenty mogą jednak uporządkować zarządzanie obowiązkami i ich dokumentowanie.
Ekspert w zakresie systemów zarządzania ISO, cyberbezpieczeństwa, compliance i AI governance. Audytor, konsultant, trener.
Ilustracje w tym wpisie zostały wygenerowane przy użyciu narzędzi sztucznej inteligencji. Treść merytoryczna powstała w redakcji COE i jest podpisana imiennie.