Guardrails for AI-agenter: begræns handlinger, ikke bare ord
Guardrails er konkrete tekniske og organisatoriske grænser for, hvad agenten kan læse, beslutte og ændre.
Guardrails er konkrete tekniske og organisatoriske grænser for, hvad agenten kan læse, beslutte og ændre.
Start med konsekvensen
Klassificér værktøjer efter risiko: kun læsning, reversible skrivehandlinger, økonomisk/juridisk handling og ekstern kommunikation. Jo større konsekvens, desto stærkere kontrol.
Valider uden for modellen
Skema-validering, adgangskontrol, beløbsgrænser, allowlists og idempotens skal håndhæves i kode eller platform – ikke som en sætning i systemprompten.
Brug godkendelser målrettet
Kræv menneskelig godkendelse ved høj risiko, usikker klassifikation eller et nyt mønster. Lad ikke godkendelse blive en klik-ritual på alle trivielle trin.
Log det, du skal kunne forklare
Gem værktøjsvalg, input-id, relevante regelresultater, model/promptversion og den endelige handling uden ukritisk at logge følsomt indhold.
Case: refundering med beløbsgrænse og godkendelse
Agenten må læse ordredata og foreslå refundering. Under 250 kr. kan et valideret regelmatch behandles automatisk; større beløb eller uklare sager går til menneskelig godkendelse. Selve betalingssystemet håndhæver beløbsgrænsen – ikke prompten.
Tegn dine kontrol-lag omkring én kritisk handling
Lav en risikotabel over agentens værktøjer: kun læsning, reversibel skrivehandling og skrivehandling med høj konsekvens. Tilføj på serversiden kontrol og godkendelse til de sidste to kategorier.
Kontrol: prøv bevidst at bryde reglerne
- Kan modellen omgå en regel ved at formulere sig anderledes?
- Er høj-konsekvens handlinger begrænset uden for modellen?
- Kan du efterfølgende forklare hvilken regel, værktøjsversion og godkendelse der førte til handlingen?
Den stærkeste guardrail er ofte noget modellen ikke kan forhandle med
En systemprompt kan sige “refundér aldrig over 500 kr.”, men en rigtig beløbsgrænse bør ligge i kode eller workflowlogik. Samme princip gælder rettigheder, tilladte domæner, gyldige statusværdier og skema-validering.
Tænk i lag: inputfilter, værktøjsrettigheder, output-skema, regelkontrol, godkendelse og efterfølgende audit. Ikke alle use cases behøver alle lag, men kritiske handlinger bør have mindst én kontrol, der ikke afhænger af modellens fortolkning.
Guardrails skal også testes adversarialt. Giv agenten input, der beder den om at omgå reglerne, skjuler instruktioner i et dokument eller lokker den til at kalde et forkert værktøj. Sikkerhed er en adfærd, du måler – ikke en sætning i prompten.
Fire guardrail-lag du bør kunne pege på i arkitekturen
Adgang: hvem og hvad må agenten læse? Input/output: hvilke skemaer og værdier accepteres? Handling: hvilke værktøjer, rettigheder og beløbsgrænser gælder? Proces: hvornår kræves godkendelse, logging eller stop? Hvis alle fire kun er tekst i systemprompten, er løsningen for skrøbelig.
Byg værktøjer så den farlige handling er svær at udtrykke
Et refund-værktøj kan kræve et eksisterende order-id, et positivt beløb under en maksimal grænse og en godkendelsestoken. Det er bedre end et generelt betalings-værktøj plus en promptregel om at være forsigtig. Sikkerhed vokser, når ugyldige handlinger afvises teknisk.
Test guardrails adversarialt
Brug prompt injections i dokumenter, ugyldige værktøjsargumenter, manglende rettigheder, grænsebeløb, dubletter og forsøg på at springe godkendelse over. En guardrail er først interessant, når den har vist, at den stopper en realistisk fejl.
Log afvisninger som produktdata
Hvis samme guardrail rammer legitime opgaver igen og igen, er designet måske for bredt eller for snævert. Brug derfor afvisninger til at forbedre værktøjskontrakter og brugeroplevelse – uden at slække på selve sikkerhedskravet.