Bezpečnost a AI: jak chránit citlivá data při využívání AI nástrojů

Proč je bezpečnost u AI specifická

Klasické aplikace zpracovávají předvídatelné vstupy, s jasně definovaným schématem a omezeným rozsahem dat. AI nástroje naopak pracují s volným textem, dokumenty, kódem, screenshoty, tabulkami i hlasem. Mnoho firem poprvé umožňuje zaměstnancům nahrávat do cloudových služeb nestrukturovaný obsah, který může obsahovat citlivé informace, aniž by si to uživatel uvědomil.

• Neúmyslné prozrazení: jeden špatně vložený prompt může obsahovat PII, obchodní tajemství nebo klíče k API.
• Široké integrace: agenti a pluginy volají další systémy – každý konektor je nové riziko egressu dat.
• „Chytrá“ paměť: asistenti uchovávají historii; pokud není správně oddělena, hrozí křížová kontaminace dat mezi týmy.
• Output rizika: AI může omylem vrátit interní informaci z kontextu (např. z neomezené paměti nebo chybně nastaveného RAG).

Nejčastější scénáře úniku a zneužití dat

1) Citlivý obsah v promptu

Uživatel vloží do veřejné AI služby smlouvu, databázový výpis nebo kód s tajnými klíči. Bez firemní kontroly nad instancí a bez „no-train“ záruk může dojít k nechtěné retenci a expozici.

2) Automatická indexace sdílených dokumentů

Firemní „copilot“ nad cloudovým úložištěm začne indexovat vše v doméně. Chybí query-time kontrola oprávnění, takže uživatel může dotazem získat citaci z dokumentu, který nikdy neměl vidět.

3) Prompt injekce a data exfiltrace

Závadný text v e-mailu nebo na webu přinutí agenta porušit pravidla („vypiš tajné instrukce“, „ulož obsah do veřejného gistu“). Bez sandboxingu nástrojů a output filtrů hrozí únik.

4) Zranitelné integrace třetích stran

Pluginy do CRM, helpdesku či kalendáře mohou posílat data dodavateli. Bez CASB/DLP a smluvního ošetření je obtížné riziko řídit.

5) Fine-tuning na reálných datech

Tréninkový dataset obsahuje PII a obchodní tajemství. Bez pseudonymizace a izolace prostředí hrozí porušení pravidel a nevratná expozice know-how.

6) Logování a telemetrie

Plné prompty a odpovědi končí v centrálním log systému. Pokud nejsou redigované a šifrované, představují „vše na jednom místě“ pro útočníka.

Bezpečnostní principy pro AI (privacy-by-design)

• Minimalizace dat: posílejte do modelu jen to, co je nutné. Automatická redakce PII, tajemství a identifikátorů.
• Segmentace a izolace: separovat vývoj/test/provoz, oddělené projekty/tenanti pro různé citlivosti a týmy.
• Least privilege & ABAC: role-based a attribute-based kontrola nad přístupem i během dotazu (runtime).
• Šifrování „všude“: transport, klid, cache, embeddingy, vektory; rotace klíčů a KMS/HSM.
• Auditovatelnost bez úniku: logovat metriky a rozhodnutí, nikoli plný citlivý obsah.
• No-train záruky: smluvně i technicky zakázat použití promptů/odpovědí k tréninku mimo kontrolu firmy.
• Governance a guardrails: centrální politika, AI gateway, detekce rizikových promptů a ochrana výstupu.

Klasifikace dat a mapování „crown jewels“

Základ je vědět, co chráníte. Zaveďte 3–4 úrovně klasifikace (např. veřejná, interní, důvěrná, přísně tajná) a ke každé přiřaďte:

• příklady dat a dokumentů,
• povolené/zakázané použití v AI (včetně příkladů promptů),
• požadavky na šifrování a přístup,
• retenční pravidla a postup bezpečného mazání.

Současně vytvořte seznam „crown jewels“ (nejcennější aktiva – cenotvorba, IP, algoritmy, seznamy klíčových klientů). U nich použijte přísnější kontroly: never upload to public AI, dvoufaktor, ABAC tagy, vyšší úroveň DLP, pravidelné audity přístupů.

Firemní politiky: co je povoleno a co ne

Politika má být krátká, pochopitelná a s příklady. Dvě roviny: pravidla pro uživatele a pravidla pro IT/bezpečnost.

Pro uživatele

• Nevkládejte do neschválených AI služeb obchodní tajemství, PII/PHI, finanční plány, zdrojové kódy a tajné klíče.
• Pro citlivé úlohy používejte firemní AI (podniková instance s no-train, logováním a řízením přístupu).
• Při vkládání dokumentů proveďte redakci (automatická i manuální) a zkontrolujte klasifikaci.
• AI výstupy jsou návrhy; v citlivých procesech je povinná lidská kontrola (HITL).
• Bez schválení nesdílejte AI odpovědi, které obsahují interní informace, mimo firmu.

Pro IT/bezpečnost

• Provozujte AI gateway (proxy) pro všechny AI dotazy s DLP/PII inspekcí, maskováním a směrováním na vhodné modely.
• Udržujte katalog schválených nástrojů, blokujte shadow AI na síti a v identitě (SSO, CASB/SSE).
• Zapněte retenční politiku pro prompty/odpovědi; ukládejte pouze nezbytná metadata.
• Provádějte posouzení rizik (DPIA apod.) u vysoce citlivých scénářů.

Je zakázáno vkládat do veřejných AI služeb dokumenty, data nebo kód označený jako DŮVĚRNÉ či PŘÍSNĚ TAJNÉ.
Citlivé dotazy smí být prováděny pouze přes firemní AI gateway s aktivní redakcí a logováním.
AI výstupy v procesech s dopadem na zákazníky podléhají kontrole druhého páru očí (HITL).

Vzory nasazení: veřejný cloud, privátní cloud, on-prem

Veřejný cloud (SaaS AI)

• Nejrychlejší start, široká nabídka modelů a funkcí.
• Nutnost smluvních záruk (no-train, regionální zpracování, subprocesory), BYOK/HYOK ideálně podporováno.
• Vždy přes gateway s DLP a routingem – co je citlivé, jde jen do schválených koncových bodů.

Privátní cloud / VPC

• Vyšší kontrola nad daty a síťovým tokem; lepší integrace s KMS/HSM.
• Nutné řízení nákladů a pravidelný patch management modelových služeb.

On-prem / vlastní hostování modelů

• Maximální suverenita a izolace, vhodné pro nejcitlivější data.
• Vyžaduje zkušený tým (MLOps/LLMOps), hardware, monitoring a bezpečnostní hardening.

Doporučení: většina organizací volí hybrid – rychlé scénáře v SaaS pod kontrolou gateway, citlivé workloady v privátním cloudu či on-prem.

Referenční architektura: bezpečný přístup k AI

Praktický vrstvený model s AI gateway uprostřed:

1. Identita & přístup: SSO, MFA, RBAC/ABAC, atributy citlivosti, podmíněný přístup.
2. Input kontrola: DLP/PII detekce, maskování/redakce, normalizace formátů, limity velikosti, malware scan příloh.
3. Routing: pravidla „typ dotazu → povolený model/region/tenant“, citlivé dotazy jen do prostředí s BYOK/HYOK, region-pinning.
4. Output kontrola: detekce citlivých informací ve výstupech, blokace uniků (např. výpis klíčů, interních instrukcí), watermarking.
5. Audit & telemetry: bezpečná metadata, rozhodnutí politik, latence, náklady; napojení na SIEM/SOAR.
6. Sandbox nástrojů: agentům povolit jen schválené pluginy/domény, egress kontrola, časové tokeny, rate-limity.

Součástí architektury je datová vrstva s jasnými „data contracts“, katalogem, lineage a ABAC tagy (např. pii:true, secret:true, legal_hold:true), které gateway respektuje při směrování a kontrole.

Šifrování, tokenizace, správa klíčů (BYOK/HYOK)

• Transport: TLS 1.2+/1.3, moderní sady šifer, HSTS, Certificate Pinning u interních klientů.
• V klidu: šifrování disků a objektových storage; oddělené klíče pro různě citlivé kolekce; pravidelná rotace.
• KMS/HSM: správa klíčů v cloudu nebo on-prem; audit přístupů; „break-glass“ jen pro incidenty.
• BYOK/HYOK: vlastní klíče u dodavatelů (BYOK) nebo úplně u vás (HYOK) pro nejcitlivější data.
• Tokenizace a masking: pro PII (rodná čísla, IBAN), čísla karet, tajemství; AI pracuje s tokeny nebo syntetikou.
• Embeddingy a vektory: šifrované indexy, oddělené kolekce podle klasifikace, omezení sdílení embeddingů mezi tenanty.
• Cache/paměť asistentů: šifrované, per-user/per-team oddělení, retenční limity a explicitní opt-out pro citlivé konverzace.

Provozní bezpečnost: logování, audit, monitoring, SIEM

Logujte dost pro audit a reakci, ale málo citlivých obsahů:

• Logujte: uživatele/roli, čas, model, objem tokenů, klasifikaci rizika, rozhodnutí DLP (povoleno/zamítnuto/maskováno), latenci, náklady.
• Neukládejte: plné prompty/odpovědi se citlivým obsahem; pro debugging používejte redigovanou podobu a krátkou retenci.
• SIEM/SOAR: alerty na anomálie (neobvyklé objemy, časy, IP), pokusy o injekce, přístupy ke „crown jewels“ kolekcím.
• FinOps: nákladové metriky na tým a use-case, alokace rozpočtů, detekce neefektivních dotazů.

Due diligence dodavatelů a smluvní zajištění

Ptejte se na klíčové body a dostaňte je do smluv:

• No-train záruka: používá poskytovatel zákaznická data k tréninku? Jak je to vynuceno technicky?
• Datová suverenita: region zpracování a ukládání; možnost region-pinning; seznam subprocesorů.
• Šifrování a klíče: podpora BYOK/HYOK, audit přístupů, rotace klíčů.
• Retence: doba uchování promptů/odpovědí, možnost kompletního vypnutí logů obsahu.
• Bezpečnostní praxe: pravidelné pen testy, bug bounty, sdílení výsledků a nápravných opatření.
• Exit plán: smazání dat a artefaktů (indexy, cache, modelové váhy) při ukončení služby.

Poskytovatel se zavazuje nepoužívat zákaznické prompty/odpovědi k tréninku modelů (NO-TRAIN).
Zpracování a ukládání dat probíhá výhradně v určeném regionu. Přístup subprocesorů je omezen a auditován.
Zákazník používá vlastní šifrovací klíče (BYOK/HYOK). Při ukončení smlouvy poskytovatel provede ověřitelné smazání.

Specifika pro RAG a vektorové databáze

RAG zvyšuje přesnost tím, že k modelu přidává vaše dokumenty. Z hlediska bezpečnosti je klíčové:

• Query-time ACL: vynucení oprávnění při každém dotazu. Uživatel nesmí získat chunk, k němuž nemá přístup.
• Citlivost v metadatech: štítky (PII, legal, trade-secret) – výstupní filtr blokuje citace přesahující oprávnění.
• Redakce před indexací: maskování PII, klíčů a tajemství přímo v obsahu (nejen při odpovědi).
• Šifrované vektory a oddělené kolekce: per-team/per-citlivost izolace, audit přístupů.
• Zdrojové citace: povinné odkazy ve výstupu (zlepšuje auditovatelnost i kvalitu).

Prompt security, injekce a ochrana před exfiltrací

• Oddělte role: systémové instrukce a pravidla oddělit od uživatelského vstupu; zakázat jejich zobrazení.
• Dezinfekce obsahu: odstraňovat/přepisovat známé „exploit“ fráze a zakázané akce ve vstupních datech.
• Allowlist nástrojů: agent smí volat jen schválené pluginy a domény, žádné volné HTTP požadavky.
• Ochrana výstupu: filtr, který zamezí vyzrazení systémového promptu, klíčů a tajných instrukcí.
• Red-teaming: pravidelné testy prompt injekce a exfiltrace; sdílení „učebných“ příkladů zaměstnancům.

Vzory k automatické redakci:
- API klíče (regex pro běžné formáty)
- Čísla karet, IBAN, rodná čísla, čísla smluv
- Interní cesty a názvy serverů
- Interní e-maily a telefonní kontakty

Fine-tuning a trénink na vlastních datech bezpečně

• Pseudonymizace/syntetika: nahradit PII a tajemství; generovat syntetické příklady, kde to možné.
• Izolace prostředí: oddělený projekt/tenant, omezený egress, dedikované klíče, šifrované úložiště.
• Dataset governance: verze, původ, licence, souhlasy; žádné „neznámé“ scrapes.
• Privacy testy: membership inference/model inversion – ověřte, že model „nepapouškuje“ tréninková data.
• Retence a mazání: po skončení projektu smazat dataset, checkpointy, dočasné exporty a zálohy.

AI DevSecOps a LLMOps: od testů po red-teaming

Stejně jako u softwaru potřebuje AI pipeline s kontrolami:

1. Repo promptů a politik: verzování systémových instrukcí, šablon a guardrails; code review.
2. Automatické testy: test-sady na bezpečnost (neprozrazovat policy), přesnost, toxicitu, citlivost.
3. Canary deploy: postupné uvolnění uživatelům, sledování metrik a stornování při anomáliích.
4. Observabilita: dashboardy kvality (hit rate, citace), bezpečnosti (zablokované prompty) a nákladů.
5. Red-team program: pravidelné scénáře útoků (injekce, exfiltrace, jailbreak, DoS), veřejná „hall of fame“ interně.

Školení zaměstnanců: snížení rizika lidské chyby

Krátké, praktické, opakované – a v pracovní době:

• AI bezpečnost v praxi (60 min): co (ne)vkládat, jak redigovat, jak poznat injekci, jak nahlásit incident.
• Role-based moduly: HR (PII, screening), Finance (citlivé reporty), Dev (IP, kód, tajemství), Support (zákaznická data).
• Table-top cvičení: simulace úniku přes chatbota; kdo dělá co; časové limity a eskalace.
• Ověření znalostí: krátký test; badge/certifikace; refresher každého půl roku.
• „Nástroje po ruce“: tlačítko Redigovat, šablony bezpečných promptů, odkazy na politiku a nahlášení.

Tip pro HR: Zařaďte AI bezpečnost do onboardingu a stanovte minimální čas, který má každý zaměstnanec věnovat micro-learningu měsíčně.

Incident response a forenzní postupy pro AI

Mějte připravený runbook – ideálně otestovaný cvičením:

• Detekce & triage: signál z DLP/SIEM; klasifikace závažnosti; odpojení napadeného pluginu/integrace.
• Zabránění šíření: dočasné vypnutí konkrétního modelu nebo route; reset klíčů; blokace egressu.
• Forenzní šetření: auditní záznamy (bez plných obsahů), časová osa, identifikace dotčených dat/subjektů.
• Notifikace: interní komunikace, případně zákonná oznámení; právní podpora a PR připravené na Q&A.
• Náprava: úprava politik, vylepšení filtrů, další školení; post-mortem s jasnými úkoly a termíny.

Metriky: jak řídit riziko vs. přínosy

Bez metrik bezpečnost těžko obhájíte – a bez metrik inovace těžko udržíte:

• Bezpečnostní KPI: počet zablokovaných rizikových promptů, čas reakce na incident, míra redigovaných vstupů, shadow AI detekce (trend).
• Provozní KPI: latence gateway, dostupnost, chybovost politik, počet false-positive blokací.
• Byznys KPI: adopce schválených nástrojů, úspora času/úkol, kvalita výstupů s HITL, spokojenost uživatelů.
• FinOps KPI: náklady na dotaz/tým/use-case, efektivita modelů, podíl neúspěšných dotazů.

30–60–90–180denní roadmapa bezpečné AI

0–30 dní: pravidla a minimální ochrany

• Schválit AI politiku (no-train, klasifikace, HITL, zakázané scénáře).
• Inventura používaných AI nástrojů; blokace neschválených (shadow AI) přes CASB/SSE.
• Spustit AI gateway v pilotu pro první týmy; zapnout základní DLP/PII a redakci.
• Úvodní školení pro všechny znalostní role; zřídit kanál pro dotazy a nahlášení incidentů.

31–60 dní: technické guardrails a měření

• Rozšířit DLP/PII detektory, nastavit retenční pravidla, omezit logování obsahů.
• Zavést routing (citlivé dotazy → schválené modely s BYOK/HYOK a region-pinning).
• Napojit gateway do SIEM, nastavit alerty (injekce, exfiltrace, anomálie).
• RAG pilot s query-time ACL, šifrovanými vektory a povinnými citacemi.

61–90 dní: smlouvy, škálování, LLMOps

• Uzavřít DPA/no-train dodatky s klíčovými dodavateli; ověřit subprocesory a regiony.
• Zavést repo promptů a politik, automatické testy (bezpečnost, kvalita, náklady).
• Škálovat gateway na další týmy; standardizovat šablony bezpečných promptů.

91–180 dní: institucionalizace a red-teaming

• Založit AI CoE (Center of Excellence) s bezpečnostním mandátem a red-team programem.
• Pravidelné audity přístupů k „crown jewels“, refresh školení, roční re-certifikace.
• FinOps governance: rozpočty, kvóty, optimalizace modelů a cache; reporty pro vedení.

Checklisty, šablony a vzorové klauzule

Rychlý bezpečnostní checklist (ANO/NE)

• Máme schválenou AI politiku s příklady povolených/zakázaných scénářů.
• Všechny AI dotazy prochází přes gateway s DLP/PII a auditními metadaty.
• RAG vynucuje query-time ACL a používá šifrované vektorové indexy.
• Logy neobsahují plné citlivé obsahy; retence je omezená.
• Dodavatelé mají smluvně ošetřenou no-train záruku a exit plán.
• Školení je povinné při onboardingu a periodicky se obnovuje.
• Incident runbook je otestovaný cvičením; měříme čas reakce.

Scorecard (0–5, kde 5 = zvládnuto špičkově)

1. Politiky a governance
2. AI gateway & guardrails
3. DLP/PII, redakce, klasifikace
4. RAG bezpečnost a šifrované vektory
5. Logování, audit, SIEM/SOAR
6. Dodavatelské smlouvy a due diligence
7. Školení a kultura bezpečné AI
8. Incident response a testy
9. FinOps a nákladová efektivita
10. LLMOps/DevSecOps (testy, canary, red-team)

Interpretace: průměr < 2,5 = vysoké riziko; 2,5–3,5 = stabilizace; > 3,5 = připraveno škálovat.

Než něco vložíš do AI:
1) Je to veřejné nebo interní? Pokud DŮVĚRNÉ/TAJNÉ → nepoužívej veřejné AI.
2) Obsahuje dokument PII/klíče/smluvní detaily? → Rediguj.
3) Používáš firemní AI? → Ano, přes gateway (ikona / adresa).
4) Je potřeba lidská kontrola? → U citlivých výstupů vždy.
5) Sdílení ven? → Jen se schválením a bez interních citací.

Bezpečné scénáře podle útvarů

HR

• Draft inzerátů a popisů rolí v interní AI s redakcí PII; screening s jasnými pravidly férovosti a HITL.
• Onboardingový asistent čerpající z dokumentace s query-time ACL (nováček vidí jen své materiály).

Finance

• AI shrnutí měsíčních reportů bez PII; kontrolní checklisty; citlivé sešity mimo veřejné AI.
• RAG nad smlouvami s právními štítky a citacemi zdrojů pro auditovatelnost.

Vývoj/IT

• Asistence při kódování v interní instanci; zákaz vkládání tajných klíčů; automatická redakce konfigurací.
• Runbooky a post-mortems generované z ticketů; logy anonymizované a bez PII.

Zákaznická podpora

• RAG nad znalostní bází s citacemi; návrhy odpovědí pro agenty; povinný HITL u citlivých požadavků.
• Automatická kategorizace ticketů; PII redakce před přeposláním do analýzy.

FAQ vedení a IT

Máme zakázat veřejné AI úplně?

Ne nutně. Omezte je přes proxy/gateway na bezpečné scénáře; citlivé dotazy směrujte do podnikových instancí s no-train a kontrolou přístupu.

Je RAG bezpečnější než fine-tuning?

Obvykle ano, protože data držíte mimo parametry modelu a vynucujete ACL při dotazu. Přesto vyžaduje šifrování vektorů a citlivostní štítky.

Můžeme logovat obsahy pro kvalitu?

Ano, ale redigovaně a s omezenou retencí. Plné obsahy pouze výjimečně (break-glass) a krátce, se schválením.

Jak se vyhnout vendor lock-inu?

Používejte gateway s abstrakcí modelů, otevřené formáty a smluvní exit plány. Kritická data chraňte BYOK/HYOK.

Jak rychle lze spustit bezpečný pilot?

Za 4–8 týdnů při existující politice, gateway v pilotu, základním školení a zvoleném use-case s nízkou citlivostí.

Závěr: inovovat rychle, ale bezpečně

AI je akcelerátor – zesiluje to, co ve firmě máte. Pokud jsou procesy bezpečné a data správně řízená, AI zrychlí hodnotu. Pokud jsou pravidla vágní a přístupy volné, AI zrychlí cestu k incidentu. Tajemství úspěchu je v kombinaci: jasná politika, AI gateway s guardrails, šifrování a řízení klíčů, RAG s query-time ACL, LLMOps testy a pravidelné školení lidí. Tak postavíte AI, která je nejen užitečná, ale i bezpečná a auditovatelná.

Chcete rychle posoudit svou připravenost? Začněte checklistem, zaveďte minimální gateway, vyberte jeden bezpečný use-case s jasnými metrikami a do 6–8 týdnů získejte důkaz hodnoty – bez kompromisů v důvěrnosti.