Guardrails jsou pravidla, filtry nebo pomocné modely, které hlídají chování AI agenta za běhu. Mohou kontrolovat vstupy (co uživatel posílá), výstupy (co agent odpovídá) i průběžné kroky (jaké nástroje a API agent volá). Nejde o nic mystického – v praxi to může být jednoduchý seznam zakázaných akcí, nebo sofistikovaný klasifikátor, který posoudí každý krok agenta před provedením.

Čísla z nedávného open-source projektu Forge mluví jasně: model s 8 miliardami parametrů (tedy relativně malý, levný model) dosahoval na komplexních agentních úlohách 53% úspěšnosti bez guardrails. Po jejich přidání vyskočila úspěšnost na 99 %. To je rozdíl, který v reálném provozu znamená desítky ušetřených hodin měsíčně a téměř nulovou chybovost. A to vše bez výměny modelu za dražší alternativu.

Guardrails se dělí do tří základních vrstev. První je vstupní validace – agent zkontroluje, zda přijatý požadavek dává smysl, než s ním začne pracovat. Příklad: agent pro vyřizování reklamací odmítne zpracovat požadavek, kde chybí číslo objednávky nebo e-mail zákazníka, a místo toho si je vyžádá. Tato vrstva sama o sobě eliminuje velkou část chyb způsobených nekvalitními vstupy.

Druhá vrstva jsou akční limity – definujete přesně, jaké nástroje a API může agent volat a za jakých podmínek. Agent zpracovávající faktury může číst data z účetního systému, ale nesmí je mazat ani měnit bez potvrzení. Třetí vrstva je výstupní kontrola – před tím, než agent odešle e-mail zákazníkovi nebo zapíše data do databáze, proběhne finální kontrola formátu, obsahu nebo částky. Například: pokud je hodnota faktury vyšší než 50 000 Kč, transakce čeká na schválení člověkem. Kombinace všech tří vrstev tvoří robustní síť, která zachytí naprostou většinu chyb.

E-shop s elektronikou nasadí AI agenta na odpovídání dotazů o dostupnosti zboží a doručení. Bez guardrails agent občas přislíbí doručení do 24 hodin i pro zboží, které je na cestě ze skladu tři dny. Stačí přidat jednoduchý kontrolní krok: před každou odpovědí agent ověří aktuální stav ve skladovém systému a teprve pak formuluje odpověď. Výsledek: nula mylných slibů, spokojenější zákazníci.

Výrobní firma středního rozměru z Moravy si postavila agenta na třídění a přeposílání interních e-mailů. Agent ze začátku občas přeposílal zprávy špatnému oddělení, protože neuměl rozlišit, kdy jde o technický problém a kdy o obchodní dotaz. Po přidání klasifikačního guardrail modelu, který kategorizuje každý e-mail před přeposláním, klesla chybovost z přibližně 12 % na méně než 1 %. Firma ušetřila odhadem 6 hodin týdně, které dříve věnoval administrativní pracovník opravám špatně směrovaných zpráv. Pokud vás zajímá, jak podobné řešení nasadit ve vaší firmě, můžete kontaktovat tým Elys a probrat konkrétní možnosti.

Začněte mapováním rizik. Projděte každý krok, který váš agent dělá, a zeptejte se: co nejhoršího se může stát, pokud tento krok selže? Zapište si tři až pět nejvyšších rizik. U agenta pro zákaznický servis to typicky bývá: špatná informace o ceně, příslib, který firma nemůže splnit, nebo únik interních dat do odpovědi zákazníkovi.

Poté pro každé riziko navrhněte konkrétní kontrolní bod. Nemusíte hned sáhnout po složitém ML modelu – mnoho guardrails je čistě logických a naprogramujete je za odpoledne. Teprve pokud logická pravidla nestačí (například potřebujete posoudit tón textu nebo záměr uživatele), sáhněte po pomocném klasifikačním modelu. Dobrou volbou jsou lehké modely jako Gemini 2.0 Flash nebo Mistral 7B, které jsou rychlé a levné. Testujte guardrails na historických datech – pokud máte logy z předchozího provozu agenta, projděte chybové případy a ověřte, zda by je nová pravidla zachytila. Cílem není nulová chybovost za cenu toho, že agent bude neustále volat člověka – hledejte rovnováhu mezi autonomií a bezpečností.

První chyba je nasadit agenta rovnou do produkce bez testovací fáze. I dva týdny provozu v „shadow módu kdy agent navrhuje řešení ale člověk je finálně schvaluje – odhalí většinu problémů dříve než způsobí reálnou škodu. Druhá chyba je přílišná důvěra ve velký model. GPT-4o nebo Gemini 1.5 Pro jsou výkonné ale ani ony nejsou neomylné. Guardrails potřebujete bez ohledu na to jaký model pod agentem běží.

Třetí, a možná nejrozšířenější chyba je absence logování. Pokud nevíte, co agent dělal, nemůžete jeho chování zlepšovat. Logujte každý vstup, každý výstup a každé volání externího nástroje. Dobré logování vám také umožní prokázat zákazníkovi nebo auditorovi, že váš systém funguje správně – v kontextu rostoucích požadavků na transparentnost AI to bude čím dál důležitější. Řada platforem jako LangSmith, Langfuse nebo česky přívětivá Helicone toto logování nabízejí jako hotovou službu za jednotky dolarů měsíčně.

Čtvrtá chyba je ignorovat aktualizace modelů. Když poskytovatel aktualizuje model, chování agenta se může jemně změnit a guardrails, které fungovaly dříve, nemusí zachytit nové typy chyb. Nastavte si pravidelný měsíční review, kde projdete logy a zkontrolujete, zda guardrails stále dělají svou práci.

Guardrails nejsou luxus pro velké korporace – jsou to základní stavební kameny každého spolehlivého AI agenta. Firma, která je přeskočí, nešetří čas; odkládá jen problémy na později, kdy budou dražší na řešení. Dobrá zpráva je, že začít můžete malými kroky: vyberte jednoho agenta, zmapujte tři největší rizika a přidejte první kontrolní body. Zbytek přijde přirozeně.

Pokud si nejste jisti, kde začít, nebo chcete mít jistotu, že vaše AI automatizace bude od začátku postavená správně, jsme tu pro vás. Pomocí naší online kalkulačky zjistíte orientační náklady na konkrétní řešení, nebo nás rovnou kontaktujte tým Elys – rádi projdeme váš případ a navrhneme architekturu, která bude bezpečná, škálovatelná a přiměřená vašemu rozpočtu.