Gemini-agenten er Googles system til at udføre arbejdsopgaver på tværs af programmer med vedvarende kontekst. Den kombinerer modeller, værktøjer og adgang til organisationens data. Den praktiske betydning afhænger derfor både af svarenes kvalitet og af, hvilke oplysninger og handlinger agenten får adgang til.
Vedvarende AI-agenter forbinder arbejdsopgaver med hukommelse, værktøjer og virksomhedsdata. Adgang til oplysninger, mandat til at ændre dem og svarenes faglige kvalitet er forskellige kontrolpunkter, mens dansk sprogkvalitet, lokal funktionsadgang og behandling af personoplysninger kræver særskilt afklaring.
Hvad har Google annonceret?
Google Cloud præsenterede Gemini-agenten den 8. oktober 2026. Lanceringen beskriver arbejde på tværs af blandt andet Gmail, Drive, Docs, Sheets, Slides, Chat og Calendar samt opgaver, der kan fortsætte i skyen, når computeren er lukket.
Nyheden handler dermed om at samle en arbejdsgang omkring en AI-agent. Et svar i et chatvindue og en gennemført opgave i organisationens systemer er forskellige resultater. Det sidste skal også vurderes på de handlinger, der faktisk bliver udført.
Er Gemini-agenten det samme som en Gemini-model?
Google skelner mellem agenten og modellen under den. Ifølge lanceringen kan agentlaget bruge både Gemini-modeller og Anthropics Claude-modeller.
En model behandler input og producerer output. Agentlaget forbinder det med en opgave, værktøjer og et forløb. Ved modelrouting kan valget af model ændres mellem trin. En vellykket modeltest fortæller derfor ikke alene, om den samlede arbejdsgang virker.
Hvad betyder vedvarende hukommelse?
Google beskriver fælles kontekst og hukommelse på tværs af enheder. Det er også et centralt princip i vedvarende AI-agenter: arbejdet knyttes til et fortsat forløb.
Et illustrativt eksempel er en projektstatus, hvor sidste uges beslutning indgår i denne uges udkast. Her bliver det relevant at skelne mellem en historisk oplysning og den senest godkendte beslutning. Hukommelsens tilstedeværelse fortæller ikke i sig selv, om agenten vælger den rigtige version.
Et konkret kontrolspørgsmål er derfor, om en ændret beslutning slår igennem i det næste resultat. Det kan afprøves med et konstrueret projekt, hvor en gammel deadline er erstattet af en ny.
Hvordan adskiller en teamagent sig fra personlig assistance?
Google beskriver også coworker-agenter med egen Workspace-konto og identitet. Disse agenter får den kontekst, teamet deler med dem.
Som praktisk skel kan opgaven opdeles efter, hvem der bruger resultatet, og hvem der må godkende det:
| Opgave | Muligt resultat | Kontrolpunkt |
|---|---|---|
| Personlig forberedelse | Et udkast til egne mødenoter | Er oplysningerne korrekte og relevante? |
| Fælles projektstatus | En oversigt til projektgruppen | Er modtagerne berettiget til alle oplysninger? |
| Ændring i et arbejdssystem | En opdateret opgave eller registrering | Har agenten mandat til netop denne ændring? |
Tabellen er en måde at analysere brugen på, ikke en oversigt over dokumenteret adgang i et bestemt abonnement. Den samme formulering kan være passende som privat kladde og forkert som fælles meddelelse.
Hvorfor har agentens egen identitet betydning?
Google Clouds Agent Identity giver en agent en særskilt teknisk identitet baseret på SPIFFE-standarden. Dokumentationen skelner mellem, at agenten handler på egne vegne, og at den får delegeret adgang fra en bruger, eksempelvis gennem OAuth.
Agent Registry katalogiserer værktøjer og destinationer, mens Agent Gateway håndhæver adgangspolitikker. I den beskrevne kombination med Gemini Enterprise og auth manager får agenten ikke adgang til brugerens rå legitimationsoplysninger; de håndteres af infrastrukturen.
Identiteten gør det muligt at knytte rettigheder og registrerede handlinger til agenten. Den siger ikke noget om rigtigheden af et resumé. En teknisk gyldig adgang kan stadig føre til et fagligt forkert resultat.
Hvordan hænger identitet og mandat sammen?
Identitet svarer på, hvem der anmoder om adgang. Mandat beskriver, hvad vedkommende må gøre. Googles IAM-dokumentation omfatter regler, der tillader eller afviser kommunikation med registrerede tjenester. En destination skal være registreret, før den kan indgå i den beskrevne politik.
Et illustrativt mandat kan være at hente oplysninger fra et projektrum og udarbejde en status uden at ændre kildematerialet. Hvis opgaven senere udvides til også at opdatere projektplanen, er det en anden adgangssituation. Læseadgang og ændringsadgang bør derfor vurderes hver for sig i et sådant forløb.
Agent Identity-dokumentationen beskriver desuden et konkret vedligeholdelsesbehov: Sletning af en agent fjerner ikke automatisk de IAM-bindinger, der henviser til den. En genoprettet agent får en ny teknisk identitet, også selv om visningsnavnet er det samme. Gamle og nye rettigheder kræver dermed særskilt håndtering.
Hvornår blokerer en sikkerhedsregel faktisk?
En registreret overtrædelse er ikke nødvendigvis en stoppet handling. Googles IAM-vejledning anbefaler at afprøve Agent Gateway i DRY_RUN i et testmiljø. Her registreres kommunikation, som reglerne ikke tillader, i Cloud Audit Logs, men den bliver ikke blokeret.
Når konfigurationen skiftes til ENFORCE, blokerer gatewayen kommunikation, der overtræder politikken. Funktionen kræver, at Agent Gateway er sat op.
For en organisation giver det to forskellige testspørgsmål: Kan systemet opdage et uønsket adgangsforsøg, og forhindrer det faktisk forsøget i den valgte driftstilstand? En logpost besvarer det første. Den dokumenterer ikke automatisk det andet.
Beskrivelsen gælder den dokumenterede platformkonfiguration. Den er ikke bevis for, at en bestemt kundes agent eller alle integrationer allerede har den tilsigtede beskyttelse.
Hvad kan det betyde for projektarbejde?
For projektledere og administrative medarbejdere i Danmark kan et relevant afprøvningsområde være en afgrænset statusopgave. Den mulige værdi er mindre manuel samling af oplysninger; den konkrete effekt må måles i organisationens egen arbejdsgang.
Et illustrativt testforløb kan se sådan ud:
- Opret et testprojekt med fiktive beslutninger, deadlines og ansvarlige.
- Definér, hvilke kilder agenten må bruge, og at resultatet kun skal være et udkast.
- Indsæt både en gammel og en ny beslutning, så versionsvalget kan kontrolleres.
- Sammenhold statusudkastet med kilderne, og undersøg udeladelser og forkerte konklusioner.
- Afprøv særskilt en afvist destination, og kontrollér både log og faktisk blokering.
- Registrér tidsforbruget inklusive opsætning, kontrol og rettelser.
Forløbet adskiller opgavens faglige resultat fra dens adgangskontrol. Det kan også vise, om et mere fastlagt AI-workflow passer bedre til en opgave, hvor trin og datakilder sjældent ændres. Eksemplet er ikke en måling af Gemini-agentens effektivitet.
Er dansk adgang og sprogkvalitet dokumenteret?
Den læste lancering giver ikke en særskilt oversigt over dansk funktionsadgang eller resultater for dansk sprog. En annonceret integration dokumenterer heller ikke, at alle funktioner er aktiveret på en bestemt organisations konto.
Ved lokal afprøvning kan et projektmateriale derfor indeholde æ, ø og å, interne forkortelser, danske datoer og dokumenter med flere mulige ansvarlige. Kontrollen kan undersøge, om agenten gengiver en frist korrekt, bevarer et forbehold og skelner mellem et forslag og en beslutning.
Det er konkrete testbehov, ikke dokumenterede svagheder ved systemet. Resultater fra én organisations materiale kan heller ikke alene beskrive kvaliteten i alle fagområder.
Hvilke GDPR-spørgsmål følger med arbejdsdata?
Når arbejdsdata indeholder personoplysninger, skal organisationen vurdere den konkrete behandling. Datatilsynets cloudvejledning fremhæver, at den dataansvarlige skal kende hele leverandørkæden og de behandlinger, der foregår. En væsentlig ændring i behandlingsaktiviteterne vil typisk kræve en fornyet risikovurdering.
For et vedvarende agentforløb er relevante spørgsmål blandt andet:
- Hvilke personoplysninger indgår i input, gemt kontekst, resultater og logs?
- Hvilke leverandører og underleverandører behandler oplysningerne?
- Hvor længe opbevares oplysningerne, og hvordan kan de slettes?
- Hvem kan tilgå dem, herunder ved support fra et tredjeland?
Datatilsynet præciserer, at se-adgang fra et tredjeland også kan udgøre en overførsel. Både passende sikkerhed og overførselsforhold skal derfor vurderes; en oplysning om europæisk lagring kan ikke alene besvare alle spørgsmålene.
Agentidentitet og adgangspolitikker kan indgå i den tekniske kontrol, men dokumenterer ikke i sig selv et behandlingsgrundlag eller en samlet lovlig behandling. Lanceringen afgør ikke, hvilke vilkår der gælder for hver mulig kombination af modeller, datakilder og integrationer.
Hvordan vurderes kvaliteten af det samlede system?
NISTs AI Risk Management Framework er en frivillig ramme for at arbejde med AI-risici i design, udvikling, brug og evaluering. Den er ikke en godkendelse af Gemini-agenten eller en erstatning for gældende regler.
Som praktisk anvendelse af et risikoperspektiv kan en afprøvning holde tre resultater adskilt: svarets faglige kvalitet, handlingernes overensstemmelse med mandatet og den efterfølgende mulighed for at undersøge forløbet. Et korrekt udkast opvejer ikke en uretmæssig deling. En blokeret handling dokumenterer omvendt ikke, at et andet svar er faktuelt korrekt.
Et brugbart testresultat beskriver derfor opgaven, materialet, rettighederne og de fejl, der opstod. På den måde bliver det tydeligt, hvad der faktisk er afprøvet, og hvilke anvendelser der stadig mangler dokumentation.
Hvilke kilder ligger til grund?
Nyheden bygger på Googles præsentation af Gemini-agenten. De tekniske afgrænsninger følger dokumentationen om Agent Identity og IAM-adgangspolitikker. Databeskyttelse og evaluering er belyst med Datatilsynets cloudvejledning og NISTs ramme for AI-risikostyring.