Data privacy in automation

Automation moves data between tools faster than humans do — which means mistakes scale too. This guide is for small businesses wiring agents or scripts into email, forms, and documents. It is not legal advice; it is an engineering-minded checklist we use before build time, aligned with GDPR-minded practice (lawful basis, minimisation, transparency, rights).

Map the data flow first

Draw a one-page diagram: source → automation → destination → logs. For each hop, note:

Does it contain PII (names, emails, addresses, IDs)?
Does it contain special category data (health, union, biometric)? If yes, stop and get legal review.
Who is controller vs processor for each vendor?
Where are logs stored and for how long?

If you cannot draw the diagram, you are not ready to automate — you are ready to discover leaks.

Minimise what the automation sees

Field filtering — webhooks pass only what the next step needs; drop attachments by default.
Redaction — strip signatures and quoted threads before sending to a model.
Sampling — in pilot, process a subset of traffic until error rates are known.
Local paths — for confidential PDFs, index on-prem; cloud APIs only with explicit sign-off.

Our private and local setups exist for teams where minimisation is not enough and data must not leave the network.

Retention and deletion

Automations create copies: vector indexes, prompt logs, CRM notes, Slack messages. For each store:

Purpose — why is this copy needed?
TTL — delete or roll off after N days unless compliance requires longer.
Subject rights — can you find and delete one person's data across stores?

On papsbot.com, contact form data goes through Formspark to our inbox — see privacy notice. We keep submissions as long as needed to respond, then delete on request. Your automations should document the same for your customers.

Subprocessors you should disclose

Typical small-team stack:

Hosting/CDN — e.g. Cloudflare for static sites.
Form handling — e.g. Formspark for contact capture.
Email — Google Workspace, Microsoft 365, or transactional provider.
Model provider — if used; note region, training opt-out, zero-retention options.
Ads — Google AdSense on this site only after cookie consent; see cookie policy.

List these in your privacy notice before turning the automation on. Update the list when you add a webhook.

Lawful basis (GDPR-minded SMB)

Common bases for B2B automation:

Contract — processing needed to deliver your service.
Legitimate interest — internal ops with balancing test documented.
Consent — marketing mail, optional cookies, some analytics.

Document your choice in one paragraph per workflow. If you rely on consent, make withdrawal as easy as signup.

Human review is a control, not a disclaimer

Supervised agents reduce risk because a person sees outbound content before it leaves. Log what the model proposed vs what the human sent — useful for quality tuning and incident review. Do not log full card numbers or passwords; block those fields at ingress.

Security basics that pair with privacy

Secrets in env vars or a vault — never in repo or Notion pages.
Rotate API keys when someone leaves the team.
Least-privilege OAuth scopes on mail and CRM.
Encrypt laptops that hold local indexes.
Incident contact — who disables the webhook at 2am.

PII in common automation patterns

Inbox triage — mail headers and bodies contain names, emails, and sometimes payment references. Index only approved folders; exclude attachments until you have a virus scan and retention policy. Lead routing — forms collect contact details; pass the minimum fields to Slack or CRM, hash or drop fields you do not need. Doc summarisation — contracts may include personal addresses and financial terms; use private workspaces, restrict who can upload, and watermark outputs as drafts.

For EU/UK customers, document lawful basis and honour access/deletion requests across every store the automation touches — not just your CRM. A deletion in the CRM but not in the vector index is a common gap.

Formspark and contact flows

If you capture leads via a form processor like Formspark (as we do on papsbot.com/contact), list Formspark as a processor in your privacy notice, note what fields you collect, and define retention. Form submissions often sit in a third-party dashboard as well as your inbox — include both in deletion procedures. Turn off fields you do not need; every extra input is data you must justify and protect.

Data Processing Agreements

Vendors that process personal data on your behalf should offer a DPA. Read annexes for subprocessor lists and breach notification timelines. For small pilots, a lightweight email trail confirming roles may suffice; for regulated clients, get signatures before processing their customers' data. Keep a table of processors with purpose, data types, and review date — update when you add a webhook.

Incident response in one page

Write a one-page runbook: who disables the automation, who notifies affected people, who preserves logs, and who speaks to customers. Test it once with a tabletop scenario ("API key leaked in Slack"). Automations amplify leaks — a misconfigured CC on a mail rule sends more copies than a human would.

Include vendor support contacts and account IDs in that runbook. During an incident you should not hunt through billing email to find your Cloudflare or form processor login. Store break-glass credentials in your vault with read access for at least two people on the ops team. Review that list quarterly.

Readiness check and browser storage

Our readiness check stores answers in sessionStorage until you contact us — documented in the cookie policy. It is not sent to our servers until you submit the form. Mirror that pattern: client-side prep is fine; surprise uploads are not.

Checklist before go-live

Data-flow diagram reviewed by someone who owns customer relationships.
Privacy notice updated with new subprocessors and purposes.
Retention TTL set on logs and indexes.
PII fields blocked or redacted at ingress.
Human checkpoint on outbound customer communication.
Deletion procedure tested once.
DPA signed where vendors require it.

Cross-border transfers

If your model provider, CRM, or form processor stores data outside your customers' country, document the transfer mechanism (Standard Contractual Clauses, adequacy decision, or explicit consent where appropriate). Small teams often assume "everyone uses US cloud" — your enterprise client may not. Ask vendors for their DPA and data region settings before the pilot, not after signatures.

Keep a living record of every webhook and API key: what data fields pass through, which account owns the integration, and when it was last reviewed. Quarterly reviews take thirty minutes and prevent "shadow automations" started by former employees. When someone leaves, revoke keys the same day — automations are a common forgotten access path.

Publish a short privacy addendum for each live automation: what it processes, why, where data is stored, and how to request deletion. Customers and regulators ask simpler questions when the answer is one link, not a scavenger hunt across Slack and Notion.

Next steps

Privacy constraints often push teams toward supervised agents or local setups instead of full-cloud processing. Tell us about your data boundaries when you reach out — we scope around them.

Attach your data-flow sketch to the contact form if you have one — boxes and arrows are enough. We respond within two business days with whether a supervised pilot, local index, or script-only path fits before any build time is booked. No customer data leaves your tools until that plan is written down, agreed with your team, and dated.