AI Act et systèmes GenAI : organiser la documentation utile à une équipe technique

Documenter un système GenAI pour l’AI Act ne consiste pas à produire un dossier juridique après le build. Il faut relier le cas d’usage, le rôle de l’organisation, les données, les versions, les contrôles, les tests, les incidents et les décisions de changement. Une équipe technique peut ainsi montrer ce qui a été conçu, ce qui a été observé et qui a validé les évolutions.

En bref

Commencez par une fiche de périmètre : usage réel, personnes concernées, décisions influencées, rôle de l’organisation et systèmes reliés.
Ne confondez pas la documentation technique attendue pour un système à haut risque avec le dossier d’exploitation d’un déployeur. Les deux se complètent, sans avoir le même responsable.
Versionnez les éléments qui changent le comportement : modèle, prompt système, règles, connecteurs, corpus, tests et droits d’accès.
Préparez des preuves lisibles : résultat de test, décision de risque, trace d’exécution minimisée, validation et lien vers la version concernée.

IgnitionAI accompagne les responsables techniques pour cadrer, construire et mettre en production des systèmes GenAI d’entreprise. Cette page propose une méthode de documentation. Elle ne permet pas, à elle seule, de qualifier juridiquement un système ni d’attester sa conformité.

Pourquoi une documentation technique devient-elle un sujet d’architecture ?

Dans un système GenAI, le comportement ne dépend pas seulement du code applicatif. Il peut aussi changer avec un modèle, une configuration de récupération, un prompt, un connecteur, une politique d’autorisation ou un jeu de données. Si ces éléments ne sont pas reliés, l’équipe ne peut pas expliquer pourquoi une réponse, un refus ou une action a changé.

Le Règlement (UE) 2024/1689 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. Son annexe IV décrit notamment des éléments sur la finalité du système, son développement, ses données, sa surveillance humaine, son exactitude, sa robustesse, sa cybersécurité, sa gestion des risques et son cycle de vie.

Cette exigence ne signifie pas que tout projet GenAI relève du régime des systèmes à haut risque. La qualification dépend du cas d’usage, du rôle de l’organisation et du cadre applicable. La bonne première question n’est donc pas « quel modèle utilisons-nous ? », mais « quelle décision ce système soutient-il ou produit-il, pour qui et dans quel contexte ? »

Quelle fiche de périmètre faut-il ouvrir avant le build ?

Une fiche de périmètre courte évite que la documentation se transforme en inventaire de composants sans usage métier. Elle sert aussi à déclencher les bonnes revues avant qu’un connecteur ou une automatisation ne devienne difficile à modifier.

Élément	Question à documenter	Preuve ou responsable à relier
Cas d’usage	Quelle tâche est assistée, recommandée ou exécutée ?	Description validée par le propriétaire métier
Personnes concernées	Qui utilise le système ou subit ses effets ?	Population, contexte et limites d’usage
Décision	Le système informe-t-il, recommande-t-il ou déclenche-t-il une action ?	Décision humaine attendue et cas de refus
Rôle de l’organisation	L’organisation fournit-elle, déploie-t-elle, distribue-t-elle ou modifie-t-elle le système ?	Analyse de rôle à faire valider par les fonctions compétentes
Dépendances	Quels modèles, outils, sources et systèmes aval interviennent ?	Registre de fournisseurs, connecteurs et propriétaires
Données	Quelles données entrent, sortent ou sont recherchées ?	Classification, source de vérité et règles d’accès

Pour un RAG, ajoutez les documents recherchés, les identités utilisées, la règle qui limite la récupération et le comportement attendu lorsqu’aucune source n’est accessible. Le guide sur le contrôle d’accès dans un RAG détaille les choix qui doivent rester vérifiables entre la source et la réponse.

Comment distinguer le dossier du fournisseur de celui du déployeur ?

Les rôles prévus par le règlement ne désignent pas automatiquement les équipes internes. Une même organisation peut occuper plusieurs rôles selon ce qu’elle construit, met à disposition, modifie ou utilise. Cette analyse doit être menée sur le cas concret.

Pour un système à haut risque, la documentation technique visée à l’article 11 et à l’annexe IV concerne le système et relève notamment des obligations du fournisseur. De son côté, le déployeur doit notamment utiliser le système conformément aux instructions, organiser la surveillance humaine lorsqu’elle s’applique, suivre le fonctionnement, conserver certains journaux sous son contrôle et signaler les incidents graves selon les conditions prévues par le règlement.

En pratique, une équipe technique peut organiser deux espaces reliés :

Le dossier du système. Il décrit le cas d’usage, l’architecture, les composants, les limites, les risques, les tests et les changements.
Le dossier d’exploitation. Il décrit les accès, les procédures, la supervision, les traces, les incidents, les mises en production et les décisions prises sur le terrain.

Cette séparation évite une erreur fréquente : demander à l’équipe qui exploite un système de reconstituer seule les informations que le fournisseur doit fournir, ou inversement supposer que la notice fournisseur décrit les permissions, corpus et processus internes du déployeur.

Quels éléments versionner dans un système GenAI ?

La documentation doit permettre de comparer un comportement observé à une configuration précise. Pour cela, ne versionnez pas seulement le dépôt de code. Établissez une convention de version pour les éléments qui modifient le périmètre, les données accessibles ou les sorties attendues.

Élément qui change	Référence à conserver	Question de contrôle
Modèle et fournisseur	Identifiant de modèle, paramètres et date de mise à jour connue	Quel comportement ou quelle limite peut changer ?
Prompts et règles	Version du prompt système et des garde-fous	Qui a validé la modification et quels tests ont été rejoués ?
Corpus RAG	Source, périmètre, date d’ingestion et règles de droits	Quels documents pouvaient être récupérés ?
Connecteurs et outils	Opérations autorisées, identités techniques et limites de portée	Une action peut-elle dépasser ce qui est prévu ?
Politique d’accès	Source de vérité, attributs utilisés et mécanisme de révocation	Qu’est-ce qui prouve qu’un refus reste effectif ?
Jeu de tests	Cas, résultat attendu, version et résultat observé	Quel écart a été accepté, corrigé ou reporté ?

Un identifiant de version n’est utile que s’il est rattaché à une décision. Lorsqu’une équipe change un modèle ou ouvre un nouveau connecteur, elle doit pouvoir retrouver la demande de changement, l’analyse de risque, les tests exécutés, l’approbation et le plan de retour arrière.

Le jeu de tests RAG représentatif propose une structure pour conserver les cas, les résultats attendus et les écarts. Pour un système agentique, complétez-la avec les limites d’action et les validations humaines adaptées à chaque opération.

Comment documenter les risques sans créer un registre abstrait ?

Un registre de risques devient exploitable lorsqu’il est lié à une fonction du système, à une situation d’usage, à une mesure de maîtrise et à une preuve de vérification. Évitez les entrées générales telles que « hallucination » ou « fuite de données » sans scénario précis.

Une entrée utile peut répondre à ces questions :

quelle sortie, décision ou action peut créer un dommage ;
dans quelles conditions l’écart peut se produire ;
quelle personne, donnée ou activité peut être affectée ;
quel contrôle prévient, détecte ou limite l’écart ;
comment ce contrôle est testé et qui traite l’échec ;
quelle décision a été prise sur le risque résiduel.

Par exemple, pour un assistant RAG connecté à des documents internes, un scénario n’est pas seulement « accès non autorisé ». Il peut préciser qu’un passage issu d’un espace restreint est récupéré pour une identité qui ne dispose pas des droits correspondants. La preuve attendue peut associer un test négatif, la politique d’accès appliquée, la trace minimisée de la recherche et la décision de correction.

Cette approche rejoint le profil GenAI du NIST, qui invite les organisations à documenter les risques et impacts, à surveiller les sorties et à suivre les erreurs ou incidents selon leur contexte. Elle ne remplace pas une analyse juridique, sécurité ou protection des données.

Quelles traces faut-il relier à la documentation ?

Les journaux ne doivent pas devenir une copie durable des conversations et données métier. Leur fonction est de soutenir l’exploitation, l’investigation et le suivi des contrôles avec un niveau de détail proportionné.

Pour une exécution importante, reliez au minimum :

un identifiant de trace et l’horodatage ;
la version du workflow, du modèle et des règles ;
l’identité ou le rôle autorisé, sous une forme minimisée lorsque cela suffit ;
la décision de politique ou de validation appliquée ;
l’outil ou le connecteur appelé et la portée de l’opération ;
le résultat technique, l’échec ou le refus ;
la référence vers l’incident, la revue ou la décision de changement si un écart est détecté.

La méthode de traçabilité d’un agent IA explique comment séparer une proposition, un contrôle, une autorisation et une exécution. Cette distinction est importante : une action envisagée par un modèle n’est pas une action exécutée.

Quelle revue préparer avant une mise en production ?

Avant une ouverture à des utilisateurs, préparez une revue courte qui examine les preuves plutôt qu’un document rédigé en dernière minute. Les participants et critères dépendent du cas d’usage, mais la revue doit pouvoir répondre aux questions suivantes :

le périmètre et le rôle de l’organisation sont-ils décrits et soumis à la bonne validation ;
les données, droits d’accès, connecteurs et actions autorisées sont-ils identifiés ;
les risques prioritaires sont-ils reliés à des contrôles et à des tests observables ;
les personnes chargées de surveiller, arrêter ou escalader le système connaissent-elles leur rôle ;
les traces permettent-elles d’expliquer un refus, une erreur ou une action à impact sans surexposer les données ;
le plan de changement prévoit-il un propriétaire, des tests, une approbation et un retour arrière.

Si une réponse manque, l’équipe peut réduire le périmètre : lecture seule, corpus limité, opérations interdites ou ouverture à un groupe restreint. Cette décision est plus utile qu’une déclaration générale de conformité. La grille de go/no-go d’un prototype LLM peut servir à formaliser ce choix avant le déploiement.

La documentation devient utile à l’exploitation lorsqu’elle est reprise et testée par l’équipe responsable du système. Notre guide sur le transfert d’un système GenAI aux équipes internes détaille le dossier, les responsabilités et l’exercice de reprise à préparer avant la livraison.

FAQ

La documentation AI Act est-elle réservée aux systèmes à haut risque ?

Non. Les obligations exactes dépendent de la qualification du système et du rôle de l’organisation. Même lorsqu’un système ne relève pas du régime des systèmes à haut risque, une documentation de périmètre, de versions, de risques et de décisions aide à l’exploiter et à vérifier les exigences applicables.

Faut-il documenter un modèle externe utilisé par API ?

Oui, au moins son rôle dans votre système, la version ou référence disponible, ses limites connues, les paramètres d’intégration et les contrôles ajoutés par votre équipe. La documentation du fournisseur ne décrit pas automatiquement votre corpus, vos droits d’accès ni vos règles d’exploitation.

Une fiche de documentation prouve-t-elle la conformité AI Act ?

Non. Elle constitue une preuve de travail et de décision. La conformité dépend du cas d’usage, des obligations applicables, de la qualité de leur mise en œuvre et des validations appropriées.

Quand mettre à jour le dossier d’un système GenAI ?

Mettez-le à jour lorsqu’un changement peut modifier le cas d’usage, les personnes concernées, les données, les droits, les performances, les risques ou le fonctionnement opérationnel. L’équipe doit définir des déclencheurs de revue plutôt que se limiter à une révision annuelle abstraite.

Méthodologie et sources

Règlement (UE) 2024/1689 sur l’intelligence artificielle, Journal officiel de l’Union européenne, 12 juillet 2024, consulté le 19 septembre 2026. Références mobilisées : article 11 et annexe IV sur la documentation technique des systèmes à haut risque, article 12 sur la tenue de registres, article 14 sur la surveillance humaine, article 18 sur la conservation de la documentation par le fournisseur et article 26 sur certaines obligations des déployeurs.
Commission européenne, Navigating the AI Act, consulté le 19 septembre 2026. La page présente les rôles, l’approche fondée sur les risques et les principales exigences applicables aux systèmes à haut risque.
NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, juillet 2024, consulté le 19 septembre 2026. Le profil propose des pratiques de documentation, de surveillance et de gestion des risques à adapter au contexte.

Cette page ne contient ni résultat client, ni estimation de délai, de coût ou de conformité. Elle présente un cadre de travail technique. La qualification d’un système et les obligations applicables doivent être évaluées dans le contexte réel de l’organisation avec les fonctions compétentes.

Vous devez relier architecture, risques, tests et exploitation avant d’ouvrir un système GenAI ? Décrivez votre contexte à IgnitionAI. Un premier échange peut aider à cadrer le dossier de décision, les preuves techniques et les responsabilités à clarifier.