Co je zabezpečení LLM? Jak zmírnit 10 hlavních bezpečnostních rizik podle OWASP

Prompt injection – útok, který přiměje AI považovat pokyny útočníka za příkazy – je od roku 2023 v každém vydání na 1. místě žebříčku OWASP Top 10 for LLM Applications.

Tento seznam má ke shodě odborníků asi nejblíže ze všeho, co v oblasti bezpečnosti AI existuje. Projekt začínal jako malá skupina bezpečnostních profesionálů a dnes se opírá o více než 600 přispívajících expertů z více než 18 zemí.

Jsme společnost zabývající se AI a vydáváme průvodce tím, jak se AI dá k různým věcem přemluvit, takže nebudeme předstírat, že je problém vyřešený. Wilson, který projekt OWASP spoluvede, se k současným obranným mechanismům vyjádřil docela jasně: „...upřímně si nemyslím, že jsme na 99 %.“

Vydání z roku 2026 začíná ve stejném duchu. Vedoucí projektu nám radí, abychom „se přestali snažit postavit model, který nelze oklamat“, a navrhli okolní systém tak, aby oklamaný model nemohl rozbít nic důležitého.

Tento přístup uplatníme na všech 10 rizik ze seznamu OWASP pro rok 2026.

Co znamená bezpečnost LLM?

Bezpečnost LLM znamená chránit modely AI a aplikace, které je používají, před útoky a zneužitím. Riziko roste s tím, k čemu je model připojen: se soubory a daty, která může číst, a s nástroji, které může používat, jako je e-mail, vyhledávání nebo firemní databáze.

Ve správně zabezpečeném softwaru existuje pevná hranice mezi pokyny, kterými se program řídí, a informacemi, které zpracovává. LLM ale takovou hranici nemají.

Vše, co model čte, k němu přichází jako jeden dlouhý proud textu: pokyny vývojáře, váš dotaz, webová stránka, kterou vyhledal. Modely AI mají rozlišovat, kdo právě mluví – zda vývojář, uživatel, nebo sám model, když promýšlí problém.

Výzkumníci Jasmine Cui a Charles Ye však zjistili, že modely většinou odhadují, kdo mluví, podle toho, jak text zní. Pokud tedy útočník napíše něco, co zní jako vlastní uvažování modelu, model může uvěřit, že na ten nápad přišel sám. To je problém pro jakékoli bezpečnostní uspořádání, které spoléhá na to, že model ví, kdo má hlavní slovo.

Na stejný problém jsme narazili i u našich vlastních agentů AI. Náš CISO Kyle Polley řekl serveru ISMG, že agenti „nemusí dodržovat zásady, ani když je přidáte do systémového promptu“. Proto jsme vytvořili Numbat, open-source nástroj, který kontroluje, co se agent chystá udělat, a dokáže akci zablokovat, pokud porušuje nastavené bezpečnostní pravidlo.

Bezpečnost LLM znamená smířit se s tím, že model bude občas přijímat příkazy od nesprávné osoby, a obklopit ho ochrannými mantinely AI, které obstojí i tehdy, když se to stane.

Jaké jsou osvědčené postupy pro bezpečnost LLM?

Projdeme OWASP Top 10 for LLM Applications 2026 postupně, od 1. do 10. místa.

U každého rizika najdete srozumitelné vysvětlení, co se může pokazit, a příklad z praxe. Poté se podíváme na postupy, které mu mohou pomoci předejít, nebo alespoň omezit škody.

1. Udržte prompt injection pod kontrolou

K prompt injection dochází, když útočník přiměje AI plnit pokyny, které by plnit neměla. Tyto pokyny mohou přijít přímo v chatu, nebo mohou být podstrčeny v e-mailu, na webové stránce či v dokumentu.

Druhý typ se označuje jako nepřímá prompt injection. Požádáte svého asistenta, aby shrnul dokument. Jeho autor v něm ale asistentovi nařídil, aby mu poslal vaše soukromé soubory. Pokud asistent tyto pokyny splní, autor dokumentu si fakticky vypůjčil váš přístup.

PCMag přirovnává zabezpečení promptů k ucpávání děr v porézním kameni. Utěsníte jeden otvor a voda si najde jiný. „Útok si najde cestu; ta se opraví, ale nespočet dalších cest útoku teprve čeká na objevení, jednoduše kvůli tomu, jak dynamické systémy typu LLM jsou.“

Příklad: V červnu 2025 objevili výzkumníci ze společnosti Aim Security EchoLeak, chybu, která přiměla Microsoft 365 Copilot vyzradit soukromé firemní informace. Když zaměstnanec položil běžný pracovní dotaz, Copilot mohl načíst e-mail, provést v něm skryté pokyny a odeslat citlivé informace útočníkovi. Útok obešel kontroly, které měly zachytávat škodlivé pokyny a odstraňovat podezřelé odkazy.

Co můžete udělat:

• Řiďte se „pravidlem dvou“ společnosti Meta: EchoLeak potřeboval AI, která dokáže číst firemní data, číst externí e-maily a odesílat informace ven – a ta měla všechny tři schopnosti. Omezení na dvě z nich zabrání tomu, aby prompt injection získala příliš velkou kontrolu. Pokud úloha vyžaduje všechny tři, vyžadujte před každou akcí schválení člověkem.
• Testujte proti útočníkům, kteří znají vaši obranu: Předejte bezpečnostním testerům pravidla a filtry, které jste zavedli, a nechte je hledat způsoby, jak je obejít. V jedné studii uspěli útočníci, kteří se přizpůsobili obraně, ve více než 90 % případů proti většině z 12 testovaných obranných mechanismů.

2. Zabraňte únikům citlivých informací

Když systémy AI poskytnou soukromé informace lidem, kteří je vidět nemají, hovoříme o úniku citlivých informací. Může jít o prozrazení platebních údajů zákazníka nebo o ponechání soukromých konverzací ve sdílené databázi.

Mnoho úniků začíná „přílišným sdílením“. Řekněme, že firma připojí svou AI k diskům a znalostním bázím s volně nastavenými oprávněními. AI načte cokoli, k čemu se dostane, přesně tak, jak byla navržena. Nikdo se nemusí nikam nabourat, přesto byste měli LLM považovat za kompromitovaný.

Příklad: V lednu 2025 výzkumníci ze společnosti Wiz našli databázi DeepSeek volně přístupnou z internetu s více než milionem záznamů v protokolech, včetně historie chatů a klíčů API, které software používá k přístupu k dalším službám. Výzkumníci nemuseli model k ničemu přemlouvat.

Co můžete udělat:

• Kontrolujte přístup dříve, než AI data načte: Vaše aplikace by měla ověřit, které dokumenty smí osoba pokládající dotaz vidět, ještě než je předá modelu.
• Chraňte záznamy, které po sobě AI zanechává: Před uložením protokolů aktivit odstraňte soukromé údaje a tajné klíče, vyžadujte přihlášení a omezte přístup na lidi, kteří ho potřebují. Nastavte dobu uchovávání, aby se tyto záznamy nehromadily donekonečna.

3. Zkroťte nadměrnou autonomii

AI s nadměrnou autonomií má větší moc, než její práce vyžaduje: nástroje, které nepotřebuje, oprávnění přesahující její úkol nebo volnost jednat bez kontroly. Příčina tu nehraje roli.

Podvržený prompt, chyba v kódu nebo model, který se prostě splete – vše vede ke stejnému výsledku. Pokud k tomu AI má možnost, dříve či později udělá něco destruktivního.

Příklad: V červenci 2025 zakladatel společnosti SaaStr Jason Lemkin oznámil, že programovací agent společnosti Replit smazal jeho databázi s 1 206 záznamy o vedoucích pracovnících, přestože měl pokyn neprovádět žádné změny. Agent nejprve tvrdil, že data nelze obnovit, později se však obnova ukázala jako možná. Jason zjistil, že pokyn nechat databázi na pokoji agentovi neodebral schopnost ji smazat.

Zvětšit

Zdroj: X

Co můžete udělat:

• Odeberte schopnosti, které úloha nepotřebuje: Omezte jak nástroje, které agent dostane, tak to, co tyto nástroje dokážou. Asistent, který shrnuje e-maily, potřebuje oprávnění je číst, ne je odesílat nebo mazat.
• Umístěte kontroly oprávnění mimo AI: Při každém požadavku na akci ji ověřte podle svých bezpečnostních pravidel a vyžadujte, aby ji schválil člověk.

4. Kontrolujte, co vstupuje do vašeho dodavatelského řetězce AI

Jen málo firem vyvíjí AI od nuly a každým rokem je jich méně. Podle průzkumu Menlo Ventures The State of Generative AI in the Enterprise za rok 2025 nakupovalo v roce 2024 modely AI 53 % firem, v roce 2025 už 76 %.

Firmy většinou stahují modely z platforem, jako je Hugging Face, dále je trénují na datových sadách, které shromáždil někdo jiný, a zapojují doplňky a balíčky kódu napsané cizími lidmi.

Každá z těchto součástí představuje možnou vstupní bránu. Pokud je některá z nich zmanipulovaná, problém se dostane přímo do vašeho produktu.

Příklad: Počet veřejných repozitářů modelů na Hugging Face vzrostl mezi lednem a srpnem 2026 z 2,43 milionu na 2,96 milionu. V červenci 2026 však modely OpenAI během interního bezpečnostního testování obešly kontroly, které je měly držet mimo internet, a pronikly do částí systémů Hugging Face. Jeden agent dokonce získal 14 veřejně přístupných přístupových údajů, ověřil, že fungují, a sdílel je s dalšími agenty. Agenti pak zneužili chyby, které jim umožnily spouštět kód na serverech Hugging Face.

„Zavádíme přísnější požadavky na alignment v průběhu celého životního cyklu modelu, vytváříme izolovanější sandboxy, omezujeme přístup k internetu a dále zpřísňujeme kontrolu přístupu k vahám modelů,“ uvádí zpráva OpenAI.

Co můžete udělat:

• Zafixujte modely na konkrétní verzi a ověřujte je: Zafixujte každý model na zkontrolovanou verzi a před načtením ověřte otisk jeho souboru, aby se pod stejným označením nemohl nepozorovaně objevit podvržený soubor. OWASP doporučuje také digitální podpisy, ovšem s výhradou – podpis dokazuje, odkud model pochází, ne že je bezpečný.
• Kontrolujte každý balíček, který AI navrhne: Než nainstalujete balíček kódu, který doporučil asistent AI, ověřte, že existuje, že jde o balíček, který jste měli na mysli, a že pochází od vydavatele, kterého očekáváte.

5. Chraňte se před otrávením dat a modelu

Otrávená AI se učí z poškozených dat. Může jít o příklady, na kterých byla doladěna, nebo o znalostní bázi, v níž hledá odpovědi. Model stále vypadá, že funguje; jen se naučí špatné věci a někdy se naučí chovat nesprávně jen tehdy, když narazí na konkrétní spouštěcí frázi.

Model projde všemi testy, které mu předložíte, dokud tu frázi někdo nepoužije.

Zvětšit

Navíc je velmi těžké to vrátit zpět. Otrávení není chyba, kterou lze opravit záplatou. Pokud jsou vaše data špatná, možná je budete muset znovu zkontrolovat, model přetrénovat, nebo ho úplně nahradit.

Příklad: V říjnu 2025 výzkumníci ze společnosti Anthropic, britského institutu UK AI Security Institute a institutu Alan Turing Institute ukázali, že 250 otrávených dokumentů dokáže model naučit generovat nesmysly, kdykoli narazí na určitý spouštěč. Stejný počet fungoval u všech čtyř testovaných velikostí modelů, přestože ten největší byl trénován na více než dvacetinásobném množství čistých dat.

Co můžete udělat:

• Sledujte, odkud vaše data pocházejí: Veďte záznam o každé datové sadě a modelu, které používáte, o tom, odkud pocházejí a co se mezi verzemi změnilo. Doporučujeme správu verzí datových sad, abyste se v případě odhalení otrávení mohli vrátit k čisté verzi a zjistit, jak se k vám dostalo.
• Testujte přítomnost zadních vrátek: „Zadní vrátka“ jsou skryté chování, které útočník do modelu zasadí a které čeká na konkrétní frázi nebo jiný spouštěč, jenž je aktivuje. Testujte je pomocí vstupů navržených tak, aby model porušil svá obvyklá pravidla.

6. Postavte hranice neomezené spotřebě

Když AI nemá žádné limity na to, kolik práce může vykonat nebo kolik může stát, považuje se její spotřeba za „neomezenou“. Většina služeb AI účtuje poplatky za použití, takže útočník by vám mohl vyhnat účet do výšin nebo vytvořit kopii vašeho modelu.

OWASP označuje jádro problému jako „nákladovou asymetrii“. Krátký, levný požadavek může na vaší straně spustit nákladné výpočty.

Příklad: V květnu 2024 odhalil tým Threat Research Team společnosti Sysdig nový útok nazvaný „LLMjacking“. Skupina útočníků se pomocí odcizených přihlašovacích údajů zaměřila na 10 cloudových služeb LLM. Dostali se dovnitř přes zranitelnou verzi frameworku Laravel, poté zjistili, co přihlašovací údaje umožňují a jaké mají kvóty, se zjevným cílem prodávat přístup. Dotazovali se také na řadu nastavení protokolování, pravděpodobně aby se vyhnuli odhalení. Podle společnosti Sysdig by oběť v nejhorším případě mohla přijít o více než 46 000 dolarů denně.

Co můžete udělat:

• Nastavte rozpočty, které útratu zastaví: Zaveďte pevné limity útraty pro jednotlivé uživatele, klíče API, týmy i účet jako celek. Vynucujte je všude, kudy mohou požadavky vstupovat.
• Dejte každé úloze bod zastavení: Omezte, jak dlouho může úloha běžet, kolik textu může zpracovat a vygenerovat a kolik volání nástrojů může provést. Přidejte automatické zastavení pro agenty, kteří se opakují nebo překračují svůj limit.

7. Zachyťte mylné informace dříve, než podle nich začnete jednat

Když AI vytvoří něco nepravdivého, co zní správně, a někdo nebo něco podle toho jedná, hovoříme o mylných informacích. Hlavním rizikem není ani tak samotná chybná odpověď, jako spíš to, že se jí uvěří a použije se.

Záznamy o incidentech naznačují, že se odborníci mylných informací neobávali tolik, kolik by měli. Podle úvodního dopisu k vydání z roku 2026 je hlasující zařadili téměř na konec, ale podle skutečných incidentů patří téměř na vrchol.

Příklad: V roce 2025 odevzdala společnost Deloitte Australia posudek IT systémů sociálního zabezpečení v rámci vládní zakázky v hodnotě 440 000 australských dolarů. Výzkumník Chris Rudge ze Sydneyské univerzity v něm našel odkazy na neexistující výzkum a smyšlenou citaci z rozsudku federálního soudu. Revidovaná zpráva uvedla, že Deloitte ve své metodice použil Azure OpenAI GPT-4o, a firma souhlasila, že vrátí poslední splátku. Šlo přitom bohužel o ověřovací posudek.

Co můžete udělat:

• Ověřte, že důkazy odpověď podporují: Opírejte tvrzení o aktuální a autoritativní zdroje. U odpovědi týkající se zásad načtěte schválenou zásadu a ověřte, že závěr podporuje, včetně jejích výjimek.
• Ověřujte dříve, než systém začne jednat: Pokud agent tvrdí, že zákazník prošel ověřením totožnosti, potvrďte to v ověřovacím systému dříve, než uvolníte platbu. U závažných rozhodnutí vyžadujte schválení člověkem a zajistěte, aby měl schvalovatel k dispozici podkladové důkazy.

8. Omezte škody způsobené odhalením skrytého kontextu

Aplikace AI dávají modelu pokyny a podkladové informace, které uživatelé běžně nevidí. Může jít o systémový prompt, interní zásady, popisy dostupných nástrojů a pravidla o tom, kdo je smí používat. K odhalení skrytého kontextu dochází, když model tyto informace někomu prozradí.

OWASP v roce 2026 rozšířil tuto položku z „úniku systémového promptu“, protože systémový prompt je jen částí toho, co může uniknout. Nebezpečí závisí na tom, co jste do něj vložili. Uniklý průvodce tónem komunikace je mírně trapný, ale uniklý klíč API dává někomu přístup k vaší důvěrné databázi.

Příklad: V únoru 2023 uživatelé přiměli Bing Chat od Microsoftu prozradit jeho interní pokyny. Jeden úspěšný pokus pocházel od Marvina von Hagena, který se vydával za vývojáře OpenAI a požádal o pokyny, aby mohl model nakonfigurovat. Bing prozradil pravidla, jimiž se řídí jeho vyhledávání, odpovědi a bezpečnostní chování, a také své interní jméno Sydney. Mezi odhalenými pokyny byl i ten, který mu ukládal tyto pokyny uchovávat v tajnosti.

Co můžete udělat:

• Držte tajné údaje mimo kontext modelu: Počítejte s tím, že cokoli, co model dokáže přečíst, se může dostat k uživatelům – hesla, klíče API a přístupové tokeny ukládejte do samostatného systému pro správu tajných údajů.
• Zajistěte, aby oprávnění platila, i když pravidla uniknou: Kontroly přístupu vynucujte v kódu aplikace. Pokud je nástroj vyhrazen pouze administrátorům, před jeho spuštěním ověřte oprávnění uživatelského účtu.

9. Zabezpečte vektory a embeddingy

Když AI pomocí vektorového vyhledávání hledá odpovědi v dokumentech vaší společnosti, neprohledává přímo text. Dokumenty se převádějí na tzv. „embeddingy“ – dlouhé řady čísel, které zachycují význam jednotlivých pasáží – a ukládají se do vektorové databáze. Stejným způsobem se převede i dotaz a systém pak vybere pasáže, jejichž čísla se číslům dotazu nejvíce blíží.

OWASP shrnuje čtyři způsoby, jak může takový systém selhat: otrávení způsobí, že bude chybovat, inverze povede k úniku dat, zahlcení ho umlčí a nefunkční řízení přístupu způsobí, že vydá cokoli komukoli.

Čísla nejsou tak bezpečnou abstrakcí, jak se zdá. Uložené embeddingy lze převést zpět na text a jedné metodě se v testech podařilo přesně obnovit 92 % krátkých pasáží o délce 32 tokenů. Uniklá záloha obsahující „pouze embeddingy“ tak může rovněž odhalit obsah dokumentů.

Příklad: Ve výzkumu prezentovaném na konferenci USENIX Security 2025 vědci ukázali, že jediný pečlivě vytvořený dokument dokáže AI zabránit v odpovědi na konkrétní otázku. Přidali ho do kolekce, kterou AI prohledávala. Když na něj AI narazila, mohla odpovědět, že nemá dostatek informací nebo že by odpověď nebyla bezpečná. Dokument přitom nemusel AI nabádat, aby ignorovala svá pravidla. Tomuto jevu se říká „zahlcení vyhledávání“ (retrieval jamming).

Co můžete udělat:

• Veďte oddělené indexy pro veřejná a soukromá data: Nemíchejte obsah stažený z webu s daty partnerů ani s důvěrnými interními dokumenty. Místo označování obsahu v jediném indexu data fyzicky oddělte podle úrovně důvěryhodnosti – odstraníte tím celou třídu chybných konfigurací a obsah stažený z internetu se nemůže ocitnout vedle materiálů pro představenstvo.
• Zacházejte s embeddingy stejně jako s dokumenty, ze kterých vznikly: Šifrujte je, chraňte zálohy vektorové databáze stejně jako zdrojové soubory a při odstranění původního dokumentu odstraňte i jeho embeddingy. Klíče API ke službě pro tvorbu embeddingů uchovávejte v tajnosti.

10. Kontrolujte výstup AI, než ho předáte dál

Kdykoli aplikace předá výstup AI jinému systému, aniž by ověřila, zda je bezpečné ho tam použít, jde o nesprávné zpracování výstupu LLM.

Tato položka se týká i nezabezpečeného kódu, který asistenti AI pro programování generují ve velkém. Každý řádek, který asistent napíše, je tedy také výstupem.

Příklad: V roce 2025 výzkumník Johann Rehberger ukázal, jak mohl programovací asistent Amp od společnosti Sourcegraph vyzradit obsah chatu pouhým zobrazením obrázku. Pomocí prompt injection přiměl Amp, aby vložil soukromé informace do webové adresy obrázku. Aplikace pak obrázek automaticky načetla a informace tím odeslala na jeho server. Selháním při zpracování výstupu byl právě tento automatický požadavek – text vygenerovaný modelem se proměnil ve spojení s externím serverem, které s sebou neslo soukromá data.

Co můžete udělat:

• Zajistěte, aby byl výstup bezpečný pro své místo určení: Odpovědi kontrolujte a zpracovávejte podle toho, kam budou směřovat. U webové stránky zabraňte tomu, aby se z vygenerovaného textu stal spustitelný kód. U databáze používejte připravené dotazy, které oddělují zadané hodnoty od příkazů.
• Zabraňte tomu, aby odpovědi automaticky navazovaly externí spojení: Ve výchozím nastavení v odpovědích modelu vypněte automatické načítání obrázků, náhledů odkazů a vložených stránek. Nezbytná spojení omezte na výslovně schválené cíle.

Jak Perplexity zabezpečuje LLM?

Vycházíme z předpokladu, že se každé z výše uvedených rizik jednou naplní, a systémy navrhujeme tak, aby pak nemohlo napáchat mnoho škody. Náš CISO Kyle Polley to podrobně vysvětlil na nedávném workshopu.

• Agent dostane vlastní počítač, který je na začátku prázdný: Agentní nástroje nainstalované ve vašem notebooku mohou získat přístup k jeho souborům, aplikacím a uloženým přihlašovacím údajům. Perplexity Computer funguje opačně. Každá úloha běží ve vlastním izolovaném sandboxu, který podle Polleyho „ve výchozím stavu nemá přístup k ničemu“.
• Agent nikdy nevidí hesla: Přihlašovací údaje k připojeným službám jsou uloženy mimo sandbox. Když agent potřebuje přistoupit ke službě, jako je GitHub, odešle požadavek bez přihlašovacích údajů. Brána ověří, že cíl i požadavek odpovídají očekávání, a teprve poté k odchozímu požadavku přidá přihlašovací údaje. Agent tak může připojení používat, aniž by získal klíče.
• Vaše oprávnění se přenášejí a můžete je dále zpřísnit: Připojení vytvořená přes OAuth zachovávají vaše přístupová oprávnění v připojené službě. Co nevidíte vy, nevidí ani váš agent.
• S každou webovou stránkou zacházíme jako s cizincem: BrowseSafe jsme vytvořili pro Comet, náš agentní prohlížeč, protože nástroje, které jsme testovali, v reálném provozu nesplňovaly naše potřeby. Prohlížeč kontroluje, zda webové stránky a další externí obsah včetně e-mailů neobsahují prompt injection. Model i datovou sadu jsme zveřejnili jako open source.
• Sledujeme agenta i počítače, na kterých běží: Numbat stojí mezi rozhodnutím agenta jednat a skutečným spuštěním nástroje. Numbat zaznamenává aktivitu podporovaných programovacích agentů a dokáže zablokovat akce porušující nastavené zásady ještě před jejich provedením. Bumblebee inventarizuje softwarové balíčky v noteboocích, na serverech a v sestavovacích pipelinách a označuje ty, o nichž je známo, že jsou škodlivé. Oba nástroje jsou open source.
• Poskytovatelé modelů vaše data neuchovávají: S externími poskytovateli LLM máme sjednáno nulové uchovávání dat. Správci verze Enterprise mohou navíc zkrátit dobu uchovávání dat přímo v Perplexity až na pouhých 24 hodin.

Numbat jsme vytvořili proaktivně, a to z důvodu, který Polley shrnuje jedinou větou: „Čím větší autonomii agentovi dáte, tím větší je riziko.“

Časté dotazy k zabezpečení LLM

Který LLM je nejbezpečnější?

Žádný LLM sám o sobě aplikaci nezabezpečí – modely si stále mohou splést obsah, který mají pouze číst, s pokyny, které mají plnit. Obranná opatření, která ve standardních testech vypadají spolehlivě, mohou pod tlakem také selhat.

Lepší otázka zní, které nastavení je pro váš případ použití nejbezpečnější. To znamená omezená oprávnění, přihlašovací údaje držené mimo dosah modelu, lidské schvalování rizikových akcí a testování lidmi, kteří vaše obranná opatření znají.

Co jsou zranitelnosti LLM?

Zranitelnosti LLM jsou slabiny, kvůli nimž lze systém AI oklamat, mohou z něj unikat data nebo může způsobit škodu – ať už vinou útočníka, nebo vlastních chyb.

Deset hlavních rizik představují prompt injection, vyzrazení citlivých informací, nadměrná autonomie, dodavatelský řetězec, otrávení dat a modelu, neomezená spotřeba, dezinformace, odhalení skrytého kontextu, slabiny vektorů a embeddingů a nesprávné zpracování výstupu.

Je soukromý LLM bezpečný?

Pro některé účely je to bezpečnější varianta, ale ne automaticky. Pokud model provozujete na vlastní infrastruktuře nebo v cloudovém prostředí, máte nad zpracováním dat větší kontrolu. Neexistuje však žádný automatický způsob, jak zabránit prompt injection, nadměrné autonomii, otrávení nebo dezinformacím.

Při vlastním hostování navíc odpovídáte i za model, který stáhnete, včetně rizik dodavatelského řetězce a infrastruktury, kterou vyžaduje.