What is a data processing agreement (DPA)?
A data processing agreement (DPA) is a contract required under Article 28 of the EU's General Data Protection Regulation whenever one organization (a controller) has another organization (a processor) handle personal data on its behalf. It sets out what the processor may and may not do with that data: the purpose and duration of processing, security measures, sub-processor rules, breach notification, and what happens to the data when the relationship ends. Without one in place, a controller that hands personal data to a processor is out of compliance with the regulation, independent of anything else the processor does right.
This is general information about what a DPA is and why one might be needed, not legal advice. Whether a specific vendor relationship requires a DPA, and what terms it should contain, is a determination for the company's own counsel or data protection officer.
Controller and processor, the two roles
GDPR defines these roles by function, not by company size or industry. The controller decides why and how personal data gets processed, typically the company whose customers or employees the data belongs to. The processor acts on the controller's instructions and doesn't decide the purpose of the processing itself, typically a vendor providing infrastructure, software, or a service the controller uses. A single company can be a controller for some data and a processor for other data, depending on the relationship in question.
Why AI vendors specifically raise this
Running a workload that touches personal data, on infrastructure the company doesn't own, is exactly the pattern Article 28 is written for: a processor handling data on the controller's behalf. That applies whether the vendor is a cloud AI API, a managed inference platform, or infrastructure like dedicated GPU hosting, whenever the workload running on it processes personal data. It doesn't apply automatically to every AI vendor relationship; if no personal data ever reaches the vendor, there's nothing for a DPA to govern. The determination hinges on what data actually flows to the vendor, not on the vendor's category.
What a DPA typically covers
Article 28 sets out required content rather than leaving it to negotiation: the subject matter, duration, nature, and purpose of the processing; the categories of data and data subjects involved; the controller's and processor's obligations; and specific terms covering confidentiality, security measures, sub-processor engagement and notice, assistance with data subject requests, breach notification, deletion or return of data at the end of the contract, and audit rights. A DPA missing these elements doesn't satisfy the article regardless of what it's called.
GPUwerk's own DPA
GPUwerk operates as a processor for customers who run personal data on their dedicated instances, and publishes its Article 28 agreement at /legal/dpa, covering the specifics of what GPUwerk does and doesn't do with instance content, sub-processor use, deletion on termination, and breach notification. That page and this one describe GPUwerk's own terms as written; they have not been reviewed by outside counsel, and a company with its own compliance requirements should have its own legal or data protection advisor confirm the agreement meets its specific obligations before relying on it.
How a DPA gets put in place
In practice, a DPA is usually a standard document a vendor publishes and the customer accepts as part of signing up, rather than something negotiated line by line for every customer. That works for most relationships, since Article 28's required content is largely fixed regardless of who the parties are. A company with unusual requirements, a specific sub-processor restriction, or a longer breach-notification window than the vendor's standard terms offer, would need to raise that directly with the vendor rather than assume the standard document covers it.
What happens without one
Processing personal data through a vendor with no DPA in place is a compliance gap under GDPR, independent of whether anything actually goes wrong with the data. A supervisory authority or auditor reviewing a company's vendor relationships would expect to find a DPA wherever personal data reaches a third-party processor; its absence is itself a finding, not something that only matters after a breach. That's the practical reason to check for one before, not after, sending personal data to any new vendor.