AI and cybersecurity : why we refuse to deploy an internal assistant without a written data policy

Should an internal AI assistant be governed before deployment?

Short answer: yes, and it's an AI cybersecurity question before it's a tooling question. Without a written rule on what data employees can enter into their prompts, we refuse to put an assistant into production, even when the model itself is reliable and the vendor checks every contractual box.

The request tends to come in the same shape every time. Leadership wants an internal AI assistant, a chatbot connected to email, support tickets or the document repository, and the project is scoped in weeks, not months. The model choice is made. The technical integration is ready. What's almost always missing is a one-page document that tells an employee what they're allowed to type into the prompt box. Without that document, we don't start the deployment, even if everything else is in place. This isn't excessive caution, it's a condition of the engagement.

What we refuse, concretely

What we refuse isn't AI. It's AI without prior classification of the data it will handle. In practice, three situations come up repeatedly and we block them systematically before go-live:

In all three cases, the problem isn't that the model is bad. The problem is that we don't know what it was given access to, and we won't be able to explain that to an insurer, to the Commission d'accès à l'information or to a forensic investigator on the day it matters.

Shadow AI already exists in your organization

Here's what we find almost every time we walk into an organization that has never formalized its AI governance: employees are already using a public assistant, with their personal account, to rephrase a sensitive email, summarize a contract or translate a customer complaint. No one authorized it, but no one forbade it either, because no one ever wrote the rule.

That's shadow AI. It doesn't show up as a technology project that needs approval. It shows up as an individual action, repeated hundreds of times, pushing company data out to servers we don't control, under terms of use nobody ever read. Refusing to deploy an official assistant without a written rule doesn't solve this problem, but acknowledging it is the only honest way to approach the file. A risk manager who presents a security program to an insurer without mentioning this informal use is presenting an incomplete file, not a strong one.

What we deploy, and under what conditions

What we agree to put into production always follows the same sequence, documented before the first deployment, not after. On this point, our service sheet is direct: we establish data classification, privacy impact assessments for AI projects, usage rules for employees, and the associated technical controls.

Concretely, that means four distinct things, in this order:

This last point is the one we see skipped most often. A written policy that no one can enforce technically remains a statement of intent, not a control.

What this changes for your defensible position

For a risk manager or a CISO, the value of this sequence isn't philosophical. It's a file you can show. When an incident touches a system running an AI assistant, the first question from an investigator or an insurer is simple: what was this model allowed to see, and how do you know? An organization that answers with a documented classification and signed rules answers in minutes. An organization that answers "we assume nobody sent anything important" answers with a gap in its file, exactly at the moment it can least afford one.

It's the same logic behind our audits and posture assessments in general: the goal isn't only to reduce technical risk, but to produce a file that holds up in front of a third party. An AI assistant deployed without this foundation doesn't just add a data leak risk, it adds a blind spot in a file that may otherwise be very well kept.

What's left to do, and in what order

A poorly governed AI assistant won't necessarily cause a visible incident tomorrow. Instead, it creates a data flow that goes undocumented, accumulates, and becomes hard to explain six months later, when the question comes up in the context of a breach notification or an insurance claim. The cost of not having this framework in place doesn't show up in a budget, it shows up in the quality of the answers you can give the day someone demands them.

If an internal AI assistant project is under discussion in your organization, the question to ask before choosing a vendor isn't technical, it's documentary: who classified the data, who assessed the privacy impact, and who will sign the usage rules before the first employee is connected. Groupe ITCS builds this AI governance framework, from data classification through to the technical controls that enforce it, before the project goes into production, not after.

Sources