Using AI with customer data: what’s safe to send, and how to protect it

The question I hear most when someone wants AI on their site isn’t about cost or which model to use. It’s some version of: “Is it okay to send our customers’ data to an AI company?”

It’s a good question, and the honest answer is “it depends what you send, who you send it to, and how”. This post is the practical version. It isn’t legal advice; if you handle health, financial or children’s data, talk to someone who does that for a living. But for most small businesses, a handful of habits covers most of the risk.

What actually happens to the data#

When your website or tool calls an AI model through an API, the text you send (the prompt, plus anything you attach, like a customer’s message or an order history) travels to the provider’s servers, the model reads it, and an answer comes back.

What happens after that depends on the provider and on which product you use. The things to find out:

• Do they train their models on it? Many providers say they don’t train on data sent through their business API by default, but consumer chat apps can have different rules. Check the terms for the exact product you’re using, not the company in general.
• How long do they keep it? Providers often keep requests for a limited time, for example to detect abuse. Find out how long, and whether you can ask for less.
• Where is it processed? If you have customers in the EU or UK, this can matter for GDPR.
• Will they sign a data processing agreement (DPA)? If you’re under GDPR and sending personal data, you’ll usually need one. Most serious providers offer a standard one.

One distinction is worth repeating: staff pasting customer emails into a free chat app is not the same as your website calling a business API. The first is usually where the real risk is.

Send only what the task needs#

This is the single most useful rule. Before you send anything, ask: does the AI need this to do the job?

A model writing a reply to a support ticket needs the question and maybe the product they bought. It doesn’t need their phone number, address, or date of birth. A model categorising feedback doesn’t need names at all.

So build the prompt from the fields you need, rather than dumping the whole customer record in:

// Instead of sending the whole record...
// const prompt = JSON.stringify(customer);

// ...pick what the task needs
const prompt = `
Write a short, friendly reply to this customer question.
Product: ${order.productName}
Question: ${ticket.message}
`;

Less data in means less data that can leak, and it often gives better answers too, because the model isn’t distracted by irrelevant fields. (More on that in AI tokens and context windows.)

Strip personal details from free text#

Fields you control are easy to leave out. Free text is harder: customers paste their email, phone number and order details straight into a message. A simple redaction step before sending catches the obvious ones:

function redact(text) {
  return text
    .replace(/[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,}/gi, "[email]")
    .replace(/\+?\d[\d\s().-]{7,}\d/g, "[phone]");
}

redact("Hi, I'm Sara (sara.k@example.com), call me on +880 1712-345678 about order 1043.");
// "Hi, I'm Sara ([email]), call me on [phone] about order 1043."

Note what it doesn’t do: the name “Sara” is still there, and the short order number is kept on purpose. Regular expressions catch patterns, not meaning. They’re a good safety net, not a guarantee. If you need stronger redaction, there are dedicated tools for detecting personal data, and some cloud providers offer it as a service.

Never let the browser talk to the AI directly#

If your site calls an AI API straight from the visitor’s browser, your API key is in the page. Anyone can open the developer tools, copy it, and run up your bill, or read whatever you send.

Always route the call through your own backend: the browser sends the question to your server, your server adds the key and any business data, calls the AI, and returns only the answer. On Wix that means a backend web method with the key in the Secrets Manager. I walk through it in how to call an external API from Wix Velo, and the full chatbot version is in how to add an AI assistant to a Wix site.

Doing it this way also gives you one place to apply the redaction, limits and logging from this post.

Be careful what you log#

When you build an AI feature, it’s tempting to log every prompt and response “for debugging”. Then six months later there’s a log file full of customer messages that nobody remembers exists.

• Log that a request happened, how long it took, and whether it failed. Avoid logging the full text by default.
• If you do need the text for a while, set a short retention period and delete it on schedule.
• Don’t put customer data in error messages that go to third-party monitoring tools.

Tell people#

If a chatbot on your site is answering with AI, say so near the chat box. If customer messages are processed by an AI provider, mention it in your privacy policy and list the provider. It’s a legal requirement in many places, and it’s simply good manners. Most people are fine with it when they’re told; they’re not fine finding out later.

A short checklist#

Before you switch on an AI feature that touches customer data:

1. You know which provider and which product you’re using, and you’ve read its data and training terms.
2. You have a DPA in place if you need one.
3. Prompts include only the fields the task needs.
4. Free text goes through a redaction step.
5. The API key lives on the server, never in the browser.
6. Logs don’t keep full prompts longer than they need to.
7. Your privacy policy and the feature itself say that AI is involved.

If you want an AI feature that’s useful and handles data carefully, I do AI integration for small businesses.