Is your business data safe with AI automation?

Your data is as safe as the exact setup you are on — which is less reassuring than a straight yes, but far more useful. The business accounts from the big AI providers do not use what you send to train their models. Free and consumer accounts, add-on tools and automation platforms each hold your data for their own periods and pass it to their own suppliers, and each one has to be checked separately. The risk is almost never the AI model itself. It is everything wrapped around it.

Here is what to check, and the questions to put to anyone who wants to build automation for you.

Three things people run together

There is a real difference between three things, and they get blurred constantly.

Training is whether what you send is used to improve the AI model itself. On the business accounts of the major providers, it is not. That is written into the contract, not a checkbox you have to find. On the free and consumer versions of the same companies' chat apps, the default has often been different. These are different products with different terms, and the fact that they share a brand name is why people get this wrong.

Retention is how long what you send is stored, even when it is not used for training. Providers usually keep it for a limited window to check for misuse — often around 30 days — and zero-retention arrangements are available on request for some uses. For compliance purposes this is usually the more important question, and it is the one people ask least.

Sub-processing is who else handles your data along the way. "Sub-processor" is the word you will see in contracts; it just means another company that touches your data because your supplier uses them. This is where the real exposure usually sits, and it is the part that gets skipped.

The chain is longer than people think

When a document goes through an AI automation, it usually passes through more hands than the AI company alone:

• The automation platform — Zapier, Make, or an n8n server. Your data goes through their systems and sits in their logs, sometimes for weeks.
• The AI provider — the model itself.
• Storage — wherever the inputs and results get written. Often Google Workspace, a database, or a spreadsheet.
• The server running any custom parts.
• Sometimes extra services — a document reader, a text-recognition tool, a data-enrichment provider.

Every one of those is a sub-processor. Every one has its own terms, its own retention period, and its own physical location. Under UK and EU data protection law you are responsible for all of them, and you have to be able to name them. India's DPDP Act puts equivalent duties on you. California's privacy law means you owe people an account of who you share their data with.

What this means in practice: ask for the full list. Anyone who cannot produce one for the system they are proposing has not thought about it, which tells you something worth knowing.

What a careful build does differently

These are the things that separate a system you can defend in a client's security review from one you cannot.

Give it the least access it needs. The automation gets to see exactly the data it needs and nothing else — not an admin key because that was quicker. If a workflow handles invoices, it should not be able to read your HR folder. The difference between those two setups is about twenty minutes of work.

Cut the data down before the AI step. If a document has fields the model does not need, strip them out before sending it. The cheapest way to protect a piece of data is not to send it at all. Decide this at the start; it is nearly free then and expensive to retrofit.

Set retention rules and enforce them. Every place data lands — logs, run history, output spreadsheets — needs a defined lifetime and something that actually deletes it. "We will tidy that up later" is how a two-year pile of customer data ends up somewhere nobody remembers.

Keep a record of what happened. What was processed, when, and what the system did with it. You need this to answer someone asking what you hold about them, and you need it to work out what went wrong when something does.

Agree how it ends. What happens to the data, the logins and the working copies when the work finishes. Write it down before you start, not afterwards.

Questions to ask anyone building this for you

Put these to whoever you are considering, including me. The answers tell you a lot.

1. Which services will my data pass through, and what are the training and retention terms for each? A good answer names products and account tiers. "Enterprise-grade security" is not an answer.
2. Can I have the full list of other companies involved? That should take a minute, not a week.
3. Which countries will my data be processed and stored in? This matters if you have EU or UK customers, industry rules, or client contracts about where data may sit.
4. What is the least access this system needs, and will you build it that way? Watch whether they have thought about it or plan to ask for admin.
5. What happens to my data when we stop working together? Working copies deleted, logins revoked, and anything you need handed over.
6. Will you sign an NDA before I explain my systems in detail? The answer should be yes, straight away, at no charge.
7. If a customer asks me what you hold about them, can I answer? This is the practical test of whether the record-keeping is real.

Where the risk actually is

In practice the problems cluster in three places, and none of them is the AI model.

Keys with too much access. A login sitting in an automation platform that can reach far more than the workflow needs. If that platform is broken into, so is everything the key can reach.

Forgotten copies. A spreadsheet or database made during testing, holding real customer data, that nobody deleted and nobody has thought about since.

Nobody wrote it down. Six months and four automations later, no one can say with confidence what data goes where. Not because anyone was careless — because it was never recorded as it grew.

All three are process problems, not technology problems. All three are prevented by writing things down and reviewing them now and then, which is dull, and is why it gets skipped.

What "safe" means for your own customers

If you handle personal data belonging to your customers, your duties do not end at picking a good supplier. Depending on where they live, you may need to update your privacy notice to describe the automated processing, have a lawful reason for doing it, and be able to answer when someone asks what you hold. Where a system makes decisions that significantly affect a person, UK and EU rules — and the EU AI Act's transparency requirements — add more on top.

None of this is a reason not to automate. It is a reason to have it built by someone who raises it before you do.

The short version

AI automation is safe when it is set up deliberately: business accounts, least access, less data sent, retention written down and enforced, a named list of everyone involved, and an agreed ending. It is unsafe when it is thrown together with admin keys and personal accounts and nobody records what was done.

The difference is not cost. It is whether the person building it treats this as part of the job, or as paperwork to do if you insist.

If you want to see what a properly scoped version of your automation would look like, including how the data flows and who would be involved, that is part of what comes out of the free audit — and you keep it whether or not you build anything.