Derfor trenger du en solid infrastruktur for å være agent-ready i 2025

Prolog

Med denne omnipresente rollen dukker det opp mange ideer og et ønske om å handle eller i det minste eksperimentere. Hos glueckkanja AG følger vi kundene våre gjennom hele denne prosessen. Vi bygger og utvikler selvsagt allerede agents, men i 80 % av prosjektene våre ligger hovedfokuset på å forberede dataene og tenant for at agents kan bygges. Før du ruller ut Copilot produktivt i organisasjonen din, lønner det seg å se kritisk på infrastrukturen din. Når du tar beslutninger på dette området, er det flere viktige aspekter du bør forstå før du setter AI-agenter i drift i stor skala. Derfor tar jeg deg i dette blogginnlegget gjennom de vesentlige trinnene og forskjellene. I en tid der AI-assistenter som Microsoft 365 Copilot Agents lover å endre arbeidshverdagen, gjelder ett prinsipp fremfor alt: AI er bare så god som systemet under den.

Denne omfattende guiden viser hvordan du forbereder data og infrastruktur for Copilot Agents, og dekker viktige praksiser i SharePoint, Teams og Power Platform.

Hvorfor infrastrukturen din (data) betyr noe

Når vi tar i bruk AI-agenter, er det avgjørende å forstå at disse agentene ikke har iboende kunnskap om organisasjonen vår, dataene våre eller den unike driftskonteksten vår. Som standard bærer en AI-agent bare med seg den innebygde kunnskapen fra treningen av Large Language Model (LLM). For å styrke og utvide kapabilitetene til disse AI-agentene effektivt, må vi systematisk integrere ulike komponenter. Det gjøres gjennom System Prompts, Knowledge Bases, Connectors, Web-Search-funksjonalitet, tilgang til Microsoft Graph, Semantic Search og andre verktøy. Til sammen setter disse komponentene AI-agentene i stand til å levere mer presise og kontekstuelt relevante svar og handlinger som treffer organisasjonens spesifikke behov og data. Siden vi står helt i starten av den agentiske epoken, vil mange av oss begynne med enkle agents som henter informasjon fra eksisterende SharePoint Online-biblioteker.

For oss i IT betyr det at vi må ta bedre vare på dataene våre i SharePoint Online enn noen gang.

SharePoint Online = kunnskap = data, og data = nøkkelen

Mitt tydelige budskap: Før du kobler AI-copilots på organisasjonen din, få orden i datahuset ditt. De samme dataene som mater Copilot Agents mater også Microsoft 365 Copilot.

Og ikke bare det. Microsoft 365 Copilot vurderer de samme dataene. Er dataene rotete, delt for bredt eller dårlig sikret, kan AI-en løfte fram feilaktig eller sensitiv informasjon på uventede måter. Se for deg at du spør Copilot om selskapsstrukturen og får detaljer om en konfidensiell omorganiseringsplan du egentlig ikke skulle sett. Slike hendelser oppstår når innhold er overshared (tilgjengelig for bredt) på plattformer som SharePoint eller Teams. Merk: Copilot respekterer alle eksisterende tillatelser, så noe slikt kan bare skje når tillatelser er feilkonfigurert. Motsatt blir AI-assistenter lite nyttige om dataene er siloerte eller utilgjengelige.

Copilot henter kun fram organisasjonsdata som den enkelte brukeren minst har view-tillatelser til

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

Hovedpoeng: Enterprise-AI lykkes bare med en solid data foundation. En fersk Microsoft-rapport peker på oversharing av data, datalekkasje og bruk som ikke er compliant som de viktigste utfordringene å håndtere før AI rulles ut. Organisasjoner som investerer i forberedelse av SharePoint Online og andre datakilder, henter ut Copilots gevinster med trygghet, mens de som ikke gjør det, risikerer sikkerhetsbrudd eller irrelevante AI-utdata. Studier viser at om lag en tredel av beslutningstakerne mangler full oversikt over kritiske data.

10 trinn for å forbedre M365-datainfrastrukturen din nå

Nå vet vi at agents trenger data. Når vi hos glueckkanja går inn i slike prosjekter, er dette den typiske tipunktslisten vi jobber gjennom sammen med kundene, fra topp til bunn.

Trinn 1: sjekk de sentrale sharing-innstillingene

Verifiser tenant-wide-innstillinger som kan føre til oversharing. Se for eksempel nøye på standard policies for lenkedeling (om «Anyone with the link» eller «People in your organization» er tillatt som standard for SharePoint/OneDrive), om brukere kan opprette offentlige Teams som standard, og om Power Platform-miljøet ditt er åpent uten governance. Feilkonfigurerte standardinnstillinger her er en vanlig årsak til utilsiktet bred tilgang.

Trinn 2: revider offentlige Teams

Gå gjennom alle Microsoft Teams som er merket «Public». Et offentlig Team betyr at hvem som helst i organisasjonen din kan finne og få tilgang til innholdet. Sørg for at ethvert Team som er satt til offentlig, faktisk bare inneholder ikke-sensitivt innhold som passer for et bredt publikum. Hvis ikke, bytt til privat eller juster medlemskapet. Det er lett for et Team å bli opprettet som offentlig og senere glemt, slik at filer eksponeres for alle ansatte.

Trinn 3: gjennomgå Graph Connectors

Sjekk om tenant har noen Microsoft Graph Connectors som henter inn tredjepartsdata (for eksempel fra eksterne filsystemer, wikis osv.). Fjern eller sikre enhver connector som indekserer data som ikke alle bør se. Hvorfor? Innhold som indekseres via Graph Connectors, blir en del av Microsoft Graph-søkeindeksen din, og det betyr at Copilot potensielt kan bruke det til å svare på prompts. Du ønsker kun relevante og tilsiktede datakilder tilkoblet.

Trinn 4: generer en SharePoint Online Baseline Report

SPO har flere mulige risikoer for uønskede data i Agents og Copilot. Du bør se etter ulike nøkkelmetrikker:

• brutt tillatelsesarv på mappenivå
• offentlige SharePoint-sites
• bruk av «Everyone Except External Users» eller andre dynamiske grupper som inneholder alle brukere
• Anyone-sharing links
• Everyone-in-my-org-sharing links
• uønskede personer i Site Admins/Owners/Members/Visitors-gruppen

Trinn 5: kategoriser og prioriter risikoene

Ta funnene fra trinn 1–4 og ranger dem etter alvorlighetsgrad. Hvilke sites eller filer bærer mest forretningskritiske eller sensitive data og har samtidig eksponeringsrisiko? Prioriter å utbedre disse først. Ved å legge på forretningskontekst, som at en site med finansielle data veier tyngre enn en site med generiske maler, kan du fokusere på de mest virkningsfulle problemene først.

Trinn 6: involver site owners i tilgangsgjennomganger

For hver SharePoint-site (eller Team) som er markert som risikoutsatt, bør site owner dobbeltsjekke hvem som har tilgang og om det er passende. Owners står typisk nærmest innholdet og oppdager raskt: «Å, hvorfor har alle leserettigheter til dette? Det burde ikke være tilfellet.» Etabler en prosess der site admins sertifiserer tillatelser jevnlig.

Trinn 7: etabler løpende oversikt

Sett opp en kontinuerlig overvåkingsprosess for nye oversharing-problemer. Kontroll over oversharing er ikke en engangsfiks; når nye sites, Teams og filer opprettes, må du fange opp feilkonfigurasjoner proaktivt. Vurder å bruke rapporter og varsler fra Microsoft Purview for å fange opp ting som filer delt eksternt eller til store grupper, nye offentlige Teams som opprettes, osv. Microsofts verktøy kan automatisere varsler for slike tilstander, så bruk dem for å opprettholde en sterk posisjon.

Trinn 8: bruk Sensitivity Labels og DLP-policies

Bruk Microsoft Purview Sensitivity Labels til å klassifisere data (Confidential, Highly Confidential, osv.) og koble labelene til beskyttelsesinnstillinger. En «Confidential»-label kan for eksempel kryptere filer eller hindre ekstern deling. Konfigurer også Data Loss Prevention (DLP)-policies for å hindre eller overvåke oversharing av sensitiv informasjon (som å blokkere at noen sender en liste med kundenes SSN på e-post). Disse verktøyene forhindrer ikke bare tilfeldige lekkasjer i daglig bruk, de virker også sammen med Copilot: hvis Copilot forsøker å få tilgang til eller sende ut merket innhold på måter den ikke skal, kan DLP gripe inn. I tillegg vil Copilot selv føre dokumentets label videre til svarene sine, som beskrevet lenger ned.

Trinn 9: innfør Power Platform governance

Utvid oversynet ditt til Power Platform (Power Apps, Power Automate osv.). Definer DLP-policies for Power Platform for å kontrollere connectors (slik at ingen for eksempel lager en flow som henter data fra en sensitiv SharePoint-liste og publiserer det til en ekstern tjeneste). Vurder også å ha flere miljøer (Dev/Test/Prod) med skikkelig sikkerhet, slik at «Citizen Developers» som bygger agents eller apper, ikke uforvarende eksponerer data. I bunn og grunn: unngå at Power Platform blir en ustyrt bakvei til dataene dine.

Trinn 10: lær opp og aktiver Agent Builders

Til slutt: lag retningslinjer og beste praksis for dem som skal bygge eller ta i bruk AI-agenter (enten de er profesjonelle utviklere eller forretningsbrukere). Etabler opplæring i trygg databehandling, for eksempel hvordan man velger egnede kunnskapskilder for en agent, hvorfor man ikke bør inkludere sensitive filer i en bredt delt agent, og hvordan man tester en agents utdata for uventet informasjon. Ved å fremme en datavarslet kultur blant «agent makers» reduserer du sjansen for at noen ved en feiltakelse eksponerer informasjon når de utformer 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 du har gjennomført disse trinnene, kan du trygt gå videre og begynne å bygge produktive agents. For å bygge agents har vi ulike plattformer og funksjoner fra Microsoft å støtte oss på. Du finner de mest fremtredende eksemplene i neste kapittel. Trenger du hjelp med denne listen, er det bare å ta kontakt med oss, så bistår vi deg med denne viktige forberedelsen.

Ingenting hindrer deg i mellomtiden i å lage PoC- eller test-agents med eksempeldata, manuelt opplastede filer eller spesifikke data koblet på via RAG. Men vi anbefaler disse trinnene før en større implementering eller utrulling av agents.

Forstå forskjellene mellom Agent-plattformer

Trinn 1: forstå agent-creators dine

Etter fundamentarbeidet med å forberede dataene må vi forstå hvilke plattformer som er tilgjengelige for å lage agents. Vi prøver å skille disse verktøyene på funksjoner og muligheter, men det er viktig å merke seg at å lage agents og velge riktig verktøy er et spekter. Det finnes flere måter å bygge AI-agenter på i Microsoft-økosystemet. Det er viktig å velge den riktige for behovene dine og teamets ferdighetsnivå. Det klargjør også når man skal bruke Azure AI Foundry kontra innebygde Copilot Studio-verktøy.

Microsoft tilbyr i dag et sett med ulike verktøy som kan bygge agents. Selv om de virker like, er de laget for ulike målgrupper og ferdighetsnivåer. Ta en nærmere titt på oversikten under. Ved å forstå hvem som skal lage og vedlikeholde disse agents, ser vi også hvilke Knowledge-kilder (= data) vi må forberede for våre Agents. I tillegg til verktøyene i listen under finnes det flere pro-code-løsninger for å bygge agents, som M365 Agents Toolkit, Visual Studio Code, Agent SDK og mer. Alle våre trinn for dataforberedelse gjelder også for disse, siden de får tilgang til de samme dataene som andre agents.

Kilde: https://www.egroup-us.com/news/microsoft-copilot-ai-integration/

Trinn 2: identifiser bruksområder og krav til plattformen din

Som du sikkert tenker, støtter ikke enhver plattform ethvert bruksområde. Agents kan brukes til enkle oppgaver, som å svare på spørsmål basert på eksisterende kunnskap, eller komplekse, som å generere svar automatisk eller kjøre prosesser. Også den endelige UX-en, hvor og hvordan vi vil aksessere agents, er viktig når vi skal velge en plattform.

Med dette i bakhodet prøver vi vanligvis å bruke den enkleste løsningen som er mulig for å bygge en Agent. Samtidig må vi finne en løsning som skalerer for videre utvikling. Men ikke enhver Agent trenger å bygges på Agent AI Foundry helt fra starten.

Tips:

Er du usikker på hvor du skal starte når du skal bygge Agent-en din, kan du alltid bruke Copilot Studio, og enten integrere mer data fra Azure AI der og publisere den til Microsoft 365 Copilot. Slik får du både «opp- og nedoverkompatibilitet».

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

Ved første øyekast ser alt ut som RAG, men det er forskjeller. Når du først utforsker Copilot Agents og de agentiske kapabilitetene, er det fristende å anta at all kunnskapsintegrasjon følger det samme RAG-mønsteret (Retrieval-Augmented Generation). Selv om det utenfra kan se ut som RAG, altså å hente dokumenter og generere svar, er måten det fungerer på under panseret vesentlig forskjellig. Å forstå disse forskjellene er avgjørende for å velge riktig tilnærming ut fra mål, skala og teknisk modenhet. Her er en kort forklaring og oversikt.

Manuell filopplasting

Manuell opplasting er den enkleste måten å legge til kunnskap i en Copilot-agent på. Du drar og slipper dokumenter direkte i Copilot Studio-grensesnittet. Microsoft indekserer disse filene automatisk og henter fram relevant innhold under en brukerforespørsel. Dette er ideelt for små piloter og tidlig testing. Vær også oppmerksom på at innholdet i filene bør være tilgjengelig for alle med tilgang til agent-en. Det finnes ingen egen tilgangsstyring her som du må ta hensyn til. På den annen side må du manuelt oppdatere disse filene på sikt hvis noe endres. Per i dag kan du for Copilot Agents legge til inntil 20 filer manuelt.

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

SharePoint Online

Denne metoden bruker Microsofts Retrieval API til å aksessere innhold direkte fra SharePoint Online, tilkoblet via Graph Connector. Agent-en henter det mest relevante innholdet live på spørretidspunktet og respekterer eksisterende Microsoft 365-tillatelser. Innholdet kan være SharePoint-sites, dokumentbiblioteker, mapper eller filer. Det er dynamisk, sikkert og godt egnet for skalering på tvers av avdelinger eller forretningsområder uten at du må drifte egen infrastruktur. Vi bygger videre på eksisterende infrastruktur og bruker den innebygde sikkerhetsmodellen fra SharePoint, noe som er en stor fordel sammenlignet med andre kunnskapsvalg. Avdelinger kan enkelt oppdatere filene, og det reflekteres i agent-en. Det betyr at hvis to brukere med ulikt tilgangsnivå spør agent-en, kan den ene få et svar fra en bestemt fil mens en annen bruker (uten tilgang) ikke får det, som er nettopp den oppførselen vi ønsker.

Merk: SharePoint-lister er per i dag ikke en støttet kunnskapstype, så du kan ikke indeksere dem uten videre (Q3 2025).

Egendefinert RAG (selvforvaltet)

I et klassisk RAG-oppsett bygger og drifter du hele retrieval-pipen selv. Det inkluderer forbehandling av dokumenter, chunking, embedding, lagring i en vektordatabase og henting av de beste treffene ved spørring. Det gir deg full kontroll over hvordan innholdet behandles og hentes, men medfører også kompleksitet og vedlikeholdsarbeid. Det passer best for avanserte bruksområder som krever tilpasning utover det Microsofts managed services tilbyr. Dette er ikke en innebygd funksjon i Copilot eller Copilot Studio; det ville vi gjøre i Microsoft Azure.

Et eksempel på når du skulle bruke RAG, kunne være dersom du måtte integrere en AI-agent med en proprietær database eller tusenvis av PDF-er lagret utenfor Microsoft 365, og bruke egendefinerte filtre. Da kan en selvforvaltet RAG være nødvendig, men det krever betydelig innsats.

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

Hva du bør velge, og når

Selv om alle tre tilnærmingene innebærer å hente innhold for å understøtte språkgenerering, er det bare den selvforvaltede, egendefinerte løsningen som kvalifiserer som «ekte RAG» i teknisk forstand. For de fleste organisasjoner som starter opp, er manuell opplasting eller SharePoint-tilkoblinger vesentlig enklere og raskere å implementere. De gir gode resultater med minimal oppsett, og lar teamene fokusere på design av bruksområder og adopsjon, ikke infrastruktur.

Et generelt råd fra min side på dette punktet:

Prøv å bygge agents så nær dataene dine som mulig

Eksempel: Ligger dataene dine i store SQL-databaser eller eksterne CRM-systemer, gjør ikke en SharePoint-Agent jobben. Har vi all kunnskap i SharePoint, kan SharePoint Agents eller Copilot Agents være et godt utgangspunkt.

Egendefinert RAG bør vurderes kun når behovene dine går utover det de managed-alternativene kan tilby, ikke som standard utgangspunkt. En manuell opplasting er utmerket for første pilot eller for små piloter med begrenset og spesifikk kunnskap som ikke oppdateres ofte. I mange scenarioer vil vi rett og slett bruke et SharePoint-bibliotek eller en site sammen med agent-en. Derfor ser vi nærmere på et scenario som dette:

Microsoft 365 Copilot & Copilot Agents: security & compliance ut av boksen

Sikker cloud-infrastruktur er fundamentet for enterprise-AI. Microsoft leverer det sikreste rammeverket som er mulig for våre Agents, ved å plassere dem i konteksten av Microsoft 365 Copilot. Enhver organisasjon kan stole på sitt eksisterende sikkerhetsrammeverk basert på Conditional Access og Multi-Factor Authentication for tilgang, og på sitt eksisterende governance-rammeverk basert på Microsoft Purview.

Agents som brukes i M365 Copilot eller publiseres fra Copilot Studio som en Teams Chatbot, er kun tilgjengelige innenfor tenant-grensene våre. Det betyr at vi får det samme sikkerhetsnivået for disse applikasjonene som vi allerede har.

I tillegg tilbyr Microsoft en rekke tekniske og organisatoriske forpliktelser samlet under det vi kaller «Enterprise Grade Data Protection».

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

Microsoft 365 Copilot: Enterprise Data Protection (EDP) for prompts og responses

• Kontraktsmessig beskyttelse: prompts (brukerinput) og responses (Copilot-utdata) er beskyttet under Data Protection Addendum (DPA) og Product Terms. Denne beskyttelsen er den samme som gjelder for e-poster i Exchange og filer i SharePoint.
• Datasikkerhet: kryptering i hvile og i transitt, fysiske sikkerhetstiltak, dataisolasjon på tenant-nivå
• Personvernforpliktelser: Microsoft opptrer som data processor og bruker data kun etter instruks fra kunden. Støtter GDPR, EU Data Boundary, ISO/IEC 27018 og mer.
• Tilgangskontroll og policy-arv: Copilot respekterer identitetsmodeller og tillatelser, sensitivity labels, retention-policies, auditinnstillinger, adminkonfigurasjoner, AI & Copyright Risk Mitigation samt beskyttelse mot prompt injection, skadelig innhold og opphavsrettslige utfordringer (via protected material detection og Customer Copyright Commitment)
• Ingen modelltrening: prompts, responses og Microsoft Graph-data brukes IKKE til å trene foundation models.

Copilot Agents med SharePoint Online-kunnskap:

• Tillatelses- og delingsmodell: Agents med tilgang til SharePoint Online respekterer alltid tillatelsene til den tilhørende SharePoint-siten. Det betyr at på den ene siden må du sørge for at alle som bør ha tilgang, har minst leserettigheter til siten; på den andre siden må du være årvåken slik at du ikke tildeler unødvendige tillatelser som kan eksponere sensitiv informasjon for uautoriserte brukere**. Å konfigurere tillatelser riktig er essensielt**, siden Copilot Agents kun vil kunne aksessere og løfte fram innhold som den spørrende brukeren har lov til å se. I tillegg sikrer bruk av Microsoft Purview information protection at sensitivity labels og data loss prevention (DLP)-policies følger med innholdet
• Vedvarende labels og DLP: aktiver Microsoft Purview information protection slik at sensitivity labels følger med innholdet. Copilot Agents arver labels på kildedokumenter. Det betyr at hvis en fil er klassifisert som «Confidential», vil alt AI-generert innhold eller dokument videre bære den labelen. Denne vedvarende label-arven virker sammen med Data Loss Prevention-policies for å hindre at AI utilsiktet eksponerer beskyttede data. I praksis betyr det at selv om Copilot oppsummerer en sensitiv fil, vil oppsummeringen også behandles som sensitiv. Dette er noe unikt vi ikke finner utenfor Microsoft 365, og vi kommer ikke til å se noen AI-Agent som er i stand til å integrere så dypt i Microsoft 365-økosystemet.

Beste praksis for å forberede SharePoint Online videre for Agent-bruk

For å forberede SharePoint Online for effektiv bruk med Copilot Agents, følg disse beste praksisene:

Dedikert SharePoint-site

Opprett først en dedikert SharePoint-site eller en spesifikk mappe som utelukkende er laget for Copilot Agent-ens kunnskapsbase. Det bidrar til å minimere problemer knyttet til oversharing og reduserer risikoen for at brukere utilsiktet laster opp sensitive eller irrelevante filer til agent-ens tilgjengelige repository. Bestemmer du deg for å bruke en eksisterende SharePoint-site, må du gjennomgå innholdet nøye og påse at ingen konfidensiell eller sensitiv informasjon ligger der som agent-en ikke skal finne.

Gi tilgang

Det er også viktig å påse at alle tiltenkte brukere har nødvendige leserettigheter til site eller mappe. Må du gi tilgang manuelt, sørg for at alle tiltenkte brukere har leserettigheter til siten (for eksempel ved å legge dem til i SharePoint-sitens Visitors-gruppe eller en passende Azure AD-sikkerhetsgruppe), for å forenkle prosessen og hindre utilsiktede tillatelsesfeil.

Forbered filer

Når du forbereder dokumenter for bruk med Copilot Agents, husk at AI-en per i dag ikke kan tolke innebygde bilder i filene. Legg derfor til beskrivende bildetekster eller alternativ tekst for å sikre at viktig visuell informasjon ikke går tapt. For tekstlige dokumenter, hold totalen på maksimalt 1,5 millioner ord eller 300 sider når du oppsummerer eller refererer til innhold, for at Copilot skal fungere effektivt.

For Excel-filer, organiser dataene slik at hver fil enten fokuserer på tall eller på tekst, siden tabeller med blandet innhold gir mindre presise resultater. Agents svarer også mest pålitelig på spørringer når de relevante dataene ligger på ett enkelt ark i arbeidsboken.

Agents responds best to Excel data when it’s contained in one sheet.

Eksempel: Har du en stor kundetilfredshetsundersøkelse lagret i én Excel-fil, del kvantitative data (som karakterer og numeriske svar) fra de kvalitative dataene (som fritekstsvar) inn i to ulike ark. Da kan du bruke verktøy som Python og Excel-formler for effektivt å analysere tallmaterialet (for eksempel beregne gjennomsnitt, sortere resultater, bestemme konfidensnivåer), samtidig som du bruker M365 Copilots sentimentanalyse for å hente innsikt ut av det tekstbaserte tilbakeføret.

Filbegrensninger

Til slutt, vær oppmerksom på filtypene og størrelsesbegrensningene som Copilot Agents og Copilot Studio støtter. Tabellen nedenfor skisserer gjeldende støtte: https://learn.microsoft.com/en-us/microsoft-365-copilot/extensibility/copilot-studio-agent-builder-knowledge#file-size-limits

Ta også hensyn til beste praksis Microsoft har delt om dokumentlengder: 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 per i dag ikke støttes i SharePoint Online: offisielt er alt annet som ikke er listet der, ikke offisielt støttet.

Enkelte filtyper, som CSV-filer, kan fungere tilfredsstillende selv om de ikke er offisielt støttet, siden de ligger nært opp til vanlige tekstformater. De fleste andre filtyper, særlig containerfiler som CAB, EXE og ZIP, samt bilde-, video- og lydformater som PNG, IMG, MP3 og MP4, er imidlertid ikke støttet på dette tidspunktet.

Oppsummering

Ved å følge disse anbefalingene sikrer du at Copilot Agents har tilgang til godt strukturerte, sikre data av høy kvalitet, slik at du får maksimal nytte og minimerer risikoen for utilsiktet dataeksponering. Å investere tid i å forberede SharePoint-miljøet legger et solid grunnlag for vellykket utrulling og adopsjon av AI-agenter i organisasjonen din.

Faktisk starter mange av «Build-an-Agent»-prosjektene våre nettopp der. Ikke med å bygge agent-en, men med å forberede infrastruktur og kunnskap slik at vi har data av god kvalitet å bruke med AI, for agent-en er bare så god som systemet under den.