Data security and confidentiality when using AI
What to ask a vendor, how to configure access to internal information, and the minimum rules that prevent most incidents.
AI security risk rarely comes from a sophisticated attack. It comes from someone pasting a confidential document into a free tool to get something done quickly on a Tuesday afternoon.
The measures that prevent most incidents are simple and require no additional technology.
The three questions for a vendor
Where is data processed and stored? Which region, which infrastructure, and how long it's retained. If the company has regulatory localization obligations, this answer decides whether the vendor is viable at all.
Is our data used to train models? The answer belongs in the contract, not on an FAQ page that can change. Enterprise plans generally include this commitment; several free plans don't.
Who can access it on the vendor's side? Which technical staff can see content, under what circumstances, and what controls exist.
The most common mistake when connecting internal documentation
When implementing an assistant over internal documents, the risk isn't the model: it's the scope of access.
If the system indexes the whole repository and answers any employee with information from any document, it has become a gateway to restricted information. Someone who couldn't open the payroll folder can now ask and get the answer.
The fix is for the assistant to respect existing source permissions: each person gets answers based only on the documents they already have access to. Verify this explicitly before implementing, because not all solutions do it.
The minimum rules worth setting
Four rules cover most of the real risk:
- Approved tools. A concrete list with names, and a simple route to request others.
- Information that never gets uploaded. Sensitive personal data, credentials, material under third-party confidentiality.
- Paid tiers for work use. Not for features, but for the data-handling terms.
- A channel to ask. Where to check first rather than decide alone.
They fit on half a page and solve more than any monitoring tool.
The risk of broad access
When an AI system integrates with internal systems, it inherits their permissions. The common practice of granting broad access "for the pilot" and never tightening it is one of the most concrete risks.
Two criteria:
- Least necessary access, exactly as for a person.
- Periodic review, because permissions granted for a pilot tend to survive for years.
What to log
To investigate an incident you need three records:
- Who asked what. To detect misuse.
- Which sources the system accessed for each answer.
- Which actions it executed, for systems that operate on other systems.
These logs are also what lets you answer an audit without reconstructing history from memory.
The layer usually missing: people
Most incidents aren't technical. They're about use. A twenty-minute session with concrete examples from the team's own work achieves more than a fifteen-page policy document.
The message is simple: which tools to use, what never to upload, what to verify before using an output, and who to ask when unsure. If someone can repeat those four things, most of the risk is covered.
A quick check worth doing this week
Ask the team which AI tools they're using today. The list is almost always longer than IT assumes, and it includes tools nobody evaluated.
That list is the real starting point for any security policy on the subject.
Frequently asked questions
Do AI vendors train their models on our data?
It depends on the plan. Enterprise and paid tiers generally include a commitment not to train on customer data, while several free tiers do use it. Verify it in the contract.
Is it safe to connect an AI assistant to our internal documents?
Yes, if it respects existing permissions: each user should get answers based only on what they already have the right to see. Connecting an entire repository without filtering permissions is the most serious and most common mistake.
What information should never go into an external tool?
Sensitive personal data, credentials and keys, information under third-party confidentiality agreements, and regulated data that cannot leave a given jurisdiction.