Gabriel Espinheira
A customer fills in your enquiry form. The record appears in the CRM, an AI step labels the request, and someone on your team gets an alert. It looks like one tidy transaction.
It may have created six copies of the same personal data.
Practical AI automation GDPR work starts by naming every place the data persists, why it is there, who can see it, when it disappears and how you would delete it. Vendor security pages are evidence, but they cannot answer those questions for the workflow you configured.
Before an automation touches customer data, run a data-copy audit. Map the source, execution history, AI provider, destination, retry path and human notification. Then give every stored copy a purpose, an owner, a retention rule and a tested deletion route. A green tick in the run history proves the workflow ran. It does not prove the data trail is controlled.
TL;DR: One AI workflow can leave personal data in more places than the CRM shows. Audit each copy, pass only the fields a step needs, shorten or disable unnecessary histories, and test deletion across the whole chain before live customer data enters it.
Where does an AI automation copy customer data?
Take a common lead-routing flow:
- A visitor submits a name, email address, company and free-text message.
- The form platform stores the submission.
- An automation platform reads the payload and keeps a run history.
- An AI service classifies the enquiry by service and urgency.
- The CRM creates a contact and opportunity.
- A failed step enters a retry queue, or the full message is pasted into an email or team chat alert.
The information can pass through even more places: webhook logs, test runs, spreadsheets, exported histories, error-monitoring tools and backups. Some copies last seconds. Others persist until somebody changes a default setting.
That difference matters. Data moving through memory for a specific step is not the same operational risk as a payload stored in a searchable history. Your first job is to distinguish transit from persistence.
If one enquiry creates five stored payloads, deleting the CRM record deletes one copy.
This is why the audit starts with the workflow you actually built, not the diagram from a vendor's homepage. Open a real execution. Inspect the input and output at each step. Search for the same email address in every connected system. The result is usually less tidy than the boxes and arrows suggest.
Why a successful run history becomes a shadow database
Run histories are useful. When an automation fails at 02:13, the engineer needs enough context to find the bad step and repair it. The problem begins when the easiest debugging setting is “save everything forever”.
A history that stores names, emails, messages and AI outputs is functionally another customer database, even if nobody calls it one. It has records, search, access rules and a retention period. It also tends to receive less scrutiny than the CRM.
The settings are often configurable. n8n's execution-data documentation shows that teams can avoid saving successful runs, keep error runs and prune older executions. Its documented default age at the time of writing is 14 days, with exceptions including waiting and annotated runs. That is a product default, not a GDPR rule.
Zapier's run-history documentation says it guarantees up to 60 days of run data and displays up to 10,000 runs. It also makes an important distinction: deleting the record of a completed run does not undo the action already taken in another system.
The sensible trade-off keeps the smallest useful diagnostic record. Keep the error code, step name, timestamp and internal record ID where those are enough. Do not keep a full customer message merely because it made the first build easier to debug.
Third parties deserve attention too. Verizon's 2025 Data Breach Investigations Report found third-party involvement in 30% of the breaches it analysed, up from roughly 15% in the prior report. The figure covers third-party involvement generally, not AI tools specifically. Every extra service and stored copy expands the system you must understand and protect.
What AI automation GDPR work actually asks you to prove
The GDPR's Article 5 sets the operating principles. Personal data should be limited to what is necessary for the purpose, kept identifiable for no longer than necessary, and protected with appropriate measures. Article 25 extends that thinking to data protection by design and by default, including the amount collected, the extent of processing, storage time and access.
Those principles expose three weak answers that often survive a technical review:
- “The vendor is GDPR compliant.” A supplier's controls do not document the workflow you configured.
- “We keep logs in case we need them.” “In case” is not a retention purpose or a deletion trigger.
- “The AI only classifies the message.” That says what the step does, not which fields it receives or what the provider stores.
The GDPR does not set one universal number of days for every automation log. Retention has to make sense for the purpose and the risk. A failed payment workflow may need a different diagnostic window from an enquiry classifier. Write the reason down. Set a date or event that ends it. Give someone responsibility for checking that the setting still matches the policy.
Using a processor does not outsource the whole decision. The European Data Protection Board's small-business guide says the controller generally retains overall responsibility, while the controller-processor relationship must be governed by a contract that documents the processing. Article 28 also covers sub-processors, support for individual rights and deletion or return of copies when the service ends.
A data processing agreement belongs in many supplier relationships. The workflow map belongs beside it.
Run a six-field data-copy audit
The ICO's practical AI and data-minimisation guidance starts with understanding and mapping every process where personal data may be used. For a small workflow, that map can be one table.
Create one row for every place data can persist and fill in six fields:
| Field | What to record | Bad answer |
|---|---|---|
| Copy | System and exact storage location | “In the automation” |
| Fields | Personal data stored there | “Form details” |
| Purpose | Why this copy must exist | “Just in case” |
| Owner and access | Named owner plus roles that can view it | “The team” |
| Retention trigger | Days, state change or contract event | “Platform default” |
| Deletion route | Exact action and last test date | “Vendor handles it” |
For the enquiry flow, a useful first pass might look like this:
| Copy | Fields kept | Purpose | Retention and deletion |
|---|---|---|---|
| Form submission | Name, email, company, message | Recover a failed hand-off | Delete after CRM creation is confirmed and the recovery window closes |
| Successful run history | Internal record ID, step status | Diagnose recent faults | Do not store the full payload; prune on a short schedule |
| AI request | Enquiry text or reduced features | Classify service type | Check provider settings, contract, region and retention; remove fields the model does not need |
| CRM lead | Contact and enquiry record | Manage the commercial conversation | Apply the CRM retention and deletion process |
| Error alert | Run ID and error summary | Tell the owner where to look | Redact the customer message; expire the alert with the incident record |
| Retry queue | Minimum payload needed to retry | Recover a temporary failure | Delete on success or when the retry window ends |
Do this with a real run, not a recollection of how the workflow was meant to work. Defaults change. A test node can be left active. A colleague can add a spreadsheet export that never appears on the original diagram.
The audit is complete only when someone other than the builder can follow the deletion route. If the answer depends on one person's memory, you have documented a bus factor, not a control.
What to delete, redact or stop logging
Start at the first unnecessary field. An AI classifier deciding “website”, “ads”, “content” or “automation” may need the message and perhaps the current page. It probably does not need the person's phone number, billing address or full CRM history.
Then reduce persistence step by step:
- Pass internal record IDs between systems instead of copying the full record where possible.
- Disable successful-run storage when a timestamp and status counter are enough.
- Keep error context, but redact free text and direct identifiers from team alerts.
- Separate production histories from test data and restrict debugging access.
- Delete exports after the investigation or migration they were created for.
- Check the model provider's retention, training-use, region and sub-processor terms against the actual account configuration.
- Test a deletion request with a seeded record and record the result.
The deletion test is the part most teams skip. Create a test enquiry with a unique address. Let the entire flow finish. Delete it through the normal process, then search the form platform, workflow history, AI traces where available, CRM, alert channel, retry queue and exports.
You may find that one deletion route is manual. That is not automatically a reason to abandon the workflow. It is a reason to name the owner, write the steps and decide whether the response time is acceptable. If the volume grows, automate the deletion process only after the operating rule is clear.
This is how AI automation should enter a business: as a maintained data path with visible decisions, not an impressive demo held together by hidden histories.
When the workflow needs privacy counsel, not another setting
The copy audit is an engineering and operating check. It does not choose your lawful basis or certify compliance.
Bring in your privacy counsel or data protection officer when the flow handles special-category data, monitors people systematically, profiles them at scale, involves children, sends personal data across uncertain jurisdictions, or makes decisions with legal or similarly significant effects. Get advice too when nobody can state the lawful basis clearly or when a data protection impact assessment may be required.
Do not hide those questions inside a build ticket. A platform toggle cannot decide whether the business should process the data in the first place.
The same rule applies to procurement. A polished security page is useful evidence, but you still need to inspect the contract, sub-processors, retention controls, deletion support and the settings available on your plan. If a vendor cannot answer where data goes or how it is removed, the workflow is not ready for live customer records.
The release test before you switch it on
An AI workflow is ready for customer data when the owner can answer yes to these questions:
- Can we list every system where a payload or identifiable output persists?
- Does every stored field have a specific purpose?
- Is each retention period intentional rather than inherited from a default?
- Can we remove one person's data across the whole chain?
- Has somebody other than the builder watched that deletion test pass?
Keep the audit with the rest of the operating record in your workspace. At SharpHaw, that kind of decision trail lives in SharpOS, beside the work rather than in a forgotten policy folder.
The useful finish line is “we can explain its data trail, operate it and delete it”. That is what “Digital work that compounds.” means when the work is an AI automation.
If you have a recurring workflow worth automating, book a focused call. We will map the smallest useful version, including the copies and controls it needs before customer data enters the flow.
