AI data privacy checklist before connecting an AI workflow

An AI data privacy checklist should show the path each field takes before customer data reaches an AI service. For one WordPress workflow, list the fields, remove identifiers the model does not need, record every destination and reader, then define retention and deletion checks before you connect production data.

Build the AI data privacy checklist around one workflow

Start with one transaction, not every system your business uses. The illustrative workflow in this series is a WordPress enquiry form that sends data to a workflow service, minimizes the model-bound message, and returns one controlled route: sales, support, billing, partnership, careers or manual_review.

The form has five illustrative inputs or local context fields:

• submission_id: a site-generated identifier used to correlate the submission and later processing.
• contact_address: the customer's email address in this demo, used for a later human response.
• message: the free-text enquiry the classifier needs to read.
• department: a controlled form field used by the routing workflow.
• customer_status: local business context for staff, such as whether the sender already has an account.

In the companion workflow, WordPress sends submission_id, department and message to a workflow webhook before the model call. The model returns a classifier object with three required fields: route, review_reason and a short free-text summary. The companion workflow saves that exact classifier output in the WordPress review queue.

The summary is derived from message, so treat it as another data copy. If an identifier survives the pre-send transform, model-written text may repeat it. Routing WordPress enquiries with AI and a review queue owns the later routing and review-queue step.

Remove identifiers before the model request

AI data minimization means sending the smallest set of fields that can still complete the task. For this classifier, the contact address and customer status are not needed in the model request.

Keep those fields in WordPress if staff need them. Do not place them in the model request merely because they are available.

Free text needs separate treatment. A customer can type an email address, phone number, order number or another identifier into message. A field-level rule that excludes contact_address does not remove identifiers embedded in the message.

Use synthetic identifiers in realistic formats for the test. A safe illustrative email is test-alpha@example.com; RFC 2606 reserves example.com, example.net and example.org for examples. Use a fake order number that follows your store's actual pattern. For example, if your store uses ORD-#####, an illustrative value is ORD-90421.

In this workflow, the raw synthetic message reaches the workflow service first. Apply the pre-send transform there before the model request. The expected model-bound payload has the synthetic email address and order number absent or replaced by fixed placeholders, while the remaining text still carries the routing intent.

That transform does not erase the raw message from workflow execution history. It also does not remove a later model-generated summary from the copies saved by the workflow. Map both separately and set their retention on purpose.

Do not call redacted text anonymous unless a qualified privacy review supports that claim for your use case. Removing one identifier can still leave other details that point back to a person or business.

Complete a field-by-field workflow map

The table below is a completed illustrative map for the synthetic form. Its local retention choices are sample policy decisions, not defaults or legal requirements. Replace them with your own approved periods.

For self-hosted n8n, the current execution environment-variable documentation (opens in a new tab) lists EXECUTIONS_DATA_SAVE_ON_SUCCESS=all, EXECUTIONS_DATA_SAVE_ON_ERROR=all and EXECUTIONS_DATA_SAVE_MANUAL_EXECUTIONS=true as defaults. It also lists EXECUTIONS_DATA_PRUNE=true and EXECUTIONS_DATA_MAX_AGE=336, measured in hours.

The manual-execution setting matters during testing. An execution started by a user in the editor can be saved even when you are focused on successful production executions.

EXECUTIONS_DATA_SAVE_ON_SUCCESS is instance configuration. If you only want to change this workflow, n8n's Workflow Settings (opens in a new tab) include separate controls for saving failed production executions, successful production executions and manual executions.

For the illustrative model provider, the current OpenAI API data controls (opens in a new tab) say data sent to the API is not used to train or improve OpenAI models unless the customer explicitly opts in. The same page says abuse-monitoring logs may contain customer content such as prompts and responses and are retained for up to 30 days by default, subject to the stated exceptions.

The page lists application-state retention separately by endpoint. The Responses API has a 30-day application-state retention period by default, or when store=true, subject to the exceptions on that page. Chat Completions lists no application-state retention apart from its stated exceptions.

The n8n OpenAI Chat Model documentation (opens in a new tab) says the node uses Chat Completions unless Use Responses API is enabled. Responses also supports persistent conversations through a conversation ID. Record the endpoint your node calls, any store setting the request sets, and any conversation setting in the provider row.

Those are provider statements. A request trace can prove which fields your integration sent, but it cannot prove provider-side handling after receipt. Record the provider page, review date, and signed terms or data-processing agreement for your account. Recheck the row if the product, endpoint, account type or provider changes.

Record access at every copy

Access belongs in the map because a private data store can still be too widely available inside the business. On WordPress, assign the review screen to the smallest staff group that needs it.

WordPress roles and capabilities (opens in a new tab) are the normal permission model for controlling what users can do. A custom review queue can use a dedicated capability rather than assuming every administrator, editor or shop role needs access.

Record workflow-service access separately. The WordPress reviewer and the person who can inspect an n8n execution may be different people, and execution history can contain fields and model output that other staff never need to see.

OWASP's LLM prompt injection prevention guidance (opens in a new tab) recommends least privilege for AI applications, including minimal permissions and restricted API scopes. Prompt-injection testing belongs in the separate assistant test plan.

For each destination, write down:

• which account or system identity sends the data;
• which staff roles can read the stored copy;
• which workflow-service accounts can inspect execution history;
• which service provider receives it;
• whether logs, traces or execution records make another copy;
• who can change the retention or logging setting.

If a standard plugin cannot enforce the field boundary, access rule or deletion path you need, custom WordPress plugin development can make those controls explicit in the site rather than relying on staff memory.

Define retention before you create the copy

An AI data retention checklist needs one line for every place data can persist. "The provider does not train on our data" does not answer how long a prompt, output, workflow execution, log or support record remains stored.

For each copy, record four things: the reason for keeping it, the deletion trigger, the person or system responsible for deletion, and the evidence that lets you check the deletion path.

Do this separately for:

• the original WordPress submission;
• the workflow-service execution history;
• any transformed request body;
• model-provider abuse-monitoring logs;
• model-provider application state for the endpoint and settings you use;
• the returned classifier object, including review_reason and summary;
• WordPress or application error logs;
• staff exports, downloads or copied notes.

Retention in WordPress, a workflow service and a model provider is separate. Deleting a WordPress record does not, by itself, delete an n8n execution or a provider-side copy.

The NIST AI Risk Management Framework is a voluntary risk-management framework rather than a compliance certificate. Use it to identify and manage AI risk, then get qualified legal or privacy advice for obligations that apply to your business, contracts and customers.

Test the map without claiming what the test cannot prove

Run the first checks with synthetic data only. Each row below is a procedure, and every outcome is stated as expected because no test has been run for your site.

Keep "tested" and "assured" as separate statuses. A clean model-bound payload is evidence about your integration. A contract or provider policy is evidence about an external commitment.

Ask vendors questions that map to a row

Before signing up, ask questions you can place into the worksheet rather than collecting broad security language.

• Do you use our prompts, files, outputs or feedback to train or improve models, and is that different by product or account type?
• What customer content do you retain, for how long, and what exceptions can extend that period?
• Which endpoints or features create application state beyond abuse-monitoring logs?
• How do request settings such as storage or conversation persistence change retention?
• How do we delete stored content, and what remains after deletion?
• Which subprocessors or connected services can receive the data?
• Which staff or support roles at the provider can access customer content, and under what controls?
• Which settings can an account administrator change that would alter training, logging or retention?
• What written terms apply to the exact product we will use?

Record the source and review date beside each answer. A sales email, public documentation and a signed contract are different evidence types.

Answer customer questions with the map, not a slogan

If a customer asks, "Do you use AI on our data?", answer from the finished map. State the workflow purpose, which fields reach the workflow service, which subset reaches the model, what the model generates, whether a person reviews the result, and the provider assurance that applies to the exact product.

A factual answer for this illustrative design might say that the workflow service receives the submission ID, controlled department value and enquiry text. Before the model call, the text is minimized to remove identifiers the classifier does not need. The model returns a route, review reason and short summary. The separate contact address and internal customer status stay in WordPress. Use that wording only after your own map confirms it.

If they ask, "Is our information used for training?", do not answer from the vendor's brand name. Check the product, endpoint, account, settings and current terms. For the OpenAI API example above, the current API documentation gives a no-training assurance unless the customer explicitly opts in, but that statement should not be copied to another OpenAI product or another provider.

Stop employees from pasting sensitive data into unapproved tools

A one-page staff rule is more useful than telling employees to "be careful." Name approved AI products and the data each one may receive. Name the categories that must stay out of personal accounts or unapproved tools.

Give staff a simple path for exceptions. If a task seems to need customer records, contracts, employee data, credentials or another sensitive category, the employee should stop and ask the named owner before pasting it into a new AI service.

Back the rule with the workflow map. Staff can see which fields are approved, which tool is approved, and which retention terms were reviewed. Review the map again when the provider, product, endpoint, workflow service, integration or business purpose changes.

Copy this empty AI workflow data map

Use one copy per workflow. Do not merge several automations into one sheet because retention and access can differ by path.

AI WORKFLOW DATA MAP

Workflow:
Business purpose:
WordPress source:
Technical owner:
Business owner:
Workflow service:
Workflow service access:
Instance execution-save settings:
Workflow execution-save settings:
Manual execution-save setting:
Workflow execution retention:
Workflow execution deletion method:
Provider/product:
Provider endpoint:
Provider store setting:
Provider conversation setting:
Provider terms reviewed on:
Signed terms/DPA reference:

FIELD OR COPY:
Source:
Purpose:
Contains customer or confidential data:
Derived from another field:
Needed by workflow service:
Needed by model:
Generated by model:
Removed or transformed before model:
Destination:
System identity used:
Staff roles with access:
Workflow-service roles with access:
Provider or subprocessor:
Stored in logs/traces/execution history:
Local retention:
Workflow-service retention:
Provider abuse-monitoring retention:
Provider application-state retention:
Deletion trigger:
Deletion method:
Deletion evidence:
Evidence type: [technical test | provider documentation | signed contract | configuration]
Last tested/reviewed:
Open question:

TEST PLAN
1. Workflow payload test:
   Synthetic input:
   Expected:
2. Model-bound field test:
   Synthetic email:
   Synthetic order number:
   Expected:
3. Production execution-history test:
   Instance settings:
   Workflow settings:
   Expected:
4. Classifier-output test:
   Synthetic markers:
   Expected:
5. Log-copy test:
   Synthetic marker:
   Expected:
6. Access test:
   WordPress test account:
   Workflow-service test account:
   Expected:
7. Local deletion test:
   Synthetic record:
   Expected:
8. Provider assurance review:
   Endpoint:
   Store/conversation settings:
   Source:
   Expected:

Do not approve production customer data while a required destination, reader, retention rule or deletion path is still marked unknown.

Make the next change small

Use the completed map to remove one unneeded field from the model request and one unneeded reader from the review queue or workflow history. If the workflow exposes a custom endpoint, keep endpoint authorization in the secure WordPress REST API endpoints guide and keep this worksheet focused on the data's journey after authorized access.