Derfor trenger AI-agenter grenser
Nøkkelinnsikt
- AI-agenter bør deles opp i små, samarbeidende enheter med minimale tilganger, ikke bygges som allmektige superagenter
- En 2x2-matrise med risiko og kapabilitet bestemmer hvordan hver agent bør styres, fra faste nøkler til dynamisk tilgangskontroll
- Agenter med høy kapabilitet bør være kortvarige, mens agenter med lav kapabilitet trygt kan kjøre over tid
- Agenter med høy risiko og høy kapabilitet trenger menneskelig godkjenning før de utfører viktige handlinger
Dette er et AI-generert sammendrag. Kildevideoen inneholder demonstrasjoner, visuelt innhold og kontekst som ikke dekkes her. Se videoen → · Slik lages artiklene våre →
Les denne artikkelen på engelsk
Kort fortalt
Grant Miller, teknologisjef for Access Transformation and Securing AI hos IBM, presenterer et rammeverk for å bygge AI-agenter, altså programmer som kan ta handlinger på egen hånd, slik at de holder seg innenfor trygge grenser. I stedet for å bygge én allmektig agent argumenterer Miller for å dele systemet opp i små, spesialiserte agenter som deles inn etter risiko og kapabilitet. Rammeverket bruker en 2x2-matrise til å bestemme hvordan hver agent bør oppføre seg: om den bør være kortvarig eller vedvarende, bruke fast eller dynamisk tilgang, og om et menneske må godkjenne handlingene.
Hva er ubegrenset handlefrihet?
Det populære bildet av AI-agenter er ett enkelt, allmektig system som kan gjøre alt og få tilgang til hva som helst. Miller kaller dette «Hollywood-synet» på agenter (0:34). Det høres imponerende ut, men skaper to problemer som gjør systemene utrygge.
Det første problemet er ubegrenset handlefrihet (super agency), der en agent har full frihet til å bestemme hva den gjør (2:10). Det andre er overprivilegering (over-privilege), der agenten har flere tilganger enn den trenger. Den kan lese, skrive, slette og oppdatere data selv om jobben bare krever lesing.
Forklart enkelt: Tenk deg at en nyansatt får hovednøkkelen til alle rom i bygningen, pluss fullmakt til å signere kontrakter, ansette folk og bruke bankkontoen allerede første dag. Et veldrevet selskap gir bare tilgang til det hver rolle faktisk trenger. I motsetning til en virkelig ansatt som kan forklare valgene sine hvis noen spør, kan en AI-agent ta beslutninger som er vanskelige å spore eller reversere.
Løsningen, ifølge Miller, er å minimere både handlinger og tilgang (3:06). Hver agent bør ha én bestemt oppgave og bare de tilgangene som trengs for den oppgaven. I programvareutvikling kalles dette høy kohesjon (high cohesion): en tett kobling mellom agenten, oppgaven og tilgangsnivået.
Risiko- og kapabilitetsmatrisen
Ikke alle agenter er like. Miller legger frem en 2x2-matrise som deler inn agenter langs to akser (5:39):
- Risiko: Hvis noe går galt, hvor mye skade kan skje? Lav risiko betyr begrenset skade. Høy risiko betyr at agenten berører sensitive systemer som finansdata eller kunderegistre.
- Kapabilitet: Hvor mye tenkearbeid må agenten gjøre? Lav kapabilitet betyr at den følger forhåndsbestemte steg uten egen vurdering. Høy kapabilitet betyr at den er ikke-deterministisk (non-deterministic): den vurderer situasjonen og velger sin egen vei.
Fire kvadranter med eksempler
Miller gir konkrete eksempler for hver kvadrant (6:01):
| Lav risiko | Høy risiko | |
|---|---|---|
| Høy kapabilitet | Intern stilguide-redigerer (omskriver tekst, ingen sensitive data) | Betalingssystem (vurderer fakturaer, starter utbetalinger) |
| Lav kapabilitet | RAG-basert wiki-oppslag (leser interne dokumenter, gir svar) | Finansdata-uttrekk (lesetilgang til sensitiv finansinformasjon) |
RAG står for gjenfinningsforsterket generering (retrieval-augmented generation), en teknikk der AI-en slår opp relevante dokumenter før den svarer på et spørsmål.
Forklart enkelt: Tenk på matrisen som ansettelse til ulike roller. En agent med lav risiko og lav kapabilitet er som en bibliotekar som finner og henter bøker. En agent med høy risiko og høy kapabilitet er som en økonomisjef som vurderer fakturaer, bestemmer beløp og overfører penger. Du ville ikke gitt begge rollene samme fullmakt. I motsetning til virkelige ansatte kan ikke agenter stilles til ansvar for feil, noe som gjør det enda viktigere å begrense autoriteten deres.
Fire atferdsregler for tryggere agenter
Når du vet hvor en agent hører hjemme i matrisen, beskriver Miller fire atferdsregler som bestemmer hvordan den bør fungere.
Steg 1 — Bestem agentens levetid
Agenter med høy kapabilitet bør være kortvarige (ephemeral) (9:56). Kortvarig betyr at agenten starter, gjør oppgaven sin og deretter forsvinner. Fordi disse agentene vurderer og tar ikke-deterministiske veier, skaper det unødvendig risiko å la dem kjøre over tid. Agenter med lav kapabilitet kan være vedvarende. De håndterer en bestemt oppgave som gjentas og kan fortsette å kjøre fordi oppførselen er forutsigbar.
Steg 2 — Velg tilgangsmodell
Agenter med høy kapabilitet trenger dynamisk tilgang (10:29). Fordi de vurderer hvilke systemer de skal samhandle med, bør tilgangene vurderes for hver vei de tar. Kan de koble til dette verktøyet? Kan de lese eller skrive? Hver beslutning vurderes ut fra hva agenten prøver å få til. Agenter med lav kapabilitet bruker faste tilganger (static credentials), den tradisjonelle modellen med API-nøkler, sertifikater og faste rettigheter (11:10).
Steg 3 — Legg til menneskelig godkjenning for høyrisikohandlinger
Når en agent befinner seg i kvadranten med høy risiko og høy kapabilitet, bør du legge til menneskelig godkjenning (human-in-the-loop) (11:51). Før agenten utfører en viktig handling, som å starte en betaling, stopper den opp og spør et menneske: «Denne handlingen skal nå utføres. Godkjenner du?» Først etter godkjenning fortsetter agenten.
Steg 4 — Bruk forretningskontroller for høyrisiko med lav kapabilitet
For agenter som håndterer sensitive data men følger forhåndsbestemte steg (som finansdata-uttrekket), bruker du vanlige forretningskontroller (12:17). Dette er de samme kontrollene organisasjoner allerede bruker for tradisjonelle automatiserte systemer: revisjonslogger, tilgangsgjennomganger og samsvarssjekker.
Sjekkliste: Vanlige fallgruver når du bygger agenter
- Bygger du en superagent? Hvis én agent håndterer flere urelaterte oppgaver, del den opp i mindre agenter med spesifikke ansvarsområder. Hver agent bør ha høy kohesjon mellom oppgave og tilgang.
- Har alle agentene de samme tilgangene? Vurder hver agent mot risiko- og kapabilitetsmatrisen. En wiki-oppslags-agent trenger ikke skrivetilgang til produksjonsdatabaser.
- Kjører agenter med høy kapabilitet i det uendelige? Gjør dem kortvarige. La dem starte, fullføre oppgaven og avslutte. Vedvarende agenter med høy kapabilitet samler opp risiko over tid.
- Finnes det et sjekkpunkt for høyrisikohandlinger? Enhver agent som kan endre finansdata, slette poster eller samhandle med eksterne systemer bør kreve godkjenning fra et menneske før den handler.
- Bruker du dynamisk tilgang der det trengs? Agenter med høy kapabilitet som vurderer sin egen vei trenger vurdering av tilganger for hver handling, ikke en fast API-nøkkel med blanke fullmakter.
Husk: Målet er ikke å gjøre agenter mindre nyttige. Det er å tilpasse hver agents autoritet til den faktiske oppgaven, slik at systemet forblir trygt etter hvert som det vokser.
Praktiske implikasjoner
For nybegynnere som utforsker AI-agenter
Start med agenter i kvadranten lav risiko, lav kapabilitet. Bygg en enkel RAG-basert oppslagsagent som leser dokumenter og gir svar. Gi den lesetilgang til én enkelt datakilde. Dette lærer deg kjerneprinsippet om minste privilegium (least privilege), altså å bare gi de tilgangene som faktisk trengs, uten å skape risiko.
For utviklere som bygger fler-agent-systemer
Plasser hver agent i risiko- og kapabilitetsmatrisen før du skriver kode. Dette avgjør arkitekturen: levetid, tilgangsmodell og om det trengs godkjenning fra mennesker. Agenter i øvre høyre kvadrant (høy risiko, høy kapabilitet) krever mest infrastruktur, så planlegg for dynamisk vurdering av tilganger og godkjenningsrutiner tidlig.
For organisasjoner som tar i bruk agenter i stor skala
Bruk matrisen som et verktøy for styring. Lag retningslinjer for hver kvadrant: hvilke tilgangskontroller som kreves, hvilke revisjonslogger som må finnes, og når menneskelig godkjenning er påkrevd. Dette gir teamene tydelige retningslinjer uten å bremse utviklingen for agenter med lav risiko.
Test deg selv
- Overføring: Hvordan ville du brukt risiko- og kapabilitetsmatrisen på et kundeservicesystem der agenter håndterer både enkle FAQ-oppslag og refusjonsbehandling?
- Avveining: Kortvarige agenter er tryggere, men koster mer å starte opp gjentatte ganger. Når ville du valgt en vedvarende agent med høy kapabilitet til tross for risikoen?
- Arkitektur: Lag et agentsystem for et sykehus som behandler pasientjournaler (høy risiko) og bestiller timer (lav risiko). Hvilke kvadranter havner agentene i, og hvilken tilgangsmodell ville du brukt for hver?
Ordliste
| Begrep | Forklaring |
|---|---|
| AI-agent | Et program som kan utføre handlinger på egen hånd, for eksempel lese filer, kalle API-er eller ta beslutninger, i stedet for bare å svare på spørsmål. |
| Dynamisk tilgang (dynamic access) | Tilganger som endrer seg basert på hva agenten gjør akkurat nå. Hver handling vurderes for seg, i stedet for å gi blanke fullmakter på forhånd. |
| Forhåndsbestemte handlinger (predetermined actions) | Faste steg som en agent alltid følger i samme rekkefølge. Agenten trenger ikke vurdere eller ta egne beslutninger. |
| Faste tilganger (static credentials) | Faste tilgangsnøkler som API-nøkler eller sertifikater som ikke endrer seg ut fra sammenhengen. Tradisjonell modell for enkle, forutsigbare systemer. |
| Høy kohesjon (high cohesion) | Et designprinsipp der agenten, dens enkeltoppgave og tilgangene den trenger henger tett sammen. Agenten gjør én ting godt og har nøyaktig de tilgangene den trenger for den ene tingen. |
| Ikke-deterministisk (non-deterministic) | Oppførsel der agenten vurderer og velger sin egen vei, i stedet for å følge faste steg. Samme input kan gi ulike handlinger avhengig av sammenhengen. |
| Kortvarig agent (ephemeral agent) | En agent som starter, gjør oppgaven sin og deretter avslutter. Det motsatte av en vedvarende agent som kjører kontinuerlig. |
| Menneskelig godkjenning (human-in-the-loop) | Et mønster der et menneske må vurdere og godkjenne agentens handling før den utføres. Brukes for høyrisikobeslutninger som betalinger eller sletting av data. |
| Minste privilegium (least privilege) | Et sikkerhetsprinsipp: gi bare de minimale tilgangene som trengs for å fullføre oppgaven. Ikke noe mer. |
| Overprivilegering (over-privilege) | Når en agent har flere tilganger enn oppgaven krever. For eksempel en agent som bare trenger å lese data, men som også har tilgang til å slette. |
| RAG (gjenfinningsforsterket generering) | En teknikk der AI-en slår opp relevante dokumenter før den lager et svar, i stedet for å bare bruke det den lærte under trening. |
| Ubegrenset handlefrihet (super agency) | Når en agent har full frihet til å bestemme hva den gjør, uten grenser for hva den kan foreta seg. |
| Vedvarende agent (persistent agent) | En agent som fortsetter å kjøre for å håndtere gjentatte oppgaver. Passer for agenter med lav kapabilitet og forutsigbar oppførsel. |
Argumentet for rekkverk blir sterkere når du sammenligner det med hvorfor AI-agenter trenger mer enn bare LLM-er og protokollaget forklart i A2A og MCP.
Kilder og ressurser
Vil du vite mer? Se hele videoen på YouTube →