What to Ask Before You Put Client Data Into AI

Somewhere in your business, somebody has pasted a client email into a chat tool to get help drafting a reply. Possibly a contract. Possibly a spreadsheet with names and numbers in it.

They were being resourceful and nobody told them not to. That is the actual state of AI adoption in most companies: not a decision, a drift.

The answer is not to ban it, because the productivity is real and a ban simply pushes it onto personal accounts where you cannot see it. The answer is to decide deliberately, and six questions cover most of it.

1. Where does the data physically go

When information leaves your systems, it lands on somebody else’s. Which country, under which laws, and with what commitments about who can see it.

For a Quebec business this matters more than most, because Law 25 has specific expectations about information leaving the province. It does not prohibit it. It expects you to have assessed it.

2. Is it used to train anything

The important distinction between consumer and business tiers of the same product.

Consumer tools frequently reserve the right to use what you submit to improve their models. Business agreements usually do not. Same interface, entirely different answer, and most people using the tool have no idea which one they are on.

3. Who inside your business can see what

An assistant trained on everything your company holds will answer questions about everything your company holds, to whoever asks it.

If salary information, client contracts and disciplinary notes sit in the same drive, an AI that reads that drive has just become a way for anyone to query it. Permissions have to carry through to the AI layer. This is the most commonly missed item on this list.

4. What happens when it is wrong

Not whether it will be wrong. When.

A drafting error caught by a person is nothing. The same error sent to a client because nobody reviewed it is a different matter. Decide which outputs need a human before they leave the building, and set that boundary by consequence rather than by volume.

5. Can you show what happened

If a client asks why they received something, or a regulator asks how a decision was made, you need a record. What was asked, what material it drew on, what it produced, and who approved it.

Systems built without that log are impossible to defend afterwards, and the log costs nothing to build at the start and cannot be reconstructed later.

6. What does it do that a person was not going to do anyway

The commercial question, and the one that should come first.

If the honest answer is that it makes an existing task slightly faster, the risk assessment above may not be worth the effort. If the answer is that it covers hours nobody was covering, or reads volume nobody had time to read, the case is clear and the controls are worth building properly.

How AI Optimize approaches it

Every system we build starts from your own material rather than from general knowledge, which is what makes the output usable without rewriting. That means the questions above are design decisions taken at the start, not policies written afterwards.

In practice: the system reads only what it has been given access to, permissions follow the person asking, anything above an agreed threshold routes to a human before it goes out, and every interaction is logged against the right record.

None of that slows the build down. It simply has to be decided before rather than discovered after.

The practical starting point

Ask your team what they are already using. Not as an audit with consequences, as a genuine question. The list will be longer than expected and it is the real picture of your exposure.

Then give them one approved route that is better than the one they found themselves. People use the sanctioned tool when it is the best tool. They route around it when it is not.

Write the one page policy

Most businesses of this size do not need a governance framework. They need one page that somebody actually reads.

It should say which tools are approved and for what. Which categories of information must never leave your systems, named specifically rather than described in the abstract. What has to be reviewed by a person before it reaches a client. And who to ask when something falls outside the list.

One page, written in plain language, given to everybody. A twelve page policy produced by a lawyer will be filed and ignored, and the behaviour you were worried about will continue exactly as before.

Client contracts may already constrain you

The question nobody thinks to ask is whether your own agreements permit this.

Many client contracts, particularly in professional services and anything touching regulated work, contain confidentiality terms that say something about where information may be processed and who may access it. Feeding that material into a third party tool can breach an agreement you signed years ago without anybody involved realising.

Check before rather than after. If your contracts are restrictive, that is an argument for systems that run on your own infrastructure rather than an argument against doing anything.

The shadow usage problem

Whatever you decide, assume some of it is already happening outside the decision.

People use whatever helps them finish the day. If the approved route is slower or more awkward than the one they found themselves, they will quietly keep using theirs, on a personal account, where you have no visibility and no agreement covering it.

Which makes the approved option a design problem rather than a policy problem. It has to be genuinely better, not merely permitted. Businesses that ban and do not replace end up with the same activity and less oversight than before.

AI Optimize builds systems where the permissions, the review boundaries and the audit trail are part of the design. That work sits under Custom AI Integrations.