Executive Summary

When turning on Gemini or Copilot moves the company into a different logic of governance.

Editorial note: This article is provided for educational and informational purposes only. It does not constitute legal advice, regulatory advice or a formal compliance opinion. In regulated environments, any assessment ultimately depends on the facts, the actual architecture in place, the service tier subscribed to, the contracts, the assessments performed and the controls that have in fact been deployed.

In the life of an organization, significant transformations often emerge without the clarity of formal intention. They take shape gradually, through incremental changes that seem too minor to warrant scrutiny, until they accumulate into a new reality that no one explicitly chose but everyone must now manage. This is increasingly how artificial intelligence is entering the enterprise. Whether the system is Gemini inside Google Workspace or Copilot inside Microsoft 365, the change often presents itself as a convenience, a small enhancement to tools people already use, a capability added to the texture of ordinary work. Yet the moment that environment contains personal, confidential or financial information, the activation of AI takes on a different meaning. It becomes a governance event. [1][3][5]

A recent case from Quebec’s mortgage sector captures that shift with unusual clarity, because it makes visible a problem that is spreading much faster than most organizations seem willing to admit. A client asked a broker whether the T4 slips, bank statements, credit reports, identification documents and the rest of the mortgage file were being stored in an environment where AI was disabled or whether they sat under the same user identity through which an AI assistant had been activated for note-taking and routine operational work. The broker replied, in substance, with a now familiar formula, pointing to the strength of the provider’s security controls and to the general compliance of the existing setup. The sentence was clearly intended to reassure, yet it left the real question untouched.

What made the exchange so revealing was the nature of the question itself. The client was not seeking a general assurance about the reputation of Google or Microsoft, nor asking whether modern security features existed. The concern was narrower, more precise and therefore more important. Had the business drawn a meaningful boundary between the custody of highly sensitive personal and financial information and the activation of an AI system inside the same operating environment? This is an architectural question, certainly, though architecture here has to be understood in its fullest sense. The issue reaches beyond where tools sit on a screen or which vendor provides them. It concerns the way a company translates its legal obligations into permissions, segregation, accountability and enforceable limits. That is why the issue extends well beyond mortgage broking. In one form or another, it now concerns every organization that stores confidential information inside a modern workspace while simultaneously embracing AI as though the technology had arrived without altering the legal and operational conditions surrounding the data already there. [1][2]

The misunderstanding at the centre of this problem is especially striking because it is so widespread. It rests on a confusion many executives still carry quite casually between security and governance, as though the two were simply variations on the same posture of diligence. They are not. Security is concerned with what must remain outside. It deals with intrusion, exfiltration, unauthorized access, credential compromise and technical resilience. Governance begins at another point. It asks what authorized people, authorized systems and authorized vendors are now permitted to do with the information they can already reach. A system can be exemplary by the ordinary standards of security and still be badly governed. In high-stakes sectors, serious exposure often begins there, with the quiet expansion of what legitimate actors are allowed to do. [1]

From the client’s side, the problem is easier to understand than many organizations assume. A mortgage file does not contain generic data. It contains the intimate outline of an economic life, income, debt, assets, banking history, professional trajectory and sometimes family circumstances, immigration status or traces of past financial difficulty. As long as those documents remain inside a conventional storage or processing environment, they are already sensitive, though their movement and transformation remain relatively bounded. The moment an AI capability is introduced into the same workspace, those same records become easier to summarize, query, reinterpret and convert into new internal artefacts, meeting notes, draft emails, extracted summaries, comparative analyses and other derivative records often easier to move than the original file itself. A flawed summary can distort the reading of a financial situation. A widened internal surface can normalize access that should never have become routine. What appears, from the organization’s point of view, as efficiency can appear, from the client’s point of view, as a subtle expansion of the number of people and systems now participating in the handling of their financial life.

Google and Microsoft do make an important commitment here. Google states that Workspace customer data, including prompts and outputs, is not used to train Google models or models for other customers. Microsoft states that prompts and responses in Microsoft 365 Copilot and Copilot Chat are not used to train the underlying foundation models. Even so, the central issue remains. The question is not confined to what the vendor refrains from doing with the data in the abstract. The real concern lies in what the information can now be made to do inside the environment itself, once AI has been activated on top of an existing workspace. Google’s administration documentation notes that Gemini Business and Enterprise can connect to Workspace services such as Gmail, Drive and Calendar, and that administrators are responsible for deciding whether such access is allowed. Microsoft, for its part, states that Copilot works through Microsoft Graph and accesses information within the signed-in user’s permissions. That is precisely why oversharing becomes such a serious governance issue once AI is layered into the environment. [4][5]

This is where Quebec’s Law 25 becomes so instructive. Its relevance lies in the precision with which it brings into view what many organizations had never truly operationalized, regardless of whether the immediate trigger is Gemini or Copilot. The baseline obligations were already there. Determine the purpose of collection. Limit collection to what is necessary. Restrict access appropriately. Protect the information. Inform individuals properly. Put governance practices in place. None of those obligations begins with AI. Yet the activation of an AI capability inside an environment that already contains personal information can move the company into a different legal and operational posture. If what is being introduced amounts to a project involving the acquisition, development or redesign of an information system that uses, stores, communicates or otherwise handles personal information, then a privacy impact assessment may be required. If the activation makes possible a broader, more inferential or more derivative use of information originally collected for another purpose, then the organization must be able to justify that use within the framework that governs purpose limitation or support it through an appropriate consent position where the law requires it. If communication outside Quebec is involved, then cross-border analysis becomes a documented obligation rather than a discretionary exercise. If, finally, the tool moves beyond administrative assistance and into decisions based exclusively on automated processing, another legal regime comes into view. The toggle introduces a new factual condition inside the organization, and once that condition exists, the law applies to it with a degree of immediacy and concreteness that becomes much harder to ignore. [1]

Google Workspace is revealing in this respect precisely because it feels ordinary, and Microsoft 365 is revealing for the same reason. Familiarity breeds a misleading confidence. Companies assume they understand the environment better than they actually govern it. They imagine Gemini or Copilot can be considered one service at a time, as though the question were simply whether they want a little drafting help in Gmail or Outlook, a little summarization in Docs or Word or note-taking in Meet or Teams. The control reality is more nuanced. Service tiers differ. Administrative capabilities vary. What matters here is less the icon visible in the interface than the structure of access that lies beneath it. Google’s documentation indicates that the ability to manage Gemini features on a service-by-service basis within Workspace is associated with certain higher-tier offerings, and it also makes clear that even where features are turned off in one service, a user may still ask Gemini in another enabled service about an item to which that user has access. Microsoft’s documentation states that Copilot accesses only the information a user is authorized to access, and it also identifies oversharing in SharePoint and OneDrive as one of the most common deployment risks. This is another way of showing that access design, rather than vendor prestige, determines the real boundary. What matters, then, is the architecture of control, the identity, the permissions, the sharing model and the pathways through which information remains reachable once AI is active somewhere in that user’s working environment. [3][4][5]

That is why the client’s question deserves to be taken with full seriousness. It reflects neither irrational suspicion toward AI nor an eccentric fixation on infrastructure. It reflects a sophisticated understanding of how digital environments now operate. What matters, in the end, is the operational reality created on the day the feature was activated, far more than the elegance of the tool, the familiarity of the vendor or the attractiveness of the feature itself. Did the company simply gain a more capable interface, or did it alter the processing condition surrounding information that had already been entrusted to it under older assumptions? Did it assess that shift before it occurred, or did it discover its significance only when a client was precise enough to ask the right question? Did it separate document custody from AI-enabled work, or did it assume that a respectable vendor and a familiar interface would be enough to carry the burden of compliance on their own?

The serious response to this situation lies in a more demanding, and in a certain sense simpler, discipline of governance. It begins with candour. Privacy notices and client-facing disclosures should describe the real workflow, rather than the one the organization would prefer to imagine it has. If AI-enabled tools are part of the operating environment, the company should be able to explain clearly what information sits there, what those tools are allowed to do, what they are not allowed to do, whether processing may occur outside Quebec, and who remains accountable for the result. It continues with architecture. The most defensible pattern remains a separation of identity and permission, in other words, an arrangement in which the environment used for AI-assisted operations does not have access to the repository containing raw client financial files. It continues again with information governance, because both Google and Microsoft make the same deeper point in different ways: these systems surface and reason over what users can already access, which means pre-existing oversharing, weak internal permissions or poorly governed repositories become newly consequential once AI is layered on top of them. It extends, finally, into internal discipline, explicit rules for raw client records, approval thresholds for any AI use touching personal information, staff training that treats AI as a governance issue rather than a convenience feature and assessments conducted before activation rather than after the first well-formed objection from a client. [1][5]

This is where the matter fully enters what I call ITOLOGY. It concerns the way technology enters executive environments, the way organizations underestimate the significance of changes introduced under the appearance of trivial implementation choices and the fact that the deepest shifts rarely occur at the level of the tool itself. They occur at the level of what the organization has allowed the tool to approach, touch, query or accompany. A feature becomes a governance question at the precise moment it shares an access domain with confidential information. From that moment onward, the conversation can no longer revolve around convenience alone. It has to turn toward purpose, boundaries, permissions, accountability and proof.

For that reason, I do not believe the right executive question concerns trust in Gemini, Copilot, Google, Microsoft or AI in the abstract. Those questions are too easy, and ultimately too shallow. The better question concerns what became true the day the feature was activated. Did the business simply gain a helpful interface, or did it create a materially new condition of processing around information that had already been entrusted to it under different assumptions? Did it evaluate that shift before it happened, or only recognize its significance when a client forced the issue by asking the right question? Did it create a real boundary between document custody and AI-enabled work, or did it assume that the credibility of the supplier and the familiarity of the environment were sufficient substitutes for governance?

I suspect the real dividing line in AI governance will emerge elsewhere, between those that understood activation changes the operating condition of data and those that carried on as though nothing of substance had changed at all. The first group will gradually build defensible systems, because it will understand what must be assessed, explained, restricted and documented. The second will continue to answer governance questions in the language of security, and will continue to be surprised when that answer no longer satisfies clients, regulators or boards.

The law was already there all along. What remained uncertain was whether the company had undertaken the harder work of translating that law into operations before the technology made the distance between principle and practice impossible to overlook.

References

[1] Quebec, Act respecting the protection of personal information in the private sector, CQLR c. P-39.1, especially sections 3.1, 3.2, 3.3, 3.5 to 3.8, 4, 8, 8.1, 12, 12.1 and 17.

[2] Autorité des marchés financiers, guidance on information to be disclosed and related obligations for mortgage brokers and representatives.

[3] Google Workspace Admin Help, Manage access to Gemini features in Workspace services.

[4] Google Workspace Admin Help, Turn the Gemini app on or off; Control Gemini Business and Enterprise access to Workspace data.

[5] Microsoft Learn, How does Microsoft 365 Copilot work?; Privacy and protections for Microsoft 365 Copilot Chat; Prevent oversharing in Microsoft 365 Copilot: deployment blueprint.