ISO 27090 vysvětlená pro týmy bezpečnosti AI

ISO/IEC 27090:2026 je mezinárodní norma, která poskytuje pokyny k bezpečnostním hrozbám a kompromitacím, jež postihují systémy umělé inteligence. Byla zveřejněna 14. října 2026 a zabývá se tím, jak mohou organizace tyto hrozby chápat, odhalovat a zmírňovat v průběhu celého životního cyklu AI. Její formální název zní Cybersecurity — Artificial intelligence (AI) — Addressing security threats and compromises to AI systems. Záznam o publikaci ISO

Pro bezpečnostní tým je praktická otázka jednoduchá: co by útočník mohl změnit, ukrást nebo k čemu by mohl systém AI přimět, a co by omezilo výslednou škodu?

Tento průvodce vysvětluje rozsah normy ISO 27090, hlavní bezpečnostní hrozby pro AI, její vztah k ISO 27001 a ISO 42001 a praktický způsob, jak pokyny proměnit v bezpečnostní práci s vlastníky, ochrannými opatřeními a důkazy. Podkladový výzkum byl ověřen 18. října 2026.

Co norma ISO 27090 pokrývá

ISO 27090 se zaměřuje na ochranu systémů AI. Její předmět přesahuje generativní AI, velké jazykové modely a chatboty a týká se systémů AI v širším smyslu. Vysvětlení ISO 27090 od ISO

Zveřejněná norma propojuje zavedené postupy bezpečnosti informací s hrozbami specifickými pro AI. Její obsah se zabývá správou, bezpečností dodavatelského řetězce, modelováním hrozeb a red teamingem a dále typy kompromitací včetně otravy, únikových útoků, vyzrazení informací a prompt injection. Zohledňuje také, jak se zmírňující opatření vzájemně ovlivňují a jak si v čase zachovávají účinnost. Zveřejněná ukázka ISO/IEC 27090

Rozsah zahrnuje organizace všech velikostí, které AI vyvíjejí nebo používají, včetně podniků, orgánů veřejné správy a neziskových organizací. Nákup služby AI od třetí strany proto organizaci z cílové skupiny nevyřazuje. Záznam o publikaci IEC

Užitečným výchozím bodem je společné přezkoumání, do něhož se zapojí bezpečnost, vývoj, datový tým, nákup a vlastník na straně byznysu. Každý z nich by měl umět vysvětlit část systému, kterou řídí, a rozhodnutí, u nichž závisí na ostatních.

Proč systémy AI potřebují dodatečnou bezpečnostní analýzu

Aplikace AI propojuje několik prvků, které si zaslouží samostatné posouzení: software, data, soubory nebo služby modelů, instrukce, uživatele a navazující akce.

Představte si asistenta pro práci s dokumenty napojeného na interní znalostní bázi. Konvenční přezkoumání může prověřit autentizaci, šifrování a zranitelnosti softwaru. Přezkoumání bezpečnosti AI by se mělo ptát také na to, co se stane, když se načtený dokument pokusí změnit instrukce asistenta, zda uživatelé mohou získat materiály mimo svá oprávnění a které akce může vygenerovaný výstup spustit.

Tyto otázky nabývají na významu, když asistent může aktualizovat záznamy nebo volat externí nástroje. Chybná odpověď a neoprávněná akce mají různé důsledky a vyžadují různá ochranná opatření.

Při prvním přezkoumání zmapujte tři otázky:

• Co může systém ovlivnit? Zahrňte trénovací data, načtený obsah, prompty, dodavatele a aktualizace modelů.
• Co může systém opustit? Zahrňte odpovědi, logy, exporty a aktiva modelů.
• Co může systém změnit? Zahrňte soubory, tikety, účty, transakce a další připojené služby.

Jde o praktickou metodu vymezení rozsahu pro níže uvedené příklady, nikoli o reprodukci článků normy.

Bezpečnostní hrozby pro AI, kterým je třeba rozumět

Následující vysvětlení vycházejí z terminologie NIST pro adversariální strojové učení a z pokynů OWASP pro aplikace LLM. Scénáře jsou ilustrativní. Taxonomie adversariálního strojového učení od NIST Pokyny OWASP k prompt injection Pokyny OWASP ke zpracování výstupů

Při posuzování rizik tato rozlišení držte jasně oddělená. Škodlivý dokument načtený aplikací využívající generování rozšířené o vyhledávání (RAG) není automaticky otravou trénovacích dat: samotné vyhledávání váhy modelu neaktualizuje. Může však aplikaci vystavit nepřímé prompt injection.

U bezpečnosti LLM jsou samotné silnější prompty neúplnou strategií kontrol. OWASP doporučuje ochranná opatření, jako jsou omezená oprávnění a schvalování citlivých akcí, zatímco NCSC zdůrazňuje řízení prompt injection jako trvalého rizika prostřednictvím návrhu a provozu systému. Pokyny OWASP k prompt injection Pokyny NCSC k riziku prompt injection

ISO 27090 vs. ISO 27001 a ISO 42001

Tyto normy podporují různé části práce organizace v oblasti bezpečnosti a správy AI.

Tato rozlišení vycházejí z popisů vydavatelů pro ISO 27001, ISO 27002 a ISO 42001.

Pro tým, který již provozuje ISMS, je praktickým přístupem rozšířit stávající záznamy. Doplňte relevantní systémy AI do inventáře aktiv, posuďte jejich cesty útoku, určete vlastníky ošetření rizik a připojte podpůrné důkazy. Podrobnosti k organizaci této práce najdete v kontrolním seznamu pro implementaci ISO 27001.

Praktický kontrolní seznam pro implementaci ISO 27090

Níže uvedené kroky představují implementační přístup vycházející z předmětu normy a z veřejných pokynů k bezpečné AI. Nejde o oficiální kontrolní seznam ISO ani o výčet povinných článků.

1. Definujte systém a jeho vlastníka

Vyberte případ užití AI s jasným obchodním účelem. Zaznamenejte odpovědného vlastníka, uživatele, poskytovatele modelu, způsob hostování a připojené služby.

Poté vymezte hranice přezkoumání. Zahrňte aplikaci a její závislosti, nejen endpoint modelu. Asistent pro zákazníky s přístupem k nástrojům vyžaduje jiné posouzení než interní nástroj pro sumarizaci textu bez oprávnění cokoli provádět.

Užitečný výstup: záznam o systému, který uvádí jeho účel, hranice, závislosti, povolené akce a odpovědného vlastníka.

2. Sledujte původ dat a modelů

Zaznamenejte, odkud pocházejí datové sady a artefakty modelů, kdo je může měnit a které verze jsou nasazeny. Zahrňte vstupy pro doladění, kolekce pro vyhledávání, prompty a kanály zpětné vazby, které jsou pro systém relevantní.

Pokyny NCSC pro vývoj doporučují sledovat aktiva AI a jejich původ, chránit je a uchovávat informace potřebné k obnovení důvěryhodných verzí. Pokyny NCSC k bezpečnému vývoji AI

U zakoupeného modelu se poskytovatele zeptejte, které odpovědnosti přebírá a jaké informace zpřístupňuje při změnách modelů nebo služeb.

Užitečný výstup: verzovaný inventář se zdroji, pravidly přístupu, historií změn a odpovědnostmi dodavatelů.

3. Modelujte hrozby skutečného pracovního postupu

Přezkoumejte systém z pohledu útočníka. Identifikujte vstupní body, citlivá aktiva, oprávnění a důsledky úspěšné kompromitace. Pokyny NCSC pro bezpečný návrh doporučují modelování hrozeb a pozornost věnovanou komponentám třetích stran a principu nejnižších oprávnění. Pokyny NCSC k bezpečnému návrhu AI

Pište konkrétní scénáře. „Riziko AI“ je příliš obecné na to, aby vedlo k užitečné akci. „Dokument nahraný externí stranou přiměje asistenta vyžádat si soubor s omezeným přístupem obsahující důkazy“ dává týmu něco konkrétního k analýze.

Stanovte priority podle expozice a potenciální škody. Zaznamenejte, kdo přijímá zbytkové riziko a kdy by se toto rozhodnutí mělo znovu přezkoumat.

Užitečný výstup: stručný registr rizik, který propojuje scénáře útoků s aktivy, důsledky, ochrannými opatřeními a vlastníky.

4. Umístěte ochranná opatření na relevantní hranice

Vyberte opatření pro scénář, kterým se zabýváte. U aktiv modelů to může zahrnovat chráněné úložiště, omezení přístupu a kontroly integrity. U nasazených služeb zvažte autentizaci, oddělení prostředí a opatření, která snižují neoprávněný přístup nebo exfiltraci. Tato témata obsahují pokyny NCSC pro nasazení. Pokyny NCSC k bezpečnému nasazení AI

U vygenerovaných výstupů validujte a kódujte obsah pro jeho cílové místo dříve, než na jeho základě začne jednat jiný systém. Pokyny OWASP ke zpracování výstupů vysvětlují, proč by výstup modelu neměl získávat autoritu jen proto, že pochází z modelu. Pokyny OWASP ke zpracování výstupů

Užitečný výstup: záznam o opatření, který uvádí hranici, kterou chrání, jeho vlastníka a důkazy používané k jeho ověření.

5. Otestujte celou aplikaci

Navrhněte testy podle důsledků identifikovaných při modelování hrozeb. U asistenta RAG použijte adversariální dokumenty a uživatele s různými oprávněními. U agenta otestujte, co se stane, když ho načtený obsah požádá o překročení povolených akcí.

Před spuštěním testu definujte očekávaný výsledek. Příklad: aplikace musí zamítnout požadavek na soubor s omezeným přístupem, i když se model pokusí takový požadavek vznést.

Zaznamenejte konfiguraci aplikace, verzi modelu, testovací vstupy, výsledek a případnou nápravu. Zvolte testovací data, která zbytečně nevyzrazují skutečné důvěrné informace.

Užitečný výstup: opakovatelné bezpečnostní testy navázané na konkrétní rizika a rozhodnutí o vydání.

6. Monitorujte změny a připravte reakci

Přezkoumávejte dopad aktualizací modelů, dat a promptů. Monitorujte relevantní vstupy a výstupy a zároveň chraňte citlivé informace v logech. Provozní pokyny NCSC zdůrazňují monitorování chování a bezpečnostní dopady změn po celou dobu provozu. Pokyny NCSC k bezpečnému provozu AI

Předem rozhodněte, kdo může vypnout nástroj, zneplatnit přihlašovací údaje, izolovat integraci nebo vrátit vydání zpět. Stanovte spouštěče přezkoumání, jako je nový poskytovatel, rozšířená oprávnění, podstatná aktualizace modelu nebo bezpečnostní incident.

Užitečný výstup: odpovědnosti za monitorování, kritéria pro přezkoumání změn, postup reakce na incidenty a otestovaná cesta obnovy.

Jak proměnit bezpečnostní rizika AI v důkazy

Níže uvedená tabulka je navrhovanou pracovní šablonou. Uvedené příklady důkazů jsou praktická doporučení, nikoli seznam dokumentů vyžadovaných normou ISO 27090.

Představte si například bezpečnostní tým, který používá asistenta ke shrnování důkazů od zákazníků. Dokument od dodavatele obsahuje instrukce, aby asistent nahrál důkazy na externí adresu.

Test týmu by měl sledovat pokus o tuto akci napříč aplikací. Má asistent nástroj, který může nahrávat soubory? Vynucuje tento nástroj oprávnění uživatele? Jsou cíle omezeny? Musí přenos schválit odpovědná osoba?

Užitečný záznam o přezkoumání by identifikoval scénář, hranici, která přenosu brání, výsledek testu a osobu, která schválila zbytkové riziko. Pokud se systém změní, tento záznam dalšímu posuzovateli řekne, co je třeba znovu ověřit.

Tento přístup dává posouzení více obsahu než tvrzení, že systém používá „odpovědnou AI“. Propojuje bezpečnostní rozhodnutí s něčím, co může prověřit i jiná osoba. Více o organizaci podpůrných materiálů najdete v článku jak strukturovat připravenost na audit.

Certifikace a požadavky ISO 27090

ISO 27090 poskytuje bezpečnostní pokyny, nikoli požadavky pro certifikaci systému řízení. Vysvětlení od ISO odlišuje její účel od požadavků na AIMS v ISO 42001. Vysvětlení ISO 27090 od ISO

Nejprve určete, jakou míru ujištění potřebujete: bezpečnostní přezkoumání, odpověď pro zákazníka v oblasti ujištění, interní analýzu mezer nebo certifikaci podle příslušné normy systému řízení.

Požádejte každého, kdo nabízí posouzení, aby uvedl jeho rozsah, kritéria a schéma ujištění. Výsledek se tak snáze interpretuje a nedojde k záměně přezkoumání postupů bezpečnosti AI s certifikací systému řízení.

V implementačním projektu si opatřete zveřejněnou normu, přezkoumejte pokyny ve vztahu ke svým vlastním systémům a zaznamenejte, proč jsou konkrétní ochranná opatření vhodná. Příklady v tomto článku poskytují výchozí strukturu pro tuto práci.

ISO 27090 a akt EU o umělé inteligenci

Uplatnění mezinárodní normy automaticky nezakládá soulad s aktem EU o umělé inteligenci (AI Act). Článek 40 spojuje předpoklad shody s harmonizovanými normami, na něž byly zveřejněny odkazy v Úředním věstníku EU, a to pouze v rozsahu, v jakém pokrývají příslušné požadavky nebo povinnosti. Článek 40 aktu EU o umělé inteligenci

Bezpečnostní přezkoumání podle ISO 27090 použijte jako jeden ze vstupů pro samostatně vymezené posouzení souladu. Veďte záznam o posuzované právní povinnosti, o důkazech, které ji podporují, a o případné zbývající mezeře.

Často kladené otázky k ISO 27090

Kdy byla ISO 27090 vydána?

První vydání, ISO/IEC 27090:2026, bylo zveřejněno 14. října 2026. Pokud starší materiály odkazují na návrh nebo na dřívější rok, ověřte si aktuální záznam vydavatele. Záznam o publikaci IEC

Pokrývá ISO 27090 generativní AI a bezpečnost LLM?

Její zveřejněný obsah zahrnuje prompt injection a citlivé výstupy modelů, což ji činí relevantní pro bezpečnost generativní AI. Její rozsah zahrnuje i další systémy AI. Zveřejněná ukázka ISO/IEC 27090 Vysvětlení ISO 27090 od ISO

Může normu uplatnit společnost, která používá AI třetích stran?

Ano. Uvedená cílová skupina zahrnuje organizace, které AI používají, i organizace, které ji vyvíjejí. Začněte riziky a odpovědnostmi, které máte pod kontrolou, a určete, co potřebujete vědět o svých dodavatelích. Záznam o publikaci IEC

Znamená certifikace ISO 27001, že je systém AI bezpečný?

Certifikace systému řízení nezaručuje, že jednotlivá aplikace odolá každému útoku. Systém řízení používejte k organizaci rozhodnutí o rizicích a posuzujte skutečný návrh, konfiguraci a chování systému AI. ISO 27090 může tuto bezpečnostní práci podpořit.

Kde získám ISO 27090 ve formátu PDF?

Zveřejněnou normu a možnosti licencování najdete v oficiálním katalogu ISO nebo v IEC Webstore. Ověřte, že označení zní ISO/IEC 27090:2026. Článek nebo náhled poskytuje jen část materiálu.

Udělejte práci na bezpečnosti AI přezkoumatelnou

Začněte jedním případem užití AI s významnými důsledky. Určete, jak by mohl být kompromitován, zvolte ochranná opatření pro relevantní hranice a definujte důkazy, které prokážou, že tato opatření fungují. Každé akci přidělte vlastníka a spouštěč přezkoumání.

Secani propojuje požadavky, rizika, opatření, důkazy, vlastníky a rozhodnutí z přezkoumání ve sdíleném pracovním prostoru pro bezpečnost a compliance. Promluvte si se Secani o tom, jak uspořádat vaši práci na bezpečnosti AI, aby týmy viděly, co bylo posouzeno, co vyžaduje pozornost a kdo za co odpovídá.