Putting Customer Data Into an AI Service: A Decision Map for Privacy, Vendors and Data Minimisation

Before customer data goes to an AI service, the decision is made per field rather than per system. You walk the fields the task genuinely needs, decide for each whether it stays home, travels masked, or is sent as it is, and record the decision together with who made it.

This is a technical description of a working method. It contains no legal conclusion and no statement about what is permitted or required in any particular business. Israel's Protection of Privacy Law and Amendment 13 exist, and the Privacy Protection Authority publishes guidance; a question about obligations belongs with a lawyer or with the Authority.

Why is the field, not the system, the unit of decision?

Because the system is the name of a file, and the field is what actually travels. Two different tasks over the same table need entirely different fields, and if the decision is taken at table level, the modest task inherits the exposure of the ambitious one.

• "Classify enquiries by topic" needs the body of the enquiry, not the name, phone number or national id.
• "Draft a personal reply" needs a first name, not a full address or a payment history.
• "Flag customers likely to churn" needs behaviour and dates, not contact details.
• "Extract fields from an invoice" needs the document, and sometimes fields inside it can be masked before sending.

The gap between those four lines and "upload the table" is the whole point. Finding where personal data sits in the first place is covered in mapping personal data in a small business, and it is the precondition for every decision here.

The three options for each field

The table does not say what is permitted. It arranges the question so it can be answered field by field instead of argued about all at once.

Minimisation and pseudonymisation as engineering steps

Minimisation is not a declaration, it is code that runs before the vendor call. The two practical tools are omission and substitution, and they behave differently.

1. Build the request shape from the fields the task needs, not from the database row as it stands.
2. Delete every field with no role in the expected output.
3. Replace identifiers with a short token, keeping the mapping table on your side only.
4. Scan free text and mask recognisable patterns such as phone numbers and email addresses.
5. Restore the real values after the answer comes back, using that mapping table.
6. Verify on a real sample that the answer is still correct after minimisation.

Step six is the one that gets skipped. Minimisation that drops answer quality below the useful threshold is not a solution, and that needs to be known before go-live rather than after.

What exactly do the vendor's terms decide, and where do you read them?

The terms of use, the privacy document and the account settings screen together determine what happens to data after it is sent. Those are public documents and settings you can open, so this is a question of reading rather than of trust.

• Whether customer input is used to train models, and whether a setting turns that off.
• How long inputs and outputs are retained, and whether shorter or zero retention is offered.
• Which geographic region processes the data, where the vendor offers a choice.
• Which sub-processors are involved in the processing.
• How the consumer account differs from the organisation or API route at the same vendor.
• Which settings can be locked at organisation level so an individual user cannot change them.

That last distinction catches small businesses out. The same vendor can behave differently on the consumer surface and the developer surface, so "what happens to our data" is a question that has to name the route. Further background on the distinction is in what happens to your data in AI tools.

Retention, deletion and what stays on your own side

The vendor side is only half of it. The other half is what your own system keeps around the call, and that is usually more than people expect.

• The full prompt in a log, including the fields you specifically did not want to send.
• The raw response, stored for debugging and then kept forever.
• The pseudonymisation mapping table, which is in practice the key to re-identification.
• Uploaded files copied into temporary storage that never got cleaned.
• Backups of all of the above, which survive a deletion in the live system.

A retention decision without a deletion decision is therefore half a decision. Anyone who has already set access and retention rules for a client folder will recognise the same pattern, described in a digital client folder with access rules and retention.

The decision log, and what is left to ask a professional

• What the task is, and exactly which fields it requires.
• What was decided per field: never leaves, masked, or sent as is.
• Which vendor and which account route, and when the terms were read.
• Which data-use and retention settings were chosen, and by whom.
• The date of the next review, because settings and terms change.

What stays outside the log matters just as much: whether a particular use is permitted, what must be documented or notified, and how long a given kind of information may be kept. Those are not engineering questions, and the answers come from a lawyer or from the Privacy Protection Authority. The value of the log is that it converts a vague general worry into a short list of focused questions that can actually be answered.

Sources

• OpenAI privacy policy
• Claude Code data usage documentation