AI Security nie znosi próżni. Jeżeli w organizacji działają modele językowe, Copiloty, chatboty, systemy RAG albo pierwsi agenci AI, klasyczna Deklaracja Stosowania może pokazywać tylko część mapy ryzyka — a decyzje zapadają na podstawie tej części, którą widać. W tekście będziemy stosować zamiennie „Augmented -> Rozszerzona” deklaracja stosowania, albowiem w polskiej przestrzeni security termin „rozszerzona” praktycznie nie występuje, a „augmented” w rozwiązaniach międzynarodowych w zaawansowanych systemach to już norma. Jego potrzeba wynika ze stosowania w sytuacjach wdrażania wybranego frameworku – np. ISO/IEC 27001 bez integracji z wieloma standardami.
Znamy to z praktyki
AI weszła do firm szybciej, niż systemy zarządzania zdążyły ją opisać
W większości organizacji sztuczna inteligencja pojawiła się nie jako projekt, lecz jako fakt. Najpierw ktoś zaczął używać asystenta do pisania kodu, potem dział obsługi wdrożył chatbota, marketing sięgnął po generatywne narzędzia, a zespół produktowy podłączył model do wewnętrznej bazy wiedzy przez RAG. Zanim powstała jakakolwiek polityka, AI już przetwarzała dane i uczestniczyła w procesach.
Problem w tym, że system AI to nie jest „jeszcze jedna aplikacja”. Model, prompt systemowy, dane treningowe, embeddingi, baza wektorowa, pipeline MLOps, konfiguracja agenta i narzędzia, które agent może wywołać — to wszystko staje się albo nowym aktywem, albo nowym kanałem przetwarzania danych, albo nowym punktem, w którym można organizację skompromitować. A jeżeli SZBI tych elementów nie widzi w inwentarzu, ocenie ryzyka i Deklaracji Stosowania, to formalnie ich nie chroni.
To jest sedno luki: nie brak polityki, lecz brak widoczności technicznej powierzchni ataku w dokumentach, na których opiera się zarządzanie bezpieczeństwem.
ISO/IEC 27090 — ważny drogowskaz, nie lekarstwo
Dobra wiadomość jest taka, że normalizacja zaczyna nadążać. ISO/IEC 27090 porządkuje temat zagrożeń specyficznych dla systemów AI i przesuwa rozmowę z ogólnego „bezpieczeństwa informacji” na konkretne mechanizmy naruszeń: zatrucie danych i modelu, ataki uchylające (evasion), ekstrakcję i kradzież modelu, wnioskowanie o przynależności do zbioru treningowego (membership inference), prompt injection oraz ujawnianie danych przez output modelu.
Warto jednak od razu ustawić właściwe oczekiwania. Po pierwsze, w chwili pisania tego tekstu norma jest wciąż na etapie FDIS (Final Draft International Standard) — głosowanie nad projektem trwa, a publikacja spodziewana jest w drugiej połowie 2026 roku. Po drugie, i ważniejsze: ISO/IEC 27090 to dokument o charakterze wytycznych. Jest informacyjny, nie zawiera wymagań typu „shall” i nie jest normą certyfikowalną — nie da się „uzyskać certyfikatu ISO 27090” tak, jak uzyskuje się certyfikat ISO/IEC 27001 czy ISO/IEC 42001.
Wniosek dla praktyka jest prosty: 27090 to cenna taksonomia zagrożeń i inspiracja dla kontrolek, ale nie gotowa architektura bezpieczeństwa AI ani zamiennik dla SZBI. Dojrzałe podejście łączy kilka źródeł — ISO/IEC 27001 jako szkielet systemu, ISO/IEC 42001 jako ramę zarządzania AI, ISO/IEC 23894 jako podejście do ryzyka AI, CSA AI Controls Matrix jako najbliższy praktyce katalog kontrolny oraz OWASP Top 10 for LLM Applications, MITRE ATLAS i NIST AI RMF (wraz z NIST AI 100‑2) jako źródła scenariuszy technicznych i terminologii.
Dlaczego klasyczna SoA przestaje wystarczać
Deklaracja Stosowania jest jednym z filarów ISO/IEC 27001. Pokazuje, które zabezpieczenia z Annex A organizacja stosuje, dlaczego je stosuje i jak uzasadnia ewentualne wyłączenia. Kłopot zaczyna się w momencie, gdy AI traktuje się jako drobny dopisek do istniejących kontrolek — bo pozornie „mieści się” w tym, co już mamy.
Weźmy inwentarz aktywów. Formalnie system AI można w nim ująć. Ale czy ten wpis naprawdę obejmuje modele, datasety, prompty systemowe, embeddingi, mechanizmy RAG, agentów i zewnętrznych dostawców modeli? Albo logowanie i monitoring: kontrolka pokrywa aplikację, ale czy widzi prompt, output, wywołania narzędzi przez agenta, anomalie w zapytaniach i próby ekstrakcji modelu? W praktyce doklejanie coraz większej liczby ryzyk AI do klasycznego Annex A prowadzi do jednego skutku — Deklaracja przestaje być czytelna. Audytor nie wie już, gdzie kończy się wymaganie normy, a gdzie zaczyna interpretacja organizacji.
Augmented SoA — rozszerzenie bez deformowania Annex A
Dojrzalszą odpowiedzią jest Augmented SoA, czyli rozszerzona Deklaracja Stosowania. Nie chodzi w niej o przerabianie Annex A ani o sugerowanie, że ISO/IEC 27001 zawiera szczegółowe kontrolki AI. Annex A pozostaje szkieletem certyfikacyjnym w niezmienionej postaci. Obok niego powstaje osobna, wyraźnie oznaczona gałąź kontrolek AI Security, zmapowana do istniejących zabezpieczeń, do ryzyk i do dowodów.
Zaletą tego modelu jest przejrzystość — i to jest zaleta przede wszystkim audytowa. Audytor od razu widzi, co jest wymaganiem lub zabezpieczeniem z ISO/IEC 27001, a co świadomie dodanym profilem kontrolnym organizacji. Zarząd widzi, że ryzyka AI zostały nazwane i mają właścicieli. Zespół techniczny dostaje konkret: threat modelling dla systemów AI, red teaming, monitoring promptów, kontrolę outputów, ochronę przed ekstrakcją modelu, ograniczenie autonomii agentów.
ryzyko AI → kontrolka AISEC → powiązanie z Annex A → źródło inspiracji → dowód audytowy → status wdrożenia → luka → plan działań.
To nie jest kolejna tabela zgodności. To ścieżka, którą da się przejść w audycie od pojedynczego ryzyka aż do dowodu, że coś z nim zrobiono.
Profil AISEC — jak wyglądają kontrolki AI Security
AISEC nie jest oficjalnym załącznikiem do żadnej normy i nie udaje, że nim jest. To profil kontrolny — zestaw kontrolek, który organizacja buduje na bazie dostępnych standardów i dobrych praktyk, po to, by uszczelnić miejsca, w których klasyczny SZBI nie widzi specyfiki AI. Jego celem nie jest zastąpienie ISO/IEC 27001, lecz jego uzupełnienie.
Typowe obszary, które taki profil obejmuje, to m.in.: inwentarz systemów i aktywów AI, przypisanie właścicielstwa, ocena ryzyka AI Security, integralność i pochodzenie danych, ochrona przed zatruciem danych, ochrona modelu jako aktywa, ochrona przed ekstrakcją modelu, ochrona przed prompt injection, bezpieczne przetwarzanie outputów, logowanie i monitoring AI, obsługa incydentów AI‑specific oraz kontrola autonomii agentów.
Kilka przykładów pokazuje, jak konkretnie może to wyglądać:
Kluczowa zasada jest jedna: każda kontrolka musi mieć cel, właściciela, określoną stosowalność, powiązane ryzyko i dowód. Bez tego „AI Security” pozostaje hasłem na slajdzie. Z tymi elementami staje się mechanizmem, który da się zaudytować.
Od macierzy do działania — cztery kroki
Profil kontrolny ma wartość dopiero wtedy, gdy zostanie użyty. W praktyce sprowadza się to do czterech ruchów.
Krok pierwszy — inwentarz AI. Ustal, gdzie faktycznie używacie AI, jakie dane są przetwarzane, kto jest właścicielem danego przypadku użycia i jaki ma on charakter: pomocniczy, produkcyjny, krytyczny czy wysokiego wpływu. To bank, z którego czerpie cała reszta.
Krok drugi — ocena ryzyka AI. Ogólne „awaria systemu” i „wyciek danych” tu nie wystarczą. Trzeba nazwać scenariusze właściwe dla AI: zatrucie danych, prompt injection, nadmierną autonomię (excessive agency), inwersję modelu, membership inference, ekstrakcję modelu i kompromitację łańcucha dostaw AI.
Krok trzeci — dobór kontrolek AISEC i mapowanie do SoA. Nie zmieniasz treści Annex A. Pokazujesz, że klasyczne zabezpieczenia zostały uzupełnione o mechanizmy adekwatne do nowej technologii — i że wiesz, które są które.
Krok czwarty — właściciele, dowody, status, plan. Dopiero przypisanie odpowiedzialności, dowodów i planu działań zamienia macierz z tabeli zgodności w realne narzędzie zarządcze.
Tło regulacyjne: NIS2, DORA, AI Act
AI Security nie istnieje w regulacyjnej próżni. NIS2 zaostrza wymagania wobec zarządzania ryzykiem cyberbezpieczeństwa, DORA wymusza odporność cyfrową w sektorze finansowym, a AI Act porządkuje odpowiedzialność za systemy AI i ich ryzyka. Nie oznacza to, że każda organizacja musi wdrożyć identyczny katalog kontrolek. Oznacza natomiast coś innego: brak widoczności AI w SZBI będzie coraz trudniej obronić jako podejście dojrzałe — zarówno przed audytorem, jak i przed regulatorem.
Augmented SoA pomaga połączyć trzy języki, które zwykle mówią osobno: język norm, język ryzyka i język technologii. Pokazuje, że organizacja nie czeka biernie na kolejne wytyczne, tylko używa tego, co już dostępne, do zamykania realnych luk.
Podsumowanie
ISO/IEC 27090 to ważny sygnał — ale biznes nie powinien czekać na idealną normę, tym bardziej że norma ta ma charakter wytycznych, a nie wymagań do certyfikacji. Systemy AI już działają w organizacjach, a razem z nimi działają nowe wektory ataku i nowe zależności technologiczne.
Dlatego AI Security warto opisać jako osobną, przejrzystą i audytowalną warstwę Augmented SoA. Annex A ISO/IEC 27001 pozostaje szkieletem systemu, a profil AISEC pokazuje, jak organizacja rozumie i kontroluje ryzyka związane z modelami, danymi, promptami, outputami, dostawcami i agentami AI. Governance definiuje odpowiedzialność. Security dowodzi, że kontrola faktycznie działa.
Materiał do pobrania — AISEC Control Mapping Matrix
Do artykułu dołączamy krótką, publiczną zapowiedź narzędzia, a pełną wersję udostępniamy klientom i partnerom jako materiał ekspercki. Macierz zawiera 32 kontrolki AISEC z mapowaniem do ISO/IEC 27001, ISO/IEC 42001, CSA AI Controls Matrix, OWASP, MITRE ATLAS i NIST, wraz z pytaniami audytowymi i listą wymaganych dowodów. Na pewno się przyda.
Bibliografia:
- ISO/IEC. ISO/IEC FDIS 27090 — Cybersecurity — Artificial Intelligence — Addressing security threats and compromises to artificial intelligence systems. Etap FDIS; publikacja spodziewana w drugiej połowie 2026 r. ISO.org
- ISO/IEC. ISO/IEC 27001:2022 — Information security, cybersecurity and privacy protection — Information security management systems — Requirements. ISO.org
- ISO/IEC. ISO/IEC 42001:2023 — Information technology — Artificial intelligence — Management system. ISO.org
- ISO/IEC. ISO/IEC 23894:2023 — Information technology — Artificial intelligence — Guidance on risk management. ISO.org
- Cloud Security Alliance. AI Controls Matrix (AICM). CSA
- OWASP. Top 10 for Large Language Model Applications. OWASP
- MITRE. ATLAS — Adversarial Threat Landscape for Artificial-Intelligence Systems. MITRE ATLAS
- NIST. Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST
- NIST. NIST AI 100-2 E2025 — Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations. NIST CSRC
- Google Search Central. AI features and your website. Google Developers
Kontekst regulacyjny
FAQ: Rozszerzona SoA
Czym jest Augmented SoA?
To rozszerzona Deklaracja Stosowania, w której klasyczne kontrolki ISO/IEC 27001 pozostają bez zmian, a organizacja dodaje osobną gałąź zabezpieczeń dla nowych obszarów ryzyka — takich jak AI Security. Dzięki temu system pozostaje przejrzysty i audytowalny.
Czy ISO/IEC 27090 zastępuje ISO/IEC 27001?
Nie. ISO/IEC 27090 to wytyczne dotyczące zagrożeń specyficznych dla AI, w dodatku niecertyfikowalne. Nie zastępuje SZBI według ISO/IEC 27001. Najlepsze podejście łączy ISO/IEC 27001, ISO/IEC 42001 i praktyczne frameworki AI Security.
Dlaczego nie dopisywać AI wprost do kontrolek Annex A?
Punktowo można. Przy większej liczbie ryzyk AI prowadzi to jednak do utraty przejrzystości. Osobna gałąź AISEC jasno pokazuje, które zabezpieczenia są dodatkowymi kontrolkami organizacji, a które należą do klasycznego Annex A.
Jakie ryzyka powinny być objęte kontrolkami AISEC?
Minimum to: shadow AI, zatrucie danych, prompt injection, niebezpieczne przetwarzanie outputów, ujawnianie informacji wrażliwych, ekstrakcja modelu, kompromitacja łańcucha dostaw, dryf modelu oraz nadużycie autonomii agentów AI.
Czy macierz AISEC nadaje się do audytu?
Tak — jako narzędzie pomocnicze do samooceny, audytu wewnętrznego lub rozmowy z klientem. To nie jest oficjalny Annex A, lecz profil kontrolny, który da się zmapować do ryzyk, SoA i dowodów audytowych.
Ekspert w zakresie systemów zarządzania ISO, cyberbezpieczeństwa, compliance i AI governance. Audytor, konsultant, trener.