Your legal team is fielding a vendor contract for an AI tool that will process customer data. The vendor's pitch deck looks solid. Their security certifications are current. The business case is clear. But if you sign without a structured due diligence process, you have just accepted liability for every GDPR Article 28 obligation the vendor cannot demonstrate it meets, and for every EU AI Act compliance gap you did not document before deployment.
Third-party AI vendor risk is one of the fastest-moving areas in privacy governance in 2026. The EDPB's 2025 guidance on processor obligations made clear that controllers cannot delegate their compliance burden to a vendor contract alone, the Article 28 requirement for "sufficient guarantees" demands documented evidence, not a signed DPA and good faith. At the same time, the EU AI Act's deployer obligations mean your organization now carries AI-specific governance requirements for high-risk and limited-risk systems regardless of which vendor built them.
This guide gives you a structured due diligence framework: the dimensions to assess, the questions to ask, the documentation to require, and a decision checklist before you sign. If you need help managing data processing agreements, vendor risk assessments, and AI system governance across your entire vendor stack, Secure Privacy's Privacy & AI Governance Platform has a dedicated Vendor Management module built for exactly this workflow.
Key takeaways
- GDPR Article 28 requires you to verify that every AI vendor processing personal data on your behalf provides "sufficient guarantees" of technical and organizational security measures. A signed Data Processing Agreement is necessary but not sufficient, you must document the basis for your assessment of sufficient guarantees.
- The EU AI Act creates deployer-specific obligations for high-risk AI systems regardless of who built the tool. If you deploy a third-party AI system that falls under Annex III (biometrics, employment screening, credit scoring, education access, law enforcement, migration, administration of justice, or essential private services), your organization is the deployer and carries governance obligations including DPIA equivalents, human oversight measures, and record-keeping.
- AI subprocessors (the vendor's own third-party dependencies) are a primary disclosure and contract-flow risk. Your DPA must flow down to subprocessors. Require a complete subprocessor list and contractual notification rights before onboarding.
- Training data provenance is a due diligence category that most organizations skip. If your vendor's model was trained on data that included personal data without a lawful basis, those privacy violations are in your supply chain. Ask for training data documentation.
- The right to audit is contractually required under GDPR Article 28(3)(h). Ensure the DPA includes a real audit right, not just a right to receive the vendor's latest ISO 27001 certificate.
Dimension 1: GDPR Article 28 processor verification
Article 28 requires that controllers use only processors that provide "sufficient guarantees to implement appropriate technical and organisational measures." The due diligence obligation is the controller's to document.
What "sufficient guarantees" means in practice: The EDPB's guidelines on processors indicate that sufficient guarantees must be assessed against the specific risk profile of the processing. General security certifications (ISO 27001, SOC 2 Type II) are evidence of security controls, not evidence of compliance with GDPR-specific processing obligations. Both are relevant; neither substitutes for the other.
Required DPA elements under Article 28(3): Verify the DPA includes all required clauses:
- Processing only on documented controller instructions
- Confidentiality obligations on all personnel with data access
- Security measures per Article 32 (encryption, pseudonymization, access controls, testing)
- Subprocessor approval: prior specific or general written authorization, with change notification
- Assistance with data subject rights requests (access, erasure, portability, objection)
- Assistance with breach notification (Article 33) within the controller's 72-hour window
- Data deletion or return upon termination
- Audit support: provide all information necessary to demonstrate compliance, allow audits
Questions to ask the vendor:
- What is your Article 28 DPA template and which clauses are negotiable?
- Do you maintain a Record of Processing Activities (RoPA) for processing on behalf of controllers?
- What is your process for notifying us of a personal data breach affecting our data?
- What is your SLA for responding to data subject rights requests we forward to you?
- What evidence of technical and organizational measures can you provide beyond certifications?
If your current DPA with an AI vendor doesn't include all of these clauses, stop and renegotiate before the next data subject rights request arrives at your door.
Dimension 2: AI subprocessor transparency
AI tools typically involve a stack of subprocessors: the foundation model provider (OpenAI, Anthropic, Google, Mistral, Cohere), the cloud infrastructure (AWS, Azure, GCP), vector database providers, fine-tuning services, and logging/monitoring platforms. Every subprocessor that processes personal data in scope of your deployment is a subprocessor under GDPR Article 28(4), and your DPA must flow down.
Subprocessor disclosure requirements: Under GDPR Article 28(2), you must authorize each subprocessor either specifically (by name) or through a general authorization with notification rights. General authorization is more common but requires a contractual mechanism by which the vendor notifies you of subprocessor changes before they take effect, giving you a meaningful opportunity to object.
What to require:
- A complete, current subprocessor list before signing
- Contractual change notification: minimum 30 days' advance notice before adding or replacing a subprocessor that processes your personal data
- Evidence of DPA flow-down: the vendor's DPA with each subprocessor that imposes equivalent obligations
- Data residency: where each subprocessor processes data, especially for international transfers
EDPB LLM anonymization finding: The EDPB's April 2025 report on AI and data protection confirmed that large language models rarely achieve GDPR anonymization standards. This means any claim by an AI vendor that their LLM "anonymizes" your data before processing it should be treated with significant skepticism and require specific technical substantiation.
Foundation model subprocessor risk: If the vendor uses a foundation model API (e.g., OpenAI's API), your personal data may be processed in the United States. Verify whether the vendor has a Standard Contractual Clauses framework in place for the transfer, and whether the foundation model provider trains on API-submitted data, most enterprise API contracts include a data non-training clause but the default must be confirmed.
Questions to ask:
- Which foundation model(s) does your tool use, and who provides them?
- Does your DPA with [foundation model provider] prevent them from training on data we submit?
- What is your subprocessor change notification process and what is our contractual objection window?
- Where is personal data processed at rest and in transit across your subprocessor stack?
Run this subprocessor check before any new AI vendor goes to procurement sign-off, retrofitting subprocessor controls after data is already flowing is significantly harder.
Dimension 3: EU AI Act deployer obligations
The EU AI Act's Annex III high-risk AI system categories determine whether your deployment triggers deployer-specific governance obligations. The Act entered full enforcement for high-risk systems on August 2, 2026, though the Digital Omnibus amendment extended the GPAI transparency obligations timeline to December 2, 2027.
High-risk system classification: Verify whether the AI tool you are deploying falls under Annex III by checking the system's intended purpose against the categories: biometric identification and categorization, management of critical infrastructure, education and vocational training access decisions, employment decisions (recruitment, screening, performance evaluation, termination), access to essential private services (credit scoring, insurance), law enforcement, migration and asylum, and administration of justice.
Deployer obligations for high-risk systems (Article 26): If the system is high-risk and your organization is the deployer, you must:
- Implement human oversight measures
- Monitor the system's operation for risks to health, safety, or fundamental rights
- Maintain logs generated by the system for at least 6 months (or as required by specific sector law)
- Notify the provider of any incidents or serious malfunctions
- Conduct a Fundamental Rights Impact Assessment (FRIA) if operating under public authority or as a provider of essential private services
- Inform employees and their representatives if the system is used in the employment context
Questions to ask the vendor about EU AI Act compliance:
- How have you classified this system under the EU AI Act's risk tiers?
- If high-risk: do you maintain the technical documentation required under Article 11 and Annex IV?
- Is the system registered in the EU database for high-risk AI systems?
- What instructions for use (Article 13) do you provide, and how are they maintained as the model updates?
- What human oversight mechanisms are built into the system, and what must we implement on our side?
- Do you notify deployers of material model updates that may affect the system's compliance profile?
Complete the EU AI Act risk classification before procurement sign-off, not after deployment when reconfiguring human oversight measures costs significantly more.
Dimension 4: Training data provenance and bias documentation
AI tools trained on personal data create a privacy risk that exists independently of how the tool processes personal data during your deployment. If the model was trained on data collected without a lawful basis, those violations are embedded in the model's weights, and regulators have begun scrutinizing training data provenance as part of AI enforcement.
What to ask about training data:
- Was personal data used to train the model, and if so, what was the lawful basis under GDPR Article 6?
- Is your training data documented in a model card or equivalent technical documentation?
- Has the model been evaluated for bias and discriminatory outputs, especially if the system affects employment, credit, or access to services?
- What is your process for handling erasure requests from individuals whose data may have been in the training set?
- Are there contractual rights for us to request re-training or fine-tuning exclusions?
Bias and fairness documentation: For high-risk systems under the EU AI Act, providers are required to conduct post-market monitoring and document bias evaluation under Article 72. Even for limited-risk systems, request the vendor's bias assessment, this is increasingly a procurement requirement under corporate ESG and procurement governance standards.
If the vendor cannot produce training data documentation, treat it as a red flag equivalent to a missing DPA, both represent undocumented legal risk in your supply chain.
Dimension 5: Security architecture and breach response
Security measures under Article 32: GDPR Article 32 requires "appropriate" technical and organizational measures. For AI tools processing personal data, appropriate measures typically include:
- Encryption at rest and in transit (document cipher standards and key management)
- Access controls: role-based access, principle of least privilege, MFA
- Audit logging: who accessed what data and when
- Vulnerability management: patch cadence, penetration testing frequency, CVE response SLAs
- Incident detection: monitoring tools, alert thresholds, incident classification criteria
Breach notification SLA: GDPR Article 33 requires breach notification to the supervisory authority within 72 hours. Your DPA must require the vendor to notify you of a breach "without undue delay" and in any case within 24 hours, to give you time to assess and notify the authority. Confirm the vendor's contractual notification SLA and their breach classification criteria.
Questions to ask:
- What certifications do you maintain (ISO 27001, SOC 2 Type II, ISO 27701)?
- What is your mean time to detect and mean time to respond to security incidents?
- What is your contractual SLA for notifying us of a personal data breach, and what information is included in the initial notification?
- Can you provide penetration testing results or executive summaries from the last 12 months?
- Do you have cyber insurance, and what is the coverage level for data breach liability?
Ask for the vendor's breach simulation results if they have them, a vendor that has tested their incident response is materially lower risk than one operating on theoretical procedures.
Dimension 6: Data retention, deletion, and portability
Retention limits: Personal data processed by a third-party AI tool must not be retained longer than necessary for the stated purpose. Confirm:
- Does the vendor retain interaction logs, queries, or outputs containing personal data? For how long?
- Is the retention period configurable per customer, or is it a fixed platform default?
- Is there a contractual data deletion mechanism at contract termination?
Data portability: If your organization needs to migrate away from the vendor, verify whether you can export your data and metadata in a machine-readable format.
Erasure rights: Verify the vendor's process for handling GDPR Article 17 erasure requests. If the tool has processed personal data as part of a fine-tuned model, confirm whether erasure from the training set is technically feasible and what the vendor's process is.
Pre-deployment decision checklist
| Assessment area | Documented? | Acceptable? |
|---|---|---|
| DPA executed with all Article 28(3) clauses | ☐ | ☐ |
| Subprocessor list reviewed and approved | ☐ | ☐ |
| Subprocessor change notification rights in DPA | ☐ | ☐ |
| International transfer mechanism (SCCs, adequacy) verified | ☐ | ☐ |
| EU AI Act risk classification assessed | ☐ | ☐ |
| High-risk deployer obligations identified and assigned | ☐ | ☐ |
| Training data provenance documented | ☐ | ☐ |
| Bias assessment reviewed | ☐ | ☐ |
| Security certifications reviewed | ☐ | ☐ |
| Breach notification SLA confirmed in DPA | ☐ | ☐ |
| Retention period reviewed and configured | ☐ | ☐ |
| Audit right confirmed in DPA | ☐ | ☐ |
| DPIA completed if high-risk processing | ☐ | ☐ |
Complete this checklist before deployment sign-off. Any "No" in the Documented column is a gap to close before signing. Any "No" in the Acceptable column is a dealbreaker or requires escalation.
Common due diligence gaps
Accepting the vendor's DPA template without review: Most AI vendor DPA templates are written to minimize the vendor's obligations. The audit right clause often reads "we will make available information sufficient to demonstrate compliance", which lets the vendor decide what information is sufficient. Negotiate for an explicit right to commission independent audits with reasonable notice.
Missing subprocessor notification rights: General authorization for subprocessors is acceptable under GDPR, but only if paired with a real notification mechanism and an objection period. Many DPAs grant general authorization with notification rights that are structurally non-functional, email notification to a generic address, 7-day objection window. Require minimum 30 days and a named technical contact.
Not assessing EU AI Act risk tier before deployment: Most organizations treat EU AI Act risk classification as the vendor's problem. It is not. Article 26 makes deployers responsible for operating within the system's intended purpose and implementing human oversight. If the vendor has not classified the system, the deployer must do it.
Treating a DPA as a risk transfer: A signed DPA allocates responsibility between controller and processor under GDPR. It does not transfer the controller's liability to the processor. If the vendor breaches their DPA obligations and a supervisory authority investigates, you are the controller and you bear the primary enforcement relationship.
Skipping DPIA because "the vendor has one": If your deployment of the tool constitutes high-risk processing (systematic monitoring, large-scale special category data, novel automated decision-making), you are required to conduct your own DPIA under Article 35. The vendor's DPIA covers their general processing; yours covers your specific use case.
Frequently asked questions
Do we need a DPA with every AI tool we use?
Yes, if the tool processes personal data on your behalf. "Processing personal data" includes submitting queries that contain personal data, processing outputs that derive from personal data, and storing logs of interactions that include personal data. If employees input customer names, emails, or case data into an AI tool, that tool is a processor and requires a DPA under Article 28.
Can we use a vendor that hasn't signed our DPA template?
You can use the vendor's template, provided it contains all Article 28(3) mandatory clauses. Review it against the Article 28(3) checklist above. Clauses that give the vendor unilateral rights to change subprocessors without prior notice, or that limit the audit right to self-attestation only, require negotiation before signing.
What if the AI vendor is based outside the EU?
If the vendor processes personal data of EU data subjects and has no EU establishment, they are subject to GDPR under Article 3(2) extraterritorial scope. The transfer of personal data to the vendor must be covered by a transfer mechanism. Standard Contractual Clauses, adequacy decision (UK, Switzerland, US Data Privacy Framework), or Binding Corporate Rules. Verify which mechanism the vendor relies on and confirm SCCs are executed if required.
Does the EU AI Act apply to us if we're just using a third-party AI tool?
If the system is a general-purpose AI tool that you deploy for a specific purpose, you are the deployer under the EU AI Act and Article 26 deployer obligations apply. If you use a general-purpose AI tool (a foundation model accessed via API) and direct it to perform high-risk tasks, your organization may also be classified as a provider of a high-risk system.
How often should we repeat due diligence on existing AI vendors?
Annual review is a baseline. Trigger additional review on: material model updates disclosed by the vendor, changes to the vendor's subprocessor list, any security incidents or breach notifications, your own changes to the use case or data types processed, changes in applicable law (new adequacy decisions, enforcement guidance), and contract renewal.
What is a Fundamental Rights Impact Assessment and when is it required?
A FRIA (Fundamental Rights Impact Assessment) is required under the EU AI Act Article 27 for deployers of high-risk AI systems who are bodies governed by public law, or private entities providing public services, financial services, health services, or education services. It assesses the impact of the AI system on fundamental rights: privacy, non-discrimination, freedom of expression, effective remedy. It is distinct from a GDPR DPIA, and both may be required for the same deployment.
If your AI vendor governance program needs a platform that maintains a centralized vendor register, automates due diligence assessments, tracks DPA status, and maps AI systems to EU AI Act risk tiers — Secure Privacy's Privacy & AI Governance Platform covers the full lifecycle from vendor onboarding through ongoing compliance monitoring.
