M365 Copilot & Agents

Copilot leser det du har lov til å lese. Ikke alltid en god plan.

Hva Copilot og Agents finner i tenanten din, står ikke i Microsoft-dokumentasjonen. Det står i tilgangsrettighetene dine. Vi sørger for at begge deler stemmer.

Book en rådgivning nå

Bestill via Azure Marketplace

Innfør M365 Copilot og Agents på en trygg måte: konfigurasjon, oversharing og riktig arkitektur

Før Copilot hadde oversharing ingen merkbare konsekvenser, fordi ingen hadde tid til å gå gjennom alle dokumentene i et gjennomsnittlig selskap. Copilot har den tiden. Den bruker sekunder, og den leter ikke etter problemer, den finner dem simpelthen, fordi den henter det den enkelte brukeren har lov til å lese via Microsoft Graph, og i de fleste tenants har en gjennomsnittlig medarbeider statistisk sett tilgang til rundt 130 000 filer som aldri var ment for vedkommende. Den vanligste første effekten etter en Copilot-utrulling er derfor ikke økt produktivitet, men ufrivillig innsyn.

Dette er ikke et argument mot Copilot. Det er et argument for rekkefølgen. Tilgangsrettigheter, sensitivity labels, DLP-policies, konfigurasjonen av Copilot Control System og spørsmålet om hvilke admin-sentre som er relevante før første utrulling: disse hjemmeleksene fantes før Copilot akkurat som etter, men anledningen til å ta tak i dem systematisk har aldri vært like håndgripelig som nå. Copilot er i denne forstand ikke et problem, den er en anledning til å sette opp tenanten slik den alltid burde ha vært.

16 %

av alle bedriftsdata er statistisk sett overberettiget (Microsoft)

130 000

filer som medarbeidere i gjennomsnitt har tilgang til, som aldri var ment for dem

70 %

av medarbeiderne har gitt forretningskritiske data videre til uautorisert KI (Microsoft)

23 %

vet ikke om selskapet deres i det hele tatt tilbyr KI-verktøy (Microsoft)

Hva Copilot er, hva en Agent er og hvorfor forskjellen betyr noe

Skillet Microsoft trekker mellom Copilot og Agents er teknisk presist, men ofte uskarpt i kommunikasjonen, noe som gjør at bedrifter enten forventer for mye eller starter i feil ende. Den enkleste linjen går gjennom spørsmålet om autonomi.

M365 Copilot og Copilot Chat er interaktive assistenter som svarer på spørsmål, sammenfatter innhold og skisserer tekster, alltid basert på det brukeren har lov til å lese via Microsoft Graph. De handler ikke, de bistår. Declarative Agents, altså SharePoint-agents eller agents fra Agent Builder, utvider denne tilnærmingen med et avgrenset, forhåndsdefinert kunnskapsområde, men tar ingen selvstendige beslutninger og utfører ingen systemhandlinger.

Virkelig autonome blir Agents først som Custom Engine Agents, bygget i Copilot Studio, Power Platform eller Azure AI Foundry: disse kan utløses hendelsesstyrt, kommunisere med eksterne tjenester og utføre handlinger uten at et menneske må bekrefte hvert skritt. Uten å kjenne denne forskjellen bygger du enten Agents for oppgaver som en enkel Copilot-prompt løser like godt, eller forventer en autonomi fra en Declarative Agent som ikke er lagt inn i arkitekturen.

Copilot og Agents forutsetter en plattform som er innrettet for dem

Copilot henter data via Microsoft Graph som brukeren har lov til å lese, og agents opererer innenfor systemgrensene som den aktuelle plattformen definerer. Hvis disse grensene ikke er satt eksplisitt, fordi tenanten har vokst historisk og aldri ble utformet for AI-tilgang, kjører Copilot og agents teknisk sett, men i et miljø som verken er optimalisert for ytelse eller governance.

Vår Cloud Workplace Foundation legger M365-grunnlaget som Copilot trenger: tilgangsstruktur, Sensitivity Labels, DLP, governance-retningslinjer, ikke ettermontert, men integrert fra begynnelsen. For agents som opererer i Azure gjelder det samme: Azure Foundation og Azure Container Foundation sikrer at byggegrunnen stemmer før det bygges. Den som deployer agents i et miljø uten denne basen, deployer på sand.