# AI Act européen : la classification d’un connecteur IA relié à Stripe > « Un système d'IA à haut risque se définit par son usage, pas par sa technologie. » Checklist des obligations de transparence à vérifier pour un connecteur IA manipulant des données de paiement. - Auteur : Clément Hadrot - Publié le : 2024-07-27 - Mis à jour le : 2024-07-27 - Catégorie : IA & MCP - URL : https://wpmoderne.dev.wordpress-developpement.fr/ia-mcp/ai-act-classification-connecteur-ia-stripe/ ## L’essentiel - Le niveau de risque dépend de l'usage, pas de la complexité du modèle - La documentation technique doit exister avant la mise en production - La transparence envers l'utilisateur final est une obligation distincte du risque « Un système d'IA à haut risque se définit par son usage, pas par sa technologie. » Cette phrase, reprise presque mot pour mot des lignes directrices publiées autour du règlement européen sur l'intelligence artificielle, aurait mérité d'être affichée au-dessus du bureau de l'équipe technique de l'éditeur logiciel Fintarive avant qu'elle ne commence à développer son connecteur IA relié à Stripe. Le connecteur en question permet à un agent conversationnel de répondre à des questions sur des paiements, de proposer des remboursements partiels sous validation humaine, et de signaler des schémas de transaction suspects à une équipe de conformité. Rien dans son fonctionnement interne ne relève d'une technologie exotique : un modèle de langage classique, des appels à l'API Stripe, une couche de règles métier. Sa classification au regard de l'AI Act, en revanche, méritait un travail sérieux avant toute mise en production. ## Les quatre niveaux de risque du règlement L'AI Act distingue quatre catégories : risque inacceptable, interdit sans exception ; risque élevé, soumis à des obligations strictes de documentation, de supervision humaine et de gestion des risques ; risque limité, avec principalement une obligation de transparence envers l'utilisateur ; risque minimal, sans obligation spécifique. Un connecteur qui manipule des données de paiement et influence des décisions financières se situe d'emblée dans une zone qui mérite un examen attentif, sans présumer d'un niveau par confort. La tentation la plus courante, observée chez plusieurs clients de Fintarive avant même ce projet, consiste à classer un système par défaut en risque minimal parce qu'il « ne fait qu'assister » un humain. Cette lecture ignore que l'AI Act s'intéresse à la fonction du système dans son contexte d'usage, y compris quand une validation humaine existe en théorie mais reste rarement exercée dans la pratique. ## Checklist de classification 1. Documenter précisément les décisions que le connecteur influence : simple information, suggestion soumise à validation, ou action exécutée automatiquement. 2. Vérifier si le système entre dans une catégorie sectorielle explicitement listée comme à haut risque (évaluation de solvabilité, notamment), même par analogie fonctionnelle. 3. Évaluer la fréquence réelle de la supervision humaine sur les suggestions de remboursement, pas seulement son existence théorique dans le cahier des charges. 4. Identifier si des personnes physiques peuvent subir un préjudice financier direct en cas d'erreur du système, indépendamment de sa probabilité. 5. Consulter, en cas de doute persistant, un conseil juridique spécialisé plutôt que de trancher en interne sur une base technique seule. > L'essentiel à retenir : Le niveau de risque dépend de l'usage, pas de la complexité du modèle ; La documentation technique doit exister avant la mise en production ; La transparence envers l'utilisateur final est une obligation distincte du risque ## Les obligations de transparence, distinctes du niveau de risque Indépendamment de la catégorie de risque retenue, le règlement impose une obligation de transparence dès qu'un utilisateur final interagit avec un système d'IA sans le savoir : il doit être informé qu'il échange avec un système automatisé. Cette obligation s'applique même à un connecteur classé en risque limité, ce qui a conduit Fintarive à ajouter une mention explicite en début de conversation, plutôt que de la considérer comme optionnelle. La documentation technique attendue, elle, va au-delà d'un simple schéma d'architecture : elle doit décrire les données utilisées pour orienter les réponses du connecteur, les limites connues du système, et les mesures prises pour limiter les biais dans les suggestions de remboursement, par exemple un traitement homogène des demandes indépendamment du montant ou de l'ancienneté du client. ### Ce que la checklist a permis d'éviter - Une classification hâtive en risque minimal qui aurait exposé l'éditeur à une non-conformité découverte tardivement. - L'absence de documentation technique, souvent reléguée après la mise en production alors qu'elle doit exister dès le déploiement. - L'oubli de la mention de transparence, un point simple à corriger mais facilement négligé une fois l'attention concentrée sur les aspects techniques. > La classification au titre de l'AI Act n'est pas une case à cocher une fois pour toutes : elle doit être révisée à chaque évolution notable des capacités du connecteur, y compris quand cette évolution semble mineure du point de vue technique. ## Ce que cette checklist ne couvre pas L'analyse de classification ne dit rien de la qualité réelle des suggestions produites par le connecteur, ni de sa performance en conditions de forte charge. Ces aspects relèvent d'une évaluation technique séparée, menée sur un environnement de test dédié, et ne sauraient être confondus avec l'exercice de conformité réglementaire décrit ici. ## En résumé Classer correctement un connecteur IA au regard de l'AI Act demande de partir de son usage réel et de la fréquence effective de la supervision humaine, pas de la sophistication du modèle sous-jacent. Pour un connecteur qui touche à des données de paiement, mieux vaut documenter trop que pas assez : la charge de la preuve, en cas de contrôle, repose sur l'éditeur du système.