GDPR
How to Get a GDPR Art.28 DPA for Your GPU Cloud
And what a valid one must actually contain (2026)
If any personal data — patient records, user data, anything identifying a real person — passes through a GPU provider while you train or run a model, that provider is your data processor. Under Article 28 of the GDPR, you cannot lawfully use them without a signed Data Processing Agreement (DPA). No DPA, no lawful processing. This is the wall most ML teams hit right before deployment.
What Article 28 actually requires
Article 28(3) GDPR is specific about what a DPA must set out. A DPA that skips any of these is not compliant, regardless of how polished it looks:
- The subject matter, duration, nature and purpose of the processing
- The type of personal data and categories of data subjects
- The obligation to process only on the controller's documented instructions
- Confidentiality commitments for anyone handling the data
- Article 32 security measures (encryption, access control, isolation)
- Rules for engaging sub-processors — and prior authorisation
- Assistance with data-subject rights and breach notification
- Deletion or return of data at the end of the service
- Submission to audits and information to demonstrate compliance
Why US GPU platforms make this hard
Popular community GPU marketplaces are optimised for price and speed, not for regulated European data. Two structural problems recur:
Jurisdiction
Data processed on US infrastructure is exposed to the US CLOUD Act, which sits in tension with your GDPR obligations. A DPA alone does not resolve where the data physically runs.
Standard terms
Many platforms offer only a generic DPA on request — or none — with no meaningful sub-processor disclosure. Your DPO cannot approve what they cannot see.
The sub-processor disclosure most teams forget
Under Article 28(2) and (4), your processor is responsible for its own sub-processors — and you are approving the whole chain, not just the vendor at the top. A credible DPA names every sub-processor, its role, the data it touches, and its location. If billing and email vendors handle any data, they belong in that table, with a clear statement that no workload data flows to them.
When you review a GPU vendor, ask for that table explicitly. Its absence is a red flag; its presence tells you the vendor has actually thought about the chain.
Self-serve vs request-and-wait
The traditional path is: email the vendor, wait days for a templated PDF, forward it to legal, iterate. For a small team trying to ship, that delay is the deployment.
It does not have to work that way. GhostNexus runs ML workloads on GPUs in Nuremberg, Germany, and lets you generate a GDPR Art.28 DPA yourself in about 30 seconds, pre-filled with the full sub-processor chain, the Article 32 security measures, a 72-hour breach-notification commitment, and French governing law. It is a draft for your legal team to review — but you get it instantly, not in three business days.
A quick checklist before you sign any GPU DPA
- Does it name every sub-processor, with role and location?
- Does it state where workloads physically execute?
- Does it commit to breach notification within a defined window?
- Does it cover deletion or return of data after the job?
- Does it specify governing law and audit rights?
This article is general information, not legal advice. GhostNexus does not hold HDS certification; whether a given setup fits your obligations depends on your overall architecture and should be confirmed with your DPO or counsel.
Get your DPA now — no email, no wait
Fill in your organisation's details and download a GDPR Art.28 DPA pre-filled with GhostNexus's sub-processors and security measures. Ready for your legal team to review.