AI Act : la feuille de route pour mettre votre entreprise en conformité

Ce que cet article présente :

Mais utiliser une IA ne consiste plus uniquement à choisir un modèle performant.
L’entreprise doit désormais savoir quelles données sont traitées, qui utilise le système, dans quel objectif, avec quels risques et sous quelle responsabilité.
L’AI Act européen adopte une approche fondée sur le niveau de risque.
Toutes les applications ne sont donc pas soumises aux mêmes obligations.
Une première analyse doit déterminer si le système relève d’un risque minimal, d’une obligation de transparence ou d’une catégorie à haut risque.

L’intelligence artificielle entre progressivement dans les processus quotidiens des entreprises : assistants documentaires, génération de contenus, analyse de contrats, automatisation commerciale, recrutement, formation, support client ou aide à la décision.

Mais utiliser une IA ne consiste plus uniquement à choisir un modèle performant. L’entreprise doit désormais savoir quelles données sont traitées, qui utilise le système, dans quel objectif, avec quels risques et sous quelle responsabilité.

L’AI Act européen adopte une approche fondée sur le niveau de risque. Toutes les applications ne sont donc pas soumises aux mêmes obligations. Une première analyse doit déterminer si le système relève d’un risque minimal, d’une obligation de transparence ou d’une catégorie à haut risque. Les domaines à haut risque comprennent notamment certains usages liés à l’emploi, à l’éducation, aux infrastructures critiques, à la biométrie, à la migration ou à l’accès à des services essentiels.

Depuis le 2 août 2026, les autorités européennes et nationales ont commencé à faire appliquer plusieurs dispositions du règlement. Les obligations de transparence de l’article 50 sont notamment devenues applicables pour certains systèmes interactifs ou génératifs. Les principales règles relatives aux systèmes à haut risque de l’annexe III s’appliqueront à partir du 2 décembre 2027, tandis que celles concernant les systèmes intégrés à certains produits réglementés s’appliqueront à partir du 2 août 2028.

Ces échéances ne doivent pas être comprises comme une invitation à attendre. Inventorier les usages, retrouver les documents, tester les modèles, définir les responsabilités et constituer les preuves peut demander plusieurs mois.

Internet Creative Center, ou ICC, a développé un logiciel de gestion locale du registre et des processus de l’AI Act. Installé sur l’infrastructure de l’entreprise, il centralise les systèmes d’IA, les analyses de risques, les tests, les journaux, les incidents, les versions et les validations humaines.

Cette étude présente les principales obligations administratives et techniques, puis montre comment le logiciel ICC permet de les transformer en une feuille de route opérationnelle.

AI Act européen : quelles obligations administratives et techniques pour votre entreprise ?

AI Act : commencer par organiser la gouvernance et les obligations administratives

La première difficulté rencontrée par les entreprises n’est généralement pas technique. Elle consiste à savoir où l’intelligence artificielle est utilisée.

Un service peut utiliser un abonnement à une IA générative, un autre peut avoir installé un modèle local et un troisième peut automatiser des traitements avec n8n sans qu’aucun registre central n’existe.

La conformité commence donc par un travail administratif structuré.

1. Inventorier tous les systèmes d’intelligence artificielle

L’entreprise doit constituer une fiche pour chaque système identifié :

nom du logiciel ou du projet ;
service utilisateur ;
finalité recherchée ;
modèle ou fournisseur utilisé ;
hébergement local ou distant ;
données traitées ;
personnes concernées ;
responsable métier ;
responsable technique ;
date de mise en service ;
statut du projet.

Cette étape permet de découvrir les usages non déclarés, les abonnements individuels, les outils expérimentaux et les automatisations qui traitent déjà des données internes.

2. Déterminer le rôle de l’entreprise

Les responsabilités peuvent changer selon la manière dont le système est conçu et utilisé.

L’entreprise peut notamment agir comme :

déployeur, lorsqu’elle utilise un système fourni par un tiers ;
fournisseur, lorsqu’elle développe un système ou le commercialise sous son nom ;
intégrateur, lorsqu’elle associe plusieurs composants pour produire une nouvelle application ;
importateur ou distributeur, dans certaines chaînes de commercialisation.

Installer un modèle open source ne dispense pas automatiquement de toute obligation. La finalité de l’application, les modifications réalisées et le rôle de l’organisation restent déterminants.

3. Qualifier le niveau de risque

Chaque fiche doit comporter un questionnaire de qualification :

le système entre-t-il dans la définition d’un système d’IA ?
son utilisation pourrait-elle relever d’une pratique interdite ?
est-il utilisé dans un domaine mentionné par l’annexe III ?
influence-t-il une décision concernant une personne ?
est-il intégré à un produit soumis à une réglementation sectorielle ?
interagit-il directement avec des personnes ?
génère-t-il des images, des vidéos, des sons ou des textes ?
une obligation d’information ou de marquage s’applique-t-elle ?

Cette qualification ne doit pas uniquement produire une case « conforme » ou « non conforme ». Le logiciel doit conserver la justification, les textes examinés, la personne ayant réalisé l’analyse et la date de la prochaine révision.

4. Définir une politique interne d’utilisation de l’IA

Une politique interne doit expliquer :

quels outils sont autorisés ;
quelles données peuvent être utilisées ;
quelles informations sont interdites dans les prompts ;
quels résultats nécessitent une vérification humaine ;
comment signaler une erreur ou un incident ;
qui peut installer ou modifier un modèle ;
qui valide la mise en production ;
quelles règles s’appliquent aux prestataires.

La politique devient ainsi un référentiel commun pour les collaborateurs, les responsables, le service informatique et les prestataires externes.

5. Documenter les risques conformément à l’article 9

Pour les systèmes d’IA à haut risque, l’article 9 prévoit un processus continu et itératif de gestion des risques pendant tout le cycle de vie. Les risques doivent être identifiés, analysés, évalués, réduits et régulièrement réexaminés. Des tests doivent permettre de vérifier que les mesures choisies fonctionnent réellement.

Le registre des risques doit notamment contenir :

la description du risque ;
la cause possible ;
les personnes ou processus concernés ;
la probabilité ;
la gravité ;
le niveau de risque initial ;
les mesures de réduction ;
le risque résiduel ;
le responsable de l’action ;
l’échéance et le statut.

Les risques peuvent concerner une hallucination, une erreur de classement, une discrimination, une divulgation de données, un jailbreak, une mauvaise décision ou l’indisponibilité du système.

6. Organiser les responsabilités et les validations

Une démarche AI Act doit identifier :

le responsable du registre ;
le propriétaire métier de chaque système ;
le responsable de l’infrastructure ;
les personnes chargées des tests ;
les personnes autorisées à valider une mise en production ;
les responsables de la surveillance humaine ;
le circuit d’escalade en cas d’incident.

L’article 14 prévoit que les systèmes à haut risque puissent être effectivement surveillés par des personnes capables de comprendre leurs limites, d’interpréter les résultats, de ne pas les utiliser, de les corriger ou d’interrompre le système.

7. Former les utilisateurs

Une personne qui utilise une IA doit comprendre :

que le modèle peut se tromper ;
qu’une réponse vraisemblable n’est pas nécessairement exacte ;
que certaines données ne doivent jamais être communiquées ;
qu’un résultat important doit être vérifié ;
comment signaler un comportement anormal ;
dans quelles situations l’intervention humaine est obligatoire.

La formation ne doit pas rester une déclaration générale. Les participants, les dates, les contenus et les validations doivent pouvoir être retrouvés.

8. Gérer les fournisseurs et les documents contractuels

Pour chaque outil externe, l’entreprise doit conserver les informations disponibles sur :

l’identité du fournisseur ;
le modèle utilisé ;
la localisation des traitements ;
les conditions de réutilisation des données ;
les durées de conservation ;
les sous-traitants ;
les procédures de sécurité ;
les limitations connues ;
la réversibilité ;
les conditions de suppression des données.

La documentation n’est pas un dossier créé une seule fois. Elle doit évoluer avec les versions du système et les modifications de son utilisation.

Transformer les obligations administratives en preuves techniques

Un registre correctement rempli ne suffit pas lorsqu’il ne correspond pas au fonctionnement réel du système.

L’entreprise doit pouvoir démontrer que les mesures annoncées sont effectivement appliquées dans l’architecture technique.

1. Maîtriser l’hébergement et les flux de données

Pour chaque système, il faut pouvoir répondre aux questions suivantes :

où le modèle fonctionne-t-il ?
où les documents sont-ils stockés ?
où les embeddings sont-ils enregistrés ?
quels services reçoivent les prompts ?
quels journaux sont conservés ?
quelles données quittent l’entreprise ?
quels composants peuvent accéder aux secrets ?

Une installation locale facilite la maîtrise de ces flux. Le modèle, les bases documentaires, les workflows et les journaux peuvent rester sur une infrastructure contrôlée par l’entreprise.

Le fonctionnement local ne constitue cependant pas, à lui seul, une garantie de conformité. Le serveur doit également être configuré, administré, sauvegardé et surveillé correctement.

2. Gérer les données et leur qualité

L’article 10 impose, pour les systèmes à haut risque concernés, une gouvernance adaptée des données utilisées pour l’entraînement, la validation et les tests. L’entreprise doit notamment s’intéresser à leur origine, leur pertinence, leur représentativité, leur qualité et aux biais susceptibles d’affecter les résultats.

Dans un système RAG local, cela implique de documenter :

la provenance de chaque document ;
son propriétaire ;
sa date de mise à jour ;
son niveau de confidentialité ;
sa durée de conservation ;
la méthode de découpage ;
le modèle d’embedding ;
la collection Qdrant utilisée ;
les règles de suppression et de réindexation.

3. Conserver la documentation technique

L’article 11 prévoit, pour les systèmes à haut risque, une documentation technique établie avant la mise sur le marché ou la mise en service et tenue à jour.

Dans la pratique, le dossier technique peut comprendre :

l’architecture du système ;
les composants logiciels ;
les versions des modèles ;
les prompts système ;
les workflows n8n ;
les paramètres Qdrant ;
les mécanismes d’authentification ;
les sauvegardes ;
les tests réalisés ;
les limites connues.

4. Journaliser le fonctionnement

L’article 12 prévoit que les systèmes d’IA à haut risque permettent l’enregistrement automatique des événements nécessaires à la traçabilité, à l’identification des risques, à la surveillance et au suivi après déploiement.

Le logiciel ICC peut centraliser les événements provenant :

de l’interface utilisateur ;
du modèle local ;
des workflows n8n ;
de la base Qdrant ;
du système d’authentification ;
du pare-feu applicatif ;
des mécanismes de sauvegarde ;
des tests de sécurité.

Les déployeurs de systèmes à haut risque doivent conserver les journaux placés sous leur contrôle pendant une durée adaptée à la finalité du système et, en principe, pendant au moins six mois, sauf autre règle applicable.

5. Tester avant la mise en production

Un système doit être testé à partir de situations représentatives de son utilisation réelle.

Les campagnes peuvent porter sur :

la précision des réponses ;
la récupération des bonnes sources ;
les erreurs de calcul ;
les hallucinations ;
les différences de comportement selon la langue ;
les tentatives de jailbreak ;
les demandes de divulgation de secrets ;
les règles métier à ne jamais contourner ;
les performances et les temps de réponse ;
la résistance à une indisponibilité technique.

Chaque test doit indiquer la question, le résultat attendu, le résultat obtenu, la version du modèle, les sources utilisées, la date, le testeur et la décision finale.

6. Assurer la robustesse et la cybersécurité

L’article 15 demande que les systèmes à haut risque atteignent un niveau approprié de précision, de robustesse et de cybersécurité. Il vise notamment la protection contre les attaques, l’empoisonnement des données ou des modèles, les exemples adversariaux et les atteintes à la confidentialité.

Une infrastructure locale doit donc intégrer :

une authentification forte ;
une gestion des rôles ;
la séparation des comptes administratifs ;
le chiffrement des communications ;
la limitation des ports exposés ;
la protection des collections documentaires ;
le filtrage des entrées et des réponses ;
la détection des injections de prompt ;
des sauvegardes testées ;
un plan de restauration.

7. Maintenir un contrôle humain réel

Le responsable désigné doit pouvoir :

consulter les sources utilisées ;
comprendre les limites du système ;
refuser une sortie ;
corriger une réponse ;
suspendre un workflow ;
désactiver un modèle ;
interrompre le système ;
valider la remise en service.

Pour les déployeurs de systèmes à haut risque, l’article 26 prévoit notamment des mesures techniques et organisationnelles adaptées, la désignation de personnes compétentes pour la surveillance humaine, le suivi du fonctionnement, la conservation de certains journaux et la remontée des risques ou incidents.

8. Informer les utilisateurs

Depuis le 2 août 2026, certaines obligations de transparence de l’article 50 sont applicables. Les utilisateurs d’un système interactif doivent notamment pouvoir comprendre qu’ils interagissent avec une intelligence artificielle lorsqu’il existe un risque de confusion. Certaines catégories de contenus générés ou manipulés doivent également être identifiables ou signalées.

Le logiciel de registre doit conserver :

le texte d’information utilisé ;
les interfaces sur lesquelles il apparaît ;
les catégories de contenus concernées ;
les mécanismes de marquage ;
les dates de vérification ;
les responsables de la validation.

9. Gérer les incidents et les corrections

Une fiche d’incident doit pouvoir être créée lorsqu’un événement significatif est détecté :

divulgation d’une donnée confidentielle ;
échec d’un garde-fou ;
tentatives répétées de jailbreak ;
décision erronée ayant produit un impact ;
altération d’un journal ;
accès non autorisé ;
action exécutée sans validation humaine ;
indisponibilité prolongée du système.

La fiche relie l’événement à sa cause, aux versions concernées, aux mesures immédiates, aux actions correctives et aux nouveaux tests.

10. Gérer les modifications et les non-régressions

Le remplacement d’un modèle, la modification d’un prompt ou l’évolution d’un workflow peut changer le comportement de l’ensemble du système.

Chaque modification doit donc comporter :

une description ;
un responsable ;
une date ;
une estimation de l’impact ;
une campagne de tests ;
une validation humaine ;
une procédure de retour arrière ;
une nouvelle version documentée.

Le logiciel ICC crée ainsi un lien entre les obligations administratives et les preuves techniques réellement produites par le serveur local.

La feuille de route ICC : passer progressivement de l’inventaire à une gouvernance opérationnelle

Internet Creative Center propose une feuille de route en huit étapes. Elle permet d’éviter deux erreurs fréquentes : commencer par remplir des documents génériques sans connaître les systèmes utilisés, ou installer des protections techniques sans organiser les responsabilités.

Étape 1 — Recenser

Objectif : retrouver tous les systèmes d’intelligence artificielle utilisés dans l’organisation.

Dans le logiciel ICC :

création des fiches système ;
identification des responsables ;
description des finalités ;
inventaire des modèles et fournisseurs ;
cartographie des données et des services.

Livrable : registre centralisé des systèmes d’IA.

Étape 2 — Qualifier

Objectif : déterminer le niveau de risque et les obligations potentiellement applicables.

Dans le logiciel ICC :

questionnaire de qualification ;
identification du rôle de l’entreprise ;
analyse des pratiques interdites ;
analyse du risque de transparence ;
examen des catégories à haut risque ;
conservation de la justification.

Livrable : fiche de qualification AI Act pour chaque système.

Étape 3 — Organiser

Objectif : attribuer les responsabilités et formaliser les règles.

Dans le logiciel ICC :

matrice des responsabilités ;
politique d’utilisation ;
circuit de validation ;
gestion des habilitations ;
suivi des formations ;
calendrier des révisions.

Livrable : plan de gouvernance de l’intelligence artificielle.

Étape 4 — Évaluer

Objectif : identifier les risques administratifs, techniques et humains.

Dans le logiciel ICC :

registre des risques ;
notation de la probabilité et de la gravité ;
mesures de réduction ;
responsables et échéances ;
suivi du risque résiduel.

Livrable : cartographie des risques par système.

Étape 5 — Sécuriser

Objectif : appliquer les protections correspondant aux risques identifiés.

Sur le serveur local ICC :

hébergement local des modèles ;
contrôle des accès ;
segmentation des données ;
protection des documents Qdrant ;
journalisation des workflows ;
filtrage des prompts et des réponses ;
sauvegardes et restauration.

Livrable : plan de sécurisation et preuves de configuration.

Étape 6 — Tester

Objectif : vérifier le comportement du système avant son utilisation réelle.

Dans le logiciel ICC :

plans de test ;
réponses attendues ;
tests de recherche documentaire ;
tests de raisonnement ;
tests de jailbreak ;
tests de non-régression ;
validation ou refus de mise en production.

Livrable : rapport de campagne de tests.

Étape 7 — Surveiller

Objectif : conserver la trace du fonctionnement et détecter les anomalies.

Dans le logiciel ICC :

journal de sécurité ;
historique des versions ;
suivi des alertes ;
indicateurs de performance ;
contrôle de l’intégrité des journaux ;
tableau de bord des actions en retard.

Livrable : tableau de bord de surveillance de l’IA.

Étape 8 — Corriger et démontrer

Objectif : traiter les incidents et constituer un dossier de preuves exploitable.

Dans le logiciel ICC :

création des fiches d’incident ;
analyse de la cause ;
actions correctives ;
validation humaine ;
nouveaux tests ;
clôture de l’incident ;
export du dossier documentaire.

Livrable : dossier de gouvernance, de suivi et de preuves.

Ce que comprend l’offre Internet Creative Center

Le logiciel ICC est proposé au tarif de :

3 500 € HT

Logiciel, installation et formation incluses

L’offre comprend notamment :

l’installation du logiciel sur l’infrastructure locale ;
la configuration initiale ;
la création du registre de l’organisation ;
la présentation des différentes fiches ;
la formation des responsables ;
la prise en main du registre des risques ;
la présentation des plans de tests et des incidents ;
la mise en place des premiers accès utilisateurs.

La maintenance est proposée au tarif de :

750 € HT par an

Elle comprend le maintien du logiciel, les corrections, les mises à jour fonctionnelles prévues au contrat et l’assistance selon les conditions de l’offre.

Pourquoi choisir une solution locale ?

Le registre AI Act peut contenir des informations particulièrement sensibles :

les systèmes utilisés par l’entreprise ;
les vulnérabilités détectées ;
les incidents de sécurité ;
les documents confidentiels concernés ;
les versions des modèles ;
les comptes techniques ;
les actions correctives ;
les décisions des responsables.

Avec une installation locale, ces informations demeurent dans l’environnement maîtrisé par l’organisation. Les accès, les sauvegardes et les flux peuvent être définis selon sa politique de sécurité.

Pour conclure sur : " AI Act : la feuille de route pour mettre votre entreprise en conformité "

L’AI Act ne se résume pas à un formulaire administratif ou à l’ajout d’une mention légale sur un site internet.

La démarche nécessite de relier plusieurs dimensions :

l’inventaire des systèmes ;
leur qualification ;
les responsabilités ;
la gestion des risques ;
la documentation technique ;
la qualité des données ;
les tests ;
la journalisation ;
la surveillance humaine ;
la cybersécurité ;
le traitement des incidents.

Un document administratif affirme qu’une règle existe. Une preuve technique démontre qu’elle est réellement appliquée.

Le logiciel local développé par Internet Creative Center rapproche ces deux dimensions. Il centralise les fiches administratives et les relie aux versions des modèles, aux plans de test, aux journaux de sécurité, aux incidents et aux décisions humaines.

Il permet ainsi à l’entreprise de construire progressivement sa gouvernance, de retrouver les informations nécessaires et de préparer les éléments utiles à une démarche de conformité.

L’offre complète est proposée à 3 500 € HT, installation et formation comprises, puis 750 € HT par an pour la maintenance.

Demander une démonstration du logiciel AI Act ICC

Le logiciel constitue un outil de gouvernance, de documentation et de suivi. Il ne délivre pas automatiquement une certification juridique et ne remplace pas l’analyse d’un conseil compétent lorsque la qualification ou les obligations applicables nécessitent une expertise particulière.