Så sätter jag guardrails runt AI utan att döda användarupplevelsen

Det enklaste sättet att göra en AI-produkt "säker" är att göra den oanvändbar: fråga om godkännande hela tiden, blockera allt ovanligt och ge modellen nästan ingen möjlighet att agera. Det näst enklaste är motsatsen: ge agenten bred access och hoppas att en bra systemprompt håller den på rätt sida. Jag försöker bygga mellan de två ytterligheterna. För mig har guardrails blivit mindre av ett "AI-safety-filter" och mer av produktarkitektur.

Guardrails börjar med behörighet, inte prompten

Den viktigaste frågan är inte "vad har jag sagt åt modellen att göra?" utan: Vad kan modellen faktiskt göra om instruktionen missförstås, prompt-injectas eller bara blir fel?

OWASP beskriver "Excessive Agency" som risker som uppstår när ett LLM-system får för mycket funktionalitet, för stora behörigheter eller för hög autonomi. Det är en mer användbar startpunkt än att försöka formulera en perfekt säkerhetsprompt.

I contentfabriken jag byggt får Researcher exempelvis forska och samla evidens. Den får inte publicera. Writer får skriva från godkända claims. Den får inte uppfinna källor. Publisher Gate får avgöra READY/BLOCKED, men får inte reparera evidens som saknas. Det är en guardrail genom separation of duties.

Min standard: read-only först

När jag kopplar en agent till ett nytt system börjar jag helst med read-only. Agenten får:

• läsa relevanta filer,
• söka dokumentation,
• analysera,
• föreslå en förändring.

Först när jag förstår felmoderna får den skriva, och även då så smalt som möjligt.

Det är samma idé som principen om least privilege i vanlig säkerhet. OpenAI beskriver i sin egen Codex-säkerhet hur agenters åtkomst, approvals och telemetry behöver vara explicita när de arbetar mot riktiga utvecklingssystem.

Det som är bra med detta UX-mässigt är att låg-risk-steg fortfarande kan vara snabba. Du behöver inte fråga användaren om lov för att läsa fem redan godkända dokument. Du behöver däremot kanske fråga innan agenten skickar ett mejl, publicerar en artikel eller skriver över data.

Tre lager av guardrails

Jag delar numera upp dem i tre lager.

1. Före modellen. Här kontrollerar jag input och kontext. Exempel:

• vilken användare gör anropet?
• vilken tenant/projekt hör datan till?
• vilka verktyg behövs för just den här uppgiften?
• får modellen ens se den här typen av data?
• finns kända prompt-injection-mönster eller otillåtna instruktioner i input?

Ju mer man kan avgöra deterministiskt före modellen, desto mindre behöver modellen bära.

2. Runt modellen. Här begränsar jag handlingsutrymmet. Exempel från min contentpipeline:

Det är mycket starkare än "följ processen noggrant".

3. Efter modellen. Här validerar jag output innan något händer i världen.

• schema validation,
• required fields,
• source references,
• policy checks,
• diff review,
• riskklassning,
• mänskligt godkännande vid högrisksteg.

OpenAI rekommenderar också lager av specialiserade guardrails snarare än att förlita sig på en enda kontroll. Det kan exempelvis vara regler, klassificerare och LLM-baserade kontroller tillsammans.

Human-in-the-loop utan klickhelvete

Den stora UX-risken med guardrails är confirmation fatigue. Om användaren måste godkänna tio små steg lär de sig snabbt att klicka "OK" utan att läsa. Då har jag skapat ceremonier, inte säkerhet.

Jag vill därför främst lägga approvals på tre typer av handlingar:

• Irreversibla. Radera, publicera, skicka, betala.
• Hög påverkan. En felaktig handling kan påverka kund, ekonomi, juridik eller förtroende.
• Låg verifierbarhet. Systemet kan inte själv med rimlig säkerhet kontrollera att beslutet är rätt.

Resten kan i många fall flyta automatiskt med loggning och möjlighet att backa.

Abstention är en produktfunktion

En av de bästa guardrails jag har lagt till i flera typer av system är möjligheten att säga:

"Jag kan inte bedöma det här på tillgängligt underlag."

Det gäller särskilt finansiell analys och faktatungt content. Det kan kännas som sämre UX eftersom användaren inte får ett omedelbart svar. I praktiken är det ofta bättre än ett övertygande svar byggt på luckor. Jag använder därför explicita states som BLOCKED, UNRESOLVED och NOT READY. Det gör osäkerheten maskinläsbar och möjlig att följa upp.

Guardrails ska vara observerbara

Om en agent stoppas vill jag veta varför. Bra loggar bör åtminstone kunna svara på:

• vilken agent agerade?
• vilken state var artikeln/ärendet i?
• vilka tools kallades?
• vilken regel stoppade flödet?
• vilket underlag användes?
• vad hade hänt om kontrollen inte funnits?

Det är här agent telemetry blir central. Säkerhet utan observerbarhet gör det svårt att förbättra både modellen och UX:en, eftersom alla stopp ser likadana ut från utsidan.

Ett konkret exempel: min publisher gate

I stället för att säga "publicera bara om artikeln är bra" har jag gjort kraven explicita:

Det viktiga är nästa regel: Publisher Gate får inte skriva om en claim för att få den att passera. Om evidensen saknas skickas ärendet uppströms. Det hindrar det klassiska agentproblemet där varje downstream-steg försöker vara hjälpsamt och gradvis maskerar att grundunderlaget var dåligt.

Rätt byggda guardrails gör faktiskt produkten enklare. De kan:

• förifylla säkra defaults,
• stoppa uppenbart ogiltiga val tidigt,
• automatisera låg-risk-arbete,
• eskalera bara det svåra,
• förklara exakt vad som saknas,
• låta användaren återuppta från rätt state i stället för att börja om.

Det är därför jag inte ser guardrails som ett lager man lägger ovanpå AI-produkten efteråt. De definierar vad produkten är kapabel att göra, när den får göra det och hur den beter sig när den inte vet. Det är både säkerhetsarkitektur och UX-arkitektur på samma gång.

Guardrails som state machine, inte bara filter

En stor del av mina guardrails ligger inte i textmoderation över huvud taget. De ligger i vilket state ett objekt befinner sig i. Ett contentjobb kan exempelvis ha:

Om draft -> published inte är en tillåten transition kan ingen välformulerad modellprompt hoppa över QA:n. Det är en stark kontroll eftersom den ligger utanför språkmodellen. Samma idé fungerar i andra produkter:

Agenten kan hjälpa till att bedöma eller förbereda. Men transaktionens livscykel styrs av systemet.

Output validation är underskattat. Många AI-fel blir enklare att hantera om output måste följa ett schema. Säg att nästa komponent kräver:

Då kan kod kontrollera:

• saknas required fields?
• är enum-värden giltiga?
• finns blockers trots PASS?
• refererar claim IDs till något som existerar?
• överskrider modellen sin behörighet?

En modell som producerar en fantastisk essä men inget verdict har inte gjort jobbet. Det är därför jag föredrar att göra agent-handoffs explicita. De blir både promptkontrakt och maskinvalideringskontrakt.

Retry är också en guardrail. "Försök igen" låter oskyldigt, men retries kan öka både kostnad och risk. Om en agent misslyckas på grund av ett transient API-fel är retry rimligt. Om den misslyckas för att evidensen saknas kommer tio retries bara generera tio varianter av samma osäkerhet. Jag vill därför skilja på feltyper:

Det här är ett exempel på hur en bra guardrail samtidigt förbättrar UX. Användaren får rätt lösning för felet i stället för att systemet spinner.

Prompt injection och extern data

När en agent läser webbsidor, mejl, dokument eller tickets behandlar jag texten som data, inte som nya systeminstruktioner. Det är lättare sagt än gjort eftersom en LLM läser allt som tokens. Men arkitekturen kan hjälpa:

• verktyg output märks som untrusted content,
• systeminstruktioner säger att instruktioner i retrieved content inte ska följas,
• verktygsbehörighet begränsas ändå,
• känsliga actions kräver separat validering,
• output från retrieval kan sanitiseras eller struktureras innan nästa steg.

Den sista kontrollen är viktig: även om prompt injection lyckas påverka modellen ska blast radius vara liten.

Privacy guardrails bör byggas före retrieval. Det räcker inte att säga åt modellen "var försiktig med personuppgifter" efter att all data redan skickats in i kontexten. Jag vill hellre kontrollera:

1. behöver den här agenten datan?
2. kan den minimeras?
3. kan identifierare pseudonymiseras?
4. får den skickas till vald modell/provider?
5. måste output redigeras innan nästa system får den?

Det är klassisk privacy engineering, men agentiska workflows gör frågan mer akut eftersom data kan flyta genom flera steg och verktyg.

Tool choice kan begränsas per state

En agent behöver inte samma tools hela tiden. Research state kan ha web search och read access. Draft state behöver kanske bara läsa approved evidence och skriva i draftmappen. Publish state behöver publiceringsverktyget, men inget web search-tool. Det minskar både kognitiv komplexitet och risk. Jag gillar därför permissions som ser ungefär ut så här:

Det är mer jobb än global tool access. Men systemets beteende blir mycket lättare att förklara.

Guardrails ska testas adversarialt

Det är lätt att testa happy path: "skriv en artikel från de här källorna." Guardrails behöver andra testfall:

• källan innehåller "ignore previous instructions",
• en källa saknas men användaren ber systemet "gissa rimligt",
• två trovärdiga källor motsäger varandra,
• användaren ber agenten hoppa över approval,
• tool returnerar malformed data,
• samma action skickas två gånger,
• modellen försöker använda ett verktyg den inte behöver,
• en downstream-agent introducerar en ny factual claim.

Jag vill att testsuiten visar att systemet misslyckas på rätt sätt.

Mät false positives och false negatives separat. En överaggressiv guardrail kan vara lika destruktiv för användarupplevelsen som en för svag. Därför vill jag veta:

• hur ofta stoppar vi något som borde fått gå igenom?
• hur ofta missar vi något som borde stoppats?
• vilka block-regler skapar mest friktion?
• vilka typer av incidenter är dyrast?

För ett kreativt verktyg kan false positives vara ett stort UX-problem. För en betalningsagent kan false negatives vara mycket dyrare. Guardrail-trösklar ska därför bero på use case, inte på en universell "safe"-nivå.

Progressive autonomy

Jag gillar att öka autonomi gradvis.

• Fas 1 – Suggest. AI föreslår. Människa utför.
• Fas 2 – Prepare. AI förbereder action. Människa godkänner.
• Fas 3 – Execute low risk. AI får utföra reversibla låg-risk-actions automatiskt.
• Fas 4 – Broader autonomy. Fler actions automatiseras först när evals, logs och incidentdata visar att systemet klarar dem.

Det här är ett bättre sätt att lansera än att börja med "full agent" och sedan dra tillbaka permissions efter första incidenten.

Min guardrail-checklista

Innan en agent får mer frihet går jag igenom:

1. Har den minsta möjliga tool set?
2. Är read/write/delete separerade där det går?
3. Finns explicit state machine?
4. Valideras output maskinellt?
5. Finns idempotency för muterande actions?
6. Är retries begränsade och felklassade?
7. Kan agenten säga BLOCKED/NEEDS_HUMAN?
8. Loggas tool calls och beslut?
9. Finns adversarial tests?
10. Vet vi vilka fel som är dyrast?
11. Kan blast radius begränsas om modellen gör fel?
12. Finns rollback eller recovery?

Det här är guardrails som användaren sällan ser. Just därför kan UX:en kännas snabbare, inte långsammare.

Alla guardrails måste inte vara osynliga. I vissa fall är UI den bästa kontrollen. Ett fritt promptfält kan exempelvis ersättas av tydliga val där användaren väljer mål, datakälla eller risknivå. Det minskar både prompt ambiguity och behovet av att tolka vad användaren menade.

I ett CV-verktyg kan en ändring visas som diff med "godkänn/avvisa". I en contentpipeline kan blockerade claims listas med exakt saknad källa. I en agent som ska utföra en extern handling kan UI:t visa en kort preview av vad som kommer att skickas eller ändras innan approval. Det är guardrails som samtidigt bygger förtroende.

Jag försöker också undvika att kritiska regler bara finns i systemprompten. Om en regel säger att en agent aldrig får publicera utan fact-check PASS bör den finnas i workflow/state machine eller permissions, inte bara i prose. Prompten kan förklara varför och hur agenten ska bete sig, men enforcement bör ligga så nära den faktiska handlingen som möjligt. En bra tumregel är:

Ju dyrare ett fel är, desto mindre bör säkerheten bero på att modellen "minns" instruktionen.

Innan en agent ska få skriva till ett riktigt system skulle jag köra ett litet red-team-batteri först. Jag skulle försöka få den att:

• använda ett otillåtet tool,
• hoppa över approval,
• följa instruktioner från retrieved content,
• skriva ut secrets,
• utföra dubbla actions efter timeout,
• agera på en tvetydig begäran,
• fortsätta efter att en upstream gate är BLOCKED.

Varje lyckad attack blir ett regressionstest. På så sätt byggs guardrail-sviten från verkliga failures i stället för generiska checklistor.

Jag vill inte att användaren ska känna att de arbetar med en produkt som är full av säkerhetsbromsar. Jag vill att produkten ska kännas snabb därför att de lågriskbeslut som går att automatisera redan är automatiserade, medan systemet blir försiktigt exakt där felet kan göra verklig skada. Bra guardrails är därför inte "mer nej". De är bättre gränser: rätt agent, rätt tool, rätt state, rätt data och rätt mänskligt beslut vid rätt tidpunkt.

Recovery är en del av guardrailen. Ett system som kan stoppa en farlig action men inte återhämta sig från ett halvfärdigt flöde skapar fortfarande problem. För muterande workflows vill jag därför tänka på idempotency och recovery samtidigt som permissions. Om en request timeoutar efter att en extern action faktiskt lyckats ska retry inte skapa en dubblett. Praktiskt innebär det ofta idempotency keys, action IDs och ett loggat resultat från externa verktyg. Agenten ska kontrollera om handlingen redan skett innan den provar igen.

Samma princip finns i contentops: när ett steg är godkänt ska /resume fortsätta från nästa state, inte generera om research och riskera att skapa en ny version av sanningen.

Guardrails behöver en ägare. En annan produktionsfråga är vem som får ändra en guardrail. Om en blockeringsregel skapar friktion är det frestande att bara lätta på den. Jag vill att kritiska regler har en definierad owner och ett change-log: varför infördes regeln, vilket incident- eller riskfall adresserar den, och vilka evals måste passera om den ändras? Det gör säkerheten mindre beroende av muntligt minne. En framtida utvecklare eller agent kan se att en till synes irriterande kontroll finns där av en konkret anledning.

Börja med blast radius

Om jag måste prioritera guardrails i ett tidigt system börjar jag med frågan: vad är det värsta som kan hända om agenten tolkar instruktionen fel? Därifrån arbetar jag bakåt. Kan den bara skapa ett dåligt draft är blast radius liten. Kan den publicera, radera eller skicka data är den större.

Det gör prioriteringen konkret. Jag behöver inte lösa all AI-säkerhet på en gång. Jag behöver först begränsa konsekvensen av de fel som faktiskt är möjliga i min produkt. Därefter kan evals och incidentdata visa vilka kontroller som behöver bli mer sofistikerade.

I praktiken betyder det att jag hellre lanserar en begränsad agent som går att förstå, logga och återhämta än en imponerande agent med bred autonomi. När den mindre versionen bevisar sig kan behörigheter öppnas stegvis. Det är enklare att skala autonomi uppåt än att försöka ta tillbaka förtroende efter ett fel i produktion.

Det är också en mer ärlig produktstrategi: autonomi är något systemet förtjänar genom mätbar tillförlitlighet, inte en feature man aktiverar för att agenten verkar kapabel i en demo. Den lilla begränsningen är avsiktlig: systemet ska vara begripligt även när något går fel.

Källor och vidare läsning

• OWASP: LLM06:2025 Excessive Agency
• OpenAI: A practical guide to building AI agents
• OpenAI: Running Codex safely at OpenAI

Relaterade artiklar

• Så minskar jag blast radius när en agent får verktygsaccess
• Varför read-only är mitt defaultläge för nya AI-agenter
• Prompt injection i praktiken: vad jag skyddar mina agentflöden mot
• Min checklista innan ett AI-workflow får gå från prototyp till produktion
• AI-system i produktion: vilka metrics jag faktiskt följer