AI Act en Belgique : ce qui change depuis le 2 août 2026 et le plan d’action pour votre organisation

Ce qui change réellement depuis le 2 août 2026

Le changement le plus visible concerne la transparence : dans plusieurs situations, une personne doit pouvoir comprendre qu’elle interagit avec une IA ou qu’un contenu a été généré ou manipulé artificiellement. La Commission européenne a annoncé qu’à partir du 2 août 2026, l’AI Office et les autorités nationales commencent à faire appliquer le règlement et les nouvelles règles de transparence.

Les lignes directrices européennes relatives à l’article 50 distinguent les obligations des fournisseurs de celles des déployeurs. Les fournisseurs doivent notamment concevoir certains systèmes interactifs de manière à informer les personnes qu’elles communiquent avec une IA. Ils doivent aussi prévoir des marquages lisibles par machine pour rendre détectables certains contenus générés ou manipulés. Les déployeurs ont des devoirs d’information dans des cas tels que la reconnaissance des émotions, la catégorisation biométrique, les deepfakes et certaines publications sur des sujets d’intérêt public sans contrôle humain ou responsabilité éditoriale.

Il faut éviter deux raccourcis. Premièrement, tous les textes corrigés ou résumés avec une IA ne doivent pas automatiquement porter une étiquette spectaculaire. Les lignes directrices prévoient un périmètre, des définitions et des exceptions. Deuxièmement, ajouter la phrase « généré par IA » ne rend pas un système conforme à lui seul. La transparence est une couche de contrôle parmi d’autres : licéité des données, sécurité, droits d’accès, qualité, supervision humaine, documentation et gestion des incidents restent nécessaires selon le contexte.

Pour les systèmes mis sur le marché avant le 2 août 2026, la Commission mentionne une période limitée jusqu’au 2 décembre 2026 pour l’obligation de marquage et de détection de certains contenus générés. Cette transition ne doit pas être interprétée comme une suspension générale. Une organisation doit documenter précisément le système, sa date, son rôle dans la chaîne de valeur et l’obligation concernée avant de conclure qu’un délai s’applique.

Êtes-vous fournisseur, intégrateur ou simple utilisateur d’un système d’IA ?

Votre rôle détermine vos obligations. Acheter une licence et autoriser des collaborateurs à utiliser un assistant standard ne crée pas les mêmes responsabilités que développer un chatbot pour des clients, intégrer un modèle dans un logiciel métier ou commercialiser une solution sous sa propre marque.

Une organisation belge peut cumuler plusieurs rôles. Elle peut être déployeur lorsqu’elle utilise Microsoft 365 Copilot pour résumer des réunions, fournisseur lorsqu’elle propose à ses clients un assistant développé sous son nom, et opérateur d’un processus sensible lorsqu’elle emploie un système pour classer des candidatures ou influencer l’accès à un service. Il faut donc classifier les usages, pas simplement l’entreprise.

Posez quatre questions pour chaque système :

1. Qui choisit le modèle et définit la finalité ? Est-ce le fournisseur, votre équipe ou un prestataire qui configure le comportement ?
2. Qui expose le système au public ou aux travailleurs ? Un chatbot interne et un assistant destiné aux citoyens n’ont pas le même contexte.
3. Le système recommande-t-il ou prend-il une décision ? Plus il influence un recrutement, un crédit, une évaluation ou un accès, plus la gouvernance doit être exigeante.
4. Avez-vous modifié le système ou sa destination ? Une modification substantielle ou un nouvel usage peut changer la qualification juridique.

Pour les projets de chatbot, RAG, agents et automatisations, la conception doit intégrer ces questions dès le cadrage. La page Automatisation et intelligence artificielle de GVISION Studio décrit une approche où les accès, la validation humaine, les journaux et le suivi de qualité font partie du système, au lieu d’être ajoutés après le lancement.

Dans quels cas faut-il informer clairement les utilisateurs ?

La règle pratique est de ne jamais laisser une personne croire qu’elle échange avec un humain lorsque le canal est automatisé. Le message doit apparaître au bon moment, dans un langage compréhensible et via un support accessible. Une mention cachée dans les conditions générales ne remplit pas nécessairement l’objectif de transparence.

Chatbots et assistants conversationnels

Un chatbot de support, un assistant de qualification commerciale ou un réceptionniste vocal doit annoncer sa nature artificielle au début de l’interaction, sauf si celle-ci est évidente pour une personne raisonnablement informée et attentive. L’interface doit aussi indiquer comment contacter un humain lorsque le contexte le justifie. Dans un service critique, le transfert ne peut pas être un simple bouton décoratif : il faut définir les horaires, les priorités, les informations transmises et ce qui se passe lorsque personne n’est disponible.

Images, sons, vidéos et deepfakes

Les deepfakes doivent être signalés. Pour les fournisseurs, le marquage lisible par machine vise à aider les outils et plateformes à détecter les contenus artificiels. Pour le déployeur, une information visible et compréhensible peut également être nécessaire. Conservez la provenance du fichier, l’outil utilisé, la date, le responsable éditorial et la version publiée. Une campagne composée de dizaines de variantes devient rapidement impossible à auditer si ces informations restent dans la mémoire du graphiste.

Textes d’intérêt public

La publication de textes générés ou manipulés par une IA sur des sujets d’intérêt public peut entraîner une obligation d’information lorsqu’il n’y a pas de contrôle humain ou de responsabilité éditoriale. Le point décisif n’est donc pas seulement l’usage d’un outil, mais la présence d’une véritable revue : une personne compétente lit, corrige, valide les sources et assume la publication.

Reconnaissance des émotions et catégorisation biométrique

Ces usages exigent une prudence particulière. Ils peuvent relever d’obligations d’information, d’interdictions ou de régimes de risque plus élevés selon la finalité. Ne déployez pas une fonctionnalité présentée comme « analytique » sans comprendre ce qu’elle infère, sur quelles données et dans quel contexte professionnel, scolaire, médical ou commercial.

Le registre des usages IA : votre première preuve de maîtrise

Vous ne pouvez pas gouverner ce que vous ne connaissez pas. Un registre utile couvre les outils officiels, les essais, les fonctions d’IA déjà intégrées dans des logiciels existants et le « shadow AI », c’est-à-dire les services utilisés sans validation.

Pour chaque usage, documentez au minimum :

• le nom du système, du fournisseur et de la version ou du plan ;
• la finalité métier et les utilisateurs concernés ;
• le propriétaire métier et le responsable technique ;
• les catégories de données envoyées, créées ou récupérées ;
• les personnes exposées : employés, clients, candidats, élèves, patients, citoyens ou fournisseurs ;
• la décision ou l’action influencée par le résultat ;
• les intégrations avec Microsoft 365, CRM, ERP, SharePoint, sites web ou API ;
• la validation humaine, les limitations et le mécanisme d’escalade ;
• les journaux disponibles, la durée de conservation et l’emplacement des preuves ;
• le statut : expérimentation, autorisé, limité, à corriger ou interdit.

Commencez avec un tableur contrôlé si votre organisation compte peu d’usages. Pour un groupe multisite ou plusieurs équipes, utilisez une liste SharePoint ou un outil de gouvernance avec propriétaire, rappels et historique. Le support importe moins que la qualité des informations et la discipline de mise à jour.

Comment classer les usages sans transformer le registre en étude juridique interminable ?

Utilisez d’abord un tri opérationnel en quatre niveaux, puis faites valider les cas sensibles. Cette classification interne ne remplace pas la qualification du règlement, mais elle permet de concentrer les ressources.

Ajoutez trois indicateurs simples : l’impact possible sur une personne, la sensibilité des données et le degré d’autonomie. Un outil qui rédige un brouillon à relire n’a pas le même profil qu’un agent qui modifie automatiquement un dossier client ou refuse une demande.

Plan AI Act en 90 jours pour une organisation belge

Un programme réaliste avance par preuves successives : cadrer, inventorier, corriger les situations les plus exposées, puis intégrer les contrôles dans les projets et les achats.

Jours 1 à 15 : gouvernance et périmètre

Désignez un sponsor et un coordinateur. Réunissez IT, sécurité, DPO ou privacy, juridique, RH, communication et métiers selon vos usages. Définissez une règle d’escalade : qui peut suspendre un système, qui valide un nouveau fournisseur et qui répond à une plainte ? Publiez une consigne provisoire sur les outils autorisés et les données interdites en attendant l’analyse complète.

Jours 16 à 35 : inventaire et entretiens

Interrogez les équipes avec des questions concrètes : « Quel outil vous aide à rédiger ? », « Avez-vous activé un chatbot ? », « Une IA classe-t-elle des demandes ? ». Analysez les achats SaaS, extensions de navigateur, licences Microsoft, automatisations et projets Studio. Le but n’est pas de punir les expérimentations mais de rendre l’usage visible.

Jours 36 à 60 : classification et corrections prioritaires

Classez les usages, vérifiez les contrats, les données, les permissions et l’information des personnes. Corrigez d’abord les interactions publiques qui se présentent comme humaines, les contenus synthétiques non signalés, les décisions sensibles insuffisamment supervisées et les outils grand public utilisés avec des informations confidentielles.

Jours 61 à 90 : politique, preuves et intégration au changement

Transformez les conclusions en règles courtes : procédure d’achat, fiche de validation d’un cas d’usage, critères de test, modèle d’information, gestion d’incident et revue annuelle. Un audit informatique GVISION peut servir de cadre documenté lorsqu’il faut relier gouvernance, actifs, fournisseurs, cloud, contrôles et feuille de route, sans confondre cette démarche avec une certification juridique de conformité à l’AI Act.

Quelles preuves conserver en cas de contrôle, de plainte ou d’incident ?

Une preuve utile permet à un tiers de comprendre ce qui existait, qui a décidé et comment le contrôle fonctionnait à une date donnée. Une politique signée mais jamais appliquée a peu de valeur si aucun système, propriétaire ou test ne peut lui être relié.

• versions datées du registre et décisions d’autorisation ;
• contrats, conditions de traitement, localisation et sous-traitants pertinents ;
• analyse du rôle de l’organisation et de la finalité ;
• captures ou spécifications des messages de transparence ;
• journaux de tests, résultats, limites connues et critères d’acceptation ;
• liste des personnes autorisées et revue des accès ;
• preuve de formation et consignes remises aux utilisateurs ;
• incidents, fausses réponses significatives, plaintes et mesures correctives ;
• validation éditoriale des contenus d’intérêt public ;
• revue périodique après changement de modèle, d’intégration ou de finalité.

Évitez de conserver davantage de données personnelles que nécessaire sous prétexte d’auditabilité. La preuve doit être proportionnée, protégée et soumise à une durée de conservation. Les exigences de l’AI Act ne suppriment pas celles du RGPD, de la sécurité de l’information ou du droit du travail.

Sept erreurs fréquentes dans les projets AI Act

1. Réduire l’AI Act à une politique d’utilisation. La politique doit s’appuyer sur un registre et des contrôles réels.
2. Inventorier uniquement les licences achetées par l’IT. Les fonctions intégrées, essais et outils individuels restent invisibles.
3. Traiter toutes les IA comme équivalentes. Finalité, données, personnes affectées et autonomie modifient le risque.
4. Afficher un label sans revoir le processus. La transparence ne corrige ni un accès excessif ni une décision non supervisée.
5. Interdire sans proposer d’alternative. Les collaborateurs contournent plus facilement une règle qui bloque un besoin légitime.
6. Confondre fournisseur et déployeur. Un projet sur mesure ou commercialisé peut augmenter les responsabilités.
7. Faire l’analyse une seule fois. Les modèles, fonctions, données et intégrations évoluent rapidement.