Back to Blog
Before First Training Run: CNIL Checklist for GDPR and AI in France

Before First Training Run: CNIL Checklist for GDPR and AI in France

Before First Training Run: CNIL Checklist for GDPR and AI in France

Hands connecting network cable to server

Yes, the GDPR applies to AI systems that process personal data, full stop. If your model trains on customer records, HR files, or chat logs, you need a documented lawful basis before that training starts, and you likely need an AIPD. CNIL and the EDPB have both laid out specific criteria for this. Start with privacy-by-design, not a compliance patch after launch.

TL;DR:

  • Training or testing AI models on personal data requires a documented lawful basis and must follow privacy-by-design principles from the start.
  • Most data processed during model development, including pseudonymized records, remains subject to GDPR unless it is genuinely anonymized through thorough testing.
  • Building training datasets involves strict data minimization, purpose limitation, provenance verification, and limiting sensitive attributes to stay compliant.
  • An AIPD is mandatory for high-risk processing, especially if the system is classified as high-risk under the AI Act, and should be integrated with GDPR documentation from the outset.
  • Effective governance includes clear role assignment, pseudonymization, exhaustive logging, and robust procedures for data subject requests to ensure ongoing compliance.

Table of Contents

How Does GDPR Apply to AI Projects in France?

GDPR and AI intersect at every phase of a project, not just at the point of deployment. Training a model on personal data is processing. Testing it against real customer records is processing. Running it in production to score, rank, or profile people is processing. CNIL’s guidance treats each phase as a separate moment requiring its own legal justification, not one blanket approval for the whole project.

The tricky part is classifying what you’re actually working with. Raw customer chat logs are personal data. Pseudonymized records still count as personal data under GDPR because they can be re-linked. Only genuinely anonymized outputs escape the regulation, and as you’ll see below, that bar is higher than most teams assume.

Common scenarios that trigger GDPR obligations include:

  • Training a support chatbot on historical customer conversations
  • Building an HR tool that scores candidates or flags attrition risk
  • Running automated fraud detection that flags individual transactions
  • Fine-tuning a model on scraped web data that includes names or contact details

Each of these needs a lawful basis before a single training run happens.

Article 6 of the GDPR gives you six lawful bases: consent, contract, legal obligation, vital interest, public interest, and legitimate interest. For AI work, only two show up in practice with any regularity.

Consent sounds clean but rarely survives contact with large-scale training. You can’t realistically get individual, informed consent from every person whose data feeds a large-scale model training, and consent must stay revocable, which breaks most training pipelines. That leaves legitimate interest as the default for most French companies building AI tools, and CNIL is clear that this basis demands real work, not a checkbox. You have to run and document a balancing test weighing your business interest against the person’s rights.

Your documentation should cover:

  • The specific purpose (not “improve AI” but “reduce support ticket resolution time by X”)
  • Why the processing is necessary for that purpose
  • What safeguards limit the impact on individuals
  • A dated, retained record of the balancing test itself

Pro Tip: Write the balancing test before training starts, not after CNIL asks for it. A record created retroactively reads very differently to a regulator than one dated before the first model run.

Building a Minimized, Traceable Training Dataset

Data minimization is where most AI projects quietly drift out of compliance, usually because “more data” feels safer for model performance than it actually is for legal exposure. CNIL’s guidance on AI compliance is explicit that collecting data is only legitimate when it’s proportionate to a stated purpose you defined before collection began.

Three rules to apply before a dataset goes anywhere near a training job:

  1. Strip unnecessary fields. If a customer’s purchase history has nothing to do with your chatbot’s stated purpose, drop it before ingestion, not after.
  2. Audit provenance on anything scraped or third-party. Verify you actually have the legal right to reuse that data for training, not just the technical ability to access it.
  3. Limit sensitive attributes in annotation. If annotators are labeling data, keep health, religion, or political indicators out unless they’re strictly necessary, and maintain a mapping so you can honor deletion or correction requests later.

When Do You Need an AIPD for an AI Project?

An AIPD, the data protection impact assessment required under Article 35, becomes mandatory whenever processing is “likely to result in high risk” to individuals. CNIL and the EDPB use a practical shortcut here: meeting two or more risk criteria (large-scale processing, sensitive data, systematic monitoring, automated decision-making with legal effect, among others) creates a presumption that an AIPD is required.

The EU AI Act adds another layer. If your system qualifies as “high risk” under the Act and it processes personal data, that classification itself strengthens the presumption that you need an AIPD. The two frameworks aren’t competing, they’re stacking.

The efficient move is building one integrated document instead of two separate ones:

  • Use your AI Act technical documentation as the backbone
  • Layer in the GDPR-mandatory AIPD elements (necessity assessment, risk to rights and freedoms, mitigation measures)
  • Keep both frameworks’ required fields visible in a single file you can hand to CNIL or a notified body without rebuilding it twice

Pro Tip: Draft the AIPD alongside your AI Act technical file from day one. Retrofitting one into the other after development is finished takes far longer than building them together.

Is Your AI Model Actually Anonymous Under GDPR?

Most teams assume that once a model is trained, the raw data disappears into weights and the privacy problem goes away. The EDPB disagrees. Its recent opinion on AI models states plainly that models trained on personal data cannot be assumed anonymous by default. Anonymity has to be demonstrated case-by-case, accounting for every reasonably available method of re-identification, not just the obvious ones.

Hands adjusting anonymization testing device

CNIL’s practical answer is to test it rather than assert it. Documented re-identification attack tests give you actual evidence to show a regulator instead of a confident claim with nothing behind it.

A note on scale: membership inference and extraction-style attacks are now standard evaluation techniques for exactly this purpose, and CNIL expects providers to run them before making anonymity claims rather than after a regulator asks.

If earlier training used data later found to be unlawfully collected, don’t assume the problem stays in the past. The EDPB indicates that deploying that model may itself constitute new processing, which means remediation or deletion could be necessary even at the deployment stage.

What Governance and Security Controls Does CNIL Recommend?

CNIL frames GDPR less as a barrier and more as a trust-building framework for AI, but that trust only materializes with real operational structure behind it. Four things need to exist before you launch anything.

  1. Assign roles clearly. Know who is the data controller and who is the processor for every AI vendor relationship, and keep a record of processing activities that reflects this.
  2. Pseudonymize wherever training doesn’t require raw identifiers, and restrict access to training environments the same way you’d restrict access to production databases.
  3. Log everything. Training runs, data access, and model updates all need an audit trail CNIL could review on request.
  4. Build a working path for data subject rights. Access, rectification, and erasure requests need an actual process, and any automated decision with legal or significant effect needs a genuine human review option, not a rubber stamp. Article 22 makes this a right, not a courtesy.

Pro Tip: Test your erasure process on a real record before you need it for a real complaint. Many teams discover their “right to erasure” workflow can delete a database row but can’t actually scrub a person’s data out of a trained model.

A governance framework built around these roles from the start avoids the scramble that happens when a request lands with no process behind it.

Hand moving wooden governance blocks

Pre-Launch Checklist for GDPR-Compliant AI Deployment

Treat compliance as three checkpoints, not one final review before launch.

  1. Pre-launch: confirm and document your lawful basis, audit the dataset’s provenance end to end, and decide formally whether an AIPD is triggered.
  2. Development: run a privacy-by-design review against the stated purpose, execute re-identification attack tests, and confirm training environments meet your security baseline.
  3. Post-launch: set up ongoing monitoring, define an incident response path, and keep documentation current for CNIL rather than frozen at launch date.
Phase Core action Owner
Pre-launch Lawful basis + AIPD decision documented Legal/DPO
Development Attack tests + privacy-by-design review Technical team
Post-launch Monitoring + incident response + updated records Compliance/Ops

An audit checklist built around these three phases keeps the process from collapsing into a single frantic pre-launch review, and post-implementation audit practices help you catch drift once the system is live and quietly evolving away from its original documentation.

How Botiqueai Approaches GDPR Compliance in AI Projects

We build AIPD drafting into the project plan from the first workshop, not as a document someone assembles after the model works. Every chatbot and automation we deploy for a client starts with a data mapping exercise and a documented lawful basis before a single training file gets touched. Compliance-by-design isn’t a slogan for us. It’s the difference between a project CNIL can review calmly and one that generates panic six months post-launch.

— Botiqueai

Get a GDPR-Ready AI Chatbot Built for Your Business

Botiqueai is the alternative to bolting compliance onto an AI project after the fact. Where a generic chatbot build treats privacy as an afterthought, our Aria AI Chatbot is engineered with privacy-by-design from the first data mapping session, so the documentation you’d need to show CNIL already exists instead of getting reconstructed under deadline pressure.

Botiqueai

Aria handles customer conversations on your website or e-commerce store, whether you run Shopify, WordPress, or WhatsApp, with the lawful-basis and data-minimization work already built into how it’s configured for your business. Beyond Aria, our broader AI consulting services cover custom chatbots, workflow automation, and predictive analytics with the same compliance-first approach described throughout this guide. If your current AI project needs a compliance audit or you’re planning a new deployment, request a pilot consultation with our team and get a concrete assessment of where your documentation stands today.

Sources

© 2026 BotiqueAI — Reproduction prohibited without attribution.