AI Strategy

AI and Data Privacy: What to Check Before You Automate

Updated 7 min read

AI and Data Privacy: What to Check Before You Automate

Before automating anything with AI, find out what data goes to which provider, what that provider may do with it, who inside your company can reach it and what gets stored. Most AI privacy problems come from skipping those four questions, not from the model. This checklist is engineering guidance, not legal advice.

Key takeaways

  • Draw the data flow first: every system the data passes through, including model providers, automation platforms, vector databases and logs.
  • Read the provider's terms for the product you actually use. Consumer chat apps and business or API products often have different rules on retention and training.
  • Send the model only the fields the task needs. Mask or drop personal data it does not need.
  • An AI assistant must not become a way around your existing access permissions.
  • Log what the system does, but treat the logs as sensitive data with their own access rules and retention period.

Step 1: Map where the data goes

You cannot assess a risk you have not drawn. For each workflow, write down every hop the data makes. A typical AI automation touches more places than people expect:

  • The source system, such as your inbox, CRM, ERP or file storage.
  • The automation or orchestration platform that runs the workflow.
  • The model provider that receives the prompt and returns the answer.
  • An embedding model and a vector database, if the system searches your documents.
  • Monitoring and logging tools that record prompts and outputs.
  • The destination system where results are written.

For each hop, note what data it receives, where it is hosted, and whether it stores the data or only processes it in passing. This one-page map is the most useful privacy document you will produce.

Step 2: Check the provider's terms

Terms differ between providers, between products from the same provider, and over time. Open the current terms and data processing documents for the exact product and plan you will use, and look for answers to these questions.

QuestionWhy it matters
Is our data used to train or improve models?You generally want this off for business data. Check whether it is off by default or needs a setting or an opt-out.
How long are prompts and outputs retained?Retention may exist for abuse monitoring or debugging. Find the period and whether it can be shortened.
Who at the provider can access the data, and when?Human review for safety or support may be possible under stated conditions.
Where is the data processed and stored?Region matters for data transfer rules and for some customer contracts.
Is a data processing agreement available?Regulations such as GDPR expect a contract between you and a processor that handles personal data for you.
How is data deleted on request or at contract end?You need a way to honour deletion requests from your own customers.

One point catches many teams. An employee pasting customer data into a personal account on a consumer chat app is a different situation from your system calling a business API under a signed agreement. Decide which tools staff may use for work data, and say so in a short written policy.

Step 3: Minimize what you send

The safest personal data is the data that never leaves your systems. For every model call, ask what the model truly needs to do the task.

  • Select fields, do not dump records. To draft a delivery update, the model needs the order status and a first name, not the full customer record.
  • Mask identifiers. Replace names, emails, phone numbers and account numbers with placeholders before the call, then put the real values back in your own code afterwards. This works well for classification and summarizing.
  • Keep special categories out unless essential. Health data, financial account details, government identity numbers and data about children carry more risk and often stricter rules.
  • Filter documents before indexing. If you build a knowledge assistant, decide which folders are indexed. Do not index HR files, contracts or payroll by accident because they sat in the same drive.

Step 4: Control access

An AI assistant connected to your data can become the easiest way to see things people were never meant to see. Prevent that by design.

  • Use a dedicated service account for the AI system, with the minimum permissions for its task. Never run it on an administrator login.
  • Respect existing permissions. If a salesperson cannot open payroll in the source system, the assistant must not answer payroll questions for that salesperson. Enforce this in the retrieval and tool layer, not by asking the model to behave.
  • Separate read from write. Many useful assistants only need to read. Grant write access tool by tool, and require approval for sensitive actions.
  • Store credentials properly. API keys belong in a secrets manager or environment configuration, never in prompts, spreadsheets or code repositories.
  • Plan for prompt injection. Text inside an email, web page or document can contain instructions aimed at your agent. Treat all retrieved content as untrusted, and limit what the agent can do so a malicious instruction cannot cause real damage. Our article on AI agent guardrails covers this in more depth.

Step 5: Log carefully

You need logs to debug, to audit and to answer "why did the system do that". Logs also hold copies of the very data you are trying to protect.

  • Record who triggered each run, what tools were called, what was changed and when.
  • Decide whether full prompts and outputs are stored, or only metadata. Where possible, redact personal data in logs.
  • Set a retention period and delete on schedule.
  • Have a simple incident process: who is told, how the system is paused, and how affected data is identified.

Step 6: Know which regulations apply to you

Privacy law depends on where you operate and whose data you hold. GDPR applies to personal data of people in the European Union and has well-known equivalents and counterparts elsewhere, including the UK and several US states. Common themes across them are a lawful basis for processing, telling people how their data is used, limiting use to the stated purpose, honouring access and deletion requests, and extra care where automated decisions significantly affect individuals.

Bring your legal or compliance adviser the data flow map from step 1 and the provider answers from step 2. With those two documents the conversation is short and specific.

A short pre-launch checklist

  1. We have a diagram of every system the data passes through.
  2. We have read the current data terms for each provider and product in use.
  3. Training on our data is disabled or not applicable, and we know the retention period.
  4. Each model call sends only the fields needed, with identifiers masked where practical.
  5. The AI system runs under a least-privilege account and respects user permissions.
  6. Sensitive actions require human approval.
  7. Logs have defined content, access rules and retention.
  8. A legal or compliance adviser has reviewed the setup for our jurisdictions.

Related guides

Frequently asked questions

Is it safe to send customer data to an AI model?

It can be, if you use a business-grade product under suitable terms, send only what is needed, and control access and logging. It is not safe by default. The answer depends on the specific provider terms, the type of data and the rules that apply to you.

Do AI providers train on our data?

It depends on the provider, the product and your settings, and policies change. Check the current terms for the exact service you use, and get the answer in writing in your agreement where it matters.

Does using a self-hosted model solve privacy?

It removes one external party, which helps for very sensitive data. It does not remove the rest of the work: access control, logging, retention and lawful use of the data still apply, and you take on the job of securing the hosting yourself.

Sources and further reading

Primary documentation and research behind this guide.

Privacy work done at the design stage is far cheaper than fixing it after launch, and it rarely blocks a good AI workflow automation project. If you want a second pair of eyes on a planned workflow and its data flow, Growmerz can walk through it with you: book a free AI audit.