The AI Confidentiality Risk Hiding in Your Everyday Tools

Most professionals treat an AI chat like a private notebook. They assume the words stay between them and the screen. That assumption now carries a serious AI confidentiality risk. In early 2026, two US federal courts examined whether material run through AI tools stays privileged or protected as work product. The answers should concern anyone who drafts sensitive analysis inside a public chatbot.

The cases are American, so the privilege doctrine does not map cleanly onto European practice. The underlying lesson does, and it travels well. Once you hand text to a tool whose terms let the provider read, store and reuse it, your claim to confidentiality weakens fast.

The confidentiality assumption that quietly fails

People assume three things about AI tools. First, that the conversation is private. Second, that anything they produce with help counts as their own protected work. Third, that nobody outside the room will ever see it. Each assumption depends on conditions most public tools simply do not meet.

A consumer chatbot is not a closed room. Its terms usually permit the provider to process inputs, sometimes to train on them, and to disclose them when law compels it. So the moment you paste a sensitive memo into a public tool, you have arguably shared it with a third party. That single act can undo the protection you assumed you had, and this AI confidentiality risk is not abstract.

Two doctrines behind the AI confidentiality risk

The US rulings turned on two separate points, and both translate into European terms.

No attorney direction, no work product

In United States v. Heppner, a defendant used a public version of an AI assistant to generate roughly thirty documents about his own case. He did this on his own initiative, without his lawyers directing the work. The court therefore refused work-product protection because no lawyer had directed the material. The principle is old; only the tool is new. Protection attaches to how and why material is created, not to how polished the drafting looks.

When provider terms defeat the confidentiality expectation

The same court found no privilege, partly because the provider’s privacy policy allowed inputs and outputs to be used for training and disclosed to authorities. A reasonable expectation of confidentiality cannot survive terms that say the opposite, which is why a documented acceptable-use position matters so much. For an EU reader, swap “privilege” for confidentiality and purpose limitation, and the warning still holds. If your contract lets the vendor reuse your data, the controller still answers for what the processor does.

Being compelled to name the tool

There is a second move that practitioners underestimate. In the companion litigation, the opposing side pushed to discover which AI tool had been used and whether confidential material had been fed into it. Courts have started treating the choice of tool, and its data terms, as fair game in discovery.

That changes your exposure in a concrete way. It is no longer only the output that may surface. The fact that you used a particular public tool, on particular data, can itself become a question you answer on the record. If your usage rules are vague, you will struggle to show you acted with care, much as an earlier ruling already turned AI chats into evidence.

The EU controls that contain the AI confidentiality risk

European organisations do not need US privilege doctrine to act. GDPR already makes the controller accountable for what processors do with personal data. The same discipline answers most of the AI confidentiality risk in front of you, because the risk you face is mostly contractual rather than exotic.

Contracts, deployment and acceptable use

Three controls do the heavy lifting. Your contract sets what the provider may do with inputs, where data sits, and whether you are notified when a government or court asks for access. Your deployment environment decides whether you run a closed, contracted instance or a public tool that anyone’s terms govern. Your acceptable-use rules then tell staff which tools may touch confidential material, and on what conditions, in line with the GDPR risks already sitting in everyday AI tools.

Add prompt discipline and output verification on top. Record what went in, what came out, and why you trusted it. That record is what lets you show, later, that confidentiality was preserved rather than merely hoped for.

Fix this before your next matter

You do not need a large legal budget to close the gap. You need a short set of decisions made on purpose rather than by default.

• Read your AI provider’s data-handling and training terms before the next sensitive matter.
• Confirm whether your tool runs as a closed, contracted instance or a public one.
• Write acceptable-use rules naming which tools may touch confidential or privileged material.
• Require contract notification for government or legal access requests.
• Verify and record outputs so you can show how each was produced.

Before your team drafts anything sensitive in an AI tool this week, ask one plain question. If this surfaced in disclosure, would your contract and your policy actually protect it? If the answer is unclear, that gap is the first thing to fix.