Od 11. září 2026 začala v EU platit první část Cyber Resilience Actu (CRA), která má praktický dopad už teď: výrobci digitálních produktů musí hlásit aktivně zneužívané zranitelnosti a závažné bezpečnostní incidenty.
Neznamená to, že každá firma s webem, e-shopem nebo interním AI asistentem získala novou povinnost do 24 hodin. Pravidlo míří především na výrobce softwaru a hardwaru uváděného na evropský trh. Pro malé české firmy je ale důležité vědět, jestli jsou jen uživatelem nástroje, nebo už dodávají vlastní digitální produkt zákazníkům.
Tento článek je praktické vysvětlení, ne právní posudek. Pokud dodáváte software, zařízení nebo službu s nejasným zařazením, ověřte konkrétní situaci s právníkem nebo specialistou na produktovou compliance.
Co se od 11. září skutečně změnilo
CRA je evropské nařízení o kybernetické odolnosti produktů s digitálními prvky. Týká se hardwaru a softwaru uváděného na trh EU — od zařízení připojených k síti přes aplikace až po samostatně prodávané softwarové komponenty.
Většina pravidel CRA začne naplno platit až 11. prosince 2027. Oznamovací povinnost podle článku 14 ale začala dříve, 11. září 2026. Výrobce musí přes evropskou jednotnou oznamovací platformu informovat příslušný CSIRT a ENISA, pokud se dozví o:
- aktivně zneužívané zranitelnosti ve svém produktu;
- závažném incidentu, který ovlivňuje bezpečnost jeho produktu.
Nejde tedy o každou chybu, výpadek nebo nepříjemný e-mail od zákazníka. Rozhodující je bezpečnostní dopad a u zranitelnosti také to, že je aktivně zneužívána.
Koho se povinnost týká — a koho zatím ne
Nejdůležitější otázka není „Používáme AI?“, ale „Jsme výrobcem produktu s digitálními prvky, který nabízíme na trhu EU?“
Typicky ve hře budete, když
- prodáváte vlastní aplikaci, desktopový program nebo mobilní aplikaci;
- dodáváte zákazníkům SaaS, klientský portál nebo jiný online software jako vlastní produkt;
- vyvíjíte a prodáváte plugin, integrační konektor, firmware nebo samostatnou softwarovou komponentu;
- uvádíte na trh zařízení s vlastním softwarem nebo připojením k internetu;
- upravujete cizí produkt natolik, že se z pohledu pravidel stává vaším vlastním řešením.
Samotné používání nástroje obvykle nestačí
Firma, která pro sebe používá účetní systém, ChatGPT, n8n, CRM nebo interního AI asistenta, není automaticky výrobcem těchto nástrojů. Primární oznamovací povinnost může zůstávat na jejich výrobci.
To ale není důvod bezpečnost ignorovat. Interní automatizace může pracovat s e-maily, objednávkami, dokumenty nebo přihlašovacími údaji. Při incidentu pak firma řeší vlastní smluvní, provozní a případně i jiné právní povinnosti — jen to není totéž co hlášení podle článku 14 CRA.
AI agent sám o sobě není nová právní kategorie. Rozhoduje, zda z něj děláte produkt pro trh, jakou roli v dodavatelském řetězci máte a jak je řešení poskytováno zákazníkům.
Čas běží ve třech krocích
Evropská komise popisuje čtyři důležité lhůty. Pro běžné rozhodování stačí rozlišit aktivně zneužívanou zranitelnost a závažný incident.
| Situace | Co se odesílá | Lhůta |
|---|---|---|
| Aktivně zneužívaná zranitelnost | První varování | Do 24 hodin od okamžiku, kdy se o ní výrobce dozví |
| Aktivně zneužívaná zranitelnost | Podrobnější oznámení | Do 72 hodin |
| Aktivně zneužívaná zranitelnost | Závěrečná zpráva | Nejpozději 14 dní poté, co je k dispozici náprava nebo zmírňující opatření |
| Závažný incident | První varování a podrobnější oznámení | Do 24, respektive 72 hodin |
| Závažný incident | Závěrečná zpráva | Do jednoho měsíce od oznámení do 72 hodin |
Praktický problém není vyplnit formulář. Je poznat, že se děje něco oznamovatelného, zjistit, kdo rozhoduje, a mít připravená data o produktu, zranitelnosti i dotčených uživatelích.
Příklad: bezpečnostní chyba v doplňku pro e-shop
Představte si firmu, která prodává vlastní doplněk pro e-shopy. Doplněk ukládá objednávky, napojuje dopravce a má přístupový token do API.
Když vývojář najde běžnou chybu při testování, opraví ji a žádné zneužití není známé, neznamená to automaticky hlášení do CRA platformy. Pořád ale musí chybu opravit a odpovědně řídit.
Jiná situace nastane, když se ukáže, že útočníci chybu opravdu využívají k získávání přístupových tokenů zákazníků. Pak už firma nemůže čekat na běžný příští release. Musí rozběhnout technickou nápravu i oznamovací proces a umět vysvětlit, co ví, koho problém může zasáhnout a jaké kroky podniká.
To je rozdíl, který má být v organizaci jasný dřív než při prvním incidentu.
Co si připravit ještě před incidentem
Malý tým nepotřebuje budovat velké compliance oddělení. Potřebuje ale jednoduchý postup, který funguje i v pátek večer, kdy je vývojář na dovolené.
- Sepište, které digitální produkty skutečně dodáváte. U každého určete vlastníka produktu, technického správce a způsob, jak zákazníci dostávají aktualizace.
- Rozhodněte, kdo vyhodnotí závažnost. Nestačí obecná adresa typu [email protected]. Potřebujete člověka nebo malý tým, který může říct: toto je aktivně zneužívaná zranitelnost a začíná nám běžet čas.
- Připravte si základní evidenci. Verze produktu, závislé komponenty, kontakty na zákazníky a záznam změn výrazně zkrátí první hodiny incidentu.
- Nastavte cestu pro technickou nápravu. Musíte umět vydat opravu, zneplatnit kompromitovaný klíč nebo dočasně vypnout rizikovou funkci bez dlouhého schvalovacího kolečka.
- Oddělte bezpečnost produktu od běžných výpadků. Pád webu a aktivní zneužívání chyby nemusí být stejná událost. Každá ale potřebuje vlastního vlastníka a komunikační plán.
Proč se to týká i firem, které teprve staví AI produkt
Mnoho týmů dnes skládá produkt z modelu, API, databáze, automatizace a několika MCP konektorů. Hotový AI agent pak může číst firemní dokumenty, pracovat s objednávkami, posílat e-maily nebo spouštět další nástroje.
Pokud takové řešení poskytujete zákazníkům jako produkt, neměli byste bezpečnost nechat až na okamžik, kdy budete řešit certifikaci v roce 2027. Už dnes potřebujete vědět, jak přijmete hlášení o zranitelnosti, kdo posoudí její dopad a jak zákazníkům doručíte nápravu.
Neznamená to, že každá automatizace musí projít stejným procesem jako bankovní aplikace. Znamená to, že množství oprávnění, typ dat a možnost spouštět akce musí odpovídat tomu, jak rychle dokážete problém odhalit a omezit.
Kde firmy nejčastěji chybují
- Považují CRA za vzdálenou věc roku 2027. Část pravidel už běží; oznamovací proces nelze navrhnout během prvních 24 hodin incidentu.
- Míchají výrobce a uživatele. Firma používající hotový nástroj má jiné povinnosti než firma, která tento nástroj prodává pod vlastní značkou.
- Nemají přehled o závislostech. U SaaS a AI produktů se problém často objeví v knihovně, konektoru nebo dodavatelské službě, ne přímo ve vlastním kódu.
- Čekají na stoprocentní jistotu. První varování má smysl právě proto, že při prvním zjištění ještě nemusíte znát celý rozsah.
Co z toho plyne pro malou firmu
Pokud jen používáte software a AI nástroje pro vlastní práci, nespěchejte se složitým projektem CRA. Začněte tím, že si ohlídáte přístupy, zálohy, aktualizace a cestu k lidskému rozhodnutí u citlivých automatizací.
Jestli ale svým klientům dodáváte vlastní aplikaci, plugin, zařízení nebo digitální službu pod vlastní značkou, oznamovací povinnost už není vzdálené téma. První krok není právnický román. Je to poctivá mapa produktu, odpovědností a schopnosti vydat nápravu.
Když stavíte produkt s AI, e-shopové napojení nebo automatizaci s přístupem k důležitým datům, pomůžeme vám projít technickou architekturu, oprávnění a provozní postupy. Právní posouzení CRA samozřejmě patří specialistovi, ale bezpečné nastavení systému začíná v tom, jak je produkt postavený. Ozvěte se.
Související články
- OpenAI Astra a bezpečné nasazení AI agentů: oprávnění, sandbox a lidské schválení
- CrowdStrike a OpenAI: proč se bezpečnost AI agentů stává samostatnou službou
- n8n: automatizace, která propojí vaše systémy bez ruční práce
