W lutym zaproponowaliśmy sześć dodatkowych kontrolek dla generatywnej AI. Teraz mamy pierwszą międzynarodową normę o zagrożeniach dla systemów AI. Sprawdzamy, co z tamtego zestawu się broni, co dopisuje nowa norma i dlaczego własne zabezpieczenia pozostają właściwą drogą.
Osiem miesięcy temu napisaliśmy o dodatkowych kontrolkach dla generatywnej AI. Zaproponowaliśmy wtedy numerację A.9 i A.10. Wydawało się naturalne: Załącznik A ISO/IEC 27001 kończy się na A.8, więc idziemy dalej.
Stan wiedzy na 30.10.2026. Polskie tłumaczenie ISO/IEC 27090 (PN) nie jest jeszcze dostępne. Terminy angielskie podajemy jako podstawowe. Wpis z 21.02.2026 pozostaje bez zmian jako zapis ówczesnego stanu wiedzy, a ten tekst go rozwija.
W SKRÓCIE
• Sześć lutowych kontrolek dla GenAI ma oparcie w ISO/IEC 27090, a norma je doprecyzowuje
• ISO/IEC 27090 dopisuje zabezpieczenia dla agentów AI, pośredniego prompt injection i pochodzenia modeli
• Biznes nie czeka na normę: własne zabezpieczenia to droga, którą przewiduje ISO/IEC 27001
• Własne zabezpieczenia można uporządkować w dwie gałęzie, np. AI-U (używanie AI) i AI-R (rozwój AI)
• Każde własne zabezpieczenie w SoA potrzebuje źródła, ryzyka i miary skuteczności
WPROWADZENIE
Dodatkowe kontrolki AI w systemie zarządzania bezpieczeństwem informacji to własne zabezpieczenia organizacji, dobrane na podstawie szacowania ryzyka i wpisane do Deklaracji Stosowania obok Załącznika A ISO/IEC 27001. Od października 2026 r. mają mocniejszy punkt odniesienia: normę ISO/IEC 27090:2026. Norma opisuje zagrożenia specyficzne dla systemów AI oraz sposoby ich wykrywania i ograniczania w całym cyklu życia. W ocenie COE – Centre of Excellence (Centrum Certyfikacji QSCert) zestaw zbudowany w lutym dla generatywnej AI w modelu SaaS nadal się broni, bo każda z sześciu kontrolek ma oparcie w ISO/IEC 27090. Norma pozwala go rozwinąć o zabezpieczenia dla agentów AI, pośredniego prompt injection, pochodzenia modeli i walidacji skuteczności. Organizacjom, które łączą SZBI z systemem zarządzania AI według ISO/IEC 42001, proponujemy dwie gałęzie z prefiksami AI-U dla używania AI i AI-R dla rozwoju AI, z polem źródła i terminem walidacji w Deklaracji Stosowania.
Ten tekst jest drugim wpisem cyklu o ISO/IEC 27090. W pierwszym opisaliśmy samą normę: jej strukturę, mapę zagrożeń i to, dlaczego zabezpieczenia AI tracą skuteczność w czasie. Teraz wracamy do własnej propozycji z lutego i sprawdzamy ją tak, jak sprawdzalibyśmy ją na audycie.
CO ZAPROPONOWALIŚMY W LUTYM I Z JAKIEJ PERSPEKTYWY
Wpis z 21.02.2026 nie był tekstem wyłącznie o AI. Jego intencją była otwartość SZBI na każdą technologię, która wpływa na bezpieczeństwo informacji w biznesie. ISO/IEC 27001 jest celowo neutralna technologicznie i tę otwartość wprost przewiduje. Klauzula 6.1.3 b) każe określić wszystkie zabezpieczenia niezbędne do postępowania z ryzykiem, a nota do niej dopuszcza zabezpieczenia projektowane przez organizację albo zaczerpnięte z dowolnego źródła. Punkt c) każe porównać je z Załącznikiem A, a nota do niego zaznacza, że lista z Załącznika A nie jest wyczerpująca. Punkt d) domyka całość Deklaracją Stosowania. Generatywna AI była pierwszą gałęzią, obok blockchaina, IoT i OT, przetwarzania brzegowego, sieci 5G oraz DevSecOps. Dla niej zaproponowaliśmy sześć zabezpieczeń:
- A.9.1 Polityka korzystania z generatywnej AI
- A.9.2 Ograniczanie danych wejściowych do systemów GenAI
- A.9.3 Zarządzanie dostępem do usług GenAI
- A.9.4 Logowanie i monitoring użycia GenAI
- A.9.5 Bezpieczeństwo w relacjach z dostawcami GenAI
- A.9.6 Weryfikacja wyników GenAI przed użyciem operacyjnym
W gałęzi AI ważna jest perspektywa: był to zestaw dla użytkownika AI, czyli organizacji, która kupuje dostęp do modelu jako usługę. ISO/IEC 27090 patrzy szerzej. Według klauzuli 1 obejmuje zarówno organizacje, które AI używają, jak i te, które ją rozwijają, a w praktyce coraz częściej obie role występują naraz. Firma, która podłącza model do własnych dokumentów przez RAG albo uruchamia agenta z dostępem do poczty, przestaje być tylko klientem usługi SaaS.
CO ZOSTAJE: SZEŚĆ KONTROLEK W ŚWIETLE ISO/IEC 27090
Każda z sześciu lutowych kontrolek ma oparcie w ISO/IEC 27090, a norma w każdym przypadku coś doprecyzowuje. Poniższe przypisanie to nasza interpretacja. Norma nie zna naszych identyfikatorów i nie odnosi się do lutowego wpisu.
| Kontrolka z lutego | Oparcie w ISO/IEC 27090 | Co norma dopisuje |
|---|---|---|
| A.9.1Polityka GenAI | 5.2 program nadzoru nad AI | Inwentarz systemów AI jako podstawa polityki |
| A.9.2Dane wejściowe | 6.11.2 ograniczanie danych, B.7 wyciek danych wejściowych | Repozytorium RAG chronione jak dane treningowe (7.6) |
| A.9.3Dostęp do usług | 5.3 zero trust | Osobna autoryzacja każdego zapytania o dokument w RAG |
| A.9.4Logowanie | 7.5 logowanie i monitorowanie | Zalecany zakres: wejście, data, czas, użytkownik, wynik, wersja modelu |
| A.9.5Dostawcy | 5.5 łańcuch dostaw, B.3.3 | Weryfikacja pochodzenia modeli, karty modeli, red teaming dostarczonych modeli |
| A.9.6Weryfikacja wyników | 6.11.3.2 nadzór, 6.10 injection w wyniku | Nadmierne zaufanie, zjawisko out-of-the-loop, wynik traktowany jako niezaufany |
Przypisanie kontrolek do klauzul to interpretacja COE. ISO/IEC 27090 nie odnosi się do identyfikatorów z wpisu z 21.02.2026.
Z praktyki audytowej najcenniejsze jest uzupełnienie A.9.4. Lutowa kontrolka kazała rejestrować, kto, kiedy, z jakiego konta i w jakim celu korzystał z narzędzia. ISO/IEC 27090 w podklauzuli 7.5 dodaje do zalecanego zakresu wynik i wersję modelu. Bez wersji modelu nie da się po fakcie ustalić, dlaczego system dał inną odpowiedź w marcu, a inną w czerwcu. A to pytanie pada przy każdym poważniejszym incydencie.
Drugie istotne uzupełnienie dotyczy A.9.6. W lutym pisaliśmy o zasadzie human-in-the-loop dla decyzji o istotnych skutkach. ISO/IEC 27090 w 6.11.3.2 zwraca uwagę, że sam udział człowieka nie wystarcza. Operator, który stale wybiera między „zatwierdź” i „odrzuć”, z czasem przestaje rozumieć, co zatwierdza. Kontrolka powinna więc określać nie tylko, że człowiek weryfikuje, ale też jak utrzymuje rzeczywiste zaangażowanie.
CO DOPISUJE ISO/IEC 27090
Lutowy zestaw świadomie dotyczył użytkownika generatywnej AI w modelu SaaS. ISO/IEC 27090 opisuje sześć obszarów, które wykraczały poza ten zakres, a stają się istotne, gdy organizacja przestaje być wyłącznie klientem usługi.
Agenci AI (6.11.3.3, 5.3). Agent, który wysyła e-maile, wywołuje API albo zmienia rekordy, potrzebuje innego modelu uprawnień niż człowiek. Norma zaleca uprawnienia przypisane do zadania, ograniczone w czasie i wydzielone tożsamościowo. Agent działa na własnym koncie usługowym, a nie dziedziczy wszystkich uprawnień użytkownika. Gdy organizacja uruchamia agentów, to zabezpieczenie powinno trafić do SoA jako pierwsze.
Pośredni prompt injection (6.9). Lutowa kontrolka danych wejściowych dotyczyła tego, co użytkownik wpisuje do modelu. Przy RAG i agentach dochodzi to, co model czyta z innych źródeł. Złośliwe polecenia mogą trafić do modelu ze strony internetowej albo dokumentu dołączanego do kontekstu. Norma zaleca weryfikowanie takich źródeł i wyraźne oddzielanie niezaufanej treści w prompcie.
Injection w wyniku modelu (6.10). Odpowiedź modelu wyświetlana w aplikacji może zawierać klasyczny atak, np. cross-site scripting. Zalecenie normy jest proste: traktować wynik jako niezaufany i stosować standardową walidację oraz kodowanie wyjścia.
Pochodzenie danych i modeli (5.5, 6.11.4). Gdy organizacja dostraja model albo pobiera gotowy model z repozytorium, potrzebuje rejestru pochodzenia, chronionego kryptograficznie i dostępnego dla audytu wewnętrznego. To odpowiedź na zagrożenia typowe dla organizacji, które same pracują z modelami: trojany w gotowych modelach i celowe fałszowanie pochodzenia.
Testy adwersaryjne i red teaming (5.6, 5.7). Norma dodaje do zabezpieczeń sprawdzian: czy działają wobec realnego przeciwnika, a nie tylko na papierze.
Walidacja skuteczności zabezpieczeń (7.2–7.4). To najważniejsza nowość. ISO/IEC 27090 wskazuje, że zabezpieczenia AI mogą się wzajemnie osłabiać i tracą skuteczność w czasie. Zestaw kontrolek bez mechanizmu okresowej walidacji z czasem staje się zestawem deklaracji.
WŁASNE ZABEZPIECZENIA: BIZNES NIE CZEKA NA NORMĘ
W lutym 2026 r. nie było jeszcze międzynarodowej normy o zagrożeniach dla systemów AI. Organizacje korzystały już jednak z generatywnej AI na co dzień, a szacowanie ryzyka nie mogło udawać, że tych narzędzi nie ma. Dlatego zaproponowaliśmy własną gałąź zabezpieczeń. Rozwinęliśmy w niej podejście znane z praktyki anglosaskiej i dopasowaliśmy je do ISO/IEC 27001: oznaczenia A.9 (Emerging Technology Controls) i A.10 (Advanced Infrastructure Controls) jako przedłużenie Załącznika A, który kończy się na A.8.
ISO/IEC 27090 potwierdza, że to była właściwa droga. Norma jest wytyczną. Opisuje zagrożenia i środki zaradcze, ale nie daje gotowego katalogu zabezpieczeń z numerami do przepisania do Deklaracji Stosowania. Nadal więc to organizacja, zgodnie z kl. 6.1.3 b)–d) ISO/IEC 27001, określa własne zabezpieczenia, porównuje je z Załącznikiem A i ujmuje w Deklaracji Stosowania.
Nie dotyczy to tylko ISO/IEC 27001. Także Załącznik A ISO/IEC 42001 nie wyczerpuje wszystkich zabezpieczeń dla systemów AI we wszystkich aspektach. Dlatego Cloud Security Alliance opracowała AI Controls Matrix, katalog 247 celów kontrolnych mapowany m.in. na ISO/IEC 42001. Normy dają ramę, a praktyka dopisuje do niej szczegóły.
Stanowisko autora: tak będzie także przy kolejnych technologiach. Blockchain, IoT, przetwarzanie brzegowe czy kryptografia postkwantowa wejdą do zakresu SZBI szybciej, niż pojawią się dla nich normy. Brak rozwiązania normowego nie usprawiedliwia bezczynności. Czekanie na normę dla każdej technologii oznaczałoby SZBI zawsze o krok za biznesem.
Jedna rzecz wymaga dopasowania w organizacjach, które łączą SZBI z systemem zarządzania AI według ISO/IEC 42001. Załącznik A tej normy ma własne sekcje A.9 „Use of AI systems” (A.9.2–A.9.4) oraz A.10 „Third-party and customer relationships” (A.10.2–A.10.4). W samodzielnym SZBI lutowe oznaczenia działają bez przeszkód. W zintegrowanej Deklaracji Stosowania ten sam numer wskazywałby jednak na dwa różne zabezpieczenia. Dla takich organizacji proponujemy prefiks opisowy, który od razu mówi, że chodzi o zabezpieczenie organizacji, a nie normy:
- AI-U-nn: zabezpieczenia dla używania AI (użytkownik, także SaaS),
- AI-R-nn: zabezpieczenia dla rozwoju i wdrażania AI (dostrajanie, RAG, własne modele, agenci w produkcji).
Ten sam schemat łatwo rozszerzyć na kolejne technologie z lutowego wpisu, bez czekania na normy: IOT-nn, BC-nn (blockchain), EDGE-nn, NET-nn (5G i sieci prywatne), DEV-nn (DevSecOps i kontenery).
ZAKTUALIZOWANY ZESTAW: DWIE GAŁĘZIE
Poniższy zestaw to propozycja autora, zbudowana na ISO/IEC 27090. Nie jest katalogiem do przepisania. Każda organizacja dobiera z niego to, co wynika z jej szacowania ryzyka, zgodnie z logiką ISO/IEC 27001, kl. 6.1.3. Identyfikatory AI-U i AI-R zastosowano dla czytelności. W samodzielnym SZBI nowe pozycje można dopisać w dotychczasowej numeracji, np. lutowe A.9.1–A.9.6 uzupełnić o A.9.7 i A.9.8.
| ID | Zabezpieczenie | Źródło w ISO/IEC 27090 | Powiązania |
|---|---|---|---|
| AI-U-01 | Polityka korzystania z AI, oparta na inwentarzu systemów AI | 5.2 | ISO/IEC 27001: A.5.1 ISO/IEC 42001: A.2.2 |
| AI-U-02 | Ograniczanie danych wejściowych, w tym ochrona repozytoriów RAG | 6.11.2 7.6 | ISO/IEC 27001: A.5.12, A.8.11 |
| AI-U-03 | Dostęp do usług AI według zero trust | 5.3 | ISO/IEC 27001: A.5.15–A.5.18 |
| AI-U-04 | Logowanie użycia z wersją modelu i wynikiem | 7.5 | ISO/IEC 27001: A.8.15, A.8.16 ISO/IEC 42001: A.6.2.8 |
| AI-U-05 | Wymagania wobec dostawców AI, w tym karty modeli | 5.5 B.3.3 | ISO/IEC 27001: A.5.19–A.5.23 ISO/IEC 42001: A.10.3 |
| AI-U-06 | Weryfikacja wyników i przeciwdziałanie nadmiernemu zaufaniu | 6.11.3.2 6.10 | ISO/IEC 42001: A.9.4 |
| AI-U-07 | noweNajmniejsze uprawnienia dla agentów AI | 6.11.3.3 | ISO/IEC 27001: A.8.2, A.5.15 |
| AI-U-08 | noweOdporność na prompt injection, także pośredni | 6.9 | ISO/IEC 27001: A.8.26, A.8.28 |
Propozycja COE zbudowana na ISO/IEC 27090:2026, nie katalog do przepisania. Zabezpieczenia dobiera się na podstawie szacowania ryzyka (ISO/IEC 27001, kl. 6.1.3). Identyfikatory AI-U i AI-R zastosowano dla czytelności. W samodzielnym SZBI nowe pozycje można dopisać w dotychczasowej numeracji organizacji.
| ID | Zabezpieczenie | Źródło w ISO/IEC 27090 | Powiązania |
|---|---|---|---|
| AI-R-01 | Rejestr pochodzenia danych i modeli | 5.5 6.11.4 | ISO/IEC 42001: A.7.5 ISO/IEC 27001: A.5.21 |
| AI-R-02 | Ochrona środowiska deweloperskiego | 7.6 | ISO/IEC 27001: A.8.31, A.8.3 |
| AI-R-03 | Integralność danych treningowych i sekwencji trenowania | 6.2 | ISO/IEC 42001: A.7.4 |
| AI-R-04 | Ochrona modelu przed eksfiltracją (ograniczanie zapytań, ukrywanie prawdopodobieństw) | 6.5 7.8 | ISO/IEC 27001: A.8.6 |
| AI-R-05 | Testy adwersaryjne i red teaming | 5.6 5.7 | ISO/IEC 27001: A.8.29 |
| AI-R-06 | Walidacja skuteczności zabezpieczeń AI przed każdym ponownym wdrożeniem | 7.2–7.4 | ISO/IEC 27001: kl. 9.1 ISO/IEC 42001: A.6.2.4 |
Propozycja COE zbudowana na ISO/IEC 27090:2026, nie katalog do przepisania. Zabezpieczenia dobiera się na podstawie szacowania ryzyka (ISO/IEC 27001, kl. 6.1.3). Identyfikatory AI-U i AI-R zastosowano dla czytelności. W samodzielnym SZBI nowe pozycje można dopisać w dotychczasowej numeracji organizacji.
W organizacji z certyfikowanym systemem zarządzania AI część gałęzi AI-U pokrywa się z zabezpieczeniami ISO/IEC 42001. Wtedy w SoA warto wskazać zabezpieczenie z 42001 jako wiodące, zamiast dublować je własnym. Dotyczy to zwłaszcza polityki, dostawców i zamierzonego zastosowania.
JAK TO UJĄĆ W DEKLARACJI STOSOWANIA
Własne zabezpieczenie broni się na audycie wtedy, gdy wynika z ryzyka, ma właściciela i zostawia ślad działania. ISO/IEC 27090 dodaje do tego czwarty element: dowód, że zabezpieczenie nadal działa.
Z praktyki audytowej proponujemy, by każdy wiersz własnego zabezpieczenia w SoA miał sześć pól:
- Identyfikator w przyjętej konwencji organizacji (np. AI-U i AI-R albo dotychczasowa numeracja), spójny w całej SoA.
- Źródło, np. „ISO/IEC 27090:2026, 6.11.3.3”. To pokazuje audytorowi, że zabezpieczenie nie jest wymysłem, tylko odpowiedzią na opisane zagrożenie.
- Powiązane ryzyko z rejestru.
- Powiązanie z Załącznikiem A ISO/IEC 27001 (i ISO/IEC 42001, jeśli system jest zintegrowany).
- Status i uzasadnienie stosowania albo wyłączenia.
- Miara skuteczności i termin walidacji. To pole najczęściej pomijamy, a ISO/IEC 27090 w klauzuli 7 daje najmocniejszy argument, by je wypełniać.
Dla podmiotów objętych znowelizowaną ustawą o krajowym systemie cyberbezpieczeństwa ma to wymiar praktyczny. Narzędzia AI objęte zakresem SZBI wchodzą do tego samego szacowania ryzyka, które ustawa wymaga od podmiotów kluczowych i ważnych. Szerzej pisaliśmy o tym przy zarządzaniu podatnościami w erze AI.
Organizacje, które wdrożyły lutową propozycję w samodzielnym SZBI, nie muszą zmieniać numeracji. Te, które łączą SZBI z ISO/IEC 42001, mogą przejść na prefiksy AI-U i AI-R przy najbliższym przeglądzie dokumentacji. Wystarczy tabela przejścia w SoA (dotychczasowy numer, nowy numer, data zmiany).
Podsumowanie
Lutowy zestaw sześciu kontrolek dla generatywnej AI powstał, zanim pojawiła się norma, i ISO/IEC 27090 potwierdza jego kierunek. Organizacja, która podłącza model do własnych danych albo uruchamia agentów, znajdzie w normie źródło kolejnych zabezpieczeń: dla agentów, przeciw pośredniemu prompt injection, dla pochodzenia modeli i dla walidacji skuteczności. A przy następnych technologiach zasada pozostanie ta sama: biznes nie czeka na normę, tylko buduje własne zabezpieczenia na podstawie ryzyka.
Jeśli Twoja organizacja ma lub buduje SZBI zgodny z ISO/IEC 27001 albo system zarządzania AI zgodny z ISO/IEC 42001, zacznij od przejrzenia swojej Deklaracji Stosowania pod kątem trzech pytań: czy obejmuje agentów, czy w systemie zintegrowanym z ISO/IEC 42001 numeracja własnych zabezpieczeń jest jednoznaczna i czy każde zabezpieczenie AI ma termin walidacji.
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 42001:2023. Information technology — Artificial intelligence — Management system, Załącznik A. ISO.org
- ISO/IEC 27002:2022. Information security, cybersecurity and privacy protection — Information security controls. ISO.org
- Cloud Security Alliance. AI Controls Matrix v1.1, 22.06.2026. cloudsecurityalliance.org
FAQ: Kontrolki AI w SZBI po ISO/IEC 27090: co zostaje, co dopisać
Tak. Klauzula 6.1.3 ISO/IEC 27001 pozwala dobierać zabezpieczenia z dowolnego źródła i zaznacza, że lista z Załącznika A nie jest wyczerpująca. Własne zabezpieczenia dla AI trafiają do Deklaracji Stosowania z uzasadnieniem i powiązaniem z ryzykiem. ISO/IEC 27090 jest dobrym źródłem takich zabezpieczeń.
W samodzielnym SZBI wystarczy spójny, własny schemat numeracji. W systemie zintegrowanym z ISO/IEC 42001 lepiej użyć prefiksu opisowego, np. AI-U-01 dla używania AI i AI-R-01 dla rozwoju AI, bo Załącznik A ISO/IEC 42001 ma własne sekcje A.9 i A.10.
Podstawą jest polityka korzystania z AI, ograniczenie danych wprowadzanych do narzędzi, zarządzanie dostępem, logowanie użycia, wymagania wobec dostawcy i weryfikacja wyników. Jeśli narzędzie ma dostęp do dokumentów firmy albo działa jako agent, dochodzą zabezpieczenia przed pośrednim prompt injection i najmniejsze uprawnienia dla agenta.
Częściowo nie. ISO/IEC 42001 obejmuje m.in. politykę AI, dostawców i zamierzone zastosowanie systemów AI. W zintegrowanej Deklaracji Stosowania warto wskazać zabezpieczenie z ISO/IEC 42001 jako wiodące, a własne dodawać tylko tam, gdzie zostaje luka, np. dla uprawnień agentów czy prompt injection.
Każde zabezpieczenie powinno mieć właściciela, powiązane ryzyko, ślad działania (logi, przeglądy, decyzje) oraz miarę skuteczności z terminem walidacji. ISO/IEC 27090 wskazuje, że zabezpieczenia AI tracą skuteczność w czasie, więc okresowa walidacja jest ważniejsza niż przy klasycznych zabezpieczeniach.
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.