The DPA was signed before the AI features shipped
A vendor passed review last year. Since then it has added an AI assistant to the product, and the assistant sends customer content to an external model provider. The data processing agreement still lists the sub-processors from the original review.
Nobody did anything unusual here. Products change faster than contracts, and AI features make the gap wider because each new capability can bring a new model provider, a new hosting region or a new retention rule.
Why does a missing sub-processor matter?
Under GDPR Article 28(2), a processor may not engage another processor without the controller's prior specific or general written authorisation. With a general authorisation, the processor must tell the controller about any intended addition or replacement, so the controller has the chance to object.
Article 28(4) then requires the same data protection obligations to flow down to that sub-processor by contract. If a model provider isn't on the list, you can't show that you were informed, that you had the chance to object, or that the obligations reached it.
Step 1: read the clause, not the questionnaire
Questionnaires ask whether the vendor uses sub-processors. The answer is usually yes, with a link. The review starts in the DPA itself: the sub-processor section, the notification mechanism for changes, and any annex that names providers and processing locations.
Then compare that list with what the vendor discloses elsewhere: its public sub-processor page, its trust centre, its AI feature documentation and its privacy notice. Any provider that appears in one place but not the other is a gap.
Step 2: turn the gap into a finding
A finding is useful when someone else can check it without redoing the review. This is how it looks in the ProcureCortex demo, which uses sample data for a fictional vendor:
- Finding F-3081, Helix Health Data (healthcare, Tier 1)
- Title: Sub-processor list does not cover AI model providers
- Requirement: GDPR Article 28(2), sub-processor transparency
- Source: DPA, section 6.3
- Severity: Critical. Confidence: 94%. Status: Open
What makes that finding defensible?
Each line answers a question an auditor will ask. The source points to the exact section of the document, so the gap can be checked in seconds. The requirement says which rule it breaks. The severity says how urgent it is, and the confidence tells the reviewer how much checking the extraction still needs. The demo labels findings against SOC 2, ISO 27001, GDPR and contract clauses; mapping to DORA, NIS2 or the AI Act is your own team's analysis.
Step 3: check it against your own policy and decide
The regulation sets the minimum. Your internal AI vendor policy decides what you accept: for example, whether customer data may be used to train models, which regions are allowed, and whether a new model provider needs re-approval.
Then a reviewer decides. The options are usually to accept the risk with a reason and an expiry date, to require a contract change before renewal, or to restrict the AI features until the DPA is updated. The decision needs a name, a date and a reason, kept with the finding rather than in an email thread.
Where does the EU AI Act come in?
The AI Act, Regulation (EU) 2024/1689, adds duties on top of GDPR. AI literacy obligations under Article 4 have applied since 2 February 2025. The transparency obligations in Article 50 apply from 2 August 2026: providers must make sure people know when they are interacting with an AI system, and deployers have their own disclosure duties, for example for deep fakes.
For a buyer, that means two more questions for an AI vendor: which of your features fall under Article 50, and what do you give us so we can meet our own deployer obligations? Ask for it in writing, and keep it with the assessment.
What to prepare if you are the AI vendor
- A current sub-processor list that names every model provider, its role and its processing location.
- A change notification process that matches your DPA, with a notice period your customers can act on.
- A short statement on training: whether customer data is used to train or improve models, and how customers can opt out.
- Documentation of your Article 50 transparency measures for each AI feature.
Try the review on sample data
You can open this finding and the rest of the Helix Health Data assessment at procurecortex.com/explore (self-serve: email sign-in link, no sales call). All vendors and findings in the demo are sample data. For the wider picture of what to ask AI providers, see our guide What Is AI Vendor Risk? A Guide to Evaluating Third-Party AI Providers.
Sources
- Regulation (EU) 2016/679 (GDPR), Article 28: https://eur-lex.europa.eu/eli/reg/2016/679/oj
- Regulation (EU) 2024/1689 (Artificial Intelligence Act): https://eur-lex.europa.eu/eli/reg/2024/1689/oj
- European Commission, AI Act regulatory framework: https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai
Frequently asked questions
Does a new AI model provider count as a sub-processor under GDPR?
If the provider processes personal data on the vendor's behalf, for example when customer content is sent to a model for inference, it is a sub-processor. Article 28(2) then requires your authorisation and, under a general authorisation, prior notice of the change so you can object.
When do the EU AI Act transparency obligations apply?
Article 50 transparency obligations apply from 2 August 2026. AI literacy duties under Article 4 have applied since 2 February 2025.
Is the Helix Health Data finding real customer data?
No. Helix Health Data and finding F-3081 are sample data in the ProcureCortex demo, used to show how a finding links to its source and requirement.
ProcureCortex turns vendor documentation into structured, explainable compliance findings. Explore demo or explore the platform.
