IA générative en entreprise : déploiement, RGPD et AI Act en 2026

Déployer une IA générative en entreprise ne consiste pas à ouvrir un compte, puis à laisser chacun improviser. Il faut partir d’un besoin précis, choisir un service compatible avec les données concernées, encadrer les usages, tester les résultats et attribuer les décisions à des personnes identifiées. En 2026, cette discipline devient aussi une question de conformité : le RGPD continue de s’appliquer aux traitements de données personnelles et plusieurs dispositions du règlement européen sur l’intelligence artificielle, ou AI Act, deviennent applicables.

Ce guide propose une méthode concrète pour une entreprise établie en France. Il distingue les obligations juridiques des mesures de prudence, car une bonne pratique n’est pas automatiquement une obligation et un abonnement professionnel ne rend pas automatiquement un usage conforme. Les règles sectorielles, le droit du travail, la propriété intellectuelle, le secret professionnel et les contrats peuvent ajouter d’autres exigences.

Sommaire

1. Comprendre le périmètre
2. Calendrier de l’AI Act en 2026
3. Fournisseur, déployeur et rôles RGPD
4. Cartographier les usages et les risques
5. Protéger les données personnelles
6. Informer et étiqueter les contenus
7. Choisir un fournisseur
8. Sécuriser les prompts, le RAG et les agents
9. Organiser la supervision humaine
10. Évaluer avant de généraliser
11. Plan d’action 30/60/90 jours
12. Modèles pratiques
13. Checklist de déploiement
14. FAQ
15. Conclusion
16. Sources officielles

1. Comprendre le périmètre avant de choisir un outil

Une IA générative produit ou transforme du texte, du code, des images, de l’audio ou de la vidéo à partir d’instructions et de données. Elle peut résumer un document, préparer un brouillon, extraire des champs ou proposer des options. Elle reste probabiliste : une réponse fluide peut être inexacte, incomplète ou fondée sur une source dépassée. La CNIL rappelle que ces modèles ne sont pas des bases de connaissance et qu’une confiance excessive peut conduire à des décisions erronées.

Le bon point de départ n’est donc pas « quel est le meilleur modèle ? », mais « quel résultat devons-nous obtenir, avec quelles données et quelles conséquences en cas d’erreur ? ». Un outil adapté à la reformulation de textes publics peut être inadapté à l’analyse de dossiers de salariés. Un assistant utile pour préparer une réponse ne doit pas nécessairement être autorisé à l’envoyer.

Trois niveaux à distinguer

• L’assistance : une personne fournit la demande, examine la sortie et reste responsable de l’action. Exemple : produire un premier plan de présentation.
• Le workflow : le modèle intervient dans une procédure définie par du code et des règles. Exemple : extraire des champs, puis envoyer les cas incomplets en revue.
• L’agent : le système choisit des outils et enchaîne plusieurs actions avec une certaine autonomie. Exemple : consulter une base, créer un ticket et proposer un message. Consultez aussi le guide des agents IA et de MCP.

Chaque niveau supplémentaire augmente la surface d’erreur, le coût de contrôle et les droits techniques nécessaires. Une entreprise mature ne recherche pas l’autonomie maximale. Elle recherche le niveau minimal d’autonomie qui apporte une valeur mesurable sans dépasser son seuil de risque.

2. Le calendrier de l’AI Act à connaître en 2026

L’AI Act suit une approche fondée sur les risques. Toutes les utilisations d’IA générative ne deviennent pas des systèmes à haut risque. Les obligations dépendent du système, de sa finalité, du rôle de l’organisation et du contexte d’utilisation. La Commission européenne publie un calendrier consolidé, actualisé après l’entrée en vigueur du Digital Omnibus sur l’IA en juillet 2026.

Repère temporel durable : cet article est vérifié le 2 août 2026. L’article 50 est applicable à compter de cette date. La Commission a publié le 20 juillet 2026 ses lignes directrices sur ces obligations de transparence.

La culture de l’IA n’est pas une formation unique

L’article 4 impose aux fournisseurs et aux déployeurs de prendre des mesures pour soutenir le développement de la culture de l’IA de leur personnel et des autres personnes qui exploitent ou utilisent leurs systèmes pour leur compte. Ces mesures doivent tenir compte des connaissances techniques, de l’expérience, de l’éducation et de la formation de ces personnes, du contexte d’utilisation ainsi que des personnes ou groupes sur lesquels les systèmes sont destinés à être utilisés. Depuis la modification entrée en vigueur le 27 juillet 2026, aucun niveau individuel universel dit « suffisant » n’est garanti ni imposé.

Une sensibilisation générale peut convenir à un salarié qui reformule des textes publics. Une équipe qui configure un RAG, traite des données clients ou autorise des actions dans le système d’information a besoin d’une formation technique et procédurale plus poussée. Documenter les publics, les contenus, les dates et les contrôles constitue une preuve plus utile qu’un simple taux de présence.

3. Fournisseur, déployeur et rôles RGPD : ne pas les confondre

Au sens de l’AI Act, le fournisseur développe un système, ou le fait développer, puis le met sur le marché ou en service sous son nom ou sa marque. Le déployeur utilise un système d’IA sous son autorité dans un cadre professionnel. L’utilisation strictement personnelle et non professionnelle est exclue de cette définition. Dans une société, les salariés agissant sous les instructions et le contrôle de l’employeur ne deviennent pas chacun des déployeurs séparés : la personne morale demeure le déployeur. Ces distinctions sont précisées par la FAQ de la Commission sur l’article 50.

Une entreprise devient fournisseur si elle fait développer un système et le met sur le marché ou en service sous son nom ou sa marque. Pour les systèmes à haut risque, l’article 25 prévoit aussi certains changements de rôle, notamment en cas de modification substantielle ou de changement de finalité faisant devenir un système à haut risque. Un simple utilisateur d’un service standard n’a pas les mêmes responsabilités qu’un intégrateur qui ajuste le modèle, ajoute des outils et contrôle sa mise à disposition.

Les qualifications du RGPD suivent une autre logique

Le responsable du traitement détermine les finalités et les moyens essentiels d’un traitement de données personnelles. Le sous-traitant traite les données pour son compte et selon ses instructions. Deux acteurs peuvent aussi déterminer ensemble certaines finalités et certains moyens. Les intitulés commerciaux ne suffisent pas : les rôles se déduisent des faits, du contrat et des décisions réellement prises.

Situation	Lecture AI Act fréquente	Question RGPD à trancher
Un salarié utilise un assistant autorisé pour résumer un document interne	L’entreprise est généralement déployeur	Qui décide de la finalité, quelles données sont envoyées et quel est le rôle du fournisseur ?
Une entreprise connecte l’assistant à sa base documentaire	Déployeur, avec analyse supplémentaire selon l’intégration	L’entreprise est responsable du traitement de sa base lorsqu’elle contient des données personnelles
Une société ajuste un modèle sur ses propres données puis le vend sous sa marque	Elle peut devenir fournisseur pour le système concerné	Responsabilités liées aux données d’ajustement, aux utilisateurs et aux destinataires
Un prestataire exécute un traitement strictement selon les instructions du client	Rôle AI Act à examiner selon le service	Il peut être sous-traitant, avec contrat conforme à l’article 28 du RGPD

4. Cartographier les usages, les données et les conséquences

Une charte générale ne suffit pas si personne ne sait où l’IA est utilisée. Recensez les outils officiels, les essais locaux, les API, les extensions de navigateur, les assistants intégrés aux logiciels métiers et les comptes individuels. Incluez les usages invisibles : traduction, transcription, génération de code, enrichissement de CRM et prise de notes.

Pour chaque cas, décrivez l’entrée, la sortie, les personnes concernées, les destinataires, les connexions, la durée de conservation et l’action qui suit. Classez ensuite le risque interne selon quatre axes : sensibilité des données, conséquence d’une erreur, autonomie technique et difficulté de détection.

Cas d’usage	Risque dominant	Point de départ raisonnable
Idées de titres depuis des informations publiques	Qualité éditoriale, propriété intellectuelle	Revue humaine et règles de marque
Résumé de procédures internes non sensibles	Confidentialité, omission	Espace approuvé, test de fidélité, interdiction de décision automatique
RAG sur des dossiers clients	Données personnelles, droits d’accès, fuite entre utilisateurs	Analyse RGPD, contrôle d’accès par document, citations, tests d’isolation
Présélection de candidats	Discrimination, droits des personnes, règles sectorielles	Ne pas lancer comme simple pilote bureautique ; expertise juridique et métier préalable
Agent qui envoie, achète ou supprime	Action irréversible, compromission, fraude	Droits minimaux, simulation, approbation obligatoire et plafond d’action

5. RGPD : protéger les données avant, pendant et après le prompt

Un prompt peut contenir des données personnelles même sans numéro de sécurité sociale. Un nom, une adresse électronique, une voix, une photographie, un identifiant, une appréciation professionnelle ou un récit permettant de reconnaître une personne peuvent suffire. Les pièces jointes, l’historique, les journaux techniques, les résultats et les retours utilisateurs peuvent également en contenir.

Avant tout déploiement, appliquez la séquence suivante. La CNIL recommande de partir d’un besoin concret, d’encadrer les usages autorisés et interdits, de choisir un mode de déploiement adapté, de former les utilisateurs et d’associer les parties prenantes.

1. Définir la finalité : formulez le résultat métier sans invoquer seulement l’innovation ou la productivité.
2. Identifier les données : sources, catégories, personnes, sensibilité, volume, fréquence et destinataires.
3. Déterminer la base légale : le consentement n’est pas la réponse automatique. La base dépend du traitement réel.
4. Minimiser : retirez les champs inutiles, préférez des exemples synthétiques et limitez le contexte transmis.
5. Informer : adaptez l’information aux personnes concernées et aux usages, puis organisez l’exercice de leurs droits.
6. Qualifier les acteurs : responsable, sous-traitant, responsables conjoints et sous-traitants ultérieurs.
7. Encadrer le contrat : instructions, confidentialité, sécurité, assistance, suppression, audit, incident et sort des données à la fin du service.
8. Contrôler les transferts : identifiez les lieux de traitement et le mécanisme applicable en dehors de l’Espace économique européen.
9. Fixer les durées : conversation, fichiers, logs, sauvegardes, évaluations et comptes supprimés.
10. Tenir le registre : lorsque l’article 30 du RGPD l’exige, inscrivez finalités, catégories de données et de personnes, destinataires, transferts, durées et mesures de sécurité.
11. Évaluer le risque : réalisez une AIPD avant le traitement lorsqu’il est susceptible d’engendrer un risque élevé pour les droits et libertés.

Examinez aussi l’article 22 du RGPD lorsqu’une sortie participe à une décision produisant des effets juridiques ou affectant significativement une personne. Une validation humaine purement formelle ne suffit pas toujours à faire disparaître le caractère automatisé : le réviseur doit pouvoir comprendre, contester et modifier réellement la décision.

Anonymiser n’est pas seulement masquer un nom

Remplacer « Sophie Martin » par « salariée A » constitue souvent une pseudonymisation : une fonction rare, un lieu, une date et un événement peuvent encore permettre la réidentification. Des données réellement anonymes ne doivent plus permettre d’identifier raisonnablement une personne. Pour apprendre à filtrer une demande avant de l’envoyer, consultez la leçon Protéger les données et vérifier les réponses.

RAG et ajustement : vos données restent votre responsabilité

Connecter un modèle à une base documentaire par RAG peut améliorer l’actualité et les citations. Cela ne rend pas le traitement anonyme ni automatiquement conforme. La CNIL indique que le déployeur qui connecte sa propre base contenant des données personnelles est responsable du traitement correspondant. Il faut préserver les droits d’accès du système source, empêcher les fuites entre utilisateurs, limiter l’indexation et prévoir suppression et mise à jour. La leçon RAG fiable et cité détaille les contrôles de provenance.

L’ajustement d’un modèle sur des données internes pose encore d’autres questions : licéité du corpus, finalité, droits, sécurité, mémorisation et possibilité d’extraire des données. Ne choisissez pas cette voie simplement parce qu’un fournisseur la propose. Comparez-la à des instructions, des exemples, un RAG ou un workflow plus simple.

6. Article 50 : quand informer ou étiqueter ?

L’article 50 ne signifie pas que chaque phrase assistée par IA doit porter la même étiquette. Il distingue plusieurs situations et répartit les obligations entre fournisseurs et déployeurs. Les faits essentiels publiés par la Commission permettent de comprendre les quatre cas principaux.

Situation	Acteur principalement visé	Exigence à compter du 2 août 2026
Système conçu pour interagir directement avec une personne	Fournisseur du système	Conception permettant d’informer la personne qu’elle interagit avec une IA, sauf si cela est évident
Système générant ou manipulant du texte, de l’image, de l’audio ou de la vidéo	Fournisseur du système	Marquage lisible par machine et détection, sous réserve des conditions et limites techniques prévues
Reconnaissance des émotions ou catégorisation biométrique	Déployeur	Informer les personnes exposées, en plus des règles de protection des données
Deepfake, ou certains textes destinés à informer le public sur une question d’intérêt public	Déployeur	Divulguer clairement l’origine artificielle selon les conditions et exceptions applicables

L’information ou l’étiquette doit être fournie de manière claire et distincte, au plus tard lors de la première interaction ou de la première exposition, et respecter les exigences d’accessibilité applicables. Pour un deepfake, un marquage uniquement lisible par machine ne suffit pas à la divulgation visible ou audible due par le déployeur.

Le cas des textes d’intérêt public

L’obligation visant le déployeur concerne les textes générés ou manipulés par IA et publiés afin d’informer le public sur des questions d’intérêt public. Pour documenter l’exception, l’organisation devrait pouvoir établir soit une revue délibérée du fond par une ou plusieurs personnes disposant des connaissances et du jugement professionnel pertinents, soit un contrôle éditorial réel par une entité ayant le pouvoir d’approuver, de modifier ou de refuser le fond du texte. La responsabilité éditoriale ultime doit être assumée. Les vérifications uniquement orthographiques, grammaticales, formelles ou procédurales ne suffisent pas. Même lorsqu’une étiquette n’est pas exigée par ce dispositif, une transparence volontaire peut rester utile.

Une période transitoire très limitée

Le délai jusqu’au 2 décembre 2026 concerne uniquement les fournisseurs de systèmes d’IA, y compris à usage général, générant du texte, de l’image, de l’audio ou de la vidéo synthétiques et mis sur le marché avant le 2 août 2026, pour l’obligation de marquage et de détection de l’article 50(2). Il ne reporte pas globalement toutes les obligations de transparence. Les contenus produits avant le 2 août 2026 ne doivent pas être étiquetés rétroactivement, même si la Commission encourage la transparence lorsque cela est possible.

Décider en pratique : cinq questions avant la mise en ligne

Une entreprise ne devrait pas appliquer une étiquette unique à tout contenu assisté par IA. Elle doit d’abord qualifier la situation et le rôle qu’elle joue. Le chemin suivant transforme l’article 50 en revue opérationnelle, sans remplacer l’analyse du cas concret.

1. Une personne interagit-elle directement avec un système d’IA ? Vérifiez que l’information prévue par le fournisseur est claire dès la première interaction, sauf si le caractère artificiel est évident pour une personne normalement informée et attentive.
2. Le système génère-t-il ou manipule-t-il du texte, de l’image, de l’audio ou de la vidéo ? Demandez au fournisseur comment fonctionne le marquage lisible par machine et quelles limites techniques sont documentées.
3. Le contenu constitue-t-il un deepfake au sens du règlement ? Si vous le déployez, prévoyez une divulgation claire, visible ou audible, adaptée au support et accessible.
4. Le texte est-il publié pour informer le public sur une question d’intérêt public ? Si oui, examinez l’obligation de divulgation et l’exception liée à une revue humaine ou à un contrôle éditorial réel.
5. Pouvez-vous prouver la revue et la responsabilité ? Conservez le réviseur, sa compétence, les sources contrôlées, les modifications substantielles, la décision finale et la personne ou entité qui assume la responsabilité éditoriale.

Exemples de revue de transparence à adapter au cas réel

Situation	Question prioritaire	Trace utile
Chatbot d’assistance client	L’utilisateur est-il informé dès la première interaction ?	Capture du parcours, texte affiché et version du système
Vidéo synthétique représentant une personne réelle	La divulgation du caractère artificiel est-elle claire et accessible ?	Version publiée avec message visible ou audible
Note publique sur une politique locale	S’agit-il d’un texte d’intérêt public et la revue du fond est-elle réelle ?	Sources, corrections, approbateur et responsabilité éditoriale
Illustration interne fictive	Une autre obligation, règle sectorielle ou politique interne s’applique-t-elle ?	Qualification courte et décision documentée

Le guide d’actualité AI Act : obligations de transparence applicables depuis le 2 août 2026 détaille les lignes directrices de la Commission, les rôles et la période transitoire. Pour un contenu sensible, vérifiez le texte et les documents officiels au moment de la publication.

7. Choisir un fournisseur sans se fier à la page marketing

Comparez le produit exact, l’édition, la région et les fonctionnalités activées. Les conditions d’une application grand public peuvent différer de celles d’une API ou d’un espace professionnel du même éditeur. Les réglages peuvent aussi évoluer. Conservez une copie datée des documents et notez qui a validé la configuration.

• Données d’usage : sont-elles utilisées pour entraîner ou améliorer le service ? Quelle option permet de s’y opposer et à quel niveau ?
• Conservation : combien de temps pour les prompts, fichiers, sorties, journaux et sauvegardes ? Que signifie la suppression ?
• Localisation et transferts : où les données sont-elles traitées, par quelles entités et avec quelles garanties ?
• Sous-traitants ultérieurs : liste, procédure de modification, droit d’opposition et services concernés.
• Accès : SSO, MFA, rôles, séparation des espaces, comptes invités, révocation et export des journaux.
• Sécurité : chiffrement, gestion des vulnérabilités, notification d’incident, audit et certifications pertinentes pour votre contexte.
• Modèles et versions : préavis de changement, stabilité, région d’inférence, possibilité de figer une version et procédure de réévaluation.
• Réversibilité : export des données, suppression, récupération des prompts, dépendances et solution de sortie.
• Transparence AI Act : informations utiles au déployeur, marquage des contenus, limites documentées et assistance à la conformité.

Le comparatif ChatGPT, Claude, Gemini et Mistral aide à comparer les fonctions. Pour un achat, complétez toujours ce panorama par l’analyse contractuelle et technique propre à votre organisation.

Les fonctions de gouvernance doivent être testées, pas seulement cochées dans une brochure. Par exemple, Mistral Studio annonce depuis le 9 juillet 2026 des Prompts et Skills avec propriétaire, versions immuables, historique, retour arrière, étiquettes et journaux d’audit. Ces fonctions peuvent améliorer la traçabilité, mais elles ne démontrent ni la conformité du traitement ni la qualité de l’instruction. Vérifiez qui peut créer, partager, promouvoir, consulter les journaux et restaurer une version. L’analyse du versionnage des Prompts et Skills dans Mistral Studio fournit un exemple de grille.

Exiger une preuve de changement exploitable

Un modèle, un mode rapide, une politique de données ou un schéma d’outil peut changer sans que le texte du prompt soit modifié. Le registre interne doit relier la version active, la date, les résultats d’évaluation, l’approbateur et la possibilité de retour. Demandez aussi si le fournisseur prévient avant une suppression de modèle, s’il permet de tester le remplaçant et combien de temps l’ancienne version reste accessible.

Registre minimal de changement
Système et cas d’usage :
Produit, édition, modèle ou mode :
Version précédente et version candidate :
Changement annoncé et date d’effet :
Jeu de tests rejoué :
Résultats, écarts et risques bloquants :
Décision, approbateur et date :
Procédure de retour et responsable :

8. Sécuriser les prompts, le RAG, les connecteurs et les agents

Un modèle peut traiter une instruction hostile cachée dans une page Web, un courriel ou un document. Cette injection de prompt indirecte cherche à modifier son comportement, à obtenir des données ou à déclencher un outil. Aucun prompt système ne constitue à lui seul un pare-feu. La leçon Prompt injection, confidentialité et sécurité montre comment séparer instructions, données et autorisations.

Les recommandations de l’ANSSI pour un système d’IA générative préconisent notamment le cloisonnement, le filtrage des entrées et sorties, la maîtrise des interactions avec les applications, la limitation des actions automatiques issues d’entrées non maîtrisées et une journalisation adaptée. Ce sont des recommandations de sécurité à adapter au risque, pas un texte réglementaire universel.

1. Inventorier les flux : utilisateur, modèle, fichiers, recherche, connecteurs, API, outils, sorties et logs.
2. Appliquer le moindre privilège : un assistant de lecture n’a pas besoin d’écrire ; un agent de ticketing n’a pas besoin d’accéder à toute la messagerie.
3. Séparer les environnements : développement, test et production, avec données synthétiques autant que possible.
4. Isoler les sources non fiables : considérez le Web, les courriels et les documents externes comme des données, jamais comme des instructions autorisées.
5. Autoriser explicitement les outils : listes blanches, paramètres bornés, destinations approuvées et validation côté serveur.
6. Exiger une approbation : envoi externe, publication, paiement, suppression, modification de droits, signature ou extraction massive.
7. Limiter l’exécution : budget, nombre d’étapes, temps maximal, volume et conditions d’arrêt.
8. Valider la sortie : format, schéma, droits métier, destinations, pièces jointes et valeurs interdites.
9. Journaliser avec mesure : tracez les décisions et appels d’outils, mais protégez les journaux s’ils contiennent des secrets ou des données personnelles.
10. Prévoir l’incident : bouton d’arrêt, révocation des jetons, conservation des preuves, notification interne et procédure de retour au mode manuel.

Journaliser sans créer une nouvelle fuite

Pour reconstituer un incident, conservez la requête utile, les transformations, les appels aux données, les outils, les filtres et le résultat. Évitez toutefois de recopier sans limite des dossiers sensibles dans les logs. Définissez les accès, la durée, le chiffrement, l’intégrité et la procédure d’extraction. Une trace inexploitable ou accessible à tous n’apporte pas de contrôle réel.

9. Concevoir une supervision humaine qui puisse dire non

« Validé par un humain » ne décrit pas un contrôle. Nommez la personne ou le rôle, les preuves disponibles, le temps prévu, les critères de refus et le canal d’escalade. La personne doit comprendre la tâche et les limites du système, accéder aux sources et pouvoir corriger, suspendre ou annuler sans subir une pression de rendement incompatible avec la revue.

Niveau	Exemple	Contrôle attendu
Faible	Idées internes sans données sensibles	Relecture par l’auteur
Modéré	Résumé transmis à un client	Vérification des faits, du ton et des informations autorisées
Élevé	Analyse influençant une décision sur une personne	Expert compétent, dossier de preuve, procédure de recours et décision indépendante
Action technique	Agent qui modifie le SI	Aperçu exact de l’action, approbation forte, journal et possibilité de retour arrière

Pour les sorties factuelles, consultez la leçon Hallucinations : vérifier avant de faire confiance. Demander au même modèle de déclarer que sa réponse est correcte ne remplace ni la source originale, ni un calcul reproductible, ni une expertise appropriée.

10. Évaluer un pilote avant de le généraliser

Le NIST AI Risk Management Framework est volontaire et ne remplace pas le droit européen. Il fournit toutefois une méthode utile : gouverner, cartographier, mesurer et gérer les risques pendant tout le cycle de vie. Son profil consacré à l’IA générative insiste notamment sur la confabulation, la protection des données, l’intégrité de l’information, la sécurité, les relations humain-IA et la chaîne de fournisseurs.

Constituez un lot de tests représentatif avant le pilote : cas courant, cas incomplet, donnée sensible, document contradictoire, instruction hostile, demande hors périmètre et panne d’un outil. Fixez les critères avant d’observer les résultats pour éviter d’adapter les objectifs après coup.

• Utilité : taux de tâches réellement terminées et temps net économisé, revue comprise.
• Fidélité : affirmations soutenues, citations correctes, calculs reproductibles et abstention lorsque l’information manque.
• Sécurité : secrets révélés, outils mal appelés, accès interdits et injections réussies.
• Conformité : données minimisées, information fournie, droits respectés, étiquetage appliqué et traces disponibles.
• Expérience : erreurs comprises, possibilité de corriger, accessibilité et charge de supervision.
• Exploitation : coût complet, latence, disponibilité, changement de modèle et retour au processus manuel.

Définissez un seuil de lancement, mais aussi un seuil d’arrêt. Une moyenne satisfaisante peut cacher une erreur rare mais grave. Les cas bloquants doivent être traités séparément et rester bloquants même si le score global est élevé.

11. Plan d’action 30/60/90 jours

Période	Actions	Livrables	Condition de passage
Jours 1 à 30 : cadrer	Nommer un sponsor et un responsable ; inventorier outils et usages ; choisir un cas borné ; cartographier données et acteurs ; interdire temporairement les usages non maîtrisés ; lancer l’analyse fournisseur et RGPD	Fiche de cas d’usage, registre initial, carte des flux, matrice de rôles, règles provisoires, critères de test	Données autorisées, propriétaire identifié, finalité claire, solution de repli et absence de risque bloquant non traité
Jours 31 à 60 : sécuriser et tester	Contractualiser ; configurer comptes et conservation ; créer le jeu de tests ; limiter les connecteurs ; former le groupe pilote ; tester erreurs, hallucinations et injections ; préparer réponse à incident	Configuration validée, dossier contractuel, AIPD si requise, résultats de tests, supports de formation, procédure d’incident	Seuils qualité atteints, aucun échec critique ouvert, approbations sensibles effectives et utilisateurs capables d’appliquer la charte
Jours 61 à 90 : piloter et décider	Ouvrir à un groupe limité ; mesurer valeur et incidents ; échantillonner les sorties ; corriger le workflow ; vérifier transparence ; préparer réversibilité ; décider lancement, prolongation ou arrêt	Tableau de bord, registre d’incidents, rapport de revue, décision signée, plan de surveillance et date de réévaluation	Valeur nette démontrée, risque résiduel formellement accepté par le responsable interne habilité et fonctionnement du mode dégradé confirmé

Ne généralisez pas parce que le pilote est apprécié. Vérifiez que la performance tient sur plusieurs équipes, que la supervision reste réaliste à plus grand volume et que les droits techniques ne s’élargissent pas silencieusement.

12. Cinq modèles pratiques à copier

Modèle 1 : fiche de cas d’usage

Nom du cas :
Propriétaire métier :
Résultat attendu :
Utilisateurs et personnes concernées :
Données autorisées :
Données interdites :
Sources et destinataires :
Action suivant la sortie :
Conséquence d’une erreur :
Contrôle humain et pouvoir de refus :
Outils et droits techniques :
Critères de réussite :
Erreurs bloquantes :
Durées de conservation :
Mode dégradé :
Date de validation et prochaine revue :

Modèle 2 : noyau d’une charte d’usage

Nous utilisons uniquement les services, comptes et connecteurs approuvés. Nous ne transmettons aucune donnée personnelle, confidentielle ou couverte par un secret sans autorisation documentée pour le cas concerné. Nous vérifions les faits, les sources, les calculs et les destinataires avant tout usage externe. Nous ne déléguons pas à l’IA une décision individuelle ou une action irréversible sans procédure validée. Toute anomalie, fuite présumée, instruction hostile ou action inattendue est signalée par le canal prévu. La personne responsable conserve le pouvoir de refuser, corriger et arrêter.

Ajoutez des exemples propres aux métiers. Une règle abstraite devient applicable lorsqu’un commercial sait si un compte rendu client est autorisé, lorsqu’un recruteur connaît les usages interdits et lorsqu’un développeur sait quel code ne doit pas quitter le dépôt.

Modèle 3 : questionnaire fournisseur

• Quel produit, quelle édition et quels modèles sont inclus ?
• Les entrées ou sorties servent-elles à l’entraînement, à l’évaluation humaine ou à l’amélioration ?
• Quelles données sont conservées, où, combien de temps et dans quelles sauvegardes ?
• Qui sont les sous-traitants ultérieurs et comment leurs changements sont-ils notifiés ?
• Quelles régions de traitement, garanties de transfert et options de résidence sont disponibles ?
• Quels contrôles d’accès, journaux, exports, suppressions et alertes administrateur existent ?
• Comment les contenus synthétiques sont-ils marqués et quelles informations de conformité sont fournies ?
• Quels changements de modèle peuvent intervenir sans accord et comment tester avant migration ?
• Quels engagements couvrent l’incident, la disponibilité, la réversibilité et la fin de contrat ?

Modèle 4 : fiche de revue d’une sortie

Identifiant de la sortie :
Modèle, version et date :
Sources fournies au système :
Faits vérifiés et preuves :
Calculs reproduits :
Données personnelles ou secrets présents :
Biais ou personnes affectées :
Étiquette ou information requise :
Action autorisée : publier / corriger / escalader / refuser
Réviseur et compétence :
Motif et corrections :
Date de prochaine vérification :

Modèle 5 : signalement d’incident IA

Date, heure et déclarant :
Système, compte, modèle et connecteurs :
Événement observé :
Données et personnes potentiellement concernées :
Actions exécutées ou tentées :
Mesures immédiates : arrêt, révocation, isolement
Preuves conservées et accès protégés :
Équipes alertées : sécurité, DPO, juridique, métier
Notifications à évaluer :
Cause et mesures correctives :
Responsable de clôture et date :

Ces modèles deviennent utiles lorsqu’ils sont reliés à un processus : responsable, délai, approbateur et emplacement de conservation. Un formulaire abandonné n’est pas une mesure de maîtrise.

13. Checklist avant ouverture

• Le besoin, le propriétaire et la décision visée sont écrits.
• Les outils et usages existants ont été inventoriés.
• Les rôles AI Act et RGPD ont été examinés séparément.
• Les données autorisées et interdites sont compréhensibles par les utilisateurs.
• La base légale, l’information et les droits sont traités si nécessaire.
• Le contrat, les sous-traitants, les transferts et la conservation sont validés.
• L’AIPD a été réalisée lorsque le risque élevé l’exige.
• Les paramètres empêchent la réutilisation non souhaitée des données.
• Les comptes disposent de MFA, de rôles et d’une révocation centralisée.
• Les connecteurs appliquent le moindre privilège et les droits du système source.
• Les actions sensibles exigent une approbation explicite.
• Les tests couvrent erreurs, données sensibles, injections, panne et cas hors périmètre.
• Les réviseurs ont preuves, temps, compétence et pouvoir de refus.
• Les obligations d’information et d’étiquetage sont documentées.
• La formation correspond aux risques et pas seulement à l’interface.
• Les journaux sont utiles, protégés et limités dans le temps.
• Le mode manuel, l’arrêt d’urgence et la réponse à incident ont été testés.
• Les seuils de lancement et d’arrêt sont décidés avant le pilote.
• Une date de réévaluation est prévue après tout changement important.

14. FAQ sur l’IA générative en entreprise

Faut-il étiqueter tous les textes rédigés avec une IA ?

Non. L’article 50(4) vise notamment les textes générés ou manipulés par IA, publiés pour informer le public sur des questions d’intérêt public, sous les conditions précisées par la Commission. Une véritable revue humaine ou un contrôle éditorial avec responsabilité peut ouvrir une exception. D’autres règles ou une politique interne peuvent néanmoins justifier une information dans des cas plus larges.

Une entreprise doit-elle interdire ChatGPT et les assistants similaires ?

Il n’existe pas d’interdiction générale de ces produits. L’entreprise doit analyser les cas d’usage, les données, le produit exact, les conditions contractuelles et les risques. Elle peut interdire temporairement les comptes non approuvés tout en proposant un espace encadré pour les usages autorisés.

Peut-on coller des données clients dans un assistant professionnel ?

Seulement si le traitement est autorisé et encadré : finalité, base légale, minimisation, information, contrat, sécurité, transferts et droits doivent être traités. Le mot « professionnel » dans l’offre ne suffit pas. Commencez par retirer les données inutiles et préférez un environnement validé.

Une offre Entreprise garantit-elle la conformité au RGPD ?

Non. Elle peut fournir les fonctions nécessaires, comme le contrôle administratif ou des engagements sur les données. La conformité dépend aussi du paramétrage et du traitement mis en œuvre par votre organisation.

Une AIPD est-elle toujours obligatoire ?

Non. Elle est obligatoire lorsque le traitement de données personnelles est susceptible d’engendrer un risque élevé pour les droits et libertés. L’usage innovant, les données sensibles, la grande échelle, les personnes vulnérables ou le croisement de données figurent parmi les critères à examiner. Lorsqu’un DPO a été désigné, associez-le aux questions de protection des données et demandez son avis sur l’AIPD, conformément aux articles 35(2) et 38 du RGPD.

Qui est le déployeur si les salariés utilisent l’outil ?

Lorsque l’outil est utilisé sous l’autorité d’une personne morale et que les salariés agissent selon ses instructions et son contrôle, l’organisation est généralement le déployeur. Les salariés ne deviennent pas chacun un déployeur indépendant pour ces actes.

Le RAG empêche-t-il les hallucinations ?

Non. Il peut fournir des documents récents et permettre des citations, mais la recherche peut sélectionner un mauvais passage et le modèle peut l’interpréter de travers. Évaluez la recherche et la réponse séparément, vérifiez les citations et autorisez l’abstention.

La pseudonymisation rend-elle les données anonymes ?

Pas nécessairement. Si une personne peut encore être reliée aux données à l’aide d’informations supplémentaires, elles restent personnelles. La combinaison de détails indirects peut aussi permettre une réidentification.

Un humain dans la boucle suffit-il à réduire le risque ?

Seulement s’il peut contrôler utilement. Il doit comprendre la tâche, disposer des sources, avoir assez de temps et pouvoir refuser. Une approbation mécanique après une longue série de sorties ne constitue pas une garantie sérieuse.

Faut-il un diplôme ou un certificat de culture de l’IA ?

L’AI Act n’impose pas un certificat universel ni un niveau identique pour tous. Les mesures doivent être adaptées aux personnes, au contexte et aux risques. Conservez une trace des besoins, contenus, publics, exercices et améliorations.

Quels documents conserver pour démontrer la maîtrise ?

Conservez une documentation proportionnée : registre des cas d’usage, qualification des rôles, analyse des données, contrat et configuration, AIPD si nécessaire, tests, décisions, formations, incidents, changements de modèle et revues. Les durées doivent rester compatibles avec le RGPD et les autres obligations applicables.

15. Passer de l’expérimentation à une capacité maîtrisée

Une politique efficace n’est ni une interdiction générale, ni une promesse d’automatisation totale. C’est un système de décisions : quel usage mérite un pilote, quelles données peuvent circuler, qui contrôle, comment mesurer, quand arrêter et comment corriger. Les entreprises qui répondent clairement à ces questions peuvent exploiter l’IA générative sans transformer chaque nouveauté en risque invisible.

Pour poursuivre, consultez le guide complet de l’intelligence artificielle générative, le guide du prompt engineering, le comparatif des assistants IA et le guide des agents IA et de MCP.

Sources officielles

• Règlement (UE) 2024/1689, texte initial de l’AI Act.
• Règlement (UE) 2026/1744, Digital Omnibus sur l’IA entré en vigueur le 27 juillet 2026.
• Règlement (UE) 2016/679, règlement général sur la protection des données.
• Commission européenne, Navigating the AI Act, calendrier et obligations générales, mise à jour du 27 juillet 2026.
• Commission européenne, lignes directrices sur les obligations de transparence, 20 juillet 2026.
• Commission européenne, FAQ sur l’article 50, rôles, champ, revue humaine et période transitoire.
• Commission européenne, questions-réponses sur la culture de l’IA, mise à jour de juillet 2026.
• CNIL, Comment déployer une IA générative ?, gouvernance et précautions.
• CNIL, questions-réponses sur l’utilisation d’un système d’IA générative, données, contrats, transferts, RAG et limites.
• CNIL, Réaliser une analyse d’impact si nécessaire, critères et démarche AIPD.
• CNIL et Conseil de l’IA et du Numérique, note sur l’IA agentique et les données personnelles, 20 juillet 2026.
• ANSSI, Recommandations de sécurité pour un système d’IA générative, version 1.0.
• NIST, AI Risk Management Framework, cadre volontaire de gestion des risques.
• NIST AI 600-1, Generative Artificial Intelligence Profile, risques et actions pour l’IA générative.
• Mistral, registre de Prompts et Skills dans Studio, 9 juillet 2026.

Dernière vérification factuelle : 2 août 2026.