ISO 27090 wyjaśniona dla zespołów bezpieczeństwa AI

ISO/IEC 27090:2026 to międzynarodowa norma zawierająca wytyczne dotyczące zagrożeń bezpieczeństwa i naruszeń, które dotykają systemy sztucznej inteligencji. Opublikowana 14 października 2026 r., opisuje, w jaki sposób organizacje mogą rozumieć, wykrywać i ograniczać te zagrożenia w całym cyklu życia AI. Jej formalny tytuł brzmi Cybersecurity — Artificial intelligence (AI) — Addressing security threats and compromises to AI systems. Karta publikacji ISO

Dla zespołu bezpieczeństwa praktyczne pytanie jest proste: co atakujący mógłby zmienić lub ukraść albo do czego mógłby nakłonić system AI i co ograniczyłoby wynikające z tego szkody?

Ten przewodnik wyjaśnia zakres normy ISO 27090, główne zagrożenia bezpieczeństwa AI, jej relację z ISO 27001 i ISO 42001 oraz praktyczny sposób przełożenia wytycznych na prace z zakresu bezpieczeństwa, które mają właścicieli, zabezpieczenia i dowody. Materiały źródłowe zweryfikowano 18 października 2026 r.

Co obejmuje norma ISO 27090

ISO 27090 koncentruje się na ochronie systemów AI. Jej przedmiot wykracza poza generatywną AI, duże modele językowe i chatboty i obejmuje systemy AI w szerszym rozumieniu. Objaśnienie ISO 27090 przygotowane przez ISO

Opublikowana norma łączy uznane praktyki bezpieczeństwa informacji z zagrożeniami specyficznymi dla AI. Jej treść obejmuje ład, bezpieczeństwo łańcucha dostaw, modelowanie zagrożeń i red teaming, a następnie rodzaje naruszeń, w tym zatruwanie, unikanie wykrycia (evasion), ujawnianie informacji i prompt injection. Norma rozważa też, jak środki ograniczające ryzyko wpływają na siebie nawzajem i jak zachowują skuteczność w czasie. Opublikowany fragment ISO/IEC 27090

Zakres obejmuje organizacje każdej wielkości, które rozwijają lub wykorzystują AI, w tym przedsiębiorstwa, instytucje publiczne i organizacje non-profit. Zakup usługi AI od strony trzeciej nie wyłącza więc organizacji z grona adresatów normy. Karta publikacji IEC

Dobrym punktem wyjścia jest wspólny przegląd z udziałem bezpieczeństwa, inżynierii, zespołu danych, zakupów i właściciela biznesowego. Każdy z nich powinien umieć wyjaśnić część systemu, którą kontroluje, oraz decyzje, w których zależy od innych.

Dlaczego systemy AI wymagają dodatkowej analizy bezpieczeństwa

Aplikacja AI łączy kilka elementów, które zasługują na odrębną analizę: oprogramowanie, dane, pliki lub usługi modelu, instrukcje, użytkowników i działania w dalszej części procesu.

Weźmy asystenta dokumentów połączonego z wewnętrzną bazą wiedzy. Konwencjonalny przegląd może objąć uwierzytelnianie, szyfrowanie i podatności oprogramowania. Przegląd bezpieczeństwa AI powinien ponadto zapytać, co się stanie, jeśli pobrany dokument spróbuje zmienić instrukcje asystenta, czy użytkownicy mogą pobrać materiały wykraczające poza ich uprawnienia i jakie działania może wywołać wygenerowany wynik.

Pytania te nabierają wagi, gdy asystent może aktualizować rekordy lub wywoływać zewnętrzne narzędzia. Błędna odpowiedź i nieautoryzowane działanie mają różne skutki i wymagają różnych zabezpieczeń.

W pierwszym przeglądzie przeanalizuj trzy pytania:

• Co może wpływać na system? Uwzględnij dane treningowe, pobierane treści, prompty, dostawców i aktualizacje modelu.
• Co może opuścić system? Uwzględnij odpowiedzi, logi, eksporty i zasoby modelu.
• Co system może zmienić? Uwzględnij pliki, zgłoszenia, konta, transakcje i inne połączone usługi.

To praktyczna metoda określania zakresu dla poniższych przykładów, a nie odwzorowanie klauzul normy.

Zagrożenia bezpieczeństwa AI, które warto rozumieć

Poniższe objaśnienia korzystają z terminologii NIST dotyczącej adversarial machine learning oraz z wytycznych OWASP dla aplikacji LLM. Scenariusze mają charakter poglądowy. Taksonomia adversarial machine learning NIST Wytyczne OWASP dotyczące prompt injection Wytyczne OWASP dotyczące obsługi wyników

Podczas oceny ryzyka zachowaj wyraźne rozróżnienia. Złośliwy dokument pobrany przez aplikację retrieval-augmented generation (RAG) nie jest automatycznie zatruciem danych treningowych: samo pobieranie nie aktualizuje wag modelu. Może natomiast narazić aplikację na pośrednią prompt injection.

W bezpieczeństwie LLM same mocniejsze prompty są niepełną strategią kontroli. OWASP zaleca zabezpieczenia takie jak ograniczone uprawnienia i zatwierdzanie działań wrażliwych, a NCSC podkreśla, że prompt injection należy zarządzać jako ryzykiem ciągłym poprzez projekt i eksploatację systemu. Wytyczne OWASP dotyczące prompt injection Wytyczne NCSC dotyczące ryzyka prompt injection

ISO 27090 a ISO 27001 i ISO 42001

Normy te wspierają różne części pracy organizacji w obszarze bezpieczeństwa i ładu AI.

Rozróżnienia te opierają się na opisach wydawców dotyczących ISO 27001, ISO 27002 i ISO 42001.

Dla zespołu, który prowadzi już SZBI, praktycznym podejściem jest rozszerzenie istniejących zapisów. Dodaj odpowiednie systemy AI do inwentarza aktywów, oceń ich ścieżki ataku, przypisz właścicieli postępowania z ryzykiem i powiąż dowody uzupełniające. Więcej o organizowaniu tej pracy znajdziesz w liście kontrolnej wdrożenia ISO 27001.

Praktyczna lista kontrolna wdrożenia ISO 27090

Poniższe kroki to podejście wdrożeniowe zbudowane na podstawie tematyki normy i publicznych wytycznych dotyczących bezpiecznej AI. Nie są oficjalną listą kontrolną ISO ani wykazem obowiązkowych klauzul.

1. Zdefiniuj system i jego właściciela

Wybierz przypadek użycia AI o jasnym celu biznesowym. Zapisz odpowiedzialnego właściciela, użytkowników, dostawcę modelu, sposób hostingu i połączone usługi.

Następnie wyznacz granice przeglądu. Uwzględnij aplikację i jej zależności, a nie tylko endpoint modelu. Asystent obsługujący klientów z dostępem do narzędzi wymaga innej oceny niż wewnętrzne narzędzie do streszczania tekstów bez uprawnień do działania.

Użyteczny rezultat: zapis systemu określający jego cel, granice, zależności, dozwolone działania i odpowiedzialnego właściciela.

2. Prześledź pochodzenie danych i modelu

Zapisz, skąd pochodzą zbiory danych i artefakty modelu, kto może je zmieniać i które wersje są wdrożone. Uwzględnij dane wejściowe do dostrajania, kolekcje używane do wyszukiwania (retrieval), prompty i kanały informacji zwrotnej istotne dla systemu.

Wytyczne NCSC dotyczące rozwoju zalecają śledzenie zasobów AI i ich pochodzenia, ich ochronę oraz zachowanie informacji potrzebnych do odtworzenia wiarygodnych wersji. Wytyczne NCSC dotyczące bezpiecznego rozwoju AI

W przypadku zakupionego modelu zapytaj dostawcę, za które obowiązki odpowiada i jakie informacje udostępnia, gdy modele lub usługi się zmieniają.

Użyteczny rezultat: wersjonowany inwentarz ze źródłami, zasadami dostępu, historią zmian i obowiązkami dostawców.

3. Zamodeluj zagrożenia dla rzeczywistego przepływu pracy

Przeanalizuj system z perspektywy atakującego. Zidentyfikuj punkty wejścia, wrażliwe zasoby, uprawnienia i skutki udanego naruszenia. Wytyczne NCSC dotyczące bezpiecznego projektowania zalecają modelowanie zagrożeń oraz zwracanie uwagi na komponenty stron trzecich i zasadę najmniejszych uprawnień. Wytyczne NCSC dotyczące bezpiecznego projektowania AI

Opisuj konkretne scenariusze. „Ryzyko AI” jest zbyt ogólne, by prowadzić do użytecznego działania. „Dokument przesłany przez podmiot zewnętrzny nakłania asystenta do zażądania pliku dowodowego o ograniczonym dostępie” daje zespołowi coś konkretnego do analizy.

Ustal priorytety według ekspozycji i potencjalnych szkód. Zapisz, kto akceptuje ryzyko szczątkowe i kiedy ta decyzja powinna zostać ponownie rozpatrzona.

Użyteczny rezultat: krótki rejestr ryzyk łączący scenariusze ataków z zasobami, skutkami, zabezpieczeniami i właścicielami.

4. Umieść zabezpieczenia na właściwych granicach

Dobierz zabezpieczenia do scenariusza, którym się zajmujesz. W przypadku zasobów modelu może to oznaczać chronione przechowywanie, ograniczenia dostępu i kontrole integralności. W przypadku wdrożonych usług rozważ uwierzytelnianie, rozdzielenie środowisk i zabezpieczenia ograniczające nieautoryzowany dostęp lub eksfiltrację. To tematy poruszane w wytycznych NCSC dotyczących wdrażania. Wytyczne NCSC dotyczące bezpiecznego wdrażania AI

W przypadku wygenerowanych wyników waliduj i koduj treść odpowiednio do jej miejsca docelowego, zanim inny system na jej podstawie zadziała. Wytyczne OWASP dotyczące obsługi wyników wyjaśniają, dlaczego wynik modelu nie powinien zyskiwać uprawnień tylko dlatego, że pochodzi z modelu. Wytyczne OWASP dotyczące obsługi wyników

Użyteczny rezultat: zapis zabezpieczenia wskazujący chronioną granicę, właściciela i dowody używane do jego sprawdzenia.

5. Przetestuj całą aplikację

Projektuj testy wokół skutków zidentyfikowanych w modelu zagrożeń. W przypadku asystenta RAG użyj dokumentów adwersarialnych i użytkowników o różnych uprawnieniach. W przypadku agenta sprawdź, co się dzieje, gdy pobrana treść prosi go o wyjście poza dozwolone działania.

Określ oczekiwany wynik przed uruchomieniem testu. Przykład: aplikacja musi odrzucić żądanie pliku o ograniczonym dostępie, nawet jeśli model spróbuje je wysłać.

Zapisz konfigurację aplikacji, wersję modelu, dane wejściowe testu, wynik i ewentualne działania naprawcze. Wybieraj dane testowe, które nie ujawniają niepotrzebnie rzeczywistych informacji poufnych.

Użyteczny rezultat: powtarzalne testy bezpieczeństwa powiązane z konkretnymi ryzykami i decyzjami o wydaniu.

6. Monitoruj zmiany i przygotuj reakcję

Oceniaj wpływ aktualizacji modeli, danych i promptów. Monitoruj istotne dane wejściowe i wyniki, chroniąc jednocześnie informacje wrażliwe w logach. Wytyczne operacyjne NCSC podkreślają monitorowanie zachowania oraz skutki zmian dla bezpieczeństwa w całym okresie eksploatacji. Wytyczne NCSC dotyczące bezpiecznej eksploatacji AI

Zdecyduj z wyprzedzeniem, kto może wyłączyć narzędzie, unieważnić poświadczenie, odizolować integrację lub wycofać wydanie. Ustal zdarzenia wyzwalające przegląd, takie jak nowy dostawca, rozszerzone uprawnienia, istotna aktualizacja modelu lub incydent bezpieczeństwa.

Użyteczny rezultat: odpowiedzialność za monitorowanie, kryteria przeglądu zmian, procedura reagowania na incydenty i przetestowana ścieżka odtworzenia.

Przekładanie ryzyk bezpieczeństwa AI na dowody

Poniższa tabela to proponowany szablon roboczy. Przykłady dowodów są praktycznymi zaleceniami, a nie listą dokumentów wymaganych przez ISO 27090.

Wyobraź sobie na przykład zespół bezpieczeństwa, który używa asystenta do streszczania dowodów od klientów. Dokument dostawcy zawiera instrukcje przesłania dowodów na zewnętrzny adres.

Test zespołu powinien prześledzić próbę działania przez całą aplikację. Czy asystent ma narzędzie, które potrafi przesyłać pliki? Czy to narzędzie egzekwuje uprawnienia użytkownika? Czy miejsca docelowe są ograniczone? Czy przesłanie wymaga zatwierdzenia przez osobę odpowiedzialną?

Użyteczny zapis przeglądu wskazywałby scenariusz, granicę, która uniemożliwia przesłanie, wynik testu oraz osobę, która zatwierdziła ryzyko szczątkowe. Jeśli system się zmieni, ten zapis pokaże kolejnemu recenzentowi, co trzeba sprawdzić ponownie.

Takie podejście nadaje ocenie więcej treści niż deklaracja, że system korzysta z „odpowiedzialnej AI”. Wiąże decyzję dotyczącą bezpieczeństwa z czymś, co inna osoba może sprawdzić. Więcej o organizowaniu materiałów uzupełniających przeczytasz w artykule jak uporządkować gotowość do audytu.

Certyfikacja i wymagania ISO 27090

ISO 27090 zawiera wytyczne dotyczące bezpieczeństwa, a nie wymagania certyfikacyjne dla systemu zarządzania. Objaśnienie ISO odróżnia jej cel od wymagań dotyczących AIMS zawartych w ISO 42001. Objaśnienie ISO 27090 przygotowane przez ISO

Najpierw określ, jakiego zapewnienia potrzebujesz: przeglądu bezpieczeństwa, odpowiedzi na potrzeby zapewnienia klienta, wewnętrznej analizy luk czy certyfikacji na zgodność z odpowiednią normą systemu zarządzania.

Poproś każdego, kto oferuje ocenę, o określenie jej zakresu, kryteriów i schematu zapewnienia. Ułatwia to interpretację wyniku i pozwala nie mylić przeglądu praktyk bezpieczeństwa AI z certyfikacją systemu zarządzania.

W projekcie wdrożeniowym zdobądź opublikowaną normę, odnieś wytyczne do własnych systemów i zapisz, dlaczego konkretne zabezpieczenia są właściwe. Przykłady z tego artykułu stanowią strukturę wyjściową dla tej pracy.

ISO 27090 a unijny akt w sprawie sztucznej inteligencji (AI Act)

Stosowanie normy międzynarodowej nie oznacza automatycznie zgodności z AI Act. Artykuł 40 wiąże domniemanie zgodności z normami zharmonizowanymi, do których odesłania opublikowano w Dzienniku Urzędowym UE, i to wyłącznie w zakresie, w jakim obejmują one odpowiednie wymogi lub obowiązki. Artykuł 40 AI Act

Traktuj przegląd bezpieczeństwa według ISO 27090 jako jeden z elementów wejściowych do odrębnie określonej oceny zgodności. Zapisz oceniany obowiązek prawny, dowody, które go potwierdzają, i ewentualną pozostałą lukę.

Najczęściej zadawane pytania o ISO 27090

Kiedy opublikowano ISO 27090?

Pierwsze wydanie, ISO/IEC 27090:2026, opublikowano 14 października 2026 r. Sprawdź aktualną kartę wydawcy, gdy starsze materiały odnoszą się do projektu lub wcześniejszego roku. Karta publikacji IEC

Czy ISO 27090 obejmuje generatywną AI i bezpieczeństwo LLM?

Jej opublikowana treść obejmuje prompt injection i wrażliwe wyniki modeli, co czyni ją istotną dla bezpieczeństwa generatywnej AI. Jej zakres obejmuje też inne systemy AI. Opublikowany fragment ISO/IEC 27090 Objaśnienie ISO 27090 przygotowane przez ISO

Czy firma korzystająca z AI stron trzecich może stosować tę normę?

Tak. Wskazani adresaci obejmują organizacje, które wykorzystują AI, a także organizacje, które ją rozwijają. Zacznij od ryzyk i obowiązków pozostających pod twoją kontrolą i ustal, co musisz wiedzieć o swoich dostawcach. Karta publikacji IEC

Czy certyfikat ISO 27001 oznacza, że system AI jest bezpieczny?

Certyfikacja systemu zarządzania nie gwarantuje, że pojedyncza aplikacja oprze się każdemu atakowi. Wykorzystaj system zarządzania do porządkowania decyzji dotyczących ryzyka i oceniaj rzeczywisty projekt, konfigurację i zachowanie systemu AI. ISO 27090 może pomóc ukierunkować tę pracę z zakresu bezpieczeństwa.

Gdzie można uzyskać ISO 27090 w formacie PDF?

Skorzystaj z oficjalnego katalogu ISO lub IEC Webstore, aby uzyskać opublikowaną normę i poznać opcje licencyjne. Sprawdź, czy oznaczenie brzmi ISO/IEC 27090:2026. Artykuł lub podgląd zawiera tylko część materiału.

Spraw, by prace nad bezpieczeństwem AI dało się sprawdzić

Zacznij od jednego przypadku użycia AI o istotnych skutkach. Ustal, jak mógłby zostać naruszony, dobierz zabezpieczenia dla właściwych granic i określ dowody, które wykażą, że te zabezpieczenia działają. Przypisz każdemu działaniu właściciela i zdarzenie wyzwalające przegląd.

Secani łączy wymagania, ryzyka, zabezpieczenia, dowody, właścicieli i decyzje z przeglądów we wspólnej przestrzeni roboczej dla bezpieczeństwa i compliance. Porozmawiaj z Secani o uporządkowaniu prac nad bezpieczeństwem AI, aby zespoły widziały, co zostało ocenione, co wymaga uwagi i kto za to odpowiada.