"If I use enterprise Copilot, inside the Microsoft ecosystem, do I still have to worry about not uploading personal data of clients or patients, tax IDs, sensitive information? Or, since the environment is protected, can I relax?" It's the question anyone starting to use AI at work asks. Short answer: yes, you still have to worry about it. And in this article we look at why, and above all how to move correctly, with a concrete focus on pseudonymization — often cited, almost never done well.

Two planes not to confuse: the technical one and the legal one

When it comes to privacy and AI, two different conversations always get mixed up. The first is technical: where the data ends up, who can see it, whether it's used to train the models. The second is legal: whether you have the right to process that data that way. A "protected" environment solves much of the first problem, but doesn't touch the second.

Put simply: the fact that the room is armored doesn't mean you can put anything you want inside it. The rules on what you can process, for what purpose, and with what legal basis remain identical, whether you're using Copilot, an Excel spreadsheet, or an email.

What enterprise Copilot guarantees (and what it doesn't)

First fundamental distinction: enterprise Copilot is not free Copilot. Microsoft 365 Copilot, with a business license and access through the organization's account (Entra ID), offers real protections that the consumer version doesn't.

What the enterprise version guarantees:

  • Your prompts and data stay inside the organization's tenant, they don't end up in a shared pool.
  • Prompts and responses aren't used to train the foundation models.
  • It's covered by Microsoft's Data Processing Agreement (DPA) and, for EU customers, falls under the EU Data Boundary, which keeps European traffic inside the Union's borders.

What it does NOT guarantee (and where it's up to you to watch):

  • It doesn't give you a legal basis to process that data: you must still have that.
  • It doesn't apply the minimization principle by itself: if you upload unnecessary data, it stays there.
  • Watch out for a recent change: since 2026 Microsoft has enabled by default "Flex Routing," which during peak times can cause the model processing to happen outside the EU area. Data at rest still remains within the EU Data Boundary (except for limited pseudonymized data) and the administrator can disable the option from the admin center. It's worth checking your tenant's configuration with IT.

Golden rule: consumer Copilot (personal account, free version) offers none of these guarantees. Client or patient data should never be put there.

But then is using Copilot like using SharePoint?

It's the most natural objection: if sensitive data is already in SharePoint, OneDrive, and Teams, and I work in the same Microsoft environment, isn't using Copilot the same thing? Partly yes, partly no.

Yes, on the infrastructure side. Enterprise Copilot runs on the same tenant, with the same protections, and above all inherits the same permissions: if you don't have access to a folder, Copilot doesn't show it to you. You're not "exporting" data outside the protected environment.

No, on three aspects that matter. First, it's a different processing: storing a file and generating/analyzing that content are distinct operations for the GDPR, with a new purpose to record. Second, Copilot amplifies the permission problems you already have: a file mistakenly shared with "the whole company" in SharePoint stays buried, but Copilot fishes it out and serves it in a response in two seconds (so-called oversharing). Third, one thing is Copilot reading files already governed in SharePoint, another is when you paste or upload by hand data taken from emails, business systems, or external sources: there you're pulling data out of its context, and that's exactly the scenario where you need to pseudonymize upstream.

In summary: the right question isn't "can I use Copilot?", but "are my file permissions really in order?". If they are, Copilot is an extension of the environment you already use; if they aren't, it turns them into a visible problem.

The data to watch most carefully

Not all personal data is the same. Some require much higher caution:

  • Data of patients or assisted persons: they are almost always "special categories" (health data, art. 9 GDPR). Here the attention threshold is maximum and a specific legal basis is required.
  • Tax IDs (codici fiscali): they are direct identifying data, and in Italy there's also specific regulatory sensitivity about their use.
  • Names and surnames, addresses, emails, phone numbers, IBANs, license plates: all personal data, even if "trivial."

The principle to keep in mind is minimization: upload only the data that really serves to obtain the result. If AI needs to summarize a contract, it doesn't need the client's tax ID to do it.

Pseudonymizing isn't anonymizing

Two words often confused, but different from a legal point of view.

Anonymization: data is made irreversibly non-traceable to a person. Done well, the data exits the scope of the GDPR — but it's technically difficult and rarely reversible.

Pseudonymization: direct identifiers are replaced with placeholders (e.g. "Client 1"), but somewhere there's a key that allows the identity to be reconstructed. The data remains personal data to all effects, but the risk is greatly reduced because whoever sees the pseudonymized text can't trace it back to the person.

For daily use with AI, pseudonymization is the most practical tool: it lets you work on the content without exposing identities.

The mistake to avoid: "I upload the file and ask AI to pseudonymize it"

Here's the most important point, and the least understood. Many think of solving it this way: I take the file with names, tax IDs, and health data, upload it to Copilot, and write "pseudonymize this data." Seems logical. In reality, it doesn't protect anything.

Why it doesn't work: at the exact moment you upload the file, the clear data has already been transmitted and processed by the system.

Pseudonymization requested from AI happens AFTER the personal data has already entered. It's like handing someone your ID card and then asking them to black out the name: they've already seen it. Processing the clear data has already happened, and if you didn't have a legal basis or authorization to do it, the problem remains.

Moreover, AI isn't a reliable tool for this task: it can forget an occurrence, leave a tax ID in the middle of the text, handle inconsistently the same name written two ways. You have no completeness guarantee.

The rule: pseudonymization must happen BEFORE uploading the data, upstream, not entrusting it to the same system you want to hide the data from.

How to actually pseudonymize, in practice

The basic idea is simple: you replace the identifiers with placeholders before giving the text to AI, keep the correspondence in a separate place, and at the end re-insert the real data into the result. In practice:

  1. Identify direct identifiers in the text: names, surnames, tax IDs, addresses, emails, phones, IBANs, case numbers, dates that identify a person.
  2. Replace them with consistent and neutral placeholders: "Client 1", "Patient A", "[TAX_ID_1]", "[ADDRESS_1]". Always use the same placeholder for the same person, otherwise the text loses meaning.
  3. Keep the correspondence table (placeholder → real data) in a separate file, which you NEVER upload to AI. It's the "key" and must be protected like personal data.
  4. Give AI only the pseudonymized text and have the work returned with the same placeholders.
  5. Re-insert the real data into the final result, yourself, using the correspondence table.

Example: before and after

Suppose we want to rewrite more clearly a communication to a patient.

Dear Mario Rossi (TAX ID RSSMRA80A01H501U), residing at Via Verdi 12, we inform you that the results of the exams on 3/12 are available.: Dear [PATIENT_1] ([TAX_ID_1]), residing at [ADDRESS_1], we inform you that the results of the exams on [DATE_1] are available.

Your correspondence table (kept separate, never uploaded):

[PATIENT_1]: Mario Rossi

[TAX_ID_1]: RSSMRA80A01H501U

[ADDRESS_1]: Via Verdi 12

[DATE_1]: 3/12

Note that the health data "exam results" stays in the text: if it doesn't serve the task, better to remove it or make it generic. Pseudonymization concerns identifiers, but minimization concerns everything that isn't necessary.

A practical aid for AI itself

Manually replacing data in dozens of documents isn't realistic. You can automate the substitution with purpose-built tools (find-and-replace functions, scripts, data masking tools, corporate DLPs), but the key point remains: automation must run upstream, on your data, before giving it to the model — it must not be the model that "sees first and hides after."

And in more structured companies? The same result is achieved with Microsoft Purview, Microsoft 365's data governance suite. In practice it allows you to classify documents with sensitivity labels (e.g. "Confidential," "Health data") and apply DLP (Data Loss Prevention) rules that prevent Copilot from accessing certain files upstream or including them in responses. The advantage is that you act once at the policy level, without having to intervene document by document. It makes sense when volumes are high and sensitive data numerous; for occasional use, manual upstream pseudonymization remains sufficient.

Operational checklist to keep at hand

  • Am I using ENTERPRISE Copilot (organization's account), not the consumer version? If not, no client/patient data.
  • Is this use of AI provided for in the internal policies and in the company's record of processing?
  • Am I uploading only the data strictly necessary for the result (minimization)?
  • Have I removed or replaced names, tax IDs, addresses, and other identifiers BEFORE uploading?
  • Is health or sensitive data really indispensable? If not, I've removed it.
  • Is the correspondence table kept separately and protected?
  • If in doubt about health or special data, have I consulted the DPO or the privacy office?

In summary

The enterprise Microsoft environment reduces many technical risks, but doesn't relieve you of legal obligations. Pseudonymization is an excellent tool, provided it's done the right way: upstream, before uploading, and not by asking AI to hide data you've already shown it. The less personal data you put in, the fewer problems you have out.

Sources

  • Microsoft Learn — Enterprise data protection in Microsoft 365 Copilot: learn.microsoft.com/microsoft-365/copilot/enterprise-data-protection
  • Microsoft Learn — Flex routing (EU and EFTA): learn.microsoft.com/microsoft-365/copilot/copilot-flex-routing
  • EDPB — Guidelines 01/2025 on Pseudonymisation: edpb.europa.eu
  • Italian Data Protection Authority: garanteprivacy.it

Note: this article has informational purposes and does not constitute legal advice. For processing health or special data, and for configuring your tenant, always verify with your DPO, privacy office, or organization's IT.