What Your IT Provider Doesn’t Cover With Copilot (And Why That’s Normal)
When Copilot gets deployed at a firm, the IT provider usually handles it. That makes sense. They manage the Microsoft 365 environment, they know the tenant, they have the credentials. So they activate the Copilot licenses, configure the basic settings, maybe run an initial test.
Technically, Copilot works after that. The compliance side usually looks different. And that is not a criticism of the IT provider. It comes down to the nature of the task.
What IT Providers Do Well
I work with IT service providers regularly and I respect their work. What they deliver is not trivial.
License provisioning and tenant configuration. Network setup and endpoint management. User onboarding and identity management. Baseline security settings: MFA, Conditional Access, Defender configuration. Exchange, SharePoint, Teams, the full Microsoft 365 administration.
That is their core competency. And for most IT requirements, it covers everything you need. A new server, a network issue, a Windows 11 rollout: the IT provider is the right contact for that. And they do it well.
Where the Gap Appears
With Copilot, something shifts. Copilot is not just another Microsoft 365 feature you activate. It is an AI system that accesses every piece of data the respective user has access to. SharePoint, OneDrive, emails, Teams chats. And that creates requirements that go beyond traditional IT administration.
What I describe here is what I see in practice. Not as criticism, but as observation.
Start with the Data Protection Impact Assessment. GDPR Article 35 requires a DPIA when a new processing operation is likely to result in high risk. An AI system that potentially searches all company data falls into that category. Creating a DPIA requires GDPR expertise. Specific knowledge of legal bases, proportionality, technical and organizational measures. That is a legal and regulatory task, not a technical one.
Then there is the Data Processing Agreement. Microsoft has a DPA for Microsoft 365. Germany’s Data Protection Conference (DSK) has previously rated Microsoft’s DPA as insufficient. Evaluating whether the current state is acceptable for your organization requires regulatory expertise. That is not something an IT technician can assess on the side. And it would be unfair to expect that.
Sensitivity Labels are another area. In a tax advisory firm or law firm in Germany, Section 203 of the Criminal Code applies. Client data falls under professional secrecy obligations. The Label architecture needs to reflect these specific requirements. That is more than a technical configuration. It requires understanding which data categories need special protection and why.
Similar situation with DLP policies. Data Loss Prevention in Microsoft 365 can prevent sensitive data from flowing into the wrong channels. But the policies need to align with industry-specific compliance requirements. I summarized which questions need answers before a Copilot rollout here.
And finally, employee training. Article 4 of the EU AI Act requires AI literacy for all employees working with AI systems. Developing the training content, documenting it, and proving compliance is a standalone task that requires knowledge of regulatory requirements.
Why This Is Not a Criticism
IT administration and compliance consulting are different disciplines. That is so obvious it almost does not need saying. But in practice, the two get mixed up.
A tax advisor does not do their own IT. An IT provider does not do GDPR impact assessments. Both are necessary. Neither replaces the other.
I sometimes see firms expecting their IT provider to cover the compliance side as well. That is understandable, because it is the existing contact and you know each other. But it is an expectation that usually cannot be met. Not because the provider is bad. Because it is not their field.
How Both Sides Work Together
The approach I take sits right at this intersection.
I create the compliance architecture. That means: DPIA, Sensitivity Label taxonomy, DLP ruleset, training materials, documentation for the Record of Processing Activities. Everything on the regulatory side.
The IT provider implements the technical configuration. They deploy the labels, configure the DLP policies, adjust the SharePoint permissions. These are tasks that fall within their core competency.
The result for the firm: working technology and documented compliance. Not one or the other.
I have done this with multiple firms. The collaboration with the respective IT provider was straightforward in every case, because the division of responsibilities was clear. No turf wars, no jurisdictional disputes. Everyone does what they are good at. How Copilot oversharing happens technically and what helps against it is something I explained here.
What This Means for You
If your IT provider activated Copilot and you are wondering whether the compliance side is fully covered: the answer is probably no. That does not mean your IT provider did something wrong. It means part of the work is still open.
The good news: catching up is not a big project. A DPIA, a clean label structure, and employee training can be done in a few days. In parallel with ongoing operations, without anyone having to turn off their Copilot.
I offer a free 30-minute assessment where I look at where your current Copilot configuration stands and what is missing on the compliance side. No sales pitch. An honest evaluation you can use even if we do not end up working together.
Book a call: 30-minute AI compliance assessment
Jose Lugo is a CISSP-certified consultant based in Germany, specializing in GDPR-compliant AI deployments for mid-size firms. More at joselugo.de and services.