Bezpečnostné riziká pri nasadení LLM do firemných procesov
Šesť rizík, ktoré nevznikajú z modelu, ale z architektúry okolo neho: únik dát, prompt injection, oddelenie prístupov, konanie agentov, halucinácie a audit.

Hlavné bezpečnostné riziká pri nasadení LLM do firemných procesov sú únik citlivých dát cez externé API, prompt injection útoky, neoprávnený prístup k informáciám cez nedostatočne oddelené dáta a nekontrolované konanie agentov v prepojených systémoch. Väčšina z nich nevzniká zo samotného modelu, ale z architektúry okolo neho: z toho, ako je model prepojený s firemnými dátami, akými nástrojmi disponuje a kto má prístup k jeho výstupom. Správne navrhnutá architektúra dokáže väčšinu rizík eliminovať už na úrovni návrhu, nie až dodatočnými záplatami.
Únik dát cez externé API
Ak firma posiela citlivé dáta do verejného API bez ďalších záruk, dáta opúšťajú kontrolované prostredie. Pri niektorých poskytovateľoch existuje riziko, že sa použijú na ďalšie trénovanie modelu alebo sa uložia dlhšie, než firma očakáva.
Riešenie. Enterprise zmluvy s garantovaným nespracovaním dát na trénovanie, prípadne on-premise alebo EU-hosted nasadenie pre najcitlivejšie použitia.
Prompt injection
Útočník vloží škodlivé inštrukcie priamo do vstupných dát, napríklad do e-mailu, dokumentu alebo webovej stránky, ktorú agent spracúva, aby systém odchýlil od pôvodného zadania: vyzradil interné informácie alebo vykonal neautorizovanú akciu.
Riešenie. Prísne oddelenie systémových inštrukcií od vstupných dát, validácia výstupov pred vykonaním akcií a obmedzenie právomocí agenta na minimum potrebné pre danú úlohu.
Nedostatočné oddelenie prístupových práv
Ak systém pracuje s dátami viacerých oddelení, klientov alebo úrovní citlivosti bez správneho filtrovania, používateľ s nižším oprávnením môže dostať odpoveď postavenú na dátach, ku ktorým nemal mať prístup.
Riešenie. Filtrovanie podľa metadát na úrovni vyhľadávania, nie až na úrovni aplikácie, a dôsledné testovanie izolácie pred nasadením. Ako to vyzerá pri viacerých klientoch v jednom systéme, rozoberá multi-tenant vektorová databáza.
Nekontrolované konanie agentov
Pri agentoch s prístupom k reálnym systémom — CRM, ERP, e-mail, platby — je chybné rozhodnutie reálnym rizikom: odoslanie nesprávnej informácie klientovi, chybná aktualizácia záznamu alebo akcia mimo zamýšľaného rozsahu.
Riešenie. Jasne definované hranice právomocí, povinné schválenie človekom pri citlivých akciách ako platby či zmluvné záväzky, a priebežný monitoring vykonaných akcií.
Halucinácie v kritických procesoch
Model môže vygenerovať fakticky nesprávnu odpoveď s vysokou mierou istoty. V procesoch ako compliance, právne poradenstvo alebo finančné rozhodnutia môže mať takáto chyba vážne dôsledky.
Riešenie. RAG architektúra s odkazom na overiteľný zdrojový dokument namiesto spoliehania sa na všeobecné znalosti modelu, plus jasné označenie, kedy je potrebná kontrola človekom.
Chýbajúci audit trail
Bez záznamu o tom, čo systém robil, na základe akých dát a prečo, je nemožné spätne vyšetriť incident alebo preukázať compliance pri kontrole.
Riešenie. Logovanie všetkých vstupov, výstupov a vykonaných akcií, uchovávané v súlade s internými a regulačnými požiadavkami.
Zhrnutie
| Riziko | Dôsledok | Riešenie |
|---|---|---|
| Únik dát cez externé API | Strata kontroly nad citlivými dátami | Enterprise zmluvy, on-premise alebo EU hosting |
| Prompt injection | Neautorizované akcie alebo únik informácií | Oddelenie inštrukcií od dát, validácia výstupov |
| Nedostatočné oddelenie prístupov | Prístup k dátam bez oprávnenia | Filtrovanie podľa metadát, testovanie izolácie |
| Nekontrolované konanie agenta | Chybné akcie v reálnych systémoch | Definované hranice, schválenie človekom |
| Halucinácie modelu | Rozhodnutia na základe vymyslených faktov | RAG s overiteľným zdrojom, kontrola človekom |
| Chýbajúci audit trail | Nemožnosť spätne vyšetriť incident | Kompletné logovanie akcií a rozhodnutí |
Ako k bezpečnosti pristupovať od návrhu
Bezpečnosť sa nepridáva po nasadení. Najefektívnejšie firmy riešia tieto riziká už vo fáze architektonického návrhu:
- Princíp najmenšieho oprávnenia – model alebo agent dostane prístup len k dátam a nástrojom, ktoré nevyhnutne potrebuje pre danú úlohu.
- Segmentácia podľa citlivosti – najcitlivejšie procesy môžu vyžadovať prísnejšie nasadenie než tie ostatné.
- Testovanie pred nasadením – simulácia útokov vrátane prompt injection a overenie izolácie dát ešte pred produkciou.
- Priebežný monitoring – bezpečnosť nie je jednorazová kontrola, ale súčasť prevádzky.
Väčšina incidentov pri AI systémoch nie je zlyhanie modelu. Je to zlyhanie oprávnení.
GDPR a EU AI Act
Pri nasadení v EÚ sa bezpečnostné riziká prelínajú s právnymi povinnosťami. GDPR vyžaduje jasné zdôvodnenie spracovania osobných údajov a možnosť preukázať, kde a ako sa dáta spracúvajú. EU AI Act zavádza dodatočné požiadavky na transparentnosť a riadenie rizika pri systémoch klasifikovaných ako vysoko rizikové, čo môže zahŕňať aj niektoré typy firemných agentov v citlivých odvetviach: zdravotníctvo, financie, rozhodovanie v personalistike.
Časté otázky
- Je bezpečnejšie použiť open-source model namiesto komerčného API?
- Nie automaticky. Bezpečnosť závisí viac od architektúry nasadenia, teda kde dáta bežia, kto má prístup a ako je systém monitorovaný, než od typu modelu. Open-source model nasadený nesprávne môže byť menej bezpečný než dobre nakonfigurované enterprise API.
- Dá sa prompt injection úplne zabrániť?
- Úplne nie, ale riziko sa dá výrazne znížiť dôsledným oddelením systémových inštrukcií od vstupných dát, validáciou výstupov pred vykonaním akcií a obmedzením právomocí agenta.
- Musí byť každé nasadenie LLM v EÚ firme on-premise?
- Nie, závisí to od citlivosti spracovávaných dát a od odvetvia. Pri bežných procesoch stačí enterprise API s garantovaným spracovaním dát v súlade s GDPR. On-premise alebo EU-hosted nasadenie je relevantné najmä pri vysoko citlivých dátach.
- Kto zodpovedá za chybu spôsobenú AI agentom?
- Zodpovednosť zostáva na firme, ktorá systém prevádzkuje. Preto je kľúčové mať jasne definované hranice právomocí agenta, ľudskú kontrolu pri citlivých rozhodnutiach a kompletný audit trail pre prípad spätného vyšetrovania.
Súvisiace články

Čo je RAG a ako funguje v enterprise chatbotoch
RAG vysvetlený pre firmy: ako model odpovedá z vašich dokumentov, kedy má zmysel oproti fine-tuningu a čo rozhoduje o kvalite nasadenia.
Čítať článok
Ako funguje multi-tenant vektorová databáza pre viacero klientov
Jedna AI infraštruktúra pre desiatky klientov bez toho, aby sa ich dáta premiešali: metadátové filtrovanie, architektonické rozhodnutia a bezpečnostné testy.
Čítať článok
Ako funguje AI automatizácia pre právne kancelárie
Revízia zmlúv, vyhľadávanie v precedensoch, compliance monitoring a due diligence — a prečo v právnom prostredí rozhoduje architektúra, nie samotný model.
Čítať článok
conusweb
conusweb