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 platia povinnosti v oblasti nahlasovania incidentov a 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 ide o reguláciu, ktorú nie je možné ignorovať.

1. Čo CRA reguluje

  • „Products with digital elements" (PDE)

    • 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Ú
    • importér — firma, ktorá uvádza na trh EÚ produkt vyrobený mimo EÚ
    • distribútor — firma šíriaca produkt v EÚ bez zásadnej zmeny

  • Geografický dosah

    • 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 v scope

2. Tri triedy produktov

  • Predvolená trieda (Default class) — ~90 % produktov

    • väčšina bežného softvéru a hardvéru
    • self-assessment: výrobca sám vyhlasuje zhodu

  • Dôležitá trieda (Important class)

    • bezpečnostné produkty, identity management, sieťové nástroje, antivírusový softvér, firewally
    • vyžaduje buď third-party audit alebo certifikáciu podľa schválenej normy

  • Kritická trieda (Critical class)

    • systémy pre energetiku, dopravu, zdravotníctvo, kritickú infraštruktúru
    • povinná certifikácia akreditovanou treťou stranou

(AI model nasadený v zdravotníctve alebo riadení dopravy s veľkou pravdepodobnosťou padne do Important alebo Critical triedy.)

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

  • SBOM — Software Bill of Materials

    • povinný zoznam všetkých softvérových komponentov vrátane závislostí a ich verzií
    • štandardné formáty: CycloneDX alebo SPDX
    • generovanie cez nástroje ako Syft, Grype, Trivy
    • pre AI produkt to zahŕňa: model weights zdroj, tréningové frameworky, inference runtime, knižnice

  • Vulnerability handling process

    • musíte mať formálny proces na príjem, triáž a opravu bezpečnostných zraniteľností
    • verejne dostupná politika zodpovedného zverejňovania (CVD — Coordinated Vulnerability Disclosure)
    • odporúčaný formát: súbor security.txt na vašej doméne (RFC 9116)

  • Incident reporting do 24 hodín

    • aktívne zneužívané zraniteľnosti musíte nahlásiť ENISA (Agentúra EÚ pre kybernetickú bezpečnosť) do 24 hodín od zistenia
    • od septembra 2026 je táto povinnosť aktívna
    • formát notifikácie bude štandardizovaný cez ENISA portál

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

    • predvolená dĺžka podpory: 5 rokov od uvedenia na trh (alebo po dobu, počas ktorej sa produkt používa)
    • nemôžete vydať produkt a „zabudnúť naň" — musíte aktívne záplatovať bezpečnostné chyby

  • Bezpečnosť od návrhu (Security by design)

    • minimalizácia útočnej plochy, bezpečná predvolená konfigurácia, ochrana integrity

4. Vzťah k EU AI Act

  • Obe regulácie fungujú paralelne

    • CRA rieši kybernetickú bezpečnosť produktov → platí pre skoro všetok softvér
    • AI Act rieši riziká AI systémov → platí pre AI produkty
    • prienikové produkty (high-risk AI systémy) musia spĺňať obe regulácie súčasne

  • Zjednodušená mapa povinností

    • AI model pre HR rozhodovanie → AI Act high-risk + CRA Important class
    • AI chatbot pre zákaznícky servis → AI Act low-risk + CRA Default class
    • AI systém pre riadenie dopravy → AI Act high-risk + CRA Critical class

  • Harmonizácia je v procese

    • EK pracuje na harmonizovaných normách, ktoré by umožnili jeden audit pokryť obe regulácie
    • zatiaľ treba rátať so separátnymi procesmi

5. Open-source výnimky

  • Stewardship výnimka pre nekomerčný open-source

    • čisto nekomerčné open-source projekty sú z väčšiny povinností vyňaté
    • podmienka: projekt musí byť skutočne nekomerčný — žiadne platené funkcie, žiadne predplatné

  • Komerčné distribúcie sú v scope

    • ak postavíte SaaS alebo komerčný produkt na open-source základe, CRA sa na vás vzťahuje
    • príklady: komerčná distribúcia Linuxu, SaaS na báze open-source LLM, platený hosting open-source nástroja

  • Upstreamové zodpovednosti

    • CRA zavádza pojem „open-source steward" — veľké firmy s komerčnými produktmi by mali prispievať k bezpečnosti upstreamových projektov, na ktorých stavajú

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

  • Krok 1: Inventarizácia — ktoré produkty sú v scope

    • prejdite každý produkt/službu: 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

  • Krok 2: SBOM generovanie

    • nainštalujte Syft alebo integrujte do CI/CD pipeline
    • generujte SBOM vo formáte CycloneDX JSON pri každom release
    • uložte a verzujte SBOM spolu s release artefaktmi

  • Krok 3: Vulnerability disclosure policy

    • vytvorte security.txt na vašej doméne (https://vasadomena.com/.well-known/security.txt)
    • definujte e-mail / formulár pre príjem hlásení o zraniteľnostiach
    • stanovte SLA: koľko dní trvá potvrdenie, triáž, oprava

  • Krok 4: Patch management — záväzok 5 rokov

    • formálne zdokumentujte dĺžku podpory pre každý produkt
    • nastavte proces monitorovania CVE pre všetky závislosti (napr. Dependabot, Renovate, Grype v CI)
    • plán vydávania bezpečnostných záplat s definovanými SLA podľa závažnosti

  • 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)
    • od septembra 2026: notifikácia do 24 hodín od zistenia aktívneho zneužívania

7. Sankcie

  • Maximálne pokuty

    • 15 000 000 EUR alebo 2,5 % celkového ročného globálneho obratu — podľa toho, čo je vyššie
    • pre Important a Critical triedu môžu byť sankcie vyššie

  • Iné opatrenia

    • príkaz na stiahnutie produktu z trhu EÚ
    • zákaz uviesť produkt na trh
    • povinné zverejnenie porušenia (reputačný dopad)

8. 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ť rolu aj pri CRA dohľade
    • kontaktný bod: nbu.gov.sk

  • Ako vyzerajú audity v praxi

    • zatiaľ (2026) prebieha fáza prípravy — audity v plnom rozsahu sa očakávajú od 2028
    • prvé kontroly budú zamerané na existenciu dokumentácie (SBOM, VDP, patch policy), nie na technickú hĺbku
    • odporúčanie: začať budovať dokumentáciu teraz, nie čakať na poslednú chvíľu

  • Slovenské firmy a európske 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

Zhrnutie

  • CRA reguluje prakticky všetok komerčný softvér a hardware predávaný v EÚ vrátane AI modelov a systémov.

  • Tri kľúčové termíny: príjem regulácie december 2024, incident reporting september 2026, plné povinnosti december 2027.

  • Päť hlavných povinností: SBOM, vulnerability disclosure, incident reporting do 24 h, 5-ročná záplata 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 2026: inventarizácia produktov → SBOM do CI/CD → security.txt → patch SLA → incident playbook.