Gemini-agent med egen identitet: governance

Google åbner for agentbaseret AI i Gemini og starter med erhvervskunderne, som TechCrunch beskrev den 8. oktober. Forskellen fra de assistenter, de fleste virksomheder allerede kender, er afgørende. En chatassistent svarer på spørgsmål og foreslår tekst. En agent planlægger en opgave, deler den op og udfører trinnene på tværs af de systemer, den har adgang til.

Det er et skifte i risikoprofil, ikke kun i funktionalitet. En fejl i et chatsvar kan en medarbejder opdage og rette, før noget sker. En fejl i en agents handling kan nå at blive udført, mailet videre eller gemt i et system, før nogen kigger med.

Det mest interessante ved lanceringen er ikke selve planlægningen, men at agenten får en identitet på arbejdspladsen, herunder en egen e-mailadresse. Det kan lyde som en detalje, men det løser og skaber samtidig problemer.

Fordelen er sporbarhed. Hvis agenten handler under sit eget navn, kan man i loggen skelne mellem, hvad en medarbejder gjorde, og hvad agenten gjorde. Det er langt bedre end den gængse genvej, hvor agenten kører på en medarbejders login og dermed arver alle vedkommendes rettigheder.

Ulempen er, at en ny identitet kræver samme omhu som en ny medarbejder. Den skal have en ejer, afgrænsede rettigheder, en udløbsdato og en procedure for, hvad der sker, når den ikke længere skal bruges. Uden det samler virksomheden hurtigt identiteter, som ingen husker at lukke.

Der er også et mere jordnært spørgsmål: Hvem må sende mails fra agentens adresse, og hvem læser svarene? En adresse, som eksterne kan skrive til, er også en adresse, som eksterne kan forsøge at manipulere agenten igennem.

Gemini-agenten kan ifølge TechCrunch trække på subagenter og flere modeller til at løse en opgave. Teknisk er det naturligt: Forskellige delopgaver egner sig til forskellige modeller. Organisatorisk er det en udfordring, fordi kæden af beslutninger bliver længere.

Når en hovedagent uddelegerer til en subagent, som igen kalder en anden model, er det ikke givet, at adgangen følger med på en kontrolleret måde. Spørgsmålene er enkle at stille og svære at besvare bagefter:

- Arver subagenten hovedagentens rettigheder, eller har den sine egne? - Kan man i en log se, hvilken model der traf hvilken beslutning? - Hvem godkender, at en ny model kobles på, og hvordan opdager man det?

Jeg kører selv agenter i drift, og reglerne viser sig næsten altid først, når ingen længere følger med dagligt. Et pilotprojekt virker, fordi en dygtig person kigger med hele tiden. Så holder agenten pludselig fri fra opsyn, og så er det et spørgsmål, om grænserne faktisk er skrevet ned. Jeg har ikke et rent tal på, hvor ofte de ikke er.

Virksomheder behøver ikke vente på, at leverandørerne har løst alt. Man kan stille de samme krav til en agent, som man stiller til en ny medarbejder med vidtgående systemadgang.

Start med en ejer. Hver agentidentitet skal have en navngiven person, der svarer for dens handlinger og kan slukke for den. Ejerskabet må ikke hvile på en afdeling eller en leverandør.

Giv derefter mindst mulig adgang. Agenten får kun de systemer og datatyper, opgaven kræver, og læseadgang er standard, indtil der er en begrundelse for skriveadgang. Handlinger, der ikke kan fortrydes, som at sende eksternt, slette eller betale, bør kræve en menneskelig godkendelse i første omgang.

Sørg for, at alt kan genfindes. Log hver handling med agentens identitet, tidspunkt og de data, den rørte ved. Uden den log kan man hverken efterforske en fejl eller dokumentere over for tilsynet, hvordan personoplysninger er blevet behandlet.

Tænk til sidst på databeskyttelsen. En agent, der arbejder på tværs af systemer, kan samle oplysninger, som aldrig tidligere lå samme sted. Det bør vurderes, før agenten sættes i drift, ikke efter.

Før en Gemini-agent, eller en tilsvarende agent fra en anden leverandør, får lov at arbejde selvstændigt, bør ledelsen kunne svare på fem spørgsmål:

1. Hvem er ejer af agentens identitet, og hvem træder til, når vedkommende er fraværende? 2. Hvilke systemer og data kan agenten tilgå, og hvornår blev det senest gennemgået? 3. Hvilke handlinger kræver menneskelig godkendelse, og hvad sker der, hvis den ikke kommer? 4. Kan vi se præcis, hvad agenten og dens subagenter har gjort, og hvilken model der stod bag? 5. Hvordan lukker vi agenten ned, og hvad sker der med dens adgange og postkasse bagefter?

Hvis svaret på ét af dem er "det ved vi ikke endnu", er agenten ikke klar til drift, uanset hvor godt den løser opgaven i en demonstration. Jeg har ikke set, hvordan Googles løsning logger subagenternes handlinger i praksis. Det er det første, jeg ville bede om at se.