Typowy pipeline AI Guardrails w produkcyjnej aplikacji LLM: (1) Input intake - użytkownik wysyła prompt do aplikacji; (2) Input guardrails: (a) PII detection (regex + ML) - jeśli wykryte, redakcja lub odmowa; (b) prompt injection detection (klasyfikator ML, semantyczne wzorce, np. Llama Guard); (c) topic classifier - czy pytanie jest w scope aplikacji ('rails' w Colang); (d) rate limiting, abuse detection na podstawie historii użytkownika; (3) Model invocation - jeśli input przeszedł guardrails, prompt trafia do LLM z opcjonalnym system prompt zawierającym dodatkowe wytyczne bezpieczeństwa; (4) Tool-use guardrails - w agentic setups: przy każdym tool call sprawdzany jest allowlist, permissions, budżet tokenów/wywołań; (5) Output guardrails: (a) toxicity/harm detection (Perspective API, Llama Guard); (b) hallucination detection przez grounding vs knowledge base; (c) format validation (JSON schema, regex); (d) fact-checking dla domen wysokiego ryzyka (medical, legal, financial); (6) Delivery - jeśli output przeszedł guardrails, zostaje zwrócony; w innym wypadku standardowa odpowiedź 'Nie mogę pomóc z tym zadaniem' lub retry z bardziej restrykcyjnym system promptem; (7) Logging i telemetria - każdy triggered guardrail loguje się do SIEM/observability platform (Datadog, Grafana) dla audytu compliance. Framework NeMo Guardrails używa DSL Colang do deklaratywnego definiowania rails ('when user asks about X, respond Y'), co eliminuje potrzebę pisania kodu Pythonowego dla każdej polityki.
Same wagi modelu (nawet po RLHF i Constitutional AI) nie są wystarczającą warstwą bezpieczeństwa dla deploymentu produkcyjnego. Modele: (a) czasem generują treści niezgodne z polityką aplikacji (mimo alignmentu ogólnego), (b) można ich zjailbrekować adversarialnymi promptami, (c) w agentic setups mogą wywoływać niebezpieczne narzędzia lub eksfiltrować dane, (d) różne aplikacje (dziecięcy chatbot, medical assistant, code review tool) mają fundamentalnie różne polityki bezpieczeństwa - a jedna waga modelu nie może być zoptymalizowana na wszystkie naraz. AI Guardrails rozwiązują to przez wprowadzenie warstwy runtime, w której każda aplikacja definiuje własne polityki, filtry i sanity checks - bez zmian w modelu bazowym. To umożliwia szybką iterację polityk, compliance i personalizację per use case.
Warstwa filtrów wejściowych walidująca prompt przed wysłaniem do LLM. Odpowiedzialności: PII detection i redakcja (email, SSN, karty), prompt injection detection (ML klasyfikator), topic scope filtering, rate limiting, abuse detection. Popularne implementacje: Llama Guard, Guardrails AI validators, Presidio (PII).
Oficjalna
Filtry walidujące odpowiedź modelu przed dostarczeniem użytkownikowi. Sprawdzają: toxicity/harm (Perspective API), hallucination (RAG-grounding, LLM-as-judge), format compliance (JSON schema, regex), factual accuracy dla domen wysokiego ryzyka.
Oficjalna
W agentic AI: kontrola wywołań narzędzi (tool calls). Egzekwują allowlist/denylist tools, permission checks (RBAC), budżet tokenów i wywołań na sesję, dry-run mode dla wrażliwych akcji (delete, transfer). Zapobiegają scenariuszom typu 'agent kasuje bazę danych'.
Oficjalna
Reguły egzekwujące topical scope przez cały dialog: 'chatbot zawsze zostaje w tematyce ubezpieczeń zdrowotnych', 'nie dyskutuje o konkurencji', 'nie udziela porad prawnych'. Zwykle definiowane deklaratywnie (Colang DSL w NeMo, YAML w Guardrails AI).
Oficjalna
Standardowe odpowiedzi dostarczane użytkownikowi gdy triggered zostanie guardrail: 'Nie mogę pomóc z tym zadaniem', 'To wykracza poza mój zakres', 'Skontaktuj się z zespołem obsługi'. Powinny być gramatycznie neutralne, nie leak'ować wewnętrznych zasad (zapobiega jailbreakowi typu 'jakie masz zasady?').
Oficjalna
Warstwa logowania każdego triggered guardrail do SIEM (Datadog, Splunk, Grafana). Kluczowa dla compliance (EU AI Act, HIPAA, SOC 2 wymagają dowodu działania guardrails), dla optymalizacji polityk (fałszywe pozytywy) i dla red-teamingu (analiza jailbreak attempts).
Każda warstwa guardrails dodaje 10-500ms do TTFT. Full stack input+output+tool guardrails z LLM-as-judge może dodać 1-2s do każdego wywołania - niepraktyczne dla real-time chat.
Za restrykcyjne guardrails blokują legitimate queries (np. medyczne pytanie interpretowane jako self-harm). User przenosi się do konkurencji bez guardrails.
Ataki typu DAN (Do Anything Now), roleplay bypass, encoding tricks (base64, rot13), multi-turn incremental jailbreaks obchodzą naive input guardrails. Guardrails muszą ewoluować z każdym nowym typem ataku.
Zbyt szczegółowe refusal messages ('Nie mogę pomóc bo policy XYZ zabrania Z') pozwalają atakującemu na reverse-engineering polityk i konstruowanie targeted bypass.
Każdy hyperscaler (AWS, Azure, GCP) ma własny format guardrails - migracja między providerami wymaga przepisania wszystkich polityk. Podobnie NeMo Colang vs Guardrails AI RAIL.
OpenAI wydaje darmowe API klasyfikujące treść wg 11 kategorii harm. Prekursor guardrails as a service.
Publikacja Constitutional AI (Bai et al.) formalizuje self-critique i alignment przez zasady konstytucyjne. Fundament dla guardrails z RLHF.
Nvidia wypuszcza NeMo Guardrails - framework z DSL Colang do deklaratywnego definiowania rails. Popularyzuje termin 'guardrails' w społeczności LLM.
Alternatywny framework Python-first z validators, RAIL spec (Reliable AI Markup Language) - komercyjny startup.
Sierpień 2023 - OWASP publikuje listę Top 10 zagrożeń LLM (prompt injection, insecure output handling, training data poisoning, model DoS, etc.), która staje się branżowym standardem taxonomii guardrails.
Meta wydaje Llama Guard 1/2 - fine-tuned Llama 2 do klasyfikacji promptów i odpowiedzi jako safe/unsafe. Popularizes ML-based guardrails.
Wielka trójka hyperscalerów wprowadza własne guardrails jako managed services - standard produkcyjny dla enterprise LLM.
Meta wydaje Llama Guard 3 z wsparciem obrazów - guardrails na multimodal AI systems.
Artykuł 15 EU AI Act nakłada obowiązek 'robust and cybersecure' guardrails dla systemów wysokiego ryzyka. Compliance staje się warunkiem koniecznym marketu europejskiego.
Tracebit pokazuje, że guardrails można wykorzystać do zatrzymywania atakujących AI hacking agents przez planted trigger payloads w decoy secrets. Rewolucja w defensywnym użyciu guardrails.
Fundamentalny trade-off: więcej false positives (frustracja użytkowników) vs więcej false negatives (naruszenia polityki). Konfiguracja per aplikacja i per użytkownik (child mode vs adult).
Które warstwy są aktywne. Minimalny setup ma input+output; enterprise typowo wszystkie 6.
Klucz do jakości: rule-based (regex/keywords), ML classifier (Llama Guard, custom BERT), LLM-as-judge. Wpływa na koszt, latencję i skuteczność.
Kiedy guardrail nie jest pewny (score między 0.3-0.7): fail-open (przepuść z warningiem), fail-closed (zablokuj), retry (zapytaj z modyfikowanym promptem).
Aktywność guardrails jest wysoce input-dependent - większość promptów przechodzi przez wszystkie filtry bez triggerowania niczego. Tylko podejrzane wejścia aktywują pełną ścieżkę policy resolution.
Guardrails routują flow aplikacji na podstawie decyzji polityk: pass = kontynuuj do modelu, block = zwróć refusal, transform = zmodyfikuj prompt/output i kontynuuj, retry = powtórz z bardziej restrykcyjnym system promptem.
Latencja guardrails jest kluczowa dla UX - każda dodatkowa warstwa zwiększa TTFT (time to first token). Guardrails muszą być O(10-100x) szybsze niż samo wywołanie LLM.
Większość guardrails to lekkie klasyfikatory (BERT, DistilBERT, small LM) lub reguły - działają idealnie na CPU z opóźnieniem <50ms. Nie wymagają GPU.
Dla LLM-as-judge guardrails (silny model oceniający wyjście słabszego) potrzebne GPU. Llama Guard 3B może działać na consumer GPU (RTX 4060+).
Rule-based guardrails (regex, keyword lists, YAML policies) są w pełni hardware-agnostic - działają wszędzie, gdzie działa runtime aplikacji.
