AI without exposing your data

The real risk is not the one you expect

When people talk about AI security, they imagine sophisticated attacks. The reality is more mundane: the leak happens through everyday use. A salesperson pasting a contract into a consumer chatbot. A developer sending a database extract "just to debug." A team adopting a free AI tool without approval — the infamous shadow AI.

Every one of those actions sends potentially sensitive data to third-party servers, under terms of service nobody has read — sometimes with a right to train on your content.

First: know what is actually sensitive

"Sensitive data" is a catch-all that can paralyze as much as protect: not everything has the same value or the same legal status, and treating everything at the highest level costs money for nothing. In practice, three tiers are enough to get started:

• Public or harmless: product documentation, marketing content, open-source code. A consumer tool can handle these — they are the right training ground for teams learning to use AI.
• Business-confidential: contracts, quotes, proprietary code, non-personal client data. Only leaves via services under contract (DPA, no-training commitment, limited retention) — never via a free account.
• Critical or regulated: personal data, health, payroll, trade secrets. Controlled perimeter required: chosen hosting, role-based access, audit logging — and often pseudonymization before any model call.

This classification has a hidden benefit: it unlocks use rather than blocking it. Once tier 1 is clearly delimited, teams can use AI freely on that content — and the temptation to circumvent the rules drops sharply.

Three questions to ask before adopting an AI tool

• Where does the data go? What hosting, what jurisdiction, what retention period?
• Is it used to train models? If the answer is not a contractual no, treat it as yes.
• Who has access? On the vendor side and the internal side — which roles, what access logs?

Your data stays yours — or it becomes someone else's.

Concrete countermeasures

Host AI on your own infrastructure (or close to it)

Open-weight models (Mistral, Llama, Qwen…) can today be deployed in your environment — European cloud or even on-premises. Solid performance, data that never leaves.

Local RAG rather than a public chatbot

Connecting AI to your documents via a controlled foundation (local search, cited sources, role-based access control) gives more accurate answers and more secure ones: the data stays within your perimeter, every query is traced.

Simple, enforced governance

A clear usage policy, validated and accessible tools (shadow AI thrives when the official alternative does not exist), technical guardrails — sensitive-data filtering, audit log — and GDPR compliance designed in from the start.

What a controlled foundation looks like

In practice, the architecture that lets you benefit from AI without exposure rests on five building blocks — the pattern we deploy regardless of company size:

• A single entry point: all model calls go through an internal gateway — one place to enforce the rules, instead of ten tools running loose.
• A filter before dispatch: detection and pseudonymization of identifiers (names, emails, numbers) before the prompt leaves your perimeter, when they are not needed for the task.
• Scoped retrieval: the RAG only searches documents the user already has access to — AI is never a way to bypass permissions.
• A complete audit log: who asked what, which sources were used, what response was returned. Essential for auditing, and for responding when someone exercises their rights.
• Interchangeable models: API under contract today, open-weight on your own infrastructure tomorrow — the architecture must not be married to a single vendor.

None of these building blocks is exotic. What is rare is putting them in place before the first incident rather than after.

GDPR and AI: the minimum reflexes

Without turning this article into a legal consultation — for that, your DPO or a lawyer — a few design-time reflexes avoid most of the unpleasant surprises when an AI workload touches personal data:

• Minimize what enters the prompt: pseudonymize or filter identifiers (names, emails, numbers) before the model call when they are not necessary for the task.
• Document the processing: which tool, which data, what purpose, what retention — your records of processing activities must reflect your actual AI use cases, not those from two years ago.
• Frame the vendor: data-processing agreement (DPA), data location, no-training commitment — clauses to verify before signing, not after the incident.
• Trace to be able to answer: if a person exercises their rights, you need to know where their data went. A foundation that logs every query makes that answer possible.

That is exactly the philosophy of the Enterprise AI Core: your data, your foundation, your rules — and our process commitment: no data sent to third-party APIs without your consent. And if you want to know where you stand today, a security audit maps the current state, including AI usage.