Maj 2026 kom med en tæt strøm af AI‑nyheder fra Google og DeepMind. Googles samlede blogindlæg “The latest AI updates we announced in May 2026” rammer produktsporet, mens DeepMind på sin blog folder detaljerne ud om Gemini‑familien, forskningsprojekter og prototyper. De to spor hænger sammen, men taler forskelligt: produkt og platform i det ene, forskning og feltresultater i det andet. Vi har sammenholdt udmeldingerne og noterer både tempo, retning – og hvor der stadig mangler dokumentation.
Det korte overblik: Gemini Omni og Gemini 3.5 fremhæves som næste skridt i multimodal retning; Gemini for Science og Co‑Scientist peger på multi‑agent samarbejde i forskning; Antigravity 2.0, WeatherNext og Project Genie udvider mod fysik, prognoser og simulering. Det er en stor mundfuld. Men hvad betyder det i praksis for danske virksomheder? Potentialet er tydeligt større end i 2025 – og samtidig mere afhængigt af jeres data og jeres drift.
Hvad Google og Deep
Mind faktisk annoncerede
Googles maj‑opsamling bekræfter, at 2026‑fokus spænder fra model til produkt – ikke én feature, men en retning. DeepMind‑bloggen supplerer med konkrete navne: Gemini Omni, Gemini 3.5, Gemini for Science, Co‑Scientist, Antigravity 2.0, WeatherNext og Project Genie. Sammenlignet er Google‑indlægget mere produktorienteret, mens DeepMind fremhæver forskningsresultater, partnerskaber og feltcases. Det peger ikke i hver sin retning, men time‑to‑value varierer: noget kan bruges nu, andet er stadig laboratorienært.
Gemini Omni og 3.5 beskrives som multimodale og hurtigere. DeepMind skriver eksplicit om frontier‑intelligens og handling – altså modeller, der ikke kun forstår tekst og billede, men også kan udføre opgaver via værktøjer og integrationer. WeatherNext nævnes som et domænespecifikt eksempel (bedre orkanprognoser i et konkret forløb). Project Genie og Street View‑simulering peger mod digitale tvillinger. Vi mangler dog uafhængige benchmarks for Omni og 3.5 i enterprise‑settings, især multimodalt. Den mangel bør adresseres, før nogen lover gevinster på svartid eller nøjagtighed i drift.

Hvorfor det føles nyt nu
Tre tekniske elementer mødes: multimodalitet, lavere latency og flere veje til at køre modeller tæt på brugeren. Når en model kan læse dokumenter, tabeller, skærmbilleder og lyd – og udføre handlinger i ét flow – ryger meget limarbejde. Det er den reelle forskel i 2026: færre adaptere, færre skrøbelige parser‑scripts, mere tempo.
On‑device og edge er den anden del. Google signalerer, at mere kan køre tættere på brugeren. Det giver lavere ventetid og en mulig vej til bedre datasuverænitet i udvalgte flows. Men der er kompromiser: mindre modeller på enheder, mere avanceret synkronisering og versionsstyring. Som i mobiludvikling: fart og driftssmerter kommer i samme pakke.

Vibe coding ændrer udviklerrollen
MarkTechPost beskriver “vibe coding” som AI‑først udvikling: man beskriver ønsket adfærd i almindeligt sprog, og en agent bygger softwaren. Begrebet tilskrives Andrej Karpathy og indrammer et skift, hvor udvikleren går fra tasterne til at styre retning og review. Det lyder luftigt, men i praksis rykker arbejdet op i abstraktion – fra “skriv controlleren” til “lav et onboarding‑flow, der…”.
Vi har prøvet det i Snilld i et lille POC. En prototype stod op om formiddagen. Men vi fór vild to gange: review‑kapaciteten var for spinkel, og testene dækkede ikke hele kodebasen. Pointen er kedelig, men nødvendig: vibe coding flytter ikke ansvaret for kvalitet væk – det flytter det op i arkitektur, test og code‑review. Uden en klar barriere ender man med teknisk gæld forklædt som fart.
Tre realistiske business‑cases nu
Kundeservice først. Med bedre multimodale modeller kan en assistent læse et skærmdump fra jeres app, tjekke en tidligere mail og kigge i en vejledning som PDF – og svare i én tråd. Det er nyt i praksis, fordi man tidligere skulle igennem flere værktøjer for at få konteksten rigtigt. Gevinsterne er kortere svartid og færre overleveringer. Begrænsningen er integration: assistenten skal kobles til ticketing, CRM og vidensbase, og der skal være en fallback, når sagen bliver sær eller følsom. Uden det ender I med frustrerede kunder og en bot, der ikke forstår undtagelserne.
Videnhåndtering som nummer to. Gemini for Science og enterprise‑søgefunktioner peger mod bedre semantisk retrieval. I en kundecase i foråret fik vi tydeligt bedre træf i en rodet SharePoint‑struktur, når metadata var i orden. Når metadata manglede, begyndte modellen at gætte – pænt formuleret, men forkert. Vi lagde et valideringslag ind og markerede svar som “foreslået, ikke endeligt”. Prosaisk, men det skaber ro i organisationen.

Beslutningsstøtte uden store armbevægelser
Tredje case er beslutningsstøtte i salg og drift. Co‑Scientist og multi‑agent opsætninger er interessante, fordi de kan uddelegere delanalyser: indhent data, rens, beregn, forklar forskelle. Det giver hurtigere førsteudkast til rapporter, pipeline‑forudsigelser og følsomhedsanalyser. Forretningsgevinsten er kortere beslutningscyklus. Men governance bider: hvem godkender analysen, hvad logges, og hvordan genskaber vi rationalet tre måneder senere? Uden svar bliver værktøjet en sort boks, som ingen tør læne sig op ad i en revisorsamtale.
Hvad er teknisk muligt nu? Retrieval‑augmenteret generering på tværs af dokumenter, simple værktøjskæder til dataopslag, rapportskabeloner og agent‑koordination i kontrollerede rammer. Hvad er ikke modent? Autonom beslutningstagning i regulatoriske miljøer, blind tillid til genererede beregninger, og ubegrænset adgang til produktionsdata. Det sidste bør under alle omstændigheder undgås.
Integration og drift uden illusioner
Integrationerne er ikke gratis. CRM (Salesforce, Dynamics), ticketing (Zendesk, ServiceNow), enterprise‑search (Elastic, Google Cloud Search, Azure Cognitive Search) skal kobles struktureret på. Det kræver klare dataveje: hvor hentes konteksten, hvordan caches den, og hvornår opdateres den. Start med to‑tre højkvalitetskilder i stedet for at sluge hele datalandskabet på dag ét. Smal bane, dyb kvalitet.
MLOps‑kravene stiger: versionering af prompts og værktøjskonfigurationer, eval‑sæt, driftsovervågning af hallucinationsrate, latency og cost pr. interaktion. Det er håndværk. On‑device giver nye tradeoffs: lavere latency og mulig offline‑robusthed, men mindre modelkapacitet og behov for hyppige modelopdateringer til klienter. CI/CD for modeller skal være trivielt – først dér tør I skalere.
Overvågning og sikre landinger
Fallback‑strategier skal være synlige. Hvad gør vi, når modellen er i tvivl, når et eksternt API fejler, eller når der er persondata i input? En praktisk opskrift, vi har set virke: tre‑trins eskalation fra selvsikkert autosvar til “kræv menneskelig godkendelse” til “afvis og forklar hvorfor”. Ikke kønt, men effektivt – og dokumenterbart.
Data pipelines skal være gentagelige. Log modelkald med anonymiserede nøgler, hold referencekopier af videnkorpus pr. release, og bind evalueringer til versionsnumre. Det føles som overkill i en POC, men netop dér etablerer man gode vaner. Vi lærte det på den hårde måde i en intern test, hvor to næsten identiske konfigurationer opførte sig forskelligt. Fejlen dukkede først op i logs: korpuset var ikke ens.


Governance der ikke dræber tempo
Datasikkerhed, modelopførsel og forklarelighed kræver faste greb. Start med en enkel klassifikation af datatyper: grøn (kan forlade huset), gul (må bruges med begrænsninger), rød (må ikke til modellen). Læg derpå controllere: inputfiltre, PII‑detektorer, output‑klassifikatorer og manuelle checkpoints for røde use‑cases. Det er produktionssikkerhed.
Beslutningstagere bør spørge nu: hvor lagres logs, hvad er retention, og hvem har adgang? Hvilke eval‑mål bruger vi – nøjagtighed, sikkerhed, bias – og hvor ofte revurderer vi dem? Hvad koster en gennemsnitsinteraktion, når værktøjskald, embeddings, lagring og overvågning tælles med? Og hvor går kill‑switch’en, hvis noget opfører sig mærkeligt fredag kl. 16? Test den i et kontrolleret forsøg, før det bliver alvor.
Hvad vi ville gøre de første 90 dage
Skulle vi starte i morgen, vælger vi én af de tre cases og sætter en snæver ramme. Dag 0‑10: afklar datatyper, kildesystemer og sikkerhedsregler. Opsæt en minimal eval‑pakke med 20‑30 repræsentative scenarier. Dag 10‑30: byg en smal integration til to kilder, implementér fallback og logging, kør intern pilot hos få brugere. Dag 30‑60: udvid kilder og brugere, stresstest latency og omkostninger, stram eval‑kriterier. Dag 60‑90: beslut om videre udrulning, og hvis ja – formalisér drift, dokumentation og ejerkreds. Ingen heltedyrkelse, bare rygmarv.
Vibe coding i samme periode: brug det til prototyper, ikke til regelmotoren i fakturering. Indfør pull‑request‑tjeklister for agent‑genereret kode, og kør tests mod hele kodebasen – ikke kun den nye mappe. Vi lavede den fejl. En gammel, sårbar dependency røg ind ad bagdøren, og først en uge senere dukkede den op i scanningen. Små skrammer, heldigvis.
Risici og indsigelser vi tager alvorligt
Skeptikere vil sige, at det hele er overdrevet, at værktøjerne bryder sammen i komplekse domæner, og at datasikkerheden ikke er på plads. Der er korn af sand i det hele. Vi ser reelle spring i multimodal forståelse, men uden gode metadata og solid retrieval falder gevinsten hurtigt. Forklarlighed halter i multi‑agent setups: det kan være svært at genskabe præcis, hvorfor en kæde valgte en bestemt vej. Derfor anbefaler vi logning og deterministiske checkpoints på kritiske trin.
Privatliv og dataretention er fortsat åbne punkter. Hverken Google‑opsamlingen eller DeepMind‑bloggen giver fuld klarhed over enterprise‑retention for alle features. Indhent skriftlige afklaringer fra leverandøren før produktion – og konfigurer en egen proxy eller gateway, hvor det er muligt, så I selv styrer logs. Det er almindelig hygiejne.
Konkurrencebilledet kort fortalt
Markedet rykker samlet: OpenAI og Microsoft presser på med agent‑workflows og copiloter tæt på 365; Anthropic holder tempo på sikkerhed og enterprise‑funktioner; Meta skubber åbne modeller, som ændrer cost‑kurven i visse scenarier. Googles særkende i maj‑pakken er vægten på search og enterprise‑kontekst koblet med on‑device‑ambition. For danske virksomheder er Google‑sporet stærkt, hvis data bor i Google‑økosystemet, eller hvis lav latency og multimodalitet i felten er afgørende – f.eks. teknikere med kamera, der skal have svar nu, ikke når forbindelsen vender hjem.
Vi synes også, retorikken bliver skruet højt op hist og her – det gør alle i år – men retningen giver mening: færre værktøjsspring, mere handling, tættere på brugeren.
Hvad vi stadig ikke ved
Der mangler uafhængige multimodale benchmarks for Gemini 3.5 og Omni i enterprise‑lignende miljøer. Licens‑ og prisstruktur for on‑device deployment er ikke fuldt belyst offentligt. Hvordan Project Genie og visse forskningsprojekter bliver til kommercielle produkter, er uklart. Og vi mangler åbne danske referencecases i produktion. Indtil da bør man kalde det, hvad det er: lovende – men ikke bevist i alle hjørner.
Vores egen feltobservation fra en semantisk søg‑case: kvaliteten løftes markant, når metadata er gennemarbejdet og dokumenter er renset for dubletter og PDF‑artefakter. Når de ikke er det, stiger risikoen for pæne, men forkerte svar. Derfor lægger vi et valideringslag ind – f.eks. en simpel scorer, der kræver beviscitat fra kilden – før noget vises som sikkert. Det sænker farten en smule. Det øger tilliden meget.
Bundlinjen for beslutningstagere
Hvis I vil udnytte maj‑opdateringerne, så gør tre ting nu: vælg én case, skær datakilderne ned til få, gode kilder, og byg jeres eval‑ og governance‑skelet, før I løber stærkt. Alt andet er pynt. Nogle steder giver on‑device mening – især ved gentagne, latency‑følsomme opgaver eller på steder med svag forbindelse. Andre steder er central API mere robust. Der er ikke ét rigtigt svar, kun klare tradeoffs.
Og en lille note fra vores skrivebord i København: Vi kunne høre regnen mod ruden, mens vi testede et multimodalt flow i går. Modellen fangede tallene i et dårligt foto af en faktura, men missede et bedragerisk lille minus‑tegn. Det er præcis derfor, at review og simple sanity‑checks stadig er kongen. Ikke fordi teknologien er ubrugelig. Men fordi hverdagen er fuld af minus‑tegn.