AI Act, article 50 : guide pratique pour les développeurs d’API IA

Votre application utilise une API pour répondre à des clients, rédiger des textes ou générer des images. Qui doit informer les utilisateurs ? Qui doit assurer le marquage des contenus ? Et une entreprise suisse est-elle concernée ?

Depuis le 2 août 2026, les obligations de transparence de l’article 50 de l’AI Act sont applicables. Une transition subsiste jusqu’au 2 décembre 2026 pour le marquage prévu à l’article 50(2), uniquement pour les systèmes mis sur le marché avant le 2 août 2026.

Utiliser un modèle tiers ne suffit pas à déterminer vos obligations. Votre rôle, votre application et son usage comptent aussi.

Le calendrier à retenir

L’AI Act, règlement (UE) 2024/1689, est entré en vigueur le 1er août 2024. Son application est progressive.

Les deux dernières échéances reflètent le règlement (UE) 2026/1744, le Digital Omnibus sur l’IA. Le report d’une partie du régime à haut risque ne reporte pas l’ensemble des obligations de transparence.

Sources : article 113, article 111 et règlement modificatif.

Développeur, fournisseur ou déployeur ?

Le fournisseur du modèle développe et commercialise le modèle sous-jacent. Le fournisseur du système développe, ou fait développer, une application IA et la commercialise ou la met en service sous son nom. Le déployeur utilise un système sous son autorité, hors activité personnelle non professionnelle.

Votre entreprise achète un assistant existant pour ses employés ? Elle agit généralement comme déployeur. Elle commercialise son propre assistant de support basé sur une API tierce ? Elle peut être fournisseur du système, même sans avoir entraîné le modèle.

Une même organisation peut cumuler plusieurs rôles. La conformité du fournisseur de modèle ne démontre pas automatiquement celle de votre application.

Source : définitions de l’article 3.

Ce que l’article 50 demande concrètement

Informer lors d’une interaction avec l’IA

Pour un système destiné à interagir directement avec des personnes, le fournisseur doit faire en sorte qu’elles sachent qu’elles échangent avec une IA, sauf si cela est évident dans le contexte. L’information doit être claire, accessible et fournie au plus tard lors de la première interaction. Une mention enfouie dans les conditions générales est une mauvaise solution pratique.

Marquer les contenus synthétiques

Les fournisseurs de systèmes générant du texte, des images, de l’audio ou de la vidéo doivent assurer un marquage lisible par machine et une détection du caractère artificiel, dans les conditions de l’article 50(2). Une étiquette visible dans l’interface et un marquage technique remplissent des fonctions différentes.

Les exceptions comprennent certaines fonctions d’édition standard. Les lignes directrices précisent aussi que le code source et certains résultats exclusivement traités entre machines, sans exposition humaine, sont hors du champ de cette obligation. Un appel entre votre serveur et une API n’exclut pas à lui seul un contenu ensuite présenté à un utilisateur.

Signaler certains usages et publications

Des obligations spécifiques concernent les déployeurs de systèmes de reconnaissance des émotions ou de catégorisation biométrique, les deepfakes et les textes publiés pour informer le public sur des sujets d’intérêt public.

Pour ces textes, une exception existe lorsqu’une révision humaine ou un contrôle éditorial porte sur le fond et qu’une personne physique ou morale assume la responsabilité éditoriale. Corriger l’orthographe ne suffit pas. Cette exception ne supprime pas les autres obligations applicables au système.

Sources : article 50 et FAQ de la Commission.

Trois situations à vérifier dans votre application

Ces cas reprennent les distinctions de la FAQ de la Commission. Ils servent à organiser vos vérifications ; ils ne constituent pas une certification de conformité.

Une entreprise suisse peut-elle être concernée ?

Oui. L’article 2 couvre notamment certains fournisseurs établis hors de l’Union qui mettent un système ou un modèle sur le marché européen. Il couvre également des fournisseurs et déployeurs de pays tiers lorsque les résultats de leur système sont utilisés dans l’Union.

Un produit IA suisse proposé à des clients européens doit donc faire l’objet d’une analyse de champ d’application. L’hébergement en Suisse ne crée pas une exemption automatique. Une activité exclusivement suisse peut être hors du champ territorial européen, tout en restant soumise au droit suisse applicable.

Le PFPDT rappelle que la loi fédérale sur la protection des données s’applique déjà aux traitements de données personnelles fondés sur l’IA lorsque ses conditions sont réunies.

Sources : article 2 et position du PFPDT.

Exemple : un assistant de support pour des clients européens

Imaginons une société suisse qui commercialise son propre assistant de support auprès d’entreprises européennes. L’assistant utilise une API de modèle et répond directement aux clients de ces entreprises.

Voici une démarche pratique à adapter au produit :

1. Qualifier les rôles. La société peut être fournisseur du système ; l’entreprise cliente peut être déployeur. Documenter qui prend en charge chaque obligation.
2. Afficher la mention au bon moment. Avant le premier échange, présenter par exemple : « Vous échangez avec un assistant IA. Ses réponses peuvent contenir des erreurs. » Adapter la langue et l’accessibilité à l’utilisateur.
3. Vérifier le marquage des réponses. Demander au fournisseur comment il fonctionne et vérifier si le streaming, la conversion de format ou l’export le préservent. Ajouter un champ ai_generated: true n’établit pas, à lui seul, que la solution répond aux exigences.
4. Documenter les dépendances. Consigner le modèle demandé, la route publique, les conditions de traitement pertinentes et la version de la notice utilisateur. Prévoir une nouvelle vérification lors d’un changement de fournisseur.
5. Conserver les preuves utiles. Garder une capture de la mention et les résultats des vérifications. Définir séparément les besoins de logs applicatifs, leurs accès et leur durée de conservation.

Cette démarche est un exemple d’organisation technique. La qualification juridique dépend du produit et de son usage.

Faut-il un audit indépendant ?

L’article 50 n’impose pas un audit indépendant général à toute entreprise utilisant une API IA. Les exigences de documentation, de journalisation et d’évaluation de conformité des systèmes à haut risque relèvent d’autres dispositions ; les procédures dépendent du système concerné.

Vous pouvez néanmoins devoir répondre aux questions d’un client ou d’une équipe de sécurité : quel modèle traite les demandes, quelles organisations reçoivent les données et quelles informations sont conservées ? Préparer ces réponses facilite les revues fournisseurs.

Sources : article 12, article 26 et article 43.

Ce que RouterLab apporte à cette démarche

RouterLab centralise l’accès aux routes de modèles publiées, les permissions, le suivi d’usage et les crédits. Le dashboard présente la route logique publique et la consommation ; il n’expose pas le routage interne détaillé.

Les modèles open source proposés par RouterLab sont hébergés sur son infrastructure en Suisse et en Allemagne. Les routes propriétaires passent par des fournisseurs externes, selon le modèle et la route sélectionnés. Leurs conditions de traitement et de rétention s’appliquent.

RouterLab ne journalise ni n’archive durablement le contenu des prompts et des réponses. Le cache technique des réponses est configuré avec une durée de vie de 10 minutes. Il peut donc conserver temporairement le contenu d’un échange ; il ne s’agit pas d’une promesse de rétention nulle. Cette durée concerne le cache RouterLab, pas les politiques de rétention des fournisseurs externes. Des événements et métadonnées opérationnelles sont conservés pour l’usage, les crédits et le support.

Cette visibilité aide à décrire vos dépendances. Elle ne remplace pas les mentions dans votre application, la provenance des contenus, vos preuves de conformité ou les logs propres à votre cas d’usage. Les engagements juridiques restent définis dans les documents contractuels applicables.

Consultez notre infrastructure et nos limites et le fonctionnement de RouterLab.

Votre checklist de départ

• Identifier votre rôle pour chaque application.
• Vérifier le champ territorial, notamment pour les clients européens.
• Tester les mentions lors des interactions humaines.
• Examiner le marquage et les transformations des contenus.
• Documenter les fournisseurs et les conditions de traitement.
• Définir les preuves utiles et une conservation proportionnée.

Pour commencer côté infrastructure, consultez la documentation API et le catalogue des modèles. Votre application doit rester compréhensible lorsque vous changez de modèle, de fournisseur ou de parcours utilisateur.

Tester votre premier parcours API

Démarrez un essai RouterLab, choisissez un modèle disponible dans l’essai et suivez le guide API pour effectuer un premier appel avec des données synthétiques. Consultez ensuite la consommation dans le dashboard et vérifiez la mention IA dans votre propre interface. Cet essai permet de vérifier l’intégration et le suivi d’usage ; il ne valide pas la conformité juridique de votre application.

---

Informations réglementaires vérifiées au 10 octobre 2026. Cet article fournit des informations générales techniques et réglementaires, sans constituer un conseil juridique. Les obligations dépendent du système, de sa finalité, du rôle de l’organisation et de la juridiction applicable.