gárdrejlsTakéAI guardrails, LLM guardrails, safety guardrailsPokročilý
Definice
Guardrails jsou vrstva pravidel, filtrů a kontrol kolem jazykového modelu nebo AI agenta, která hlídá, co smí přijít na vstup a co smí odejít na výstup. Blokují nebo přepisují nevhodné dotazy, ověřují formát odpovědi, omezují dostupné nástroje a zachytí témata, kterým se aplikace má vyhnout.
Nezaměňujte: V AI systémech znamenají guardrails kontrolní vrstvu kolem modelu, zatímco v cloud governance (například AWS Control Tower) jde o preventivní a detekční pravidla nad účty a zdroji.
Proč model samotný nestačí
Jazykový model generuje text podle pravděpodobnosti, ne podle firemní politiky. Trénink a doladění (RLHF, safety fine-tuning) posunou chování správným směrem, ale nedávají tvrdou záruku: stejný model, který 999krát odmítne nevhodný dotaz, ho po tisící přeformulovaný splní. Guardrails proto stojí mimo model jako deterministická vrstva, kterou lze auditovat, testovat a měnit bez přetrénování.
Kde guardrails v aplikaci sedí
Typické nasazení má tři body kontroly. Na vstupu se filtruje uživatelský text: detekce prompt injection, pokusů o extrakci systémového promptu, osobních údajů nebo zakázaných témat. Uprostřed se omezuje samotné běhové prostředí: povolený seznam nástrojů, limit počtu kroků agenta, read-only přístup k databázi. Na výstupu se kontroluje odpověď: validace JSON schématu, kontrola, zda odpověď vychází z dodaných dokumentů, maskování PII, blokace toxického obsahu.
Deterministické kontroly
Deterministické kontroly jsou regulární výrazy, seznamy zakázaných řetězců, JSON Schema, kontrola, že vrácené ID skutečně existuje v databázi. Jsou levné, rychlé a jejich chování je předvídatelné. Pokrývají ale jen to, co jde přesně popsat.
Kontroly modelem
Kontroly modelem používají druhý, obvykle menší a levnější model jako klasifikátor: „porušuje tento text politiku?“, „je odpověď podložená kontextem?“. Zvládnou nuance, ale samy mohou chybovat a přidávají latenci i náklady. V praxi se obě vrstvy kombinují.
Co se stane při porušení
Návrh guardrailu musí odpovědět na otázku, co následuje po zásahu. Možnosti jsou tvrdé odmítnutí s vysvětlením, tichá sanitizace (odstranění telefonního čísla z odpovědi), opakovaný pokus s doplněnou instrukcí, nebo eskalace na člověka. U agentů, kteří provádějí akce, bývá nejbezpečnější varianta lidské potvrzení před nevratným krokem: odeslání peněz, smazání dat, odchozí e-mail zákazníkovi.
Cena, kterou guardrails platí
Každá kontrola přidává latenci a peníze. Klasifikátor na vstupu i výstupu znamená tři volání místo jednoho. Agresivní nastavení navíc produkuje falešně pozitivní zásahy: zdravotnická poradna, které guardrail blokuje slovo „krev“, je nepoužitelná. Guardrails se proto ladí jako každý klasifikátor, na sadě reálných dotazů, s měřením falešně pozitivních a falešně negativních případů, a s logem každého zásahu pro pozdější revizi.
Vztah k regulaci
Guardrails jsou obvyklý technický způsob, jak doložit opatření požadovaná AI Actem a interními politikami: záznam o tom, že systém odmítá určité kategorie výstupů, že vysoce rizikové akce potvrzuje člověk a že se incidenty logují. Samotné guardrails ale nejsou compliance; jsou důkazním materiálem k ní.
Příklady z praxe
Výstupní guardrail vynucuje strukturu odpovědi
Chatbot podpory má vracet strojově zpracovatelný objekt s intentem a ID objednávky. Místo důvěry v prompt se odpověď validuje proti schématu a nevyhovující výstup se jednou zopakuje s chybovou hláškou v kontextu. Po druhém neúspěchu se konverzace předá operátorovi.
from pydantic import BaseModel, Field class Reply(BaseModel): intent: str = Field(pattern=r"^(refund|status|other)$") order_id: str | None message: str def guard(raw: str) -> Reply: reply = Reply.model_validate_json(raw) # vyhodí chybu při nevalidním výstupu if reply.intent == "refund" and not reply.order_id: raise ValueError("refund bez order_id") return replyAgent s právem mazat data
Interní agent nad firemní databází dostal nástroj pro SQL dotazy. Guardrail na úrovni oprávnění mu přidělí read-only roli, takže i kdyby prompt injection v načteném dokumentu přiměla model napsat DELETE, databáze příkaz odmítne. Druhá vrstva navíc loguje každý dotaz a nad limit řádků vyžaduje potvrzení člověkem.
Časté omyly
- MýtusGuardrails vyřešíme v system promptu, stačí napsat, co model nesmí.
- Ve skutečnostiSystémový prompt je jen další text, který model váží proti zbytku kontextu, a útočník ho může přebít formulací dotazu nebo obsahem načteného dokumentu. Tvrdou záruku dává až kontrola mimo model: validace výstupu, omezená oprávnění, filtr na vstupu.
- MýtusGuardrails jsou hlavně o vulgaritách a citlivých tématech.
- Ve skutečnostiVětšina produkčních guardrailů v podnikových aplikacích řeší nudnější věci: platný formát odpovědi, podloženost tvrzení v dodaných dokumentech, únik osobních údajů a rozsah akcí, které smí agent provést.
- MýtusČím přísnější guardrails, tím lépe.
- Ve skutečnostiPřísné nastavení zvyšuje počet falešně pozitivních blokací a produkt se stane nepoužitelným pro legitimní dotazy. Guardrails se ladí měřením obou typů chyb na reálných datech, ne intuicí.
Časté dotazy
- Jak poznám, že jsou guardrails nastavené příliš přísně?
- Přísnost guardrailů se pozná z logu zásahů. Když si projdete vzorek zablokovaných dotazů a významná část z nich jsou legitimní požadavky uživatelů, jde o falešně pozitivní zásahy a pravidlo je moc široké. Pomáhá měřit dvě čísla vedle sebe: podíl legitimních dotazů, které guardrail zablokoval, a podíl skutečně problematických, které prošly. Bez logování obou stran se ladí naslepo a tým obvykle přitvrzuje, dokud uživatelé produkt neopustí.
- Kolik latence guardrails přidají?
- Latence guardrailů závisí na jejich typu. Deterministické kontroly, tedy regulární výrazy, seznamy zakázaných řetězců nebo validace JSON schématu, běží v jednotkách milisekund a jsou prakticky zdarma. Kontrola druhým modelem přidá další volání API, tedy typicky stovky milisekund až sekundy, a to na vstupu i na výstupu. Vstupní filtr lze pustit paralelně s hlavním voláním, výstupní ne, protože potřebuje hotovou odpověď. U streamovaných odpovědí se proto kontroluje po částech nebo se první tokeny zadrží.
- Chrání guardrails proti prompt injection?
- Guardrails riziko prompt injection snižují, ale samy ho neodstraní. Vstupní klasifikátor zachytí zjevné pokusy typu "ignoruj předchozí instrukce", nezachytí ale injection ukrytou v načteném webu, PDF nebo e-mailu, který agent zpracovává jako data. Spolehlivější obranou je omezení dopadu: agent dostane jen ta oprávnění, která nutně potřebuje, nevratné akce potvrzuje člověk a nedůvěryhodný obsah se od instrukcí odděluje. Guardrails a princip nejmenších oprávnění se doplňují, nenahrazují.
- Mám guardrails psát sám, nebo použít hotovou knihovnu?
- Volba mezi vlastní implementací a knihovnou se řídí tím, kolik pravidel má aplikace. Pro jeden nebo dva kontrolní body bývá vlastní kód s Pydantic validací a několika pravidly čitelnější a rychlejší než framework. Hotová řešení, například NeMo Guardrails nebo moderační API poskytovatelů modelu, dávají smysl tam, kde přibývají politiky, potřebujete jednotné logování napříč aplikacemi a nechcete udržovat vlastní klasifikátory. Většina týmů kombinuje obojí: knihovnu na obsahovou moderaci a vlastní kód na doménová pravidla.
Zdroje
- OWASP Top 10 for Large Language Model Applications(otevře se v novém okně)
- AI Risk Management Framework(otevře se v novém okně)
- Azure AI Content Safety documentation(otevře se v novém okně)
- Amazon Bedrock Guardrails(otevře se v novém okně)