AI data privacy checklist before connecting an AI workflow

Originally published at hamzaahmadaslam.com.

How this article was made: drafted with AI assistance from a researched brief, then checked against primary documentation before publishing.

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 [e-mail]; 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.

Illustrative data item	Why it exists	Sent to model?	Destination and access	Retention and deletion	Evidence type
submission_id	Correlate one submission with its processing record	No	WordPress workflow record; n8n workflow webhook and execution data; approved staff or workflow operators	Illustrative WordPress policy: delete 30 days after the case closes; configure and test n8n retention separately	Technical configuration plus deletion tests
contact_address	Let a person reply after review	No	WordPress review record; approved staff only	Illustrative local policy: delete 30 days after the case closes	Technical configuration plus a deletion test
message	Give the classifier the wording it must categorize	Yes, after the pre-send transform	WordPress review record; n8n workflow webhook and execution data; OpenAI API after minimization	Provider handling depends on the endpoint, request settings and your terms; configure n8n execution retention separately; illustrative WordPress copy: delete 30 days after closure	Technical tests for transmitted and stored copies; provider assurance for provider-side handling
department	Supply a controlled form value used by the routing workflow	No in this model request	WordPress workflow record; n8n workflow webhook and execution data	Illustrative local policy: delete with the case; configure n8n execution retention separately	Technical configuration plus deletion tests
customer_status	Give staff local context	No	WordPress review record; approved staff only	Illustrative local policy: delete with the case	Technical configuration plus a deletion test
Classifier output: route, review_reason, summary	Record the routing decision and the model-written context used for review	Returned by model	n8n execution data; exact classifier output saved in the WordPress review queue; approved staff and workflow operators	Apply the same local retention and deletion rules as the related enquiry unless your approved policy says otherwise; include the free-text summary in marker and deletion tests	Technical tests for stored output; provider assurance for provider-side handling
n8n execution data	Keep workflow execution records according to the workflow service configuration	N/A	n8n; accounts allowed to inspect the workflow's execution history; may contain submission_id, department, raw message, classifier output and later node data	Current self-hosted defaults save successful, failed and manual execution data, enable pruning and set the maximum execution age to 336 hours; workflow-level save settings also affect what this workflow keeps	Technical configuration plus a deletion test
WordPress/application log	Diagnose failures without intentionally copying full customer content	No raw customer fields by design	WordPress or application logging system; technical staff with a support need	Illustrative local policy: retain only as long as the support purpose needs it	Technical test plus log configuration

For self-hosted n8n, the current execution environment-variable documentation 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 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 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 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 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 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.

Illustrative test	Procedure	Expected result	What it verifies	What it does not verify
Field boundary	Submit a synthetic message containing [e-mail] and a fake order number in your store's actual format. Inspect both the WordPress-to-workflow payload and the final model-bound payload	The workflow receives only its approved fields. In the model-bound payload, the synthetic email address and order number are absent or replaced by fixed placeholders, and the remaining text still carries the routing intent	Your field selection and pre-model transform	Provider-side retention or training behavior
Workflow-history copy	Send the synthetic submission through the published production webhook rather than an editor or test webhook. Inspect the instance execution variables, this workflow's save settings and the resulting production execution record	Stored production execution data matches the map. Successful production data is absent if saving is disabled for this workflow; the check does not confuse separately configured manual executions with production executions	Instance and per-workflow execution-data configuration	Copies held by the model provider
Classifier-output copy	Inspect the illustrative route, review_reason and summary returned for the synthetic submission, then inspect n8n execution data and the WordPress review queue	The exact classifier output is present only in the mapped stores; the summary does not contain the synthetic email address or order number that should have been removed before the model call	Storage and minimization effects on model-generated text	Provider internal storage
Log boundary	Put illustrative marker TEST-SECRET-BETA in synthetic input that should not enter WordPress or application logs; inspect those logs and the saved classifier output	The marker is absent from logs that do not need customer content and absent from model-written free text when the marked input was removed before the model request	WordPress logging and whether minimized data reappears in stored classifier output	n8n copies that the map intentionally allows or provider-side copies
Access boundary	Use a test account that lacks the WordPress review capability and request the review screen; separately use an n8n account that should not have access to the workflow's execution history	The unapproved accounts cannot read the corresponding stored data; approved test accounts can	Access controls in systems you manage	Access inside the model provider
Deletion path	Create and close a synthetic submission, then run the documented WordPress and workflow-service deletion or pruning process and search for the original message and classifier output in the first-party records named in the map	Records covered by each local policy, including the generated summary, are gone from the named locations after that system's deletion process completes	Your deletion process for systems you control	Provider internal deletion unless the provider exposes verifiable evidence
Provider assurance review	Compare the provider's current data-control page with your endpoint, request settings, account configuration and signed terms	The written assurance and retention entry match the exact endpoint and configuration you plan to use	The basis for the vendor statement in your map	Runtime proof of what happens inside the provider

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.