Systemu AI nie trzeba hakować, żeby go skompromitować. Wystarczy zatruć mu dane albo cierpliwie zadawać pytania. Pierwsza międzynarodowa norma o zagrożeniach dla systemów AI pokazuje, co chronić, przed czym i dlaczego zabezpieczeń AI nie wdraża się raz na zawsze.
Stan wiedzy na 30.10.2026. Polskie tłumaczenie normy (PN) nie jest jeszcze dostępne. Terminy angielskie podajemy jako podstawowe, z proponowanymi polskimi odpowiednikami. Kolejne wpisy cyklu przyniosą nowsze dane.
Twój SZBI obejmuje narzędzia AI? Sprawdź pięć rzeczy przed najbliższym audytem:
W SKRÓCIE:
- ISO/IEC 27090:2026 to wytyczna, nie podstawa certyfikacji. Buduje na ISO/IEC 27001 i 27002
- Najpierw fundament: ochrona stosu bywa skuteczniejsza niż techniki specyficzne dla AI
- Mapa zagrożeń: od zatruwania danych po prompt injection, według aktywów i właściwości CIA
- Agenci AI dostają uprawnienia do zadania, a nie uprawnienia użytkownika
- Zabezpieczenia AI wzajemnie się osłabiają i tracą skuteczność w czasie
- Pięć kroków, by wpiąć normę w istniejący SZBI lub system AI
WPROWADZENIE
ISO/IEC 27090:2026 to opublikowana w październiku 2026 r. norma wytyczna komitetu ISO/IEC JTC 1/SC 27, która opisuje zagrożenia specyficzne dla systemów sztucznej inteligencji. Należą do nich zatruwanie danych treningowych, ataki unikowe, wnioskowanie o przynależności, eksfiltracja i odwracanie modelu, bezpośrednie zatrucie modelu, prompt injection oraz ujawnianie wrażliwych danych w odpowiedziach modelu. Dla każdego zagrożenia norma podaje skutki oraz metody wykrywania i ograniczania, uporządkowane według zagrożonego aktywa i naruszonej właściwości bezpieczeństwa w całym cyklu życia systemu. Nie jest podstawą certyfikacji i nie zastępuje ISO/IEC 27001 ani ISO/IEC 27002. Zakłada działający fundament klasycznych zabezpieczeń i dodaje do niego środki specyficzne dla AI. Wyróżnia ją klauzula 7: zabezpieczenia AI mogą się wzajemnie osłabiać i tracą skuteczność w czasie, dlatego wymagają stałej walidacji. W ocenie COE – Centre of Excellence (Centrum Certyfikacji QSCert) normę najprościej wykorzystać jako źródło zabezpieczeń przy postępowaniu z ryzykiem w SZBI według ISO/IEC 27001 i w systemie zarządzania AI według ISO/IEC 42001.
Zgodnie z klauzulą 1 norma dotyczy organizacji każdej wielkości, które systemy AI rozwijają albo tylko z nich korzystają. Jej punkt wyjścia jest trzeźwy. Wprowadzenie przypomina, że systemy AI dziedziczą wszystkie klasyczne podatności informatyczne. Do nich dochodzą nowe zagrożenia, oparte na danych, manipulacji danymi wejściowymi i działaniu samych modeli. Najbardziej niepokojący przykład z tej samej części: model da się odtworzyć i w praktyce ukraść wyłącznie przez legalne zapytania. Może się to udać nawet wtedy, gdy klasyczne zabezpieczenia działają poprawnie.
Ten tekst otwiera krótki cykl. Pokazujemy w nim, czym norma jest, jak jest zbudowana i jak wpiąć ją w istniejący system zarządzania. W lutym opisywaliśmy dodatkowe kontrolki ISO/IEC 27001 dla generatywnej AI. Kolejny wpis zestawi tamte propozycje z tym, co wnosi ISO/IEC 27090.
CZYM ISO/IEC 27090 JEST, A CZYM NIE JEST
ISO/IEC 27090 jest normą wytyczną, a nie normą wymagań. Nie istnieje według niej certyfikacja. Nie zastępuje też ISO/IEC 27001 ani ISO/IEC 27002, tylko na nich się opiera. Wprowadzenie wprost zaleca stosowanie praktyk z obu tych norm. Organizacja, która chce wykazać skuteczność zabezpieczeń AI certyfikatem, nadal robi to w ramach systemu zarządzania bezpieczeństwem informacji zgodnego z ISO/IEC 27001 albo systemu zarządzania AI.
Dla audytorów jest tu ważny niuans. Klauzula 5.1 zawiera dwa zdania w trybie wymagającym („shall”):
- zabezpieczenia bezpieczeństwa informacji, takie jak opisane w ISO/IEC 27002, mają zostać wdrożone na podstawie potrzeb organizacji i wyników oceny ryzyka;
- potencjalne kompromitacje specyficzne dla AI, w tym wymienione w Tabeli 1, mają być uwzględniane w całym cyklu życia systemu.
W naszej ocenie te zdania nie tworzą nowego obowiązku certyfikacyjnego. Porządkują natomiast oczekiwania: najpierw fundament klasycznych zabezpieczeń, potem świadome uwzględnienie zagrożeń AI. Audytor SZBI może traktować ISO/IEC 27090 jako punkt odniesienia dobrej praktyki. Pomaga ona ocenić, czy szacowanie ryzyka nie pominęło oczywistych scenariuszy dla systemów AI objętych zakresem.
Relację z ISO/IEC 42001:2023 najprościej opisać tak: 42001 mówi, jak organizacja ma zarządzać sztuczną inteligencją, a 27090 przed czym bronić konkretny system AI. Sama norma w podklauzuli 5.2 odsyła do ISO/IEC 42001 po wskazówki, jak zbudować program nadzoru nad AI.
Warto też odróżnić ją od prawa. ISO/IEC 27090 nie jest normą zharmonizowaną i nie daje domniemania zgodności z art. 15 AI Act. Tę rolę ma pełnić europejski projekt prEN 18282, który na dzień 30.10.2026 nie został opublikowany.
STRUKTURA NORMY: OD FUNDAMENTU DO INTERAKCJI ZABEZPIECZEŃ
Norma prowadzi czytelnika w czterech krokach:
- klauzula 5: fundament bezpieczeństwa, na którym stoi system AI;
- klauzula 6: katalog zagrożeń specyficznych dla AI, ułożony według aktywów;
- podklauzula 6.11: zalecenia dla eksploatacji;
- klauzula 7: to, jak zabezpieczenia wpływają na siebie nawzajem i jak zmienia się ich skuteczność w czasie.
Uzupełniają je trzy załączniki informacyjne:
- A: mapowanie ataków na cykl życia i aktywa,
- B: klasyczne ataki w wersji specyficznej dla AI,
- C: uczenie federacyjne.
Fundament przed egzotyką (klauzula 5)
Klauzula 5 zaczyna od stwierdzenia, które łatwo przeoczyć. System AI to zwykle komponent oprogramowania wbudowany w większy system, a nie samodzielny model. Wszystko, co chroni oprogramowanie, chroni więc także AI. Norma idzie dalej: zabezpieczenie stosu technologicznego bywa efektywniejszym punktem startu niż środki specyficzne dla AI. Jeśli organizacja obawia się utraty poufności modelu, szybciej zyska na ochronie przed bezpośrednią kradzieżą parametrów niż na kosztownych mechanizmach przeciw eksfiltracji przez API (5.1).
Na tym fundamencie norma buduje kilka filarów.
Program nadzoru nad AI (5.2). Organizacja bierze odpowiedzialność za AI: prowadzi inwentarz systemów i sposobów ich użycia, analizuje ich ryzyka i nimi zarządza.
Zero trust w cyklu życia AI (5.3). Norma wychodzi od zasad zero trust zawartych w ISO/IEC 27002:2022, 8.27, i przenosi je na grunt AI:
- każde zapytanie o dokument w systemie RAG ma być osobno uwierzytelniane i autoryzowane;
- każda akcja agenta AI ma być osobno weryfikowana, a uprawnienia mają wygasać po zakończeniu zadania;
- dane wejściowe od użytkownika mają być walidowane niezależnie od tego, czy użytkownik się uwierzytelnił.
Inżynieria oprogramowania i zespoły mieszane (5.4). Norma zaleca zespoły łączące data scientistów z inżynierami oprogramowania. Wskazuje też praktyki specyficzne dla AI: śledzenie pochodzenia i historii danych treningowych, identyfikowalność modeli, ciągłą walidację oraz testy na starzenie się modelu i dryf koncepcji.
Łańcuch dostaw (5.5). Norma wymienia cztery wektory ataku:
- zatrute dane,
- trojany ukryte w gotowych modelach,
- złośliwy kod w bibliotekach AI,
- celowe fałszowanie pochodzenia danych lub modeli (provenance confusion).
Odpowiedzią ma być m.in. weryfikacja pochodzenia, kryptograficzne podpisywanie zbiorów danych i modeli, korzystanie ze zweryfikowanych repozytoriów oraz regularne skanowanie zależności.
Modelowanie zagrożeń i red teaming (5.6, 5.7). Norma zaleca też modelowanie zagrożeń w całym cyklu życia oraz testy red teaming, czyli kontrolowane ataki naśladujące realnych przeciwników.
Mapa zagrożeń: aktywa, właściwości, cykl życia (klauzula 6)
Rdzeniem normy jest Tabela 1. Porządkuje zagrożenia według dwóch kryteriów: które aktywo jest kompromitowane jako pierwsze i która właściwość bezpieczeństwa zostaje naruszona.
| Aktywo | Naruszona właściwość | Przykładowe typy kompromitacji |
|---|---|---|
| Model | integralność | direct model poisoning (bezpośrednie zatrucie modelu) |
| Model | poufność | kradzież i eksfiltracja modelu |
| Dane treningowe | poufność | model inversion (odwracanie modelu), membership inference (wnioskowanie o przynależności), wyciek danych treningowych, sensitive model output (wrażliwe dane w odpowiedzi modelu) |
| Dane treningowe | integralność | data poisoning (zatruwanie danych) |
| Dane testowe | integralność | prompt injection, evasion attack (atak unikowy) |
| Dane testowe | poufność | model input leak (wyciek danych wejściowych) |
| Wynik modelu | integralność | data poisoning, prompt injection, evasion, generowanie niebezpiecznego kodu, jailbreaking |
| Usługa | dostępność | niedostępność usługi AI, np. przez wyczerpanie zasobów |
Opracowanie COE na podstawie ISO/IEC 27090:2026, Tabela 1; polskie odpowiedniki terminów są propozycją roboczą do czasu wydania PN. „Dane testowe” zgodnie z oryginałem (test data); załącznik A normy doprecyzowuje to aktywo jako dane wejściowe lub testowe.
Każdy typ kompromitacji jest opisany w tym samym układzie: opis, skutki, wykrywanie, ograniczanie. Dzięki temu klauzula 6 może służyć jako szkielet rejestru ryzyk AI. Norma zastrzega jednak, że katalog nie jest wyczerpujący. Kilka obserwacji wartych wyniesienia z tekstu:
- Data poisoning (6.2). Większość udokumentowanych ataków wymagała zatrucia zaledwie niewielkiego odsetka danych. Norma przyznaje też, że wiarygodne wykrywanie zatrucia wciąż jest otwartym problemem badawczym. Repozytoria RAG mogą zostać zatrute nawet wtedy, gdy sam model pozostaje nienaruszony. Ciekawostką jest atak polegający wyłącznie na zmianie kolejności podawania danych treningowych. Dla modeli wysokiego ryzyka norma zaleca więc traktowanie sekwencji trenowania i dostrajania promptów jako odrębnego elementu konfiguracji.
- Model exfiltration (6.5). Atak prowadzony jest wyłącznie poprawnymi zapytaniami. Niekiedy pełne odtworzenie modelu wymaga znacznie mniejszej liczby zapytań, niż potrzeba było do jego wytrenowania. Wśród środków zaradczych norma wymienia ukrywanie wartości prawdopodobieństwa w odpowiedziach, ograniczanie częstotliwości zapytań i znakowanie modelu (watermarking).
- Prompt injection (6.9). Wykrywanie jest trudne, bo system AI nie odróżnia danych wejściowych od wewnętrznych instrukcji. Odmiana pośrednia dociera do modelu przez skompromitowane źródło zewnętrzne, np. stronę internetową dołączaną do kontekstu. Jednym z zalecanych środków jest wyraźne oddzielanie niezaufanej treści w prompcie, np. znacznikami, wraz z instrukcją, by nie traktować jej jak poleceń.
- Injection w wyniku modelu (6.10). Odpowiedź modelu może zawierać klasyczny atak, np. cross-site scripting. Norma zaleca traktowanie wyniku jako niezaufanego, jeśli niezaufane były dane treningowe.
- Sensitive model output (6.8). Ta kompromitacja nie wymaga atakującego. Może ujawnić się przy zwykłym użytkowaniu, a wśród ujawnianych danych mogą znaleźć się także teksty i obrazy chronione prawem autorskim.
Załącznik A pokazuje, na których etapach cyklu życia materializuje się każde zagrożenie. Rozdziela też etapy, na których interesariuszami są zwykle dostawcy i twórcy systemu, od tych, na których są nimi klienci i użytkownicy. W praktyce audytowej to gotowa podstawa do rozmowy o podziale odpowiedzialności między organizacją a dostawcą AI.
Załącznik B przypomina, że klasyczne ataki mają swoje wersje dla AI. Przykłady:
- tzw. sponge attacks, czyli zapytania wymuszające nawet trzydziestokrotnie dłuższe przetwarzanie i wyższe zużycie energii;
- backdoory ukryte w plikach wag modelu, przed którymi chronią m.in. bezpieczne formaty zapisu wag;
- zmiana środowiska zagrożeń, gdy organizacja dostraja model w chmurze na własnych dokumentach.
Eksploatacja: dane, nadzór, agenci, logi (6.11 i 7.5–7.9)
Podklauzula 6.11 przenosi ciężar z ataków na codzienne działanie systemu.
Ograniczanie danych (6.11.2). Norma zaleca ograniczanie powierzchni ataku przez:
- minimalizację danych treningowych,
- krótką retencję,
- szyfrowanie i maskowanie,
- ograniczanie publicznie dostępnych szczegółów technicznych systemu.
Ostatni punkt norma świadomie zestawia z wymogami przejrzystości. Chodzi o to, by nie ujawniać informacji przydatnych napastnikowi, a jednocześnie pozostać transparentnym wobec interesariuszy.
Niepożądane zachowanie modelu (6.11.3). Gdy system AI zachowuje się w niepożądany sposób, norma zaleca najpierw ustalić, czy w ogóle chodzi o atak. Wśród częstych przyczyn wymienia też:
- overreliance, czyli nadmierne zaufanie użytkowników do systemu;
- excessive agency, czyli zbyt szerokie uprawnienia i autonomię nadane systemowi przez inżynierów.
Nadzór człowieka (6.11.3.2). Norma zwraca uwagę na zjawisko „out-of-the-loop”. Operator, któremu system stale podsuwa wybór „zatwierdź” albo „odrzuć”, z czasem przestaje rozumieć, co zatwierdza.
Najmniejsze uprawnienia dla agentów (6.11.3.3). Uprawnienia agentów AI mają być przypisane do zadania, ograniczone w czasie i wydzielone tożsamościowo. Przykład z normy dotyczy asystenta rozliczania wydatków. Działa on na własnym koncie usługowym zamiast dziedziczyć wszystkie uprawnienia użytkownika, a próby wyjścia poza jego domenę, np. do systemu płacowego, są blokowane automatycznie.
Pochodzenie systemu i danych (6.11.4). Norma zaleca ramę rejestrującą pochodzenie wszystkich krytycznych komponentów systemu AI, chronioną podpisami kryptograficznymi. Rejestry pochodzenia mają być dostępne m.in. dla audytów wewnętrznych. To bezpośredni punkt zaczepienia dla programu audytów.
Klauzula 7 dodaje konkrety operacyjne:
- Logi (7.5). Zalecany minimalny zakres logów użycia modelu to: dane wejściowe, data, czas, identyfikator użytkownika, wynik i wersja modelu.
- Środowisko deweloperskie (7.6). W systemach AI dane wrażliwe znajdują się zwykle w środowisku deweloperskim, odwrotnie niż w klasycznym IT. Repozytorium RAG z poufnymi dokumentami steruje zachowaniem modelu tak jak dane treningowe, więc wymaga tych samych zabezpieczeń.
- Ograniczanie zapytań (7.8). Throttling w kontekście AI nie służy ochronie przed przeciążeniem. Ma utrudniać napastnikowi eksperymentowanie.
Zabezpieczenia też się psują (klauzula 7.1–7.4)
Ta część najbardziej odróżnia ISO/IEC 27090 od typowych katalogów zabezpieczeń. Norma wskazuje trzy zjawiska, które w praktyce rzadko trafiają do dokumentacji systemu.
Po pierwsze, zabezpieczenia mogą się wzajemnie osłabiać (7.2). Norma przywołuje obserwację z projektu NIST Dioptra. Trenowanie modelu na danych adwersaryjnych jednego typu znacznie zwiększyło jego podatność na ataki z użyciem tzw. łatek adwersaryjnych. Zalecenie: przy każdej nowej mitygacji, przed wdrożeniem modelu, weryfikować skuteczność całego zestawu zabezpieczeń i wydajność modelu.
Po drugie, mitygacje muszą działać spójnie na kolejnych etapach cyklu życia (7.3). Ochrona przed wnioskowaniem o przynależności może wymagać jednocześnie kontroli danych treningowych, trenowania z prywatnością różnicową i filtrowania wejść oraz wyjść podczas działania. Każde z tych ogniw musi pasować do pozostałych.
Po trzecie, skuteczność zabezpieczeń spada w czasie (7.4). Tak samo jak sam model. Norma zaleca bieżące monitorowanie tej degradacji, ponowne trenowanie, także na danych użytych do mitygacji, oraz pełną walidację przed ponownym wdrożeniem.
Stanowisko autora: z perspektywy SZBI skuteczność zabezpieczenia systemu AI nie jest statusem „wdrożone” w Deklaracji Stosowania. Jest zmienną, którą trzeba mierzyć w ramach klauzuli 9.1 ISO/IEC 27001 i omawiać na przeglądzie zarządzania.
KORZYŚCI ZE STOSOWANIA NORMY
Pierwszą korzyścią jest wspólny język. Zespół bezpieczeństwa i zespół data science często opisują te same problemy innymi słowami. Tabela 1 i układ „aktywo, właściwość, cykl życia” dają im słownik, w którym zatrucie danych, kradzież modelu i prompt injection stają się pozycjami rejestru ryzyk, a nie hasłami z konferencji.
Druga korzyść to lepsze wykorzystanie budżetu. Norma wprost wskazuje, że ochrona stosu technologicznego bywa efektywniejszym punktem startu niż zaawansowane techniki odporności modelu. Dla zarządu to argument, by najpierw domknąć podstawy (logi, dostępy, separację środowisk), a dopiero potem inwestować w rozwiązania specyficzne dla AI.
Trzecia korzyść dotyczy relacji z dostawcami. Załącznik B, w punkcie B.3.3, podsuwa konkretne tematy do umów:
- bezpieczeństwo łańcucha dostaw w kontraktach z dostawcami danych i gotowych modeli,
- szkolenia dla dostawców,
- wymianę specyfikacji modeli, np. kart modelu,
- testy red teaming dostarczonych modeli.
Dla organizacji, które kupują AI zamiast ją budować, to gotowa lista pytań do dostawcy.
Czwarta korzyść jest najmniej oczywista: ochrona przed fałszywym poczuciem bezpieczeństwa. Klauzula 7 przypomina, że zabezpieczenie AI wdrożone rok temu mogło stracić skuteczność albo osłabić inne zabezpieczenie. Organizacja, która to rozumie, planuje walidację z góry, zamiast odkrywać problem po incydencie.
ZASTOSOWANIE PRAKTYCZNE: JAK WPIĄĆ 27090 W ISTNIEJĄCY SYSTEM
ISO/IEC 27090 nie wymaga budowy osobnego systemu. Najprościej traktować ją jako źródło kandydackich zabezpieczeń przy postępowaniu z ryzykiem według ISO/IEC 27001, kl. 6.1.3, zgodnie z logiką, którą potwierdziło szóste wydanie ISO/IEC 27000. W systemie zarządzania AI jej wskazówki trafiają do zabezpieczeń cyklu życia. Sama norma przywołuje tu zabezpieczenia A.6.2.3 i A.6.2.6 ISO/IEC 42001:2023.
Praktyczna sekwencja składa się z pięciu kroków.
1. Inwentarz systemów AI (5.2). Inwentarz obejmuje także narzędzia SaaS i agentów. Przy każdym systemie warto określić, czy organizacja jest jego twórcą, czy użytkownikiem. Od tego zależy, która część cyklu życia z załącznika A jest jej odpowiedzialnością.
2. Rejestr aktywów AI (Tabela 1, zał. A.3–A.4). Do rejestru aktywów dopisuje się aktywa specyficzne dla AI: dane treningowe, testowe i wejściowe, parametry modelu, wyniki, narzędzia przygotowania danych i repozytoria RAG.
3. Scenariusze zagrożeń w szacowaniu ryzyka (klauzula 6). Scenariusze z klauzuli 6 filtruje się według charakteru systemu. Inne zagrożenia dotyczą AI generatywnej, a inne predykcyjnej. Uczenie ciągłe, RAG i agenci każdorazowo poszerzają powierzchnię ataku.
4. Dobór zabezpieczeń. Najpierw sięga się po klasyczne zabezpieczenia z ISO/IEC 27002, które norma sama przywołuje:
- logowanie i monitorowanie: 8.15 i 8.16,
- bezpieczna architektura: 8.27,
- dostawcy i chmura: 5.19–5.23,
- separacja środowisk: 8.31.
Dopiero potem dobiera się środki specyficzne dla AI. Każde zabezpieczenie trafia do Deklaracji Stosowania z powiązaniem do konkretnego ryzyka.
5. Monitorowanie skuteczności. Ciągłą walidację modelu (6.11.3.5) i ocenę degradacji zabezpieczeń (7.4) włącza się do monitorowania i przeglądu zarządzania.
Z naszego doświadczenia audytowego, na razie zbyt skromnego, by je uogólniać: w znanych nam przypadkach organizacja z działającym SZBI, która AI wyłącznie używa, zamykała przegląd luk względem ISO/IEC 27090 w kilka dni roboczych. Organizacja rozwijająca własne modele lub agentów potrzebowała kilku tygodni. Dochodziły tam pochodzenie danych i modeli, red teaming oraz walidacja ciągła, a przede wszystkim uzgodnienia między wieloma stronami zaangażowanymi w system.
ISO/IEC 27090 nie rozwija szczegółowo reagowania na incydenty. Tę stronę tematu opisaliśmy w tekście o tym, dlaczego klasyczne playbooki zawodzą przy incydentach AI. Sytuację odwrotną, czyli AI jako narzędzie atakującego, omawia wpis o tym, jak AI skraca drogę od podatności do exploita.
Pytania, które warto zadać przed najbliższym audytem
- Czy inwentarz AI obejmuje także narzędzia SaaS i agentów, z określeniem roli organizacji (twórca czy użytkownik)?
- Czy szacowanie ryzyka zawiera choć jeden scenariusz zatrucia danych, prompt injection lub eksfiltracji modelu tam, gdzie mają zastosowanie?
- Czy repozytoria RAG są chronione tak jak dane treningowe?
- Czy logi użycia modelu pozwalają ustalić, która wersja modelu dała konkretny wynik?
- Czy wiadomo, kiedy ostatnio sprawdzano skuteczność zabezpieczeń AI i kto za to odpowiada?
Podsumowanie
ISO/IEC 27090:2026 nie dodaje nowego systemu zarządzania. Pokazuje, przed czym trzeba bronić system AI, gdy fundament bezpieczeństwa informacji już stoi: danych treningowych, modelu, wyników i usługi, w całym cyklu życia. Najcenniejsza lekcja normy dotyczy czasu. Zabezpieczenia AI wchodzą ze sobą w interakcje i tracą skuteczność, więc trzeba je mierzyć, a nie tylko odhaczać.
Certyfikacji według ISO/IEC 27090 nie ma, ale jej wskazówki wzmacniają dwa certyfikowalne systemy: system zarządzania AI zgodny z ISO/IEC 42001 oraz SZBI zgodny z ISO/IEC 27001. Jeśli przygotowujesz któryś z nich do audytu, zacznij od inwentarza AI i pięciu pytań powyżej. W kolejnym wpisie zestawimy z ISO/IEC 27090 nasze lutowe propozycje dodatkowych kontrolek.
Bibliografia:
- ISO/IEC 27090:2026. Cybersecurity — Artificial intelligence (AI) — Addressing security threats and compromises to AI systems. Wydanie 1, ISO/IEC, 2026-10. ISO.org
- ISO/IEC 27001:2022. Information security, cybersecurity and privacy protection — Information security management systems — Requirements. ISO.org
- ISO/IEC 27002:2022. Information security, cybersecurity and privacy protection — Information security controls. ISO.org
- ISO/IEC 42001:2023. Information technology — Artificial intelligence — Management system. ISO.org
- Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2024/1689 (AI Act), art. 15. Dziennik Urzędowy UE. EUR-Lex
FAQ: Zatrute dane, skradziony model. Co mówi ISO/IEC 27090:2026?
ISO/IEC 27090:2026 to międzynarodowa norma wytyczna o zagrożeniach specyficznych dla systemów sztucznej inteligencji, opublikowana w październiku 2026 r. Opisuje m.in. zatruwanie danych, kradzież i eksfiltrację modelu oraz prompt injection. Dla każdego zagrożenia podaje skutki oraz metody wykrywania i ograniczania w całym cyklu życia systemu AI.
Nie. ISO/IEC 27090 jest wytyczną i nie przewiduje certyfikacji. Organizacje, które chcą potwierdzić bezpieczeństwo swoich systemów AI certyfikatem, robią to w ramach SZBI zgodnego z ISO/IEC 27001 lub systemu zarządzania AI zgodnego z ISO/IEC 42001. ISO/IEC 27090 pomaga wtedy uzupełnić szacowanie ryzyka i dobór zabezpieczeń.
ISO/IEC 42001 to norma wymagań dla systemu zarządzania sztuczną inteligencją w organizacji. ISO/IEC 27090 opisuje, przed jakimi atakami bronić konkretny system AI i jakimi środkami. Normy się uzupełniają. ISO/IEC 27090 sama odsyła do ISO/IEC 42001 po wskazówki, jak zbudować program nadzoru nad AI.
Tak. Zakres normy obejmuje organizacje każdej wielkości, które systemy AI rozwijają albo z nich korzystają. Użytkownik narzędzi AI skorzysta zwłaszcza z części o łańcuchu dostaw, ograniczaniu danych, logowaniu użycia modelu i najmniejszych uprawnieniach dla agentów AI.
Nie. ISO/IEC 27090 nie jest normą zharmonizowaną w rozumieniu AI Act i nie daje domniemania zgodności z wymaganiami cyberbezpieczeństwa z art. 15. Tę funkcję ma pełnić europejski projekt prEN 18282, który na dzień 30.10.2026 nie został opublikowany.
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.