What actually happens to your data, and how to check it

The short answer: four questions, all answerable this week

Whether AI is safe for your business data comes down to four things, and every one of them has a checkable answer. Where does the data physically go when the system runs. Whether the terms of the exact plan you are on permit your content to be used for training. Who inside your business and inside your supplier can see it. And what gets stored as a by-product, where, and for how long.

The model itself is rarely where the exposure sits. The exposure sits in the plumbing: an automation holding a credential that can read your entire customer database when it only needed one table, an execution log storing the full text of every message it ever processed, a transcript folder nobody set a retention period on. Those are ordinary security problems in a new location, and they are fixable with ordinary discipline.

None of this is legal advice, and what obligations apply to your business is a question for somebody qualified to answer it. What follows is how to find out what your setup is actually doing.

Where the data goes when the system runs

When a workflow calls a model, the content of that request leaves your systems and reaches a provider. Two things determine whether that matters: what their terms say about using your content, and where the processing physically happens.

Terms differ substantially between consumer products and business or interface plans from the same company, and they change. So do not accept a general reassurance, and do not accept a claim about a provider from a supplier either. Ask which exact plan and interface you are on, get the relevant clause in writing, and put a matching commitment into your own agreement so that changing it later is a decision rather than an accident.

Region matters separately. Some providers offer control over where processing occurs and some do not, and the answer can differ by plan. If it matters to you, it becomes a selection criterion rather than a question asked afterwards, because moving a live system between regions is not a settings change.

The practical rule that makes all of this smaller: decide what must never be sent at all. Identity document images, full card details, anything you would not put in an email to a stranger. Then make that a rule in the workflow rather than a rule in a document, so it is enforced rather than remembered.

The copies nobody counted

This is where most real exposure lives, and it almost never appears in a security discussion because none of it feels like a database. Every one of these is a full or partial copy of your customer data, sitting somewhere with weaker controls than the system it came from.

Automation platforms keep execution histories, and those histories often contain the entire content of every message that passed through, retained by default for a period nobody chose. Transcripts of voice notes get written somewhere. Indexes built from your documents are a searchable copy of those documents. Backups of all of it exist. And then there are the human copies: the export somebody made to check a number, the screenshot pasted into a group chat, the spreadsheet emailed to a colleague at home.

The exercise that fixes this takes an afternoon and produces more improvement than most security purchases. List every place a copy exists, decide a retention period for each, and set it. A log kept for a month will not be there when a question arrives late. A log kept forever, containing full customer records, has become a second copy of your sensitive data with none of the protection of the first.

• Execution history on the automation platform, and what it retains by default
• Transcripts, drafts and generated summaries, wherever they are written
• Indexes built from your documents, which are a searchable copy of them
• Backups of every one of the above
• Exports, screenshots and spreadsheets made by people doing their jobs

Access, and what the workflow itself can reach

An automation is a user, and it is usually the most over-permissioned user in the business. It gets set up quickly, often with somebody's personal login because that was what was available on the day, and it ends up able to read and write far more than the job needs.

Fix it in three moves. Give the workflow its own account rather than a person's, so nothing breaks and nothing is orphaned when that person leaves. Scope its permissions to what the job requires, which usually turns out to be startlingly little. And write down which humans can edit the workflow and the instructions, because whoever can change the prompt can change what the system is allowed to do, and in most small businesses that list has never been considered.

Then handle the leaving process, which is the one people forget. When somebody leaves, the checklist should include the automation accounts, the model provider keys and the platform logins, not only email and the shared drive.

What to write down before switching anything on

One page, before go-live, and it will be read more often than any policy document. What data the system touches, and which categories are forbidden from ever reaching it. Where every copy lives and how long each is kept. Which accounts and credentials exist, in whose name, with what scope.

Add two operational items that are usually missing. Who is told when something goes wrong, by what route, and how quickly it reaches a person rather than a mailbox. And what a member of staff does if they think the system has sent something it should not have, because the alternative to a clear route is that they hope nobody noticed.

Then review it when anything changes: a new integration, a new model, a new person with access. These setups drift, and the drift is always in the direction of more access and more copies.

The risks this page does not cover

Controls constrain what a system does. They do not improve the quality of its judgement. A workflow producing subtly wrong output inside its permitted scope will pass every check described here, which is why accuracy testing is a separate exercise from security.

There is also a proportion problem worth naming. For a business whose AI reads public information and writes nothing anywhere, most of the above is ceremony, and imposing it slows down something harmless while the actual exposure sits in a shared spreadsheet with a public link that nobody has looked at in two years. Effort should follow the data rather than the novelty, and in plenty of businesses here the largest single exposure is a WhatsApp group containing years of customer details on phones nobody controls.

And this page cannot tell you what you are obliged to do. Sector rules, customer contracts and the jurisdictions your customers sit in all impose requirements, and those are questions for somebody qualified. What is written here is how to build sensible practice once somebody has told you what the requirements are.

Who answers the four questions, and what the answers cost

The copies nobody counted are an ownership problem before they are a security one. Where the accounts, the workflow platform, the document store and the execution history are registered in your company's name and held under your logins, the list of copies is something you can produce yourself. You own the system, which means the deletion question has an answer you can walk end to end rather than one you have to request. Where any of it lives inside a supplier's tenant, the same question becomes a support ticket with a legal deadline attached to it.

Controls constrain what a system does rather than how well it judges, as the last section says, and the practical response to that is a stop rather than a tighter permission. Anything touching money, a price, a public statement or a serious complaint waits for human approval, and a case outside the written scope hands it to a person with the record attached. A workflow producing subtly wrong output inside its permitted scope passes every control on this page, and the only thing that catches it is somebody reading what it did.

There is no price on this site, and what moves the number for this particular work is how many systems the automation must reach, how many categories of data are forbidden from ever reaching it, and how many copies already exist in places nobody has counted. The one page described above is free, and your own team should write it in-house before anybody is engaged, because it is the document that shapes the build rather than a formality attached to the end of one.

Moiz Khan owns automation architecture at Wobble and decides what a workflow may reach, which in practice means refusing the convenient permission. The published work runs across markets with different obligations, including Center for Sight in New York in eye care, Quillon in Australia, BuildHub in Germany and Amari Sayulita in Mexico, which is where the habit of writing down the systems and regions list came from.

Common questions

Is it safe to use AI with business data?

It can be, and the answer depends on four checkable things: where the data goes when the system runs, whether the terms of your exact plan permit training on your content, who can see it on both sides, and what copies are created as a by-product. The model is rarely where the risk sits.

Will our data be used to train a model?

It depends on the specific plan and interface you are using, and terms differ between consumer and business tiers from the same company. Do not accept a general reassurance from anyone. Ask which plan you are on, get the clause in writing, and mirror the commitment in your own agreement.

What is the most commonly missed data risk?

The copies. Automation platforms keep execution histories that often contain the full text of every message processed, transcripts get written somewhere, indexes are searchable copies of your documents, and backups exist of all of it. Listing every copy and setting a retention period for each is an afternoon's work.

Should an automation use a staff member's login?

No. Give it its own account, scoped to what the job needs, which is usually far less than it was granted. A personal login means the automation breaks or becomes orphaned when that person leaves, and it makes it impossible to tell later which actions were the person and which were the system.

Who should be allowed to edit the instructions?

A named, short list. Whoever can edit the prompt can change what the system is permitted to say and do, and in most small businesses that list has never been decided. Write it down, and treat a change to the instructions as a change to the system rather than as a wording tweak.

Does good security make the AI accurate?

No, and conflating the two is a common mistake. Controls limit what a system is able to do. They do nothing about output that is wrong within permitted limits. Accuracy has to be tested separately, against your own real cases, with the failures counted rather than the successes.