Using third-party AI without a data processing agreement puts you at legal risk under the GDPR because the moment personal data flows to an external AI provider, that provider becomes a data processor — and EU law requires a formal, written DPA to be in place before that processing begins. Without one, your organisation is operating outside its legal basis for data sharing, which can expose you to regulatory fines, enforcement action, and reputational damage. Below, we unpack the most important questions organisations are asking about AI tools and DPAs in 2026 — and if you want to talk through your specific situation, feel free to get in touch with us.
What counts as a data processing agreement and when is one required?
A data processing agreement is a legally binding contract between a data controller (your organisation) and a data processor (a third party that handles personal data on your behalf). Under Article 28 of the GDPR, a DPA is required whenever a processor handles personal data on your instructions — and it must set out the subject matter, duration, nature, and purpose of the processing, as well as the obligations and rights of both parties.
A DPA is required the moment personal data is involved. That means names, email addresses, employee records, customer information, IP addresses, or any other information that can identify a living individual. If you send that data to a third party — including an AI tool — for any processing purpose, you need a DPA in place before that data transfer occurs. There is no minimum volume threshold and no grace period. The legal obligation applies from the very first interaction.
The DPA must cover specific elements to be valid. These include the categories of data being processed, the technical and organisational security measures the processor applies, rules around sub-processors, data breach notification obligations, and provisions for returning or deleting data at the end of the relationship. A vague or incomplete DPA may not satisfy regulatory requirements even if one exists on paper.
What data does third-party AI actually process when you use it?
Third-party AI tools process whatever data you input into them, and often more than users realise. When you type a prompt, upload a document, paste an email thread, or ask a question about a client, all of that content is transmitted to the AI provider’s infrastructure. If that content contains personal data, the provider is processing it — regardless of whether you intended to share it.
Beyond the obvious inputs, AI tools frequently collect metadata: your session identifiers, usage patterns, timestamps, and in some cases, the content of your prompts for model improvement purposes. Depending on the provider’s configuration, your inputs may be retained and used to fine-tune future model versions. Enterprise plans with specific data handling commitments often differ significantly from free or consumer-tier access, where data retention and use policies are far more permissive.
The categories of data that commonly flow into AI tools without users noticing include customer names and contact details pasted into drafting prompts, employee performance data used in HR-related queries, financial figures included in analysis requests, and medical or legal information shared in professional contexts. Each of these categories carries its own regulatory weight, and some — like health data — are classified as special category data under the GDPR, attracting even stricter handling requirements.
What are the specific legal risks of missing a DPA?
The specific legal risks of operating without a DPA include GDPR enforcement action, fines of up to 4% of global annual turnover or €20 million (whichever is higher), regulatory investigations, and the inability to demonstrate lawful data processing to supervisory authorities. Beyond fines, missing DPAs create gaps in your accountability documentation that can undermine your entire compliance posture.
From a regulatory standpoint, the absence of a DPA is treated as a structural failure, not a minor oversight. Data protection authorities across the EU have demonstrated a willingness to act on DPA deficiencies — not only when a breach has occurred, but as part of routine audits and complaint-driven investigations. If a data subject files a complaint about how their data was handled and your organisation cannot produce a valid DPA with the AI provider involved, that gap becomes evidence of non-compliance.
There are also contractual and reputational risks. Many enterprise contracts and procurement frameworks now require evidence of compliant data processing arrangements. If a client or partner discovers that personal data shared with your organisation was passed to an AI tool without a DPA, it can trigger contract termination clauses, damage trust, and create liability exposure that goes well beyond regulatory fines. Continuous governance means tracking these risks before they surface, not after.
Does a vendor’s privacy policy replace the need for a DPA?
No. A vendor’s privacy policy does not replace a data processing agreement. A privacy policy is a public-facing document that describes how the vendor processes data for its own purposes as a controller. A DPA is a bilateral contract that governs the vendor’s role as a processor acting on your instructions. These are legally distinct instruments that serve entirely different functions under the GDPR.
This is one of the most common misconceptions we encounter. Organisations point to a vendor’s privacy policy as evidence of compliance, but the privacy policy tells you what the vendor does with data it collects as a business — not what it commits to do with your customers’ personal data when you use its service. The DPA is the document that creates the legal relationship between your organisation and the vendor in their capacity as your processor.
Some vendors include DPA-adjacent language within their terms of service, which can create further confusion. Terms of service may reference data handling, security standards, or even GDPR compliance, but unless the document is explicitly structured and titled as a data processing agreement and meets the requirements of Article 28, it does not satisfy the legal obligation. When in doubt, check whether the document is signed (or accepted through a formal process), covers the mandatory Article 28 elements, and specifically addresses your organisation’s data rather than the vendor’s general operations.
Which AI tools are most commonly used without a proper DPA in place?
The AI tools most commonly used without a proper DPA in place are consumer-grade or freemium AI assistants accessed through personal or team accounts rather than enterprise agreements. Tools in this category include general-purpose large language model interfaces, AI writing assistants, AI-powered email tools, meeting transcription services, and AI-integrated productivity applications where users have signed up individually rather than through a corporate procurement process.
Consumer and freemium AI assistants
When employees sign up for AI tools using their work email addresses but without going through IT or legal review, they are typically accepting consumer terms of service rather than enterprise agreements. Consumer terms rarely include a DPA because the vendor is not positioned as your processor in that context. The data you submit may be used to improve the model, stored on infrastructure outside the EU, and subject to the vendor’s own data governance decisions rather than yours.
AI features embedded in existing software
A growing source of DPA gaps in 2026 is AI functionality built into tools organisations already use — word processors, email clients, project management platforms, and CRM systems. When a vendor adds an AI feature to an existing product, the data processing implications change, but the original DPA (if one exists) may not cover the new AI processing activities. Organisations need to review existing agreements when vendors introduce AI capabilities, not assume that the original DPA extends automatically.
How should organisations close the DPA gap for AI tools they already use?
To close the DPA gap for AI tools already in use, organisations should conduct an AI tool inventory, assess whether each tool processes personal data, check whether a valid DPA exists for each one, and either obtain a compliant DPA or discontinue use of tools where one cannot be established. This process should be embedded into ongoing governance rather than treated as a one-time exercise.
Start with discovery. Many organisations do not have a complete picture of which AI tools their teams are using, particularly those adopted informally at the team or individual level. A practical first step is to survey department heads, review software procurement records, and check browser extension usage and app integrations connected to core platforms. Shadow AI adoption — tools used without IT or legal awareness — is a real and growing challenge.
Once you have an inventory, categorise each tool by whether it processes personal data and whether a DPA is currently in place. For tools that process personal data without a DPA, your options are to request a DPA from the vendor (many enterprise tiers include this), upgrade to an enterprise plan that includes data processing commitments, or restrict use to non-personal data only. If a vendor cannot or will not provide a DPA, continued use for personal data processing is not legally defensible.
Closing the gap is not a project — it is an ongoing capability. New tools are adopted continuously, vendors update their terms, and AI features are added to existing software without fanfare. Our governance services are built around exactly this kind of continuous governance: maintaining visibility, accountability, and legal compliance across all the systems your organisation uses, not just at implementation time but throughout the entire lifecycle. That is the structural difference between governance as a living system and governance as a periodic audit.
If your organisation is ready to take a structured approach to AI governance and close the DPA gaps in your current toolset, contact us to plan a conversation — we will help you build the foundation that keeps you compliant as AI adoption continues to grow.
Frequently Asked Questions
Can we use a standard DPA template, or does it need to be customised for each AI vendor?
Many AI vendors provide their own DPA templates, particularly at the enterprise tier, and in most cases you will be working from their document rather than your own. The key is not whether the template is bespoke but whether it meets the mandatory requirements of Article 28 GDPR — covering the correct categories of data your organisation actually processes, your specific processing purposes, and the security measures relevant to your use case. If a vendor's template is overly generic or omits elements specific to your context, you are entitled to negotiate amendments. A DPA that does not accurately reflect the actual processing taking place offers weaker legal protection even if it technically exists.
What happens if an employee has already been using an AI tool without a DPA — do we need to report it as a data breach?
Not automatically, but it requires careful assessment. The absence of a DPA is a compliance failure, and if personal data was transferred to a vendor without one, that transfer lacked a lawful basis — which is a serious issue. Whether it rises to the level of a reportable data breach under Article 33 GDPR depends on whether the unauthorised processing created a risk to the rights and freedoms of the individuals whose data was involved. You should document what data was shared, with which tool, under what terms, and assess the risk level. If there is any uncertainty, consulting your Data Protection Officer or an external adviser before deciding not to report is strongly recommended.
Does the DPA requirement apply if we only use AI tools to process anonymised or aggregated data?
If the data is genuinely anonymised — meaning it cannot be re-identified by any reasonable means — then GDPR obligations, including the DPA requirement, do not apply to that data. However, true anonymisation is a high bar. Pseudonymised data, data where individuals could be re-identified using additional information the vendor holds, or aggregated data that includes small enough cohorts to allow inference, still qualifies as personal data under the GDPR. Before relying on anonymisation as a reason to skip a DPA, you need to be confident the anonymisation is robust and documented — regulators will scrutinise this claim if a complaint or audit arises.
We use a US-based AI provider. Does a DPA alone cover the international data transfer requirements?
No — a DPA addresses the controller-processor relationship but does not by itself legalise the transfer of personal data outside the European Economic Area. For transfers to US-based providers, you also need a valid transfer mechanism under Chapter V of the GDPR, such as Standard Contractual Clauses (SCCs) or reliance on the EU-US Data Privacy Framework if the provider is certified under it. Many enterprise-tier DPAs incorporate SCCs as a schedule, which is convenient, but you should verify this is explicitly included rather than assumed. Missing a transfer mechanism is a separate and equally serious compliance gap that sits alongside the DPA requirement.
How often should we review our DPAs with AI vendors to make sure they're still valid?
DPAs should be reviewed whenever there is a material change — when a vendor updates its terms of service, introduces new AI features, changes its sub-processor list, or alters its data retention or storage practices. Beyond event-driven reviews, an annual audit of all active DPAs is good practice, particularly in the AI space where product capabilities and data handling practices are evolving rapidly. Pay close attention to sub-processor notifications: most DPAs require vendors to inform you of sub-processor changes, and AI providers frequently add or change the infrastructure and model providers they rely on. Failing to track these changes means your DPA may no longer reflect the actual processing taking place.
What should we do if an AI vendor refuses to sign a DPA or says one isn't necessary?
If a vendor refuses to provide a DPA or claims one is not required, that is a significant red flag and, under GDPR, means you cannot lawfully use that tool to process personal data. Some vendors — particularly those operating consumer-grade products — take this position because they are not structured to act as a data processor and do not want the contractual obligations that come with it. In that scenario, your options are to restrict use of the tool strictly to non-personal data, escalate to a senior commercial contact or the vendor's legal team to request enterprise terms, or discontinue use for any purpose involving personal data. Continuing to use the tool while the vendor declines to provide a DPA is not a defensible position under GDPR, regardless of how useful the tool is.
Are there specific DPA considerations for AI tools used in HR, legal, or healthcare contexts?
Yes — significantly so. These contexts frequently involve special category data under Article 9 GDPR (health data, data about criminal convictions, trade union membership, and similar), which attracts stricter processing conditions and requires explicit justification beyond the standard lawful bases. When AI tools are used to process employee health records, legal case files, or patient information, your DPA needs to specifically address the special category nature of that data, the additional safeguards applied, and the explicit legal basis permitting its processing. Many standard DPA templates do not adequately address special category data, so legal review is particularly important in these sectors. The reputational and regulatory consequences of a breach involving health or legal data are also substantially higher than for standard personal data.
Related Articles
- What does a potential acquirer look for during security due diligence?
- What does a governance maturity assessment involve?
- How does a governance policy reduce the risk of regulatory fines?
- Why is a governance framework important for private equity portfolios?
- What governance documentation is required for ISO 27001 stage 2 audits?