AI and Your Customer Data: What Small Businesses Need to Know

This is the question owners ask last and should ask first, usually phrased as “is it safe to put our stuff in there?” The answer is conditional, the conditions are knowable, and most of the risk comes from staff using personal accounts rather than from the tools themselves.

Nothing here is legal advice. If you handle health records, financial data, or information covered by a client contract, the specifics belong with your attorney, what follows is the structure of the problem so that conversation is shorter.

Where does your data actually go?

When someone types into a hosted AI tool, the text travels to the vendor’s servers, is processed, and a response comes back. The questions that matter are what happens to that text afterwards:

• Is it retained, and for how long? Most vendors keep inputs for a period for abuse monitoring and debugging, often around thirty days, sometimes configurable to zero on business tiers.
• Is it used for training? This is the big distinction between consumer and business plans. Consumer tiers have historically used conversations for model improvement by default with an opt-out; business and enterprise tiers generally do not train on customer data by default.
• Who can see it? Vendor staff access for abuse review, subprocessors, and — in a business account — your own administrators.

Those answers change as vendors revise terms, which is why the durable advice is to check the current terms for your specific plan rather than to trust a summary written at any point in the past, including this one.

What is the biggest actual risk for a small business?

Shadow usage. Not the tool. The fact that staff are already using personal accounts to do work, and nobody knows what has been pasted into them.

This is nearly universal and mostly well-intentioned: someone pastes a customer email to get help drafting a reply, or a spreadsheet to get a summary. On a personal consumer account, that content may sit under terms your business never agreed to and cannot audit.

The fix is not prohibition, which drives it further underground. It is providing a sanctioned account on a business tier, saying clearly that it exists and is approved, and being specific about what may and may not go into it. People follow rules that come with a working alternative.

What should never go into a general AI tool?

A short, memorable list beats a long policy nobody reads:

• Full identifiers: Social Security numbers, full card numbers, bank details.
• Credentials of any kind, including API keys pasted “just to debug.”
• Health information tied to an identifiable person.
• Anything covered by a confidentiality clause in a client contract, unless you have checked that the clause permits third-party processing.
• Information about a person that they would be surprised to learn you had shared with a vendor.

That last one is not a legal test, but it is the most useful instinct to give staff, because it generalizes to situations the list does not anticipate.

What is a DPA and do you need one?

A data processing agreement is a contract governing how a vendor handles personal data on your behalf: what they may do with it, how long they keep it, who else touches it, and what happens if there is a breach. Business tiers of major AI vendors offer one; consumer tiers generally do not.

If any personal data about customers or employees will pass through the tool, you want one in place. It is also the document your own clients will ask about when they audit you: increasingly common if you serve larger organizations, and a reason to sort it out before somebody requires it on a deadline.

Does building something custom make this safer?

Sometimes, and less automatically than people assume. A custom system still runs on a model hosted somewhere, and that somewhere has terms. What building does give you is control over three things that genuinely reduce exposure:

• What gets sent at all. A purpose-built system can strip or tokenize identifiers before anything leaves, so the model sees the shape of the problem without the person attached.
• Which vendor and tier. You choose the API and plan, with its retention and training terms, rather than inheriting whatever an application vendor chose.
• What is logged, and where. Your logs, your infrastructure, your retention rules.

The strongest version — running a model entirely on your own hardware — does exist and is occasionally the right answer for genuinely sensitive work. It costs meaningfully more and performs somewhat worse than the leading hosted models, so it should follow from a real constraint rather than from general unease.

A practical checklist

1. Find out what staff are already using, without making it a disciplinary conversation. You cannot govern what you have not surveyed.
2. Move sanctioned use onto a business tier and confirm the training and retention settings for that tier in writing.
3. Put a DPA in place if personal data is involved.
4. Write a one-page rule set: what is fine, what is never, who to ask. One page, or nobody reads it.
5. Check your client contracts for confidentiality clauses that restrict third-party processing, before a client checks for you.
6. Review annually, and whenever a vendor emails about changed terms, which is the email everyone deletes.