EU Cyber Resilience Act — dopady na AI produkty

Cyber Resilience Act (CRA) je nariadenie EÚ prijaté v októbri 2024, ktoré vstúpilo do platnosti v decembri 2024. Od septembra 2026 — teda za menej ako dva mesiace — platia povinnosti v oblasti nahlasovania incidentov. Od decembra 2027 naberajú účinnosť všetky hlavné požiadavky. Pre tímy vyvíjajúce alebo nasadzujúce AI produkty na európskom trhu je to regulácia, ktorú nie je možné ignorovať — a čas na prípravu sa kráti.

1. Čo CRA reguluje

„Products with digital elements" (PDE) je kľúčový pojem. CRA sa vzťahuje na akýkoľvek produkt so softvérovými alebo hardvérovými komponentmi, ktorý sa pripája k sieti alebo iným zariadeniam. Explicitne zahŕňa softvér, firmvér, hardvérové zariadenia aj AI modely dodávané na trh EÚ.

Kto je povinný subjekt:

Výrobca (manufacturer) — ten, kto produkt navrhuje a uvádza na trh EÚ. Nesie hlavnú zodpovednosť.
Importér — firma, ktorá uvádza na trh EÚ produkt vyrobený mimo EÚ.
Distribútor — firma šíriaca produkt v EÚ bez zásadnej zmeny. Má obmedzené, ale reálne povinnosti.

Geografický dosah je bez výnimky: ak váš produkt predávate zákazníkom v EÚ, CRA sa vzťahuje na vás bez ohľadu na to, kde sídlite. Americký SaaS predávajúci do EÚ je plne v scope. Japonský výrobca priemyselných AI senzorov taktiež.

Dôležitý detail: CRA sa nevzťahuje na služby ako také (to je doména NIS2), ale softvér dodávaný ako súčasť SaaS produktu — vrátane modelov, klientskych aplikácií a SDK — pod CRA padá.

2. Tri triedy produktov

Zaradenie do triedy určuje prísnosť požiadaviek aj náklady na certifikáciu. Chybné zaradenie je jednou z najčastejších chýb pri prvotnom compliance assessmente.

Trieda	Príklady produktov	Spôsob zhody
Default (~90 % produktov)	Bežný spotrebiteľský softvér, produktivitné nástroje, väčšina B2B SaaS	Self-assessment — výrobca sám deklaruje zhodu
Important class	Bezpečnostné produkty, identity management, antivírusy, firewally, VPN, priemyselné AI nástroje	Third-party audit alebo certifikácia podľa harmonizovanej normy
Critical class	Systémy pre energetiku, dopravu, zdravotníctvo, kritickú infraštruktúru, HSM, PKI	Povinná certifikácia akreditovanou treťou stranou

Praktická heuristika pre AI produkty: AI model nasadený v zdravotníctve alebo riadení dopravy s veľkou pravdepodobnosťou padne do Important alebo Critical triedy. Väčšina B2B AI nástrojov pre kancelársku prácu zostane v Default triede — no aj tá má nezanedbateľné povinnosti.

3. Kľúčové požiadavky pre AI produkty

SBOM — Software Bill of Materials

SBOM je povinný strojovo čitateľný zoznam všetkých softvérových komponentov vrátane závislostí a ich verzií. Pre AI produkt to nie je triviálna vec — zahŕňa:

zdroj a verziu model weights (napr. Hugging Face commit hash)
tréningové frameworky (PyTorch, JAX, TensorFlow) s verziami
inference runtime (vLLM, TensorRT-LLM, ONNX Runtime)
všetky Python/systémové závislosti
akékoľvek vlastné alebo third-party pluginy

Štandardné formáty: CycloneDX 1.5+ (preferovaný pre AI, má rozšírenia pre ML metadata) alebo SPDX 2.3+. Nástroje: Syft, Trivy, Grype pre skenovanie; pre AI-špecifické metadáta sa rozvíja rozšírenie CycloneDX for ML.

Vulnerability Handling Process

Musíte mať formálny, zdokumentovaný proces na príjem, triáž a opravu bezpečnostných zraniteľností. Súčasťou je:

verejne dostupná politika zodpovedného zverejňovania (CVD — Coordinated Vulnerability Disclosure)
súbor security.txt na vašej doméne podľa RFC 9116 (/.well-known/security.txt)
definované SLA: potvrdenie hlásenia, triáž, oprava podľa závažnosti (napr. Critical: 7 dní, High: 30 dní)

Incident Reporting do 24 hodín — aktívne od septembra 2026

Aktívne zneužívané zraniteľnosti musíte nahlásiť ENISA do 24 hodín od zistenia. Toto je prvá povinnosť CRA, ktorá vstúpi do platnosti — od septembra 2026 je vymáhateľná. Notifikácia bude prebiehať cez ENISA Single Reporting Platform (SRP), ktorá je v pilotnej fáze od začiatku roka 2026.

Postup po notifikácii: do 72 hodín nasleduje podrobnejšie hlásenie, do 1 mesiaca záverečná správa s analýzou príčin.

Bezpečnostné aktualizácie počas životnosti produktu

Predvolená dĺžka podpory je 5 rokov od uvedenia na trh alebo po dobu aktívneho používania. Produkt vydaný v roku 2026 musíte aktívne záplatovať minimálne do roku 2031. Nemôžete vydať produkt a „zabudnúť naň".

Security by Design

Minimalizácia útočnej plochy, bezpečná predvolená konfigurácia, ochrana integrity, princíp najmenších oprávnení, šifrovanie citlivých dát v pokoji aj pri prenose. Pre AI produkty to zahŕňa aj ochranu model weights pred neoprávneným prístupom a odolnosť voči adversarial inputs v bezpečnostne kritických kontextoch.

4. Vzťah k EU AI Act

Obe regulácie fungujú paralelne a pre AI produkty sa prekrývajú — no riešia odlišné riziká.

CRA rieši kybernetickú bezpečnosť produktov → platí pre skoro všetok softvér a hardware
AI Act rieši riziká AI systémov → platí pre AI produkty s dôrazom na transparentnosť, diskrimináciu, základné práva

Prienikové produkty (high-risk AI systémy) musia spĺňať obe regulácie súčasne. Keďže harmonizácia medzi CRA a AI Act je stále v procese, v praxi to znamená separátne audity a dokumentácie.

Produkt	AI Act klasifikácia	CRA trieda	Hlavné povinnosti
AI model pre HR rozhodovanie	High-risk (Annex III)	Important	Conformity assessment (AI Act) + third-party audit (CRA)
AI chatbot pre zákaznícky servis	Low-risk	Default	Transparency disclosure (AI Act) + self-assessment (CRA)
AI systém pre riadenie dopravy	High-risk	Critical	Notified body (AI Act) + akreditovaná certifikácia (CRA)
AI generátor obsahu (B2C)	General purpose AI	Default	GPAI transparency (AI Act) + self-assessment (CRA)
Embedded AI v medicínskom prístroji	High-risk + MDR	Critical	Trojitá regulácia: AI Act + CRA + MDR

Európska komisia prisľúbila do konca roka 2026 harmonizované normy, ktoré by umožnili jeden technický audit pokryť požiadavky oboch nariadení. Zatiaľ treba rátať so separátnymi procesmi.

5. Open-source výnimky — a ich hranice

CRA zavádzol pojem „open-source steward" a výnimku pre nekomerčný open-source, no tieto pojmy sú v praxi úzke.

Čo je vyňaté: Čisto nekomerčné open-source projekty, kde neexistujú platené funkcie, predplatné ani komerčná podpora. Typicky ide o hobby projekty alebo akademický softvér bez monetizácie.

Čo je v scope:

Komerčné distribúcie open-source softvéru (Red Hat model, komerčný Kubernetes distro)
SaaS postavený na open-source LLM (napr. self-hosted Llama cez komerčný produkt)
Platený hosting alebo podpora open-source nástroja
Open-source projekt s „dual license" kde existuje komerčná verzia

Open-source steward povinnosti: Veľké firmy s komerčnými produktmi postavenými na open-source majú povinnosť aktívne prispievať k bezpečnosti upstreamových projektov — konkrétne: zverejniť kontaktný bod pre bezpečnostné hlásenia a spolupracovať pri opravách zraniteľností v projektoch, ktoré komerčne využívajú.

6. Vzťah k NIS2

CRA a smernica NIS2 (Network and Information Security Directive 2) sú komplementárne, no regulujú odlišné subjekty:

NIS2 reguluje prevádzkovateľov — firmy poskytujúce kľúčové alebo dôležité služby (banky, nemocnice, energia, digitálna infraštruktúra). Povinnosti sa týkajú bezpečnosti prevádzky a incidentov.
CRA reguluje výrobcov produktov — firmy, ktoré vyvíjajú a predávajú softvér/hardware.

Firma môže byť v scope oboch: napríklad cloudový poskytovateľ (NIS2 ako digital infrastructure provider) predávajúci vlastné bezpečnostné nástroje (CRA ako manufacturer). V takomto prípade platia obe sady povinností a je rozumné koordinovať incident response procesy tak, aby spĺňali obe.

7. Praktické kroky pre tím nasadzujúci AI produkt v 2026

September 2026 je za rohom. Toto je minimálny plán pre tím, ktorý zatiaľ nezačal:

Krok 1: Inventarizácia — ktoré produkty sú v scope Prejdite každý produkt a položte si otázky: Pripája sa k sieti? Majú zákazníci v EÚ? Je to softvér alebo hardware s digitálnymi prvkami? Výsledok: zoznam produktov s priradením do Default / Important / Critical triedy. Dokumentujte rozhodnutia — pri audite musíte vedieť zdôvodniť zaradenie.

Krok 2: SBOM generovanie do CI/CD Nainštalujte Syft alebo integrujte Trivy do CI/CD pipeline. Generujte SBOM vo formáte CycloneDX JSON pri každom release. Uložte a verzujte SBOM spolu s release artefaktmi — minimálne posledných 5 rokov. Pre AI produkty doplňte manuálne záznamy o model weights (zdroj, commit hash, licencia).

Krok 3: Vulnerability Disclosure Policy Vytvorte security.txt na vašej doméne. Definujte e-mail alebo formulár pre príjem hlásení. Stanovte SLA: potvrdenie do 5 pracovných dní, triáž do 14 dní, oprava podľa závažnosti. Zverejnite politiku na webe — musí byť prístupná bez prihlásenia.

Krok 4: Patch management — záväzok 5 rokov Formálne zdokumentujte dĺžku podpory pre každý produkt. Nastavte automatizované monitorovanie CVE pre všetky závislosti: Dependabot, Renovate alebo Grype v CI. Definujte SLA pre záplaty: Critical (CVSS 9+) do 7 dní, High do 30 dní, Medium do 90 dní.

Krok 5: Incident Response Playbook s 24h ENISA notifikáciou Zdokumentujte kroky od detekcie incidentu po notifikáciu ENISA. Určte zodpovednú osobu (CISO alebo security contact). Zaregistrujte sa na ENISA SRP portáli ešte pred septembrom 2026 — registrácia trvá niekoľko týždňov. Otestujte playbook simulovaným incidentom.

Krok 6: Príprava technickej dokumentácie (pre Important/Critical triedu) Ak váš produkt padá do Important alebo Critical triedy, začnite zbierať technickú dokumentáciu pre conformity assessment: risk assessment, security architecture, výsledky penetračných testov, SBOM, politiky. Toto je dokumentácia, ktorú pri audite predložíte — budovanie od nuly tesne pred auditom je nákladné a riskantné.

8. Nástroje a ekosystém

Pre tímy, ktoré sa práve orientujú v CRA toolchaine — prehľad nástrojov, ktoré sa v roku 2026 ustálili ako štandard:

Kategória	Nástroj	Poznámka
SBOM generovanie	Syft, Trivy, cdxgen	cdxgen má najlepšiu podporu pre Python/AI stacks
SBOM skenovanie zraniteľností	Grype, Trivy, OWASP Dependency-Check	Integrácia do GitHub Actions / GitLab CI
CVE monitoring	Dependabot, Renovate, socket.dev	Renovate má flexibilnejšiu konfiguráciu
VDP hosting	GitHub Security Advisories, HackerOne, Bugcrowd	GitHub je zadarmo pre open-source
Incident management	PagerDuty, OpsGenie, Jira Service Management	Kľúčové: integrácia s ENISA SRP
Compliance tracking	Vanta, Drata, Sprinto	Automatizujú dôkazné zbieranie pre audity

Pre malé tímy (do 20 ľudí): kombinácia Trivy v CI + GitHub Security Advisories pre VDP + jednoduchý Google Workspace incident log pokryje základné požiadavky Default triedy s minimálnymi nákladmi.

9. Sankcie

CRA má ostré zuby. Regulátor môže uplatniť:

15 000 000 EUR alebo 2,5 % celkového ročného globálneho obratu — podľa toho, čo je vyššie — za najzávažnejšie porušenia (nevyhovujúci produkt na trhu, nesplnenie povinnosti nahlasovania)
10 000 000 EUR alebo 2 % obratu za menej závažné procesné porušenia
Príkaz na stiahnutie produktu z trhu EÚ
Zákaz uviesť produkt na trh
Povinné zverejnenie porušenia — reputačný dopad, ktorý môže byť pre B2B firmy závažnejší než samotná pokuta

Dôležitý kontext: regulátor nebude od prvého dňa udeľovať maximálne pokuty. Prvé roky (2027–2028) sa očakáva fáza „soft enforcement" zameraná na existenciu dokumentácie a procesov, nie na technickú hĺbku. No firmy, ktoré ignorovali CRA úplne, budú vystavené reálnemu riziku.

10. Slovenský kontext

Kto je slovenský regulátor: Pre kybernetickú bezpečnosť je príslušným orgánom Národný bezpečnostný úrad (NBÚ). NBÚ implementuje smernice NIS2 a bude mať dohľadovú rolu aj pri CRA. Pre produkty s CE označením zostáva primárnym dohľadom príslušný market surveillance orgán — v závislosti od kategórie produktu to môže byť SÚTN (Slovenský ústav technickej normalizácie) alebo sektorový regulátor.

Ako vyzerajú audity v praxi (2026): Aktuálne (júl 2026) prebieha fáza prípravy. Audity v plnom rozsahu sa očakávajú od roku 2028, keď sú všetky povinnosti aktívne minimálne 6 mesiacov. Prvé kontroly budú zamerané na existenciu dokumentácie — SBOM, VDP, patch policy — nie na technickú hĺbku implementácie.

Slovenské firmy a certifikačné schémy: ENISA a EK pracujú na európskych schémach kybernetickej certifikácie (EUCS — European Union Cybersecurity Certification Scheme). Slovenské akreditačné orgány budú môcť certifikovať produkty v rámci týchto schém. Pre Important triedu to môže byť alternatíva k plnému third-party auditu.

Praktická rada: slovenské startupy a SME s produktmi v Default triede by mali v roku 2026 investovať čas do inventarizácie a SBOM — nie do drahých externých auditov. Audity prídu, keď budú povinné a keď bude jasné, čo presne auditori hľadajú.

Zhrnutie

CRA reguluje prakticky všetok komerčný softvér a hardware predávaný v EÚ vrátane AI modelov a systémov. Pre väčšinu tímov nie je otázka, či CRA platí — platí. Otázka je, ako rýchlo a efektívne sa pripraviť.

Tri kľúčové termíny:

December 2024 — CRA vstúpil do platnosti
September 2026 — incident reporting povinný (za menej ako 2 mesiace)
December 2027 — všetky hlavné požiadavky aktívne

Päť hlavných povinností: SBOM, vulnerability disclosure policy, incident reporting do 24 h, 5-ročná záplatová podpora, security by design.

Open-source výnimka platí len pre skutočne nekomerčné projekty. Komerčný SaaS na open-source základe je v scope.

Pokuty dosahujú 15M EUR alebo 2,5 % obratu. Ignorovanie CRA nie je reálna možnosť pre žiadnu firmu predávajúcu do EÚ.

Odporúčanie pre júl 2026: inventarizácia produktov → SBOM do CI/CD → security.txt + VDP → patch SLA → incident playbook s ENISA registráciou. V tomto poradí, tento mesiac.