TechCrunch formulerede det kras og enkelt: “The AI agents are coming. A lot of them.” Det er ikke bare en tendens. Samtidig forsøger Google at sælge idéen om Gemini Spark som en personlig agent, der arbejder i baggrunden hele døgnet. Signalværdien er tydelig, men målgruppen er ikke kun dig med en Android i lommen. Det her rammer først i virksomhedernes drift – ikke i din private indbakke.
Hvorfor? Fordi data, processer og systemadgange i organisationer er der, hvor autonome agenter både kan levere værdi og skabe rod, hvis styringen halter. Forbrugere vil lege med huskelister og rejseplaner; virksomheder sidder med SLA’er, revision og produktionssystemer. Det ser vi allerede i henvendelserne: færre store ord, flere konkrete spørgsmål fra IT og automationsteams.
Hvad er nyheden
Google præsenterer Gemini Spark som en “24\/7 personal AI agent”, der kan køre i baggrunden – selv når telefon og laptop er slukket – og som kobler apps for at udføre flertrinsopgaver på tværs af dit digitale økosystem. TechCrunchs formulering sætter scenen for mængden af produkter, vi vil se. VentureBeat skriver samtidig, at leverandører som Microsoft, Salesforce, Google og ServiceNow jagter at blive standard‑infrastrukturen for enterprise‑agenter. Samme retning, forskellig målgruppe.
Google lover autonomi under brugerstyring og at systemet spørger før større handlinger. Beroligende i en forbrugerkontekst – men i enterprise rejser det et hårdt spørgsmål: Hvem er “brugeren”, når en agent kører tværfaglige flows over ERP, CRM og dataplatforme, og hvor går grænsen for “større handlinger”? Der er endnu intet klart standardsvar, og det presser governance‑designet fra dag ét.
Hvad lover Gemini Spark konkret
Gemini Spark beskrives som noget, der arbejder opgaver fra start til slut: multi‑step handlinger som at samle mails, logge kvitteringer i et ark, opdatere kalender og sende opfølgninger. Det kobler apps og “connects the dots” i baggrunden – men altid efter dit samtykke, siger Google. Løfterne omfatter også at holde øje med abonnementer, samle nyheder i temaer og gøre indbakken mere håndterbar.
Hvordan “baggrunden” er skruet sammen, er ikke en detalje. Google skriver, at Spark arbejder, selv når dine enheder er slukket – logisk set via server‑side processer og app‑integrationer på Googles infrastruktur. Det rejser spørgsmål om overvågning, pris og ansvar, som produktsiden ikke folder ud. De tekniske linjer mellem enhed, konto og server er uklare, især når handlinger krydser tredjeparts‑apps.
Hvorfor forbrugeren måske ikke køber idéen
TechCrunch antyder skepsis hos almindelige brugere, hvilket giver mening. En altid‑kørende assistent lugter hurtigt af overvågning, og de fleste vil have noget enkelt – ikke en automatik, der roder i kalender og mails. Batteri er næppe problemet; tillid er. Hvem betaler for 24\/7‑ressourcerne? Hvad koster det pr. måned? Og hvad sker der, når den tager fejl af en faktura og en nyhedsmail?
Forbrugerprodukter vinder typisk, når de er lette at forstå og lette at slukke. En agent er sværere at forklare end en chatbot: Den gør ting, når du ikke kigger, og kræver samtykker, som mange springer over. Forbrugerne skal nok komme, men virksomhederne har allerede cases, data og problemer, der gør det nærliggende at teste nu.
Kapløbet om enterprise‑infrastruktur
VentureBeat beskriver, hvordan Kore.ai lancerer Artemis‑udgaven af sin platform med et Agent Blueprint Language baseret på YAML. Målet er at komprimere design, byg, test og drift af agenter fra måneder til dage ved at lade AI hjælpe det meste af vejen. Det er et rent enterprise‑pitch, der lægger sig i mellemlaget, hvor politikker, validering og runtime bor.
Samtidig peger VentureBeat på, at Microsoft, Salesforce, Google og ServiceNow vil være den foretrukne infrastruktur for agenter. Det matcher udbud og partnerskaber, vi ser. Ikke ét økosystem, men flere – og ingen fælles standarder endnu. Derfor rykker governance og portabilitet fra fodnote til førsteside.
Tre konsekvenser for drift og projekter
Workflow: Når en agent kobler e‑mail, CRM, dokumentlager og betalingssystemer, flytter forretningslogik ud af enkeltværktøjer og ind i et agentlag. Praktisk, men også en ny monolit, hvis man ikke passer på. Fejl opstår ikke kun i én app, men i kæder. Support får nye fejlsøgninger, hvor årsagen kan ligge tre led tilbage.
Governance: En agent, der må “tage handling” i andre systemer, kræver tydelige tilladelser, revisionsspor og stopklodser. Mange undervurderer tiden til adgangsanmodninger, rollemodeller, dataklassificering og godkendelsesflows. Starter man uden, ender man ofte med et uigennemsigtigt agent‑setup – lige så tungt at rydde op i som gammel ETL.
Teknisk gæld: Agentlogik ender hurtigt som skjult afhængighed på tværs af API’er og prisplaner. Uden versionsstyring, testdata og en exit‑plan bliver små ændringer hos en leverandør til driftsbrud hos jer.
Snillds erfaring i felten
I en kundetest klarede en prototype‑agent en flertrinsopgave i kundeservice. Magisk første dag. På tredje dag ramte den API‑rate limits i et eksternt system og satte sig fast i en halvtilstand, der både sendte dobbelt‑kvitteringer og manglede sager. To mennesker rullede tilbage og rensede op. Læringen: hold agentens retry‑politik konservativ.
Og ja, begejstringen er ægte i de første uger. Efter tre til seks måneder er det drift, overvågning og omkostningssporing, der æder kalenderen. Alerts skal tunes, dashboards bygges, og nogen skal eje hændelserne. Kedeligt – men det afgør, om en agent bliver hjælp eller endnu en skjult belastning.
Hvordan en pragmatisk indfasning kan se ud
Start med at kortlægge de mest hyppige, lavrisiko processer, hvor fejl kan tåles og effekten er målbar. Lav en PoC – ikke et halvt års program – med klar afgrænsning og en plan for at slukke. Gennemsigtighed i data er et must; ellers aner man ikke, hvorfor agenten beslutter, som den gør. Sæt overvågning og KPI’er op fra dag ét, ikke som eftertanke.
Udpeg en “owner” for hver agent – for mål og adfærd, ikke kun for team. Personen skal forstå både forretning og teknik og kunne tage beslutninger, når agenten går i stå. Omstændeligt i starten, men ved første natlige hændelse giver det mening. Vi har desværre set det modsatte for ofte.
Tekniske faldgruber og integrationsspørgsmål
API‑adgang lyder banalt, men token‑levetid, scopes og rate limits bliver forretningskritiske, når en agent arbejder 24\/7. Standardisér autentifikation med kortlivede tokens og central styring, så nøgler ikke spredes i scripts. Event‑drevet arkitektur hjælper, fordi agenter reagerer på hændelser i stedet for at poll’e efter tidsskemaer, der koster og skaber støj. Men uden ordentlig event‑log og idempotens fordobler du handlinger i stilhed.
Omkostninger siver. En agent i baggrunden lyder let, men server‑side kørsler, evalueringskald, vektoropslag og tredjeparts‑API’er lægger sig som små poster, der bliver store i skala. Opdateringsstyring er et andet hul: Når en leverandør ændrer et felt i et API, kan agentkæden knække. Hold versions‑locks, tests og en hurtig rollback‑vej klar. Ikke glamourøst – nødvendigt.
Hvilke roller ændres i organisationen
Support lærer at kende forskel på menneske‑ og agenthandlinger i loggene. Drift overvåger flows, ikke kun CPU og RAM. Compliance ejer rettigheder og revisionsspor og afgør, hvad en agent må uden menneskelig bekræftelse. Produktledelse definerer mål og succeskriterier, så agenten optimerer mod noget, der faktisk betyder noget.
Vi bruger en enkel RACI: Produkt ejer mål og roadmap. Sikkerhed ejer governance og politikker. Automatisering ejer runtime og hændelser. Det er ikke kunst – det skal bare skrives ned. Ellers bliver agenten alles og ingens ansvar på samme tid.
Konkurrenceperspektivet
Google taler til forbrugeren med Spark, men det er tydeligt, at backend’en er der, hvor arbejdet sker. Kore.ai pitcher et mellemlag til virksomheder med et blueprint‑sprog, som ifølge VentureBeat kan accelerere udvikling. Microsoft, Salesforce og ServiceNow har fordelen af at være dybt inde i hverdagsværktøjerne allerede. Forvent ikke én vinder, men parallelle spor alt efter hvor jeres data lever.
Googles 24\/7‑fortælling ser flot ud på slides, men den reelle forskel mærkes først, når agenten får lov at røre ved rigtige systemer. Vi har ikke set varig værdi uden at tage styringen over integrationer, logning og omkostninger selv. Google overdriver ikke – de forenkler. Helt normalt ved produktlanceringer, men værd at huske.
Usikkerheder og risici
Der mangler uafhængige tal for forbrugeradoption af altid‑kørende agenter. Vi ved det ikke endnu. Den tekniske mekanik i “kører når telefonen er slukket” er ikke beskrevet i detalje af Google, ud over at det åbenlyst kræver server‑side processer. VentureBeat gengiver påstande om at komprimere måneder til dage, men uden åbne benchmarks. Prisstrukturen for konstant kørende personlige agenter er heller ikke tydelig.
Og vigtigst: Der findes ingen fælles standard for agent‑governance på tværs af platforme. Hver leverandør har sit sprog og sine politikker. Det gør portabilitet og vendor‑exit til en reel risiko. Planlæg for det – ellers planlægger I for problemer senere.
Hvad vi anbefaler som næste skridt
En simpel 6‑punkts plan: 1) Kortlæg to‑tre højfrekvente, lavrisiko workflows. 2) Kør en afgrænset PoC med klare stopkriterier og driftsbudget. 3) Kræv datagennemsigtighed og audit‑log fra dag nul. 4) Etabler runtime‑overvågning med alerts og simple SLO’er, der kan forklares til ledelsen. 5) Letvægts‑governance med godkendelsesflows og begrænsede handlingstilladelser. 6) En exit‑ og versionsplan, så I kan rulle tilbage eller flytte agenten, hvis leverandør eller pris ændres.
I en sen PoC på retail‑data var én ting spot on, én helt ved siden af. Spot on: markant færre manuelle triageringer i indbakken på tre dage. Ved siden af: for mange “næsten‑relaterede” sager, fordi datakilderne ikke var label‑rene. Løsning: benhård datahygiejne og en strammere policy for, hvilke labels agenten må skabe selv.
Korte scenarier fra virkeligheden
Intern kommunikation: En agent holder øje med ukommenterede beslutningsforslag i Confluence, mapper dem til teams i Slack og poster en ugentlig “beslutningsliste” med links og ejere. Den må ikke auto‑lukke sager – kun minde og måle svarrater. Effekten er synlig, risikoen lav. Drift spotter hurtigt, hvis listen pludselig bliver tom, fordi et API brød ned.
Kundesupport: En agent læser nye tickets, slår op i produktdatabasen, henter loguddrag via en støtteservice og foreslår et svar til menneskelig godkendelse. Når svaret godkendes, udsendes det, og sagen labeles og triageres. Timeout efter fem minutter for at undgå hængepartier. Hvis API’et siger nej én gang, prøv igen om 30 sekunder. To fejl i træk – så gå i kø. Enkelt, men robust.
Konklusion
Google forsøger at sælge os en 24\/7‑agent i lommen. Fair. Men det bliver virksomhederne, der først mærker både gevinster og bøvl. Rådet er jordnært: test, mål, begræns, overvåg – og tag ejerskab. Forskellen mærkes først, når man sidder med det i hænderne.
Bilag og kilder
TechCrunch: “Google is pitching an AI agent ecosystem to consumers who may not buy it” – inkl. “The AI agents are coming. A lot of them.” Bruges som nyhedspeg og vurdering af forbrugerskepsis. Google Gemini Spark produktside: “24\/7 personal AI agent”, autonomi under brugerens retning og bekræftelse før større handlinger samt eksempler med multi‑step opgaver og app‑forbindelser. VentureBeat om Kore.ai Artemis og Agent Blueprint Language samt kapløbet blandt Microsoft, Salesforce, Google og ServiceNow om enterprise agent‑infrastruktur. Snilld manual brief: anvendt som baggrund for anbefalinger og praksiserfaring, ikke som dokumentation for leverandørers påstande.
