
AI · 18 October 2026 ·

Translated with AI. This article was translated by an AI model from an article by Twentynext in another language, and the translation was checked automatically against the original. Verify figures and sources before acting on them. See our disclaimer.
The pressure to adopt Copilot can come from several directions. Microsoft and its partners offer adoption programmes, your board wants to know what the organisation “is doing with AI”, and you may not know whether employees are already using AI tools out of your sight. Anyone who says yes quickly in that situation is mainly buying an obligation. Anyone who says no risks losing grip on what may already be happening anyway.
This article sets three responses side by side: rolling out broadly, holding off, or starting in a controlled way. It describes which preconditions you need to have in place before a licence can deliver anything. Without figures about other people’s successes, because those say little about your organisation.
First, a demarcation. This article is about Microsoft 365 Copilot: the assistant in the office suite. Which licence you need for it exactly, and how it relates to your existing subscription, is something you check in Microsoft’s own current product terms: licensing models change, and a blog or framework is not a reliable source for that.
Microsoft has an interest in Microsoft 365 Copilot being used widely and itself offers information on increasing adoption, including an overview of adoption partners. IT service providers also offer adoption and change programmes, such as Cegeka. That is a legitimate offer, but the existence of an offer says nothing about whether your organisation is ready for it now.
In addition, there may be internal pressure: board members who do not want to lag behind peer organisations, or employees who work with a language model privately and expect the same at the office. How strongly that expectation lives in your organisation is something you only know once you ask.
Keep the two kinds of pressure apart. The external offer can be parked with a clear schedule. An internal expectation, if there is one, calls for an answer that you formulate yourself.
As a framework for thinking, we set three routes side by side. In your situation, hybrid forms are conceivable, but each route has a price that only becomes visible later.
| Response | What you gain | What you risk |
|---|---|---|
| Roll out broadly | Speed, a visible decision, one line for everyone | Chance that licences remain unused; information for which permissions are set too broadly can surface more easily; no basis for measuring results |
| Hold off or block | Time, deferral of licence costs, no new risk on paper | Possible shadow use of external AI tools with company data; possible loss of credibility among employees |
| Start in a controlled way | Learning on a limited scale, measurable effect, demonstrable care | Slower, requires ownership and discipline, can get bogged down in a perpetual pilot |
The first route is the obvious one under pressure: one decision and done. The risk lies in the question that follows: who here does something differently tomorrow? If that question remains unanswered, licences sit idle and you have no starting point for measuring anything.
The second route feels safe, but mainly so on paper. The risk, if the internal expectation is there, is that employees without an approved tool choose another one themselves. How big that risk is in your organisation depends on what you block technically and which agreements you make. If it happens outside your managed environment, it is harder to keep sight of which data leaves the organisation and to make agreements about it.
The third route is more laborious. It only works if someone in the line owns the pilot, has an end date and has the authority to say afterwards: this we stop, this we scale up. Microsoft itself advises in its onboarding guide for IT administrators to carry out a readiness assessment and prepare your data before roll-out, and to determine the next step only on the basis of that outcome.
How Microsoft 365 Copilot handles access rights and data processing is described by the supplier in its official product documentation. Read it, and have your information security officer read along. Check in particular how the assistant handles the permissions the user already has, which data sources are indexed and searched, and which security and search settings you manage yourself in that respect.
Microsoft points out in its own guide that you must prepare your data before roll-out, among other things with the features in your Microsoft 365 subscription and with SharePoint Advanced Management, and refers for that to setting up a secure and managed data foundation. That advice does not exist for nothing: the state of your permissions and information management determines what can surface in answers later.
Providers that work with Copilot implementations describe that risk more concretely. Epiq speaks of “overexposed data”, information that is accessible more broadly than intended, and advises tackling it in phases, starting with the files containing sensitive content. Hands on ICT puts it this way: Copilot works on the basis of the data, permissions, documents and processes that are already present within your Microsoft 365 environment.
Think of a folder that was once opened up for a project group and never closed again. Whether such a folder can come back in an answer depends on the permissions, the indexing and the settings you manage. That is precisely why you check beforehand who has access to what, and verify in the product documentation how your environment is configured.
How much work that clean-up is depends on how long your information management has grown organically. Plan it as a separate workstream with an owner and an end date, otherwise it gets pushed back.
Involve your privacy officer early. First determine, per processing operation, which role your organisation has under the AVG (the GDPR as it applies in the Netherlands), because that determines who is responsible for what. Then have it assessed whether a data protection impact assessment (DPIA) is required for the specific processing you have in mind; your privacy officer or data protection officer can advise on this on the basis of the current legal text and the supervisory authority’s guidelines. Base that assessment on what you will actually be processing yourself; supplier documentation is input for that, not a conclusion.
Also involve information security, IT management and the works council. Security and management want to know who manages settings, what is logged and who runs the service after delivery. Whether the works council has a role depends on what exactly you are introducing; have legal or HR check which provisions of the Wet op de ondernemingsraden (Works Councils Act) may apply, for example when you adopt a scheme concerning personnel data or a system that can record the use or behaviour of employees. Put that question on the table early, not afterwards.
Finally, make agreements about input and use. Which information may employees put in a prompt? What do they do with an answer that sounds convincing but is wrong? The AI Act (Article 4) also requires measures that support the AI literacy of the people who work with AI systems on your behalf; since the amendment of July 2026 it prescribes no specific level per person. Have your lawyer go through the current legal text and the factors named in it and translate that into what it means for your deployment. Do not assume that a standard training package answers that question. Without working agreements and basic explanation, you have a tool, not a way of working.
Governance sounds like a side issue for later. In an advisory opinion from July 2026 on a planned Copilot deployment at a municipality, the Autoriteit Persoonsgegevens (the Dutch Data Protection Authority) wrote that an organisation must in any case carry out a number of actions before it starts using a generative AI system, certainly if that system has access to (all) the organisation’s data. According to the AP, anyone who skips those preconditions makes lawful deployment at a later stage virtually impossible. At a minimum, it is about knowing which data the system can access, who has access to it and for what purposes that information may be used. The questions you answer with your information manager, security officer and privacy officer are concrete:
If your organisation falls under archiving legislation, also raise the question of how you handle the drafts and summaries that Copilot produces. Which of those must be retained and under which selection rules is something you determine with your archivist or DIV adviser (records and information management); record a working agreement on this.
We advise answering these questions in writing in a concise usage framework of no more than a few pages. Keep it short enough to read in one sitting.
The question “Microsoft 365 Copilot or not” is really the question “which AI application belongs with which work”. There are roughly three categories.
A generic assistant in the office suite is aimed at work that individuals and teams do within their existing applications. In its Cloud Adoption Framework, Microsoft places Microsoft 365 Copilot under the purpose “Enhance individual efficiency”, with examples such as drafting, research and meeting preparation. Whether that is responsible in your case depends partly on the risk and the kind of data that occur in that work. Whether it saves time on balance depends on how often those tasks occur in your organisation and how much correction the outcome needs. Therefore measure per task; an organisation-wide effect is difficult to separate from other changes.
A targeted application for a single process, for example classifying incoming requests or searching a specific knowledge base, usually requires its own set-up: a demarcated dataset, integrations, management. In the same framework, Microsoft counts this type as “Automate business functionality” and notes that greater customisation generally requires more specialised skills and greater operational ownership. How much building work that is depends on the chosen solution and the integration. The effect of such an application can be better confined to one process and is therefore usually easier to measure, although attributing it to the application alone remains an assumption you must test.
Less supplier dependency is not something you get automatically with that. It requires deliberate choices in the architecture (can you replace the model or supplier without rebuilding the application?) and in the contract (who owns the data, prompts and configuration?).
A combination is quite conceivable: a generic assistant for the workplace, plus a few targeted applications where it really matters. Assess each choice against the same criteria: where is the work that costs time, which data does the application need, who manages it after delivery, and how do you measure whether it delivers anything?
Do not be led by the supplier’s bundle question. That something is possible within your licence is not an argument that it belongs in your process.
The term “digital employee” suggests that Copilot gets to work independently. That is only true in the sense that your real employees will work differently because of it, and that does not happen by itself. Cegeka names user resistance as one of the main barriers. Take that resistance seriously and ask what lies behind it before you schedule a training session.
What works in our experience:
Applications per role. A policy officer, a project leader and a service desk employee have different daily tasks. For each role, choose two or three recurring actions where you expect Copilot to save time, and let the pilot test whether that is correct. As Changelabel points out, employees do not automatically know how to use the tool meaningfully in their daily work; therefore focus the training on those actions.
Champions who use it themselves. Colleagues in the line who use the tool daily and answer questions from their immediate surroundings. That need not be a full-time position, but it must be someone’s task, with time in the diary.
A place for mistakes. Agree that users check Copilot’s output, and make sure that anyone who encounters an incorrect or incomplete result can report it without it feeling like a personal failure. Consider a Teams channel where participants share examples of good and bad output, alongside the formal training.
A measurement error you want to avoid: confusing satisfaction with results. That employees find an assistant pleasant does not mean their work becomes better or faster. That is a different question.
Therefore, for each pilot, choose two or three concrete tasks for which you record in advance how they currently run. How much time does an average completion take, how often does it go wrong, who has to check it? Without that baseline measurement, comparing afterwards becomes considerably weaker: you then rely mainly on impressions.
Microsoft, too, advises in its adoption material to define success measures in advance for business results, operational improvement, adoption and quality. That is a sensible starting point, provided you link those measures to your own work and not to usage figures alone.
Also measure the downside. How much output has to be corrected? Who does that and how much time does it take? If the correction time eats up the time saved, or quality does not improve, an assistant shifts work rather than reducing it.
Record who assesses the outcome and which outcome leads to which decision. A pilot without a stop criterion agreed in advance runs the risk of simmering on without a decision ever being taken.
As a conservative planning heuristic, an estimate based on experience and not a measurement, we count in months rather than weeks for a controlled start. That clashes with the impression that adoption material sometimes creates. The difference lies in what you count.
Cleaning up access rights, the privacy assessment, formulating working agreements and a pilot with real measurement each take time. Microsoft explicitly places the readiness assessment and data preparation before roll-out, in its onboarding guide for IT administrators. How long the whole takes depends on the state of your information management and on the availability of the people who have to carry it.
Approach it as a process in the line rather than as the launch of an IT project. That is an observation Innvolve also makes on the basis of its experience with Copilot adoption, with the advice to start with the conversation about the work rather than with the tool.
A possible division of roles, as an example and not as a prescription: one process owner who carries the pilot, an information manager who monitors data and permissions, IT management or service management that assigns settings, logging and management after delivery, and a board member who parks the supplier’s offer while the programme is running. Which division suits you depends on how your organisation is set up.
It also requires the willingness to conclude after a pilot that it delivers nothing for certain work. That is precisely the information you ran the pilot for.
Schedule a one-hour meeting with your information manager, your privacy officer and one process owner who wants to start themselves. As soon as permissions, logging or sensitive data come into play, and with Microsoft 365 Copilot that is quickly the case, your information security officer and IT management also sit at the table. Together, answer three questions: which two tasks in that process demonstrably cost time, which information does an assistant need for them, and who can already see that information now who should not?
With the answers you have a concrete message for your supplier and your board: this is where we start, this must be arranged first, and on this date we decide whether to continue. That is an answer to the pressure that you keep in your own hands.

Sixteen questions, seven minutes, and an instant spider chart showing your strongest and weakest dimension. No e-mail address needed to see the result.

AI · 20 October 2026
A model that performs well in testing can deliver less than expected in practice. Learn why trust drives AI value in government and how to measure it.
Read the article →

AI · 18 October 2026
An honest checklist: six questions that determine whether your organisation is ready for AI, and what the next step is if the answer is no.
Read the article →

AI · 18 October 2026
Almost every organisation that gets serious about data faces the same question: who is actually going to do this? Build, hire or outsource?
Read the article →
Work with us
The people who build it also run it afterwards. Eindhoven, since 2014.
We use Google Tag Manager to measure visits and Leadinfo to recognise which company is visiting. Neither loads unless you agree. If you choose essential only, the site works as normal and we measure nothing. Cookie statement · Privacy statement