Gestion des risques liés aux données dans les flux de travail basés sur l'IA

Un employé du service client saisit une réclamation dans un assistant IA et lui demande de rédiger une réponse. La réclamation contient le nom du client, son numéro de compte et ses antécédents médicaux. La réponse est générée en quelques secondes, corrigée, puis envoyée. Aucune faille de sécurité n’est immédiatement détectée, aucune alerte de sécurité ne se déclenche et l’employé considère que la tâche est terminée.

Pourtant, plusieurs questions importantes restent sans réponse. Ces informations ont-elles été autorisées à sortir de l’environnement contrôlé de l’entreprise ? Ont-elles été conservées par le fournisseur d’IA ? Pourraient-elles être utilisées pour améliorer le service ou entraîner le modèle ? Quels sous-traitants les ont traitées ? L’entreprise serait-elle en mesure de récupérer la requête si le client contestait ultérieurement la décision ?

Voici comment les flux de travail basés sur l'IA modifient les risques liés aux données. Le danger ne se limite plus au vol d'une base de données ou à l'ajout par un employé d'une feuille de calcul erronée. Les informations sensibles transitent désormais par des invites, des systèmes de recherche, des interfaces de modèles, des plug-ins, des agents automatisés et des infrastructures tierces. Le flux de travail est peut-être plus rapide, mais la traçabilité des données est plus longue et souvent moins visible.

La question centrale en matière de gestion n'est donc pas de savoir si l'IA réduit les erreurs humaines. Il s'agit plutôt de déterminer si l'entreprise sait toujours quelles informations sont traitées, où elles transitent, qui peut y accéder et quelles actions automatisées elles sont autorisées à déclencher.

L'automatisation peut réduire les erreurs et en multiplier les conséquences

Les contrôles traditionnels des données ont été conçus, pour l'essentiel, pour des systèmes dont les entrées et les sorties sont prévisibles. Une application de gestion de la paie effectue un calcul bien défini. Une base de données clients stocke des enregistrements dans des champs connus. L'accès peut être accordé en fonction du poste occupé, tandis que les modifications importantes peuvent être consignées et vérifiées.

Un workflow basé sur l'IA fonctionne différemment. Il peut classer les informations reçues, les résumer, les associer à des documents internes, générer une recommandation et transmettre cette recommandation à un autre système. Lorsque des agents interviennent, le modèle peut également envoyer un e-mail, mettre à jour un dossier, approuver une demande courante ou lancer un autre processus automatisé.

Cela permet d'éliminer les tâches manuelles répétitives. L'IA peut aider à détecter des schémas d'accès inhabituels, à identifier des informations sensibles, à classer des documents et à signaler des transactions nécessitant un contrôle. Elle peut également reproduire la même erreur dans des milliers de cas avant que quiconque ne s'en aperçoive.

Un employé qui interprète mal une politique peut traiter de manière incorrecte plusieurs dossiers. Un flux de travail automatisé reposant sur cette même interprétation erronée peut, quant à lui, traiter de manière incorrecte tous les dossiers concernés dans le système. Le gain d'efficacité et le risque lié au contrôle découlent de la même caractéristique : l'échelle.

Les entreprises devraient donc cesser de considérer le principe du “ human in the loop ” comme une solution suffisante. Une personne qui valide plusieurs centaines de décisions générées par l’IA en un après-midi a peu de chances d’évaluer chacune d’entre elles de manière pertinente. La supervision humaine n’est utile que lorsque le responsable de la vérification dispose de suffisamment d’informations, de pouvoirs et de temps pour intervenir.

Le « prompt » est devenu un nouveau canal de transfert de données

De nombreuses entreprises ont passé des années à restreindre les possibilités offertes à leurs employés pour exporter des listes de clients, des documents comptables et des documents sensibles sur le plan commercial. L'IA générative a ouvert une voie moins évidente : la boîte de saisie de prompt.

Un employé peut coller une partie d'un contrat dans un assistant pour obtenir un résumé, télécharger des données de vente à des fins d'analyse ou fournir l'adresse e-mail d'un client afin que le système puisse rédiger une réponse. Cette action peut sembler plus proche de l'utilisation d'un moteur de recherche que du transfert de données vers un processeur externe, même si, du point de vue de la gouvernance, il peut s'agir exactement de cela.

Cela modifie la portée concrète de la prévention des pertes de données. Il ne suffit plus de surveiller les pièces jointes aux e-mails, les clés USB et les plateformes de partage de fichiers. Les entreprises doivent savoir à quelles interfaces d’IA leurs employés ont accès, quelles catégories d’informations peuvent y être saisies et quels contrôles techniques empêchent les données sensibles de sortir des environnements autorisés.

Une interdiction générale constitue rarement une solution efficace à long terme. Les employés peuvent être amenés à recourir à leurs comptes personnels ou à des outils non autorisés s’ils estiment que l’IA améliore considérablement leur travail. Une approche plus efficace consiste à mettre à disposition un environnement d’entreprise agréé, à préciser quelles informations sont interdites et à mettre en place des contrôles permettant de détecter ou de masquer les données personnelles, confidentielles et soumises à une réglementation avant qu’elles n’atteignent un modèle.

La politique doit être plus précise que la simple consigne “ ne communiquez pas d’informations sensibles ”. Un commercial doit savoir si cela inclut les noms des clients, les détails du pipeline commercial, les tarifs, les conditions contractuelles, les comptes-rendus de réunions et les prévisions internes. Un ingénieur a besoin de directives similaires concernant le code source, les conceptions de produits, les identifiants de connexion et les informations relatives aux vulnérabilités.

Sans exemples concrets, une politique en matière d'IA n'est qu'un document que les employés prennent acte de lire, puis interprètent à leur guise.

La récupération pose un problème d'autorisations

De nombreux systèmes d'IA d'entreprise utilisent la génération augmentée par la recherche, communément appelée RAG. Plutôt que de s'appuyer uniquement sur l'entraînement général d'un modèle, l'application effectue des recherches dans des sources internes validées et fournit des informations pertinentes au modèle lorsqu'il répond à une question.

Cela peut rendre un assistant nettement plus utile. Un collaborateur peut poser une question concernant une politique de déplacement, une procédure technique ou le compte d'un client, et obtenir une réponse fondée sur les données de l'entreprise.

Cela pose également un problème important en matière de contrôle d'accès. L'assistant ne doit pas récupérer des documents que l'utilisateur n'a jamais été autorisé à consulter.

Un système mal conçu peut se connecter à un vaste référentiel de documents sans respecter fidèlement les droits d'accès sous-jacents. Un employé qui ne parviendrait pas à localiser un dossier relatif à la rémunération des dirigeants via l'interface habituelle pourrait néanmoins en obtenir le contenu en posant une question suffisamment précise à l'assistant.

Le risque s'accroît lorsque les autorisations ne sont pas harmonisées entre les disques partagés, les plateformes de collaboration et les systèmes existants. L'IA n'est pas à l'origine de ces failles, mais elle peut faciliter considérablement leur exploitation. Des informations qui nécessitaient auparavant de la persévérance et une bonne connaissance de la structure des fichiers de l'entreprise peuvent désormais être obtenues par le biais de questions formulées en langage naturel.

Avant de connecter un assistant IA à sa base de connaissances interne, l'entreprise doit vérifier si les autorisations du système source sont héritées et appliquées au moment de la requête. Elle doit également s'assurer que les réponses générées ne révèlent pas d'informations par le biais de résumés, de comparaisons ou de déductions, même lorsque le document d'origine n'est pas affiché.

Les tests d'accès doivent inclure des requêtes malveillantes réalistes. Il ne suffit pas de vérifier qu'un employé autorisé peut récupérer la politique appropriée. L'équipe doit également vérifier si un employé non autorisé peut amener le système à divulguer indirectement des informations confidentielles.

Une quantité plus importante de données ne garantit pas automatiquement un meilleur flux de travail

Les projets d'IA partent souvent du principe que les performances s'amélioreront si le modèle peut accéder à davantage d'informations. Cela incite les équipes à regrouper les dossiers clients, les communications, l'historique des transactions et les données comportementales avant de déterminer quels champs sont réellement nécessaires.

C'est le contraire de la minimisation des données. Cela amplifie l'impact potentiel d'une violation, augmente le risque que les informations soient utilisées à des fins autres que celles pour lesquelles elles ont été collectées et rend leur suppression ou leur correction plus difficile.

Un assistant en recrutement, par exemple, peut avoir besoin de connaître les compétences et l'expérience d'un candidat, ainsi que ses réponses à des questions liées au poste. Il n'a pas nécessairement besoin de photos, de la date de naissance, d'informations sur la famille ou de métadonnées historiques issues de toutes les candidatures précédentes. Un modèle de fidélisation de la clientèle peut nécessiter de connaître l'activité récente du compte sans pour autant avoir besoin d'un accès illimité à l'ensemble de la correspondance jamais envoyée par le client.

La minimisation des données doit être intégrée à l'architecture du flux de travail. Le système ne doit recevoir que les informations nécessaires à la tâche spécifique, et ce pendant la durée la plus courte justifiée. Les identifiants non pertinents peuvent être supprimés, les champs hautement sensibles isolés et les données transformées avant d'être transmises au modèle.

Cela permet également de renforcer la traçabilité. Lorsqu'un processus produit un résultat inattendu, il est plus facile d'analyser un ensemble défini de données d'entrée que des données rassemblées de manière aléatoire à partir de plusieurs systèmes d'entreprise.

La qualité des données devient un contrôle opérationnel

Dans le cadre d'un processus de reporting classique, des données de mauvaise qualité peuvent donner lieu à un graphique ou à un rapport de gestion inexact. Dans un flux de travail automatisé basé sur l'IA, cela peut entraîner une décision ou une action erronée.

Prenons l'exemple d'un assureur qui utilise l'IA pour acheminer les demandes d'indemnisation. Un code de police obsolète pourrait faire aboutir une demande légitime dans la file d'attente réservée aux cas de fraude. Une fiche client en double pourrait amener un conseiller à fournir des informations contradictoires. L'absence d'un indicateur de consentement pourrait entraîner l'utilisation de données à caractère personnel dans un flux de travail dont elles auraient dû être exclues.

Le problème ne se résout pas en choisissant un modèle plus performant. Les performances d'un modèle ne peuvent pas compenser de manière systématique le manque de fiabilité des données sources, l'absence de définition de certains champs ou la présence d'enregistrements contradictoires.

Les entreprises doivent considérer les seuils de qualité des données comme des conditions préalables au déploiement. Avant d'automatiser un workflow, son responsable doit savoir quelles sources celui-ci utilise, dans quelle mesure ces données sont à jour, quel pourcentage d'enregistrements est incomplet et quelles erreurs pourraient avoir une incidence significative sur le résultat.

L'indicateur pertinent ne se limite pas à la précision du modèle. Il peut s'agir du nombre de cas mal orientés, de la proportion nécessitant une correction humaine, du taux de fausses alertes de fraude ou du nombre de clients recevant des conseils fondés sur des informations obsolètes.

Ces mesures établissent un lien entre les performances techniques et leurs conséquences opérationnelles.

La chaîne d'approvisionnement basée sur l'IA fait partie de la frontière des données

Une application d'IA d'entreprise est rarement un système unique fourni par une seule entreprise. Elle peut s'appuyer sur un modèle de base, une infrastructure cloud, une couche d'orchestration, une base de données vectorielle, un logiciel de surveillance, des plug-ins et des sources de données externes.

Chaque composant peut avoir une incidence sur la manière dont les informations sont traitées et protégées. Une entreprise peut avoir conclu un contrat avec l'éditeur de l'application sans savoir quel fournisseur de modèles reçoit les requêtes, où sont stockés les embeddings, ni si les journaux de diagnostic contiennent des informations sur les clients.

Les questionnaires traditionnels destinés aux fournisseurs sont souvent trop généraux pour cette architecture. Demander à un fournisseur s’il respecte une norme de sécurité ne permet pas de savoir si les données de saisie sont conservées, si les données clients sont utilisées pour améliorer les modèles ou ce qui se passe en cas de changement de sous-traitant.

Les équipes chargées des marchés publics devraient demander un diagramme de flux de données pour chaque processus d'IA important. Ce diagramme doit indiquer les catégories d'informations collectées, les systèmes par lesquels elles transitent, les emplacements où elles sont stockées, les durées de conservation et les parties habilitées à y accéder.

Le contrat devrait également couvrir les modifications apportées au modèle et aux composants. Un service d’IA peut subir des changements substantiels lorsque le prestataire remplace le modèle sous-jacent, modifie les filtres de sécurité ou fait appel à un nouveau sous-traitant. Un flux de travail approuvé pour une configuration donnée ne devrait pas rester approuvé indéfiniment une fois que sa base technique a changé.

Le risque lié au fournisseur devient donc un risque continu, plutôt que concentré au moment de l'achat.

L'IA présente des risques de sécurité que les filtres classiques peuvent ne pas détecter

Les systèmes d'IA présentent les mêmes risques de cybersécurité que ceux que l'on connaît déjà, tels que les accès non sécurisés, les identifiants exposés et les composants logiciels vulnérables. Ils introduisent également de nouvelles méthodes d'attaque liées à la manière dont les modèles interprètent les instructions et les données.

L'injection de prompt en est un exemple. Des instructions malveillantes peuvent être insérées dans un document, une page web, un message ou tout autre contenu traité par le modèle. Le système peut alors considérer ces instructions comme faisant autorité et ignorer les règles prévues par l'organisation.

Imaginez un agent d'IA chargé de vérifier les factures des fournisseurs reçues par e-mail. Un document falsifié pourrait contenir du texte caché ordonnant à l'agent de ne pas tenir compte des consignes précédentes, d'extraire des informations internes ou de rediriger le flux de travail. Le risque est d'autant plus grand lorsque le système peut accéder à d'autres données ou effectuer des actions sans autorisation spécifique.

L'empoisonnement des données pose un autre problème. Si les données d'entraînement, de test ou d'extraction sont manipulées, le système risque d'apprendre ou de reproduire des comportements indésirables. La divulgation d'informations sensibles peut se produire lorsqu'un modèle révèle des contenus confidentiels dans ses résultats, que ce soit parce que ces informations figuraient dans une invite, dans une base de connaissances connectée ou dans un ensemble de données mal géré.

Ces risques ne peuvent être gérés uniquement par la sensibilisation des employés. Le système doit disposer d'autorisations restreintes, de zones de confiance distinctes, d'une surveillance des entrées et des sorties, de limites de débit et d'une validation explicite avant toute action ayant des conséquences importantes. Le contenu provenant d'une source externe ne doit pas être automatiquement considéré comme des instructions fiables.

Le principe de conception le plus sûr consiste à ne conférer à l'IA que les pouvoirs minimaux nécessaires. Un système qui rédige un ordre de paiement présente moins de risques qu'un système capable d'effectuer le paiement sans vérification indépendante.

La journalisation est indispensable, mais elle génère un autre ensemble de données sensibles

Lorsqu'un workflow d'IA aboutit à une décision contestée, l'entreprise doit reconstituer le déroulement des événements. Cela peut nécessiter de disposer de la requête, des documents consultés, de la version du modèle, de la réponse générée, de l'identité de l'utilisateur, des instructions du système et des actions qui ont suivi.

Sans ces données, l'enquête se résume à des conjectures. L'organisation peut savoir qu'un outil d'IA a été utilisé sans être en mesure d'expliquer quelles informations ont influencé le résultat.

Pourtant, les journaux peuvent eux-mêmes contenir des informations très sensibles. L'historique des commandes peut contenir des réclamations de clients, des informations médicales, des clauses contractuelles, du code source ou des discussions entre employés. Le stockage indéfini de toutes ces données crée un nouveau concentré de risques.

La solution réside dans une journalisation sélective et ciblée. Les organisations doivent déterminer quels enregistrements sont nécessaires à la sécurité, à l'audit, à la conformité réglementaire et au suivi des performances, puis définir des règles d'accès et de conservation en conséquence.

Un assistant de rédaction à faible risque peut se contenter de journaux d'exploitation limités. En revanche, un processus ayant une incidence sur le crédit, l'emploi, l'assurance ou l'accès à des services essentiels peut nécessiter une piste d'audit bien plus complète.

Les journaux doivent également consigner les modifications apportées à la configuration. Si un modèle est mis à jour, si un modèle d'invite est modifié ou si une nouvelle source de données est connectée, l'organisation doit savoir quelles décisions ont été prises et sous quelle version.

La gouvernance doit s'adapter au flux de travail, et non au budget technologique

De nombreuses entreprises confient la gouvernance de l'IA à un comité d'innovation, tandis que la protection des données relève du service juridique, la cybersécurité du service informatique et les risques opérationnels des différentes unités opérationnelles. Il en résulte une supervision fragmentée des flux de travail qui recoupent ces quatre domaines.

Le cas d'utilisation constitue une unité de gouvernance plus appropriée. Chaque processus opérationnel important doit disposer d'un responsable métier désigné, chargé du résultat, d'un responsable technique chargé de la mise en œuvre, ainsi que de spécialistes clairement identifiés dans les domaines de la sécurité, de la protection de la vie privée, des aspects juridiques et de la gestion des documents.

Avant le déploiement, l'équipe doit être en mesure de répondre à plusieurs questions pratiques :

Quelle décision ou quel processus opérationnel fait l'objet d'une modification ?

Quelles données sont intégrées au flux de travail, et sur quelle base juridique et opérationnelle ?

Quels sont les systèmes et les tiers qui reçoivent ces données ?

Quelles erreurs pourraient entraîner un préjudice matériel ?

Quelles actions l'IA peut-elle entreprendre sans autorisation ?

Comment les utilisateurs pourront-ils contester ou corriger le résultat ?

Dans quel cas faudrait-il suspendre le workflow ?

Ces questions sont plus pertinentes que celle de savoir si l'entreprise dispose d'une stratégie en matière d'IA. Elles permettent de déterminer si quelqu'un comprend suffisamment bien le système pour l'utiliser de manière responsable.

Commencez par créer un flux de travail d'IA

La première étape concrète consiste à dresser un inventaire. De nombreuses organisations ne parviennent pas à réguler efficacement l'IA, car elles ignorent où celle-ci est utilisée.

Le registre doit inclure les outils achetés, les systèmes développés en interne, les fonctionnalités d'IA intégrées dans des logiciels existants et les utilisations, par les employés, d'assistants polyvalents. Chaque entrée doit préciser l'objectif commercial, les catégories de données, le responsable, le fournisseur, le modèle, les intégrations, l'importance de la décision et le niveau de supervision humaine.

Cet exercice mettra souvent en évidence des IA « fantômes », des outils en double et des systèmes consommant plus de données que ne le justifie l'analyse de rentabilité. Ces constatations ne doivent pas être considérées uniquement comme des manquements à la conformité. Elles témoignent du fait que les employés tentent de résoudre de réels problèmes liés aux flux de travail sans suivre la procédure approuvée.

L'organisation peut alors classer les cas d'utilisation en fonction de leurs conséquences. Un assistant qui reformate du texte interne ne nécessite pas le même environnement de contrôle qu'un système chargé de déterminer si un client peut bénéficier d'un prêt. La gouvernance doit être proportionnée, mais elle ne doit pas pour autant faire défaut.

Les processus présentant un risque élevé doivent faire l'objet de tests formels avant leur mise en service, notamment une évaluation de la protection de la vie privée, un examen de la sécurité, des tests adversariaux, des contrôles de la qualité des données et la définition de seuils de performance. Ils doivent également s'appuyer sur une méthode fiable permettant d'interrompre ou d'annuler le processus si le système sort de ces limites.

Le risque ne se limite plus à la simple perte de données

L'IA modifie les risques liés aux données, car celles-ci ne sont plus simplement stockées et consultées. Elles sont interprétées, combinées, font l'objet de déductions et sont utilisées pour prendre des décisions.

Une entreprise peut protéger le dossier client d'origine tout en générant un profil inexact à partir de celui-ci. Elle peut empêcher tout accès non autorisé à sa base de données tout en permettant à un assistant de divulguer des informations confidentielles dans une réponse générée. Elle peut conserver des journaux d'audit complets, mais se rendre compte que personne n'est chargé de les examiner.

Les meilleurs programmes de gouvernance de l'IA ne seront pas ceux qui approuvent le plus grand nombre d'outils ou qui rédigent les politiques les plus longues. Ce seront ceux qui garantissent une chaîne de responsabilité claire, depuis la saisie des données jusqu'aux résultats opérationnels.

Avant la mise en service d'un workflow basé sur l'IA, la direction doit être en mesure d'identifier les données dont il a besoin, les autorisations dont il dispose, les erreurs qu'il peut commettre et la personne habilitée à l'arrêter. Lorsque ces éléments ne sont pas clairement définis, l'automatisation n'a pas réduit le risque lié aux données de l'entreprise. Elle n'a fait que rendre ce risque plus rapide.