AI Vendor Data Processing Agreements: What Should Be Included

When you send data to an AI vendor, you remain responsible for protecting that data under privacy laws. A Data Processing Agreement (DPA) establishes the rules. For AI vendors, DPAs need provisions that standard templates don't include.

Executive Summary

Data Processing Agreements are legally required whenever vendors process personal data on your behalf, as outlined in the PDPC Guide to Data Protection Provisions. Yet standard DPA templates were built for a pre-AI world and consistently fail to address the concerns that make AI vendors fundamentally different from traditional software providers. Model training on customer data, indefinite retention under the banner of "improvement," and cross-border processing through layered cloud infrastructure all introduce risks that generic contracts leave unmanaged.

The most critical gap is sub-processor management: AI vendors routinely depend on a web of third-party services, each of which must be subject to the same data protection obligations. For organizations operating under Singapore or Malaysia's PDPA, these requirements must be addressed explicitly rather than assumed. No AI contract should be signed without a compliant, comprehensive DPA, and every existing DPA should be reviewed annually as both vendor practices and regulatory frameworks evolve.

Why This Matters Now

AI services process data in ways that traditional software simply does not. Customer data may be used to train models that serve other customers entirely, creating a form of data leakage that conventional processing never risked. Retention periods may extend indefinitely when vendors justify keeping data for "improvement" purposes, well beyond what any legitimate processing need would require. Processing routinely crosses national borders through cloud infrastructure, often without the organization's knowledge. And the chain of sub-processors, from cloud providers to external model APIs, adds layers of complexity that a single vendor relationship obscures.

Standard DPAs written for traditional SaaS were never designed to address these realities. Organizations deploying AI vendors need purpose-built provisions that confront each of these concerns directly.

Definitions and Scope

Data Controller: The organization that determines the purposes and means of processing personal data (usually you).

Data Processor: The organization that processes personal data on behalf of the controller (the AI vendor).

Sub-Processor: Third parties engaged by the processor to assist in processing (cloud providers, APIs, etc.).

Data Processing Agreement (DPA): Contract establishing data protection obligations between controller and processor.

Scope of this guide: DPA requirements for commercial AI software/platform vendors processing personal data, not custom development or consulting.

DPA Structure for AI Vendors

Section 1: Scope and Purpose

Every DPA begins with standard elements: a description of processing activities, the categories of data subjects involved, the types of personal data being processed, the stated purpose of processing, and the expected duration. These form the contractual baseline.

What distinguishes an AI vendor DPA is the additional specificity required around how data interacts with models. The following provisions address this gap:

PROCESSING SCOPE - AI SPECIFIC

AI-Related Processing
In addition to providing the Services, Processor may process
Personal Data for the following AI-related purposes only with
Controller's explicit consent:
□ Training machine learning models
□ Improving AI accuracy
□ Benchmarking AI performance
□ Other: [specify]

If no boxes are checked, Processor shall not use Personal Data
for any AI-related purpose beyond direct service delivery.

Processing Limitations
Personal Data shall not be:
- Used to train AI models for third parties
- Aggregated with other customers' data for model training
- Retained beyond service delivery requirements
- Processed for purposes incompatible with those specified

Section 2: Processor Obligations

Standard processor obligations form the foundation: processing only on documented instructions, ensuring personnel confidentiality, implementing appropriate security measures, assisting with data subject requests, notifying breaches, and submitting to audits. These remain essential.

AI vendors, however, carry additional obligations that reflect the unique nature of machine learning systems. Model training controls, data isolation between customers, and algorithmic transparency each require explicit contractual language:

PROCESSOR OBLIGATIONS - AI SPECIFIC

Model Training Controls
Processor shall:
- Maintain technical controls to prevent Personal Data from being
  used in model training without Controller's consent
- Provide Controller with option to opt out of any collective
  learning features
- Document any model training using Controller's data

Data Isolation
Processor shall:
- Logically separate Controller's Personal Data from other customers
- Not commingle training data across customer boundaries without consent
- Maintain audit trail of data usage

Algorithmic Transparency
Upon request, Processor shall:
- Explain in plain language how AI processes Personal Data
- Document decision-making logic affecting data subjects
- Provide information sufficient for Controller to respond to
  data subject inquiries about automated decisions

Section 3: Data Subject Rights Support

Standard requirements already mandate that processors assist controllers with access requests, support correction and deletion, enable data portability, and facilitate restriction of processing. These obligations carry forward unchanged.

Where AI demands additional attention is in the area of automated decision-making. When AI systems make decisions that affect data subjects, the processor must be contractually bound to provide meaningful information about the logic involved, support requests for human review, and enable the controller to explain outcomes. Deletion requests introduce a further complication: the DPA must address whether data was used for model training and, if so, what the practical impact of deletion will be on trained models.

DATA SUBJECT RIGHTS - AI SPECIFIC

Automated Decision-Making
Where AI makes automated decisions affecting data subjects,
Processor shall:
- Provide meaningful information about the logic involved
- Support data subject requests for human review
- Enable Controller to provide explanations to data subjects

Right to Deletion
Upon deletion request:
- Remove Personal Data from active systems within [X] days
- Remove from backups within [X] days
- Confirm whether data was used for model training
- If used for training, explain impact of deletion (or inability
  to fully delete from trained models)

Section 4: Security Measures

Standard security requirements remain the baseline: encryption, access controls, vulnerability management, and incident response. No AI-specific DPA should weaken these foundations.

The additional security surface introduced by AI systems, however, requires its own provisions. AI models face adversarial attacks that traditional software does not, prompt injection represents a novel attack vector, and anomalous outputs may signal compromise before conventional intrusion detection systems respond. Data protection in the AI context also demands techniques such as differential privacy, rigorous data minimization in training sets, and the removal or anonymization of personal data from production models wherever technically feasible.

SECURITY - AI SPECIFIC

AI System Security
In addition to standard security measures, Processor shall:
- Protect AI models from adversarial attacks
- Implement input validation to prevent prompt injection
- Monitor for anomalous outputs indicating compromise
- Secure APIs against unauthorized access

Data Protection in AI Context
- Implement differential privacy or similar techniques where appropriate
- Apply data minimization to AI training sets
- Remove or anonymize Personal Data from production AI models
  where technically feasible

Section 5: Sub-Processors

Standard sub-processor provisions require prior authorization, notification of changes, binding contracts with each sub-processor, and the processor's continued liability for sub-processor actions. These are table stakes.

AI vendors, however, depend on a far more complex chain of sub-processors than traditional SaaS providers. Cloud AI and ML platform providers, external model API providers, data annotation services, and specialized AI infrastructure all constitute sub-processors that must be disclosed and assessed. The DPA should require the processor to evaluate each sub-processor's data handling practices, model training policies, data residency arrangements, and security certifications before engagement. The controller must retain the right to object within a specified timeframe.

SUB-PROCESSORS - AI SPECIFIC

AI Infrastructure Disclosure
Processor shall disclose all AI-specific sub-processors including:
- Cloud AI/ML platform providers
- External model API providers
- Data annotation services
- Specialized AI infrastructure

Sub-Processor Assessment
Before engaging AI-specific sub-processors, Processor shall assess:
- Their data handling practices
- Model training policies
- Data residency and transfer practices
- Security certifications

Controller may object to any sub-processor within [X] days of notice.

Section 6: International Transfers

Standard transfer provisions require identifying destinations, implementing appropriate safeguards, and complying with transfer restrictions. These remain necessary but insufficient for AI.

AI processing introduces transfer complexities that traditional software rarely creates. Model training may occur in jurisdictions different from where data is stored, and the layered infrastructure of cloud AI services can route data through multiple countries without explicit awareness. The DPA must specify processing locations, document transfer mechanisms (whether standard contractual clauses, adequacy determinations, binding corporate rules, or specific consent), and restrict model training locations to approved jurisdictions. For organizations subject to Singapore's PDPA Section 26 or Malaysia's PDPA Section 129, compliance must be explicitly confirmed.

CROSS-BORDER TRANSFERS - AI SPECIFIC

AI Processing Locations
Personal Data may be processed in the following locations:
[List specific jurisdictions]

Transfer Mechanisms
The following transfer mechanisms apply:
□ Standard contractual clauses
□ Adequacy determination
□ Binding corporate rules
□ Specific consent

Model Training Locations
If permitted, model training may occur in: [specify]
Training data shall not be transferred to jurisdictions beyond
those specified without Controller's consent.

SINGAPORE/MALAYSIA PDPA
Processor commits that all cross-border transfers comply with:
- Singapore PDPA Section 26 requirements
- Malaysia PDPA Section 129 requirements (if applicable)

Section 7: Data Retention and Deletion

Standard provisions require the return or deletion of data on termination, impose retention period limits, and mandate secure deletion methods. For traditional software, these are generally sufficient.

AI introduces a retention problem that standard language fails to address. Data used for model training may be retained indefinitely under vague justifications of "potential future use," and deletion from trained model weights may be technically impossible. The DPA must confront these realities directly: training data should be retained only for documented purposes, deleted or anonymized when no longer needed, and never held indefinitely without justification. Upon contract termination, the processor must certify the deletion of personal data from production systems and backups, and must honestly disclose the status of any data embedded in trained model weights.

RETENTION AND DELETION - AI SPECIFIC

Model Training Data
Data used for model training shall be:
- Retained only for documented training purposes
- Deleted or anonymized when no longer needed
- Not retained indefinitely for "potential future use"

Deletion Certification
Upon contract termination, Processor shall certify:
- All Personal Data deleted from production systems
- Backups will be deleted per retention schedule
- Any data used in model training has been [deleted/anonymized/
  remains in trained model weights which cannot be extracted]

Retention Schedule
| Data Category | Retention Period | Justification |
|--------------|------------------|---------------|
| Active service data | During contract | Service delivery |
| Backup data | [X] days post-termination | Business continuity |
| Training data | [specify] | [specify] |
| Logs | [X] months | Security/compliance |

Section 8: Audit and Compliance

Standard audit provisions grant the controller a right to audit, require compliance certification, and mandate cooperation with regulators. These remain the baseline.

AI-specific audit rights must extend further. The controller should be able to audit or assess model training practices, data usage within AI systems, algorithmic decision-making processes, and bias and fairness testing results. The processor must maintain and provide, upon request, records of any personal data used for model training, AI system impact assessments, bias and fairness testing documentation, and model versioning and update records. Without these provisions, meaningful oversight of AI data processing is impossible.

AUDIT AND COMPLIANCE - AI SPECIFIC

AI-Specific Audit Rights
Controller may audit or assess:
- AI model training practices
- Data usage in AI systems
- Algorithmic decision-making processes
- Bias and fairness testing results

Compliance Documentation
Processor shall maintain and provide upon request:
- Records of any Personal Data used for model training
- AI system impact assessments
- Bias/fairness testing documentation
- Model versioning and update records

DPA Review Checklist

AI DPA REVIEW CHECKLIST

Scope
□ All AI processing activities described
□ Model training permissions clearly stated
□ Controller consent requirements for AI use
□ Data categories and subject types specified

Processor Obligations
□ Model training controls specified
□ Data isolation requirements
□ Transparency obligations
□ Instruction compliance

Data Subject Rights
□ Automated decision-making support
□ Explanation capabilities
□ Deletion impact on models addressed

Security
□ AI-specific security measures
□ Adversarial attack protection
□ Input/output monitoring

Sub-Processors
□ AI infrastructure providers listed
□ Assessment requirements
□ Objection rights

International Transfers
□ Processing locations specified
□ Transfer mechanisms documented
□ PDPA compliance confirmed

Retention and Deletion
□ Training data retention limits
□ Deletion certification process
□ Model impact addressed

Audit
□ AI-specific audit rights
□ Documentation requirements
□ Regulatory cooperation

Common Failure Modes

1. Using Generic DPA

The most pervasive failure is relying on standard DPA templates that were never designed with AI in mind. Generic agreements address data storage and basic processing but leave model training, algorithmic transparency, and AI-specific security concerns entirely unaddressed. Every AI vendor DPA should incorporate the AI-specific provisions outlined in this guide.

2. Vague Training Permissions

Ambiguity around whether a vendor can use customer data for model training is the second most common gap. When DPA language is unclear, vendors default to broad interpretations that serve their interests. Explicit opt-in or opt-out provisions eliminate this ambiguity and ensure the controller retains meaningful authority over how data is used.

3. Ignoring Sub-Processors

AI vendors typically depend on a far larger and more complex chain of third-party services than traditional SaaS providers. Failing to require complete sub-processor disclosure leaves the controller blind to where data actually flows and who has access. The DPA must mandate full transparency and provide the controller with objection rights.

4. Inadequate Deletion Provisions

Data embedded in trained AI models presents a deletion challenge that traditional software never posed. If the DPA does not explicitly address the reality that certain data cannot be fully extracted from model weights, both parties operate under false assumptions. Honest, transparent language about what deletion can and cannot achieve is essential.

5. Missing Transfer Safeguards

AI processing routinely crosses borders through layered cloud infrastructure, often without the organization's awareness. Without specified processing locations and documented transfer mechanisms, cross-border data flows proceed without the safeguards that privacy law requires.

FAQ

Q: Is a DPA legally required for AI vendors? A: If the vendor processes personal data on your behalf, yes, under PDPA and similar regulations.

Q: Can I use the vendor's standard DPA? A: Review carefully. Vendor DPAs are often minimal. Negotiate AI-specific additions.

Q: What if the vendor won't negotiate DPA terms? A: For significant vendors, this is a red flag. Consider alternatives. Document the gap in your risk assessment.

Q: How do I handle AI vendors that use my data to train models? A: Either prohibit it contractually, or ensure explicit consent with clear limitations.

Q: What about data that can't be fully deleted from trained models? A: Address this honestly in the DPA. Acknowledge limitations and document mitigation.

Disclaimer

This guide provides general information about Data Processing Agreements and is not legal advice. DPA terms should be reviewed by qualified legal counsel and data protection specialists familiar with your jurisdiction.

Next Steps

AI vendors require DPAs with provisions standard templates don't include. Review your existing AI vendor DPAs against this guide and negotiate enhancements where needed.

Need help with AI vendor data protection agreements?

Book an AI Readiness Audit to get expert guidance on vendor compliance and data protection.