Artikler · Drift og governance · Del 4 af 5 · 6 min. læsning
AI-agenten kan sende mails og ændre i kundesystemet. Hvem bestemmer, hvad den må?
Først hjalp AI med et udkast. Nu kan løsningen også sende mailen, oprette opgaven og ændre oplysninger i kundesystemet. Det kan fjerne manuelt arbejde. Men virksomheden skal tage stilling til mere end kvaliteten af teksten. Den skal beslutte, hvilke handlinger løsningen må udføre, med hvilke oplysninger og på hvis ansvar.
Af Martin Egesø · Udgivet
Kort svar
Beskriv agentens konkrete opgave, og adskil det, den må læse, foreslå og udføre. Begræns adgang og handlinger teknisk til det nødvendige, aftal menneskelig godkendelse dér, hvor konsekvensen kræver det, og sørg for, at en ansvarlig kan undersøge og stoppe forløbet.
I artiklen 10 afsnit
- Hvad er en AI-agent, og hvad er forskellen på at læse, foreslå og udføre?
- Begynd med den handling, I vil slippe for
- Hvad sker der, hvis agentens adgang er bredere end opgaven?
- Skeln mellem at læse, foreslå og udføre
- Gør godkendelsen forståelig
- Prøv også det, agenten skal afvise
- Hvor kan SPOR hjælpe, og hvor skal kontrollen ligge?
- Typiske fejl, når en AI-agent får adgang
- Hvad kan I gøre nu?
- Ofte stillede spørgsmål
Det vigtigste
- Adskil, hvad agenten må læse, foreslå og udføre. Det er tre forskellige beslutninger.
- Begræns adgangen teknisk. En instruktion om kun at læse er ikke en teknisk spærring.
- Godkendelsen skal vise modtager og de konkrete ændringer.
- Prøv også det, agenten skal afvise, i et testmiljø med egnede testdata.
- En ansvarlig skal kunne undersøge og stoppe forløbet.
Dette er del 4 af serien om AI på tværs af virksomheden.
Hvad er en AI-agent, og hvad er forskellen på at læse, foreslå og udføre?
En AI-agent er en løsning, der ikke kun svarer, men kan tage handlinger i andre systemer, fx at sende en mail eller oprette en opgave. At læse giver adgang til oplysninger. At foreslå viser en handling, som et menneske kan godkende. At udføre ændrer noget i et system. Det er tre forskellige beslutninger med hver sin risiko.
Begynd med den handling, I vil slippe for
I seriens fiktive virksomhed har Mikkel en fungerende arbejdsgang for mødenoter. Nu vil han gerne have, at AI også opretter opfølgningsopgaver i CRM og sender en mail til kunden.
Det er en ny anvendelse. En beslutning om udkast til referater fortæller ikke, om løsningen må sende beskeder eller ændre i systemet.
Sofie beder ham beskrive de ønskede handlinger hver for sig. De opdager, at den største hjælp lige nu er at klargøre en opgave med kunde, ansvarlig og frist. Automatisk afsendelse kan vente, mens de undersøger behovet nærmere.
Hvis I er i tvivl om, hvorvidt opgaven kræver en agent, kan I begynde med AI-agent, automatisering eller integration?.
Hvad sker der, hvis agentens adgang er bredere end opgaven?
Er agentens adgang bredere end opgaven, kan en fejl eller en uventet besked få konsekvenser, ingen har besluttet. Går noget galt, skal nogen kunne svare på, hvem der gav adgangen, og hvem der kan stoppe den. Derfor bør ansvaret være aftalt, før agenten må handle. Læs også hvad I gør, når AI laver en fejl.
Skeln mellem at læse, foreslå og udføre
| Mulighed | Et spørgsmål til jeres leverandør eller udvikler |
|---|---|
| Læse udvalgte oplysninger | Kan adgangen begrænses til de relevante sager og felter? |
| Foreslå en handling | Kan brugeren se modtager, indhold og ændringer før godkendelse? |
| Udføre en handling | Hvilke præcise handlinger tillader systemet, og hvordan kontrolleres tilladelsen? |
| Arbejde på tværs af systemer | Hvem får data, og kan handlingen kontrolleres i hvert system? |
OWASP anbefaler blandt andet mindst mulige rettigheder og menneskelig godkendelse af handlinger med stor konsekvens. For brede funktioner, tilladelser og selvstændighed kan gøre en fejl mere alvorlig. Se OWASP: Excessive Agency.
En instruktion om “kun at læse” er ikke det samme som en teknisk læsebegrænsning. Bed om at få vist, at løsningen faktisk afviser handlinger uden for den besluttede adgang. OWASP beskriver også behovet for selvstændig kontrol af adgang og godkendelse, før agentens foreslåede handling udføres. Se AI Agent Security Cheat Sheet.
Gør godkendelsen forståelig
Hvis en medarbejder skal godkende noget, skal det være tydeligt, hvad der bliver gjort. “Fortsæt” giver ikke meget hjælp, hvis handlingen både sender en mail og ændrer en leveringsdato.
Min anbefaling er at vise modtager, de konkrete ændringer og det grundlag, medarbejderen har brug for. Godkendelsen skal gælde den handling, der faktisk udføres. Hvis indhold eller modtager ændres, skal det håndteres, før handlingen fortsætter.
I den fiktive virksomhed vælger Sofie og Mikkel først en arbejdsgang, hvor medarbejderen gennemgår opfølgningsopgaven før oprettelse. Det giver dem et afgrænset forløb at afprøve.
Prøv også det, agenten skal afvise
En demonstration af en vellykket opgave fortæller ikke, hvad der sker ved fejl. Bed den tekniske ansvarlige afprøve relevante grænser i et testmiljø med egnede testdata.
Eksempler på spørgsmål til prøven:
- Hvad sker der, hvis agenten vælger en kunde uden for den tilladte opgave?
- Kan samme godkendelse komme til at udløse handlingen to gange?
- Hvad sker der, hvis mailen indeholder en besked, som forsøger at ændre agentens instruktioner?
- Hvem opdager en fejl, og hvordan standses flere handlinger?
- Kan I se, hvad der blev ændret, og hvilke muligheder der er for at rette det?
Dette er et udgangspunkt for jeres samtale med leverandøren, ikke en fuldstændig sikkerhedstest. Ved adgang til følsomme systemer eller handlinger med væsentlige konsekvenser bør relevante specialister vurdere løsningen.
Hvor kan SPOR hjælpe, og hvor skal kontrollen ligge?
Sofie har brug for at samle formål, ansvarlig og beslutningen om agentens brug. Mikkel har brug for at forstå rammerne. Den tekniske ansvarlige har brug for et klart grundlag at sætte adgangen op efter.
Det fælles grundlag passer til retningen for SPOR. Adgangsbegrænsning, handlingstilladelser og stop skal samtidig fungere i agentløsningen og de systemer, den bruger. En registrering af beslutningen er ikke en teknisk spærring.
SPOR er under udvikling. Få besked, når første version er klar.
Typiske fejl, når en AI-agent får adgang
- At give agenten en medarbejders brede konto, fordi den allerede findes.
- At stole på en instruktion i stedet for en teknisk begrænsning.
- En godkendelsesknap uden synlig modtager og konkrete ændringer.
- Kun at teste en vellykket opgave og ikke det, agenten skal afvise.
- Ingen måde at standse flere handlinger på, når en fejl er opdaget.
Hvad kan I gøre nu?
- Skriv den ene handling, agenten skal kunne udføre, og de handlinger, den ikke må.
- Del dem i læse, foreslå og udføre, og beslut, hvor et menneske skal godkende.
- Send spørgsmålene fra tabellen til den tekniske ansvarlige eller leverandøren, og bed om at se en afvist handling i et testmiljø.
Næste skridt: Når agenten er i brug, skal I vurdere den samlede nytte inklusive kontrol og drift. Læs hvilke AI-løsninger I skal beholde, samle eller stoppe. Se også hvem der ejer AI-systemet efter go-live.
Ofte stillede spørgsmål
Skal et menneske godkende alt?
Behovet afhænger af handling og konsekvens. Min anbefaling er at begynde afgrænset og gøre kontrollen stærkere, hvor en fejl er vanskelig at opdage eller rette.
Kan vi bruge medarbejderens almindelige konto?
Få den tekniske ansvarlige til at vurdere identitet og rettigheder. Agenten bør ikke få bred adgang, blot fordi kontoen allerede har den. Adgangen skal passe til den konkrete opgave.
Hvad er forskellen på et AI-register og adgangsstyring?
Et register kan beskrive den besluttede brug og ansvaret. Adgangsstyringen håndhæver, hvad løsningen kan gøre. I bør kunne sammenholde de to.
Hvad må en AI-agent gøre i virksomheden?
Det afgør virksomheden for hver opgave. Beskriv de konkrete handlinger, og beslut for hver, om agenten må læse, foreslå eller udføre. Begræns adgangen teknisk til det nødvendige.
Hvordan begrænser vi en AI-agents adgang?
Giv agenten mindst mulige rettigheder til de sager og felter, opgaven kræver, og bed om at se, at uønskede handlinger afvises i et testmiljø. Det svarer til OWASP's anbefaling om at minimere funktioner og tilladelser; se OWASP: Excessive Agency.
Eksemplet er fiktivt. Artiklen er et praktisk beslutningsgrundlag, ikke en sikkerhedsgodkendelse af en bestemt løsning. Artiklen er generel vejledning og ikke juridisk rådgivning. Udgivet .