Därför behöver du en solid infrastruktur för att vara agentredo 2025

Prolog

Med denna allestädesnärvaro uppstår många idéer och en vilja att agera eller åtminstone experimentera. På glueckkanja AG stöttar vi våra kunder genom hela den processen. Vi utvecklar och bygger förstås redan agenter, men i 80 % av våra projekt ligger huvudfokus på att förbereda data och tenant för att skapa agenter. Innan du inför Copilot produktivt i din organisation lönar det sig att kritiskt granska din infrastruktur. När du fattar beslut på det här området finns det flera viktiga aspekter att förstå innan du rullar ut AI-agenter i stor skala. Därför guidar jag dig i det här blogginlägget genom de väsentliga stegen och skillnaderna. I en tid då AI-assistenter som Microsoft 365 Copilot Agents lovar att förändra arbetslivet gäller framför allt en princip: AI är bara så bra som systemet under den.

Den här heltäckande guiden beskriver hur du förbereder din data och infrastruktur för Copilot Agents och tar upp centrala metoder i SharePoint, Teams och Power Platform.

Varför din infrastruktur (data) spelar roll

När vi använder AI-agenter är det avgörande att förstå att dessa agenter inte i sig besitter kunskap om vår organisation, vår data eller vårt unika verksamhetssammanhang. Som standard bär en AI-agent bara den inbyggda kunskap som härrör från träningen av den stora språkmodellen (LLM). För att effektivt förstärka och utöka dessa AI-agenters förmåga är det nödvändigt att systematiskt integrera olika komponenter. Den förstärkningen kan uppnås genom att implementera System Prompts, kunskapsbaser, connectors, webbsökfunktioner, åtkomst till Microsoft Graph, semantisk sökning och ytterligare verktyg. Tillsammans gör dessa komponenter det möjligt för AI-agenterna att leverera mer precisa, kontextuellt relevanta svar och åtgärder som ligger nära organisationens specifika behov och data. Eftersom vi nu befinner oss i själva början av den agentiska eran kommer många av oss att börja med enkla agenter som hämtar information från befintliga bibliotek i SharePoint Online.

För oss i IT betyder det att vi behöver ta hand om vår data i SharePoint Online mer än någonsin.

SharePoint Online = kunskap = data och data = nyckeln

Mitt tydliga budskap: Innan du lägger till AI-copiloter i din organisation, få ordning på ditt datahus. Samma data som matar dina Copilot Agents matar också Microsoft 365 Copilot självt.

Och inte bara det. Microsoft 365 Copilot bedömer samma data. Om den datan är rörig, översdelad (overshared) eller dåligt skyddad kan AI:n oväntat visa felaktig eller känslig information. Föreställ dig till exempel att du frågar Copilot om företagets struktur och får detaljer om en konfidentiell omorganisationsplan som du inte var menad att se. Sådana incidenter inträffar när innehåll är overshared (tillgängligt för brett) på plattformar som SharePoint eller Teams. Observera: Copilot respekterar alla befintliga behörigheter, vilket innebär att något sådant bara kan inträffa när behörigheter är felkonfigurerade. Omvänt gäller att om data är isolerad i silos eller otillgänglig blir AI-assistenterna mindre användbara.

Copilot visar bara organisationsdata som den enskilda användaren har minst visningsbehörighet till.

Källa: https://learn.microsoft.com/en-gb/copilot/microsoft-365/microsoft-365-copilot-privacy?azure-portal=true

Viktigaste lärdomen: AI i företag lyckas bara med en solid datagrund. En färsk rapport från Microsoft pekar ut oversharing av data, dataläckage och regelvidrig användning som de främsta utmaningarna att hantera innan man inför AI. Organisationer som investerar i att förbereda SharePoint Online och andra datakällor kommer att kunna dra nytta av Copilot med tillförsikt, medan de som inte gör det riskerar säkerhetsincidenter eller irrelevanta AI-svar. Studier visar att ungefär en tredjedel av beslutsfattarna saknar full insyn i affärskritisk data.

10 steg för att förbättra din M365-datainfrastruktur nu

Nu vet vi att dina agenter kommer att behöva data. När vi på glueckkanja går in i den här typen av projekt är detta vår typiska 10-punktslista som vi arbetar igenom uppifrån och ned tillsammans med våra kunder.

Steg 1: Kontrollera grundläggande delningsinställningar

Verifiera inställningar på tenant-nivå som kan leda till oversharing. Granska till exempel standardpolicyerna för länkdelning (om till exempel ”Anyone with the link” eller ”People in your organization” är tillåtet som standard för SharePoint/OneDrive), om användare kan skapa publika Teams som standard och om din Power Platform-miljö är öppen utan styrning. Felkonfigurerade standardinställningar här är en vanlig orsak till oavsiktligt bred åtkomst.

Steg 2: Granska publika Teams

Gå igenom alla Microsoft Teams som är markerade som ”Public”. Ett publikt Team innebär att vem som helst i din organisation kan hitta och komma åt dess innehåll. Säkerställ att varje Team som är satt till publikt verkligen bara innehåller icke-känsligt innehåll som passar för en bred publik. Om inte, ändra det till privat eller justera medlemskapet. (Det är lätt för ett Team att skapas som publikt och sedan glömmas bort, vilket exponerar filer för alla anställda.)

Steg 3: Se över Graph Connectors

Kontrollera om din tenant har några Microsoft Graph Connectors uppsatta som hämtar in tredjepartsdata (till exempel från externa filsystem, wikis och så vidare). Ta bort eller säkra varje connector som indexerar data som inte alla borde se. Varför? Innehåll som indexeras via Graph Connectors blir en del av ditt Microsoft Graph-sökindex, vilket betyder att Copilot potentiellt kan använda det för att besvara prompts. Du vill bara ha relevanta, avsedda datakällor anslutna.

Steg 4: Ta fram en SharePoint Online Baseline Report

SPO har olika möjliga risker för oönskad data i agenter och Copilot. Du behöver leta efter flera nyckeltal:

• Bruten behörighetsnedärvning på mappnivå
• Publika SharePoint-webbplatser
• Användning av ”Everyone Except External Users” eller andra dynamiska grupper som omfattar alla användare
• Delningslänkar av typen ”Anyone”
• Delningslänkar av typen ”Everyone in my org”
• Oönskade personer i grupperna Site Admins / Owners / Members / Visitors

Steg 5: Kategorisera och prioritera risker

Ta resultaten från steg 1–4 och rangordna dem efter allvarlighetsgrad. Vilka webbplatser eller filer bär den mest affärskritiska eller känsliga datan och har samtidigt exponeringsrisker? Prioritera att åtgärda dem. Genom att lägga på affärskontext (till exempel en webbplats med finansiell data jämfört med en webbplats med generiska mallar) kan du fokusera på de mest verkningsfulla problemen först.

Steg 6: Involvera webbplatsägare i åtkomstgranskningar

För varje SharePoint-webbplats (eller Team) som markerats som riskabel, låt webbplatsägaren dubbelkolla vem som har åtkomst och om det är lämpligt. Ägare är oftast närmast innehållet och kan snabbt upptäcka ”Åh, varför har alla läsåtkomst till det här? Det borde de inte ha.” Inför en process där webbplatsadministratörer regelbundet intygar behörigheter.

Steg 7: Etablera löpande tillsyn

Inför en kontinuerlig övervakningsprocess för nya oversharing-problem. Kontroll av oversharing är ingen engångsåtgärd; i takt med att nya webbplatser, Teams och filer skapas behöver du fånga felkonfigurationer proaktivt. Överväg att använda Microsoft Purviews rapporter eller aviseringar för att fånga sådant som filer som delas externt eller till enorma grupper, nya publika Teams som skapas och så vidare. Microsofts verktyg kan automatisera aviseringar för dessa förhållanden, så använd dem för att upprätthålla en stark säkerhetsställning.

Steg 8: Tillämpa Sensitivity Labels och DLP-policyer

Använd Microsoft Purview Sensitivity Labels för att klassificera data (Confidential, Highly Confidential och så vidare) och koppla dessa etiketter till skyddsinställningar. En etikett som ”Confidential” kan till exempel kryptera filer eller förhindra extern delning. Konfigurera även policyer för Data Loss Prevention (DLP) för att förhindra eller övervaka oversharing av känslig information (som att blockera någon från att mejla en lista med kunders personnummer). Dessa verktyg förhindrar inte bara oavsiktliga läckor i det dagliga arbetet, de fungerar också tillsammans med Copilot: om Copilot försöker komma åt eller mata ut etiketterat innehåll på sätt det inte borde kan DLP ingripa. Dessutom för Copilot själv med sig dokumentets etikett till sina svar, vilket beskrivs längre fram.

Steg 9: Inför styrning av Power Platform

Utöka din tillsyn till Power Platform (Power Apps, Power Automate och så vidare). Definiera DLP-policyer för Power Platform för att kontrollera connectors (så att någon inte till exempel kan bygga ett flöde som hämtar data från en känslig SharePoint-lista och postar den till en extern tjänst). Överväg också att ha flera miljöer (Dev/Test/Prod) med korrekt säkerhet så att ”Citizen Developers” som bygger agenter eller appar inte oavsiktligt exponerar data. I grunden handlar det om att förhindra att Power Platform blir en ostyrd bakdörr till din data.

Steg 10: Utbilda och rusta dina agentbyggare

Skapa slutligen riktlinjer och bästa praxis för dem som ska bygga eller driftsätta AI-agenter (oavsett om de är professionella utvecklare eller verksamhetsanvändare). Inför utbildning i att hantera data säkert: till exempel hur man väljer lämpliga kunskapskällor för en agent, varför man inte ska inkludera känsliga filer i en brett delad agent och hur man testar en agents utdata för oväntad information. Genom att främja en datamedveten kultur bland ”agentbyggare” minskar du risken att någon oavsiktligt exponerar information när en AI-lösning designas.

Källor:

• https://techcommunity.microsoft.com/blog/microsoft365copilotblog/from-oversharing-to-optimization-deploying-microsoft-365-copilot-with-confidence/4357963
• https://techcommunity.microsoft.com/blog/microsoft365copilotblog/microsoft-graph-connectors-update-expand-copilot%E2%80%99s-knowledge-with-50-million-ite/4243648

När du har slutfört dessa steg kan du nu tryggt gå vidare och börja bygga produktiva agenter. För att bygga agenter har vi olika plattformar och funktioner från Microsoft att luta oss mot. Du hittar de mest framträdande exemplen i nästa kapitel. Om du behöver hjälp med den här listan är du välkommen att höra av dig till oss så hjälper vi dig med den här viktiga förberedelsen.

Under tiden hindrar inget dig från att skapa PoC- eller testagenter med exempeldata, manuellt uppladdade filer eller specifik data kopplad via RAG. Men vi rekommenderar dessa steg innan en större implementering eller utrullning av agenter.

Förstå skillnaderna mellan agentplattformar

Steg 1: Förstå dina agentskapare

Efter grundarbetet med att förbereda datan behöver vi förstå vilka plattformar som finns för att skapa dessa agenter. Vi försöker skilja dessa verktyg åt utifrån funktioner och möjligheter, men det är viktigt att notera att att skapa agenter och välja rätt verktyg är ett spektrum. Det finns flera sätt att bygga AI-agenter i Microsofts ekosystem. Det är viktigt att välja rätt utifrån dina behov och ditt teams kompetensnivå. Det klargör också när man bör dra nytta av Azure AI Foundry kontra de inbyggda verktygen i Copilot Studio.

Microsoft erbjuder i dag en uppsättning olika verktyg som kan bygga agenter. Även om de påminner om varandra är de byggda för olika målgrupper och kompetensnivåer. Titta närmare på översikten nedan. Att förstå vem som behöver skapa och underhålla dessa agenter visar oss också vilka kunskapskällor (= data) vi behöver förbereda för våra agenter. Utöver verktygen i listan nedan finns det ännu fler pro-code-lösningar för att bygga agenter, som M365 Agents Toolkit, Visual Studio Code, Agent SDK med flera. Alla våra steg för dataförberedelse gäller även för dem, eftersom de kommer åt samma data som andra agenter gör.

Källa: https://www.egroup-us.com/news/microsoft-copilot-ai-integration/

Steg 2: Identifiera användningsfall och krav för din plattform

Som du säkert kan tänka dig stöder inte varje plattform varje användningsfall. Agenter kan användas för enkla uppgifter, som att besvara frågor utifrån befintlig kunskap, eller komplexa, som att automatiskt generera svar eller utföra processer. Även den slutliga UX:en, var och hur vi vill komma åt dessa agenter, är viktig att ta hänsyn till när man väljer plattform.

Med detta i åtanke försöker vi vanligtvis använda den enklaste möjliga lösningen för att bygga vår agent. Men vi behöver också hitta den lösning som är skalbar för fortsatt utveckling. Samtidigt behöver inte varje agent byggas på Azure AI Foundry redan från början.

Tips:

Om du är osäker på var du ska börja bygga din agent kan du alltid använda Copilot Studio och antingen integrera mer data från Azure AI där och publicera den till Microsoft 365 Copilot. Då får du både ”upp- och nedåtkompatibilitet”.

RAG (Retrieval-Augmented Generation) vs. SharePoint vs. Upload

Vid första anblicken verkar allt vara RAG, men det finns skillnader. När du först utforskar Copilot Agents och deras agentförmågor är det frestande att anta att all kunskapsintegration följer samma RAG-mönster (Retrieval-Augmented Generation). Även om de alla ser ut som RAG utifrån, att de hämtar dokument och genererar svar, skiljer sig sättet de fungerar under huven avsevärt. Att förstå dessa skillnader är avgörande för att välja rätt ansats utifrån dina mål, din skala och din tekniska mognad. Här är en kort förklaring och översikt.

Manuella filuppladdningar

Manuell uppladdning är det enklaste sättet att lägga till kunskap i en Copilot-agent. Du drar och släpper dokument direkt i gränssnittet i Copilot Studio. Microsoft indexerar dessa filer automatiskt och hämtar relevant innehåll under en användares fråga. Det är idealiskt för små piloter och tidig testning. Var också medveten om att innehållet i filerna bör vara tillgängligt för alla med åtkomst till agenten. Det finns ingen behörighetshantering här som du behöver ta hänsyn till. Å andra sidan behöver du på sikt manuellt uppdatera dessa filer om saker förändras. För närvarande kan du för Copilot Agents lägga till upp till 20 filer manuellt.

Källa: https://learn.microsoft.com/en-us/microsoft-365-copilot/extensibility/copilot-studio-agent-builder-knowledge#file-size-limits

SharePoint Online

Den här metoden använder Microsofts Retrieval API för att komma åt innehåll direkt från SharePoint Online, anslutet via Graph Connector. Agenten hämtar det mest relevanta innehållet live vid frågetillfället och respekterar befintliga Microsoft 365-behörigheter. Innehållet kan vara SharePoint-webbplatser, dokumentbibliotek, mappar eller filer. Det är dynamiskt, säkert och väl lämpat för att skala över avdelningar eller affärsenheter utan att man behöver hantera egen infrastruktur. Genom att bygga vidare på den befintliga infrastrukturen använder vi den inbyggda säkerhetsmodellen i SharePoint, vilket är en enorm fördel jämfört med andra kunskapsalternativ. Avdelningar kan enkelt uppdatera filerna och det speglas i agenten. Det betyder att om två användare med olika åtkomstnivåer frågar agenten kan den ena få ett svar från en viss fil medan den andra användaren (utan åtkomst) inte skulle få det, vilket är precis det beteende vi vill ha.

Observera: SharePoint Lists är för närvarande inte en kunskapstyp som stöds, så du kan inte indexera dem out of the box (Q3 2025).

Anpassad RAG (self-managed)

I en klassisk RAG-uppsättning bygger och hanterar du hela retrieval-pipelinen själv. Det inkluderar förbehandling av dokument, chunking, embedding, lagring i en vektordatabas och att hämta de bästa träffarna vid frågetillfället. Det ger dig full kontroll över hur innehåll bearbetas och hämtas, men det för också med sig komplexitet och underhållsbörda. Det passar bäst för avancerade användningsfall som kräver anpassning bortom vad Microsofts hanterade tjänster erbjuder. Detta är inte en inbyggd funktion i Copilot eller Copilot Studio; vi skulle göra detta i Microsoft Azure.

Ett exempel på när man kan använda RAG kan vara om du behövde integrera en AI-agent med en proprietär databas eller tusentals PDF-filer som lagras utanför Microsoft 365 och tillämpa anpassade filter. Då kan en self-managed RAG vara nödvändig, men det kräver betydande insats.

Källa: https://learn.microsoft.com/en-us/azure/search/retrieval-augmented-generation-overview?tabs=docs

Vad man ska välja och när

Även om alla tre ansatserna innebär att hämta innehåll för att stödja språkgenerering är det bara den anpassade self-managed-lösningen som kvalificerar som ”äkta RAG” i teknisk mening. För de flesta organisationer som börjar är manuella uppladdningar eller SharePoint-anslutningar betydligt enklare och snabbare att implementera. De ger starka resultat med minimal konfiguration, och de låter team fokusera på design av användningsfall och adoption i stället för på infrastruktur.

Ett generellt råd från min sida på den här punkten:

Försök att bygga agenterna så nära din data som möjligt

Exempel: Om din data lagras i stora SQL-databaser eller externa CRM-system kommer en SharePoint-agent inte att lösa uppgiften. Om vi har all vår kunskap i SharePoint kan SharePoint-agenter eller Copilot Agents vara en bra start.

Anpassad RAG bör bara övervägas när dina behov går bortom vad de hanterade alternativen kan erbjuda, inte som standardutgångspunkt. En manuell uppladdning är utmärkt för den första piloten eller för små piloter med begränsad och specifik kunskap som inte uppdateras ofta. I många scenarier skulle vi bara använda ett SharePoint-bibliotek eller en SharePoint-webbplats med agenten. Därför fokuserar vi på ett scenario som ser ut så här:

Microsoft 365 Copilot och Copilot Agents: säkerhet och efterlevnad från start

Säker molninfrastruktur är grundbulten för AI i företag. Microsoft tillhandahåller det säkraste möjliga ramverket för våra agenter genom att sätta dem i kontexten av Microsoft 365 Copilot. Varje organisation kan lita på sitt befintliga säkerhetsramverk baserat på Conditional Access och multifaktorautentisering för åtkomst och sitt befintliga styrningsramverk baserat på Microsoft Purview.

Agenter som används i M365 Copilot eller publiceras från Copilot Studio som en Teams-chattbot är endast åtkomliga inom vår tenants gränser. Det betyder att vi får samma säkerhetsnivå för dessa applikationer som vi redan har.

Utöver detta erbjuder Microsoft flera tekniska och organisatoriska åtaganden som sammanfattas i det vi kallar ”Enterprise Grade Data Protection”.

Källa: https://learn.microsoft.com/en-gb/copilot/microsoft-365/microsoft-365-copilot-privacy?azure-portal=true

Microsoft 365 Copilot: Enterprise Data Protection (EDP) för prompts och svar

• Avtalsmässigt skydd: Prompts (användarinmatning) och svar (Copilots utdata) skyddas under Data Protection Addendum (DPA) och Product Terms. Dessa skydd är desamma som de som tillämpas på e-post i Exchange och filer i SharePoint.
• Datasäkerhet: Kryptering i vila och under överföring, fysiska säkerhetskontroller, dataisolering på tenant-nivå
• Integritetsåtaganden: Microsoft agerar som databehandlare och använder data endast enligt kundens instruktioner. Stöder GDPR, EU Data Boundary, ISO/IEC 27018 med mera.
• Åtkomstkontroll och policynedärvning: Copilot respekterar: identitetsmodeller och behörigheter, Sensitivity Labels, kvarhållningspolicyer, granskningsinställningar, adminkonfigurationer, riskreducering för AI och upphovsrätt samt skydd mot: prompt injection, skadligt innehåll, upphovsrättsproblem (via detektering av skyddat material och Customer Copyright Commitment)
• Ingen modellträning: Prompts, svar och Microsoft Graph-data används INTE för att träna grundmodeller.

Copilot Agents med SharePoint Online-kunskap:

• Behörighets- och delningsmodell: Agenter med åtkomst till SharePoint Online respekterar alltid behörigheterna för den kopplade SharePoint-webbplatsen. Det betyder att du å ena sidan behöver säkerställa att alla som ska ha åtkomst har minst läsbehörighet på webbplatsen; å andra sidan måste du vara vaksam på att inte bevilja onödiga behörigheter som kan exponera känslig information för obehöriga användare. Att konfigurera behörigheter korrekt är avgörande, eftersom Copilot Agents endast kommer att kunna komma åt och visa innehåll som den frågande användaren har rätt att se. Att dessutom dra nytta av Microsoft Purviews informationsskydd säkerställer att Sensitivity Labels och DLP-policyer följer med innehållet.
• Beständiga etiketter och DLP: Aktivera Microsoft Purview-informationsskydd så att Sensitivity Labels följer med innehållet. Copilot-agenter ärver etiketter på källdokument. Det betyder att om en fil klassificeras som ”Confidential” kommer allt AI-genererat innehåll eller dokument från och med då att bära den etiketten vidare. Denna beständiga etikettnedärvning fungerar tillsammans med DLP-policyer för att förhindra att AI oavsiktligt exponerar skyddad data. I praktiken betyder det att även om Copilot sammanfattar en känslig fil kommer sammanfattningen också att hanteras som känslig. Detta är något enastående som vi inte hittar utanför Microsoft 365, och vi kommer inte att se någon AI-agent som kan integrera lika djupt som detta i Microsoft 365-ekosystemet.

Bästa praxis för att förbereda SharePoint Online ytterligare för agentanvändning

För att förbereda SharePoint Online för effektiv användning med Copilot Agents, följ dessa bästa praxis:

Dedikerad SharePoint-webbplats

Skapa först en dedikerad SharePoint-webbplats eller en specifik mapp som är utformad uteslutande för din Copilot-agents kunskapsbas. Den ansatsen hjälper till att minimera problem kopplade till oversharing och minskar risken att användare av misstag laddar upp känsliga eller irrelevanta filer till agentens åtkomliga arkiv. Om du bestämmer dig för att använda en befintlig SharePoint-webbplats, granska dess innehåll noga för att säkerställa att ingen konfidentiell eller känslig information lagras där som inte bör kunna hittas av agenten.

Bevilja åtkomst

Det är också viktigt att säkerställa att alla avsedda användare har de nödvändiga läsbehörigheterna för att komma åt webbplatsen eller mappen. Om du behöver bevilja åtkomst manuellt, säkerställ att alla avsedda användare har läsåtkomst till webbplatsen (till exempel genom att lägga till dem i SharePoint-webbplatsens Visitors-grupp eller en lämplig säkerhetsgrupp i Azure AD) för att förenkla processen och förhindra oavsiktliga behörighetsfel.

Förbered filer

När du förbereder dokument för användning med Copilot Agents, kom ihåg att AI:n för närvarande inte kan tolka inbäddade bilder i filer. Lägg därför till beskrivande bildtexter eller alternativtext för att hjälpa till att säkerställa att viktig visuell information inte går förlorad. För textintensiva dokument, se till att när du sammanfattar eller refererar till innehåll hålla totalen till maximalt 1,5 miljoner ord eller 300 sidor för att Copilot ska fungera effektivt.

För Excel-filer, organisera din data så att varje fil fokuserar antingen på siffror eller på text, eftersom tabeller med blandat innehåll tenderar att ge mindre exakta resultat. Agenter svarar också mest tillförlitligt på frågor när relevant data finns i ett enda blad i arbetsboken.

Agenter svarar bäst på Excel-data när den finns i ett enda blad.

Exempel: Om du har en stor kundfeedbackundersökning lagrad i en enda Excel-fil, separera den kvantitativa datan (som betyg och numeriska svar) från den kvalitativa datan (som fritextåterkoppling) i två olika blad. Den här metoden gör att du kan använda verktyg som Python och Excel-formler för att effektivt analysera den numeriska datan (till exempel beräkna medelvärden, sortera resultat, fastställa konfidensnivåer), samtidigt som du drar nytta av M365 Copilots funktioner för sentimentanalys för att få insikter från den textbaserade återkopplingen.

Filbegränsningar

Var slutligen medveten om de filtyper och storleksbegränsningar som stöds av Copilot Agents och Copilot Studio. Följande tabell beskriver aktuellt stöd: https://learn.microsoft.com/en-us/microsoft-365-copilot/extensibility/copilot-studio-agent-builder-knowledge#file-size-limits

Ta även del av de bästa praxis som Microsoft har delat om dokumentlängder: https://support.microsoft.com/en-gb/topic/keep-it-short-and-sweet-a-guide-on-the-length-of-documents-that-you-provide-to-copilot-66de2ffd-deb2-4f0c-8984-098316104389

Filtyper som för närvarande inte stöds i SharePoint Online: officiellt är allt annat som inte listas där inte officiellt stött.

Vissa filtyper, som CSV-filer, kan fungera tillräckligt bra trots att de inte officiellt stöds, eftersom de liknar rena textformat. De flesta andra filtyper, särskilt containerfiler som CAB, EXE, ZIP samt bild-, video- och ljudformat som PNG, IMG, MP3 och MP4, stöds dock inte i nuläget.

Avslutande tankar

Genom att följa dessa rekommendationer kan du säkerställa att dina Copilot Agents har åtkomst till välstrukturerad, säker och högkvalitativ data, vilket maximerar deras nytta och minimerar risken för oavsiktlig dataexponering. Att investera tid i att förbereda din SharePoint-miljö lägger en stark grund för framgångsrik driftsättning och adoption av AI-agenter i din organisation.

Faktum är att många av våra ”Build-an-Agent”-projekt börjar precis där. Inte med att bygga agenten, utan med att förbereda infrastrukturen och kunskapen så att vi har data av god kvalitet att använda för AI:n, eftersom agenten bara är så bra som systemet under den.