GDPR and AI: What Is Actually Allowed When Processing Personal Data

GDPR does not prohibit the use of artificial intelligence. It governs the processing of personal data, whatever the tool employed. When an AI receives, analyses or produces information relating to identified or identifiable persons, that processing falls within the scope of the regulation and must comply with its principles. The practical difficulty is not determining whether GDPR applies, it almost always does, but identifying what is lawful and what is not.

A legal basis is required, before any processing

Any processing of personal data presupposes a legal basis identified beforehand. The regulation provides for several: the data subject’s consent, the performance of a contract, compliance with a legal obligation, the legitimate interest of the controller, among others. Resorting to AI does not create a new basis. If one wishes to have client files or emails analysed by a model, this use must be attached to one of these bases, and it must be verified that it remains compatible with the original purpose for which the data was collected.

The principle of purpose limitation is central here. Data collected to manage a commercial relationship cannot be freely reused to train or feed an AI system if that purpose was neither anticipated nor compatible. Reuse must be justified; it cannot be presumed.

Minimisation: process only what is necessary

The principle of minimisation requires limiting the data processed to what is strictly necessary for the purpose pursued. Applied to AI, it prompts a simple and often overlooked question: does the model need to know the real identity of the persons in order to produce the expected result? In many cases, the answer is no. Summarising a document, classifying a request, drafting a standard reply does not, in itself, require transmitting an individual’s name, address or case number.

This observation has a practical consequence: the more one reduces the personal data actually exposed to the processing, the closer one comes to the standard expected by the regulation, and the more one reduces exposure to risk.

Health data: a prohibition in principle

GDPR distinguishes a particular category of so-called sensitive data, which includes data concerning health, but also opinions, origin, beliefs or biometric data. For these categories, the principle is not regulation but prohibition. Their processing is forbidden, unless it falls under a strictly defined exception, such as the explicit consent of the data subject or an obligation in the field of health.

Concretely, exposing health data to an AI model without a solid basis for exception is not one risk among others: it is processing forbidden by default. This is why a prudent approach consists in treating such data as data to be blocked, and not merely regulated, whenever no exception clearly applies.

Pseudonymisation does not, in itself, make processing lawful

Replacing names with codes is a useful measure, but its exact scope must be understood. GDPR recognises pseudonymisation as a security measure, one that reduces risk without taking the data out of the scope of the regulation, since re-identification remains possible. The position expressed by the European Data Protection Board (EDPB) goes in this direction: pseudonymising a processing operation does not, on its own, suffice to make it lawful. A legal basis remains necessary, and the principles continue to apply.

Pseudonymisation is therefore a means, not an absolution. It strengthens a compliance that is established by other means; it does not replace it. Anonymisation in the strict sense, which excludes any re-identification, does take the data out of the scope of GDPR, but it is more demanding and rarely achieved in absolute terms. It is better to describe honestly what one is implementing than to call anonymous what remains pseudonymous.

Transfers outside the European Union

Another point calls for vigilance: the location of the processing. Calling upon an AI provider whose servers are located outside the European Union constitutes a transfer of data, subject to specific rules (adequacy decision, standard contractual clauses, appropriate safeguards). The fact that a service is widely used does not exempt one from this analysis. Many everyday AI uses rely on infrastructure located outside the EU, which must be documented and governed, not assumed to be compliant.

The “GDPR-compliant” trap

This is undoubtedly the most frequent confusion, and the one with the heaviest consequences. The label “GDPR-compliant” does not mean that the data stays with you. It indicates that a processing operation is governed according to the rules: legal basis, retention period, data subjects’ rights, security measures. But a perfectly compliant processing operation can quite well cause the real data to leave towards a third party.

It is therefore useful to separate two families of cases. On one side, data that may be processed and transmitted, subject to a compliant framework: let us call it “GDPR-acceptable, but it leaves”. On the other, data that an organisation, by internal decision, sectoral constraint or sensitive nature, considers as data that must never leave its perimeter: “forbidden to leave”. For the first family, a good contract and good documentation suffice. For the second, no contractual clause replaces the technical fact that the data did not leave.

The “forbidden to leave” case: answering with technical means

It is precisely this second case that guided the design of CLEVYA. When data must not leave the server, the answer cannot be a commitment: it must be a verifiable technical measure. The approach consists in detecting and replacing sensitive identifiers locally before any call to a model, so that the model never receives the real data, and in logging every transmission so that the DPO can verify what has, or has not, left.

One must remain precise about what is established and what is not. Identifier detection has been measured: it reaches 94.2% recall on our in-house corpus (206 synthetic multi-domain documents in French, written for testing) and around 75% on a public French benchmark, within our scope of types. No automatic detection reaches 100%, and we do not claim it. This is why the system relies on several layers, known formats, entity recognition, lists specific to the organisation, and on a principle of prudence: in case of doubt, the data does not leave. Security rests on deterministic code and human oversight, never on the model’s judgement alone.

Going further

The full compliance reading is detailed on the GDPR & sovereignty page. To understand the difference between a contractual commitment and technical proof, see AI Sovereignty: Contract vs Proof. On the obligations to come, see EU AI Act 2026: What to Prepare, whose application is phased, the first obligations (prohibited practices, AI literacy) having been in force since 2025 and a major deadline on 2 August 2026. Finally, on the invisible AI uses already present in organisations, see Shadow AI: The Invisible Risk.