Comment le règlement européen redessine la gouvernance des copilotes internes
Un copilote mis à disposition des salariés ne peut plus être piloté comme une simple fonctionnalité de productivité. Avec la montée en application de l’AI Act, la gouvernance des copilotes internes devient un sujet de responsabilités, de transparence, de supervision et de preuve : il faut savoir quel outil est utilisé, par qui, sur quelles données, pour quelle décision et avec quels contrôles.
Le changement est particulièrement concret à compter du 2 août 2026, date à laquelle les règles de transparence de l’AI Act s’appliquent dans l’Union européenne. Pour un responsable projet, un DSI, un product owner ou une direction métier, l’enjeu n’est pas de freiner tous les usages génératifs : il est d’organiser des usages utiles, limités à ce qui est maîtrisable et documentables face aux équipes, aux autorités compétentes et, selon les cas, aux représentants des travailleurs.
La gouvernance des copilotes internes en une réponse
La gouvernance des copilotes internes consiste à attribuer des responsabilités claires, classer les cas d’usage, informer les utilisateurs, encadrer les contenus générés, assurer une supervision humaine, conserver les éléments de traçabilité nécessaires et contrôler les fournisseurs. Dans l’UE, l’organisation qui met le copilote à disposition de ses salariés est généralement concernée comme deployer au sens de l’AI Act.
Cette définition est volontairement opérationnelle. Elle évite deux erreurs fréquentes : considérer que l’éditeur du modèle porte seul la conformité, ou supposer qu’un outil utilisé uniquement en interne échappe aux règles. La Commission européenne précise que les obligations de transparence visent à la fois les fournisseurs et les déployeurs d’IA.
Le mot « interne » ne fait donc pas disparaître le besoin de conformité. Il modifie surtout le périmètre à examiner : accès des collaborateurs, données injectées dans les requêtes, sorties exploitées dans les processus de travail, droits accordés au système et impact potentiel sur les personnes.
Un assistant conversationnel qui répond à des questions sur une base documentaire interne soulève des sujets d’accès, de qualité des sources et d’information des utilisateurs.
Un outil de rédaction qui produit des comptes rendus, des notes ou des images synthétiques peut relever d’exigences de transparence et de marquage selon son usage et le contenu concerné.
Un copilote RH, de support managérial ou d’évaluation peut exiger une analyse renforcée de ses effets sur les travailleurs, particulièrement lorsque le système entre dans le champ des usages à haut risque.
Un agent relié à des applications métiers doit être gouverné aussi comme une surface de sécurité : ses autorisations, ses actions et ses journaux ne sont pas des détails techniques.
La bonne question n’est donc pas seulement « quel modèle choisissons-nous ? ». Elle devient : « quel niveau d’autonomie, de données, de décision et de visibilité acceptons-nous pour ce cas d’usage précis ? »
Pourquoi l’AI Act transforme un projet d’outil en responsabilité d’organisation
L’AI Act installe un cadre de gouvernance qui dépasse l’équipe ayant acheté ou développé le copilote. L’Union européenne s’appuie notamment sur l’AI Office et sur les autorités nationales compétentes. Ce système à deux niveaux impose aux entreprises de comprendre à la fois la nature du système utilisé et la répartition des responsabilités applicable.
L’AI Office supervise notamment les obligations relatives aux modèles d’IA à usage général, souvent désignés par GPAI, ainsi que certaines catégories de systèmes. Les autorités nationales supervisent le reste du dispositif. Pour une entreprise utilisatrice, cette architecture signifie qu’un même copilote peut s’inscrire dans plusieurs couches de conformité.
Un copilote repose souvent sur une chaîne d’acteurs
Un assistant interne peut combiner un modèle de fondation fourni par un acteur externe, une interface choisie par l’entreprise, une couche d’orchestration développée en interne, un moteur de recherche documentaire et des connecteurs vers le système d’information. La conformité ne se résume alors ni au contrat de licence ni à la qualité apparente des réponses.
Les règles applicables aux modèles GPAI ont commencé à s’appliquer en 2025, avant les obligations de transparence de 2026. Une organisation qui déploie un copilote reposant sur un modèle de fondation doit donc distinguer ce qui relève du fournisseur du modèle de ce qui relève de son propre rôle de déployeur.
Ce partage ne doit pas devenir un angle mort. Le fournisseur peut avoir ses obligations liées au modèle ; l’entreprise doit néanmoins gouverner le paramétrage, les utilisateurs autorisés, les données d’entrée, les cas d’usage réellement mis en production et la réponse aux incidents dans son environnement.
Passer d’un sponsor isolé à des responsabilités explicites
Dans beaucoup d’organisations, l’adoption commence par une initiative métier ou par l’expérimentation d’une équipe numérique. C’est utile pour apprendre, mais insuffisant pour industrialiser. Un déploiement durable demande un dispositif où les décisions ne reposent pas sur une seule personne ni sur un comité qui ne se réunit qu’après un incident.
Le sponsor métier
définit la valeur attendue, les utilisateurs concernés et les limites fonctionnelles du cas d’usage.
Le responsable produit ou projet
maintient le périmètre, les exigences, les critères d’acceptation et la documentation de décision.
Les équipes sécurité, données et conformité
instruisent les risques associés aux accès, aux données personnelles, aux fournisseurs et aux traces.
Les responsables opérationnels
organisent la supervision humaine et remontent les comportements inattendus ou les erreurs récurrentes.
Les utilisateurs
restent responsables de vérifier les sorties avant de les transformer en action, en communication ou en décision.
La maturité ne vient pas de la multiplication des validations. Elle vient de l’alignement entre les droits techniques, les procédures de travail et les responsabilités formelles. Un copilote sans propriétaire clairement identifié est difficile à améliorer, à auditer et à arrêter si son comportement devient problématique.
Classer les cas d’usage avant de choisir les contrôles
Il n’existe pas une gouvernance identique pour tous les copilotes. Un assistant qui reformule une note dont l’auteur garde la maîtrise n’a pas le même profil qu’un système qui trie des candidatures, suggère des actions dans un outil de production ou synthétise des données confidentielles. La première étape utile consiste à cartographier les usages réels, et non les seules solutions officiellement achetées.
Cette cartographie doit inclure les outils tiers, les prototypes internes, les assistants inclus dans des suites logicielles et les intégrations réalisées par les équipes métiers. Elle doit également distinguer l’expérimentation encadrée de la mise à disposition en production.
Construire une fiche de cas d’usage exploitable
Une fiche courte mais complète est souvent plus efficace qu’un registre abstrait. L’objectif est de permettre une décision : autoriser, restreindre, compléter par des contrôles, traiter comme un cas sensible ou suspendre le déploiement.
Décrire la finalité.
Précisez ce que le copilote aide à accomplir : rédiger, rechercher, résumer, classifier, assister un support, produire une image ou préparer une analyse.
Identifier les personnes concernées.
Recensez les utilisateurs directs, les salariés éventuellement affectés par les résultats, les clients ou partenaires dont des informations peuvent être traitées.
Qualifier les données d’entrée et de sortie.
Distinguez les informations publiques, internes, confidentielles, personnelles et les données à ne pas transmettre à l’outil.
Décrire le niveau d’action.
Le copilote suggère-t-il seulement du contenu, ou peut-il déclencher des actions, modifier un dossier, envoyer un message ou influencer une décision ?
Identifier le modèle et les fournisseurs.
Documentez le fournisseur, les sous-traitants connus, les connecteurs, les conditions d’usage et le lieu où se situent les responsabilités techniques.
Définir les contrôles.
Associez au cas d’usage un responsable, une supervision humaine, des règles de conservation, un canal d’incident et une date de revue.
Ce travail permet de faire émerger les dépendances cachées. Par exemple, un assistant de recherche interne paraît limité tant qu’il ne lit qu’un espace documentaire ciblé. Il change de nature si son compte de service peut consulter des répertoires RH, des contrats, un CRM ou des tickets de sécurité.
Préférer les copilotes bornés aux assistants omniscients
Dans les milieux professionnels, la tendance observée en 2026 va vers des copilotes plus étroits, intégrés à un workflow précis, mieux audités et moins largement autorisés. Cette orientation ne signifie pas qu’un assistant généraliste est nécessairement interdit. Elle reflète un arbitrage de gouvernance : plus le périmètre fonctionnel et informationnel est large, plus il devient difficile de démontrer que les droits, les sorties et les incidents sont maîtrisés.
Un copilote de préparation de compte rendu, limité à une équipe et à une base de connaissances validée, est souvent plus simple à administrer qu’un assistant généraliste connecté à l’ensemble du système d’information. En contrepartie, la spécialisation réduit la polyvalence immédiate et peut imposer plusieurs interfaces ou plusieurs produits. C’est un coût de conception, mais aussi un moyen de réduire la surface de risque.
Le principe pratique est simple : donner au copilote le minimum de données, de capacités et de droits nécessaires à la valeur recherchée. Cette approche facilite aussi les tests, la formation des utilisateurs et l’analyse d’un incident.
Transparence et contenus générés : ce qui change à partir du 2 août 2026
Les obligations de transparence prévues par l’AI Act s’appliquent dans l’UE à partir du 2 août 2026. Les lignes directrices de la Commission européenne publiées en juillet 2026 précisent le périmètre des obligations prévues à l’article 50 afin de soutenir une application cohérente, effective et proportionnée.
Pour les copilotes internes, ce calendrier rend la transparence très concrète. Les systèmes génératifs et interactifs couvrent des usages typiques d’entreprise : interface conversationnelle, rédaction assistée, génération de texte, création d’images ou transformation de contenus. Il faut donc examiner comment l’utilisateur sait qu’il interagit avec une IA et comment les contenus synthétiques sont gérés dans le workflow.
Informer n’est pas seulement afficher une mention légale
Une bannière générale à l’ouverture de l’outil ne remplace pas une information adaptée au contexte. L’utilisateur doit pouvoir comprendre les capacités et les limites pertinentes : caractère génératif de la réponse, nécessité de relire, sources éventuellement utilisées, règles sur les données qu’il peut saisir et processus à suivre lorsqu’un résultat paraît erroné ou sensible.
Cette information doit aussi être cohérente avec le processus métier. Dans un outil de communication, il peut être nécessaire de distinguer le brouillon généré de la version validée. Dans une base de connaissances, les contenus issus d’un copilote doivent pouvoir être soumis à un circuit éditorial clair avant de devenir une référence interne.
Vérifier le marquage et la détection des contenus synthétiques
Lorsque le système produit, manipule ou diffuse du texte, des images ou d’autres contenus synthétiques, l’entreprise doit analyser si les obligations de marquage et de détection sont applicables à son cas. Cette vérification ne doit pas être limitée aux publications externes : un workflow interne peut produire des éléments qui seront réutilisés dans une décision, une présentation, une formation, une communication ou un processus opérationnel.
La Commission indique qu’une période transitoire existe dans certains cas pour les systèmes placés sur le marché avant le 2 août 2026, avec un report jusqu’au 2 décembre 2026 concernant l’obligation de marquage et de détection des contenus générés. Ce report n’est pas une raison pour différer l’inventaire. Il doit plutôt servir à organiser les adaptations techniques, contractuelles et opérationnelles requises.
Définir où l’origine IA doit être visible dans l’interface, dans les exports et dans les validations humaines.
Tester si les mécanismes fournis par l’éditeur répondent réellement aux besoins du processus interne.
Prévoir le traitement des contenus modifiés par un utilisateur après génération.
Éviter qu’une sortie non vérifiée soit automatiquement promue comme vérité documentaire ou décisionnelle.
Conserver la justification des choix de transparence retenus pour chaque cas d’usage.
La transparence utile est celle qui aide une personne à agir correctement. Elle ne se limite pas à rendre visible la présence de l’IA ; elle rend visible ce qu’il reste à vérifier et qui est responsable de la validation.
Organiser supervision humaine, logs et gestion des incidents
La conformité ne se joue pas uniquement avant la mise en service. Elle dépend de la capacité de l’entreprise à surveiller l’usage après le lancement, à détecter une dérive et à agir rapidement. Les obligations relatives aux systèmes à haut risque, notamment celles figurant à l’article 26, fournissent un repère structurant : suivre les instructions d’utilisation, assurer une supervision humaine compétente, surveiller le système, gérer les données d’entrée et conserver les journaux pendant au moins six mois.
Cette exigence de six mois concerne le cadre prévu pour les deployers de systèmes à haut risque. Il serait imprudent de l’étendre automatiquement à tout copilote sans qualification, mais il serait tout aussi imprudent de conclure que les autres outils n’ont besoin d’aucune trace. Pour chaque cas d’usage, une politique de journalisation proportionnée doit permettre de comprendre les événements importants, de traiter les incidents et de démontrer les contrôles prévus.
La supervision humaine doit être définie, pas présumée
Dire qu’un humain reste « dans la boucle » n’a de valeur que si cette personne dispose de la compétence, du temps et de l’autorité nécessaires pour intervenir. Un manager qui valide mécaniquement une recommandation parce que le flux de travail ne lui donne ni contexte ni possibilité de contester n’assure pas une supervision effective.
Une supervision adaptée précise les décisions que le copilote ne peut pas prendre seul, les contrôles obligatoires avant action, les signaux qui imposent une escalade et les personnes habilitées à désactiver ou restreindre le service. Elle doit être testée lors de scénarios réalistes : réponse erronée, fuite de données par une requête, comportement inattendu d’un connecteur ou hallucination présentée avec assurance.
Des logs utiles sans collecte indiscriminée
Les journaux aident à reconstituer un incident, mais ils peuvent aussi contenir des données sensibles. Leur gouvernance doit donc répondre à deux objectifs : obtenir une traçabilité suffisante et éviter une conservation disproportionnée. Il faut décider quels événements sont enregistrés, qui peut consulter les traces, combien de temps elles sont conservées et comment elles sont protégées.
Selon le contexte, les éléments pertinents peuvent inclure l’identité ou le rôle de l’utilisateur, le système et la version du modèle, le connecteur sollicité, les droits mobilisés, les actions déclenchées, les paramètres de sécurité, les erreurs et les alertes. Le contenu intégral des requêtes ou des réponses ne doit pas être traité comme une évidence : son enregistrement doit être évalué au regard des données concernées et du besoin opérationnel.
Prévoir un cycle d’incident spécifique à l’IA
Un incident lié à un copilote n’est pas toujours une panne technique. Il peut s’agir d’une réponse fictive reprise dans un document, d’une divulgation de contenu à un utilisateur non autorisé, d’une instruction malveillante dans une source documentaire, d’un biais observé dans un usage ou d’un changement du fournisseur qui modifie le comportement du service.
Donner aux utilisateurs un canal simple pour signaler un résultat dangereux, faux, discriminatoire, confidentiel ou inexplicable.
Trier le signalement par gravité et pouvoir suspendre rapidement un connecteur, une fonction ou un groupe d’accès.
Conserver les éléments nécessaires à l’analyse sans élargir inutilement l’accès aux données concernées.
Corriger la cause : droit d’accès, source documentaire, instruction système, formation, configuration ou périmètre du cas d’usage.
Communiquer les enseignements aux équipes concernées et mettre à jour le registre de risques ainsi que les supports de formation.
La sécurité et la résilience prennent une place croissante dans cette gouvernance. La Commission a évoqué en juillet 2026 un plan d’action cyber et IA destiné à aider les États membres, les entreprises et les autorités publiques face aux risques de cybersécurité liés aux modèles avancés. Pour les équipes projet, cela confirme qu’un copilote connecté ne doit pas être traité comme un simple composant d’interface.
Former les équipes : l’AI literacy est déjà une obligation
L’article 4 de l’AI Act s’applique depuis le 2 février 2025. Il impose aux fournisseurs et aux déployeurs de prendre des mesures pour soutenir un niveau suffisant de littératie en IA de leur personnel et des autres personnes qui exploitent les systèmes en leur nom, en tenant compte notamment de leurs connaissances techniques, de leur expérience, de leur formation et du contexte d’utilisation.
Pour un copilote interne, l’AI literacy ne se réduit donc pas à une démonstration d’outil ou à une charte envoyée par e-mail. Elle porte sur la compréhension pratique des capacités et des limites du système, des risques de données, des règles de validation, des voies d’escalade et de l’impact des usages sur le travail.
Adapter la formation aux rôles plutôt qu’imposer un module unique
Les utilisateurs occasionnels
doivent savoir quelles données ils peuvent saisir, comment reconnaître une réponse incertaine et quand ne pas utiliser le copilote.
Les utilisateurs avancés
ont besoin de maîtriser les instructions, les sources autorisées, les contrôles de sortie et les limites des automatismes.
Les managers
doivent comprendre les effets du copilote sur l’organisation du travail, la qualité et la responsabilité de validation.
Les équipes techniques
doivent connaître les exigences liées aux accès, aux logs, aux connecteurs, aux versions de modèles et aux incidents.
Les fonctions de contrôle
doivent pouvoir lire une documentation produit et challenger les mesures annoncées par les fournisseurs ou les équipes projet.
La formation doit être liée à des situations de travail concrètes. Une règle telle que « ne saisissez pas de données sensibles » reste insuffisante si les utilisateurs ne savent pas identifier une donnée sensible dans leurs propres pratiques, ni quelles solutions approuvées utiliser à la place.
Les administrations européennes expérimentent déjà l’IA générative pour la rédaction, la gestion des connaissances et le traitement de l’information, tout en rencontrant des défis de gouvernance et de protection des données, comme le souligne une publication de l’UE de juin 2026. Cette expérience est transposable au privé : plus le copilote se rapproche du travail quotidien, plus les règles d’usage doivent être intégrées au travail quotidien.
Un indicateur de maturité n’est pas le nombre de personnes ayant assisté à une session. C’est la capacité d’une équipe à expliquer quand elle utilise le copilote, ce qu’elle vérifie systématiquement et comment elle remonte un problème.
Articuler AI Act, GDPR et droits des travailleurs
Un dispositif de conformité efficace ne juxtapose pas des listes AI Act, cybersécurité et protection des données. Il regarde le parcours complet de l’information. Les copilotes internes traitent souvent des requêtes rédigées par des salariés, consultent des documents de travail et génèrent des sorties qui peuvent contenir des données personnelles ou influencer une relation professionnelle.
Les autorités de protection des données relient explicitement l’IA générative au GDPR. L’Autoriteit Persoonsgegevens a publié le 13 juillet 2026 des orientations relatives au développement et au déploiement licites de modèles génératifs au regard du GDPR. Cela renforce la nécessité d’une analyse conjointe : une mesure apparemment utile pour la traçabilité, telle que l’enregistrement des prompts, doit aussi être évaluée au regard de la minimisation, de l’accès et de la conservation des données.
Ne pas traiter les salariés comme de simples utilisateurs techniques
Lorsque le système est utilisé dans le cadre professionnel, les enjeux de droits des travailleurs doivent être pris au sérieux. L’article 26 de l’AI Act prévoit que les deployers de systèmes à haut risque notifient les représentants des travailleurs et les travailleurs concernés. Cette exigence ne vise pas indistinctement tous les copilotes, mais elle montre que la gouvernance de l’IA au travail ne peut pas être pensée uniquement par l’IT ou les achats.
L’Espagne illustre ce durcissement de l’attention portée aux usages professionnels : l’AEPD a publié le 7 octobre 2026 des orientations sur les systèmes algorithmiques en milieu professionnel. Pour les entreprises, le signal est clair : les outils qui structurent, observent, évaluent ou influencent le travail seront de plus en plus examinés sous l’angle de la protection des personnes et de la gouvernance RH.
Avant un déploiement dans un domaine RH, managérial ou de pilotage de performance, il est prudent d’associer très tôt les parties compétentes : RH, protection des données, sécurité, représentants lorsque le cadre le requiert, responsables métier et équipes techniques. Une revue tardive est coûteuse, car elle intervient souvent après la conception des flux et des droits.
Questions à poser avant d’ouvrir un copilote à une population large
Le copilote reçoit-il, déduit-il ou expose-t-il des données personnelles ou des informations susceptibles d’affecter une personne au travail ?
Ses sorties sont-elles utilisées pour éclairer, classer, recommander ou préparer une décision concernant un salarié ?
Les utilisateurs comprennent-ils que le contenu est généré et que la validation humaine est obligatoire dans les cas définis ?
Les personnes autorisées à consulter les logs, les prompts et les résultats sont-elles identifiées et leurs accès sont-ils proportionnés ?
Le fournisseur et les intégrations offrent-ils les garanties nécessaires au regard du traitement envisagé ?
Ces questions ne remplacent pas une qualification juridique du système. Elles permettent de détecter assez tôt les cas qui nécessitent une instruction approfondie avant toute généralisation.
Mettre en place une feuille de route de conformité sans bloquer l’innovation
La conformité la plus robuste est celle qui entre dans le cycle de vie produit. Attendre qu’un copilote soit largement adopté pour documenter les rôles, les données et les traces crée un coût de rattrapage important. À l’inverse, imposer un processus excessivement long à chaque prototype pousse les équipes vers des outils non approuvés et moins visibles.
Une approche proportionnée consiste à créer des voies distinctes selon le niveau de risque et d’intégration. Un essai isolé, sans données sensibles ni connecteurs, n’a pas besoin du même niveau de contrôle qu’un copilote déployé à grande échelle, connecté à des applications métiers ou utilisé dans un contexte affectant les travailleurs.
Un plan d’action pragmatique en six mouvements
Rendre visibles les usages.
Réalisez un inventaire des copilotes officiels, des fonctions IA intégrées aux outils existants et des expérimentations métiers.
Évaluer et prioriser.
Classez les cas d’usage selon les données, les droits, le niveau d’autonomie, les personnes concernées et l’impact potentiel des erreurs.
Définir un socle de contrôles.
Formalisez des exigences minimales : propriétaire métier, règles de données, information utilisateur, gestion des accès, revue fournisseur, incidents et formation.
Traiter les cas sensibles.
Ajoutez les analyses requises pour les usages qui peuvent entrer dans des régimes spécifiques, notamment lorsqu’ils touchent au travail, à la décision ou aux systèmes à haut risque.
Industrialiser la preuve.
Conservez dans un espace gouverné les fiches de cas d’usage, décisions, validations, paramètres importants, contrats, résultats de tests et actions correctives.
Réviser en continu.
Réévaluez le copilote après un changement de modèle, de connecteur, de population d’utilisateurs, de données accessibles ou de finalité métier.
La Commission a mis en place l’AI Pact pour aider les organisations à préparer l’application du règlement. Pour une entreprise, s’en inspirer peut constituer un signal de maturité : non pas annoncer une conformité théorique, mais démontrer que l’anticipation réglementaire structure déjà les choix de déploiement.
Les modifications intervenues en 2026 ont prolongé certains délais, notamment pour les sandbox et la mise en œuvre de certaines solutions de transparence, selon le Conseil. Ce temps supplémentaire doit être considéré comme une fenêtre de préparation. Il ne supprime ni le besoin de gouvernance ni la nécessité d’outiller les équipes qui exploitent déjà des copilotes.
Le règlement européen redessine la gouvernance des copilotes internes en faisant passer l’entreprise d’une logique d’adoption d’outil à une logique de maîtrise d’usage. Transparence à partir du 2 août 2026, littératie IA déjà applicable, supervision humaine, journalisation adaptée, traitement des contenus générés, sécurité, protection des données et attention aux droits des travailleurs forment un ensemble cohérent, même si les obligations exactes dépendent de la qualification de chaque système.
La démarche la plus solide consiste à commencer par les cas d’usage réels, puis à les borner, les documenter et les revoir. Un copilote utile n’est pas celui qui accède à tout et répond à tout : c’est celui dont l’organisation peut expliquer la finalité, les limites, les contrôles et la responsabilité à chaque étape de son usage.
