Keď sa povie kybernetický útok, väčšina ľudí si predstaví vírus, ransomware alebo phishingový email. Niečo, čo príde zvonku, pokúsi sa preniknúť do systému a antivírus to zachytí — alebo nezachytí. Tento obraz kybernetickej hrozby je zakorenený hlboko a do značnej miery správny.

Pre klasickú IT infraštruktúru.

Umelá inteligencia mení pravidlá hry. Nie preto, že by klasické hrozby zmizli — stále existujú a stále sú relevantné. Ale AI systémy prinášajú úplne novú vrstvu zraniteľností, ktoré fungujú inak, útočia inak a — čo je kľúčové — klasické bezpečnostné nástroje ich väčšinou vôbec nezaznamenajú.

Predstavte si chatbota, ktorého vaša firma nasadila na zákaznícku podporu. Antivírus ho skenuje. Firewall monitoruje prevádzku. Všetko vyzerá v poriadku. A napriek tomu útočník práve presvedčil vášho chatbota, aby zákazníkovi poskytol zavádzajúce informácie — alebo aby vyzradil interné dáta, ku ktorým by zákazník nemal mať prístup. Nestalo sa to cez malware. Stalo sa to cez obyčajnú textovú správu.

Alebo si predstavte, že AI model, ktorý vaša firma používa na analýzu zákazníckych dát, bol pred mesiacmi nenápadne „otrávený" manipulovanými tréningovými dátami. Jeho výstupy vyzerajú normálne. Nikto nič nepozoruje. A model systematicky produkuje skreslené výsledky, ktoré ovplyvňujú vaše obchodné rozhodnutia.

Toto nie sú scenáre zo sci-fi. Sú to reálne triedy útokov, ktoré bezpečnostná komunita dokumentuje a analyzuje — a ktorým väčšina malých a stredných firiem nie je pripravená čeliť, pretože o nich jednoducho nevie.

V tomto článku si ich prejdeme ľudskou rečou — bez zbytočného technického žargónu, ale s dostatočnou presnosťou na to, aby ste pochopili, čo sa deje, prečo je to problém a čo s tým môžete urobiť.

Data poisoning — keď niekto otrávil studňu pred tým, ako ste z nej začali piť

Predstavte si, že váš dodávateľ softvéru vám dodá nový modul na spracovanie objednávok. Nainštalujete ho, otestujete — funguje. Používate ho mesiace bez problémov. Až po pol roku zistíte, že modul od začiatku obsahoval skrytú funkciu, ktorá v určitých situáciách presmerúvala platby. Dodávateľ o tom nevedel — niekto manipuloval zdrojový kód ešte pred dodaním.

Data poisoning funguje rovnako — len namiesto kódu sa manipulujú dáta, na ktorých sa AI model učí. A rovnako ako v tomto príklade: v čase, keď si problém všimnete, model už dlho robí to, čo útočník chcel.

Čo je data poisoning

Data poisoning je typ útoku, pri ktorom útočník manipuluje tréningové dáta AI modelu tak, aby model produkoval skreslené, nesprávne alebo útočníkom želané výstupy. Útok sa nestáva v momente používania modelu — stáva sa skôr, počas jeho trénovania. V čase, keď model nasadíte a začnete ho používať, je už „otrávený" — a vy o tom neviete.

Dva základné typy

Prvý typ sa nazýva útok na integritu — útočník manipuluje model tak, aby v určitých situáciách produkoval konkrétne nesprávne výstupy. Klasickým príkladom sú AI systémy na rozpoznávanie obrazu, ktoré boli natrénované tak, aby konkrétny objekt — napríklad zastavovací dopravný znak s malou nálepkou — identifikovali ako niečo úplne iné. Pre autonómne vozidlo to môže mať fatálne následky. Pre firmu, ktorá používa AI na detekciu podvodných transakcií, to môže znamenať, že útočníkom navrhnuté transakcie budú systematicky označované ako bezpečné.

Druhý typ sa nazýva útok na dostupnosť — útočník degraduje celkovú kvalitu modelu natoľko, že prestáva byť použiteľný. Cieľom nie je konkrétny výstup, ale celkové znefunkčnenie systému.

Prečo je to relevantné pre bežnú firmu

Možno si myslíte, že data poisoning sa týka len firiem, ktoré si trénujú vlastné AI modely. To je čiastočne pravda — priamy útok na tréning modelu si vyžaduje prístup k tréningovým dátam. No existuje aj nepriama vrstva rizika, ktorá sa týka každej firmy.

Ak používate AI nástroj tretej strany — chatbota, analytický model, odporúčací systém — dôverujete tomu, že jeho poskytovateľ má tréningové dáta pod kontrolou. Ak ich nemá, alebo ak bol sám obeťou data poisoningu, výstupy nástroja, ktorý platíte a používate, môžu byť systematicky skreslené. A vy to nezistíte pohľadom na výstup — pretože výstup vyzerá normálne.

Prípad spoločnosti Vercel z apríla 2026, ktorý sme podrobnejšie rozobrali v súvislosti so Shadow AI, je dobrým príkladom toho, ako kompromitácia jedného článku v dodávateľskom reťazci AI nástrojov môže mať kaskádový efekt na všetkých jeho používateľov.

Dosah z pohľadu GDPR a NIS2

Ak AI model trénovaný na osobných údajoch zákazníkov alebo zamestnancov podlieha data poisoningu, môže dôjsť k situácii, keď model začne produkovať výstupy, ktoré odhaľujú alebo nesprávne spracúvajú tieto osobné údaje. Z pohľadu GDPR ide o bezpečnostný incident, ktorý môže zakladať povinnosť notifikácie dozorného orgánu podľa článku 33 GDPR.

Pre subjekty spadajúce pod NIS2 — respektíve v slovenskom právnom prostredí pod zákon č. 69/2018 Z.z. o kybernetickej bezpečnosti — data poisoning predstavuje relevantné riziko v rámci povinného hodnotenia bezpečnosti dodávateľského reťazca. Firmy, ktoré poskytujú služby NIS2-regulovaným subjektom, musia byť schopné preukázať, že ich AI nástroje pochádzajú z dôveryhodných zdrojov a sú pravidelne overované.

Praktická poznámka: pre väčšinu MSP nie je reálnym scenárom priamy útok na vlastný AI model — väčšina malých firiem si modely sama netrénuje. Relevantnejšia otázka je: dôverujete bezpečnostným praktikám poskytovateľa AI nástroja, ktorý používate? Overili ste, ako zabezpečuje integritu svojich modelov? Tieto otázky by mali byť súčasťou due diligence pri výbere akéhokoľvek AI nástroja — rovnako ako cena alebo funkcie.

Model inversion a model theft — keď AI prezradí, čo by nemala

Doteraz sme hovorili o útokoch, pri ktorých útočník niečo do AI systému vkladá — škodlivé dáta, škodlivé inštrukcie. Teraz sa pozrieme na opačný smer: útočník sa nepokúša do systému niečo dostať, ale niečo z neho dostať von. Konkrétne — informácie, ktoré by model nemal prezradiť.

Čo je model inversion

Model inversion je typ útoku, pri ktorom útočník systematicky kladie AI modelu otázky a na základe jeho odpovedí spätne rekonštruuje dáta, na ktorých bol model trénovaný. Zjednodušene povedané: model sa naučil zo skutočných dát — a šikovne formulovanými otázkami ho môžete prinútiť, aby vám tieto dáta prezradil.

Príklad z praxe: firma trénuje AI model na rozpoznávanie tvárí zamestnancov pre systém kontroly vstupu. Model sa naučil zo skutočných fotografií. Útočník systematicky kladie modelu otázky a na základe odpovedí dokáže rekonštruovať fotografie konkrétnych osôb — bez toho, aby k nim mal priamy prístup.

Pre firmy, ktoré trénujú AI modely na osobných údajoch zákazníkov alebo zamestnancov — napríklad na histórii nákupov, zdravotných záznamoch alebo finančných dátach — model inversion predstavuje reálne riziko úniku osobných údajov. A to aj v prípade, že samotná databáza je bezpečne uložená a chránená.

Čo je model theft

Model theft — krádež modelu — je útok, pri ktorom útočník systematickým dopytovaním AI systému vytvorí jeho funkčnú kópiu bez toho, aby mal prístup k pôvodnému modelu alebo jeho tréningovým dátam. Útočník jednoducho kladie veľké množstvo otázok, zaznamenáva odpovede a na ich základe trénuje vlastný model, ktorý sa správa podobne ako originál.

Pre firmu to znamená dve veci. Po prvé, konkurent môže získať funkčný ekvivalent AI systému, do ktorého ste investovali čas a peniaze — čo je priamy zásah do obchodného tajomstva. Po druhé, ukradnutý model môže byť použitý na hlbšiu analýzu zraniteľností pôvodného systému — útočník ho testuje v bezpečí vlastného prostredia a hľadá slabé miesta.

Prečo je model inversion závažný problém z pohľadu GDPR

Toto je bod, kde sa technická hrozba priamo stretáva s právnou zodpovednosťou.

Ak AI model trénovaný na osobných údajoch umožňuje ich rekonštrukciu prostredníctvom model inversion útoku, ide o bezpečnostnú zraniteľnosť, ktorá môže zakladať porušenie GDPR hneď z niekoľkých dôvodov.

Po prvé, článok 25 GDPR zakotvuje zásadu ochrany údajov už v štádiu návrhu — teda privacy by design. Firma, ktorá trénuje AI model na osobných údajoch bez toho, aby zohľadnila riziká model inversion, pravdepodobne túto zásadu nespĺňa.

Po druhé, článok 35 GDPR vyžaduje posúdenie vplyvu na ochranu údajov — DPIA — pri spracúvaní, ktoré môže predstavovať vysoké riziko pre práva a slobody fyzických osôb. Tréning AI modelu na citlivých osobných údajoch do tejto kategórie typicky spadá.

Po tretie, ak k model inversion útoku skutočne dôjde a osobné údaje sú rekonštruované, vzniká bezpečnostný incident s povinnosťou notifikácie podľa článku 33 GDPR.

Praktická poznámka: model inversion a model theft sú hrozby, ktoré sa primárne týkajú firiem trénujúcich vlastné AI modely na citlivých dátach. Pre väčšinu MSP, ktoré používajú hotové AI nástroje tretích strán, je priame riziko nižšie. Napriek tomu odporúčame pri výbere AI nástroja overiť, či poskytovateľ implementuje technické opatrenia proti týmto typom útokov — napríklad obmedzenie počtu dopytov, monitorovanie neštandardného správania alebo diferenciálne súkromie pri tréningu modelov. Tieto informácie by mali byť súčasťou bezpečnostnej dokumentácie poskytovateľa.

Prečo sa tieto hrozby líšia od klasických kybernetických útokov

Keď IT oddelenie alebo externý správca siete nastavuje bezpečnosť firemnej infraštruktúry, pracuje s osvedčeným nástrojovým arzenálom: antivírus, firewall, detekcia prienikov, zálohovanie, správa prístupov. Tieto nástroje sú dobre preverené a pri správnej konfigurácii dokážu zachytiť väčšinu klasických kybernetických hrozieb.

Pri AI-špecifických hrozbách, o ktorých sme hovorili v predchádzajúcich častiach, tieto nástroje zlyhávajú. Nie preto, že by boli zastarané — ale preto, že útočná plocha AI systémov je zásadne odlišná od klasickej IT infraštruktúry.

Kde klasické nástroje nestačia

Antivírus hľadá škodlivý kód — súbory, procesy, správanie programov, ktoré sa odlišuje od normy. Data poisoning nepracuje so škodlivým kódom. Pracuje s dátami — a manipulované tréningové dáta vyzerajú pre antivírus úplne normálne. Nie sú to vírusy. Sú to čísla a texty, ktoré sú len trochu iné ako by mali byť.

Firewall monitoruje sieťovú prevádzku a blokuje neoprávnené spojenia. Prompt injection útok nepotrebuje otvoriť nové sieťové spojenie. Využíva existujúce, legitímne rozhranie — textový vstup chatbota alebo AI asistenta. Z pohľadu firewallu je prompt injection útok nerozoznateľný od bežnej komunikácie so zákazníkom.

Detekcia prienikov — IDS/IPS systémy — hľadá vzory správania, ktoré naznačujú útok: skenovanie portov, neobvyklé množstvo požiadaviek, pokusy o prihlásenie. Model inversion útok vyzerá ako séria bežných dopytov na AI systém. Každý jednotlivý dopyt je legitímny. Škodlivý je až ich celok — a to je niečo, čo klasické IDS systémy bez špecializovanej AI bezpečnostnej vrstvy nedokážu rozpoznať.

Nová útočná plocha: vstup, model, výstup

Klasická IT bezpečnosť chráni infraštruktúru — servery, siete, zariadenia. AI systémy pridávajú tri nové vrstvy útočnej plochy, ktoré klasická bezpečnosť nepokrýva.

Prvá vrstva je vstup — teda to, čo do AI systému vkladáte. Tu útočí prompt injection a nepriamy prompt injection cez externý obsah.

Druhá vrstva je model samotný — jeho tréningové dáta a váhy. Tu útočí data poisoning a model theft.

Tretia vrstva je výstup — teda to, čo AI systém produkuje a čo firma ďalej používa. Tu sa prejavujú halucinácie, bias a dôsledky model inversion.

Žiadna z týchto vrstiev nie je štandardne pokrytá klasickým bezpečnostným stackom. Vyžadujú špecializovaný prístup — a ten začína nie technológiou, ale povedomím o tom, kde riziká existujú.

Prepojenie na NIS2

Pre firmy spadajúce pod smernicu NIS2 — respektíve pod zákon č. 69/2018 Z.z. o kybernetickej bezpečnosti v slovenskom právnom prostredí — majú AI-špecifické hrozby priamy regulačný dosah.

Článok 21 NIS2 vyžaduje implementáciu opatrení kybernetickej bezpečnosti primeraných riziku — vrátane bezpečnosti dodávateľského reťazca a riadenia zraniteľností. AI nástroje sú súčasťou tohto dodávateľského reťazca. Firma, ktorá ich používa bez toho, aby posúdila AI-špecifické riziká, nespĺňa požiadavky NIS2 bez ohľadu na to, ako dobre má zabezpečenú klasickú IT infraštruktúru.

Pre firmy, ktoré priamo NIS2 nepodliehajú, ale dodávajú služby subjektom, ktoré jej podliehajú, platí rovnaká logika — bezpečnostné požiadavky sa kaskádujú cez dodávateľský reťazec.

Praktická poznámka: rozpoznanie rozdielov medzi klasickými a AI-špecifickými hrozbami nie je akademické cvičenie. Je to základ pre správne nastavenie bezpečnostných priorít. Firma, ktorá investuje do antivírusu a firewallu, no nasadí nezabezpečeného AI agenta s prístupom k zákazníckym dátam, má v bezpečnostnom perimetri medzeru, ktorú klasické nástroje nezaplnia. Prvým krokom k náprave je vedieť, kde medzera je.

Praktické kroky — ako sa brániť

Zoznam hrozieb, ktorý sme prešli v predchádzajúcich častiach, môže pôsobiť odstrašujúco. Data poisoning, prompt injection, model inversion, model theft — a na to všetko klasické bezpečnostné nástroje nestačia. Čo teda môže urobiť bežná firma bez bezpečnostného tímu a bez rozpočtu na špecializované AI bezpečnostné riešenia?

Viac, ako si možno myslíte. A väčšina z toho nevyžaduje technické znalosti.

1. Uplatňujte princíp minimálnych oprávnení pre všetky AI systémy

Každý AI nástroj, ktorý nasadzujete — chatbot, AI agent, analytický model — by mal mať prístup výlučne k tým dátam a funkciám, ktoré nevyhnutne potrebuje na svoju úlohu. Nič viac.

Chatbot na zákaznícku podporu nepotrebuje prístup k mzdovým dátam. AI asistent na spracovanie emailov nepotrebuje oprávnenie posielať emaily bez ľudského schválenia. AI nástroj na analýzu objednávok nepotrebuje prístup k celej zákazníckej databáze.

Obmedzenie oprávnení je najúčinnejší spôsob, ako znížiť potenciálny dosah prompt injection útoku — aj keď útok prebehne, útočník nedostane prístup k ničomu, čo AI systém nemá.

2. Zaveďte ľudské schválenie pre všetky akcie AI agentov s reálnym dopadom

AI agenti, ktorí môžu vykonávať akcie — posielať emaily, vytvárať záznamy, spúšťať platby, pristupovať k externým systémom — by mali pred každou takouakciou s reálnym dopadom vyžadovať ľudské schválenie. Automatizácia je hodnotná, no plná autonómia AI agenta bez ľudského dohľadu je bezpečnostné riziko, ktoré v súčasnom stave technológie nie je opodstatnené.

Toto pravidlo navyše nie je len odporúčanie — od 2. decembra 2027 je ľudský dohľad nad vysokorizikovými AI systémami právnou povinnosťou podľa AI Actu.

3. Overujte poskytovateľov AI nástrojov rovnako dôsledne ako iných dodávateľov

Pri výbere účtovného softvéru alebo CRM systému väčšina firiem overuje referencie, bezpečnostné certifikácie a zmluvné podmienky. Pri výbere AI nástroja by malo platiť to isté — alebo prísnejšie kritériá, pretože AI nástroje majú prístup k dátam, ktoré klasický softvér nemá.

Konkrétne otázky, ktoré by mal každý dodávateľ AI nástroja vedieť zodpovedať: Ako zabezpečujete integritu tréningových dát? Aké opatrenia máte proti prompt injection? Kde sú dáta fyzicky uložené? Je k dispozícii zmluva o spracúvaní osobných údajov podľa článku 28 GDPR? Ak dodávateľ na tieto otázky nevie odpovedať — je to varovný signál.

4. Monitorujte výstupy AI systémov priebežne

Anomálie v správaní AI systému — neočakávané odpovede, nezvyčajné vzory v output dátach, výstupy, ktoré sa líšia od očakávaného správania — môžu byť prvým príznakom data poisoning útoku alebo inej kompromitácie. Pravidelný prehľad výstupov kľúčových AI nástrojov, ktoré firma používa, pomáha zachytiť problémy skôr.

Nie je to technická úloha. Je to manažérska zodpovednosť — rovnaká ako sledovanie kvality akéhokoľvek iného firemného procesu.

5. Zahrňte AI nástroje do svojho bezpečnostného hodnotenia

Ak vaša firma pravidelne robí hodnotenie kybernetických rizík — a ak podlieha NIS2, tak musí — AI nástroje by mali byť jeho súčasťou. Nie ako príloha, ale ako plnohodnotná časť. To znamená zmapovať, aké AI nástroje firma používa, aký majú prístup k dátam, aké sú ich zraniteľnosti a aké opatrenia sú zavedené.

Ak vaša firma hodnotenie kybernetických rizík doteraz nerobila, zavedenie AI nástrojov je dobrý dôvod začať.

6. Vzdelávajte zamestnancov aj o AI-špecifických hrozbách

Zamestnanci, ktorí vedia, čo je prompt injection, rozpoznajú nezvyčajné správanie chatbota skôr, ako spôsobí škodu. Zamestnanci, ktorí vedia, čo je model inversion, budú opatrnejší pri rozhodovaní, aké dáta použiť na tréning interných modelov. Povedomie je lacnejšia a účinnejšia obrana ako väčšina technických riešení.

Praktická poznámka: ak si z tohto článku odnesiete jedinú vec, nech je to toto — AI-špecifické hrozby nevyriešite len dobrým antivírusom. Vyriešite ich kombináciou správne nastavených oprávnení, ľudského dohľadu, starostlivého výberu dodávateľov a vzdelaných zamestnancov. Každý z týchto krokov sa dá urobiť bez veľkého rozpočtu. Vyžaduje len rozhodnutie.

Bezpečnosť AI nie je IT problém. Je to obchodné rozhodnutie.

Data poisoning, prompt injection, model inversion, model theft — štyri hrozby, o ktorých ste pred prečítaním tohto článku možno nepočuli. A ktoré váš antivírus nezachytí.

Nie preto, že by bol pokazený. Ale preto, že bol navrhnutý na iný svet — svet, v ktorom hrozby prichádzali cez škodlivý kód a podozrivé súbory. AI systémy vytvorili novú útočnú plochu, na ktorú klasické nástroje jednoducho nedosiahnu.

Dobrou správou je, že obrana proti týmto hrozbám nie je záležitosťou miliónovych investícií do bezpečnostných technológií. Je to záležitosť rozhodnutí — o tom, komu dáte prístup k svojim dátam, aké oprávnenia dostanú vaše AI nástroje, ako budete overovať ich výstupy a či budete vzdelávať svojich ľudí.

Firmy, ktoré tieto rozhodnutia urobia dnes, budú zajtra v podstatne lepšej pozícii — nielen z pohľadu bezpečnosti, ale aj z pohľadu regulačnej pripravenosti na AI Act a NIS2.

Tie, ktoré ich neurobian, sa o nich dozvedia inak. Z bezpečnostného incidentu. Z pokuty. Alebo z titulky.

Chcete vedieť, ako na to vo vašej firme konkrétne?

V Codamore pomáhame firmám posúdiť riziká spojené s AI nástrojmi — od bezpečnostného hodnotenia cez nastavenie oprávnení až po zmluvnú dokumentáciu a súlad s GDPR, NIS2 a AI Actom. Ak chcete vedieť, kde vaša firma stojí, radi si s vami sadneme.

→ Kontaktujte nás na office@codamore.sk alebo telefonicky.

Disclaimer

Tento článok má výlučne informačný a vzdelávací charakter. Nepredstavuje právne poradenstvo ani právnu analýzu v zmysle zákona č. 586/2003 Z.z. o advokácii. Informácie obsiahnuté v článku nie sú náhradou za individuálne právne poradenstvo zohľadňujúce konkrétnu situáciu vašej firmy.

Právna úprava v oblasti ochrany osobných údajov, kybernetickej bezpečnosti a umelej inteligencie sa dynamicky vyvíja. Obsah článku zodpovedá stavu právnych predpisov a dostupných informácií ku dňu jeho uverejnenia. Codamore s.r.o. nezodpovedá za prípadné zmeny legislatívy ani za rozhodnutia prijaté na základe informácií uvedených v tomto článku.

Ak potrebujete posúdiť konkrétnu situáciu vašej firmy, odporúčame vyhľadať odborné poradenstvo. Radi vám pomôžeme. 

Zdroje: Nariadenie (EÚ) 2016/679 (GDPR): https://eur-lex.europa.eu/legal-content/SK/TXT/?uri=CELEX%3A32016R0679 | Nariadenie (EÚ) 2024/1689 (AI Act): https://eur-lex.europa.eu/legal-content/SK/TXT/?uri=CELEX%3A32024R1689 | Zákon č. 69/2018 Z.z. o kybernetickej bezpečnosti: https://www.slov-lex.sk/pravne-predpisy/SK/ZZ/2018/69/ | Digital Omnibus — Rada EÚ, 7. mája 2026: https://www.consilium.europa.eu/en/press/press-releases/2026/05/07/artificial-intelligence-council-and-parliament-agree-to-simplify-and-streamline-rules/ | ISO/IEC 42001:2023: https://www.iso.org/standard/42001 | ISO/IEC 27001:2022: https://www.iso.org/standard/27001 | OWASP Top 10 for LLM Applications: https://owasp.org/www-project-top-10-for-large-language-model-applications/ | ENISA — AI Cybersecurity Threats (2024): https://www.enisa.europa.eu/topics/artificial-intelligence | Vercel Security Incident (apríl 2026): https://vercel.com/kb/bulletin/vercel-april-2026-security-incident | Codamore blog