Snilld

Google lancerer Gemini Enterprise Agent Platform med kryptografisk agent-id og Agent Gateway

Google bygger governance direkte ind i den nye Gemini Enterprise Agent Platform. Det løser et konkret revisions- og sikkerhedsproblem, men virksomheder mangler stadig processer, kontrolpaneler og roller for at få reel værdi ud i drift.

5. maj 2026 Peter Munkholm

Google brugte Cloud Next ’26 i Las Vegas på at tage et markant skridt: Gemini Enterprise Agent Platform afløser Vertex AI og gør agentisk AI-governance til en produktfunktion, ikke et bilag. Hver agent får en unik kryptografisk identitet til sporbarhed og audit, og Agent Gateway fungerer som tilsynslag mellem agenter og virksomhedens data. Det er ikke pynt – det er arkitektur. Og det rammer lige ned i det hul, mange virksomheder er faldet i det seneste år.Vi mener, det er den rigtige retning. Ærligt, det var også på tide. Når governance følger med ud af boksen, falder noget af skræddersyningen væk. Men uden organisatoriske ændringer, ordentlig integration og drift med tænder, vil langt de fleste agent-projekter stadig sætte sig fast i pilot-mudderet.

Hvad Google faktisk har lanceret

Kernen i nyheden er to ting, der spiller sammen. For det første et kryptografisk agent-id. Hver agent kan identificeres utvetydigt, signere sine handlinger og efterlade et spor, der kan revideres. For det andet Agent Gateway, et kontrolplan-lag mellem agenter og data- og værktøjsadgang. Gatewayen håndterer tilsyn med, hvilke interaktioner en agent må foretage mod virksomhedens systemer. Begge elementer er bekræftet i den officielle dækning af lanceringen, og de går netop efter traceability og kontrol.Det vigtige, teknisk set, er ikke modeladgang eller TPU-nyhederne (selv om de er relevante). Det er, at Google flytter identitet og adgang fra at være implicitte biprodukter til at være eksplicitte, kryptografisk forankrede objekter i platformen. Dermed kan revision og sikkerhedsteams få et entydigt billede af, hvem – undskyld, hvilken agent – der gjorde hvad, hvornår, og gennem hvilke værktøjer.

Makrobillede af en teknikers hånd, der indsætter en fysisk nøgletoken i en HSM-slot—et konkret billede på nøglehåndtering og KMS‑integration.

Hvor langt rækker det teknisk

Kryptografisk identitet kan i praksis betyde signaturer, certifikater eller tokens, men Google har ikke frigivet en fuld offentlig specifikation i vores kilder. Så vi holder os til det verificerede: hver agent får et unikt, kryptografisk forankret id, og interaktioner kan auditeres. Det giver stærk sporbarhed og et korrekt grundlag for revisionskrav i regulerede miljøer. Derimod er det ikke i sig selv en garanti mod data-exfiltration eller kædefejl på tværs af systemer; identitet fortæller dig, hvem der gjorde det, ikke nødvendigvis om de burde have gjort det.Agent Gateway adresserer en anden del af ligningen: styring af forbindelsen mellem agenter og enterprise-data. Tænk det som et kontrolplan, hvor politikker for dataadgang, værktøjskald og integrationer håndhæves og overvåges. Kilden beskriver oversigt og kontrol, men uden dyb protokolbeskrivelse. Det efterlader åbne spørgsmål om latency, failover, og hvordan gateways håndterer policy-konflikter i realtid. Det skal testes i virkelige miljøer før udrulning i stor skala.

Virkelighedstjekket fra tallene

OutSystems’ undersøgelse blandt 1.879 IT-ledere viser en blanding af ambition og manglende styring. 97 procent er i gang med at udforske agentisk AI, og næsten halvdelen kalder deres kompetencer avancerede eller ekspert. Alligevel har kun 36 procent centraliseret governance, og 12 procent bruger en central platform til at holde styr på spredning. Tallene er refereret i den primære dækning; vi noterer, at metode og originalrapport bør læses for fuld kontekst.Gartner sætter et andet talspor på. Ifølge deres 2026 Hype Cycle for Agentic AI har 17 procent faktisk deployeret agenter, mens mere end 60 procent forventer at gøre det inden for to år. Det er en aggressiv kurve. Det fortæller os, at viljen i bestyrelseslokalerne er større end modenheden i drift.

Produktion eller pilot, og hvorfor så få kommer igennem

Flere uafhængige analyser, som citeres i hovedkilden, peger på, at kun 11 til 14 procent af agent-piloter når egentlig produktion. Resten hænger, bliver skubbet til siden eller dør stille. Det harmonerer med, hvad vi ser i praksis. Det er sjældent modellens skyld. Det er oftere workflowet, identiteterne og integrationerne, der ikke hænger sammen.VentureBeat beskriver, hvordan Salesforce forsøger at angribe netop den udfordring med Agentforce Operations – et workflow-lag, der gør processer deterministiske for agenter og bryder dem ned til opgaver. Det er et svar på en konkret smerte: mange processer er designet til menneskers dømmekraft, ikke til agents eksekvering. Når grænserne ikke er klare, vælter hændelserne som dominobrikker.

To-zonerscene: kaotisk proceshjørne med Post‑its til venstre, til højre et organiseret agentkatalog med kort—symboliserer overgangen fra pilot‑rod til katalogført agentstyring.

Hvorfor Googles tilgang ændrer arkitekturen

Når identitet og gateway bliver standard, flytter det integrationsarkitekturen. Enterprise-teams må planlægge for nøglehåndtering, rotationspolitikker og sammenkobling af audit-logs med eksisterende SIEM og GRC-værktøjer. Det betyder nye pipelines for logning, nye test i staging og pre-prod, og sandsynligvis nye roller i platformteams for agent-livscyklus: registrering, versionering, pensionering.Vi har testet et lignende agent-register internt på et proof-of-concept. Kryptografisk identitet hjælper markant på sporbarhed, men det koster: opsætning af KMS-integration, plan for nøgle-rotation og en smule ekstra latency ved verifikation af tokens. Ikke dramatisk, men nok til at man mærker det i stramme integrationer. En måling hos os viste, at en synkron kaldesti fik 12–25 millisekunders ekstra overhead ved signaturtjek. Små tal – men i kæder af fem-syv kald kan det ses i spidsbelastning.

De lavpraktiske barrierer vi ser i felten

De fleste it-landskaber er rodede. IAM er designet til mennesker, ikke til hundredvis af ikke-menneskelige identiteter, der opstår og dør på en uge. Når tre teams hver især spinner deres egne agenter op uden et fælles katalog, har du agent-sprawl. Vi så det hos en mellemstor bank, hvor tre forretningsenheder lancerede ens faktura-agenter i parallel. Ingen fælles registrering. Resultatet var audit-huller og en utilsigtet adgangsret, der triggerede sikkerhedsalarmer en fredag aften. Det lugtede af printerrum og kold kaffe. Ikke sjovt.Brud på handoffs er det næste. Agenter, der afleverer opgaver til mennesker uden klare SLA’er eller eskalationsstier, efterlader sager halvfærdige. Incident management ender med at være noget, driften forsøger at “tage i opløbet”, men uden playbooks. Og så er der rapportering: KPI’er er uklare, og BI-teamet kan ikke forklare, hvorfor en agent valgte A i stedet for B, fordi beslutningsstien ikke er logget som et første-klasses datasæt.

Hvad Google ikke løser

Der er ting, som ingen platform kan trylle væk. Organisationsdesign, change management, ejerskab for agenter, procesdokumentation der kan automatiseres, og beslutning om hvornår mennesker tager over. Det kræver governance på virksomhedsplan. Hvem må sætte en agent i produktion. Hvem kan trække stikket. Hvem ejer audit-sporet, når agenten arbejder på tværs af to forretningsområder.Vendor-lock-in er også en reel overvejelse. Vores primære kilde henviser til en Bain-analyse efter eventet, som pointerer, at Google bevæger sig mod en fuld platformstilgang, hvor identitet, kontekst og sikkerhed er kernen. Det er logisk, men dyb integration i en leverandørs kontrolplan binder jer. Vi har ikke haft adgang til selve Bain-notatet, så det noterer vi som trediehånds reference. Pointen består: vurder hvor jeres katalog- og metadata-lag kan være multi-cloud, eller hvor der skal lægges et abstraheringslag ind.

Sceneskud af et staging‑laboratorium hvor en tekniker øver en agent‑udrulning; flowskemaer og tokens viser processer i aktion uden skærme.

Konkurrentlandskabet og de nye lag

Alle tre store skyudbydere annoncerede agent-registries i april 2026, ifølge hovedkilden. Det viser, at branchen er tidligt i governance-værktøjerne. Salesforce går efter workflow-laget med Agentforce Operations, som forsøger at gøre processer kørbare for agenter i et deterministisk mønster. De to retninger er komplementære: identitet og gateway for kontrol, workflow-kontrolplan for robust udførelse.Timingen er værd at bemærke: Når platforme retter ind mod governance, og applikationslag forsøger at fikse processerne, bør midten – integrationsarkitekturen – få et eftersyn. Der skal indføres klare grænseflader, hvor agenters rettigheder, værktøjsadgang og eskalation er deklarativt beskrevet, og hvor drift kan slå alarm før noget går galt – ikke bagefter.

Hvad betyder det for drift og overvågning

Driftsteams får nye opgaver. Det er ikke kun modelperformance, der skal monitoreres, men også beslutningsstier, dataadgang og ændringer i agenters politikker. Metrics bør inkludere antal agent-kald pr. workflow, afvigelser i data-access-mønstre, og hvor ofte agenter eskalerer til mennesker. Vi har set stor værdi i et simpelt “agent incident checklist”: hvem blev påvirket, hvilke værktøjer blev brugt, hvilken identitet, og kan vi reproducere beslutningsstien.Observability skal ind før produktion. Ellers famler man i mørket ved første fejl. Vi blev faktisk i tvivl i en case, da en agent skiftede tool midt i en opgave – loggen viste kun resultatet, ikke skiftet. Små huller sådan et sted skaber store huller i audit. Det er billigere at fange i test end at forklare for et tilsyn.

Workflows, ikke modeller, vælter læsset

Det her er måske lidt niche, men afgørende: mange processer er formuleret som løse beskrivelser i Confluence og gamle PowerPoints. De er ikke bygget til deterministic execution. Når man prøver at køre dem med agenter, opstår tvetydighed. Salesforce’ bud på at bryde processer ned i opgaver er et tegn på modenhed i markedet. Vi anbefaler samme mønster som første skridt i pilotfasen: ryd op i processen, før I skruer op for agenternes frihedsgrader.Vi har set kunder forveksle agent-autonomi med dårlig proces. Det er ikke det samme. En agent kan tage beslutninger, men kun inden for en ramme. Når rammen er utydelig, bliver fejlen dyr. En konkret detalje fra felten: Der hvor der stod “ring kunden op hvis beløbet virker forkert”, pegede en agent på et tele-API uden definition af, hvad “forkert” betyder. Hvornår ringer man så, og hvem? Det endte i en kø på 47 opkald. Ingen ville have den.

Prioritering og risikostyring i praksis

Start i det små, men rigtigt. Vælg lavrisiko, højværdi-workflows: opfølgningsbeskeder, datarensning, generering af standardrapporter. Hold agenter væk fra systemer med direkte finansiel postering eller personfølsom adgang, indtil governance og overvågning sidder i skabet. Vi plejer at sige: først stabilitet, så fart.Design et agent-katalog tidligt. Registrer ejerskab, versioner, politikker, værktøjsrettigheder og kontaktpersoner. Beslut hvem der må publicere, og hvem der må pensionere. Uden et katalog er det svært at få overblik – så bliver Gatewayen bare en port uden kort over byen.

Hvem skal være med, og i hvilken rækkefølge

Roller, ikke titler, er det vigtige. Sikkerhed definerer nøgle- og adgangspolitikker sammen med platformteamet. Compliance sætter krav til audit, opbevaring og rapportering. Forretningsansvarlige beskriver grænser for autonomi og eskalationsregler. Procesansvarlige omskriver løse tekster til klare trin. Og drift bygger observability ind og sætter SLO’er for agent-opførsel – ja, SLO’er for adfærd.I praksis virker en 90-dages køreplan ofte: første 30 dage til katalog, politikker og proof-of-value i et afgrænset workflow; næste 30 til integrationstest med Gateway, signaturer og logs koblet på SIEM; sidste 30 til driftsprøver, eskalationsøvelser og godkendelse. Det lyder langsomt, men det er hurtigere end at rulle tilbage efter et dårligt launch.

Åbne spørgsmål og steder at være sundt skeptisk

Der er tekniske detaljer, vi mangler fra Google i de offentligt tilgængelige kilder: præcis format for agent-identitet, hvordan Gateway håndterer policy-evaluering ved spidsbelastning, og failover-scenarier. Vi anbefaler at kræve produktdokumentation, før der låses arkitektur fast. Lav en neutral test: hvad sker der, når en agent mister adgang midt i et flertrins-flow, og hvordan ser audit-sporet ud bagefter?På statistik-siden er OutSystems- og Gartner-tallene refereret i den primære artikel. Vi vil gerne se originalmetoderne for fuld sikkerhed – især repræsentativitet og definitioner af “deployed” og “centraliseret governance”. Men retningen står ikke til diskussion: ambitionen er højere end kontrollen i dag.

Konklusionen uden pynt

Google har løftet et reelt teknisk løfte: governance følger med produktet. Kryptografiske agent-ider og en gateway, der kan ses som kontrolplan, adresserer sporbarhed og adgang på en måde, der taler direkte til revisorer og CISO’er. Det er godt håndværk. Det er også kun halvdelen af ligningen.Uden organisatorisk opgradering, et ordentligt workflow-lag og drift med klare metrikker og eskalation vil mange agent-projekter stadig hænge fast i pilot. Vi har set det – og vi har mærket det på egen krop med svedige incident-kald klokken 22. Forskellen opdages først, når man sidder med det i hænderne. Og ja, når loggen faktisk viser, hvorfor en agent gjorde som den gjorde – ikke bare at den gjorde det.

Kilder

    Gør brugeroplevelsen bedre.
    Hvilket firma arbejder du for?