Interná AI smernica firmy: bezpečné používanie AI a AI Act

Bezpečné používanie AI vo firme neznamená nulové riziko. Znamená, že organizácia pozná svoje AI systémy a use cases, rozumie dátam, ktoré do nich vstupujú, vie, kto smie čo robiť, nastavila primerané technické a organizačné kontroly a dokáže riziko priebežne merať, znižovať a eskalovať.

Širšie súvislosti vysvetľuje sprievodca Umelá inteligencia v praxi: od financií po zefektívnenie výroby.

Rýchle zhrnutie pre manažérov

Generatívna umelá inteligencia vo firme je súčasne nástroj produktivity, informačný systém, externá služba, zdroj nových dátových tokov a pri agentných riešeniach aj potenciálny vykonávateľ reálnych akcií. Preto ju nemožno riadiť iba zákazom v pracovnom poriadku ani iba nákupom enterprise licencie. Bezpečný model potrebuje inventár používaných AI systémov, klasifikáciu dát, pravidlá pre schválené nástroje, use case approval, ľudský dohľad, bezpečnostnú architektúru, AI gramotnosť, auditnú stopu a incidentný proces.

AI Act je od roku 2026 praktická prevádzková téma. Zakázané praktiky a povinnosť prijímať opatrenia na rozvoj AI gramotnosti sa uplatňujú od 2. februára 2025. Transparentnostné povinnosti podľa článku 50 sa uplatňujú od 2. augusta 2026. Po zmenách prijatých v roku 2026 sa pravidlá pre vysokorizikové použitia z prílohy III uplatnia od 2. decembra 2027 a pravidlá pre vysokorizikové AI systémy integrované do regulovaných produktov od 2. augusta 2028. [1][2][3]

AI Act však nie je jediný predpis. Ak AI spracúva osobné údaje, vstupuje GDPR. Ak firma chráni know-how a obchodné tajomstvo, musí vedieť preukázať primerané kroky na zachovanie tajnosti. Ak patrí pod NIS2 alebo DORA, AI dodávateľ a AI integrácia sa stávajú aj súčasťou širšieho kybernetického a third party risk manažmentu. [4][5][6]

Interná AI smernica preto nemá byť statický dokument plný všeobecných zákazov. Má fungovať ako rozhodovací systém. Zamestnanec musí vedieť, ktoré nástroje sú schválené, aké dáta môže použiť, pri ktorých úlohách je potrebná kontrola človekom, ktoré use cases sú zakázané, čo sa musí pred nasadením schváliť a ako postupovať pri incidente alebo pochybnosti.

1. Čo presne znamená bezpečné používanie AI vo firme

Bezpečné používanie AI vo firme je riadený spôsob výberu, konfigurácie, používania, monitorovania a ukončovania AI systémov, pri ktorom organizácia pozná účel použitia, právny a bezpečnostný kontext, zdroje dát, používateľov, oprávnenia, limity automatizácie, riziká chybného výstupu a pravidlá ľudského dohľadu. Bezpečnosť sa musí posudzovať počas celého životného cyklu, od prvotného nápadu cez pilot a produkciu až po zmenu dodávateľa alebo ukončenie systému.

Táto definícia je širšia než kybernetická bezpečnosť. AI môže byť technicky dobre zabezpečená a stále sa používať nevhodným spôsobom. Príkladom je zamestnanec, ktorý cez schválený enterprise nástroj hodnotí uchádzačov podľa neoverených kritérií, alebo chatbot, ktorý správne chráni dáta, ale poskytuje nesprávne právne informácie zákazníkovi bez primeraného upozornenia a kontroly. Naopak, právne prípustný use case môže byť prevádzkovo nebezpečný, ak má agent príliš široké oprávnenia alebo neexistuje spôsob, ako zastaviť chybnú akciu.

1.1 Päť oblastí, ktoré musí governance chrániť

Prvou oblasťou sú ľudia a ich práva. AI môže ovplyvniť zamestnanca, zákazníka, uchádzača, pacienta, študenta alebo občana. Druhou sú dáta, vrátane osobných údajov, obchodného tajomstva, zmlúv, bezpečnostných informácií a know-how. Treťou sú rozhodnutia, najmä v HR, financiách, práve, zdravotníctve, pricingu alebo zákazníckej podpore. Štvrtou sú systémy a oprávnenia, napríklad CRM, ERP, DMS, API a účty. Piatou je reputácia a kontinuita, teda schopnosť firmy zachovať dôveru, dostupnosť a kontrolu nad dodávateľmi.

Dobrá interná smernica musí tieto oblasti prepájať. Nestačí mať privacy dokument zvlášť, kybernetickú smernicu zvlášť a AI školenie zvlášť, ak zamestnanec pri konkrétnom use case nevie, ako ich premeniť na jedno rozhodnutie.

2. Governance, compliance, security a etika nie sú to isté

AI governance je systém rozhodovacích právomocí, procesov, kontrol a zodpovedností, ktorými organizácia riadi AI počas celého životného cyklu. Compliance je podmnožina, ktorá rieši súlad s právnymi, regulačnými, zmluvnými a internými požiadavkami. Security chráni dôvernosť, integritu, dostupnosť a ďalšie bezpečnostné vlastnosti systému. Etika rieši hodnotové otázky, napríklad férovosť, primeranosť, dôsledky pre ľudí a situácie, ktoré môžu byť právne možné, ale organizačne neprijateľné.

Praktický problém vzniká, keď firma tieto vrstvy zamieňa. Právnik môže potvrdiť, že použitie nie je explicitne zakázané, ale security tím môže identifikovať neprimeraný prístup k dátam. IT môže potvrdiť technickú realizovateľnosť, ale business owner nevie preukázať hodnotu. Etická komisia môže pomenovať reputačné riziko aj tam, kde právny predpis neurčuje priamy zákaz. Governance vytvára miesto, kde sa tieto perspektívy spoja do jedného rozhodnutia.

AI governance nie je dokument. Je to prevádzkový systém rozhodovania o tom, ktoré AI použitia organizácia povoľuje, za akých podmienok ich prevádzkuje a kedy ich zastaví.

3. AI Act vo firme: rizikový prístup namiesto univerzálneho zákazu

AI Act rozlišuje povinnosti podľa typu systému, role organizácie a rizika konkrétneho použitia. Pre firmu je preto nepresné pýtať sa iba: „Týka sa nás AI Act?“ Správna otázka znie: Pri ktorom AI systéme a use case vystupujeme ako poskytovateľ, deployer alebo iný regulovaný subjekt, do akej kategórie použitie patrí a ktoré povinnosti sa naň už uplatňujú alebo začnú uplatňovať neskôr.

Najčastejšou rolou bežnej organizácie je deployer, teda subjekt, ktorý používa AI systém pod svojou autoritou v profesionálnom kontexte. Ak však firma vyvinie vlastný AI systém alebo si ho nechá vyvinúť a poskytuje ho pod vlastným menom, môže sa dostať do role poskytovateľa. Jedna firma preto môže byť pri internom copilotovi deployer a pri vlastnom zákazníckom AI produkte provider. Rozsah povinností sa musí posudzovať po systémoch, nie jednou nálepkou pre celú spoločnosť. [1]

3.1 Aktuálny harmonogram k septembru 2026

V praxi z toho vyplýva dôležitá zásada. Firma nemá odkladať governance do roku 2027. Niektoré povinnosti už platia, ďalšie sa pripravujú a technické alebo organizačné zmeny sa nedajú kvalitne zaviesť za niekoľko týždňov. Ak organizácia dnes testuje AI v HR, vzdelávaní alebo inom citlivom procese, mala by si vytvárať dokumentáciu, risk assessment, human oversight a auditnú stopu už počas pilotu.

4. Zakázané praktiky: čo musí interná smernica blokovať bez ohľadu na dodávateľa

Zakázané praktiky podľa článku 5 sa uplatňujú od 2. februára 2025. Interná politika ich má preložiť do konkrétnych firemných scenárov. Nestačí napísať, že firma rešpektuje AI Act. Zamestnanec musí vedieť, že určitý spôsob použitia je zakázaný aj vtedy, ak technicky funguje a ak ho konkrétny nástroj umožňuje. [1]

4.1 Manipulatívne a klamlivé použitia

AI Act zakazuje určité systémy využívajúce podprahové, účelovo manipulatívne alebo klamlivé techniky, ak významne narušia schopnosť osoby urobiť informované rozhodnutie a spôsobia alebo môžu spôsobiť významnú ujmu. Pre marketing a predaj to neznamená zákaz personalizácie alebo persvazívnej komunikácie ako takej. Znamená to však, že firma musí veľmi opatrne posudzovať AI mechanizmy, ktoré zneužívajú slabosti používateľa alebo obchádzajú jeho schopnosť slobodne rozhodovať.

4.2 Zneužívanie zraniteľnosti

Citlivé je najmä cielene zneužívať zraniteľnosť spojenú s vekom, zdravotným postihnutím alebo sociálnou či ekonomickou situáciou. Organizácia preto nemá hodnotiť riziko iba podľa toho, aké dáta spracúva, ale aj podľa toho, na koho systém pôsobí a aký typ behaviorálneho zásahu vykonáva.

4.3 Emócie na pracovisku

Osobitne dôležitý pre HR je zákaz používania systémov na odvodzovanie emócií fyzických osôb na pracovisku a vo vzdelávacích inštitúciách, s úzko vymedzenými výnimkami pre medicínske alebo bezpečnostné dôvody. Interná smernica má preto explicitne blokovať use cases typu „AI vyhodnotí z videa motiváciu kandidáta“ alebo „kamera meria náladu tímu“, kým právne posúdenie nepreukáže veľmi špecifickú prípustnú výnimku.

4.4 Biometrika a sociálne scoringové mechanizmy

Pri biometrických technológiách a sociálnom scoringu sú pravidlá podstatne citlivejšie než pri bežnom generovaní textu. Firmy by nemali tieto scenáre schvaľovať v štandardnom procese nákupu SaaS. Majú ísť do samostatného právneho, privacy, security a governance review, pretože technický názov funkcie nemusí používateľovi odhaliť jej regulačnú kvalifikáciu.

5. Vysokorizikové použitia: čo robiť ešte pred dátumom povinnej aplikácie

Po zmene harmonogramu sa pravidlá pre high risk use cases z prílohy III uplatnia od 2. decembra 2027. To však neznamená, že organizácia má do tohto dátumu používať citlivé systémy bez kontroly. Už dnes môžu byť dotknuté GDPR, pracovnoprávne pravidlá, antidiskriminačné predpisy, sektorová regulácia a interné bezpečnostné povinnosti. [2]

Prakticky má firma vytvoriť pre citlivé use cases predbežný high risk readiness režim. Ten obsahuje popis účelu, vlastníka, kategóriu osôb, zdroje dát, rozhodovací dopad, human oversight, požadovanú presnosť, logovanie, incidentný proces, vendor dokumentáciu a plán, ako sa use case zosúladí s pravidlami, keď začnú byť uplatniteľné.

5.1 HR a nábor ako typický príklad

Ak AI iba prepisuje formát životopisu alebo pomáha napísať neutrálny pracovný inzerát, rizikový profil je iný než pri automatizovanom screeningu kandidátov, scoringu výkonnosti alebo odporúčaní, kto má dostať výpoveď. Interná smernica preto nesmie označiť celé oddelenie HR ako „AI povolené“ alebo „AI zakázané“. Potrebuje rozlišovať konkrétne úlohy a rozhodovací dopad.

6. Transparentnosť od 2. augusta 2026: kedy musí človek vedieť, že komunikuje s AI

Článok 50 a usmernenia Európskej komisie vyžadujú pri priamom kontakte AI systému s fyzickou osobou informovať človeka, že komunikuje s AI, pokiaľ to nie je zrejmé z okolností. Informácia má byť poskytnutá jasne a rozlíšiteľne od začiatku prvej interakcie a musí rešpektovať požiadavky na prístupnosť. [3]

Pre firmu je dôležité, že povinnosť sa neobmedzuje na spotrebiteľské chatboty. Môže ísť aj o profesionálnych používateľov. Naopak, AI systém pracujúci iba na pozadí bez priamej komunikácie s človekom do tejto konkrétnej povinnosti nespadá. To však nevylučuje iné informačné povinnosti podľa GDPR alebo sektorovej regulácie.

6.1 Ako má vyzerať praktické oznámenie

Oznámenie má byť stručné, zrozumiteľné a neklamlivé. Používateľ má vedieť, že odpovedá AI systém, aký je približný účel interakcie a ako sa môže dostať k človeku, ak je to relevantné. Pri rizikovejšom procese môže byť potrebná rozsiahlejšia vrstva transparentnosti mimo samotného chatového bannera.

Interná smernica má určiť, kto schvaľuje text oznámenia, kde sa zobrazuje, ako sa dokumentuje jeho verzia a čo sa stane pri zmene modelu alebo spôsobu použitia. Transparentnosť nie je jednorazový grafický prvok, ale súčasť governance systému.

7. AI literacy: školenie musí byť podľa roly, nie rovnaké pre všetkých

Článok 4 AI Act vyžaduje od providerov a deployerov prijímať opatrenia na rozvoj AI gramotnosti ľudí, ktorí AI systémy používajú alebo s nimi pracujú v ich mene. Po úpravách z roku 2026 sa nevyžaduje jedna konkrétna „dostatočná“ úroveň pre každého. Komisia však odporúča vychádzať z technických znalostí, skúseností, vzdelania, kontextu použitia a rizík konkrétneho systému. [7]

Preto je univerzálne hodinové školenie všetkých zamestnancov slabým dôkazom governance. Účtovník, marketingový copywriter, HR recruiter, administrátor AI agenta a člen predstavenstva potrebujú odlišné kompetencie. Rozdiel je v type dát, oprávneniach, rozhodovacom dopade a schopnosti spôsobiť škodu.

7.1 Minimálne úrovne role based AI gramotnosti

E-E-A-T logika interného vzdelávania je podobná ako pri odbornom obsahu. Nestačí deklarovať expertízu. Organizácia potrebuje dôkaz, že ľudia rozumejú relevantným rizikám a vedia ich aplikovať na konkrétny pracovný scenár.

8. GDPR a generatívna AI: osobné údaje sa nesmú stratiť v technickom nadšení

AI Act nenahrádza GDPR. Ak AI systém spracúva osobné údaje, organizácia musí stále určiť účel, právny základ, rozsah údajov, dobu uchovávania, príjemcov, bezpečnostné opatrenia a práva dotknutých osôb. Pri niektorých prípadoch môže byť potrebné DPIA ešte pred spracúvaním. GDPR článok 35 výslovne vyžaduje posúdenie vplyvu, ak spracúvanie s využitím nových technológií pravdepodobne povedie k vysokému riziku pre práva a slobody ľudí. [4]

EDPB zároveň upozorňuje, že anonymitu AI modelu nemožno automaticky predpokladať a má sa hodnotiť prípad od prípadu. Pri legitímnom záujme sa musí vykonať test účelu, nevyhnutnosti a vyváženia. Tvrdenie „model dáta anonymizuje“ alebo „je to náš oprávnený záujem“ preto nesmie nahrádzať dokumentované právne posúdenie. [8]

8.1 Minimalizácia údajov pri promptoch a prílohách

Zamestnanec má do AI nástroja vkladať iba údaje potrebné na konkrétnu úlohu. Ak možno zmluvu analyzovať po odstránení osobných identifikátorov, je zbytočné posielať celý dokument s údajmi všetkých zmluvných strán. Ak možno podporu vyriešiť pomocou čísla objednávky získaného cez autorizovaný backend, chatbot nepotrebuje dostať kompletný profil zákazníka.

Minimalizácia musí byť technicky podporená. Smernica bez DLP, masking nástrojov, access controlu alebo bezpečného enterprise prostredia prenáša príliš veľkú zodpovednosť na jednotlivca. Pri rizikových dátach má systém obmedzovať možnosť chyby ešte pred odoslaním promptu.

8.2 DPIA a AI risk assessment nie sú to isté

DPIA hodnotí vplyv spracúvania osobných údajov na práva a slobody. AI risk assessment môže byť širší a zahŕňať bezpečnosť, kvalitu, bias, prevádzku, reputáciu, vendor lock in alebo finančný dopad. Pri komplexnom use case treba oba pohľady prepojiť, ale nezamieňať. Jeden dokument môže podporovať druhý, ak pokrýva povinné otázky, no názov „AI audit“ automaticky nesplní GDPR požiadavky.

9. Ochrana firemného know-how a obchodného tajomstva

Únik know-how je jeden z najväčších praktických dôvodov, prečo korporácie zavádzajú AI governance. Obchodné tajomstvo podľa smernice EÚ zahŕňa informácie, ktoré sú tajné, majú komerčnú hodnotu práve preto, že sú tajné, a osoba oprávnene kontrolujúca informáciu prijala primerané kroky na zachovanie tajnosti. [5]

Tretia podmienka je pre AI zásadná. Ak firma označuje stratégiu, zdrojový kód alebo cenotvorbu za obchodné tajomstvo, ale zamestnanci ich bez pravidiel kopírujú do verejných AI nástrojov, vzniká otázka, či boli prijaté primerané kroky na ochranu. Bezpečná AI smernica preto nie je iba compliance dokument, ale aj súčasť praktickej ochrany firemného know-how.

9.1 Čo má firma považovať za dôverné AI vstupy

Typicky ide o nepublikované cenové modely, marže, obchodné plány, akvizičné stratégie, zoznamy zákazníkov, neveľejné produktové roadmapy, bezpečnostnú architektúru, zdrojový kód, modely zmlúv, výskum a vývoj, interné metodiky a detailné procesné know-how. Konkrétny zoznam však musí vychádzať z reálnej klasifikácie informácií vo firme.

Pravidlo „nevkladajte citlivé údaje“ je nedostatočné, ak zamestnanec nevie, čo firma považuje za citlivé. Preto má smernica používať príklady z vlastného prostredia a odkazovať na konkrétnu dátovú klasifikáciu.

10. Klasifikácia dát pre AI: praktický rozhodovací model

Klasifikácia dát je most medzi informačnou bezpečnosťou a každodenným používaním AI. Najpraktickejší model používa niekoľko tried, ku ktorým je priradené pravidlo, v akom type AI prostredia možno údaje použiť. Nižšie uvedená matica je vzor. Musí sa prispôsobiť vlastným právnym, zmluvným a sektorovým povinnostiam.

10.1 Kontext môže zmeniť klasifikáciu

Samotný názov poľa nestačí. Jeden e-mail môže byť bežná interná informácia alebo obsahovať obchodné tajomstvo. Verejne dostupný dokument môže byť citlivý, ak sa spojí s neverejným zákazníckym profilom. Klasifikácia preto musí zohľadňovať obsah, kombináciu dát, účel a potenciálny dopad.

10.2 Pseudonymizácia nie je anonymizácia

Odstránenie mena a nahradenie identifikátora interným kódom nemusí znamenať anonymizáciu. Ak možno osobu znovu identifikovať pomocou ďalších údajov, stále ide o osobné údaje. Interná smernica má preto používať presné pojmy a neprezentovať jednoduché masking techniky ako automatické odstránenie GDPR povinností.

11. Schválené AI nástroje: prečo whitelist nestačí

Zoznam povolených aplikácií je základ, nie koniec vendor governance. Ten istý produkt môže mať odlišné podmienky v spotrebiteľskom účte, enterprise pláne alebo API. Rozdiel môže byť v použití dát na zlepšovanie modelov, retencii, logovaní, admin kontrole, SSO, DPA, subprocesoroch, lokalite spracúvania alebo možnostiach vypnúť konektory.

Firma preto schvaľuje konkrétny spôsob použitia služby, nie iba značku. Môže napríklad povoliť enterprise workspace pre interné dokumenty, ale zakázať rovnakú službu cez osobný účet. Môže povoliť API v izolovanej aplikácii, ale nie webové uploady citlivých príloh. Toto rozlíšenie má byť súčasťou živého registra schválených AI služieb.

11.1 Vendor due diligence

• Zmluvné role pri osobných údajoch, DPA a zodpovednosti zmluvných strán.
• Či sa customer content používa na tréning, zlepšovanie alebo iné sekundárne účely.
• Retencia, možnosti zníženej retencie a mazania.
• Subprocesori, medzinárodné prenosy a lokalita spracúvania.
• SSO, MFA, SCIM, role based access a admin audit logy.
• Encryption, tenant isolation, incident management a business continuity.
• Možnosť zakázať alebo obmedziť konektory, plugins, web access alebo tool use.
• SLA, limity služby, model change policy a oznamovanie významných zmien.
• Export dát, exit plán a vendor lock in.
• Dostupnosť security, privacy a AI governance dokumentácie potrebnej pre audit.

Pri finančných subjektoch DORA ide ešte ďalej a vyžaduje riadiť ICT third party risk ako súčasť ICT risk managementu, vrátane due diligence, registra zmlúv a kontroly kritických alebo dôležitých funkcií. [9]

12. Shadow AI: riziko, ktoré nevyrieši zákaz bez alternatívy

Shadow AI vzniká, keď zamestnanci používajú AI nástroje mimo schváleného prostredia. Môže ísť o osobný chatbot, browser extension, meeting transcription, prekladač, AI funkciu v existujúcom SaaS alebo lokálny model. Organizácia často ani nevie, že dátový tok vznikol, pretože nástroj neprešiel procurementom ani IT integráciou.

Čistý zákaz bez dostupnej bezpečnej alternatívy má slabú účinnosť. Ľudia používajú AI preto, že im rieši reálnu potrebu. Governance musí túto potrebu pochopiť, poskytnúť bezpečnú cestu a mať jednoduchý proces na posúdenie nového nástroja. Cieľom je dostať experimentovanie do viditeľného a riadeného prostredia, nie ho vytlačiť do súkromných účtov.

12.1 Ako zistiť reálny stav shadow AI

Prvým krokom je nepostihujúci discovery prieskum. Organizácia potrebuje vedieť, ktoré nástroje ľudia už používajú, na aké úlohy, s akými dátami a aký prínos z nich majú. Trestajúci prístup v prvej fáze znižuje kvalitu informácií. Až po zmapovaní reality možno nastaviť whitelist, technické blokácie, DLP pravidlá a proces výnimiek.

Druhým krokom je kontrola existujúcich SaaS platforiem. Mnohé produkty získali generatívne AI funkcie bez samostatného procurementu. Firma môže mať AI v CRM, e-maili, office suite alebo customer support systéme aj vtedy, keď žiadny samostatný „AI projekt“ neschválila.

13. Interná AI smernica: štruktúra, ktorá je použiteľná v praxi

Interná smernica má mať dve vrstvy. Prvá je normatívna a stabilná, teda účel, princípy, role, kategórie použití, dátové pravidlá a schvaľovanie. Druhá je operatívna a živá, napríklad register schválených nástrojov, kontaktné osoby, výnimky, konkrétne technické konfigurácie a zoznam aktuálnych use caseov. Tým sa zabráni tomu, aby každá zmena dodávateľa vyžadovala formálnu novelu celého dokumentu.

13.1 Povinné kapitoly smernice

13.2 Smernica musí obsahovať príklady

Zamestnanec sa rozhoduje podľa situácií, nie podľa abstraktných definícií. Smernica má preto obsahovať príklady typu: „môžem vložiť verejný text konkurenta do schváleného nástroja na sumarizáciu“, „nemôžem vložiť neveľejnú zákaznícku zmluvu do osobného AI účtu“, „pri analýze kandidáta možno použiť AI na zhrnutie explicitných faktov, ale nie na odvodenie osobnostných alebo citlivých charakteristík bez samostatného schválenia“.

14. Rozhodovací model: povolené, podmienené a zakázané use cases

Jedným z najpraktickejších nástrojov je trojúrovňová klasifikácia use caseov. Namiesto otázky „smie sa používať AI?“ firma rozhoduje podľa rizika konkrétnej úlohy. Tento model je jednoduchý pre zamestnanca a zároveň umožňuje compliance tímu pridať jemnejšie pravidlá v approval procese.

14.1 Riziko sa neposudzuje iba podľa dát

Použitie verejných dát môže byť stále vysoko rizikové, ak AI vykonáva dôležité rozhodnutie o človeku. Naopak, dôverný interný dokument môže byť spracovaný relatívne bezpečne v izolovanom schválenom prostredí na nízkorizikovú sumarizáciu. Risk classification preto musí kombinovať citlivosť dát, typ rozhodnutia, autonómiu, počet dotknutých osôb, reverzibilitu, pravdepodobnosť chyby a maximálny dopad.

15. Human oversight: človek nemá byť iba formálny podpis

Human oversight je účinný iba vtedy, keď má človek reálnu schopnosť chybu rozpoznať a rozhodnutie zmeniť. Ak systém vytvára tisíce výstupov, ktoré pracovník nestíha skontrolovať, formálna požiadavka „človek má posledné slovo“ nemusí znižovať riziko. Organizácia musí navrhnúť kontrolu podľa objemu, zložitosti a následkov chyby.

15.1 Štyri režimy kontroly

15.2 Automation bias

Ľudia majú tendenciu veriť presvedčivo formulovaným výstupom, najmä ak systém dlhodobo funguje dobre. Preto samotné tlačidlo „schváliť“ nie je dostatočný dohľad. Review proces má zobrazovať zdroje, neistotu, kritické údaje a dôvody, prečo sa prípad dostal na ľudskú kontrolu. Školenie musí učiť, kedy AI spochybniť, nie iba ako ju používať.

16. Prompt injection a agentné AI: keď model môže vykonať reálnu akciu

Pri bežnom chatbote môže zlý prompt vytvoriť zlú odpoveď. Pri agentovi napojenom na e-mail, CRM, súbory alebo backend môže zlý vstup vyvolať nežiadanú akciu. Prompt injection vzniká vtedy, keď nedôveryhodný externý obsah obsahuje pokyny navrhnuté tak, aby model ignoroval svoje pravidlá alebo vykonal inú úlohu, než používateľ zamýšľal.

Bezpečnosť nemôže stáť na jednej systémovej vete. Potrebuje architektúru least privilege, oddelenie dôveryhodných inštrukcií od externého obsahu, serverovú validáciu nástrojov, allowlist operácií, potvrdenie významných akcií, auditné logy a testovanie adversarial scenárov. ENISA aj NIST pri AI riziku zdôrazňujú potrebu AI špecifických kontrol nad rámec tradičnej IT bezpečnosti. [10][11]

16.1 Tool permissions

Model nesmie dostať širšie oprávnenia, než potrebuje na konkrétnu úlohu. Ak support asistent potrebuje iba čítať stav objednávky, nemá mať automaticky právo meniť adresu, refundovať platbu alebo exportovať celý zákaznícky dataset. Každý write nástroj potrebuje autorizáciu a deterministické business rules mimo samotného promptu.

16.2 Secrets a autentifikačné údaje

API kľúče, heslá, privátne tokeny a iné tajomstvá nemajú byť súčasťou promptu ani znalostnej bázy. Musia zostať v secret managemente a backendovej vrstve. Model môže požiadať o povolenú funkciu, ale nemá potrebovať poznať samotné tajomstvo, ktorým sa systém autentifikuje.

17. Technické kontroly, ktoré má interná smernica podporovať

Najlepšia smernica je slabá, ak technické prostredie umožňuje každému obísť pravidlá bez viditeľnosti. Kontroly majú byť proporcionálne. Malá firma nebude implementovať rovnakú architektúru ako banka, ale základné princípy sú podobné: identita, least privilege, ochrana dát, auditovateľnosť, bezpečný lifecycle a možnosť rýchlo obmedziť poškodenie.

18. Incident management pre AI: čo robiť pri úniku alebo chybnom správaní

AI incident nemusí byť iba kybernetický útok. Môže ísť o odoslanie dôverného dokumentu do neschváleného nástroja, systematickú halucináciu zákazníckeho chatbota, prompt injection, nežiadaný tool call, diskriminačný vzorec, únik osobných údajov alebo zmenu modelu, ktorá zhorší kvalitu. Interný incident proces musí preto obsahovať AI špecifické kategórie.

18.1 Minimálny incidentný postup

• Identifikácia: čo sa stalo, ktorý systém, verzia, používateľ a dáta sú dotknuté.
• Containment: obmedziť prístup, vypnúť konektor, tool call, účet alebo konkrétny use case.
• Evidence preservation: uchovať relevantné logy, prompt, výstup, konfiguráciu a časovú os bez zbytočného rozširovania osobných údajov.
• Impact assessment: posúdiť privacy, security, právny, obchodný, reputačný a ľudský dopad.
• Notification: určiť, či vzniká oznamovacia povinnosť podľa GDPR, NIS2, DORA, zmluvy alebo iného režimu.
• Remediation: opraviť proces, prompt, model, oprávnenia, dokumentáciu alebo školenie.
• Lessons learned: aktualizovať risk register, evaly a smernicu, aby sa incident neopakoval.

Incidentný proces musí byť prepojený s existujúcim security a privacy incident managementom. Vytvárať úplne paralelnú AI incident organizáciu bez väzby na CISO, DPO alebo business continuity spravidla zvyšuje chaos.

19. Monitoring, evaly a zmeny modelov

Produkčný AI systém sa môže zmeniť aj bez zmeny firemného kódu. Dodávateľ môže aktualizovať model, bezpečnostné pravidlá alebo správanie služby. Znalostná báza sa mení, pribúdajú integrácie a používatelia objavujú nové spôsoby použitia. Preto sa AI risk assessment nemôže vykonať raz pri nákupe a považovať za uzavretý.

Organizácia potrebuje eval set reprezentatívnych prípadov, risk based monitoring a change management. Pred významnou zmenou modelu, promptu, retrievalu, nástrojov alebo dátovej vrstvy má prebehnúť regresné testovanie. Pri high impact use case sa má opakovať aj právne a bezpečnostné posúdenie, ak sa zmení účel alebo profil rizika.

19.1 Čo merať

20. NIS2 a AI: AI je ďalší informačný systém v kybernetickom riziku

NIS2 vyžaduje od dotknutých subjektov risk based kybernetické opatrenia vrátane analýzy rizík, incident handlingu, business continuity, supply chain security, bezpečného vývoja a údržby systémov, hodnotenia účinnosti opatrení, cyber hygiene, školení, kryptografie a riadenia prístupov. Ak AI systém podporuje kritickú alebo významnú službu, jeho riziká majú byť súčasťou tohto rámca. [6]

To znamená, že AI governance nemá byť oddelená od asset managementu. Organizácia potrebuje vedieť, ktoré AI aplikácie majú prístup k sieti, dátam a kritickým funkciám, kto ich prevádzkuje, aké majú závislosti a ako sa obnovia pri výpadku dodávateľa.

21. DORA a finančný sektor: AI vendor je aj ICT third party risk

Pre finančné subjekty je DORA samostatná významná vrstva. Nariadenie vyžaduje integrovať ICT third party risk do celkového ICT risk managementu. Organizácia zostáva zodpovedná aj vtedy, keď službu outsourcuje. Pred uzatvorením zmluvy musí pri relevantných službách identifikovať riziká, vykonať due diligence, posúdiť kritickosť a udržiavať register zmluvných vzťahov. [9]

Pri AI to má praktický dôsledok. Otázka „je model presný?“ nestačí. Banka alebo finančná inštitúcia potrebuje posúdiť kontinuitu, koncentráciu dodávateľa, subprocesorov, exit strategy, audit rights, bezpečnostné štandardy a dopad výpadku AI služby na kritickú alebo dôležitú funkciu.

22. ISO/IEC 42001 a NIST AI RMF: ako z interných pravidiel vytvoriť systém

ISO/IEC 42001:2023 stanovuje požiadavky na vytvorenie, implementáciu, udržiavanie a neustále zlepšovanie systému manažérstva AI. Je vhodná pre organizácie, ktoré chcú prejsť od jednotlivých pravidiel k opakovateľnému management systému s politikou, cieľmi, zodpovednosťami, risk managementom, dokumentáciou a zlepšovaním. [12]

NIST AI RMF je dobrovoľný rámec, ktorý organizuje AI risk management do funkcií Govern, Map, Measure a Manage. Generative AI Profile dopĺňa riziká špecifické pre generatívne systémy. Pre európsku firmu NIST nenahrádza AI Act ani GDPR, ale môže byť veľmi užitočným technickým a prevádzkovým rámcom na operacionalizáciu rizika. [11]

22.1 Praktické mapovanie

23. RACI: kto má za bezpečné AI reálne zodpovedať

AI governance zlyháva, keď je „vlastníkom AI“ abstraktné oddelenie. Každý use case potrebuje business ownera, technického ownera a jasné kontrolné role. Právnik nemá vlastniť business výsledok a IT nemá samo rozhodovať o etickej primeranosti. RACI pomáha rozdeliť zodpovednosť bez rozmazania accountability.

V menšej organizácii môže jedna osoba zastávať viac rolí. Dôležité je zachovať funkcie, nie nevyhnutne počet pracovných miest. Pri kritických rozhodnutiach však treba riešiť konflikt záujmov, napríklad keď ten istý človek systém vyvíja, schvaľuje jeho bezpečnosť aj hodnotí výsledok auditu.

24. Use case approval: čo musí prejsť pred pilotom

Schvaľovací formulár nemá byť administratívna prekážka, ale krátky dôkazový záznam, že firma vie, čo ide robiť. Pri nízkorizikovom use case môže mať jednu stranu. Pri high impact riešení môže prerásť do plného risk assessmentu, DPIA alebo compliance dokumentácie.

25. Praktické pravidlá pre zamestnanca pri generatívnej AI

Interná smernica má byť doplnená krátkym používateľským kódexom. Jeho úlohou nie je vysvetliť celú legislatívu, ale umožniť správne rozhodnutie počas bežnej práce.

• Používaj iba schválený firemný účet alebo aplikáciu pre pracovné úlohy.
• Pred vložením textu alebo súboru urči jeho dátovú klasifikáciu.
• Nevkladaj heslá, API kľúče, autentifikačné tokeny alebo iné tajomstvá.
• Pri osobných údajoch používaj iba schválený use case a minimálny potrebný rozsah údajov.
• Pred externým použitím over faktické tvrdenia, čísla, zdroje a citlivé formulácie.
• AI výstup nevydávaj automaticky za právne, medicínske, finančné alebo personálne rozhodnutie.
• Ak nástroj pracuje s firemným backendom, neobchádzaj approval gate ani oprávnenia.
• Pri nečakanom správaní, úniku, podozrivom prompt injection alebo chybnej akcii incident okamžite nahlás.
• Nepredpokladaj, že „enterprise“ automaticky znamená povolenie pre všetky dáta a use cases.
• Pri pochybnosti radšej zastav proces a požiadaj o schválenie, než aby si vytvoril nevratný problém.

26. Implementácia AI vo firme: 180 dňový governance plán

Bezpečná implementácia nemusí začínať masívnym programom. Dôležité je správne poradie. Najprv treba zistiť realitu, potom definovať pravidlá a až následne zvyšovať autonómiu a integrácie. Nasledujúci plán je orientačný a musí sa prispôsobiť veľkosti a regulovanosti organizácie.

26.1 Prvých 30 dní: získať kontrolu nad realitou

• vymenovať governance ownera a pracovnú skupinu
• zmapovať používané AI nástroje a shadow AI
• identifikovať zakázané a vysokorizikové scenáre
• zaviesť dočasné pravidlá pre citlivé dáta
• vybrať jeden bezpečný firemný nástroj pre bežné nízkorizikové použitie
• spustiť základné role based školenie pre najaktívnejších používateľov

26.2 Dni 31 až 60: vytvoriť riadiaci systém

• schváliť internú AI smernicu
• zaviesť AI inventory a use case register
• prepojiť dátovú klasifikáciu s AI pravidlami
• definovať vendor due diligence a approval workflow
• pripraviť incidentný proces a kontaktné body
• zaviesť minimálny eval a monitoring štandard pre produkčné AI riešenia

26.3 Dni 61 až 90: pilotovať pod kontrolou

• vybrať 2 až 4 use cases s jasným business prínosom a zvládnuteľným rizikom
• urobiť risk assessment a podľa potreby DPIA alebo právne review
• nastaviť human oversight, logovanie a stop kritériá
• zmerať baseline a pilotné KPI
• testovať prompt injection, chybné vstupy a failure modes, nielen ideálne scenáre

26.4 Dni 91 až 180: škálovať len preukázané riešenia

Po pilote sa nemá škálovať technológia, ale use case, ktorý preukázal hodnotu a kontrolovateľné riziko. Organizácia rozšíri iba riešenia, ktoré prešli evalmi, majú vlastníka, dokumentované oprávnenia, monitoring a incidentný proces. Zlyhané alebo marginálne use cases sa zastavia bez sunk cost argumentu.

27. Interný audit bezpečného používania AI

Audit nemá kontrolovať iba existenciu smernice. Musí overiť, či kontrolné mechanizmy reálne fungujú. Papierová politika bez inventára, logov, školení a enforcementu vytvára falošný pocit bezpečnosti.

• Existuje úplný a aktuálny inventár používaných AI systémov a use caseov?
• Je pri každom use case určený business owner a technický owner?
• Sú zakázané praktiky explicitne blokované v smernici a procurement procese?
• Je dátová klasifikácia prepojená s konkrétnymi AI prostrediami?
• Sú osobné údaje pokryté právnym základom, minimizáciou a prípadne DPIA?
• Majú používatelia role based AI literacy a existuje dôkaz o jej absolvovaní?
• Prešli vendori privacy, security a zmluvným review?
• Sú tool permissions, konektory a write operácie obmedzené podľa least privilege?
• Existuje eval set, monitoring a change management pre produkčné systémy?
• Vie organizácia zastaviť use case a zachovať dôkazy pri incidente?
• Je transparentnosť voči používateľom implementovaná tam, kde sa uplatňuje článok 50?
• Je AI governance integrovaná s NIS2, DORA, ISO 27001, risk managementom alebo interným auditom tam, kde sú relevantné?

28. Najčastejšie chyby firemnej AI governance

• Firma vytvorí smernicu, ale nemá inventár reálne používaných AI nástrojov.
• Zakáže všetku AI a tým presunie používanie do osobných účtov a shadow AI.
• Povolí enterprise nástroj bez rozlíšenia, aké dátové triedy a use cases sú v ňom prípustné.
• Predpokladá, že AI Act nahrádza GDPR alebo sektorové povinnosti.
• AI literacy rieši jedným všeobecným školením bez role based rizík.
• Human oversight znamená iba formálne kliknutie na schválenie bez dostatočných informácií.
• Agent dostane široké write oprávnenia, pretože „model vie, čo robí“.
• Vendor due diligence sa zúži na otázku, či dodávateľ má ISO certifikát.
• Firma nemá evaly a po zmene modelu nevie, či sa systém zhoršil.
• Incidentný proces nepokrýva halucinácie, prompt injection a chybné tool calls.
• Citlivé know-how sa chráni zmluvou o mlčanlivosti, ale nie technickými a organizačnými krokmi pri AI používaní.
• AI policy je plná zákazov, ale zamestnanec nevie, akú bezpečnú alternatívu má použiť.

29. FAQ

Čo znamená bezpečné používanie AI vo firme?

Je to riadený spôsob používania AI, pri ktorom firma pozná systémy, use cases, dáta, používateľov, oprávnenia, riziká, human oversight a technické kontroly a priebežne ich monitoruje. Bezpečnosť neznamená nulové riziko, ale preukázateľné riadenie rizika.

Musí mať každá firma internú AI smernicu?

AI Act nepomenúva univerzálnu povinnosť mať dokument s názvom interná AI smernica pre každú firmu. V praxi však provider alebo deployer potrebuje opatrenia, ktorými plní povinnosti a riadi riziko. Interná smernica je jeden z najpraktickejších spôsobov, ako pravidlá zjednotiť a preukázať.

Čo už z AI Actu platí v septembri 2026?

Zakázané praktiky a povinnosť prijímať opatrenia na rozvoj AI gramotnosti sa uplatňujú od 2. februára 2025. Transparentnostné povinnosti článku 50 sa uplatňujú od 2. augusta 2026. Časť high risk pravidiel má po zmene harmonogramu neskorší termín.

Je používanie ChatGPT alebo iného generatívneho AI nástroja vo firme zakázané?

Nie všeobecne. Rozhoduje konkrétny use case, dáta, konfigurácia, zmluvné podmienky, právny kontext a riziko. Rovnaký nástroj môže byť povolený na verejný brainstorming a zakázaný na spracúvanie prísne chránených údajov.

Môžu zamestnanci vkladať firemné dokumenty do AI?

Iba ak to povoľuje dátová klasifikácia, interná smernica a konkrétne schválené AI prostredie. Pri dôverných dokumentoch musí firma poznať zmluvné, privacy, security a retention podmienky.

Stačí anonymizovať meno zákazníka?

Nie automaticky. Odstránenie mena môže byť iba pseudonymizácia, ak je osobu možné znovu identifikovať z ďalších údajov. Rozsah a metóda sa musia posudzovať podľa konkrétneho datasetu a účelu.

Čo je shadow AI?

Používanie AI nástrojov mimo schváleného firemného procesu alebo infraštruktúry. Môže zahŕňať osobné chatbot účty, browser extensions, meeting boty alebo AI funkcie v SaaS, o ktorých firma nevie.

Čo je AI literacy podľa AI Actu?

Súbor znalostí a kompetencií potrebných na informované používanie AI v konkrétnom kontexte. Organizácia má prijať opatrenia podľa rolí, skúseností, typu systémov a rizík, nie iba absolvovať jednorazové všeobecné školenie.

Musí chatbot oznámiť, že je AI?

Ak AI systém priamo komunikuje s fyzickou osobou, článok 50 vo všeobecnosti vyžaduje informovanie od začiatku prvej interakcie, pokiaľ nie je z okolností zrejmé, že ide o AI. Konkrétny prípad treba posúdiť podľa usmernení a výnimiek.

Ako chrániť obchodné tajomstvo pri AI?

Kombináciou dátovej klasifikácie, schválených nástrojov, zmluvných kontrol, access controlu, DLP, role based školení, incidentného procesu a preukázateľných primeraných krokov na zachovanie tajnosti.

Je ISO/IEC 42001 povinná?

Nie všeobecne. Je to medzinárodný štandard systému manažérstva AI. Organizácii môže pomôcť systematizovať governance, riziká, dokumentáciu a zlepšovanie, ale nenahrádza právne povinnosti AI Actu, GDPR alebo sektorovej regulácie.

Ako začať implementáciu AI vo firme bezpečne?

Najprv zmapovať existujúce AI používanie, vytvoriť inventár, definovať zakázané a podmienené use cases, schváliť dátové a vendor pravidlá, zaviesť role based AI literacy a až potom škálovať piloty s evalmi, monitoringom a human oversight.

30. Záver: bezpečná AI nie je brzda inovácie, ale podmienka škálovania

Firma môže experimentovať s AI rýchlo, ale nemôže škálovať bezpečne bez toho, aby poznala svoje systémy, dáta, oprávnenia a riziká. Čím viac AI preniká do CRM, dokumentov, HR, zákazníckej podpory, rozhodovania a agentných workflowov, tým menej stačí individuálna opatrnosť používateľa. Riziko sa musí presunúť do architektúry, governance a kontrol organizácie.

AI Act dáva európskym firmám právny rámec, ale dobrá governance ide ďalej. Prepája AI Act s GDPR, ochranou know-how, kybernetickou bezpečnosťou, third party riskom, NIS2, DORA a interným risk appetite. Výsledkom nie je zákaz AI, ale presnejšie rozhodovanie o tom, kde AI používať, s akými dátami, s akou mierou autonómie a s akou kontrolou.

Najsilnejšia interná smernica je tá, ktorá ľuďom umožní bezpečne pracovať. Zamestnanec vie, čo smie, čo musí overiť, čo sa musí schváliť a kedy má systém zastaviť. Vedenie vie, kto nesie zodpovednosť. Security vie, čo monitorovať. Právny a privacy tím majú dôkazy. A firma môže AI škálovať bez toho, aby s každým novým use case nekontrolovane rástlo riziko úniku know-how, nesprávneho rozhodnutia alebo regulačného problému.

Odborné zdroje

• [1] Európska únia. Nariadenie (EÚ) 2024/1689, AI Act, najmä články 4 a 5. EUR-Lex. https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng
• [2] Európska komisia. AI Act, regulatory framework a aktuálny harmonogram po AI Omnibus, aktualizované 2026. https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai
• [3] Európska komisia. Guidelines on transparency obligations under Article 50 a Q&A, júl 2026. https://digital-strategy.ec.europa.eu/en/library/guidelines-transparency-obligations-providers-and-deployers-ai-systems
• [4] Európska únia. GDPR, Nariadenie (EÚ) 2016/679, najmä článok 35. EUR-Lex. https://eur-lex.europa.eu/eli/reg/2016/679/oj
• [5] Európska únia. Smernica (EÚ) 2016/943 o ochrane obchodného tajomstva, najmä definícia primeraných krokov na zachovanie tajnosti. https://eur-lex.europa.eu/legal-content/en/TXT/?uri=CELEX:32016L0943
• [6] Európska únia. Smernica (EÚ) 2022/2555, NIS2, kybernetické risk management opatrenia. https://eur-lex.europa.eu/eli/dir/2022/2555
• [7] Európska komisia. AI Literacy, Questions & Answers, aktualizované 2026. https://digital-strategy.ec.europa.eu/en/faqs/ai-literacy-questions-answers
• [8] European Data Protection Board. Opinion 28/2024 on data protection aspects related to AI models. https://www.edpb.europa.eu/documents/opinion-of-the-board-art-64/opinion-282024-on-certain-data-protection-aspects-related-to_en
• [9] Európska únia. Nariadenie (EÚ) 2022/2554, DORA, ICT risk a third party risk. https://eur-lex.europa.eu/eli/reg/2022/2554/oj
• [10] ENISA. Multilayer Framework for Good Cybersecurity Practices for AI. 2023. https://www.enisa.europa.eu/publications/multilayer-framework-for-good-cybersecurity-practices-for-ai
• [11] NIST. AI Risk Management Framework a Generative AI Profile NIST AI 600-1, aktualizované zdroje 2026. https://www.nist.gov/itl/ai-risk-management-framework
• [12] ISO. ISO/IEC 42001:2023, Artificial intelligence management systems. https://www.iso.org/standard/42001