M365 Copilot & Agents

Copilot läser det du får läsa. Inte alltid en bra plan.

Vad Copilot och Agents hittar i din tenant står inte i Microsofts dokumentation. Det står i dina behörigheter. Vi ser till att båda stämmer.

Boka rådgivning nu

Boka via Azure Marketplace

Införa M365 Copilot och Agents säkert: konfiguration, oversharing och rätt arkitektur

Före Copilot hade oversharing inga märkbara konsekvenser, eftersom ingen människa hade tid att söka igenom alla dokument i ett genomsnittligt företag. Copilot har den tiden. Den behöver sekunder, och den letar inte efter problem, den hittar dem bara, eftersom den kommer åt det som respektive användare får läsa via Microsoft Graph, och i de flesta tenants får den genomsnittliga medarbetaren statistiskt läsa runt 130 000 filer som aldrig var avsedda för hen. Den vanligaste första effekten efter en Copilot-utrullning är därför inte ökad produktivitet, utan oönskad transparens.

Det är inte ett argument mot Copilot. Det är ett argument för ordningsföljden. Behörigheter, Sensitivity Labels, DLP-policyer, konfigurationen av Copilot Control System och frågan om vilka administrationscenter som är relevanta före den första utrullningen: dessa läxor fanns lika mycket före Copilot som efter, men anledningen att ta itu med dem systematiskt var aldrig så konkret som nu. Copilot är i den meningen inget problem, utan en möjlighet att ställa in din tenant så som den borde ha varit hela tiden.

16 %

av alla företagsdata är statistiskt överbehörigade (Microsoft)

130 000

filer som medarbetare i genomsnitt har åtkomst till men som aldrig var avsedda för dem

70 %

av medarbetarna har lämnat vidare affärskritiska data till icke auktoriserad AI (Microsoft)

23 %

vet inte om deras företag över huvud taget erbjuder AI-verktyg (Microsoft)

Vad Copilot är, vad en Agent är och varför skillnaden spelar roll

Skillnaden som Microsoft drar mellan Copilot och Agents är tekniskt precis, men i kommunikationen ofta otydlig, vilket leder till att företag antingen förväntar sig för mycket eller börjar i fel ände. Den enklaste gränsdragningen går via frågan om autonomi.

M365 Copilot och Copilot Chat är interaktiva assistenter som svarar på frågor, sammanfattar innehåll och tar fram utkast till texter, alltid utifrån det som användaren får läsa via Microsoft Graph. De handlar inte, de stödjer. Declarative Agents, alltså SharePoint-Agents eller Agents från Agent Builder, utökar detta med ett begränsat, fördefinierat kunskapsområde, men fattar inga egna beslut och utför inga systemåtgärder.

Verkligt autonoma blir Agents först som Custom Engine Agents, byggda i Copilot Studio, Power Platform eller Azure AI Foundry: dessa kan utlösas händelsestyrt, kommunicerar med externa tjänster och utför åtgärder utan att en människa behöver bekräfta varje steg. Den som inte känner till den skillnaden bygger antingen Agents för uppgifter som en enkel Copilot-prompt löser lika bra, eller förväntar sig av en Declarative Agent en autonomi som arkitektoniskt inte är avsedd.

Copilot och Agents förutsätter en plattform som är inriktad på det

Copilot kommer åt data via Microsoft Graph som användaren har läsbehörighet till, och agenter arbetar inom de systemgränser som respektive plattform definierar. Om dessa gränser aldrig satts uttryckligen, för att din tenant vuxit fram historiskt och aldrig utformats för AI-åtkomst, fungerar Copilot och agenter tekniskt sett, men i en miljö som varken är optimerad för prestanda eller för styrning.

Vår Cloud Workplace Foundation lägger den M365-grund som Copilot behöver: behörighetsstruktur, Sensitivity Labels, DLP och styrningsprinciper, inte påsatta i efterhand utan integrerade från början. För agenter som arbetar i Azure gäller detsamma: Azure Foundation och Azure Container Foundation säkerställer att grunden är rätt innan något byggs. Den som distribuerar agenter i en miljö som saknar denna bas bygger på sand.