Gå til indhold
atlas

Guardrails (sikkerhedsværn)

Også kendt som: AI-guardrails, sikkerhedsfiltre

Kontroller rundt om et AI-system, der stopper usikre forespørgsler på vej ind og skadelige eller lækkende svar på vej ud.

Kladde - dette opslag er endnu ikke gennemgået.

Formelt

Regler, filtre og små kontrolmodeller, der kører før og efter en stor sprogmodel og tjekker input og output mod en politik - blokerer jailbreak-forsøg, fjerner personoplysninger, tvinger et tilladt format - uafhængigt af, hvordan modellen er trænet.

Forklaret enkelt

Som autoværnet langs en bjergvej - det styrer ikke bilen, men det forhindrer den i at køre ud over kanten, når føreren laver en fejl.

I praksis

Kundeservicechefen i en webshop lader hver chatbesked passere et filter, der markerer jailbreak-formuleringer, og hvert svar passere et andet, der skjuler kortnumre, før kunden ser det.

Hvorfor det betyder noget

Træning gør aldrig en model helt sikker, så eksterne kontroller giver en ekstra forsvarslinje, der kan testes, og som ejeren hurtigt kan ændre uden at træne modellen igen.

Sådan kommer du i gang

De typiske trin i rækkefølge. Tilpas dem til jeres organisation.

  1. Skriv en kort politik for applikationen om, hvad den aldrig må tage imod eller sige, fx jailbreak-forsøg, personoplysninger som CPR- og kortnumre, hemmeligheder og indhold, der er skadeligt eller uden for emnet, og hvilket outputformat der er tilladt.
  2. Kortlæg de steder, hvor kontroller kan sidde, nemlig brugerens besked, hentede dokumenter, værktøjsresultater, værktøjskald og det endelige svar, og beslut, hvilken regel der gælder hvor.
  3. Start med deterministiske kontroller, fx regulære udtryk med Luhn-tjek for kortnumre, tilladelseslister for URL'er og domæner, længdegrænser og JSON Schema-validering af struktureret output.
  4. Tilføj klassifikatorer til det, regler ikke kan fange, fx en detektor for prompt injection på brugerinput og hentet indhold, en sikkerhedsklassifikator på svar og en PII-detektor, og brug kun en LLM som dommer, hvor intet enklere virker.
  5. Beslut for hver kontrol, om den blokerer, omskriver, maskerer, spørger brugeren igen eller sender sagen videre til et menneske, og log hvert fund uden at gemme flere personoplysninger end nødvendigt.
  6. Opbyg et mærket testsæt med almindelige forespørgsler og angreb, også på dansk, kodede og fordelt over flere ture, mål falske positiver og falske negativer, og justér tærsklerne til den enkelte use case.
  7. Kontrollér ved streamede svar teksten i bidder med mulighed for at trække den tilbage, eller hold højrisikosvar tilbage, til output-kontrollen har set dem i fuld længde.
  8. Kør testsættet igen, hver gang model, prompt eller guardrail ændres, tilføj nye angreb fra hændelser og red teaming, og gennemgå blokeringsrater og brugerklager hver måned.

Typiske faldgruber

  • Kun at kontrollere brugerens besked, mens indirekte prompt injection kommer ind via hentede dokumenter, websider og værktøjsresultater.
  • At behandle et guardrail som en mur i stedet for en klassifikator med fejlrater og give agenten brede rettigheder, fordi filteret nok skal fange misbrug.
  • Kun at tune på engelske eksempler, så danske, kodede eller opdelte angreb slipper lige igennem.
  • At blokere så meget, at brugerne giver op og går over til ustyrede AI-værktøjer.

Gode vejledninger

Teknisk uddybning

Arkitektonisk er guardrails håndhævelsespunkter for politik i requestflowet i en LLM-applikation, på linje med en WAF eller en DLP-gateway. NVIDIAs NeMo Guardrails gør trinene eksplicitte: input-rails på brugerens besked, retrieval-rails på RAG-bidder, før de kommer ind i konteksten, dialog-rails, der styrer samtalens forløb (defineret i sproget Colang), execution-rails rundt om værktøjskald og output-rails på det genererede svar. Hvert trin kan afvise, omskrive, maskere, stille et opklarende spørgsmål eller eskalere til et menneske. Det er kontrollen af hentet indhold og værktøjsresultater - ikke kun af brugerens besked - der gør guardrails relevante over for indirekte prompt injection.

Implementeringerne falder i tre klasser. Deterministiske kontroller: regulære udtryk og validatorer for kortnumre (med Luhn-tjek), CPR-numre, formater for API-nøgler, allow-lists for URL'er og domæner, længdegrænser og JSON Schema-validering af struktureret output. Klassifikatormodeller: særligt trænede sikkerhedsklassifikatorer som Metas Llama Guard-familie (en LLM finjusteret til at mærke prompts og svar efter en skadestaksonomi, fra Llama Guard 3 tilpasset MLCommons' taksonomi), detektorer for prompt injection som Prompt Shields i Azure AI Content Safety og PII-detektorer baseret på named-entity recognition. LLM-as-judge: en anden model, der med en politik i prompten bedømmer svaret. Constrained decoding - generering styret af en grammatik eller et skema - er en beslægtet teknik, der forhindrer ugyldigt output allerede under genereringen i stedet for at filtrere det bagefter.

Ethvert guardrail er en klassifikator med en rate for falske positiver og en for falske negativer, og begge tæller: overblokering driver brugerne over i ustyrede værktøjer, underblokering lukker angreb igennem. Guardrails bør evalueres på mærkede testsæt, også med flersprogede og kodede varianter, og tærsklerne bør tilpasses den enkelte use case. Kendte svagheder er obfuskering (Base64, homoglyffer, en payload delt over flere ture), sprog med få træningsdata, som klassifikatoren ikke er trænet på, at klassifikatoren selv kan rammes af prompt injection, når den er en LLM, og streaming, hvor tokens når brugeren, før en output-kontrol har set hele svaret; modtrækket er kontrol i bidder med mulighed for at trække svaret tilbage eller buffering af højrisikosvar. Hvert ekstra modelkald giver også mere latens og flere omkostninger.

Guardrails supplerer alignment frem for at erstatte det: alignment ændrer, hvad modellen er tilbøjelig til at producere, guardrails begrænser, hvad applikationen tager imod og sender ud, og de kan opdateres på timer uden gentræning. Ingen af dem erstatter mindst mulige rettigheder til værktøjer, for et filter kan omgås, men en rettighed, agenten ikke har, kan ikke misbruges. OWASP's LLM Top 10 anbefaler filtrering af input og output som et lag mod LLM01 Prompt Injection, LLM02 Sensitive Information Disclosure og LLM05 Improper Output Handling, og NIST AI 600-1 behandler indholdsfiltrering som én af flere risikostyringshandlinger for generativ AI.

Hvad du bør lære først

Alt det, dette bygger på - grundlaget først.

  1. Token
  2. →Transformer
  3. →Stor sprogmodel (LLM)
  4. →Guardrails (sikkerhedsværn)

Relationer

Forveksl ikke med
AI-alignment

Kilder og videre læsning

Standarder og officielle tekster

  • NIST AI 600-1 - Artificial Intelligence Risk Management Framework, Generative AI Profile · NIST

Opslagsværker

Hvor dataene kommer fra

Dette opslag er skrevet af en AI ud fra kilderne ovenfor og er endnu ikke gennemgået af et menneske. Brug det som udgangspunkt, og tjek alt vigtigt mod kilderne.

Se gennemgangskøenForeslå en rettelse på GitHubDette begreb som JSON

Test dig selv

Indlæser…

Atlas er i beta.