IA et conformité : 7 questions à poser avant tout déploiement en entreprise

Une équipe voit une démo impressionnante. En quelques minutes, tout le monde veut la tester avec de vraies données. C'est à ce moment que les vraies questions commencent : peut-on charger des documents clients ? Des CV de candidats ? Des contrats ? Des demandes médicales ? Ces questions ne sont pas seulement techniques — ce sont des questions de conformité. Et elles doivent être posées avant de brancher l'IA sur un processus réel, pas après le premier incident. Voici les sept questions qui séparent un projet contrôlé d'un projet qui expose l'entreprise.

Quelles données l'IA va-t-elle utiliser ?

La première question est la plus simple à formuler et la plus souvent oubliée : quelles catégories de données exactes l'IA va-t-elle voir ? Des textes internes anonymes ne créent pas les mêmes obligations que des données personnelles ou sensibles — noms, coordonnées, CV, données RH, informations de santé, documents juridiques. Dès que des données personnelles entrent en jeu, le RGPD s'applique : finalité définie, base légale, minimisation, durée de conservation. Une donnée floue produit un risque flou. Si personne ne sait précisément ce que l'IA lit, personne ne peut évaluer ce qu'elle expose.

Qu'a-t-elle le droit de faire ?

Un système d'IA n'a pas un seul niveau de risque : tout dépend de l'action qu'on lui confie. Résumer une politique interne n'a rien à voir avec envoyer un conseil directement à un client, trier des candidatures ou rejeter un dossier. Il faut donc définir deux choses : le rôle de l'IA, et ce qu'elle ne doit jamais faire. Peut-elle rédiger un brouillon soumis à validation, ou agir seule ? Peut-elle envoyer un message vers l'extérieur, ou seulement préparer un contenu interne ? Plus l'action a d'effet sur une personne, plus la limite doit être écrite noir sur blanc.

Ce cas d'usage crée-t-il un risque élevé ?

Certains domaines demandent des contrôles renforcés par nature : recrutement, RH, santé, juridique, finance, sécurité des personnes. Ce sont des cas où une erreur ou un biais ne coûte pas seulement du temps, mais peut affecter les droits, l'emploi ou la sécurité de quelqu'un. Le règlement européen sur l'IA (AI Act) suit exactement cette logique : il est fondé sur le risque. Plus l'impact d'un système est élevé, plus les obligations de transparence, de documentation et de supervision sont fortes. Classer honnêtement son cas d'usage — usage courant ou usage à fort impact — conditionne tout le reste du dispositif.

Qui reste responsable, et qui supervise ?

Quand l'IA produit une réponse utilisée dans une décision, qui en répond ? La réponse n'est jamais l'outil. Il faut attribuer des rôles clairs : un propriétaire du processus, un propriétaire des données, un propriétaire de la décision (dans une PME, une même personne peut en cumuler plusieurs). Cette responsabilité se traduit ensuite en supervision humaine concrète : qui relit les sorties, lesquelles exigent une approbation formelle avant d'être utilisées, et que se passe-t-il en cas de doute ou d'erreur ? La supervision doit être proportionnée au risque — légère pour un résumé interne, stricte pour une décision qui touche une personne.

Que promet le fournisseur par écrit ?

Beaucoup de garanties se donnent en réunion commerciale et disparaissent ensuite. Ce qui compte, c'est ce qui figure dans le contrat. Où les données sont-elles hébergées ? Sont-elles utilisées pour entraîner les modèles du fournisseur ? Combien de temps sont-elles conservées, et comment sont-elles supprimées ? Existe-t-il un accord de traitement des données (DPA) et une liste claire des sous-traitants ? Une entreprise qui déploie de l'IA sur des données réelles a besoin de réponses écrites, vérifiables, pas d'assurances orales. Si le fournisseur ne peut pas les mettre par écrit, c'est déjà une réponse.

Comment le système sera-t-il surveillé après le lancement ?

Un déploiement d'IA n'est pas terminé le jour de la mise en production. Le comportement d'un système change avec le temps : les usages dérivent, des erreurs apparaissent, les sources sur lesquelles il s'appuie sont mises à jour, un cas limite non prévu surgit. Il faut donc décider dès le départ comment on suit l'usage, les erreurs, la dérive et les mises à jour de sources, et comment on remonte un incident. Sans ce suivi, une entreprise ne découvre les problèmes que lorsqu'ils sont devenus visibles de l'extérieur — au pire moment.

Où se situe BeLogic

Chez BeLogic, nous déployons des agents IA autour d'un cas d'usage clair, de sources de données approuvées, d'une revue humaine définie, d'une visibilité sur les sources et d'une journalisation des actions. Concrètement : un agent qui prépare des brouillons soumis à validation plutôt qu'un système qui décide seul ; des données cadrées et hébergées dans l'UE ; des limites écrites sur ce que l'agent peut et ne peut pas faire ; un fournisseur qui s'engage par contrat. Nous accompagnons aussi nos clients pour situer leur projet vis-à-vis du RGPD et de l'AI Act, et pour accéder aux subventions régionales à l'IA. L'objectif n'est pas de ralentir l'IA, mais de la rendre à la fois utile et contrôlée — parce qu'un système que l'on peut expliquer est un système sur lequel on peut s'appuyer.