Enterprise + Sovereign AI

What should GDPR reviews ask about an AI API?

A GDPR review of an AI API covers six questions: what personal data enters prompts, which lawful basis applies, who is controller versus processor, where processing and transfers happen, whether data trains models, and how retention, deletion and data subject rights are supported. Get answers as architecture and contract evidence — region maps, subprocessor lists, retention schedules — not just policy prose.

Key facts

RolesCustomer as controller, Plugsky as processor for inference workloads
Transfer mechanismEU Standard Contractual Clauses are referenced in the standard DPA
EU regionseu-west-1 (Dublin) and eu-central-1 (Frankfurt) available for pinning
Rights supportAssistance with access, deletion and portability requests
Training useContractual limits on using customer data for model training; confirm wording
RetentionReturn and deletion commitments on termination, including derived data
Breach termsNotification and cooperation duties documented in the DPA
Compliance postureSOC 2 Type II and ISO 27001 readiness in progress (not yet certified)

TL;DR

  • Decide whether prompts contain personal data before debating residency.
  • Pin an EU region if transfers are the blocker, and verify it in configuration.
  • Ask for the training-use clause and the technical control behind it.
  • Make deletion cover prompts, embeddings, logs and backups.
  • Test a data subject request end to end during the pilot.

How it works, step by step

  1. Map data flows: what enters prompts, what is logged, what is embedded, what is retained.
  2. Confirm the lawful basis for each processing purpose in your record of processing.
  3. Verify controller-processor roles and sign the data processing terms.
  4. Choose an EU region and evidence it with a workspace configuration export.
  5. Check subprocessors, their locations and the change-notification process.
  6. Agree retention and deletion for every store, including vector collections.
  7. Rehearse a DSAR and a deletion request before go-live.
1Map data flows:what entersprompts, what is2Confirm the lawfulbasis for eachprocessing purpose3Verifycontroller-processorroles and sign the4Choose an EU regionand evidence itwith a workspace5Checksubprocessors,their locations and6Agree retention anddeletion for everystore, including

Try it yourself

Open the AI data residency checklist →

The six questions that decide the review

  • Scope: does personal data enter prompts, files or embeddings, or only metadata? This determines everything downstream.
  • Basis: which Article 6 basis covers each purpose, and is a DPIA required for the processing?
  • Roles: confirm controller and processor responsibilities and where joint-controller situations arise.
  • Transfers: where does processing, storage, logging and support access occur, and what mechanism legitimises each transfer?
  • Training: can the vendor use your inputs or outputs to improve models, and what enforces the limit?
  • Lifecycle: retention periods, deletion of primary and derived data, and how rights requests are supported.

Residency is an architecture question

A DPA clause does not keep data in Europe; configuration does. Ask for a store-by-store map covering inference, prompt logs, embeddings, backups and support access, then choose the EU region that satisfies the requirement and verify it with a configuration export. Failover deserves explicit attention because it is a common source of unintended transfer. If absolute in-region processing is required, plan capacity and secondary deployments inside the jurisdiction rather than relying on routine failover, and consider VPC or on-prem deployment where the data path itself is in scope for audit.

Training use, retention and rights

The AI-specific clauses carry the most risk. Require explicit wording that limits use of customer data to providing the service, ask how that limit is technically enforced and audited, and confirm it flows down to subprocessors and upstream model providers. Retention should be specified per store, and deletion should cover prompts, completions, logs, derived embeddings and backups, with evidence you can file. Data subject rights need an operational path: how access, rectification, erasure and portability requests reach the vendor, within what timeframe, and what the customer is responsible for. Rehearse one DSAR and one deletion in the pilot; process gaps surface there, not in the contract review.

Evidence to collect for the file

  • Region and workspace configuration exports.
  • Subprocessor list with locations and change-notification terms.
  • Retention schedule and deletion certificate sample.
  • Training-use clause and the mechanism enforcing it.
  • Security control descriptions and current certification status.
  • Incident notification path and escalation contacts.

Contractual positions should be taken from the signed terms and SLA — /legal/terms and /legal/sla — with the DPA and enterprise addenda attached. Plugsky's certification status is readiness in progress rather than completed, so record that as a tracked risk with milestones rather than assuming certification.

Honest comparison

GDPR concernPlugskyHyperscaler AI platformSelf-hosted model
EU residencyeu-west-1 and eu-central-1 pinningMultiple EU regionsYour own data centre
Transfer mechanismSCCs referenced in the standard DPASCCs and cloud transfer frameworksNot applicable
Training useContractual limits; confirm current wordingVaries by service and opt-outFully in your control
SubprocessorsPublished list with change notificationPer-service subprocessor pagesYou contract suppliers
Deletion evidenceReturn and deletion on terminationVaries by serviceYour procedures
Certification statusSOC 2 / ISO 27001 readiness in progressCompleted audits in many regionsYour own audit programme

Frequently asked questions

Is Plugsky a processor under GDPR?

For inference workloads the customer is generally the controller and Plugsky the processor, with terms set out in the data processing documentation and the platform terms at /legal/terms. Confirm the mapping for each use case with counsel.

Can data stay in the EU?

Yes. eu-west-1 (Dublin) and eu-central-1 (Frankfurt) can be selected and pinned per workspace, and data stays in the pinned region. Verify the configuration in your own environment before relying on it.

What transfer mechanism applies?

The standard DPA references EU Standard Contractual Clauses for cross-border transfers, with subprocessor terms attached. Review the current DPA and terms for your specific data flows.

Can we stop our data being used for training?

The terms define how customer data is handled. Ask for explicit wording limiting use to service provision, document it in your diligence file, and confirm it applies to subprocessors.

Are embeddings covered by deletion requests?

They should be. Vectors are derived data and must be deleted with the source. Verify that deletion procedures cover vector stores and backups, not only primary storage.

Does Plugsky support data subject rights?

The DPA documents assistance with access, deletion and portability requests, with the customer handling user-facing requests. Test the collaboration path during the pilot.

What is the breach notification path?

The DPA documents notification and cooperation duties. Verify the operational escalation path from the vendor to your security team, not just the legal clause.

Is Plugsky GDPR certified?

There is no such certification. Plugsky aligns with GDPR and documents SOC 2 Type II and ISO 27001 readiness in progress; record certification status as pending and verify evidence during diligence.