GDPR-Compliant AI Automation: A Data-Privacy Playbook for Small Businesses

Start with a lawful basis, not a tool

The first GDPR question is never “which model should we use.” It is “are we processing personal data, and if so, on what legal ground.” Personal data is anything that identifies a living person directly or indirectly — a name, an email, an order history, even an IP address. The moment an automation touches that, GDPR applies, and Article 6 requires you to pin one of six lawful bases to each processing purpose: consent, performance of a contract, a legal obligation, vital interests, a public task, or legitimate interests.

For most small-business automations the realistic bases are contract (you are fulfilling an order or a service the customer asked for), legitimate interests (lead qualification, fraud screening, internal analytics), or consent (marketing). If you rely on legitimate interests, document a short balancing test that weighs your interest against the person’s rights — the regulator expects to see it, not just hear that you considered it. Crucially, purpose limitation (Article 5) means the basis you collected data under constrains how you may reuse it. Feeding existing CRM records into an LLM for a brand-new purpose is fresh processing; check it is compatible with the original purpose, or establish a new basis and update your privacy notice.

One trap deserves a flag. Article 22 restricts decisions based solely on automated processing that produce legal or similarly significant effects on a person — think automated loan refusal or hiring rejection. Keep a meaningful human in the loop on consequential decisions and you stay clear of those extra requirements. A short AI systems audit is the cheapest way to confirm which of your automations touch personal data and which lawful basis each one stands on before you build anything.

Map your data with an Article 30 record

You cannot redact, retain, or delete data you have not mapped. Article 30 requires controllers to keep a Record of Processing Activities (a ROPA): what data you process, why, who you share it with, where it goes, and how long you keep it. Many small businesses assume the “fewer than 250 employees” line exempts them — it does not, in practice. The Article 30(5) exemption falls away if the processing is likely to result in a risk to people’s rights, is not occasional, or includes special-category data. An automation that runs continuously against customer records is the definition of “not occasional,” so most automated pipelines need a record regardless of headcount.

Keep it lightweight but real. For each automation, write down the processing activity and purpose, the categories of data and data subjects, the recipients (and yes, the LLM vendor is a recipient), any transfers outside the EEA, the retention period, and the security measures. This single document becomes the backbone for every later control: redaction maps reference the data categories, retention jobs reference the periods, and access requests reference the recipients. A structured intake like the automation requirements document template is a natural home for the data-mapping section, so privacy is captured at design time instead of bolted on after launch.

Minimize and redact PII before the LLM sees it

Data minimisation (Article 5(1)(c)) is the most powerful privacy control you have, and it is entirely under your control. The principle is simple: process only data that is adequate, relevant, and limited to what the purpose needs. Applied to an LLM step, that means the model should receive the minimum personal data required to do its job, and frequently that is far less than the raw record contains.

Three techniques cover most cases. Field selection sends only the columns the model needs and drops the rest at the source. Pseudonymisation replaces direct identifiers (name, email, phone) with reversible tokens, so the model reasons over {{NAME_1}} while you re-map the real values into the final record afterwards. Redaction strips personal data out of free-text fields — an email body or a support ticket — using a regex plus named-entity pass before the API call. In n8n this is a dedicated transform node placed before the LLM node, never after. Pseudonymised data is still personal data if it can be re-identified (Recital 26), so this is not a magic exemption, but it sharply reduces what the processor ever holds and shrinks your exposure if anything goes wrong. The field map below is a concrete starting point you can adapt per workflow.

# pii-redaction map — applied in n8n BEFORE the LLM node
# drop     = removed entirely, never sent to the model
# mask     = replaced with a fixed placeholder string
# tokenize = swapped for a reversible token, restored after the response

fields:
  full_name:      tokenize    # -> {{NAME_1}}, restored on output
  email:          tokenize    # -> {{EMAIL_1}}
  phone:          mask        # -> "[REDACTED_PHONE]"
  national_id:    drop        # the model never needs it
  card_number:    drop        # payment data, never to an LLM
  health_notes:   drop        # special category (Art. 9)
  postal_address: mask
  free_text_body: ner_redact  # regex + NER strips names, emails, IDs inline

post_process:
  restore_tokens: true        # re-insert real values into the stored record only
  log_pii:        false       # never write raw PII into run logs

Your LLM vendor is a processor: DPAs, sub-processors, transfers

When you send personal data to OpenAI or Anthropic, you are the controller and the vendor is your processor. Article 28 says you must have a written contract — a Data Processing Addendum (DPA) — that binds the processor to act only on your instructions, keep the data secure, help with data-subject requests, and delete or return data at the end. Both OpenAI and Anthropic publish DPAs you can execute; signing one is not optional paperwork, it is the legal mechanism that makes the whole arrangement compliant.

Two clauses matter most. Training: there is a sharp line between consumer products and the API. Anthropic’s commercial terms state it will not train models on customer content from its services, and OpenAI states that data submitted through its API and business products is not used to train its models by default. The free consumer apps can behave differently, which is exactly why business automations should run on API or enterprise plans, not someone’s personal ChatGPT login. Sub-processors: your processor uses its own sub-processors (cloud hosting, for example). Article 28 requires you to authorise them and requires the same obligations to flow down, so check the vendor’s sub-processor list and change-notification terms.

Then there is the transfer question, since both vendors are US-based. Chapter V of the GDPR governs sending personal data outside the EEA. Transfers to the United States are lawful where the recipient is certified under the EU-US Data Privacy Framework, whose adequacy decision took effect on 10 July 2023 and was upheld by the EU General Court on 3 September 2025; otherwise you rely on Standard Contractual Clauses, which the major vendors also offer in their DPAs. Check which mechanism your vendor uses and whether they offer EU data residency. Finally, retention at the processor: OpenAI retains API inputs and outputs for up to 30 days for abuse monitoring unless you use a Zero Data Retention endpoint, after which they are deleted in the ordinary course (a legal hold can override this, as the NYT litigation showed); choosing a no-retention path makes erasure dramatically simpler because there is nothing left at the vendor to delete. Document these decisions in the governance layer described in the small-business automation governance policy.

Retention, deletion, and DSARs that survive automation

Storage limitation (Article 5(1)(e)) sounds easy until you notice how many copies an automation creates. A single lead can exist in the web form’s database, in n8n’s execution history, in the LLM provider’s short-term logs, in your CRM, and in last night’s backup. Each is a copy you must retain consistently and delete consistently, or you will keep data you swore you had erased.

Set a retention period per data category, then enforce it with a scheduled cleanup. Configure n8n to avoid saving sensitive payloads in execution data, or to prune that history quickly, so your own logs do not become a shadow database of personal data. Where the vendor offers no-retention processing, use it, because it removes one of the copies entirely.

Then there are data-subject rights. Article 15 gives people the right to access a copy of their data, and Article 17 the right to erasure, and Article 12(3) gives you one month to respond. You can only honour either if you mapped where the data lives. Build a small lookup that takes an identifier (an email or customer ID) and finds every record across your stores; for an access request it exports a copy, and for erasure it deletes locally and asks the processor to purge. The config below shows both retention and the request workflow as one policy you can version-control.

# retention-policy.yml — enforced by a scheduled n8n "cleanup" workflow
retention:
  lead_records:        180d   # delete unconverted leads after 6 months
  invoice_data:        7y     # tax/legal obligation overrides minimisation
  n8n_execution_logs:  7d     # short; strip PII from saved payloads
  llm_request_cache:   0d     # zero retention; never cache prompts with PII
  backups:             35d    # rolling; re-apply erasures after any restore

dsar:
  lookup_keys: [email, customer_id]    # search every store by these
  on_access:   export_json             # Art. 15 — provide a copy
  on_erasure:  delete + processor_purge  # Art. 17 — local delete + vendor purge
  sla_days:    30                      # respond within one month (Art. 12(3))

A 7-step GDPR compliance runbook

Run these in order the first time you take an automation near real personal data. Each step produces an artifact you can show a regulator or a worried customer.

1. Inventory the data. Build or update the Article 30 record for this workflow: data categories, subjects, purpose, recipients (including the LLM vendor), transfers, retention, and security. If you cannot list the data, stop here.
2. Pin a lawful basis per purpose. Choose one Article 6 basis for each processing purpose and write down why. If it is legitimate interests, attach a short balancing test; if it is consent, confirm how consent is captured and withdrawn.
3. Minimize and redact before the model. Add a transform node ahead of the LLM that drops, masks, or tokenizes personal data per your field map. Send the smallest payload that still lets the task succeed.
4. Sign DPAs and verify transfers. Execute a Data Processing Addendum with each vendor, confirm the no-training terms, check the sub-processor list, and confirm the transfer mechanism (Data Privacy Framework certification or Standard Contractual Clauses).
5. Set retention and auto-deletion. Define a retention period per data category and schedule deletion across every store — source app, n8n logs, output database, and backups. Prefer zero retention at the vendor.
6. Wire in access and erasure. Build a lookup keyed on email or customer ID that can export a person’s data for an access request and delete it (plus request a processor purge) for an erasure request, within the one-month deadline.
7. Secure and monitor. Encrypt in transit and at rest, scope API keys and store access to least privilege, keep PII out of logs, and run a Data Protection Impact Assessment where the processing is high-risk. Document the lot in your governance policy.

Worked example: a GDPR-safe lead-intake automation

Consider a common build. A website contact form feeds n8n, an LLM summarises and scores each enquiry, and the result lands in the CRM with a Slack ping to sales. The raw enquiry contains a name, email, phone, company, and a free-text message that often includes more personal detail than the form fields suggest. Here is how the controls apply in sequence.

Basis and notice. The lawful basis is legitimate interests for qualifying an inbound enquiry, supported by a clear line in the privacy notice that submissions are processed with automated tools and named sub-processors; marketing follow-up is gated behind a separate consent checkbox. Minimise and redact. Before the LLM node, a transform drops the phone number (the scoring model does not need it), tokenizes the name and email to {{NAME_1}} and {{EMAIL_1}}, and runs a named-entity pass over the message body so any stray identifiers are masked. The model receives the company, the tokenized fields, and a cleaned message — enough to summarise and score, and nothing more.

Process and restore. The LLM returns a summary and a priority score referring to the tokens; n8n restores the real name and email only when writing the final CRM record, so the provider never held the plain identifiers in a way that could be logged against them. Vendor terms. The workflow runs on the vendor’s API under a signed DPA with no-training terms and a verified transfer mechanism, with zero data retention enabled on the endpoint. Retention and rights. Unconverted leads auto-delete after 180 days, n8n execution data is pruned after 7 days with PII stripped from saved payloads, and a small DSAR workflow can find this person by email across the form store, the CRM, and backups to export or erase their record within a month. The same discipline scales to heavier pipelines such as an AI document-processing workflow, where redaction and retention matter even more because the documents themselves are dense with personal data.

What other experts say

Pre-launch checklist for a GDPR-safe automation

• Open one real test run. Confirm the redaction node fires before the LLM node and that no plain name, email, or phone appears in the payload the model actually receives.
• Grep your saved logs for PII. Export one n8n execution and search it for a real email; if identifiers show up, disable saving execution data for that workflow or prune the history to a few days.
• Counter-sign a DPA per vendor. Execute the Data Processing Addendum for every model provider in the flow and file the signed copy beside your Article 30 record so you can produce it on demand.
• Pin the transfer mechanism in writing. Check each US vendor lists EU-US Data Privacy Framework certification or attaches Standard Contractual Clauses, and note which one applies to which vendor.
• Switch eligible endpoints to zero retention. Turn on no-retention processing where the vendor offers it so there is nothing left at the provider to chase when an erasure request arrives.
• Test the DSAR lookup end to end. Feed it one real identifier and confirm it can both export and delete that person across the form store, CRM, n8n logs, and backups.
• Watch one deletion cycle run. Trigger the scheduled cleanup and verify records past their retention window actually vanish from every store, not just the primary database.

GDPR automation readiness card