„Najdi v kalendáři volný termín a připrav pozvánku“ zní jako pohodlné zadání. Dokud AI pouze vypíše několik možností a navrhne text, můžeme její chybu opravit dřív, než se něco stane. Jakmile však sama otevře kalendář, vybere účastníky a pozvánku odešle, stejná chyba opustí okno chatu. Objeví se v cizích schránkách, zabere lidem čas a může prozradit informaci, která měla zůstat neveřejná.
Technologická změna tedy neleží jen v tom, že AI odpovídá lépe. Spočívá v přechodu od slov k činům. Návrh e-mailu není odeslaný e-mail. Doporučená změna není přepsaný soubor. Seznam možností není zaplacená objednávka. Mezi každou dvojicí leží oprávnění jednat a s ním následky, které už nemusí jít odstranit klávesou Zpět.
Právě zde se často objevuje slovo agent. Marketing z něj někdy dělá digitálního kolegu, který dostane cíl a samostatně se postará o zbytek. Takový obraz je přitažlivý, ale zakrývá důležitější otázku: kdo rozhodl, co tento „kolega“ smí vidět, měnit a odesílat, kdy se musí zastavit a kdo ponese odpovědnost, když zvolí přesvědčivý, ale chybný krok?
Odpověď ještě není čin
Jazykový model může bez připojených nástrojů vytvořit text, plán nebo radu. Jeho výstup může být chybný, zavádějící či nevhodný, ale aby se proměnil ve skutečný čin, obvykle jej musí převzít člověk nebo další software. Člověk musí text zkopírovat, soubor uložit, formulář odeslat nebo příkaz spustit.
Nástroj tuto mezeru zmenšuje. AI může získat funkci pro čtení kalendáře, úpravu dokumentu, vytvoření úkolu, odeslání zprávy nebo spuštění programu. Její výstup se tak může přímo proměnit v operaci v jiném systému.
Podobně se liší člověk, který na papír napíše „zavřít ventil“, od toho, který má ruku na jeho páce. Oba se mohou mýlit. U druhého záleží mnohem více na tom, ke kterému ventilu má přístup, zda zná tlak v potrubí, zda jej někdo kontroluje a zda jde zásah rychle vrátit.
Kdo určuje další krok
Pojem agent nemá v technologickém oboru jedinou ostrou hranici. Někdo tak označí téměř každý chatbot s nástrojem, jiný až systém schopný dlouho pracovat bez člověka. Pro orientaci je proto užitečnější sledovat, kdo volí další krok.
Chatbot většinou reaguje na konkrétní vstup a vrátí odpověď. Pevný pracovní postup neboli workflow může použít několik modelů a nástrojů za sebou, ale cestu určil člověk předem: nejdřív načti dokument, potom jej shrň, nakonec ulož výsledek do dané složky. Agent dostane cíl a podle průběžných výsledků volí, zda bude hledat, doptá se, použije nástroj, zkontroluje výsledek, změní plán nebo se zastaví.
Takové rozlišení používá i technický přehled společnosti Anthropic Building effective agents: workflow vede modely a nástroje předem definovanými cestami, zatímco agent nechává model průběžně řídit postup a použití nástrojů.
| Podoba systému | Kdo určuje další krok | Typický výsledek | Hlavní otázka |
|---|---|---|---|
| chatbot | člověk novým zadáním | odpověď nebo návrh | Je výstup správný a vhodný? |
| pevný workflow | předem napsaný postup | opakovatelná posloupnost | Jsou pravidla a výjimky nastavené správně? |
| agent | model v rámci cíle a dostupných nástrojů | proměnlivá řada kroků a akcí | Co smí zvolit a jaké následky může způsobit? |
Ve skutečné aplikaci se tyto podoby mohou míchat. Agent může pracovat v pevně stanovených hranicích, workflow v jednom kroku dovolit modelu volbu a chatbot po potvrzení zavolat nástroj. Rozhodovací volnost proto posuzujeme podle konkrétního postupu.
Proč samostatný postup ještě neznamená dobrý úsudek
Agent často pracuje ve smyčce: vytvoří plán, provede krok, přečte výsledek a podle něj pokračuje. Takto jeho činnost popisuje i přehled Trustworthy agents in practice. Může si všimnout, že hledání nic nenašlo, zkusit jiný dotaz a nakonec požádat člověka o chybějící údaj. Zvenčí to může připomínat zkušeného kolegu, který si umí práci rozdělit.
Podoba procesu však nedokazuje hloubku úsudku. Model může velmi plynule plánovat a přitom vycházet z nesprávného předpokladu. Může použít nástroj přesně podle jeho popisu, ale nepochopit místní pravidlo, nepsanou výjimku nebo společenský následek. A především nenese vlastní profesní, právní ani morální odpovědnost způsobem, jakým ji nese člověk ve svěřené roli.
Označení „seniorní digitální kolega“ proto snadno zamění schopnost postupovat za oprávnění rozhodovat. Zkušený člověk není cenný pouze tím, že umí udělat mnoho kroků bez dotazu. Ví také, kdy běžný postup nepoužít, koho se změna dotkne, kterou nejistotu nesmí zakrýt a za jakých okolností musí práci zastavit.
Co MCP propojuje a co nezaručuje
Model Context Protocol neboli MCP je otevřený standard pro propojování aplikací využívajících AI s externími systémy. Oficiální architektura rozlišuje hostitelskou aplikaci, klienta obstarávajícího komunikaci a MCP server, který nabízí určité schopnosti. Server je zde program; může běžet přímo v našem počítači i u poskytovatele vzdálené služby. Zpřístupňuje nástroje, zdroje a prompty.
Zdroj dodává modelu podklady, například obsah souboru nebo záznam z databáze. Prompt nabízí předem připravené zadání. Nástroj je vykonatelná funkce: může vyhledat záznam, ale také změnit soubor, zavolat rozhraní jiné služby nebo vytvořit událost. Tyto tři schopnosti serveru ukazují, proč nestačí říct, že jsme AI „připojili k datům“. Čtení dokumentu a odeslání zprávy jsou zásadně odlišné možnosti.
MCP bývá přirovnáván k USB-C konektoru pro AI. Metafora pomáhá vysvětlit společné rozhraní, ale má hranici. Stejný konektor neříká, zda připojujeme klávesnici, úložiště, nebo neznámé zařízení. MCP standardizuje komunikaci; podle vlastní dokumentace neurčuje, jak AI aplikace použije model a poskytnutý kontext. Sám tedy není bezpečnostním certifikátem serveru, zárukou správného popisu nástroje ani důkazem, že systém dostal přiměřená oprávnění.
Číst, psát a odeslat jsou tři různé pravomoci
U běžné aplikace často jedním kliknutím povolíme přístup ke „kalendáři“, „souborům“ nebo „e-mailu“. Tak široký název však neříká, co přesně systém dokáže. Smí jen zjistit obsazené termíny? Vidí názvy a účastníky všech událostí? Může vytvářet nové? Může je také rušit a rozesílat změny lidem mimo organizaci?
Stejnou otázku lze položit u dokumentů. Čtení několika vybraných souborů je jiná pravomoc než zápis do celé sdílené složky. Vytvoření návrhu změny je něco jiného než přepsání originálu. Přesun do koše je bezpečnější než trvalé smazání, ale stále může narušit práci ostatních.
Bezpečnostní projekt OWASP mezi příčiny nadměrné pravomoci řadí nepotřebné funkce, příliš široká oprávnění a příliš velkou autonomii. Mohou se uplatnit jednotlivě i společně. Problém tedy nemusí být jen v tom, že model odpověděl špatně. Prostředí mu umožnilo, aby se chyba proměnila v příliš závažný čin.
Přístup má odpovídat úkolu
Princip nejmenšího oprávnění říká, že systém má dostat pouze přístup nutný pro konkrétní úkol a pouze na nezbytnou dobu. Agent, který má shrnout tři dokumenty, nepotřebuje právo mazat celou složku. Pomocník hledající volný čas nemusí znát obsah soukromých poznámek u všech událostí. Nástroj připravující odpověď zákazníkovi nepotřebuje automaticky právo ji odeslat.
Aktuální bezpečnostní doporučení MCP výslovně radí nedávat systému jedno všezahrnující oprávnění, ale dělit přístup podle nástrojů či schopností. Důvod není jen technický. Úzké oprávnění zpřehledňuje, k čemu člověk skutečně svolil, omezuje rozsah případné chyby a umožňuje přístup odebrat bez narušení všeho ostatního.
Při rozšíření úkolu může agent potřebovat také další přístup. Má pak vysvětlit, k čemu jej potřebuje a jak dlouho má platit. Jasně vymezený souhlas umožňuje pokračovat v dohodnuté práci, aniž by člověk musel znovu potvrzovat každý běžný krok.
Omezení přitom musí vynucovat samotná služba nebo prostředí, v němž nástroj běží. Představme si pomocníka, který smí upravovat pracovní kopie v jedné složce. Kdyby mu model omylem zadal cestu k firemnímu účetnictví, má přístup odmítnout souborový systém nebo nástroj. Pokud jedinou ochranou zůstane pokyn „na ostatní soubory nesahej“, závisí ochrana na úsudku modelu, který může selhat. OWASP doporučuje kontrolovat oprávnění v navazujících systémech, nezávisle na rozhodnutí modelu.
Také při pouhém čtení záleží na cestě dat. Aplikace může načíst dokument z našeho počítače a předat jeho obsah vzdálenému modelu. Soubor zůstane beze změny, ale údaje už zpracovává další služba. Před povolením přístupu proto potřebujeme vědět, kam se podklady posílají a kdo je smí zpracovat.
Když se instrukce schová do toho, co AI čte
Agent nemusí selhat jen proto, že špatně pochopí člověka. Může zpracovávat webovou stránku, e-mail nebo dokument, do něhož někdo vložil instrukci určenou modelu. Pro člověka je takový text součástí dat; agent jej může zaměnit za pokyn, který má následovat.
NIST tento problém označuje jako agent hijacking neboli únos agenta prostřednictvím nepřímé instrukce ukryté v datech. Útočník například vloží škodlivý pokyn do obsahu, který agent musí přečíst při plnění legitimního úkolu. Pokud systém nedokáže dobře oddělit důvěryhodné zadání od nedůvěryhodných dat, může změnit cíl a použít nástroj způsobem, který uživatel nezamýšlel.
Obrana potřebuje více vrstev: rozpoznání podvrženého pokynu, omezené nástroje, kontrolu oprávnění i možnost akci zastavit. Čím širší přístup agent má, tím více může chybným krokem zasáhnout. Úspěšnost útoku přitom závisí na konkrétním modelu, úloze a ochranách kolem něj.
Co má ukázat potvrzovací okno
Nabízí se jednoduché řešení: před každou akcí se AI zeptá. Jenže člověk může během jedné úlohy dostat deset dialogů s technickými názvy funkcí a neurčitým tlačítkem Povolit. Po několika bezpečných krocích může začít potvrzovat automaticky. Jeho souhlas se sice dál zaznamenává, ale pozorná kontrola se vytrácí.
Smysluplné potvrzení musí přijít ve chvíli, kdy ještě lze něco změnit. Má srozumitelně ukázat, co se stane, s jakými daty, komu nebo kam výsledek odejde a zda je akce vratná. Člověk potřebuje čas i informace k rozhodnutí a skutečnou možnost říct ne, aniž by celé rozhraní jeho odmítnutí trestalo nebo obcházelo.
U pozvánky z úvodu by proto mělo být vidět datum, čas, název schůzky, přesný seznam adresátů a zpráva, kterou dostanou. Představme si, že agent vybral správného Petra, ale ke schůzce přidal i jeho bývalou kolegyni ze starší události. Tlačítko „Povolit přístup ke kalendáři“ takovou chybu neodhalí. Přehled konkrétních příjemců ano. Po změně adresátů už také schvalujeme jinou akci, než jakou jsme viděli původně.
Míra kontroly má odpovídat následkům akce. Opakovaný dotaz, který v omezené složce data pouze čte, může být předem povolený. Odeslání e-mailu, zveřejnění příspěvku, smazání dat, nákup nebo přijetí závazku vyžadují pečlivější posouzení. Dokumentace MCP k nástrojům doporučuje možnost člověka volání odmítnout a potvrzení citlivých operací, ale konkrétní podobu musí navrhnout hostitelská aplikace.
Kontrolovat potřebujeme záměr i skutečný dopad
Před akcí můžeme vidět plán. Po akci potřebujeme zjistit, co se opravdu stalo. Agent mohl požádat o úpravu jednoho souboru, ale nástroj mohl změnit více položek. Rozhraní služby mohlo vrátit nečekanou odpověď. Síťová chyba mohla vést k opakovanému odeslání. Proto nestačí uložit jen konečnou větu „úkol dokončen“.
Užitečný záznam ukazuje, který nástroj byl použit, s jakým cílem, jaké důležité údaje dostal, jak odpověděl a kdo případný citlivý krok schválil. Hesla a přístupové tokeny, tedy údaje umožňující přístup k účtu, do takové historie nepatří. Soukromý obsah se má zaznamenávat jen v rozsahu potřebném pro kontrolu a s odpovídajícím omezením přístupu.
Je také rozdíl mezi technickým záznamem a slovním vysvětlením. Záznam může přesně zachytit deset použití nástroje, ale člověku neřekne, proč agent považoval právě tuto cestu za vhodnou. Naopak plynulé zdůvodnění může znít přesvědčivě, aniž přesně odpovídá tomu, jak postup vznikl. Při kontrole proto porovnáváme vysvětlení s ověřitelnými stopami o provedených akcích.
Zpět není univerzální bezpečnostní tlačítko
Některé chyby lze izolovat a vrátit. Agent může pracovat v dočasné kopii, vytvořit návrh změn, použít verzování nebo přesunout soubor do koše místo trvalého smazání. Takové prostředí dovoluje vyšší míru samostatnosti, protože omezuje rozsah škody.
Jiné kroky vratné nejsou nebo se vracejí jen zdánlivě. Odeslaný e-mail lze doplnit omluvou, ale jeho příjemce už jej mohl přečíst. Zveřejněný údaj lze smazat, ale kopie může zůstat. Zrušená schůzka mohla změnit plány deseti lidí. Objednávku lze někdy stornovat, ne však bez nákladů či právních následků.
Než agentovi dovolíme jednat, proto nestačí otázka, zda má aplikace funkci Zpět. Potřebujeme vědět, zda lze obnovit technický stav, napravit dopad na lidi a zastavit řetězec dalších akcí. Čím hůře se následek vrací, tím dříve má přijít lidské rozhodnutí.
Kdy je obyčejná automatizace lepší
Agent je užitečný tam, kde se cesta k cíli mění podle situace: při hledání v různých zdrojích, řešení nečekaných chyb nebo kombinování nástrojů, které nelze předem seřadit pro každý případ. Pružnější řešení však automaticky neznamená lepší řešení.
Pokud známe pravidla, vstupy i výjimky, pevný postup bývá levnější, rychlejší, snáze testovatelný a předvídatelnější. Zpracování faktury s pevně stanovenými poli nemusí řídit systém, který pokaždé znovu přemýšlí, co udělá dál. Pravidelné zálohování nepotřebuje kreativitu. Kritická operace s přesně popsanou posloupností může být bezpečnější bez modelu v rozhodovací smyčce.
Dobrá otázka tedy není „Kde ještě můžeme použít agenta?“, ale „Která část úkolu skutečně potřebuje pružnou volbu?“ Agent může například vyhledat a připravit návrh, zatímco kontrola, zápis a zveřejnění proběhnou pevným, předvídatelným postupem. Autonomie nemusí být vlastností celého systému. Může být úzkou výjimkou uvnitř něj.
Pět otázek před připojením nástroje
Přehled oprávnění bývá technický, ale rozhodnutí může začít obyčejnými otázkami:
- Co systém uvidí? Jen vybraný dokument, nebo celou složku? Volné termíny, nebo i názvy schůzek a jejich účastníky?
- Co smí změnit? Vytvoří kopii a návrh, nebo přepíše originál? Smí pouze přidávat, nebo také mazat?
- Co může opustit moje prostředí? Odešle data jiné službě, člověku nebo veřejnosti? Je zřejmé, komu patří připojený server?
- Kdy se musí zastavit? Jaká finanční částka, počet příjemců, druh dat nebo nejistota vyžaduje souhlas člověka?
- Jak zjistím a napravím, co udělal? Existuje historie kroků, verzování, testovací režim, limit počtu akcí a nouzové zastavení?
Odpověď „nástroj potřebuje plný přístup, jinak nebude pohodlný“ není technická nevyhnutelnost. Je to návrhové rozhodnutí s cenou, kterou často neplatí autor aplikace, ale člověk, jehož data nebo jméno agent používá.
Kdo odpovídá za nastavení a následky
Když organizace dá agentovi přístup k firemnímu systému, nevytváří tím nového nositele odpovědnosti. Sama rozhoduje, jaký model a nástroj použije, které funkce zpřístupní, jak nastaví kontrolu a zda uživatele i zaměstnance upozorní na omezení. Věta „udělala to AI“ může popsat bezprostřední mechanismus, ale neodpovídá na otázku, proč bylo možné, aby to udělala.
To je podstatné i pro zaměstnance. Člověk nemůže být pouze formálním schvalovatelem desítek kroků, kterým nerozumí, a zároveň jediným viníkem každé chyby. Pokud má nést odpovědnost, potřebuje přiměřený čas, znalosti, pravomoc akci zastavit a prostředí, které kontrolu nepovažuje za zdržování.
Když software přiděluje úkoly zaměstnancům, vzniká podobná otázka z opačné strany: je AI kolega, nástroj, nebo šéf? U agenta člověk svěřuje systému jednání svým jménem. V obou případech ovlivňuje výsledek nastavení nástroje, rozhodnutí vedení i prostor člověka u posledního potvrzení. Rozdělení práce mezi ně musí zahrnovat také jasné určení, kdo kontroluje chyby a kdo zajišťuje nápravu.
Samostatnost potřebuje jasné hranice
Debata o agentech se snadno změní v závod, kdo vydrží déle bez lidského zásahu. Jenže dlouhá samostatnost není sama o sobě známkou dobrého systému. Agent, který se včas zastaví před nejasným nebo nevratným krokem, může být užitečnější než ten, který hrdě dokončí nesprávný úkol.
Pohodlí se pozná podle ušetřené práce. Kontrola podle toho, zda člověk rozumí předané pravomoci, vidí důležité kroky a může zasáhnout. Dobře navržený systém spojuje obojí: běžné úkony provádí plynule, u závažné změny ukáže konkrétní důsledky a technicky brání zásahům mimo povolený prostor.
U pozvánky z úvodu to znamená připravit správný termín, text i adresáty, před odesláním je ukázat člověku ke kontrole a potom ověřit, že zpráva odešla právě jim. Samotné „hotovo“ v chatu nestačí. Rozhodující je, co se skutečně stalo v kalendáři a ve schránkách lidí, které jsme pozvali na schůzku.
