Microsoft udvidede under Build testafprøvningen af sin nye Autopilot. Første konkrete agent hedder Scout. Den kører på tværs af Outlook, OneDrive, SharePoint og Teams og er i hænderne på interne testere, udvalgte kunder og de mere uklare “Frontier organisations”. Det er ikke bare endnu en Copilot‑variant, men en arbejdsassistent, der kan handle selv på brugerens vegne — sådan lyder Microsofts udmelding.
Scout samler data på tværs og kan bl.a. booke møder, flagge vigtige beskeder og oprette kalenderhændelser for at holde fokus på opgaver. Over tid tilpasser den sig brugerens mønstre og præferencer, ifølge Microsoft. Det er den korte version. Nedenfor: hvad det betyder i praksis for drift og governance i en dansk tenant.
Hvad er annonceret — og hvad er bekræftet
Ifølge Microsofts egen Build‑kommunikation (opsummeret af AI News) er Autopilots en ny klasse af agenter, der arbejder autonomt på brugerens vegne. Hver agent får sin egen identitet, så flere kan eksistere side om side med forskellige regelsæt (fx hjem kontra arbejde). Scout er den første. Den er testet internt og nu på vej ud til en udvalgt kundegruppe og Frontier organisations. Det er underbygget af kilden.
Scout opererer i Microsoft 365‑apps og koordinerer data fra Outlook, OneDrive, SharePoint og Teams for at holde arbejde i gang — ved at planlægge møder, prioritere beskeder og generere kalenderpunkter. Formuleringerne “enterprise‑grade security” og “trusted from day one” er Microsofts egne vurderinger (marketing). Vi lægger i stedet vægt på de konkrete styringsgreb nedenfor.
Hvad Scout gør i hverdagen
Tirsdag morgen: Indbakken er tyk. Scout har registreret en deadline fredag, blokerer kalenderen onsdag eftermiddag som fokustid og foreslår et kort møde med to nøglekolleger, der — ifølge Teams‑tråde og SharePoint‑aktivitet — ligner flaskehalse. Den flagger to mails fra kendte nøgleafsendere og genererer et kladderesumé med næste skridt. Du godkender — og planen eksekveres.
Det kan være effektivt. I agent‑lignende forløb hos kunder har vi set reelle tidsgevinster ved mødeforslag og udkast til opfølgningsmails. Men to fejltyper går igen: prioriteringsfejl (mindre ting blokerer for det vigtige) og overentusiastiske bookingforslag. Én kunde endte med tre overlappende arbejdsmøder i en travl uge, fordi automatiske blokeringer ikke tog højde for et fast ledermøde torsdag. Småt i det enkelte tilfælde, men dyrt i irritation og spildtid.
Sådan lærer Scout — og hvor det kan gå galt
Microsoft oplyser, at Scout tilpasser sig den enkelte brugers præferencer og arbejdsrytme over tid. I praksis betyder det, at prioriteringslogikken flytter sig med dine klik, møder og mails. Det virker — når dataene er gode. Risikoen er, at eksisterende bias forstærkes: Den kollega, du oftest svarer sent, bliver måske også nedprioriteret fremover. Ikke nødvendigvis ønskeligt.
Kontrol skal derfor være designet ind. Kræv et synligt “hvorfor” ved større handlinger, som brugeren kan udfordre. Gør præferencejusteringer lavfriktions — ikke begravet tre menuer nede. Kilden nævner brugertilpasning, men ikke om fællesmønstre på tværs af organisationen. Det er et dokumentationshul.
OpenClaw som fundament — åbner det for bedre integration
Under motorhjelmen bygger Scout på OpenClaw, og Microsoft siger, de vil bidrage upstream til open source‑projektet. Det kan i princippet give eksterne mulighed for at inspicere og udvide integrationspunkter — og potentielt hurtigere fejlrettelser via communityet.
Men kilden afklarer ikke grænsen mellem OpenClaw og Microsofts proprietære dele. Ingen roadmap. Ingen tidslinje. Hvis I forventer at tilpasse agentlogik selv, kræver det engineeringkapacitet og en plan for vedligehold på tværs af versioner. Vi har set lokale tilpasninger dø ved næste større opdatering. Praktisk råd: antag, at kerneagenten er et første‑partsprodukt, og betragt OpenClaw som bonus — indtil andet er dokumenteret.
Sikkerhed, identitet og datapolitikker
Scout leveres med enterprise‑kontroller ifølge Microsoft. Tre punkter fra kilden er konkrete: agenter får egne identiteter i Entra, datapolitik forankres i Microsoft Purview, og maskin‑credentials redigeres væk fra logs og diagnostik. Derudover kræver “følsomme” handlinger menneskelig signoff.
På papiret dækker det meget. Men to spørgsmål står åbne: Hvad er præcis en “følsom handling”, og kan kunder definere kategorier og tærskler uden at kode? Og hvor langt går log‑redaktion? I et revisionsmøde hos en kunde gav anonymiserede servicekonti modstand, fordi hændelsessporingen blev for uklar. Løsningen blev en separat audit‑kanal med begrænset adgang. Det er ikke dokumenteret for Scout, men vi forventer lignende behov.
Hvad betyder det for drift
Indfører I Scout, får I nye driftsrutiner. Først identitetsstyring for agenter i Entra — livscyklus, rolleprofiler, nøgleopbevaring og ophør. Dernæst runbooks for fejlsituationer: Hvad gør I, når agenten blokerer en direktørs kalender forkert en hel uge? Og hvem ejer hændelsen — slutbrugersupport, M365‑platformsteam eller sikkerhed?
Logs bliver også en disciplin. Når maskin‑credentials redigeres væk, skal der etableres alternative sporbarhedsbeviser for de hændelser, der betyder noget. Ellers står I i en CAB og må sige “vi kan ikke se mere end det her”. Det holder ikke.
En realistisk udrulning i en dansk organisation
Start smalt. Fx kalenderstyring for én afdeling uden kundekontakt. PoC på 2–4 uger med klare succesmål: færre dobbeltbookinger, hurtigere mødebooking, færre oversete flags. Kør parallelt en sikkerheds‑ og datastyringsworkshop, hvor I designer agentidentiteter, tilladelser, signoff‑regler og log‑behov. Når PoC’en leverer, ryk til pilot i en ikke‑kritisk funktionsenhed i 4–8 uger.
Først derefter skala — og først når supporten har opdateret vagtplan, triage‑matrix for agentfejl og SLA’er, der eksplicit dækker autonome handlinger. En kunde måtte ændre hele eskaleringsstien, fordi incidents startede i kalenderen men endte i SharePoint‑tilladelser. Den slags kædereaktioner bør fanges i pilot, ikke i produktion.
Kontrol, produktivitet — og de ubehagelige mellemtilfælde
Agentisk hjælp giver tempo. Kontrol koster tid. Hvis alt kræver signoff, forsvinder gevinsten. Hvis intet gør, stiger fejl og risiko for dataslip. Definér tre niveauer af handlinger: automatisk, kvitteringskrævende og godkendelseskrævende. Mål faktiske mis‑handlinger ugentligt i pilotperioden.
Fejltilstande er særligt giftige i krydsfeltet mellem apps. Et generisk eksempel: en agent, der arkiverer Teams‑filer for aggressivt i OneDrive (fordi en lokal særregel i salg ikke er modelleret). Eller fejlgodkendelser, hvor brugeren klikker “ja” af vane. Vi har set, at korte godkendelsesdialoger på mobil øger fejl. En lille detalje — med stor effekt.
Compliance og revision uden fuldt indblik i logs
At fjerne credentials fra logs er fornuftigt af hensyn til sikkerhed, men gør revisors arbejde sværere. Etabler supplerende bevisførelse: hændelses‑hashes, signeret jobhistorik eller en særskilt audit‑log med mere detaljerede felter bag streng adgangskontrol. Kilden beskriver ikke sådanne mekanismer for Scout. Notér hullet for revisor tidligt og lav et designsprint på audit før pilot.
På tværs af tenants er billedet uklart. Kilden nævner ikke multitenancy eller API‑kvoter. I koncerner med flere tenants og cross‑tenant sync skal begrænsninger afklares. Vi savner tal for latenser og kvoteforbrug — de foreligger ikke i kilden.
Integration og åbenhed — hvad kan man faktisk skrue på
OpenClaw giver forhåbninger om hooks. Spørgsmålet er, om I kan tilpasse eller auditere beslutningslogikken, eller om det fortsat er et lukket første‑partsprodukt. Kilden siger, at Microsoft vil bidrage upstream — ikke hvor meget. Praktisk implikation: byg proces‑tilpasning uden om kernen via policy, identitet og godkendelser. Vent med dybe hooks, til der findes dokumentation og en supporteret udvidelsesmodel.
Hvis — og kun hvis — der åbnes for reel udvidelse, kræver det disciplin: versionsstyring, regressionstests og et ansvarligt team, der holder tilpasninger driftssikre. Ellers ender man med en skrøbelig særudgave. Det har vi set før.
Snillds praksisnære forslag
Alt her bygger på vores erfaringer fra udrulninger af agent‑lignende arbejdsgange i M365 og kundesupport. Ikke på officiel Microsoft‑dokumentation:
- Etabler en Autopilot‑governance‑skabelon med handlingstyper, signoff‑krav, roller og undtagelser.
- Lav en sikkerhedscheckliste for agentidentiteter i Entra: livscyklus, nøglehåndtering, RBAC, nødslet.
- Opsæt en test‑suite for agentadfærd med syntetiske data, så I kan køre “tørre” forløb uden at røre produktion.
- Afhold en pilotworkshop med slutbrugere for at sætte klare forventninger — især hvornår man siger stop.I en aktuel kundecase (anonymiseret) måtte vi begrænse automatiske kalenderblokeringer til 10–14 og aldrig fredag efter kl. 13 — fordi salget lever i de tidsrum. Små regler gør en stor forskel.
Modargumenter og det, vi ikke ved endnu
Skeptikere vil pege på overhyping: at “autonom” i praksis bliver “halvautonom med mange tilladelser”. Måske. Det må ses i brug. Andre nævner multitenancy‑flaskehalse, performance i Teams‑klienten og brugeraccept. Kilden leverer ingen tal, så de forbliver åbne risici.
Vi savner også klare svar på: hvilke handlinger er “sensitive” per default, hvilke felter præcist redigeres i logs, og hvor grænsen går mellem OpenClaw og lukket kode. Hvem er desuden “Frontier organisations”, og hvorfor blev de valgt? Den type cases giver normalt de bedste læringer — de er ikke delt endnu.
Hvad vi mener — nøgternt
Scout er et seriøst skridt fra Microsoft mod en hverdagsagent, der faktisk må trykke på knapperne. Det mærkes, når kalenderen lander rigtigt, og de rigtige mails hopper frem. Microsofts løfter om enterprise‑kontrol ser fornuftige ud på papiret, men styrken afhænger af jeres egne politikker og opsætning.
Skal man kaste sig over det nu? Start småt, mål gevinster, byg governance før skala. Scout vil sandsynligvis opleves hurtigere end generiske chat‑hjælpere, fordi den må handle — og det er i brugen, forskellen viser sig, ikke i slides.
Næste skridt de næste 30–90 dage
Vil I være klar til Scout i 2024/25, så gør tre ting nu:
- Kør en hurtig “agent readiness” på Entra‑roller og Purview‑politikker — især hvem må hvad uden eksplicit godkendelse.
- Definér et snævert PoC‑scope i M365, aftal succeskriterier, og udpeg en pilotafdeling uden kundekontakt.
- Design en auditstrategi, der kompenserer for redigerede logs, inkl. adgangsstyring til en særskilt audit‑kanal.Og skriv jeres “stopknap”: Hvem kan sætte Scout på pause, hvordan og hvor længe. Det virker småt — indtil noget løber løbsk tirsdag kl. 15.42.
