Résumez cet article avec :
- Le Zero Data Retention ne signifie pas simplement que vos données ne sont pas utilisées pour l’entraînement des modèles. Un fournisseur d’API d’IA peut exclure vos données de l’entraînement tout en conservant les prompts, fichiers et sorties générées dans ses logs pendant plusieurs jours ou plusieurs semaines.
- La conservation par défaut des données via une API d’IA crée un risque côté fournisseur. Les prompts et réponses stockés peuvent augmenter l’exposition aux violations de données, aux demandes judiciaires et aux risques de non-conformité, en particulier pour les cas d’usage dans le juridique, la santé, la finance ou les ressources humaines.
- La minimisation des données est nécessaire, mais elle ne suffit pas. Vous pouvez supprimer les données personnelles non indispensables avant l’appel API, mais vous avez toujours besoin du Zero Data Retention pour contrôler ce que le fournisseur conserve après le traitement.
- Le Zero Data Retention doit être vérifié contractuellement. Analysez le DPA ou le MSA pour confirmer les endpoints couverts, les modèles concernés, la durée de conservation, le traitement des entrées et sorties, les logs d’erreur, les nouvelles tentatives et les sous-traitants impliqués.
Une entreprise de logiciel de santé connecte une API d’IA pour résumer les tickets de support patients. L’intégration fonctionne bien, la qualité des réponses est solide et les équipes techniques avancent vite. Ce n’est que plus tard que l’équipe conformité réalise que chaque prompt et chaque sortie générée ont peut-être été stockés par le fournisseur pendant 30 jours.
C’est tout l’enjeu du Zero Data Retention pour les API d’IA. Pour les équipes soumises au RGPD, à HIPAA, à SOC 2, à ISO 27001 ou à des exigences internes de protection des données, comprendre comment les données envoyées à une API d’IA sont stockées est désormais un critère de mise en production, et non un simple détail juridique.
Cet article explique ce que signifie le Zero Data Retention pour les API d’IA, pourquoi il est important pour les entreprises et les cas d’usage réglementés, en quoi il diffère du principe de non-entraînement des modèles, ce qu’il protège, ce qu’il ne protège pas, ainsi que les contrôles techniques, juridiques et fournisseurs à vérifier avant de déployer des API d’IA en production.
Qu’est-ce que le Zero Data Retention (ZDR) dans les API d’IA ?
Le Zero Data Retention dans les API d’IA signifie que le fournisseur traite les entrées et les sorties client uniquement pour exécuter la requête API, puis ne conserve pas ce contenu une fois la réponse renvoyée.
Pour les équipes qui utilisent des API LLM, des API d’IA générative, des API OCR, des API speech-to-text, ou des API de traitement documentaire, cela concerne généralement les données d’inférence sensibles : prompts, réponses générées, fichiers importés, texte extrait, embeddings, métadonnées et sorties de modèle.
Au niveau de l’infrastructure, le Zero Data Retention signifie que la requête peut transiter par les systèmes du fournisseur, mais qu’elle ne doit pas être écrite dans un stockage persistant. En pratique, cela implique :
- Aucun prompt brut stocké dans les logs applicatifs
- Aucun fichier importé conservé dans un stockage objet
- Aucune sortie de modèle enregistrée en base de données
- Aucune donnée client réutilisée pour l’analytics, l’évaluation, le fine-tuning ou l’entraînement
C’est pourquoi l’expression “traité uniquement en mémoire” ne doit pas être mal interprétée. Elle ne signifie pas que le fournisseur ne manipule jamais les données. Elle signifie que les données sont traitées temporairement pour exécuter la requête et ne doivent pas persister ensuite.
Pour les cas d’usage réglementés ou sensibles d’un point de vue sécurité, cette distinction est essentielle. Des prompts, fichiers ou sorties conservés peuvent toujours créer des risques de conformité, de confidentialité et de violation de données, même si le fournisseur n’utilise pas ces données pour entraîner ses modèles.
Le ZDR est aussi différent du principe de non-entraînement sur vos données. Un fournisseur peut s’engager à ne pas utiliser les données client pour l’entraînement des modèles, tout en conservant des prompts, sorties, fichiers ou métadonnées à des fins de débogage, de surveillance des abus, d’amélioration du service ou de conformité légale.
Pour les entreprises soumises au GDPR, à HIPAA, à SOC 2, à ISO 27001, aux règles des services financiers ou à des politiques internes de protection des données, ces données conservées représentent toujours un risque à évaluer avant tout déploiement en production.
Le Zero Data Retention couvre uniquement la partie fournisseur de l’intégration avec l’API d’IA. Votre propre application, backend, proxy, stack d’observabilité, outils de monitoring d’erreurs, data warehouse ou système de support client peuvent encore journaliser les prompts et les sorties s’ils sont configurés ainsi.
Pour appliquer une logique de Zero Data Retention de bout en bout, les équipes doivent donc aussi mettre en place des règles internes de journalisation, de redaction, de contrôle d’accès, de minimisation des données, de durée de conservation et de suivi des flux de données liés aux requêtes d’IA dans leur propre infrastructure.
Que deviennent vos données sans Zero Data Retention ?
Sans Zero Data Retention, votre fournisseur d’API d’IA peut conserver les données client après la fin de l’appel API. Par exemple, certaines API d’IA peuvent conserver les entrées et les sorties pendant plusieurs jours, voire jusqu’à 30 jours, afin d’assurer le service, surveiller les abus ou répondre à des obligations internes.
En pratique, cela signifie que les prompts, les fichiers importés et les réponses générées par le modèle peuvent rester dans des systèmes contrôlés par le fournisseur, même après que votre application a reçu la réponse.
Les données stockées augmentent les risques de violation et de demande légale
Si les données client sont stockées, elles deviennent potentiellement accessibles, consultables et exposées.
Une équipe juridique qui envoie des clauses contractuelles à une API d’IA, une entreprise de santé qui traite des messages patients ou une plateforme RH qui analyse des notes de candidats ne fait pas seulement appel à un modèle. Elle peut aussi créer une copie temporaire de données sensibles dans un système tiers.
Ces données peuvent ensuite devenir concernées par une violation de données, une revue d’accès interne, une demande légale, une assignation ou une procédure de discovery.
Les données stockées augmentent les risques de violation et de demande légale
Si les données client sont stockées, elles deviennent potentiellement accessibles, consultables et exposées.
Une équipe juridique qui envoie des clauses contractuelles à une API d’IA, une entreprise de santé qui traite des messages patients ou une plateforme RH qui analyse des notes de candidats ne fait pas seulement appel à un modèle. Elle peut aussi créer une copie temporaire de données sensibles dans un système tiers.
Ces données peuvent ensuite devenir concernées par une violation de données, une revue d’accès interne, une demande légale, une assignation ou une procédure de discovery.
La conservation par défaut peut entrer en conflit avec la minimisation des données du RGPD
Pour les entreprises européennes, la conservation par défaut des données par une API d’IA peut aussi poser un problème au regard du principe de minimisation des données du RGPD. L’article 5 du RGPD exige que les données personnelles soient adéquates, pertinentes et limitées à ce qui est nécessaire au regard de la finalité du traitement.
Si une API d’IA n’a besoin des données client que pour générer une réponse, conserver les mêmes prompts, fichiers ou sorties pendant 30 jours peut être difficile à justifier dans des cas d’usage réglementés.
Ce point devient particulièrement sensible lorsque l’API traite des données client, des données employés, des documents financiers, des contrats juridiques, des informations de santé ou d’autres données personnelles.
Les infractions graves au RGPD peuvent entraîner des amendes allant jusqu’à 20 millions d’euros ou 4 % du chiffre d’affaires annuel mondial, le montant le plus élevé étant retenu. Cela ne signifie pas que chaque problème de conservation entraîne le même niveau de risque, mais cela confirme que la rétention des données doit être vérifiée avant tout déploiement d’API d’IA en production.
ZDR et conformité : RGPD, HIPAA et EU AI Act
RGPD : le ZDR renforce la limitation de conservation et le privacy by design
Le Zero Data Retention répond à deux exigences clés du RGPD : l’article 5(1)(e) sur la limitation de la conservation et l’article 25 sur la protection des données dès la conception et par défaut. L’article 5(1)(e) impose de ne conserver les données personnelles que pendant la durée nécessaire, tandis que l’article 25 exige de limiter l’exposition des données personnelles dès la conception des systèmes.
L’exposition aux sanctions est significative. Les violations du RGPD peuvent entraîner des amendes allant jusqu’à 20 millions d’euros ou 4 % du chiffre d’affaires annuel mondial, le montant le plus élevé étant retenu. En 2025, les autorités européennes de protection des données ont prononcé environ 1,2 milliard d’euros d’amendes liées au RGPD.
Le ZDR aide les entreprises à réduire ce risque en garantissant que les prompts, fichiers et sorties contenant des données personnelles ne sont pas conservés par le fournisseur d’API d’IA après traitement.
HIPAA : le ZDR réduit l’exposition des PHI dans les environnements fournisseurs
Le Zero Data Retention soutient les contrôles HIPAA liés aux Protected Health Information, aux Business Associate Agreements et à la Breach Notification Rule prévue par 45 CFR §§ 164.400-414.
Les sanctions HIPAA varient selon le niveau de responsabilité. En 2026, les pénalités civiles vont de 145 dollars par violation à 2 190 294 dollars pour les violations les plus graves liées à une négligence volontaire, avec des plafonds annuels par catégorie de violation.
Le ZDR permet de limiter la quantité de données de santé protégées conservées dans l’environnement d’un fournisseur ou d’un sous-traitant. Cela réduit l’exposition en cas de violation de données et simplifie l’analyse des risques liés aux partenaires commerciaux.
EU AI Act : le ZDR améliore la gouvernance de la chaîne d’approvisionnement IA
Pour les systèmes d’IA à haut risque, le Zero Data Retention soutient les exigences de l’article 10 de l’EU AI Act relatives à la gouvernance des données, ainsi que les contrôles plus larges liés à la qualité des données, à la traçabilité et à la supervision des systèmes.
L’exposition aux sanctions dans le cadre de l’EU AI Act peut atteindre 35 millions d’euros ou 7 % du chiffre d’affaires annuel mondial pour les pratiques interdites, et 15 millions d’euros ou 3 % du chiffre d’affaires annuel mondial pour de nombreux autres cas de non-conformité. Le règlement est entré en vigueur en août 2024, avec des obligations relatives aux modèles d’IA à usage général applicables à partir d’août 2025, puis la majorité des obligations à partir d’août 2026.
Le ZDR aide à limiter la conservation non maîtrisée de données opérationnelles sensibles dans la chaîne d’approvisionnement IA.
Si votre organisation est soumise au RGPD, à HIPAA ou à l’EU AI Act, le Zero Data Retention ne doit pas être considéré comme une option secondaire. Pour les workloads IA réglementés, c’est un critère de base dans le choix d’un fournisseur.
Zero Data Retention vs minimisation des données : quelle différence ?
La minimisation des données et le Zero Data Retention répondent à deux parties différentes du même risque.
La minimisation des données est un principe du RGPD qui impose de transmettre uniquement les données nécessaires à une finalité précise. Dans un workflow IA, cela signifie supprimer les données personnelles non indispensables avant l’appel API : noms, identifiants, coordonnées, identifiants financiers ou tout autre champ dont le modèle n’a pas besoin.
Le ZDR intervient ensuite. Il contrôle ce que le fournisseur d’API d’IA conserve une fois la requête traitée. Une entreprise peut appliquer une minimisation stricte des données et rester exposée si le fournisseur stocke le prompt, le fichier ou la sortie générée dans ses logs pendant 30 jours.
Cette distinction est essentielle dans les environnements réglementés, car des données minimisées peuvent rester sensibles. Une entreprise de santé peut retirer le nom d’un patient et son numéro d’assurance avant d’envoyer un résumé de dossier à un LLM. Mais si ce résumé contient encore des symptômes, des antécédents de diagnostic ou un contexte de traitement, il reste une donnée de santé sensible. Si le fournisseur d’API la conserve, l’entreprise garde une exposition côté fournisseur.
Le point clé pour les achats et la conformité est simple : la minimisation des données ne remplace pas le Zero Data Retention. Posez deux questions séparées : quelles données envoyons-nous ? et que conserve le fournisseur après traitement ? Pour l’IA en entreprise, ces deux contrôles sont nécessaires.
Comment les principaux fournisseurs d’IA gèrent le Zero Data Retention
La tendance est assez claire chez les principaux fournisseurs d’API d’IA : le Zero Data Retention n’est généralement pas le mode par défaut. Il nécessite souvent une approbation spécifique, un accès enterprise ou scale-tier, ainsi qu’une vérification précise des endpoints utilisés.
Pour les équipes achats, sécurité et conformité, la bonne question n’est pas seulement : “Ce fournisseur propose-t-il le ZDR ?” Il faut plutôt demander : “Quels modèles, endpoints, outils et régions sont exactement couverts par le Zero Data Retention dans notre contrat ?”
Comment Eden AI met en œuvre le Zero Data Retention
Eden AI met en œuvre le Zero Data Retention au niveau de sa passerelle d’IA. Plutôt que de connecter chaque application directement à chaque fournisseur de modèles, l’entreprise envoie ses requêtes IA via Eden AI, qui applique les contrôles de rétention et de routage avant que la requête n’atteigne le modèle sous-jacent sélectionné.
Cette approche est importante, car le ZDR n’est pas seulement une fonctionnalité fournisseur. C’est une couche d’application et de contrôle sur toute la chaîne d’approvisionnement IA. Eden AI centralise la gestion des prompts, fichiers, sorties, métadonnées de routage et accès aux fournisseurs, afin que les équipes n’aient pas à négocier et surveiller un niveau de rétention différent pour chaque intégration de modèle.
L’offre Zero Data Retention d’Eden AI inclut :
- Suppression des données sous 24 heures
- Endpoint européen disponible pour la résidence des données en Europe
- Aucune utilisation des données client pour l’entraînement des modèles
- Certifications SOC 2 Type II et ISO 27001
- Documentation DPA compatible RGPD incluse
L’avantage opérationnel est clair : plus de contrôle. Les équipes disposent d’un seul contrat, d’une piste d’audit centralisée et d’un socle de conformité commun pour les différents fournisseurs d’IA utilisés via Eden AI, au lieu de maintenir des politiques séparées pour chaque fournisseur.
Vous pouvez consulter la documentation d’Eden AI sur la conformité des données à l’adresse edenai.co/data-compliancy ou commencer directement avec l’endpoint européen.
Comment vérifier qu’une API d’IA propose réellement le Zero Data Retention
Le Zero Data Retention est souvent revendiqué, mais rarement vérifié en détail. Beaucoup de fournisseurs d’API d’IA affirment proposer le ZDR, mais tous ne précisent pas clairement quels endpoints, modèles, logs, retries et sous-traitants sont réellement couverts.
Utilisez cette checklist lors de l’évaluation d’un fournisseur :
- Le Zero Data Retention est-il activé par défaut, ou nécessite-t-il un accord séparé, une approbation spécifique ou un plan enterprise ?
- Quels endpoints, modèles, outils et fonctionnalités sont couverts par le ZDR ? Lesquels sont exclus ?
- Existe-t-il un DPA signé ou un document contractuel qui mentionne explicitement le ZDR et définit la durée de conservation ?
- En combien de temps les prompts, fichiers, sorties et contenus associés sont-ils supprimés après traitement ?
- Le ZDR s’applique-t-il à la fois aux entrées et aux sorties, y compris les fichiers importés, les system prompts, le contexte récupéré et les réponses du modèle ?
- Que se passe-t-il en cas d’erreur système, de requête échouée, de retry, de surveillance des abus ou de débogage par le support ? Le contenu client est-il journalisé dans ces cas ?
Si un fournisseur ne peut pas répondre clairement par écrit à ces six questions, le Zero Data Retention n’est pas pleinement vérifiable. Le site web peut afficher “Zero Data Retention”, mais ce sont le contrat et l’architecture technique qui déterminent le niveau de risque réel.

.jpg)

.png)
