Derfor har du brug for en solid infrastruktur for at være agent-ready i 2025
Før Microsoft 365 Copilot Agents kan levere reel værdi, skal fundamentet være solidt: rene data, korrekte rettigheder og en pålidelig infrastruktur. Denne guide forklarer, hvorfor datakvalitet afgør, om AI lykkes, fremhæver risici som oversharing og siloer og beskriver 10 praktiske trin til at gøre dit M365-miljø agent-ready: sikkert, compliant og skalerbart.

Prolog
Med denne allestedsnærværelse opstår der mange idéer og et ønske om at handle eller i det mindste eksperimentere. Hos glueckkanja AG støtter vi vores kunder gennem hele den proces. Vi udvikler og bygger naturligvis allerede agenter, men i 80 % af vores projekter ligger hovedfokus på at forberede data og tenant til at skabe agenter. Før du implementerer Copilot produktivt i din organisation, er det værd at kaste et kritisk blik på din infrastruktur. Når man træffer beslutninger på dette område, er der flere vigtige aspekter at forstå, før man udruller AI-agenter i stor skala. Derfor guider jeg dig i dette blogindlæg gennem de væsentlige trin og forskelle. I en tid, hvor AI-assistenter som Microsoft 365 Copilot Agents lover at forandre arbejdslivet, gælder ét princip frem for alt: AI er kun så god som det system, den hviler på.
Denne omfattende guide beskriver hvordan du forbereder dine data og din infrastruktur til Copilot Agents og dækker centrale praksisser i SharePoint, Teams og Power Platform.
Hvorfor din infrastruktur (dine data) betyder noget
Når vi bruger AI-agenter, er det afgørende at forstå, at disse agenter ikke i sig selv har viden om vores organisation, vores data eller vores særlige driftsmæssige kontekst. Som standard bærer en AI-agent kun den indbyggede viden, der stammer fra træningen af Large Language Model (LLM). For effektivt at forbedre og udvide disse AI-agenters kapabiliteter er det nødvendigt systematisk at integrere forskellige komponenter. Den forbedring kan opnås ved at implementere System Prompts, Knowledge Bases, Connectors, web-søgefunktioner, adgang til Microsoft Graph, Semantic Search og yderligere værktøjer. Tilsammen sætter disse komponenter AI-agenterne i stand til at levere mere præcise, kontekstuelt relevante svar og handlinger, tæt tilpasset organisationens konkrete behov og data. Da vi lige nu er helt i begyndelsen af den agentiske æra, vil mange af os starte med simple agenter, der henter information fra eksisterende SharePoint Online-biblioteker.
For os i it betyder det, at vi skal tage os af vores data i SharePoint Online mere end nogensinde før!
SharePoint Online = viden = data, og data = nøglen
Mit klare budskab: Før du tilføjer AI-copiloter til din organisation, få styr på dit datahus. De samme data, der fodrer dine Copilot Agents, fodrer også Microsoft 365 Copilot selv.
Og ikke kun det! Microsoft 365 Copilot vurderer de samme data. *Hvis de data er rodede, overdelte eller dårligt sikrede, kan AI'en uventet bringe forkerte eller følsomme oplysninger frem *for eksempel, forestil dig at spørge Copilot om virksomhedens struktur og få detaljer om en fortrolig omorganiseringsplan, du ikke var ment at skulle se. Den slags hændelser sker, når indhold er overdelt (tilgængeligt for bredt) på platforme som SharePoint eller Teams. Bemærk: Copilot respekterer alle eksisterende rettigheder, hvilket betyder, at sådan noget kun kan ske, når rettigheder er fejlkonfigureret. Omvendt vil AI-assistenter være mindre nyttige, hvis data er siloopdelte eller utilgængelige.
Copilot viser kun organisationsdata, som den enkelte bruger som minimum har visningsrettigheder til!
Hovedpointe: Enterprise-AI lykkes kun med et solidt datafundament. En nylig Microsoft-rapport udpeger oversharing af data, datalækage og ikke-compliant brug som de største udfordringer, der skal håndteres, før man udruller AI. Organisationer, der investerer i forberedelse af SharePoint Online og andre datakilder, vil trygt kunne udnytte Copilots fordele, mens de, der ikke gør det, risikerer sikkerhedsbrud eller irrelevante AI-resultater. Undersøgelser viser, at omkring en tredjedel af beslutningstagerne mangler fuldt overblik over kritiske data.

10 trin til at forbedre din M365-datainfrastruktur nu
Nu ved vi, at dine agenter får brug for data. Når vi som glueckkanja går ind i disse projekter, er dette vores typiske 10-punktsliste, som vi arbejder igennem fra top til bund sammen med vores kunder.
Trin 1: Tjek de centrale delingsindstillinger
Kontrollér tenant-brede indstillinger, der kan føre til oversharing. Gennemgå for eksempel standardpolitikkerne for delingslinks (f.eks. om »Alle med linket« eller »Personer i din organisation« er tilladt som standard for SharePoint/OneDrive), om brugere kan oprette offentlige Teams som standard, og om jeres Power Platform-miljø står åbent uden governance. Fejlkonfigurerede standarder her er en almindelig årsag til utilsigtet bred adgang..
Trin 2: Gennemgå offentlige Teams
Gennemgå alle Microsoft Teams, der er markeret som »Offentlig«. Et offentligt Team betyder, at alle i din organisation kan finde og tilgå dets indhold. Sørg for, at ethvert Team, der er sat til offentligt, reelt kun indeholder ikke-følsomt indhold, der er bredt egnet. Hvis ikke, så skift det til privat, eller justér medlemskabet. (Det er let for et Team at blive oprettet som offentligt og senere glemt, så filer eksponeres for alle medarbejdere.)
Trin 3: Gennemgå Graph Connectors
Undersøg, om jeres tenant har Microsoft Graph Connectors sat op, som trækker tredjepartsdata ind (f.eks. fra eksterne filsystemer, wikier osv.). Fjern eller sikr enhver connector, der indekserer data, som ikke alle bør se. Hvorfor? Indhold, der indekseres via Graph Connectors, bliver en del af jeres Microsoft Graph-søgeindeks, hvilket betyder, at Copilot potentielt kan bruge det til at besvare prompts. I vil kun have relevante, tilsigtede datakilder tilsluttet.
Trin 4: Lav en SharePoint Online Baseline Report
SPO rummer forskellige mulige risici for uønskede data i Agents og Copilot. I skal kigge efter forskellige nøglemålinger:
- Brudt rettighedsnedarvning på mappeniveau
- Offentlige SharePoint-sites
- Brug af "Everyone Except External Users" eller andre dynamiske grupper, der indeholder alle brugere
- Anyone-delingslinks
- Everyone-in-my-org-delingslinks
- Uønskede personer i grupperne Site Admins / Owners / Members / Visitors
Trin 5: Kategorisér og prioritér risici
Tag resultaterne fra trin 1-4, og ranger dem efter alvorlighed. Hvilke sites eller filer indeholder de mest forretningskritiske eller følsomme data og har samtidig eksponeringsrisici? Prioritér at rette dem. Ved at lægge forretningskontekst ovenpå (f.eks. et site med finansielle data over for et site med generiske skabeloner) kan I fokusere på de mest betydningsfulde problemer først.
Trin 6: Inddrag site-ejere i adgangsgennemgange
For hvert SharePoint-site (eller Team), der er markeret som risikabelt, skal site-ejeren dobbelttjekke, hvem der har adgang, og om det er passende. Ejerne er typisk tættest på indholdet og kan hurtigt få øje på: »Hov, hvorfor har alle læseadgang til det her? Sådan burde det ikke være.« Indfør en proces, hvor site-administratorer regelmæssigt attesterer rettighederne.
Trin 7: Etablér løbende tilsyn
Indfør en løbende overvågningsproces for nye oversharing-problemer. Kontrol med oversharing er ikke en engangsopgave; efterhånden som nye sites, Teams og filer bliver oprettet, skal I proaktivt fange fejlkonfigurationer. Overvej at bruge rapporter eller alerts i Microsoft Purview til at opdage ting som filer, der deles eksternt eller med meget store grupper, nye offentlige teams osv. Microsofts værktøjer kan automatisere alerts for disse forhold, så brug dem til at opretholde en stærk posture.
Trin 8: Anvend følsomhedsmærkater og DLP-politikker
Brug følsomhedsmærkater i Microsoft Purview til at klassificere data (Confidential, Highly Confidential osv.) og knyt de mærkater til beskyttelsesindstillinger. Et »Confidential«-mærkat kan for eksempel kryptere filer eller forhindre ekstern deling. Konfigurér også Data Loss Prevention (DLP)-politikker til at forhindre eller overvåge oversharing af følsomme oplysninger (som at blokere nogen fra at maile en liste med kunders CPR-numre). De værktøjer forhindrer ikke kun utilsigtede lækager i den daglige brug, de arbejder også sammen med Copilot: Hvis Copilot forsøger at tilgå eller udlevere mærket indhold på måder, den ikke burde, kan DLP gribe ind. Desuden fører Copilot selv dokumentets mærkat videre til sine svar, som nævnt senere.
Trin 9: Implementér Power Platform-governance
Udvid jeres tilsyn til Power Platform (Power Apps, Power Automate osv.). Definér DLP-politikker for Power Platform, så I kan styre connectors (så nogen ikke for eksempel kan lave et flow, der trækker data fra en følsom SharePoint-liste og sender dem til en ekstern tjeneste). Overvej også at have flere miljøer (Dev/Test/Prod) med ordentlig sikkerhed, så »citizen developers«, der bygger agenter eller apps, ikke utilsigtet eksponerer data. Grundlæggende: Forhindr, at Power Platform bliver en ustyret bagdør til jeres data.
Trin 10: Uddan og klæd dine agentbyggere på
Til sidst skal I lave retningslinjer og best practices for dem, der skal bygge eller udrulle AI-agenter (uanset om de er professionelle udviklere eller forretningsbrugere). Etablér træning i sikker håndtering af data: f.eks. hvordan man vælger passende videnkilder til en agent, hvorfor man ikke skal lægge følsomme filer ind i en bredt delt agent, hvordan man tester en agents output for uventede oplysninger. Ved at fremme en datakyndig kultur blandt »agent makers« reducerer I risikoen for, at nogen utilsigtet eksponerer information, når de designer en AI-løsning.
Kilder:
- 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 I har gennemført disse trin, kan I trygt gå videre og begynde at bygge produktive agenter. Til at bygge agenter har vi forskellige platforme og funktioner fra Microsoft, som vi kan læne os op ad. De mest fremtrædende eksempler finder I i næste kapitel. Har I brug for hjælp med denne liste, er I velkomne til at kontakte os, så vi kan hjælpe jer med denne vigtige forberedelsesøvelse.
Der er i mellemtiden intet til hinder for at lave PoC- eller testagenter med eksempeldata, manuelt uploadede filer eller specifikke data tilknyttet via RAG. Men vi anbefaler disse trin før en større implementering/udrulning af agenter.
Forstå forskellene mellem agentplatforme
Trin 1: Forstå dine agent-skabere
Efter grundarbejdet med at forberede data skal vi forstå, hvilke platforme der er til rådighed til at skabe disse agenter. Vi forsøger at skelne mellem værktøjerne ud fra funktioner og muligheder, men det er vigtigt at bemærke, at det at skabe agenter og vælge det rigtige værktøj er et spektrum. Der er flere måder at bygge AI-agenter på i Microsoft-økosystemet. Det er vigtigt at vælge den rigtige til jeres behov og jeres teams kompetenceniveau. Det gør det også klarere, hvornår man skal bruge Azure AI Foundry frem for de indbyggede Copilot Studio-værktøjer.
Microsoft tilbyder i dag en række forskellige værktøjer, der kan bygge agenter. Selvom de ligner hinanden, er de bygget til forskellige målgrupper og ekspertiseniveauer. Kig nærmere på oversigten nedenfor. At forstå, hvem der skal skabe og vedligeholde disse agenter, viser os også, hvilke videnkilder (= data) vi skal forberede til vores agenter. Ud over værktøjerne på listen nedenfor findes der endnu flere pro-code-løsninger til at bygge agenter som M365 Agents Toolkit, Visual Studio Code, Agent SDK og flere. Alle vores dataforberedelsestrin gælder også for dem, da de tilgår de samme data som andre agenter.
Kilde: https://www.egroup-us.com/news/microsoft-copilot-ai-integration/

Trin 2: Identificér use cases og krav til din platform
Som I sikkert kan regne ud, understøtter ikke enhver platform enhver use case. Agenter kan bruges til simple opgaver, som at besvare spørgsmål ud fra eksisterende viden, eller komplekse, som automatisk at generere svar eller udføre processer. Også den endelige UX, hvor og hvordan vi vil tilgå disse agenter, er vigtig for valget af platform.

Med det i baghovedet forsøger vi normalt at bruge den enklest mulige løsning til at bygge vores agent. Men vi skal også finde den løsning, der er skalerbar til den videre udvikling. Dog behøver ikke enhver agent at bygges på Agent AI Foundry helt fra begyndelsen.
Tip:
Er du i tvivl om, hvor du skal starte med at bygge din agent, kan du altid bruge Copilot Studio og enten integrere flere data fra Azure AI der og publicere den til Microsoft 365 Copilot. Sådan får du både »op- og nedadgående kompatibilitet«.
RAG (Retrieval-Augmented Generation) vs. SharePoint vs. Upload
Ved første øjekast ser alt ud til at være RAG, men der er forskelle! Når du første gang udforsker Copilot Agents og deres agentkapabiliteter, er det fristende at antage, at al videnintegration følger det samme RAG-mønster (Retrieval-Augmented Generation). Selvom de udefra alle kan ligne RAG, altså at hente dokumenter og generere svar, er måden, de arbejder på under motorhjelmen, markant forskellig. At forstå disse forskelle er afgørende for at vælge den rigtige tilgang ud fra jeres mål, skala og tekniske parathed. Her er en kort forklaring og oversigt
Manuel filupload
Manuel upload er den enkleste måde at tilføje viden til en Copilot-agent. Du trækker og slipper dokumenter direkte ind i Copilot Studio-grænsefladen. Microsoft indekserer automatisk disse filer og henter relevant indhold under en brugerforespørgsel. Det er ideelt til små pilotprojekter og tidlig test. Vær også opmærksom på, at indholdet af filerne bør være tilgængeligt for alle med adgang til agenten. Der er ingen rettighedsstyring her, som du skal tage dig af. Til gengæld skal du på længere sigt manuelt opdatere disse filer, hvis noget ændrer sig. Aktuelt kan du for Copilot Agents tilføje op til 20 filer manuelt.
SharePoint Online
Denne metode bruger Microsofts Retrieval API til at tilgå indhold direkte fra SharePoint Online tilsluttet via Graph Connector. Agenten henter det mest relevante indhold live på forespørgselstidspunktet og respekterer eksisterende Microsoft 365-rettigheder. Indholdet kan være SharePoint-sites, dokumentbiblioteker, mapper eller filer. Det er dynamisk, sikkert og velegnet til at skalere på tværs af afdelinger eller forretningsenheder uden at skulle drive sin egen infrastruktur. Ved at bygge videre på den eksisterende infrastruktur bruger vi den indbyggede sikkerhedsmodel fra SharePoint, hvilket er en enorm fordel sammenlignet med andre videnmuligheder. Afdelinger kan let opdatere filerne, og det afspejles i agenten. Det betyder, at hvis to brugere med forskellige adgangsniveauer spørger agenten, kan den ene få et svar fra en bestemt fil, mens en anden bruger (uden adgang) ikke ville, hvilket er præcis den adfærd, vi ønsker.
Bemærk: SharePoint-lister er aktuelt ikke en understøttet videntype, så du kan ikke indeksere dem ud af boksen (Q3 2025)
Custom RAG (selvadministreret)
I en klassisk RAG-opsætning bygger og administrerer du hele retrieval-pipelinen selv. Det omfatter forbehandling af dokumenter, chunking, embedding, lagring i en vektordatabase og hentning af de bedste match på forespørgselstidspunktet. Det giver dig fuld kontrol over, hvordan indhold behandles og hentes, men det medfører også kompleksitet og vedligeholdelsesbyrde. Det egner sig bedst til avancerede use cases, der kræver tilpasning ud over, hvad Microsofts managed services tilbyder. Dette er ikke en indbygget funktion i Copilot eller Copilot Studio; det ville vi gøre i Microsoft Azure.
Et eksempel på, hvornår man kan bruge RAG, kunne være: Hvis du skulle integrere en AI-agent med en proprietær database eller tusindvis af PDF'er gemt uden for Microsoft 365 og anvende brugerdefinerede filtre, kunne en selvadministreret RAG være nødvendig, men det kræver en betydelig indsats.
kilde: https://learn.microsoft.com/en-us/azure/search/retrieval-augmented-generation-overview?tabs=docs
Hvad man skal vælge hvornår
Selvom alle tre tilgange indebærer at hente indhold til at understøtte sproggenerering, er det kun den selvadministrerede løsning, der kvalificerer sig som »ægte RAG« i teknisk forstand. For de fleste organisationer, der lige er gået i gang, er manuelle uploads eller SharePoint-forbindelser markant lettere og hurtigere at implementere. De giver stærke resultater med minimal opsætning, og de lader teams fokusere på design af use cases og adoption i stedet for infrastruktur.
Et generelt råd fra min side på dette punkt:
Prøv at bygge agenterne så tæt på jeres data som muligt
Eksempel: Hvis jeres data ligger i store SQL-databaser eller eksterne CRM-systemer, klarer en SharePoint-agent ikke opgaven. Har vi al vores viden i SharePoint, kan SharePoint Agents eller Copilot Agents være en god start.
Custom RAG bør kun overvejes, når jeres behov går ud over, hvad de managed muligheder kan levere, ikke som standardudgangspunkt. En manuel upload er glimrende til det første pilotprojekt eller til små pilotprojekter med begrænset og specifik viden, der ikke opdateres ofte. I mange scenarier ville vi bare bruge et SharePoint-bibliotek eller -site sammen med agenten. Derfor fokuserer vi på et scenarie, der ser sådan ud:
Microsoft 365 Copilot og Copilot Agents: sikkerhed og compliance ud af boksen
Sikker cloud-infrastruktur er grundstenen for enterprise-AI. Microsoft leverer den mest sikre ramme, der er mulig, for vores agenter ved at sætte dem i kontekst af Microsoft 365 Copilot. Enhver organisation kan stole på sin eksisterende sikkerhedsramme baseret på Conditional Access og multifaktor-autentificering til adgang og på sin eksisterende governance-ramme baseret på Microsoft Purview.
Agenter, der bruges i M365 Copilot eller publiceres fra Copilot Studio som en Teams-chatbot, er kun tilgængelige inden for vores tenant-grænser. Det betyder, at vi får det samme sikkerhedsniveau for disse applikationer, som vi allerede har.

Ud over det tilbyder Microsoft flere tekniske og organisatoriske forpligtelser samlet i det, vi kalder »Enterprise Grade Data Protection«.
Microsoft 365 Copilot: Enterprise Data Protection (EDP) for prompts og svar
- Kontraktlig beskyttelse: Prompts (brugerinput) og svar (Copilot-output) er beskyttet under Data Protection Addendum (DPA) og Product Terms. Disse beskyttelser er de samme som dem, der gælder for mails i Exchange og filer i SharePoint.
- Datasikkerhed: Kryptering i hvile og under transport, fysiske sikkerhedskontroller, dataisolation på tenant-niveau
- Privatlivsforpligtelser Microsoft agerer som databehandler og bruger kun data efter kundens instruks. Understøtter GDPR, EU Data Boundary, ISO/IEC 27018 med flere.
- Adgangskontrol og nedarvning af politikker: Copilot respekterer: identitetsmodeller og rettigheder, følsomhedsmærkater, opbevaringspolitikker, auditindstillinger, administratorkonfigurationer, AI- og ophavsretsrisikoreduktion og beskyttelse mod: prompt injection, skadeligt indhold, ophavsretsproblemer (via detektion af beskyttet materiale og Customer Copyright Commitment)
- Ingen modeltræning: Prompts, svar og Microsoft Graph-data bliver IKKE brugt til at træne foundation-modeller.
Copilot Agents med SharePoint Online-viden:
- Rettigheds- og delingsmodel: Agenter med SharePoint Online-adgang respekterer altid rettighederne på det tilknyttede SharePoint-site. Det betyder, at du på den ene side skal sikre, at alle, der bør have adgang, som minimum har læserettigheder på sitet; på den anden side skal du være årvågen over for ikke at tildele unødvendige rettigheder, der kunne eksponere følsomme oplysninger for uautoriserede brugere**. Korrekt konfiguration af rettigheder er essentie**l, da Copilot Agents kun vil kunne tilgå og vise indhold, som den forespørgende bruger har lov til at se. Derudover sikrer brug af Microsoft Purview information protection, at følsomhedsmærkater og data loss prevention (DLP)-politikker følger med indholdet
- Vedvarende mærkater og DLP: Aktivér Microsoft Purview information protection, så følsomhedsmærkater følger med indholdet. Copilot-agenter arver mærkaterne på kildedokumenterne. Det betyder, at hvis en fil er klassificeret »Confidential«, vil alt AI-genereret indhold eller dokument fra da af bære det mærkat videre. Denne vedvarende mærkatnedarvning arbejder sammen med Data Loss Prevention-politikker for at forhindre, at AI utilsigtet eksponerer beskyttede data. I praksis betyder det, at selv hvis Copilot opsummerer en følsom fil, vil resuméet også blive behandlet som følsomt. Det er noget enestående, som vi ikke finder uden for Microsoft 365, og vi kommer ikke til at se nogen AI-agent, der kan integrere så dybt i Microsoft 365-økosystemet!
Best practices til yderligere forberedelse af SharePoint Online til agentbrug
For at forberede SharePoint Online til effektiv brug med Copilot Agents skal I følge disse best practices:
Dedikeret SharePoint-site
Opret først et dedikeret SharePoint-site eller en specifik mappe, der udelukkende er designet til jeres Copilot-agents videnbase. Den tilgang hjælper med at minimere problemer med oversharing og reducerer risikoen for, at brugere ved et uheld uploader følsomme eller irrelevante filer til agentens tilgængelige arkiv. Beslutter I at bruge et eksisterende SharePoint-site, så gennemgå omhyggeligt dets indhold for at sikre, at der ikke ligger fortrolige eller følsomme oplysninger, som agenten ikke bør kunne finde.
Tildeling af adgang
Det er også vigtigt at sikre, at alle tiltænkte brugere har de nødvendige læserettigheder til at tilgå sitet eller mappen. Skal I tildele adgang manuelt, så sørg for, at alle tiltænkte brugere har læseadgang til sitet (for eksempel ved at tilføje dem til SharePoint-sitets Visitors-gruppe eller en passende Azure AD-sikkerhedsgruppe) for at forenkle processen og forhindre utilsigtede fejlkonfigurationer af rettigheder.
Forbered filer
Når I forbereder dokumenter til brug med Copilot Agents, så husk, at AI'en aktuelt ikke kan fortolke indlejrede billeder i filer. Tilføj derfor beskrivende billedtekster eller alternativ tekst for at hjælpe med at sikre, at vigtig visuel information ikke går tabt. For teksttunge dokumenter skal I sikre, at I ved opsummering eller reference af indhold holder jer til maksimalt 1,5 millioner ord eller 300 sider, så Copilot fungerer effektivt.
For Excel-filer skal I organisere jeres data, så hver fil fokuserer enten på tal eller på tekst, da tabeller med blandet indhold har tendens til at give mindre præcise resultater. Agenter svarer også mest pålideligt på forespørgsler, når de relevante data ligger i ét enkelt ark i projektmappen.
Agenter svarer bedst på Excel-data, når de ligger i ét ark.
Eksempel: Har I en stor kundetilfredshedsundersøgelse gemt i én enkelt Excel-fil, så adskil de kvantitative data (som ratings og numeriske svar) fra de kvalitative data (som fritekstfeedback) i to forskellige ark. Den metode gør det muligt at bruge værktøjer som Python og Excel-formler til effektivt at analysere de numeriske data (f.eks. beregne gennemsnit, sortere resultater, bestemme konfidensniveauer), mens I udnytter M365 Copilots funktioner til sentimentanalyse til at få indsigt i den tekstbaserede feedback.
Filbegrænsninger
Endelig skal I være opmærksomme på de filtyper og størrelsesbegrænsninger, som Copilot Agents og Copilot Studio understøtter. Tabellen nedenfor viser den aktuelle understøttelse:https://learn.microsoft.com/en-us/microsoft-365-copilot/extensibility/copilot-studio-agent-builder-knowledge#file-size-limits
Vær også opmærksom på de best practices, Microsoft har delt 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
| Filtype | SharePoint Online - grænse | Manuel upload - grænse |
|---|---|---|
.doc | 150 MB | 100 MB |
.docx | 512 MB | 100 MB |
.html | 150 MB | ikke understøttet |
.pdf | 512 MB | 100 MB |
.ppt | 150 MB | 100 MB |
.pptx | 512 MB | 100 MB |
.txt | 150 MB | 100 MB |
.xls | 150 MB | 100 MB |
.xlsx | 150 MB | 100 MB |
Aktuelt ikke-understøttede filtyper i SharePoint Online: Officielt er alt andet, der ikke står på listen der, ikke officielt understøttet.
Visse filtyper, som CSV-filer, kan fungere tilstrækkeligt, selvom de ikke officielt er understøttet, fordi de minder meget om rene tekstformater. De fleste andre filtyper, særligt containerfiler som CAB, EXE, ZIP samt billed-, video- og lydformater som PNG, IMG, MP3 og MP4, er dog ikke understøttet på nuværende tidspunkt.
Afsluttende tanker
Ved at følge disse anbefalinger kan I sikre, at jeres Copilot Agents har adgang til velstrukturerede, sikre data af høj kvalitet, så deres nytteværdi maksimeres og risikoen for utilsigtet dataeksponering minimeres. At investere tid i at forberede jeres SharePoint-miljø lægger et stærkt fundament for en vellykket udrulning og adoption af AI-agenter i jeres organisation.
Faktisk starter mange af vores »byg-en-agent«-projekter præcis der. Ikke med at bygge agenten, men med at forberede den infrastruktur og viden, der giver os data af god kvalitet at bruge til AI'en, for agenten er kun så god som det system, den hviler på!
Agent-Ready Infrastructure: dit grundlag for produktive Copilot Agents
AI er kun så god som den infrastruktur, den kører på. Den, der for alvor vil bruge Copilot Agents i praksis, har brug for mere end licensering og aktivering. Det handler om strukturerede data, konsistent governance og en gennemtænkt arkitektur, der skalerer, kort sagt: en Agent-Ready Infrastructure.
I vores engelsksprogede oplæg viser vi dig:
- Hvorfor datakvalitet og informationsarkitektur er afgørende for succes
- Hvordan du gør dit Microsoft 365-miljø klar til produktive agenter
- Og hvilke skruer du skal dreje på i dag, for at din virksomhed i morgen får reel gavn af AI














