What Operations Leaders Should Know About AI Data Security and Privacy

Most of the AI data security conversations I have with clients start the same way. Someone in operations, usually a director who has just approved a pilot, asks me a version of this question: "If my team pastes a customer contract into a chatbot, where does it go?"

It is the right question, and the honest answer is that it depends entirely on which account they used. The same model, from the same vendor, can be covered by a strict contract or by no contract at all, depending on whether your analyst logged in through the company workspace or through the free account they made in 2023. That single distinction accounts for most of the risk I see inside mid-sized and large organizations right now.

This piece is the version of that conversation I have most often. No legal theory, no scare tactics. Just what actually happens to your data, what to ask vendors, and what to put in place first.

The real exposure is not the model, it is the account

Public research through 2025 and 2026 consistently shows the same pattern: a large majority of employees now use AI tools at work, a minority of organizations have a written policy covering it, and a meaningful share of those users are on personal accounts that IT cannot see. Surveys put personal-account usage somewhere near half of all generative AI use inside companies, and roughly a quarter to a third of employees admit they have entered confidential material into a consumer tool. Treat the exact percentages loosely; the direction is not in dispute.

Here is why account type matters so much. Consumer tiers of most major assistants historically allowed the vendor to use conversations to improve models unless the user changed a setting. Business and enterprise tiers do not, and the difference is contractual rather than a toggle someone can flip back. When an employee uses a personal login, you inherit consumer terms for corporate data, you get no admin visibility, no retention control, no audit log, and no ability to revoke access when they leave.

I had a client last year discover that an entire pricing model had been rebuilt inside a personal AI account by a well-meaning analyst who found the company tool too slow to get approved. Nothing malicious happened. But the company had no record of it, no way to delete it, and no idea what else had been pasted alongside it.

So the first move is almost never a new tool. It is getting your people onto sanctioned accounts fast enough that the workaround stops being worth it.

AI data security: what vendors actually do with your data in 2026

Four things determine your exposure, and they are worth separating because vendors often answer one when you asked another.

Training. Does the provider use your inputs and outputs to train or fine-tune models? On business, team, and enterprise plans from the major providers, the answer in 2026 is no, and it is written into the agreement rather than left as a preference. Consumer plans are where this gets murky, and policies have changed more than once.

Retention. Separate question. A vendor can promise never to train on your data while still keeping it for 30 days for abuse monitoring. For most operations use cases that is fine. For regulated data it may not be. Zero Data Retention, where prompts and responses are processed and discarded without being logged to disk, has moved from a niche request to a standard enterprise option over the past two years. It is available on enterprise tiers from the major providers and on several API endpoints, usually on request and sometimes with feature trade-offs, since you lose the stored history that some features depend on.

Subprocessors and residency. Most SaaS platforms do not run their own models. They call someone else's through a managed cloud API. monday.com, for example, states that it does not use customer content to train models and that its AI providers operate under zero-retention terms, accessed through managed services on Azure and AWS Bedrock. That is a reasonable posture, and it is the kind of specificity you want in writing. Ask where processing happens too, because for Quebec and Canadian clients data residency is often the sticking point long before model behaviour is.

Access controls on your side. This is the part vendors cannot fix for you. If an AI assistant is connected to a workspace where permissions were never tightened, it will faithfully summarize documents the requester should not have been able to open. AI does not create the permissions problem. It makes an existing one visible and searchable.

The regulatory picture, briefly

Canada still has no dedicated federal AI statute. Bill C-27, which carried both the CPPA and AIDA, died in 2025 and has not been replaced. What binds you today is existing privacy law: PIPEDA federally, and in Quebec, Law 25, which is fully in force with penalties reaching into the tens of millions.

Law 25 matters more than people expect for AI projects. It requires explicit, informed consent, and it obliges you to notify individuals when a decision about them is made exclusively by automated processing, along with an explanation of the logic involved. If you are using AI to score applicants, route credit decisions, or triage claims, that provision applies to you regardless of how good the model is.

If you sell into Europe, the EU AI Act's high-risk obligations continue phasing in through 2026 and 2027, and for exporters it tends to become the effective standard because it is easier to build to the strictest requirement once.

None of this requires a legal department to start. It requires knowing which of your AI use cases touch personal information and which do not.

Where I tell clients to start

A practical sequence that takes weeks, not quarters:

1. Inventory the reality. Ask each department head which AI tools their team uses, including personal accounts, and promise no consequences for honest answers. You will find more than you expect.

2. Buy the business tier for one tool and make it easy. One sanctioned assistant, provisioned through SSO, available same-day on request. Adoption of the safe path is a supply problem more than a discipline problem.

3. Write a one-page classification rule. Three tiers is enough: public, internal, and restricted. Restricted means customer personal information, health data, financial records, credentials, and anything under NDA. Restricted never goes into a tool that has not been reviewed.

4. Review the paperwork for anything touching restricted data. Data processing agreement, subprocessor list, retention terms, residency, SOC 2 Type 2 or ISO 27001, and breach notification timelines.

5. Tighten permissions in the systems the AI can reach before you connect it, not after.

6. Log what you build. Every automation that sends data to a model should have a named owner, a stated purpose, and a note on what data class it handles. My clients keep this on a monday.com board, which makes the annual review a filter rather than an investigation.

The organizations that handle this well are not the most cautious ones. They are the ones that made the approved path faster than the unapproved one and then spent their attention on the handful of use cases that genuinely touch sensitive data.

FAQ

Is it safe to use AI with customer data? It can be, on the right plan with the right agreement in place. What makes it unsafe is doing it through a consumer account with no data processing agreement, no retention terms, and no admin visibility. Same model, very different risk.

Does our data get used to train the model? On business, team, and enterprise tiers from the major providers in 2026, no, and it is contractual rather than a setting. Verify it in your own agreement, and check the consumer tiers separately, since those terms have changed several times.

What is zero data retention, and do we need it? It means prompts and responses are processed and discarded rather than stored. It is worth requesting for regulated or highly sensitive data. For general operational work, standard enterprise retention with a no-training commitment is usually enough.

Do we need an AI policy before we start using AI? No, but you need one quickly. Start with the one-page data classification rule and the sanctioned-tool list. A longer policy written before anyone has used the tools tends to describe a company that does not exist yet.