Across European businesses, the adoption of AI productivity tools has accelerated faster than compliance frameworks have adjusted. Microsoft Copilot, ChatGPT Enterprise, Gemini for Workspace, and dozens of sector-specific AI tools are now embedded in daily workflows — drafting emails, summarising meetings, analysing documents, processing client data. Most of the legal teams responsible for data protection compliance have not yet caught up with what this actually requires under GDPR.
This article explains the specific GDPR obligations that attach to enterprise AI tool deployment, the gaps that most organisations have, and what a compliant deployment actually looks like.
The core problem: AI tools process personal data
The first thing to establish is that enterprise AI tools almost universally process personal data. An AI assistant that summarises a meeting transcript processes the names, voices, and views of everyone in that meeting. A tool that drafts emails processes the contact details and communication history of your clients and colleagues. A tool that analyses sales call recordings processes the personal data of your customers.
Under GDPR, any processing of personal data requires a lawful basis, must be covered in your Records of Processing Activities, must be disclosed in your privacy notices to data subjects, and — if a third-party processes the data on your behalf — must be governed by a Data Processing Agreement (DPA).
None of this is controversial. What is surprising is how many organisations have deployed AI tools at scale without completing any of these steps.
A scenario: the 80-person professional services firm
Consider a hypothetical: a consulting firm with 80 employees, based in Brussels, serving enterprise clients across Belgium and Germany. In early 2026, the IT team rolled out Microsoft Copilot to all employees as part of the Microsoft 365 E5 upgrade. Separately, the client-facing team started using ChatGPT Enterprise for proposal drafting.
Six months later, the firm receives a data subject access request from a former client contact who has learned that their name and meeting notes appear in Copilot's suggested summaries. The data protection officer — a part-time role — begins investigating and discovers:
- Neither Copilot nor ChatGPT Enterprise is listed in the firm's Records of Processing Activities
- The firm signed the standard Microsoft Customer Agreement but never specifically reviewed or signed the Microsoft GDPR Data Processing Amendment that governs Copilot's processing of personal data
- No Transfer Impact Assessment was conducted for ChatGPT Enterprise, which stores and processes data on US-based infrastructure operated by OpenAI
- Client privacy notices do not mention that AI tools may process client data
- There is no documented legal basis for processing client personal data through AI summarisation tools — it was assumed to fall under the existing contract lawful basis, but this assumption was never analysed
This is not an extreme scenario. It is a description of the state of compliance at most professional services firms that adopted enterprise AI tools in 2025 and early 2026.
Obligation 1: The Data Processing Agreement
Article 28 of GDPR requires a written DPA with every third party that processes personal data on your behalf. An AI tool vendor that processes personal data at your instruction — summarising your meetings, drafting your emails, analysing your documents — is a processor under GDPR. The DPA must meet the requirements of Article 28(3), including specifying the subject matter and duration of processing, the nature and purpose of processing, the types of personal data and categories of data subjects, and the obligations and rights of the controller.
The major AI vendors all provide standard DPA templates — Microsoft's Data Processing Addendum, OpenAI's Enterprise Privacy Agreement, Google's Data Processing Amendment. These are not automatically in force by virtue of using the service. They must be specifically reviewed, and in most cases specifically accepted or countersigned, to take effect.
The common failure mode: an organisation's IT team enabled an AI tool under a standard commercial agreement without realising that a separate DPA process was required, or assuming the general vendor agreement was sufficient.
What to do: Audit every AI tool deployed in your organisation. For each one, identify whether a GDPR-compliant DPA is in place. If not, locate the vendor's DPA template and execute it before any further personal data is processed through that tool.
Obligation 2: Records of Processing Activities
Article 30 requires that the ROPA cover all processing activities carried out on behalf of the controller. Every new AI tool that processes personal data is a new processing activity that must be added. The ROPA entry should include: the purposes of the AI-based processing, the legal basis, the categories of personal data processed, the categories of data subjects, the recipients (including the AI vendor), any transfers to third countries, and the retention period.
The most common gap here is not a failure to update the ROPA at all — it is updating it at a level of abstraction that does not reflect what the AI tools actually do. "Employee productivity tools" is not a sufficient description of Copilot processing meeting transcripts containing client names and commercially sensitive conversations.
What to do: For each AI tool, map the specific personal data it accesses and processes. Add a granular ROPA entry for each distinct AI processing activity — meeting summarisation, email drafting, document analysis — specifying the actual data categories and the individuals whose data is affected (employees, clients, third parties).
Obligation 3: Transfer Impact Assessments for US-based AI providers
Most enterprise AI tools are operated by US-based companies. Data processing under these tools involves personal data being transferred to and processed in the United States. This requires a valid transfer mechanism under Chapter V of GDPR.
US companies that are certified under the EU-US Data Privacy Framework (DPF) provide an adequacy basis for transfers. OpenAI, Google, and Microsoft are DPF-certified for the relevant services. However, a DPF certification does not eliminate the requirement to conduct a Transfer Impact Assessment — it changes its scope. Even with DPF certification, the DPF remains subject to legal challenge (Schrems III proceedings are ongoing), and responsible compliance programmes maintain SCCs alongside DPF reliance.
For AI vendors that are not DPF-certified, Standard Contractual Clauses are required, and a Transfer Impact Assessment must be conducted before the SCCs are executed. The TIA must assess whether US surveillance law (particularly FISA Section 702 and Executive Order 12333) creates risks for the specific data being transferred.
What to do: For each US-based AI tool, verify whether the vendor is DPF-certified. Review whether SCCs are in place as a supplementary mechanism. Conduct or review TIAs specifically addressing AI-processed personal data. Document the analysis.
Obligation 4: Legal basis analysis
Every AI-based processing activity requires a lawful basis. The three most commonly applicable bases for enterprise AI tool deployment are:
Legitimate interests (Article 6(1)(f)): The most likely basis for internal operational uses such as productivity tooling, internal meeting summarisation, and employee workflow tools. Requires a documented Legitimate Interests Assessment that weighs the business interest against employee privacy expectations. In employment contexts, the power imbalance makes this basis less reliable than in customer-facing contexts — employees cannot freely object to processing tied to their employment tools.
Contract (Article 6(1)(b)): Applicable where the AI processing is strictly necessary to perform a service contract with the data subject — for example, if a client has engaged you specifically to produce AI-generated analysis of their data. "Necessary" is interpreted narrowly. Processing that is convenient but not strictly required for contract performance does not qualify.
Consent (Article 6(1)(a)): High bar in professional contexts. Must be freely given, specific, informed, and revocable. Not appropriate as the primary basis for widespread enterprise tool deployment because it creates a fragile compliance architecture — any employee or client who withdraws consent disrupts the processing.
The practical conclusion for most organisations: legitimate interests is the most viable basis for internal productivity tool use, provided a proper LIA is conducted. For client-facing AI processing, the basis needs to be assessed specifically for each use case — and the client privacy notice must be updated to reflect the processing before it begins.
Obligation 5: Privacy notice updates
Articles 13 and 14 require that data subjects be informed, at or before the time their data is collected, of all relevant processing — including the purposes, legal bases, and recipients. If you have deployed AI tools that process client data, and your client-facing privacy notice does not mention this, you are in breach of your transparency obligations regardless of whether any other GDPR requirement is met.
Privacy notice updates for AI tool deployment should specify: that AI tools may be used to process data shared with or generated in interactions with your organisation; the categories of AI processing involved; the vendors used; and the basis on which that processing occurs.
What a compliant AI tool deployment looks like
A compliant deployment involves, before the tool is enabled for employees:
- Reviewing and executing the vendor's DPA
- Conducting a Transfer Impact Assessment if the vendor processes data outside the EEA
- Documenting the legal basis for each AI processing activity in a written analysis
- Adding ROPA entries for each AI processing activity
- Updating employee-facing privacy notices to disclose AI tool use
- Updating client-facing privacy notices where client data will be processed by AI tools
- If the AI processing involves large-scale or high-risk personal data processing, conducting a DPIA under Article 35
The DPIA requirement is commonly overlooked for AI tools because the individual transactions seem low-risk. But Article 35 requires a DPIA for processing that "is likely to result in a high risk" — and systematic AI processing of employee communications, client interaction data, or sensitive professional information at scale meets this threshold for most organisations.
The enforcement risk from non-compliant AI tool deployment is not hypothetical. Multiple DPAs have already initiated investigations following complaints about employer AI tool use. The Italian Garante and French CNIL have both published guidance on AI in the workplace that sets clear expectations. An organisation that deployed enterprise AI tools in 2025 without the GDPR infrastructure described above has a live compliance liability — one that compounds with every day the tools remain in use without correction.
Frequently Asked Questions
Does Microsoft Copilot require a separate DPA from our standard Microsoft 365 agreement?
Yes. The standard Microsoft Customer Agreement and standard Microsoft 365 agreements are not sufficient on their own. Microsoft provides a specific Data Processing Addendum (DPA) that governs the processing of personal data through Microsoft 365 services including Copilot. In most enterprise agreements, this DPA is incorporated by reference and accepted through the online services terms — but you should verify this with your Microsoft account team and confirm the DPA is specifically applicable to your Copilot deployment. The DPA terms vary by product and region.
Can employees use personal ChatGPT accounts for work tasks involving client data?
No, and this is one of the highest-risk scenarios for GDPR compliance. When an employee uses their personal ChatGPT account, the organisation has no DPA with OpenAI, no ROPA entry covering the processing, and no visibility into what personal data is being sent to OpenAI's systems. The organisation is the data controller for client data it holds — and its obligations do not transfer when employees informally route that data through personal tool accounts. Organisations should have a clear policy prohibiting personal AI tool accounts for any processing involving personal data, backed by technical controls where possible.
What categories of personal data processed by AI tools are highest risk for GDPR purposes?
The highest-risk categories are those that are special category data under Article 9 — health information, political opinions, religious beliefs, sexual orientation, trade union membership, biometric data, genetic data. AI tools that process meeting recordings or communications may inadvertently capture special category data (a client mentioning a health condition, an employee discussing their union involvement). The processing of special category data requires an explicit legal basis under Article 9(2) in addition to the Article 6 lawful basis, and typically triggers a DPIA requirement. Organisations should specifically assess whether their AI tools might encounter special category data and implement controls accordingly.
Our AI vendor is based in the US but is DPF-certified. Do we still need SCCs?
Legally, DPF certification provides an adequacy basis for transfers, meaning SCCs are not strictly required. However, many privacy advisers recommend maintaining SCCs alongside DPF reliance as a precautionary measure, given the DPF's history of legal challenge (Privacy Shield was invalidated in 2020; the current DPF faces a CJEU challenge in Schrems III proceedings). An organisation that relied solely on the DPF and it is subsequently invalidated would be left without a transfer mechanism overnight. SCCs provide continuity, and the cost of maintaining them alongside DPF is minimal compared to the cost of responding to an invalidation.
How detailed must the ROPA entry be for an AI tool that processes multiple types of data?
The ROPA entry must be granular enough to accurately reflect the actual processing. If a single AI tool performs distinct processing operations on distinct data sets — for example, summarising client meetings (which processes client contact data and conversation content) and drafting internal reports (which processes employee data) — these should be separate ROPA entries, or a single entry with clearly differentiated rows for each processing activity. The ROPA is the document a supervisory authority will examine first in an investigation. An entry that says "AI productivity tool" without specifying the categories of data, the legal basis, or the recipients does not meet the Article 30 standard.