Do You Need a DPA to Use AI at Work? (GDPR)

Yes. Under the GDPR, whenever a processor handles personal data on your behalf, Article 28 requires a written contract — the document commonly called a data processing agreement, or DPA. When your staff enter personal data into an AI (customer names, emails, HR records), the provider acts as a processor and you remain the controller: a DPA becomes legally mandatory. Business and API tiers offer this contract; consumer accounts do not. And a DPA alone isn't enough: you also need a legal basis, transparency toward the individuals, and a safeguard for transfers outside the EU.

Why a DPA is mandatory (GDPR Article 28)

GDPR Article 28 requires that, whenever a processor handles personal data on behalf of a controller, the relationship be governed by a contract (or another binding legal act). That contract must set out the subject-matter and duration of the processing, its nature and purpose, the type of personal data, the categories of data subjects, and the obligations and rights of the controller. Article 28(9) states the contract must be 'in writing, including in electronic form' — so the DPA obligation is explicitly written, it cannot be left informal.

The controller also has an upstream duty: Article 28(1) requires using only processors that provide 'sufficient guarantees' regarding appropriate technical and organisational measures. So choosing your AI vendor is itself a compliance act — not just signing the paperwork.

What the DPA must contain

Article 28(3) lists eight mandatory clauses (a to h). The DPA must provide that the processor:

• processes the data only on the controller's documented instructions, including for transfers to third countries;
• ensures persons authorised to process the data are bound by confidentiality;
• implements the security measures of Article 32;
• respects the conditions for engaging another processor (sub-processor);
• assists the controller in responding to data-subject rights requests;
• helps the controller meet its Articles 32-36 obligations (security, breach notification, impact assessment);
• deletes or returns the data at the end of the engagement;
• provides the information needed to demonstrate compliance and allow audits.

The DPA also governs sub-processors: the processor cannot engage another processor without the controller's prior written authorisation, and must impose the same protection obligations down the chain. The EDPB's Guidelines 07/2020 stress that a DPA should not merely restate the GDPR: it must include concrete, specific detail on how each requirement and security level will be met.

Consumer AI vs business tier: the dividing line

This is where compliance plays out in practice. OpenAI offers a Data Processing Addendum (DPA) for its business products — ChatGPT Business/Team, ChatGPT Enterprise and the API — to support customer GDPR compliance. No DPA is available for consumer services such as the free or Plus version of ChatGPT: this is precisely why processing personal data should go through a business account, not a personal one.

The difference goes beyond paperwork. By default, OpenAI does not train its models on data submitted through its business plans or the API unless the customer explicitly opts in; conversely, consumer ChatGPT may use conversations to improve models unless the user opts out in settings. That gap maps exactly onto the 'documented instructions' and confidentiality clauses a DPA is meant to lock in (see the OpenAI — Enterprise privacy and OpenAI — Data Processing Addendum pages, cited by name).

A DPA isn't enough: legal basis, transparency, transfers

A DPA is not a blanket authorisation to use AI. For lawful use, the controller must also meet several conditions:

1. 1A valid legal basis under Article 6 (for example legitimate interest or contract performance).
2. 2Transparency toward the data subjects: they must know their data may be processed via an AI tool.
3. 3Data minimisation: process only data that is adequate, relevant and limited to what is necessary.
4. 4A transfer mechanism when data leaves the EU/EEA: many AI providers route to the United States, which generally makes the European Commission's Standard Contractual Clauses (SCCs) necessary — often embedded in the provider's DPA.

The Standard Contractual Clauses (SCCs) are model contract clauses pre-approved by the European Commission (modernised version adopted 4 June 2021) that provide appropriate safeguards for transferring personal data from the EU/EEA to third countries. Even with SCCs, the controller must verify that the general GDPR conditions and the Chapter V requirements are met for each transfer.

The fix: shrink the perimeter by anonymizing upstream

The practical conclusion for employers is clear: if staff paste personal data (customer names, emails, HR records, client files) into an AI tool with no DPA in place, no documented legal basis, no transparency to the individuals and no transfer safeguard, the use is not GDPR-compliant. Using a business or enterprise tier — or an API — that executes a DPA is the baseline fix.

A complementary lever cuts the risk at the root: anonymise or remove personal data before sending it to the provider. The less personal data reaches the processor, the smaller the compliance perimeter — and the transfer exposure — becomes. That is exactly the spirit of data minimisation: processing that is adequate, relevant and limited to what is necessary.

That's where ONYRI Sanitize comes in: the engine replaces sensitive data with reversible tokens before sending; detection and the token↔value mapping stay in your browser, and only anonymized text reaches the AI tool. A DPA is still needed for whatever still transits, but the less personal data leaves in the clear, the more your processing and transfer perimeter shrinks.