Over the past two years, AI assistants have evolved from being primarily chat tools to becoming embedded in everyday workflows. Microsoft 365 Copilot sits inside Word, PowerPoint and Outlook. Google’s Gemini is built into Docs, Gmail and Drive. Anthropic’s Claude now connects to Google Workspace and to a growing number of business systems through connectors. The mechanics are different, since Microsoft and Google build their assistants directly into the systems they read from, while Claude connects to those systems from outside. But the governing principle is the same: none of these tools creates a new identity or a new permission system. Each one authenticates as the signed-in user and operates inside whatever access controls the organisation has already put in place.
The responsibility sits with the organisation
The reason is structural. An AI assistant cannot see a file, inbox or calendar for the person using it if they do not already have permission to access it. It does not, in other words, create a new access boundary. What it does is expose every access decision the organisation has already made, immediately and at scale. Decisions made carelessly, provisionally or years ago and never revisited, are amplified by the assistant, which finds and surfaces in seconds what would otherwise have stayed forgotten.
The real governance question is, then, whether the organisation’s own access model was robust before any assistant was introduced. Microsoft, Google and Anthropic each describe their assistants as operating within the organisation’s existing security boundary, authenticating through the organisation’s identity provider and respecting the conditional access and permission structures that are already configured. Where those structures are well maintained, the assistant behaves accordingly. Where they are not, the assistant makes that gap difficult to ignore.
The practical consequence is the same regardless of when an assistant is adopted. If a folder was shared too broadly two years ago, if a link was set to “anyone with the link”, or if permission was never revoked after a project ended, that exposure belonged to the organisation before the AI assistant arrived. Concentric AI’s 2H 2025 Data Risk Report found that approximately a third of files shared via ”anyone with the link” settings contain sensitive information, so this is not a theoretical scenario. The exposure just sat there, easy to overlook, because finding it required someone to know it existed and go looking. An AI assistant collapses that search into a single prompt. The exposure was always the organisation’s. What an AI assistant changes is how quickly that oversight gets tested.
With agents, the exposure grows
The governance conversation becomes more complex once organisations move from a single assistant answering questions to agents that carry out multi-step tasks, connect to external systems and act with reduced direct human oversight. Microsoft’s developer guidance for Copilot agents recommends that connectors be limited to trusted sources and that agents be designed with the possibility of breach in mind. Claude‘s architecture reflects the same logic: the model’s safety behaviour does not extend to managing access, identity or third-party integrations, which remain the organisation’s responsibility to govern. Google’s enterprise documentation for Gemini describes similar controls, including the ability to restrict which Workspace applications an AI agent can reach and to manage external sharing separately from internal access.
Regulators and standards bodies in different jurisdictions are beginning to speak to this directly, and are arriving at similar conclusions, independent of which vendor is involved. The UK Information Commissioner’s Office (ICO), in its January 2026 report on agentic AI, frames careful selection of the tools and data sources an AI system can access as a core governance requirement. The US National Institute of Standards and Technology (NIST) expresses a related idea in its Generative AI Profile: that responsibility rests with the deploying organisation, that risk must be assessed in the specific context of use, and that third-party data sources and components should be verified rather than trusted by default.
The law confirms where accountability rests
Under Articles 5(2) and 24 of the GDPR, and their mirrored provisions in the UK GDPR, accountability sits with the controller, not the vendor. This is true whichever AI assistant an organisation deploys. A vendor’s assurance that its product is “GDPR-compliant”, or that it respects existing access controls, address only the service itself. The organisation retains its own obligations to assess and document how the new tool changes the way personal data is processed.
For most organisations, this also means that an existing Data Protection Impact Assessment (DPIA) written before an AI assistant was introduced is unlikely to remain fit for purpose without a fresh review, whether the tool in question is Copilot, Gemini, Claude, or another workplace assistant. Across all of them, the role of a Data Protection Officer (DPO) is to advise on whether the DPIA reflects how the tool actually changes data processing, and to flag exposure before it materialises as live incidents.
Common governance gaps across AI workplace tools
A few gaps deserve particular attention.
- Old or overshared permissions: the most common source of exposure, with AI simply making them visible faster.
- Unclear agent and connector boundaries: with autonomous agents, it also gets harder to say which systems an agent can reach and under what authority.
- Inconsistent data handling terms: training use, retention, compliance commitments vary by vendor and plan and are easy to misunderstand.
- Outdated risk assessments: DPIAs and vendor reviews written before deployment often no longer reflect what’s actually being processed.
- Personal AI accounts on corporate devices: these can bypass whatever governance framework was built for the sanctioned tool entirely.
What good governance looks like
A workable approach to closing the gaps mentioned above tends to follow a similar sequence, whichever tool is being deployed. The specific controls available differ by vendor and by product tier, but the underlying sequence, and the categories of control it relies on, hold consistently across the major platforms.
First, remediate oversharing before the AI assistant is switched on.
This means identifying where sensitive information is exposed more broadly than necessary and reducing access to those who genuinely need it. In practice, this means admin-level controls: the ability to turn AI access on or off for specific applications, users or groups, rather than enabling it organisation-wide by default.
Second, set up guardrails that hold over time.
This includes labelling information by sensitivity and restricting access on a need-to-know basis. The AI tool also shouldn’t manage its own logins. It should use the same identity system as everything else, so access updates automatically when someone changes roles or leaves. Agents and connectors need clear boundaries too: a policy on which third-party sources they’re permitted to reach, reviewed before rollout. And external sharing of AI-generated content should be controlled separately from internal access.
Third, build in the ongoing compliance work.
This means maintaining audit records, applying retention policies, and running periodic data clean-up, so that accountability can actually be demonstrated.
The DPO can play a pivotal role in coordinating all three steps, since access control, information labelling, retention and record-keeping rarely sit within a single team’s responsibility.
Getting AI-ready
AI workplace assistants can deliver real value, but only in an environment configured to support them safely. At HewardMills, we help organisations get AI-ready: assessing access controls and oversharing exposure, refreshing DPIAs for the new processing context, helping set guardrails for the agents and connectors being introduced, and building the wider AI governance framework that lets these tools, whichever platform they run on, be adopted with confidence. For further information, please get in touch.
