14 października 2026 r. ISO i IEC opublikowały ISO/IEC 27090:2026 – pierwszy międzynarodowy standard poświęcony obronie samych systemów AI przed atakami. Dla regulowanych przedsiębiorstw w UE to zmienia rozmowę o AI. Do tej pory CISO oceniający platformę GRC wspieraną przez AI musiał improwizować pytania due diligence. Teraz istnieje wspólny słownik zagrożeń. Zatruwanie danych, kompromitacja modelu, pośredni prompt injection czy integralność łańcucha dostaw zostały przypisane do etapów cyklu życia AI.
W BCMLogic przyjmujemy to z zadowoleniem. Naszymi klientami są banki, ubezpieczyciele, firmy inwestycyjne i operatorzy infrastruktury krytycznej. Dlatego BCMLogic Next od pierwszego dnia projektowaliśmy z myślą o audycie. Zakładaliśmy, że klienci będą sprawdzać nasze AI tak jak każdą inną usługę ICT w reżimie DORA.
W tym artykule pokazujemy, jak architektura bezpieczeństwa BCMLogic Next mapuje się na kategorie zagrożeń z ISO/IEC 27090. Wyjaśniamy też, co to oznacza dla Państwa due diligence.
Czym jest norma ISO/IEC 27090?
Pełny tytuł standardu to ISO/IEC 27090:2026 „Cybersecurity – Artificial intelligence (AI) – Addressing security threats and compromises to AI systems”. Opublikowano go 14 października 2026 r., po czterech latach prac w komitecie ISO/IEC JTC 1/SC 27. To ten sam komitet, który utrzymuje ISO/IEC 27001 i 27002. Dla praktyków istotne są trzy rzeczy:
- To wytyczne, a nie certyfikowalny system zarządzania. Nie ma „certyfikatu ISO 27090”. Wartością standardu jest ustrukturyzowany katalog zagrożeń i kontroli, wobec którego można audytować.
- Chroni system AI, a nie organizacyjne użycie AI w ogóle. ISO/IEC 42001 mówi, jak zarządzać AI jako organizacja; ISO/IEC 27090 – jak bronić systemu AI przed atakującym. Oba standardy są komplementarne i oba zakładają działający ISMS (ISO/IEC 27001/27002).
- Obejmuje pełny cykl życia AI – projektowanie, zbieranie danych, trening lub grounding, wdrożenie, eksploatację i aktualizacje modelu. Standard wprost zauważa, że dane operacyjne mogą stać się przyszłymi danymi treningowymi. Wtedy ryzyko zatrucia wykracza daleko poza fazę budowy.
ISO/IEC 27090 na tle ISO/IEC 27001 i ISO/IEC 42001
Dlaczego ISO/IEC 27090 ma znaczenie właśnie teraz?
Na polskim rynku jednym z pierwszych, którzy przybliżyli standard środowisku compliance, był dr Michał Nowakowski (analiza na LinkedIn). Jego kluczowa teza się broni: standard jest narzędziem due diligence w równym stopniu, co inżynierskim.
Dla podmiotów finansowych w UE standard pojawia się w dogodnym momencie. DORA obowiązuje od stycznia 2025 r. W Polsce od 3 kwietnia 2026 r. obowiązuje nowelizacja ustawy o Krajowym Systemie Cyberbezpieczeństwa (KSC) wdrażająca NIS2. AI Act stosuje się etapami. Obowiązki dla systemów wysokiego ryzyka – po zmianach z pakietu Digital Omnibus – zaczną obowiązywać od 2 grudnia 2027 r. ISO/IEC 27090 daje tym trzem reżimom wspólny techniczny kręgosłup dla pytania „czy wasze AI jest bezpieczne?”.
Model zagrożeń: co atakujący robi z AI w platformie GRC
ISO/IEC 27090 porządkuje zagrożenia specyficzne dla AI w kategorie, których klasyczne cyberbezpieczeństwo w pełni nie pokrywa. Przełożone na realia platformy GRC, która czyta Państwa dokumenty BIA, umowy z dostawcami i rejestry ryzyk, wyglądają tak:
- Zatruwanie danych – zmanipulowane wejścia zmieniają to, co AI „wie”. W GRC spreparowany dokument dostawcy albo naruszona baza wiedzy regulacyjnej może wypaczyć ocenę wg art. 28 DORA lub raport BIA.
- Pośredni prompt injection – instrukcje ukryte w przetwarzanym dokumencie (PDF dostawcy, raport z audytu) próbują przejąć zachowanie modelu. To najbardziej praktyczny wektor ataku w każdym workflow AI opartym na dokumentach.
- Kompromitacja i ekstrakcja modelu – kradzież lub manipulacja modelem albo jego wyjściami. Należą tu też ataki inferencyjne, które próbują odtworzyć poufne dane treningowe lub kontekstowe.
- Wyciek między klientami (tenantami) – standard nie nazywa tego wprost, ale to GRC-owa konsekwencja powyższych zagrożeń. Poufne plany ciągłości jednego klienta pojawiają się w odpowiedzi AI u innego. Dla platformy SaaS obsługującej konkurujące banki to ryzyko egzystencjalne.
- Zagrożenia łańcucha dostaw – kompromitacje „powyżej” dostawcy: model bazowy, dostawca embeddingów, biblioteki parsujące, usługi chmurowe, na których działa AI.
Kluczowa obserwacja: te zagrożenia powstają na konkretnych etapach cyklu życia i tam muszą być mitygowane. Zatrutej bazy wiedzy nie da się załatać na etapie odpowiedzi modelu.
Jak BCMLogic Next mapuje się na ISO/IEC 27090?
BCMLogic Next używa retrieval-augmented generation (RAG). AI opiera się na dwóch ściśle rozdzielonych źródłach kontekstu. Pierwszym są Państwa własne dokumenty, izolowane per klient. Drugim – współdzielona, wersjonowana baza wiedzy regulacyjnej (DORA, NIS2, ISO 22301, ISO 31000, wytyczne EBA i ENISA). Dodatkowo AI odpytuje na żywo Państwa ustrukturyzowane dane GRC, z kontrolą uprawnień.
Grounding zamiast treningu na danych klientów
Świadomie nie trenujemy ani nie fine-tunujemy modeli na danych klientów. Ta jedna decyzja architektoniczna eliminuje całą klasę zagrożeń, którym ISO/IEC 27090 poświęca sporą część objętości. Chodzi o zatruwanie danych treningowych i memoryzację modelu. W modelu nie ma danych klienta, które można zatruć albo wyekstrahować.
Gdzie powstaje zagrożenie i gdzie działa kontrola
Pozostałą powierzchnię ataku adresujemy warstwa po warstwie. Infografika pokazuje ścieżkę pojedynczego żądania AI w BCMLogic Next – od dokumentu do zatwierdzonego wyniku.
Mapowanie zagrożeń z ISO/IEC 27090 na kontrole w BCMLogic Next
Ograniczone, wykrywalne, przypisywalne
Komentarz ekspercki BCMLogic: ISO/IEC 27090 wymusza na każdym dostawcy uczciwe zastrzeżenie – żadna lista kontroli nie sprowadza ryzyka AI do zera. Architektura gwarantuje natomiast, że ewentualne awarie są ograniczone (jeden klient, jedno żądanie) i wykrywalne (cytowania, audit trail). Są też przypisywalne dzięki niezmiennym logom. I o to standardowi faktycznie chodzi – o proporcjonalne zabezpieczenia poparte dowodami, a nie marketingowe „bezpieczne AI”.
Bezpieczny cykl życia AI w praktyce
ISO/IEC 27090 obejmuje cały cykl życia AI, więc kontrole na papierze nie wystarczą. Trzeba je stosować na co dzień. Cztery praktyki niosą większość ciężaru w tym, jak budujemy i rozwijamy BCMLogic Next:
- Projektowanie: modelowanie zagrożeń przed funkcjami. Każda nowa zdolność AI, np. generator raportów czy asystent oceny dostawcy, przechodzi przegląd bezpieczeństwa. Przegląd z góry zadaje pytania z ISO/IEC 27090: jaki kontekst widzi funkcja, jakie narzędzia wywołuje, co się stanie przy wrogim wejściu. Zdolności są ograniczone do minimalnego zestawu narzędzi potrzebnych do zadania.
- Grounding, nie trening. Wiedza AI o DORA czy wytycznych EBA pochodzi z wersjonowanego korpusu, który kontrolujemy, z udokumentowanym kwartalnym cyklem aktualizacji. Gdy regulacja się zmienia, aktualizujemy korpus, a wersja jest widoczna – przeciwieństwo nieprzejrzystej aktualizacji modelu.
- Człowiek w pętli z założenia. Wynik pracy AI w BCMLogic Next to szkic z cytowaniami, nigdy autonomiczna decyzja. Raport BIA, scoring ryzyka dostawcy czy analiza root cause trafia najpierw do imiennie wskazanej, odpowiedzialnej osoby. Dopiero ona zatwierdza zapis w systemie. To jednocześnie mitygacja wg ISO/IEC 27090, oczekiwanie AI Act i po prostu dobre GRC.
- Monitoring i gotowość incydentowa. Wywołania AI są logowane z kosztem, latencją i atrybucją klienta; anomalne wzorce podlegają przeglądowi jak każda inna telemetria bezpieczeństwa. Ewentualny incydent związany z AI przeszedłby przez ten sam proces, który nasza platforma pomaga prowadzić klientom. Obejmuje to także dowody, o które zapytałby regulator.
Co to oznacza dla Państwa due diligence?
Jeśli są Państwo podmiotem finansowym objętym DORA, dostawcy wspierani przez AI są zewnętrznymi dostawcami usług ICT. ISO/IEC 27090 właśnie wręczył Państwu checklistę do oceny ryzyka dostawców. Pytania warte zadania każdemu dostawcy GRC z AI (łącznie z nami):
- Czy dane klienta są używane do treningu lub fine-tuningu modeli? Jeśli tak, jak mitygowane jest zatruwanie i memoryzacja?
- Jak izolacja klientów jest wymuszana konkretnie na warstwie AI – a nie tylko w bazie danych aplikacji?
- Czy model można zmanipulować treścią przetwarzanych dokumentów? Co się dzieje z wstrzykniętą instrukcją?
- Czy każde twierdzenie wygenerowane przez AI da się prześledzić do źródła? Czy każde działanie AI da się odtworzyć z logów?
- Gdzie działa inferencja, gdzie spoczywają dane i czy jedno i drugie można przenieść on-premise, jeśli wymaga tego regulator?
To pytania, które instytucje nadzorowane przez KNF już zaczęły zadawać w zapytaniach ofertowych. Mapują się niemal jeden do jednego na katalog zagrożeń ISO/IEC 27090. Dostawca, który nie potrafi odpowiedzieć na nie architekturą zamiast przymiotnikami, nie odrobił pracy domowej. Te same pytania warto zadawać także poza sektorem finansowym. Nowelizacja ustawy o KSC wymaga od podmiotów kluczowych i ważnych zarządzania ryzykiem łańcucha dostaw ICT.
FAQ
Czym jest norma ISO/IEC 27090?
To międzynarodowy standard opublikowany 14 października 2026 r. Zawiera wytyczne dotyczące rozpoznawania, wykrywania i mitygowania zagrożeń specyficznych dla systemów AI w całym ich cyklu życia. Chodzi m.in. o zatruwanie danych, kradzież i ekstrakcję modelu czy pośredni prompt injection.
Czy można uzyskać certyfikat ISO/IEC 27090?
Nie. ISO/IEC 27090 to wytyczne, a nie wymagania systemu zarządzania. Standard służy jako katalog zagrożeń i kontroli, wobec którego można ocenić system AI lub jego dostawcę. Certyfikowalnym systemem zarządzania AI jest ISO/IEC 42001.
Czym ISO/IEC 27090 różni się od ISO/IEC 42001?
ISO/IEC 42001 określa, jak organizacja ma zarządzać AI (governance, role, ocena wpływu). ISO/IEC 27090 opisuje, jak bronić samego systemu AI przed atakującym. Normy są komplementarne i obie zakładają działający ISMS zgodny z ISO/IEC 27001/27002.
Czy stosowanie ISO/IEC 27090 zapewnia zgodność z DORA, NIS2 lub AI Act?
Nie bezpośrednio – stosowanie wytycznych nie jest równoznaczne ze spełnieniem obowiązków prawnych. Standard daje jednak wspólny techniczny język do oceny bezpieczeństwa AI. Przydaje się przy ocenie dostawców ICT (art. 28 DORA), zarządzaniu ryzykiem łańcucha dostaw (ustawa o KSC) i wymogach cyberbezpieczeństwa AI Act.
Czy BCMLogic Next trenuje modele AI na danych klientów?
Nie. BCMLogic Next nie trenuje ani nie fine-tunuje modeli na danych klientów. AI korzysta z retrieval-augmented generation. Opiera się na dokumentach klienta i wersjonowanej bazie wiedzy regulacyjnej, a każda odpowiedź zawiera cytowania źródeł. Prompty i odpowiedzi nie są używane do treningu.
Czy AI w BCMLogic Next podejmuje decyzje samodzielnie?
Nie. Wynik pracy AI to szkic z cytowaniami, który zatwierdza imiennie wskazana, odpowiedzialna osoba. Każde działanie AI jest zapisywane w niezmiennym audit trail.
Podsumowanie
ISO/IEC 27090 nie czyni AI bezpiecznym – czyni bezpieczeństwo AI audytowalnym. To dokładnie ta zmiana, której potrzebowały regulowane przedsiębiorstwa: od ufania deklaracjom dostawcy do weryfikowania jego architektury. BCMLogic Next był budowany pod taki audyt, zanim standard powstał. Regulatorzy naszych klientów nigdy nie akceptowali „zaufajcie nam” jako kontroli.
Źródła: ISO/IEC 27090:2026 – katalog ISO; komunikat prasowy BSI o BS ISO/IEC 27090:2026; dr M. Nowakowski, „ISO 27090 – standard cyberbezpieczeństwa dla AI”, LinkedIn.
Pokażemy audit trail, nie slajd
Chętnie przejdziemy z Państwem przez architekturę bezpieczeństwa AI w BCMLogic Next. Możemy to zrobić pod kątem ISO/IEC 27090, art. 28 DORA albo Państwa kwestionariusza due diligence. BCMLogic Solutions wspiera firmy z sektora finansowego i technologicznego w zarządzaniu ryzykiem operacyjnym, ciągłością działania i zgodnością regulacyjną. Pracujemy zgodnie z ISO 22301, ISO 27001 oraz wymogami DORA i NIS2/KSC.
