Enterprise + Sovereign AI

What should you check in an AI API data processing agreement?

Check an AI API DPA for seven things: the controller-processor roles, the subprocessor list and change-notification terms, cross-border transfer mechanisms, limits on using your data to train models, retention and deletion commitments, breach notification timelines with cooperation duties, and audit rights. AI adds clauses that classic SaaS DPAs miss — prompt and completion handling, embeddings, and log retention — so read those sections explicitly.

Key facts

Standard DPAGDPR Article 28 controller-processor terms, EU SCCs, PDPL alignment, SOC 2 attestation commitments
SubprocessorsPublished list plus change notification and objection rights
Breach terms72-hour breach notification and cooperation duties
Rights supportData subject access, deletion and portability assistance
Retention and deletionData return and deletion on termination, with evidence
Audit rightsAnnual and on-cause audit rights; enterprise addenda negotiable
Deployment and residencyRegion-locked planes: EU, GCC, APAC, US; cloud, VPC, on-prem, air-gapped
Compliance postureSOC 2 Type II and ISO 27001 readiness in progress (not yet certified)

TL;DR

  • Confirm roles and scope first: what data, which purposes, and who is controller.
  • Get the subprocessor list with locations, change notice and a real objection right.
  • Check transfer mechanisms if any processing or support crosses borders.
  • Read the AI-specific clauses: training use, prompts, embeddings, logs and retention.
  • Make deletion and audit rights operational, with evidence you can collect, and negotiate enterprise addenda for liability and localization.

How it works, step by step

  1. Map your data flows: prompts, completions, embeddings, logs, support access and backups.
  2. Confirm the roles section reflects your actual relationship and legal obligations.
  3. Review subprocessor terms, locations and change-notification windows against your risk tolerance.
  4. Check the training-use clause and the mechanism that enforces it.
  5. Verify retention schedules and deletion procedures for every store, including vectors.
  6. Test the breach notification path and audit rights against your incident playbook.
  7. Negotiate addenda for liability caps, localization and exit assistance where needed.
1Map your dataflows: prompts,completions,2Confirm the rolessection reflectsyour actual3Review subprocessorterms, locationsand4Check thetraining-use clauseand the mechanism5Verify retentionschedules anddeletion procedures6Test the breachnotification pathand audit rights

Original data

GDPR Article 2Standard DPA72-hour breachBreach termsSOC 2 Type II Compliance postureSource: Plugsky facts table · updated 2026-09-25

Try it yourself

Open the AI data residency checklist →

The standard clauses — and where AI changes them

Classic DPA sections still apply: roles, purposes, security, subprocessors, transfers, rights, breach and deletion. AI changes the surface area. Prompts and completions may contain personal data even when you did not intend it. Embeddings are derived data that must also be deleted. Logs may retain content by default. Support engineers may access conversations. Read each section with these stores in mind, and confirm defaults rather than assuming them.

Training use and model improvement

The single most important AI-specific clause is what the vendor may do with your data beyond providing the service. Ask for an explicit limitation on training and model improvement, the technical mechanism enforcing it, and how it is audited. If opt-outs exist, understand what they cover — inference inputs, logs, feedback data — and whether subprocessors are bound by the same restriction. Plugsky's platform processes customer data to provide the service; confirm the current contractual wording at /legal/dpa and /legal/terms for your diligence file.

Transfers, residency and subprocessors

Residency commitments in a DPA should match the architecture. Check where each store lives, which subprocessors or upstream model providers process data, and what mechanism supports any cross-border transfer — for example EU Standard Contractual Clauses, which the standard DPA references. If you selected a region-locked plane, the DPA should not quietly permit routine processing elsewhere. Failover and support access deserve explicit treatment because they are common sources of unintended transfer.

Operationalising audit and deletion

  • Confirm what evidence you receive for audits: control descriptions, reports, logs, certificates.
  • Agree deletion timeframes and the certificate you receive at termination.
  • Verify that deletion covers prompt history, embeddings, logs and backups, not just primary storage.
  • Record the escalation path for rights requests, including response targets.
  • Rehearse a deletion request in the pilot so process gaps surface early.

Common pitfalls

Signing a strong DPA that the architecture contradicts is the most damaging pattern: localized language with global log replication. The second is accepting a subprocessor list without locations or change notice. The third is an unfunded deletion obligation — a commitment with no operational path. The fourth is forgetting that audit rights need practical scope, notice periods and cooperation duties to be useful. Validate each with the security and legal teams before signature.

Honest comparison

CapabilityPlugskyHyperscaler AI platformBuilding in-house
Standard DPAPublished with GDPR Art. 28, SCCs and PDPL alignmentStandard enterprise DPAsYou draft and negotiate
Subprocessor termsList with change notification and objectionPer-service subprocessor pagesYou contract each supplier
Training-use limitsContractual limits; confirm wording for your fileVaries by service and opt-outFully in your control
Deletion evidenceDocumented return and deletion on terminationVaries by serviceYour procedures
Audit rightsAnnual and on-cause, with enterprise addendaStandard audit provisionsNot applicable
Residency alignmentRegion-locked planes selectable per workspaceRegion configuration per serviceYour design

Frequently asked questions

Does Plugsky publish a DPA?

Yes — a standard DPA covering GDPR Article 28 terms, EU SCCs, PDPL alignment, subprocessors, breach notification, audit rights and deletion is published at /legal/dpa, with bespoke addenda for Enterprise.

Can we prohibit training on our data?

The DPA and terms define how customer data is handled. Ask for explicit wording that limits use to service provision, and document it in your diligence pack before signing.

What breach notification timeline applies?

The standard DPA references 72-hour breach notification with cooperation duties. Confirm the exact clause and how notification reaches your security team operationally.

Are embeddings covered by deletion obligations?

They should be. Derived data such as vectors is still your data; verify that deletion procedures cover vector stores and backups, not only primary storage.

How do subprocessor changes work?

The DPA includes the subprocessor list and change notification. Review objection windows and the process for raising concerns before a change takes effect.

What audit rights exist?

Annual and on-cause audit rights are documented, with bespoke addenda available for Enterprise. Agree evidence formats and notice periods so the right works in practice.

Does the DPA cover residency?

Residency is implemented in the platform through region-locked planes and workspace selection; the DPA and SLA provide the contractual frame. Make sure the two match for your workload.

What is covered by enterprise addenda?

Liability caps, data localization, subprocessor restrictions, enhanced audit rights and termination rights for material breach are negotiable in Enterprise addenda.