Je kent intussen de grounding van Copilot (4.1). Je bouwde een agent (4.2), gaf je werk een vaste plek in Copilot Notebooks (4.3) en zette twee specialistische agents aan het werk (4.4). Al dat werk draait op inhoud waar Copilot al een weg naartoe heeft: je mail, je bestanden, je chats en alles wat via Microsoft Graph geïndexeerd is. Maar wat met inhoud van helemaal buiten Microsoft 365? Daarvoor dient een connector. Die voegt nieuwe inhoud toe aan die pool.
Wat is een Copilot-connector?
Een connector haalt inhoud uit een extern systeem binnen in Microsoft Graph. Denk aan ServiceNow, Salesforce, Box, Jira, MediaWiki of Azure. In de Connectors gallery staan er nog ruim honderd andere. Eens die inhoud in Graph zit, kan je ze doorzoeken zoals je eigen bestanden. Via Microsoft Search, via gewone Copilot Chat, en via de agents en tools die bovenop Graph gebouwd zijn. Researcher en Analyst uit de vorige les horen daarbij. En bouw je een agent in Agent Builder, dan kan je die inhoud aanvinken als kennisbron.
Wat levert dat concreet op? Stel, je vraagt Copilot: "wat is de status van de Henderson-supportcase?" Zolang er geen connector is voor je ticketingsysteem, krijg je niets. Copilot kan gewoon niet aan die data. Rolt je beheerder er wel een connector voor uit, dan haalt dezelfde vraag het ticket meteen boven. De inhoud zit nu in dezelfde pool die Copilot al doorzoekt voor je mail en bestanden.
Waar verbonden inhoud opduikt
Niet alleen in het chatvenster. Eens een connector live is en de inhoud geïndexeerd, kan die op vier plekken opduiken. In een gewone zoekopdracht in Microsoft Search. In een antwoord van gewone Copilot Chat. In de scope van Researcher, als je het in "werkinhoud" laat zoeken. En in de lijst met kennisbronnen die je kan aanvinken als je een agent bouwt in Agent Builder. Wil je bijvoorbeeld een agent die vragen beantwoordt over je bedrijfswiki? Dan moet een connector die wiki eerst in Graph binnenbrengen. Agent Builder kan niet bij een systeem waar Graph nog nooit van gehoord heeft.
Wie zet er eentje op?
Hier zit een fundamenteel verschil, en dat wil je scherp hebben. Het verandert hoe je kijkt naar elke connector die je ooit in Copilot ziet opduiken. Bij Claude koppel je zelf een app, op het moment dat je hem nodig hebt. Je opent de Connectors Directory, kiest een app, klikt op Connect, logt in, en in je volgende chat werkt hij al.
Een Copilot-connector werkt anders. Om er eentje op te zetten, heb je de rol AI-beheerder nodig in het Microsoft 365-beheercentrum. Daar ga je naar Copilot en dan naar Connectors. Je kiest een bron uit de Gallery, geeft ze een naam en een URL, kiest een authenticatiemethode en maakt ze aan. Als gewone gebruiker kan je dus geen directory doorbladeren en zomaar een app toevoegen. Er bestaat wel een nieuwere tussenvorm. Bij sommige connectors (self-serve sync connectors en federated connectors) zet de beheerder de connector één keer aan. Daarna log je zelf in met je eigen account om hem te gebruiken. Maar ook dan kan je alleen verbinden wat je beheerders goedkeurden. Welke externe systemen Copilot kan bereiken, beslist je organisatie. Niet jij.
Is dat dan gewoon een beperking? Niet helemaal, het is een afweging. Een connector die je zelf in Claude opzet, raakt alleen je eigen chats. Een connector die een beheerder in Copilot uitrolt, is een beslissing voor de hele tenant. Eens hij live is, kan iedereen die de beheerder toegang gaf hem gebruiken. Daarom moet iemand met het mandaat voor de hele organisatie die knoop doorhakken. Niet één persoon die voor zichzelf een schakelaar omzet.
Wie ziet wat, eens het verbonden is?
Dit is de tweede grote beslissing van de beheerder, en zeker geen detail. Per connector kiest die tussen twee toegangsmodellen. Het eerste is "enkel gebruikers met toegang tot de inhoud". Copilot koppelt je dan via je e-mailadres aan je identiteit in Microsoft Entra ID. Geïndexeerde inhoud krijg je alleen te zien als je ze in het bronsysteem al kon zien. Het tweede is "iedereen in de organisatie". Dan is de geïndexeerde inhoud zichtbaar voor de hele tenant, los van wie ze bij de bron kon openen.
De eerste optie werkt zoals Claude-connectors altijd werken: je ziet nooit meer dan je al kon zien. Voor de tweede heeft Claude eigenlijk geen tegenhanger. Kiest een beheerder die instelling, dan kan een connector de zichtbaarheid echt verbreden, verder dan de toegangslijst van het bronsysteem zelf. Precies daarom is het een bewuste keuze van de beheerder. Niemand rolt daar per ongeluk in.
Het addertje: rechten synchroniseren
Nog één praktisch detail, handig voor je aan een raar zoekresultaat begint te twijfelen. Een connector houdt zijn inhoud vers met incrementele crawls: kleine, frequente updates. Maar die werken de rechten niet bij. Verandert iemands toegang tot een bestand in het bronsysteem? Dan komt die wijziging pas in de index van Copilot bij een volledige crawl. En die draait periodiek, niet continu, en dus niet op het moment dat de toegang verandert. Duikt inhoud op bij iemand die ze niet zou mogen zien? Of ontbreekt ze net bij iemand die er wel aan zou moeten kunnen? Dan is een verouderde rechtensynchronisatie een echte, gedocumenteerde verklaring. Check dat eerst, voor je denkt dat er iets kapot is of het als beveiligingsincident escaleert.
Handelen, niet alleen lezen
Claude maakt een duidelijk onderscheid. Een connector die je data leest is één ding. Een connector die iets kan doen, zoals een bericht sturen, een ticket aanmaken of een bestand verwijderen, is iets anders. Met die tweede soort vraagt Claude je echt voorzichtig te zijn. Copilot-connectors dienden in het begin vooral om te zoeken en op te halen: inhoud binnenhalen zodat je ze kan vinden. Maar federated connectors, algemeen beschikbaar sinds september 2026, breiden dat uit naar schrijven, bijwerken en verwijderen. Dat is dezelfde stap van "iets opzoeken" naar "iets veranderen" die de connectors van Claude al zetten.
Hoe ziet dat verschil eruit in de praktijk? Een connector die alleen leest, laat Copilot antwoorden op "wat is de huidige status van het Henderson-ticket?" door het op te zoeken. Een connector die ook acties ondersteunt, kan iets doen met "sluit het Henderson-ticket en noteer dat de fix is uitgerold". Die voert de wijziging echt door in het bronsysteem. Zit de eerste ernaast, dan is er niets aan de hand. De tweede past een echt record aan waar collega's op rekenen. Daarom weegt de afweging hier even zwaar als bij Claude. Iets opzoeken is laag risico. Iets veranderen in het bronsysteem is dat niet. Kijk dus extra goed voor je dat toevertrouwt aan een agent die op eigen houtje draait.
Een connector krijgen die je echt wil
Je kan er zelf geen toevoegen. Wil je dat Copilot een systeem bereikt dat het nog niet dekt? Dan is de praktische zet: vragen. Zoek niet naar een instelling die niet bestaat. Vertel je IT- of beheerteam precies welk systeem je nodig hebt. Zeg wat je Copilot zou vragen, eens het verbonden is. En zeg of de inhoud zichtbaar moet zijn voor iedereen, of alleen voor wie al toegang heeft in het bronsysteem. Dat laatste weegt zwaarder dan het klinkt. Jij weet het best of "iedereen in de organisatie" de juiste keuze is voor dat systeem. Geef de beheerder die inschatting meteen mee. Dan moet hij niet gokken. Zo krijg je een connector die ingesteld is zoals jij hem nodig hebt.
Waar dit heen gaat
Daarmee is Deel 4 rond. Je kan de context beheren die Copilot automatisch voor je opbouwt (4.1). Je kan een herhaalbare taak verpakken in een agent die je kan delen (4.2). Je geeft werk waar je op terugkomt een vaste plek in Copilot Notebooks, niet in een chat die je toch ooit sluit (4.3). Je grijpt naar Researcher of Analyst als een vraag echte diepgang vraagt (4.4). En nu weet je hoe externe systemen erbij komen, en wie daarover beslist (4.5). Deel 5 gaat nog een stap verder: meer gespecialiseerde tools, planning en automatisering, en volledige draaiboeken die alles wat je leerde aan elkaar knopen.
Probeer het
Denk aan één extern systeem dat je elke dag gebruikt en dat niet bij Microsoft 365 hoort. Je ticketingtool, je CRM, een wiki. Stel dat Copilot het kon doorzoeken: wat is de eerste echte vraag die je zou stellen? Stel jezelf daarna de vraag die de beheerder moet beantwoorden. Moet iedereen in je organisatie die inhoud via Copilot kunnen vinden, of alleen wie ze al bij de bron kon openen? Dat is precies de beslissing die je IT-team neemt voor elke connector die het uitrolt.