How do you build GDPR-compliant automation?
GDPR-compliant automation means data-residency in EU regions where required, signed DPAs and SCCs with every processor, documented data flows, lawful basis for processing, and retention/deletion that actually runs. It's an architectural decision, not a checkbox, bake it in at design time or pay for a retrofit later.
GDPR compliance for automation comes down to four hard requirements and a handful of soft ones. The hard requirements: data processed in EU regions where residency is contractual; a signed Data Processing Agreement and Standard Contractual Clauses with every sub-processor; documented data flows and retention; and a lawful basis (consent, contract, legitimate interest) for every processing activity.
The soft requirements separate good systems from compliant-on-paper systems. Data minimisation, collecting only what the workflow actually needs. Encryption in transit and at rest, keyed appropriately. Audit logs that survive a regulator's curiosity. Subject access requests that complete inside the deadline (one month) without engineering heroics.
LLM workloads add a wrinkle. Anthropic, OpenAI, and most major providers offer EU-region endpoints with no-training contracts; use them. For sensitive workflows, run open-source models on private infrastructure, Mistral, Llama, Qwen, and keep the data on-shore. Anywhere a customer's PII touches a model that retains training data, you have a problem.
- →What is a Data Processing Agreement (DPA)?
- →Are AI tools GDPR-compliant?
- →GDPR and customer data in n8n / Zapier
- →How to handle subject access requests automatically