Microsoft Copilot Cowork beheren: van rechten en connectors naar gecontroleerde vrijgave

Je hebt Cowork toegang gegeven tot een groep gebruikers. Een medewerker laat het vervolgens een document lezen, een Teams-bericht voorbereiden en een gedeeld bestand aanpassen. Als je die drie handelingen onder dezelfde toestemming laat vallen, weet je achteraf wel dát er iets gebeurde, maar niet of de juiste persoon de juiste mutatie heeft vrijgegeven.

Een governanceflow voor Copilot Cowork koppelt daarom acht controlepunten aan elkaar: toegang, connector, actie, risicoklasse, bewijs, eigenaar, uitzonderingsqueue en menselijke vrijgave. De AI mag snel werken. De grens wordt bepaald door de combinatie van gebruikersrechten, connectorbereik, een expliciete actieklasse en een controleerbaar vrijgavemoment.

Op 1 oktober 2026 is Cowork algemeen beschikbaar. Ik heb de GA-toegangssemantiek die ochtend opnieuw gecontroleerd in Microsofts actuele uitleg over Cowork-toegang: een gebruiker heeft toegang zodra minstens één spending policy de gebruiker omvat en Cowork selecteert. Een lage creditlimiet, de discoverability-instelling of de modelkeuze blokkeert toegang niet; de oude preview-instelling onder Agents > All Agents heeft bij GA geen effect meer op toegang. De access-pagina is bijgewerkt op 8 september 2026 en de beheerdocumentatie op 14 september 2026. Deze gids is voor de IT-beheerder, proceseigenaar of ondernemer die een pilot wil openen zonder dat een goedbedoelde prompt meteen een ongecontroleerde mutatie wordt.

Wat je nodig hebt voordat je Cowork openzet

Begin niet in de chat. Begin met de grens. Je hebt de volgende zaken nodig:

• Een Microsoft 365-tenant met Copilot-licenties voor de gebruikers in de pilot. Cowork en de plugins die je inzet vallen onder de Microsoft 365-beheerlaag.
• Afzonderlijke beheerrollen. Een Global administrator of Billing administrator is nodig voor de billingmethode. Een AI administrator of License administrator beheert policies, limieten en meldingen. Geef finance of security bij voorkeur een reader-rol voor inzage. Microsoft adviseert zelf de rol met de minste rechten te gebruiken.
• Een Microsoft Entra ID-securitygroep, bijvoorbeeld SG-Cowork-Pilot-Inkoop. Gebruik die groep als allowlist. Voeg geen hele tenant toe omdat het testen dan sneller lijkt.
• Een actuele connectorinventaris. Noteer per plugin of connector de naam, eigenaar, authenticatiemethode, doelgroep, datastroom en toegestane bewerkingen. Maak onderscheid tussen het pluginpakket, de connectorverbinding, het externe account en het agent- of toolonderdeel. Die vier zijn niet hetzelfde.
• Een actieregister. Leg per actie vast of Cowork mag lezen, een concept mag maken, iets mag wijzigen of een externe boodschap mag versturen. Zet er ook de risicoklasse, eigenaar, goedkeurder, bewijs en terugdraaipad naast.
• Een veilige proefset. Gebruik een afgeschermde SharePoint-map met tien tot twintig representatieve documenten. Neem minstens één ontbrekende waarde, één gevoelig document en één geval met een uitzondering op.
• Microsoft Purview Audit. Spreek vooraf af wie de auditrecords controleert, welke periode je bewaart en welk bewijs bij een vrijgave hoort.
• Een uitzonderingsqueue. Dat kan een Microsoft List in een beperkte SharePoint-site zijn. Zonder queue verdwijnen afgewezen acties in een chatgeschiedenis waar niemand eigenaar van is.

De actuele Cost Management-documentatie is bijgewerkt op 30 september 2026 en gecontroleerd op 1 oktober 2026. Schermnamen en beschikbaarheid kunnen nog verschuiven, maar de beslislogica blijft hetzelfde: je maakt toegang, actiebevoegdheid en vrijgave afzonderlijk toetsbaar.

Zo bouw je één testbare governanceflow

De route is steeds dezelfde: een gebruiker moet eerst binnen de allowlist vallen, daarna moet de connector precies het benodigde bereik hebben, vervolgens krijgt de actie een risicoklasse. Pas dan bepaal je of Cowork zelf mag uitvoeren, een mens moet laten goedkeuren of de actie naar de uitzonderingsqueue gaat.

1. Maak de pilotgroep en wijs eigenaars toe

Maak in Microsoft Entra ID één securitygroep voor de eerste gebruikers. Zet daarin bijvoorbeeld vier medewerkers, één proceseigenaar en één beheerder. De proceseigenaar bepaalt wat een correcte uitkomst is. De beheerder controleert instellingen. De goedkeurder mag niet automatisch dezelfde persoon zijn als degene die de actie heeft aangevraagd.

Schrijf de groepsnaam en de eigenaar op in het actieregister. Doe dat vóór je Cowork activeert. Een groep zonder eigenaar is geen governance, maar een vergeten allowlist.

2. Gebruik de spending policy als toegangspoort

Ga in het Microsoft 365 admin center naar Copilot > Cost Management. Kies Get Started en maak de default spending policy aan met een billingmethode. Selecteer bij Select agents and services expliciet Cowork. Kies bij het maandbudget Limit monthly spending, stel een limiet per gebruiker in en voeg meldingen toe voor de beheerder.

Voor een pilot zet je Auto-apply new services uit. De instelling staat standaard aan. Als je hem laat aanstaan, kunnen nieuw ondersteunde Copilot-diensten later automatisch onder dezelfde policy vallen. Dat is handig voor brede uitrol, maar ongeschikt voor een gecontroleerde proef.

De belangrijkste nuance: een spending policy is óók een toegangscontrole. Een policy met één credit limiet geeft de gebruiker nog steeds toegang tot Cowork totdat die limiet is bereikt. Wil je iemand uitsluiten, voeg die persoon dan niet toe aan een Cowork-selecterende policy. Een budgetplafond is dus een stopregel voor verbruik, geen vervanging van een allowlist.

Als de policy de limiet bereikt, verliezen gescopete gebruikers de toegang tot de diensten voor de rest van de maand. Gebruik die grens als noodrem en als signaal om het gebruik te beoordelen. De aparte gids over Copilot Credits en budgetplafonds behandelt de begroting; hier is het creditplafond alleen één schakel in je governanceketen.

3. Beperk plugins en connectors tot wat de taak nodig heeft

Open in het Microsoft 365 admin center Agents > All agents of Agents > Tools. Zoek de plugin, open de details en kies bij Installed for voor Specific users/groups. Gebruik dezelfde Entra-securitygroep als in stap 1. Publiceer een plugin niet organisatiebreed om een pilot te versnellen.

Een Cowork-plugin kan skills en connectors bevatten. Een pluginpakket beschikbaar maken betekent nog niet dat elk extern account is ingetrokken of dat elke verbinding dezelfde rechten heeft. Microsoft beschrijft die grens in de documentatie over pluginbeheer, authenticatie en Purview-monitoring, bijgewerkt op 1 september 2026. Elke gebruiker doorloopt de eigen sign-in- of consentstap. Je kunt niet namens iedereen inloggen.

Maak voor iedere connector een klein contract:

• Bron: welke SharePoint-site, mailbox, Teams-kanaal of externe dienst mag worden benaderd?
• Identiteit: draait de verbinding in de context van de gebruiker of via een service-account?
• Bewerking: is het alleen lezen, concepten maken, wijzigen, publiceren of verwijderen?
• Grenzen: welke mappen, records, ontvangers of kanalen vallen buiten scope?
• Eigenaar: wie controleert toegang en wie kan consent intrekken?
• Stop: hoe schakel je de verbinding uit, trek je credentials in en draai je een mutatie terug?

De scheiding tussen connectorpakket en connectorverbinding is niet theoretisch. De Microsoft-governancekaart benoemt voor connectorverbindingen aparte controles voor authenticatie, gebruikers, inhoud, schema, synchronisatie en operationele gezondheid, bijgewerkt op 30 september 2026. Controleer ze dus allebei.

Een concreet voorbeeld van bronbeheersing: Fabric IQ gebruikt vertrouwde Power BI-modellen en rapporten als bedrijfscontext in Copilot Chat en Cowork. Dat maakt de eigenaar van het semantische model onderdeel van je review. Wie de bron beheert, bepaalt indirect welke definities en cijfers de agent kan gebruiken.

4. Geef elke actie een risicoklasse

Maak het actieregister uitvoerbaar met vier klassen:

1. Lezen: zoeken, samenvatten of vergelijken zonder wijziging. Dit kan meestal zonder aparte vrijgave, mits de bronrechten kloppen.
2. Concept: een Word-document, Excel-uitkomst, e-mail of Teams-bericht voorbereiden. De gebruiker controleert de inhoud vóór gebruik.
3. Wijzigen: een gedeeld bestand aanpassen, een record bijwerken of een interne status veranderen. Laat de eigenaar de mutatie goedkeuren.
4. Extern of onomkeerbaar: versturen naar een klant, publiceren, verwijderen, een financiële handeling of een wijziging met juridische of operationele gevolgen. Gebruik een gescheiden goedkeurder en een queue. Laat Cowork niet op basis van alleen de prompt uitvoeren.

Dit is geen juridische kwalificatie van Cowork. Het is een praktisch ontwerpprincipe. Artikel 14 van de AI Act beschrijft voor hoog-risicosystemen dezelfde richting: menselijk toezicht moet proportioneel zijn, de werking kunnen interpreteren en de mogelijkheid houden om een systeem te onderbreken of te overrulen. Het Europese AI Act Service Desk werkt de officiële tekst van 13 juni 2024 uit; de pagina is gecontroleerd op 1 oktober 2026, maar controleer voor jouw toepassing altijd de actuele juridische kwalificatie.

Cowork heeft zelf een actiegoedkeuringssysteem. Bij gevoelige handelingen, zoals e-mail versturen, Teams-berichten plaatsen of bestanden wijzigen, toont het een preview. De opties Approve once, Always allow en Cancel hebben verschillende gevolgen. Microsoft vermeldt dat een keuze om niet opnieuw te vragen alleen voor de huidige conversatie geldt en via het Permissions-paneel kan worden ingetrokken. De gebruikspagina is gecontroleerd op 1 oktober 2026. Laat Always allow in de pilot uit voor klasse 3 en 4. Bekijk ook de technische parameters voordat je goedkeurt.

Microsoft beschrijft daarnaast een permission boundary: Cowork werkt binnen de bestaande Microsoft 365-rechten van de gebruiker en kan die niet zelf verhogen. De application card noemt voor medium- en high-risk acties ook een zichtbaar risiconiveau in de goedkeuringsprompt. Die kaart is gecontroleerd op 1 oktober 2026. Dat helpt de beoordelaar, maar vervangt je eigen actieklasse en functiescheiding niet.

Voor klasse 3 en 4 is een tweede, technische grens nodig. Een Microsoft List is alleen een registratie- en werkqueue, geen autorisatiebarrière. Als Cowork of de aanvrager nog een directe schrijfconnector naar het doel heeft, kan die route de lijst omzeilen. Blokkeer directe uitvoering daarom zo:

1. Geef de pilotgroep in Cowork alleen lees- en conceptrechten. Verwijder of blokkeer de schrijfconnector voor leveranciersrecords, publiceren, verwijderen en externe berichten.
2. Geef in het doelsysteem geen schrijfpermissie aan de pilotgroep. Alleen de vrijgaveflow krijgt de minimale write-scope. Een downstream-API of SharePoint-site controleert die identiteit opnieuw.
3. Laat Cowork uitsluitend een queue-item indienen. Genereer daarbij server-side een unieke request_id en bewaar de voorgestelde payload of bestandsversie. De proceseigenaar keurt het item goed.
4. Laat daarna alleen Cowork-release-executor de mutatie uitvoeren. De flow controleert opnieuw status, goedkeurder, payload-hash en scope. De aanvrager is dus niet de uitvoerende identiteit.

Voor een bedrijfskritische flow gebruik je een dedicated Microsoft Entra service principal als Power Automate application user, bijvoorbeeld spn-cowork-release-prod, met alleen de benodigde downstream-rechten. Microsofts guidance over service-principal-eigenaarschap, bijgewerkt op 14 augustus 2026, beschrijft dat zo'n niet-menselijke identiteit kritieke flows stabiel kan laten draaien. Leg approved_by en executor_identity apart vast. Zo is de vrijgave een eigen record en niet alleen een klik in dezelfde sessie.

5. Leg bewijs vast dat iemand anders kan narekenen

Gebruik Microsoft Purview en zoek onder Audit naar Copilot-activiteiten. Filter op de relevante periode en controleer minstens de gebruiker, tijdstip, plugin of agent, actie, bron, status en doelobject. De auditrecords kunnen onder meer AgentId, AgentName, AgentVersion, AISystemPlugin, AccessedResources, Action, Status en beleidsdetails bevatten.

De actuele Purview-documentatie voor Copilot-auditlogs is bijgewerkt op 26 augustus 2026. Daarin staat ook dat Microsoft-applicaties, waaronder Cowork, onder Audit Standard vallen. Voor niet-Microsoft AI-applicaties kan een andere, gebruiksafhankelijke auditlaag gelden. Trek die twee situaties niet gelijk.

Bewaar naast het auditrecord een korte vrijgavereferentie in je queue, bijvoorbeeld REL-2026-041. Noteer de request_id, approved_by, approved_at, de hash of bestandsversie, executor_identity, execution_id, uiteindelijke status en het resultaat van het doelsysteem. Een logregel zegt dat een actie plaatsvond. De combinatie van auditrecord, goedkeuringsrecord en downstream-resultaat laat zien waarom die actie mocht plaatsvinden en onder welke identiteit ze is uitgevoerd.

6. Richt de uitzonderingsqueue in

Maak een Microsoft List met deze kolommen:

Laat een item naar deze queue gaan wanneer een bron gevoelig is, de actie klasse 3 of 4 heeft, de eigenaar ontbreekt, de connector onverwachte rechten heeft of een creditlimiet wordt geraakt. Kies één eigenaar per item. Een gedeeld kanaal zonder verantwoordelijke is geen uitzonderingsproces. De List is hierbij niet de beveiligingsgrens: de pilotgroep mag het doel niet rechtstreeks wijzigen en de flow moet de goedkeuring opnieuw afdwingen.

Maak vervolgens de uitvoerflow concreet:

• Trigger Cowork-release-executor op When an item is created or modified voor deze List. Zet in Settings > Trigger conditions de triggerconditie @equals(triggerBody()?['status'], 'Goedgekeurd') als status een tekstkolom is met exact die interne naam. Gebruik bij een SharePoint-keuzekolom de door de designer getoonde waarde, meestal @equals(triggerBody()?['status']?['Value'], 'Goedgekeurd'). Microsoft beschrijft dat een triggerconditie de flow niet start als de expressie niet waar is, in plaats van pas later een run te laten overslaan in een gewone condition.
• Laat de flow vóór de write opnieuw Get item uitvoeren en controleer status, approved_by, approved_at, payload_hash, toegestane actieklasse en doelgroep. Controleer ook dat approved_by niet gelijk is aan requested_by.
• Gebruik request_id als idempotency-key. Zet de kolom op unieke waarden of registreer de sleutel in een aparte Dataverse-tabel of downstream-endpoint met een unieke sleutel. De flow probeert vóór de mutatie één request_id als In uitvoering te claimen. Een duplicate-conflict stopt de run met Duplicate request_id, zonder tweede write. Zet daarnaast trigger concurrency op één, maar vertrouw daar niet alleen op.
• Voer de write uit met de vaste connection reference van spn-cowork-release-prod, niet met de verbinding van de inkoper of goedkeurder. Schrijf daarna execution_id, executor_identity en Uitgevoerd terug naar de queue. Het doel-systeem moet dezelfde request_id als idempotency-key accepteren of de claim zelf afdwingen. Microsofts actuele Power Automate-documentatie, bijgewerkt op 4 september 2025, beschrijft triggercondities; de troubleshooting-documentatie, bijgewerkt op 7 augustus 2026, waarschuwt bovendien dat flows minstens één keer kunnen worden afgeleverd en daarom idempotent moeten zijn.

7. Test de hele keten vóór je uitrolt

Test niet alleen of Cowork een goed antwoord geeft. Test of het systeem op het juiste moment stopt. Voer minstens deze scenario’s uit:

• Een gebruiker buiten de securitygroep probeert Cowork te openen.
• Een gebruiker binnen de groep leest een toegestaan document.
• Dezelfde gebruiker probeert een document buiten de toegestane map te gebruiken.
• Cowork maakt een conceptbericht, maar verstuurt niets zonder goedkeuring.
• Een gebruiker probeert een gedeeld bestand te wijzigen zonder eigenaar.
• Een klasse 4-actie komt in de uitzonderingsqueue terecht.
• Een connector wordt geblokkeerd en bestaande consent en credentials worden ingetrokken.
• De policy nadert de limiet en de afgesproken beheerder krijgt een melding.

Definieer vóór de pilot een periode van veertien aaneengesloten kalenderdagen. In dit voorbeeld loopt die van 5 tot en met 18 oktober 2026; bij een andere startdatum verschuif je het venster, maar niet de definities. Tel alle uitvoeringen met een mutatietijdstip binnen het venster mee, ook wanneer de aanvraag eerder is aangemaakt.

Een ongeautoriseerde mutatie is elke geslaagde write, update, delete, publicatie of externe verzending waarvoor op het moment van uitvoering geen passend queue-item bestaat met status = Goedgekeurd, een goedkeuring vóór executed_at, een goedgekeurde payload-hash en de toegestane executor_identity. Ook een tweede geslaagde uitvoering met dezelfde request_id, een wijziging buiten de goedgekeurde scope of een mutatie door een directe gebruikersconnector telt als ongeautoriseerd. Lezen, een concept zonder publicatie en een geweigerde aanvraag zijn geen mutatie, maar moeten wel als poging of resultaat worden geregistreerd.

Gebruik vier meetgetallen:

• Ongeautoriseerde-mutatiegraad: ongeautoriseerde mutaties / alle geslaagde mutaties. Doel: 0 / n = 0%.
• Goedkeuringsdekking: het aantal klasse 3- en 4-aanvragen met vóór de uitvoering een beslissing Goedgekeurd of Afgewezen, gedeeld door alle klasse 3- en 4-aanvragen. Doel: 100%, dus ook afgewezen acties hebben bewijs.
• Pre-approvaldekking: uitgevoerde klasse 3- en 4-mutaties met een geldige goedkeuring vóór uitvoering, gedeeld door alle uitgevoerde klasse 3- en 4-mutaties. Doel: 100%.
• Auditdekking: mutaties met een matchende Purview-gebeurtenis én downstream execution_id en request_id, gedeeld door alle mutaties. Doel: 100%.

Een pilot is pas klaar voor uitbreiding als alle vier de uitkomsten de norm halen, de teller en noemer groter dan nul zijn, en de testset minstens één afwijzing, één dubbele aflevering, één directe bypass-poging en één scope-overtreding bevat. Bij elke afwijking zet je de flow uit, bewaar je het bewijs en herhaal je de volledige periode na herstel. “Het leek goed te gaan” is geen releasecriterium.

Valkuilen die je pilot onveilig maken

• Je gebruikt de oude preview-schakelaar. Sinds de algemene beschikbaarheid bepaalt de Cowork-vermelding onder Agents > All Agents niet meer wie toegang heeft. Controleer de spending policy. Gebruikers buiten elke Cowork-selecterende policy horen geen toegang te hebben.
• Je zet de limiet laag en denkt dat toegang daarmee uitstaat. Dat klopt niet. Een gebruiker met één credit limiet kan Cowork nog openen. Verwijder de gebruiker uit de policy als je toegang wilt voorkomen.
• Je verwart plugininstallatie met connectorrechten. Een plugin blokkeren maakt niet automatisch externe OAuth-consent, credentials of accounts onbruikbaar. Trek die apart in.
• Je geeft een generiek service-account brede rechten. OWASP noemt overmatige functionaliteit, rechten en autonomie de drie wortels van Excessive Agency. De OWASP-mitigaties zijn concreet: beperk tools, functies en downstream-rechten en laat high-impact acties door een mens goedkeuren. Maak liever één kleine connectoractie dan een open API met brede bevoegdheden.
• Je behandelt de Microsoft List als autorisatiebarrière. De lijst bewaart een verzoek, maar een directe schrijfconnector kan hem omzeilen. Verwijder schrijfpermissies uit Cowork en uit de pilotgroep, laat alleen de vrijgaveflow met spn-cowork-release-prod het doel wijzigen en laat het doelsysteem de identiteit, scope en request_id opnieuw controleren.
• Je vertrouwt op de prompt als beveiliging. Een zin als “stuur alleen naar leveranciers met een goedgekeurd contract” is geen autorisatie. Controleer ontvanger, recordstatus en budget in het systeem dat de mutatie uitvoert.
• Je klikt op “Always allow” om de pilot vlotter te maken. Daarmee haal je juist het zichtbare vrijgavemoment weg. Gebruik die optie alleen voor laag-risico acties in een beperkte testconversatie.
• Je behandelt een auditlog als goedkeuring. Een auditrecord toont wat er gebeurde, niet waarom het mocht. Koppel de log aan een request_id, een eigenaar en een expliciete status in de queue.
• Je vergeet geplande en gebeurtenisgestuurde taken. De actuele Cowork-FAQ van Microsoft, gecontroleerd op 1 oktober 2026 en ongedateerd weergegeven, bevestigt dat Cowork geplande prompts en gebeurtenistaken voor binnenkomende e-mail of Teams-berichten ondersteunt. De actuele beheerdocumentatie is bijgewerkt op 14 september 2026 en vermeldt dat zulke taken met de rechten van de maker draaien en standaard goedkeuring vragen vóór gevoelige acties. Wijs daarom een eigenaar en plaatsvervanger toe, test de trigger en pauzeer de taak bij vertrek van de eigenaar.
• Je laat nieuwe diensten automatisch binnenkomen. Voor een pilot zet je Auto-apply new services uit. Review elke nieuwe dienst eerst op data, actie en kosten.
• Je maakt één menselijke vrijgave voor alles. Dan wordt de goedkeurder een drukknop. Geef de persoon een preview, bron en mutatieparameter. Voor hoge impact is een tweede controle of een downstream-regel nodig.

Beslis-kader: kant-en-klaar of maatwerk?

De juiste keuze hangt minder af van het aantal gebruikers dan van de actie die je wilt toestaan. Beantwoord vijf vragen:

1. Moet Cowork alleen lezen, of ook schrijven? Alleen lezen en samenvatten past bij een beheerde plugin met een kleine groep. Schrijven vraagt om een actiecontract en een eigenaar.
2. Blijft alles binnen Microsoft 365? SharePoint, OneDrive, Outlook en Teams zijn eenvoudiger te begrenzen dan een externe dienst met eigen rollen, tokens en auditlog.
3. Is de actie omkeerbaar? Een conceptdocument kun je terugzetten. Een extern bericht, verwijderactie of financiële mutatie vraagt om een expliciete vrijgave en terugdraaipad.
4. Moet de goedkeurder iemand anders zijn dan de aanvrager? Als dat verplicht is, is de native Cowork-prompt alleen onvoldoende. Voeg een Microsoft Lists-queue en Power Automate-goedkeuring toe, of bouw een aparte vrijgavepoort.
5. Moet je een eigen API, MCP-server of idempotente mutatielaag koppelen? Dan is maatwerk logisch. Laat de downstream-service opnieuw autoriseren, valideer parameters en schrijf een eigen release-id naar de mutatie.

Voor de meeste kleine pilots is kant-en-klaar de beste start: een Microsoft 365-plugin, één Entra-groep, alleen lezen en concepten, met native action approval. Zodra je meerdere systemen, gescheiden goedkeuring of bedrijfsspecifieke regels nodig hebt, kies je een hybride route. Maatwerk is pas nodig als de businessregel niet betrouwbaar in Microsoft 365 of de connector zelf af te dwingen is.

Gebruik usage-based billing als stopregel, niet als risicomodel. Een limiet beschermt je verbruik. Hij zegt niets over de juistheid van een e-mail, de bevoegdheid van een ontvanger of de legaliteit van een wijziging. De grens hoort dus in twee systemen te bestaan: de spending policy bewaakt gebruik, de connector of downstream-app bewaakt autorisatie.

De keuzehulp geeft dezelfde uitkomsten als het geschreven kader. Lezen of concepten binnen Microsoft 365 kun je klein en kant-en-klaar starten. Schrijven over meerdere systemen vraagt om een hybride route. Externe of onomkeerbare acties horen achter een vrijgavepoort, ook als Cowork zelf al een bevestigingsvenster toont.

Uitgewerkt voorbeeld: een inkoopteam met gecontroleerde vrijgave

Neem een fictieve groothandel met twaalf inkopers. Het team wil Cowork gebruiken om leveranciersoffertes uit SharePoint te vergelijken, een samenvatting in Word te maken en een voorstel in Teams te plaatsen. Het mag geen leveranciersrecord aanpassen of bericht naar een leverancier sturen zonder aparte toestemming.

De inrichting

De beheerder maakt SG-Cowork-Inkoop-Pilot met vier inkopers en de proceseigenaar. De pilot-policy krijgt de naam Cowork Inkoop Pilot, selecteert Cowork, heeft als voorbeeldlimiet 10.000 credits per maand, een gebruikerslimiet van 1.500 credits en een melding bij 70 procent. Dit zijn testwaarden voor deze casus, geen Microsoft-advies. Auto-apply new services staat uit.

De plugin is alleen beschikbaar voor de securitygroep. SharePoint levert leesrechten op de map Inkoop/Leveranciers/Offertes/2026. Outlook en Teams blijven beschikbaar voor concepten en voorgestelde interne communicatie. De gebruikers authenticeren zelf. De pilotgroep heeft geen directe schrijfverbinding naar het leveranciersregister of naar een externe verzendconnector.

In de Microsoft List Cowork-vrijgavequeue staan alleen de proceseigenaar en de plaatsvervanger als bewerkers. De inkopers mogen een item indienen en de status lezen. De List is de registratie, niet de autorisatiebarrière: het leveranciersregister accepteert writes alleen via Cowork-release-executor, waarvan de vaste verbinding onder spn-cowork-release-prod draait. De flow gebruikt als triggerconditie @equals(triggerBody()?['status'], 'Goedgekeurd'), valideert opnieuw de goedgekeurde payload en claimt request_id vóór de write. Een duplicate-conflict stopt de run. De flow voert dus geen leveranciersactie uit zonder status Goedgekeurd, een geldige functiescheiding en een nog niet gebruikte request_id.

De actieklassen

De proceseigenaar legt vier regels vast:

• Een offerte lezen en bedragen uit een bron halen is klasse 1. Cowork mag dit doen. Het antwoord moet bestandsnamen en versies noemen.
• Een Word-samenvatting maken is klasse 2. De inkoper controleert de output. De samenvatting wordt een nieuw document, geen wijziging in het brondossier.
• Een Teams-bericht met het voorstel plaatsen is klasse 3. Cowork mag het bericht voorbereiden. De eigenaar controleert ontvangers en inhoud in de preview.
• Een leveranciersrecord of een extern bericht wijzigen is klasse 4. Dat gaat naar de queue. Zonder vrijgave stopt de keten.

Eén proefactie

De testgebruiker vraagt: “Vergelijk offerte-2026-041.pdf met de voorwaarden in Inkoopbeleid-2026.docx, maak een Word-samenvatting en zet een concept voor het inkoopkanaal klaar.” Cowork leest twee toegestane SharePoint-bestanden, noemt de bronnen en maakt het concept. In het document staat dat de leverancier een betalingstermijn van 75 dagen voorstelt, terwijl het beleid 60 dagen als grens gebruikt.

De uitkomst wordt daardoor geen automatisch “akkoord”. Cowork markeert de afwijking, zet risicoklasse = Wijzigen, vult de eigenaar in en maakt server-side REL-2026-041 in de queue. De proceseigenaar bekijkt de twee bronbestanden, het voorgestelde Teams-bericht en de afwijking. Bij afwijzing blijft het leveranciersrecord onaangeraakt. Bij goedkeuring controleert Cowork-release-executor nogmaals de status en payload-hash en voert spn-cowork-release-prod hooguit de toegestane interne statuswijziging uit. Een extern bericht blijft een nieuwe klasse 4-actie.

In de veertiendaagse pilot van 5 tot en met 18 oktober zijn er 20 aanvragen: 8 leesacties, 4 concepten, 5 klasse 3-acties en 3 klasse 4-acties. Zeven hoog-risicoacties worden goedgekeurd en uitgevoerd; één klasse 4-aanvraag wordt afgewezen en veroorzaakt geen write. De beheerder vindt 7 geslaagde mutaties, 0 ongeautoriseerde mutaties, 7 van 7 mutaties met een Purview-record en downstream execution_id, en 8 van 8 klasse 3- en 4-aanvragen met een geregistreerde beslissing. Daarmee zijn de ongeautoriseerde-mutatiegraad 0%, de auditdekking 100% en de goedkeuringsdekking 100%. De controle omvat ook een herhaalde aflevering van REL-2026-041: de unieke claim op request_id laat de tweede run stoppen zonder dubbele uitvoering. De Consumption-weergave laat zien welke gebruiker, service en policy credits verbruikten. Het team verhoogt de limiet pas na die review, niet omdat de eerste test prettig verliep.

Dit voorbeeld laat ook zien wat je níét automatiseert. De AI mag bronmateriaal verzamelen en een voorstel structureren. De bevoegdheid om een zakelijke uitzondering te accepteren blijft bij de proceseigenaar. Die scheiding is de waarde van de flow.

Vergelijkingstabel: welke aanpak past bij jouw risico?

Kies de kleinste aanpak die je risicoklasse werkelijk afdwingt. Een kant-en-klare plugin is geen probleem zolang de connector alleen leest of een concept maakt. Maatwerk is geen veiligheidsbewijs zolang de downstream-API geen eigen autorisatie controleert. In beide gevallen blijft de test hetzelfde: kan je achteraf aantonen wie toegang had, welke bron is gebruikt, wat Cowork wilde doen, wie vrijgaf en welke mutatie uiteindelijk plaatsvond?

Een bruikbare Cowork-governanceflow is geen dikke beleidsmap naast het product. Het is een korte keten die bij elke actie hetzelfde antwoord geeft: deze gebruiker had toegang, deze connector mocht dit bereik zien, deze actie had deze risicoklasse, dit bewijs lag klaar, deze eigenaar gaf vrij, en deze mutatie is terug te vinden. Als één schakel ontbreekt, laat je de actie wachten. Dat is geen rem op AI, maar de voorwaarde om haar werk uit handen te geven zonder je eigen verantwoordelijkheid kwijt te raken.