Dès que vous livrez une fonctionnalité d'IA, un assistant, une fonction de résumé, un score, une recommandation ou un composant génératif, la question n'est plus de savoir si l'AI Act européen vous concerne, mais dans quel rôle et à quelle profondeur. Le Règlement (UE) 2024/1689 s'étend également aux fournisseurs suisses et britanniques, via l'art. 2, par. 1, lit. c, dès lors que l'output est utilisé dans l'UE. Un seul client professionnel en Allemagne ou en France suffit à entrer dans le champ d'application.

Pour la plupart des fournisseurs SaaS B2B, le message est rassurant : vos fonctionnalités d'IA ne sont pas à haut risque. Elles déclenchent surtout des obligations de transparence au titre de l'art. 50. Pour un petit nombre de cas d'usage, la voie du haut risque selon l'Annexe III s'applique. Qui fournit son propre modèle rencontre en outre des obligations GPAI. La seule mauvaise réaction est de ne pas classifier du tout. Cet article expose ce que l'AI Act signifie concrètement pour le SaaS avec fonctionnalités d'IA, comment se répartissent les rôles, comment tout s'articule avec votre contrat de sous-traitance et le vendor security review, et comment démarrer de manière pragmatique dès aujourd'hui.

Pour la grande majorité des fonctionnalités d'IA dans le SaaS B2B, l'art. 50 est la norme centrale. Quatre situations sont pertinentes. Premièrement : qui exploite un système d'IA interagissant directement avec des personnes physiques, comme un chatbot ou un assistant de support, doit informer la personne concernée qu'elle interagit avec une IA, sauf si cela est manifeste. Deuxièmement : qui génère des contenus audio, image, vidéo ou texte synthétiques doit les marquer comme générés artificiellement de manière lisible par machine. Troisièmement : les deepfakes doivent être divulgués séparément. Quatrièmement : les textes générés par IA portant sur des questions d'intérêt public doivent être étiquetés comme tels.

En pratique, pour les fournisseurs SaaS, cela signifie un avis dans l'interface indiquant qu'une fonction est assistée par IA, un marquage des contenus générés et une documentation propre de ces mesures. C'est tout à fait maîtrisable et cela devrait faire partie de vos processus produit et de release. Important : l'art. 50 vise tant les fournisseurs que les déployeurs, selon la fonction. Si vous fournissez le système d'IA, vous êtes responsable en tant que fournisseur du marquage technique ; votre client professionnel, en tant que déployeur, est responsable de l'information de ses utilisateurs finaux. Les deux obligations s'imbriquent, et toutes deux devraient être clairement traitées dans le contrat.

Le haut risque est l'exception, non la règle, mais il touche directement certaines fonctionnalités SaaS B2B. L'Annexe III liste huit clusters. Pour les fournisseurs SaaS, trois sont les plus pertinents en pratique. Le cluster 4 (emploi et gestion du personnel) couvre la technologie RH : IA pour le tri de CV, le classement de candidats, le ciblage de candidatures, l'évaluation des performances ou l'observation du comportement. Le cluster 5 (accès aux services essentiels) couvre la fintech et l'insurtech : notation de crédit (hors pure détection de fraude) ainsi qu'évaluation des risques et tarification en assurance vie et santé. Le cluster 1 (biométrie) touche les fournisseurs de fonctions d'identité et d'accès.

Si votre fonctionnalité d'IA relève de l'un de ces domaines, le catalogue d'obligations est étendu : système de gestion des risques (art. 9), gouvernance des données (art. 10), documentation technique (art. 11), journalisation (art. 12), transparence envers les déployeurs (art. 13), supervision humaine (art. 14), robustesse (art. 15), management de la qualité (art. 17) et évaluation de la conformité (art. 43). Il existe un mécanisme d'exemption selon l'art. 6, par. 3 pour les systèmes sans risque significatif, par exemple des tâches préparatoires étroitement définies. Cette exemption n'est pas automatique : elle exige une justification documentée et un enregistrement, et un système qui effectue un profilage de personnes physiques en est exclu. Ici, la classification initiale décide entre une voie légère et un programme de conformité à six chiffres.

Une couche d'obligations distincte s'applique aux fournisseurs de modèles d'IA à usage général (GPAI). La plupart des fournisseurs SaaS ne sont pas concernés ici : utiliser un modèle de fondation existant via une API et construire une fonctionnalité par-dessus ne fait pas de vous le fournisseur de ce modèle, vous n'êtes donc pas fournisseur GPAI. En revanche, si vous entraînez votre propre modèle, ré-entraînez substantiellement un modèle existant (fine-tuning d'une ampleur qui équivaut à fournir votre propre modèle) ou mettez un modèle à disposition sous votre propre nom, des obligations GPAI peuvent être déclenchées.

Les obligations centrales pour les fournisseurs GPAI comprennent la documentation technique du modèle, des informations pour les fournisseurs en aval qui intègrent le modèle, une politique de respect du droit d'auteur de l'UE et un résumé suffisamment détaillé des données d'entraînement. Pour les modèles particulièrement performants présentant un risque systémique, des obligations renforcées s'appliquent. La distinction entre la simple utilisation d'une API et la fourniture de votre propre modèle doit être appréciée au cas par cas. Elle est déterminante pour votre rôle et l'étendue de vos obligations, et elle doit figurer au début de toute classification.

La répartition des rôles est l'aiguillage le plus important, et pour le SaaS elle est souvent contre-intuitive. Le fournisseur est celui qui développe un système d'IA et le met sur le marché sous son propre nom. En tant que fournisseur SaaS intégrant une fonctionnalité d'IA dans son produit et la livrant à des clients professionnels, vous êtes en règle générale le fournisseur de ce système d'IA, même si vous utilisez en arrière-plan un modèle de fondation tiers. Votre client professionnel, qui utilise la fonctionnalité dans son exploitation, est le déployeur.

Ce partage a des conséquences concrètes. En tant que fournisseur, pour les fonctionnalités à haut risque, vous portez la pleine charge de conformité selon l'art. 16, de la documentation technique à l'évaluation de la conformité. Votre client, en tant que déployeur, porte des obligations de diligence, de supervision et d'information selon l'art. 26 et, dans certaines situations comme les banques ou les organismes publics, une évaluation d'impact sur les droits fondamentaux selon l'art. 27. Attention à la configurabilité : si un client modifie substantiellement votre système ou le redistribue sous sa propre marque, il peut lui-même devenir fournisseur selon l'art. 25. Clarifiez ces rôles par fonctionnalité, non globalement par produit, et fixez-les dans le contrat.

La conformité IA ne tient jamais seule. Si votre fonctionnalité d'IA traite des données personnelles, la loi suisse sur la protection des données (nLPD) et, en cas de rattachement à l'UE, le RGPD s'appliquent en parallèle. Votre contrat de sous-traitance (selon l'art. 9 nLPD, l'art. 28 RGPD) doit refléter précisément le traitement par IA : quelles données circulent dans quelle fonctionnalité, si elles sont utilisées pour l'amélioration du modèle (dans un contexte B2B, à exclure régulièrement ou à strictement encadrer), quels sous-traitants ultérieurs sont impliqués, par exemple le fournisseur du modèle, et où le traitement a lieu.

Deux points méritent une attention particulière. Premièrement, la liste des sous-traitants ultérieurs : si votre fonctionnalité d'IA appelle un fournisseur de modèle externe, celui-ci est un sous-traitant ultérieur et doit figurer de manière transparente dans votre liste, y compris la résidence des données et tout transfert vers des pays tiers. Deuxièmement, les décisions individuelles automatisées : si votre fonctionnalité prend des décisions ayant un effet significatif sur des personnes, l'art. 21 nLPD et l'art. 22 RGPD s'appliquent, avec des obligations d'information, d'intervention et d'explication. Une analyse d'impact relative à la protection des données peut être requise. La classification AI Act, le DPA et l'AIPD appartiennent au même dossier, sinon vos réponses aux clients et aux autorités de surveillance se contrediront.

La pression pratique vient rarement d'abord de l'autorité de surveillance, elle vient du client professionnel. Les achats d'entreprise et la gestion des risques tiers interrogent aujourd'hui systématiquement sur vos fonctionnalités d'IA. Les questions typiques du questionnaire de sécurité sont : quelles fonctions d'IA traitent nos données ? Nos données sont-elles utilisées pour l'entraînement ou l'amélioration du modèle ? Quel fournisseur de modèle se trouve derrière, et où les données sont-elles traitées ? Comment votre gouvernance de l'IA est-elle organisée ? Existe-t-il une classification AI Act de vos fonctionnalités ? Comment assurez-vous la supervision humaine et la transparence ?

Répondre à ces questions rapidement, précisément et de manière cohérente maintient le deal en mouvement. Hésiter ou répondre de façon contradictoire risque des semaines de retard dans le procurement ou la perte du mandat. C'est précisément là que le travail préparatoire paie : un inventaire d'IA, une classification documentée, des clauses DPA claires sur l'utilisation de l'IA, une liste de sous-traitants ultérieurs à jour et une entrée de trust center sur votre gouvernance de l'IA. La sécurité et la conformité deviennent ainsi un argument de vente plutôt qu'un coût : vous raccourcissez le review et gagnez la confiance.

Les échéances de l'AI Act sont en mouvement. Les obligations de transparence de l'art. 50 sont posées, les échéances haut risque se situent à partir de 2026/2027 et sont en révision dans le cadre du Digital Omnibus, la date est donc à vérifier au cas par cas. Cette incertitude n'est pas une raison d'attendre, c'est une raison de poser les fondations dès maintenant. Commencez par ce qui tient indépendamment des échéances : un inventaire complet de vos fonctionnalités d'IA et de leurs flux de données, une classification initiale documentée (transparence, haut risque, GPAI) et une attribution claire des rôles fournisseur vs déployeur par fonctionnalité.

SIDD intervient ici avec deux prestations. L'AI Governance Check (dès CHF 3'900) vous fournit un inventaire d'IA documenté, la classification initiale de vos fonctionnalités et une liste de mesures priorisées, résistante à la surveillance du marché et au review client. L'AI Officer (dès CHF 500/mois) maintient votre gouvernance de l'IA à jour en continu, gère l'inventaire et la classification et répond de manière fiable aux questions IA du security review. Nous articulons le volet protection des données via le conseil en protection des données (nLPD) et, en cas de rattachement à l'UE, le DPO RGPD et le représentant UE. Une première appréciation de vos fonctionnalités d'IA peut être discutée via le formulaire de contact ; un programme complet peut être demandé via notre formulaire d'offre.