Oprávnění a lidská kontrola

Nový zaměstnanec v účtárně nedostane první den klíče od všech kanceláří, přístup do všech systémů a podpisové právo na libovolnou částku. Dostane přístupy podle toho, co dělá, a velké platby za něj podepisuje vedoucí. Nikdo to nebere jako nedůvěru, je to obyčejná provozní hygiena.

U AI se na tuhle hygienu kupodivu často zapomíná. Agent dostane přístup „ke všemu, ať to funguje“, firemní vyhledávání najde i dokumenty, které daný člověk neměl vidět, a schvalování akcí se po týdnu změní v rutinní klikání. Předchozí lekce o prompt injection skončila závěrem, že model se dá přemluvit a obrana musí stát mimo něj. Tahle lekce rozebírá dvě nejdůležitější vrstvy té obrany: co AI smí, a kde o věcech rozhoduje člověk.

Nejmenší možná oprávnění

Princip nejmenších oprávnění(principle of least privilege)

Každý uživatel, program nebo AI agent má jen ta oprávnění, která nutně potřebuje ke svému úkolu, a jen na dobu, po kterou je potřebuje. Cokoli navíc je riziko bez užitku.

Pro AI má tenhle starý princip zvláštní váhu. U člověka spoléháme i na jeho úsudek: účetní s přístupem k celé databázi ji nebude mazat jen proto, že mu to někdo napsal do e-mailu. U modelu na úsudek spolehnout nejde, protože jeho chování ovlivňuje každý text, který čte. Oprávnění jsou proto u AI hlavní hranice škody: co agent nemůže, to ho nikdo nepřiměje udělat.

OWASP mezi hlavními riziky AI aplikací uvádí přílišnou samostatnost (Excessive Agency) a popisuje tři její zdroje. Hodí se jako kontrolní otázky:

• Příliš mnoho funkcí. Agent má nástroje, které úkol nepotřebuje. Asistent na čtení pošty, který umí i mazat a odesílat, protože „to šlo v jednom balíku“.
• Příliš široká oprávnění. Nástroj potřebný pro úkol má větší přístup, než je nutné. Agent má číst jednu tabulku, ale připojuje se účtem s právem zapisovat do celé databáze.
• Příliš velká samostatnost. Agent provádí akce s velkým dopadem, aniž by je kdokoli nezávisle ověřil.

Jak to vypadá v praxi

Několik konkrétních pravidel, která můžeš chtít po svém týmu nebo dodavateli:

1. Čtení odděleně od zápisu. Pokud úkol vyžaduje jen čtení, ať má AI jen čtení. Kde je zápis nutný, ať je co nejužší: třeba „vytvořit koncept odpovědi“, ne „odeslat e-mail“.
2. Úzce omezené přístupové klíče. Systémy, se kterými AI pracuje přes nástroje a API, obvykle umí vydat přístupový klíč (token) s omezeným rozsahem (scope): jen určitá složka, jen čtení, jen jeden projekt, s dobou platnosti. Používej je místo jednoho všemocného klíče.
3. Samostatné servisní účty. Agent, který běží sám (třeba noční zpracování faktur), má mít vlastní účet s vlastními právy, ne účet ředitele nebo administrátora. Pak v záznamech vidíš, co udělal agent a co člověk, a můžeš mu přístup kdykoli vzít, aniž bys rozbil něco jiného.
4. Konkrétní nástroje místo univerzálních. Nástroj „najdi objednávku podle čísla“ je bezpečnější než „spusť libovolný dotaz do databáze“. Univerzální nástroje (příkazová řádka, libovolné HTTP volání) dávají modelu volnost, kterou útočník může využít.
5. Kontrola práv v cílovém systému, ne v promptu. Věta „nikdy nemaž záznamy“ v systémovém promptu není ochrana. Ochrana je, když účet, pod kterým agent běží, mazat nemůže. Pravidla vynucuje software, ne model.
6. Pravidelná revize. Přístupy mají tendenci jen přibývat. Jednou za čas projdi, co který agent smí, a co nepoužívá, mu odeber.

AI musí respektovat práva každého uživatele

Zvláštní případ oprávnění nastává u firemního vyhledávání a asistentů nad firemními daty (o tom, jak fungují, je lekce RAG v praxi). Zaměstnanec se zeptá „jaké jsou platy v našem oddělení?“ a systém prohledá dokumenty. Které dokumenty smí prohledat?

Správná odpověď: jen ty, které by tazatel mohl otevřít i bez AI. AI asistent nesmí fungovat jako zadní vrátka, přes která se člověk dostane k tomu, k čemu nemá přístup. Velcí výrobci to tak u svých produktů popisují. Microsoft například v dokumentaci k Microsoft 365 Copilot uvádí, že Copilot zobrazuje jen data, ke kterým má konkrétní uživatel aspoň právo čtení, a vyhledávání respektuje stejné přístupové hranice jako ostatní služby Microsoft 365.

Tady je ale háček, který firmy často nepříjemně překvapí. Pokud AI práva respektuje, ukáže každému všechno, co vidět smí. A ve většině firem lidé formálně smí vidět mnohem víc, než by měli: sdílené složky „pro celou firmu“, které někdo kdysi vytvořil omylem, odkazy na dokumenty sdílené „všem s odkazem“, staré týmové weby s personálními tabulkami. Dřív to nevadilo, protože to nikdo nenašel. AI asistent to najde za vteřinu. Microsoft v téže dokumentaci výslovně píše, že je důležité používat modely oprávnění ve službách jako SharePoint, aby správní lidé měli přístup ke správnému obsahu.

Do hloubkyJak se práva uživatele technicky přenášejí do AI+

Jsou dva základní způsoby, jak AI systém pracuje s firemními daty.

V kontextu uživatele. Systém se do zdrojů dotazuje „jménem“ přihlášeného člověka, typicky přes jeho přihlášení (OAuth), a zdrojový systém sám rozhodne, co mu vrátí. To je bezpečnější varianta: práva se nemusí nikde kopírovat a změna práv se projeví okamžitě. OWASP ji doporučuje jako jedno z opatření proti přílišné samostatnosti.

Servisním účtem s filtrováním. Systém má vlastní účet, který vidí všechno, a výsledky filtruje podle toho, kdo se ptá. Například si u každého dokumentu ve znalostní bázi pamatuje, které skupiny ho smí číst. Funguje to, ale je to křehčí: když se práva ve zdrojovém systému změní a kopie se neaktualizuje, AI ukazuje staré stavy. A chyba ve filtru znamená únik.

U nepřímé prompt injection pak platí ještě jedna věc: pokud agent běží s právy uživatele a nechá se přemluvit, škoda je omezená na to, co smí ten uživatel. To je další důvod, proč nedávat agentům práva širší, než má člověk, pro kterého pracují.

Kde musí rozhodovat člověk

Ani dobře nastavená oprávnění nestačí, když agent smí udělat něco závažného. Některé akce proto musí před provedením schválit člověk. V lekci Jak výstupy ověřovat jsi poznal pojem člověk ve smyčce (human in the loop). Tady ho použijeme na akce, nejen na texty.

Člověk by měl rozhodovat vždy, když akce patří aspoň do jedné z těchto skupin:

• Nevratná. Smazání dat, odeslání zprávy, zveřejnění, podpis, zrušení objednávky. Co nejde vzít zpátky, musí projít člověkem.
• Jde ven. Cokoli, co opouští firmu: e-mail zákazníkovi, příspěvek na sociální sítě, odpověď úřadu, sdílení dokumentu s externistou. Tady se navíc potkává se „smrtící trojicí“ z minulé lekce: cesta ven je přesně to, co útočník potřebuje.
• Finanční. Platby, refundace, slevy, změny cen, objednávky nad limit.
• Právní. Cokoli, co firmu zavazuje: smlouvy, přísliby, souhlasy, prohlášení.
• Týká se lidí. Rozhodnutí o zaměstnancích nebo zákaznících: nábor, hodnocení, odmítnutí žádosti, přístup ke službě. Tady se navíc často dostáváš do oblastí, které AI Act řadí mezi vysoce rizikové.

Naopak tam, kde je akce vratná, interní a levná (zařazení e-mailu do složky, návrh štítku u tiketu, koncept odpovědi), schvalování obvykle jen zdržuje. Lepší je nechat AI pracovat a výsledky kontrolovat vzorkem.

Jak zařídit, aby schválení nebylo odklikávání

Schvalovací tlačítko samo o sobě nic nezaručuje. Z lekce o ověřování znáš automatizační zkreslení: když nástroj stokrát navrhne správnou věc, sto první návrh člověk odklikne bez čtení. Schvalování se tak změní v razítko. Navíc razítko, které vytváří falešný pocit, že kontrola proběhla.

Několik zásad, které dělají schvalování smysluplným:

1. Ukaž, co přesně se stane, ne co AI „chce“. Místo „Agent chce odeslat e-mail. Schválit?“ ukaž příjemce, předmět, celý text a přílohy. Místo „provést platbu“ částku, účet a důvod. Schvalovatel musí vidět konkrétní akci, ne její shrnutí od modelu (to může být samo ovlivněné útokem).
2. Zvýrazni, co je neobvyklé. Nový příjemce, externí doména, částka nad běžným průměrem, akce mimo pracovní dobu. Pozornost člověka je omezená, nasměruj ji tam, kde je riziko.
3. Schvalovat málo, ale pořádně. Když člověk schvaluje stovky akcí denně, nečte je. Schvalování vyhraď pro akce, kde opravdu záleží, a ostatní nech běžet s kontrolou vzorkem a limity.
4. Dej schvalovateli čas, znalosti a pravomoc. Kdo schvaluje platby, musí rozumět platbám a musí mít možnost akci zamítnout bez vysvětlování nadřízenému, proč „zdržuje“.
5. Občas otestuj, jestli kontrola funguje. Můžeš do schvalovací fronty (třeba v testovacím prostředí nebo při školení) vložit cvičný chybný návrh a sledovat, jestli ho lidé zachytí. Je to citlivé a nesmí to působit jako past na zaměstnance, proto o tom tým předem informuj. Výsledek ti ale řekne víc než jakákoli směrnice.
6. Sleduj míru schválení. Když lidé schvalují 100 % návrhů, buď je AI dokonalá, nebo nikdo nečte. Obojí stojí za prověření.

Špatně: „Asistent připravil odpověď dodavateli. [Odeslat] [Zrušit]“

Dobře: „Odeslat e-mail na nabidky@novy-dodavatel.example (externí doména, první kontakt). Příloha: Ceník 2026 – interní.xlsx (označeno jako interní). Text: [celý text e-mailu]. [Odeslat] [Upravit] [Zamítnout a nahlásit]“

Ve druhém případě schvalovatel na první pohled vidí, že interní ceník míří na neznámou adresu. V prvním případě by to zjistil, jen kdyby si odpověď sám rozklikl.

Auditní stopa

Všechno, co AI dělá, by mělo zanechat stopu: kdo zadal úkol, jaké podklady model dostal, jaké nástroje volal a s jakými parametry, kdo co schválil a kdy. Bez toho nejde vyšetřit incident, prokázat, že kontrola proběhla, ani se poučit z chyb.

Prakticky to znamená, že se ukládají záznamy (logy) o voláních nástrojů a schváleních, vedou se k jednotlivým uživatelům a servisním účtům a někdo je pravidelně prochází nebo nad nimi běží automatická upozornění. Jak takové sledování postavit, rozebírá lekce Monitoring a logování. U vysoce rizikových systémů navíc AI Act ukládá provozovatelům uchovávat automaticky vytvářené záznamy aspoň šest měsíců, pokud jiný předpis nestanoví jinak.

Zkus svůj systém napadnout dřív než ostatní

Před spuštěním stojí za to systém cíleně „napadnout“. Tomu se říká red-teaming: skupina lidí (vlastní tým nebo externí specialisté) se schválně snaží přimět systém k tomu, co dělat nemá. Pro AI aplikace to znamená hlavně:

• zkusit přímé injekce: vymámit systémový prompt, přemluvit chatbota k nevhodné odpovědi nebo slibu,
• zkusit nepřímé injekce: připravit testovací e-mail, dokument nebo webovou stránku se skrytými pokyny a sledovat, co agent udělá,
• ověřit oprávnění: přihlásit se jako běžný zaměstnanec a ptát se na věci, ke kterým by se dostat neměl,
• ověřit cesty ven: zkusit, jestli lze agenta přimět něco odeslat na cizí adresu nebo vložit odkaz či obrázek z cizí domény,
• ověřit schvalování: projde akce, která měla čekat na člověka, i bez něj?

Co najdeš, přidej do testovací sady, aby se to po každé změně modelu nebo promptu otestovalo znovu. Red-teaming není jednorázová akce: nové modely, nové nástroje a nové triky útočníků znamenají nová rizika.

Co k tomu říká AI Act

Evropský AI Act u vysoce rizikových systémů (které to jsou, vysvětluje lekce Kategorie rizika) vyžaduje lidský dohled. Článek 14 mimo jiné požaduje, aby lidé, kteří systém dozorují, rozuměli jeho schopnostem a omezením, uměli správně vyložit jeho výstupy, mohli se rozhodnout výstup nepoužít nebo ho zvrátit a mohli systém zastavit. Výslovně přitom zmiňuje i riziko, že se lidé budou na výstupy systému přehnaně spoléhat, tedy automatizační zkreslení. Článek 26 pak provozovatelům ukládá svěřit dohled lidem, kteří mají potřebné kompetence, vzdělání a pravomoc.

Všimni si, že zákon popisuje přesně to, co tahle lekce doporučuje z bezpečnostních důvodů: dohled, který je skutečný, ne formální. Konkrétní povinnosti a termíny, od kdy platí, najdeš v lekci Povinnosti a termíny. Termíny se v době psaní ještě mohou posouvat, proto vycházej z aktuálního stavu.

Šablona: schvalovací matice

Na závěr nástroj, který můžeš použít hned. Pro každý AI systém nebo agenta sepiš, jaké akce umí, a ke každé urči, jestli ji AI dělá sama, jestli ji schvaluje člověk, nebo jestli ji AI dělat nesmí vůbec. Tady je vzor pro asistenta zákaznické podpory:

Akce	Dopad	Kdo rozhoduje	Co schvalovatel vidí	Záznam
Vyhledat informace v nápovědě a interních článcích	Nízký, jen čtení	AI sama	–	Ano
Navrhnout odpověď zákazníkovi	Nízký, koncept	AI sama	–	Ano
Odeslat odpověď zákazníkovi	Jde ven	Operátor schvaluje	Celý text, příjemce, přílohy	Ano, včetně schvalovatele
Vrátit peníze do 500 Kč	Finanční	Operátor schvaluje	Částka, objednávka, důvod	Ano
Vrátit peníze nad 500 Kč	Finanční	Vedoucí týmu schvaluje	Částka, historie zákazníka, důvod	Ano
Změnit údaje v zákaznickém účtu	Týká se lidí, těžko vratné	Operátor schvaluje	Původní a nová hodnota	Ano
Smazat zákaznický účet	Nevratné	AI nesmí	–	–
Sdílet dokument mimo firmu	Jde ven	AI nesmí	–	–

Částky a role jsou ilustrační, nastav je podle své firmy. Důležité jsou tři věci. Zaprvé, řádek „AI nesmí“ musí být vynucený oprávněními, ne jen napsaný v promptu. Zadruhé, sloupec „Co schvalovatel vidí“ rozhoduje o tom, jestli je schválení skutečná kontrola. A zatřetí, matice není hotová jednou provždy: když přidáš nástroj nebo zjistíš, že lidé něco odklikávají bez čtení, uprav ji.

Co si odnést

• AI agent má mít jen ta oprávnění, která úkol nutně potřebuje: čtení místo zápisu, úzké přístupové klíče, vlastní servisní účet, konkrétní nástroje místo univerzálních. Pravidla vynucuje software, ne prompt.
• Firemní AI smí každému ukázat jen to, k čemu má přístup i bez ní. Protože to najde rychle, před nasazením ukliď sdílená práva.
• Člověk má rozhodovat o akcích, které jsou nevratné, jdou ven, týkají se peněz, práva nebo lidí. Ostatní nech běžet s kontrolou vzorkem.
• Schválení má smysl, jen když člověk vidí konkrétní akci, neobvyklosti jsou zvýrazněné a schvalovaných věcí není tolik, že je nikdo nečte.
• Všechno, co AI dělá, má zanechat auditní stopu. Před spuštěním a po každé větší změně systém cíleně napadni.
• AI Act u vysoce rizikových systémů požaduje skutečný lidský dohled lidmi s kompetencí a pravomocí, včetně ochrany před automatizačním zkreslením.

Zdroje a další čtení

• OWASP: LLM06:2025 Excessive Agency – tři zdroje přílišné samostatnosti AI a doporučená opatření.
• Microsoft Learn: Data, Privacy, and Security for Microsoft Copilot – jak Copilot respektuje oprávnění uživatelů a proč na jejich nastavení záleží.
• AI Act, článek 14: Lidský dohled – požadavky na lidský dohled u vysoce rizikových systémů, včetně zmínky o automatizačním zkreslení.
• AI Act, článek 26: Povinnosti provozovatelů – komu svěřit dohled a jak dlouho uchovávat záznamy.
• Beurer-Kellner a kol.: Design Patterns for Securing LLM Agents against Prompt Injections (arXiv, 2025) – návrhové vzory, jak omezit, co agent smí po přečtení nedůvěryhodného obsahu.