Pourquoi la régulation de l'IA fixe désormais les termes des contrats SaaS

Un responsable achats chez un assureur de taille moyenne ouvre un questionnaire de sécurité fournisseur début 2026 et y trouve une nouvelle section : « Votre produit intègre-t-il un modèle d'IA à usage général ? Si oui, nommez le fournisseur, sa classification de risque au titre de l'AI Act européen, et joignez votre dernière model card. » Il y a trois ans, cette question n'existait pas. Aujourd'hui, elle peut bloquer un deal à six chiffres pendant des semaines.

C'est la nouvelle réalité pour les éditeurs SaaS (Software as a Service) : la régulation de l'IA n'est plus un sujet de conformité traité après coup, elle apparaît ligne par ligne dans les Data Processing Agreements (DPA) et les questionnaires de risque fournisseur, et elle redéfinit qui porte la responsabilité quand un modèle embarqué se trompe.

Le contexte réglementaire, en bref

Deux régimes comptent surtout aujourd'hui.

L'AI Act européen (entré en vigueur en 2024, obligations échelonnées jusqu'en 2026-2027) est la première loi complète sur l'IA venant d'une grande juridiction. Il classe les systèmes d'IA par niveaux de risque :

• Risque inacceptable : interdits purement et simplement (par ex. le scoring social, certaines catégorisations biométriques).
• Risque élevé : soumis à des obligations strictes (évaluations de conformité, documentation technique, supervision humaine). Cela couvre des cas d'usage comme l'IA dans le recrutement, le credit scoring ou les dispositifs médicaux.
• Risque limité : obligations de transparence (par ex. indiquer qu'un contenu est généré par IA).
• Risque minimal : largement non régulé (la plupart des chatbots, les filtres anti-spam).

Point essentiel, l'AI Act crcrLe pourcentage de visiteurs ou de prospects qui réalisent une action attendue (achat, inscription, formulaire de contact), calculé en divisant les conversions par le nombre total d'opportunités.Voir la définition complète →ée aussi des règles pour les modèles d'IA à usage général (GPAI) (les modèles de fondation derrière des outils comme GPT-4, Claude ou Gemini), avec des obligations supplémentaires pour les modèles jugés porteurs d'un « risque systémique » sur la base de seuils de puissance de calcul. Source : résumé du texte officiel de l'AI Act, Commission européenne.

Aux États-Unis, il n'existe pas de loi fédérale unique sur l'IA en 2026. À la place, un patchwork de règles étatiques émerge : l'AI Act du Colorado (visant les systèmes de décision automatisée à risque élevé), les diverses règles californiennes sur la transparence de l'IA et la prise de décision automatisée, et des orientations sectorielles émanant d'organismes comme la FTC (Federal Trade Commission) sur les allégations trompeuses en matière d'IA. Cette fragmentation constitue en soi une charge de conformité : un éditeur SaaS vendant à l'échelle nationale peut devoir produire des informations différentes État par État.

Comment cela se traduit dans les contrats réels

Les acheteurs enterprise, surtout dans les secteurs régulés (banque, assurance, santé), imposent désormais des clauses spécifiques à l'IA dans les DPA et les Master Service Agreements. Ajouts fréquents en 2026 :

• Divulgation de la provenance du modèle : nommer le fournisseur du modèle sous-jacent (OpenAI, Anthropic, Google, Mistral, ou un modèle en open-weight que l'éditeur héberge lui-même).
• Attestation de niveau de risque : une déclaration écrite indiquant où se situe la fonctionnalité d'IA embarquée dans les niveaux de l'AI Act européen, même pour des clients uniquement américains, car beaucoup d'acheteurs enterprise opèrent à l'international.
• Droit d'audit ou de demander les model cards : documentation décrivant la provenance des données d'entraînement, les limites connues et les résultats d'évaluation.
• Restrictions sur les flux de données : interdire que les données client servent à entraîner le modèle de fondation sous-jacent, ou exiger la confirmation d'un opt-out.
• Répartition de la responsabilité : qui est responsable si la fonctionnalité d'IA produit une recommandation de recrutement discriminatoire ou une réponse de conformité hallucinée, l'éditeur SaaS ou le fournisseur du modèle en amont ?

C'est sur ce dernier point que la plupart des éditeurs se font surprendre.

Ce qu'un éditeur hérite en intégrant un modèle tiers

Si votre produit SaaS appelle une APIAPIApplication Programming Interface : une interface standardisée qui permet aux applications de communiquer et d'échanger des données sans connaître leur fonctionnement interne respectif.Voir la définition complète → d'OpenAI ou d'Anthropic pour alimenter une fonctionnalité de « résumé intelligent », vous n'êtes pas fondé à dire « c'est leur modèle, pas notre problème ». Selon l'AI Act européen comme selon la plupart des normes contractuelles enterprise, le déployeur (l'entreprise qui place le système d'IA dans un contexte d'usage donné) porte de véritables obligations, même s'il n'a pas construit le modèle sous-jacent.

Concrètement, une entreprise SaaS qui intègre un large language modellarge language modelUn Large Language Model est un système d'IA entraîné sur d'énormes volumes de texte pour prédire et générer du langage, ce qui permet de rédiger, résumer ou répondre à des questions.Voir la définition complète → (LLM) tiers hérite généralement :

1. De la responsabilité de classification : vous devez évaluer si *votre cas d'usage spécifique* (et non le modèle de base dans l'abstrait) relève d'une catégorie à risque élevé. Un chatbot généraliste est à faible risque ; le même modèle branché sur une fonctionnalité de tri de CV est à risque élevé au titre de l'AI Act européen.
2. Des obligations de transparence : indiquer aux utilisateurs finaux qu'ils interagissent avec des sorties générées par IA.
3. Des exigences de supervision humaine : pour les usages à risque élevé, garantir qu'un humain peut revoir et outrepasser les sorties de l'IA avant que des décisions à conséquence soient prises.
4. De la gouvernance des données : confirmer quelles données client transitent vers le fournisseur du modèle, si elles sont conservées, et si elles pourraient servir à un entraînement ultérieur.
5. De la journalisation des incidents et des erreurs : une pratique de plus en plus attendue, consistant à conserver la trace des défaillances du modèle ou des interventions humaines, utile à la fois pour les audits et pour l'analyse post-incident.

Le fournisseur en amont (OpenAI, Anthropic, etc.) ne conserve généralement d'obligations que pour le modèle de base lui-même (ses propres évaluations de conformité en tant que fournisseur de GPAI). Les obligations de déployeur sont les vôtres.

Une façon simple de voir l'exposition

Un modèle mental utile, adaptable en checklist interne rapide :

Feature: "AI resume screener" in an HR SaaS product

1. Underlying model: third-party LLM via API
2. Use case risk tier (EU AI Act): HIGH (employment decision)
3. Obligations triggered:
   - Conformity documentation: REQUIRED
   - Human review before rejection: REQUIRED
   - Bias/accuracy testing on outputs: REQUIRED
   - Transparency notice to candidates: REQUIRED
4. Contract clause needed: liability split with model
   provider for output errors vs. deployment errors

Ce n'est pas du code exécutable, c'est le type de triage de risque structuré qu'une équipe produit et juridique devrait mener ensemble avant de livrer toute fonctionnalité d'IA, et de plus en plus, avant de signer le DPA que l'équipe achats d'un client renvoie annoté.

Pourquoi cela concerne même le SaaS « ennuyeux »

On peut être tenté de penser que cela ne vaut que pour des domaines manifestement sensibles comme le recrutement ou le crédit. Mais les obligations de l'AI Act européen et les règles des États américains touchent de plus en plus des fonctions SaaS ordinaires : le support client assisté par IA qui pourrait donner des conseils médicaux ou financiers erronés, les outils de planification par IA qui affectent indirectement l'accès à des services, ou la modération de contenu par IA qui façonne ce que voient les utilisateurs. L'exercice de classification doit être mené cas d'usage par cas d'usage, pas produit par produit.

À quoi ressemble une bonne gouvernance en pratique

Les éditeurs qui traversent sans heurts les deals enterprise en 2026 font en général trois choses tôt :

• Tenir un inventaire IA vivant : chaque fonctionnalité utilisant de l'IA, quel modèle l'alimente, quelles données elle touche, et sa classification de risque. C'est ce qu'on joint aux questionnaires de sécurité au lieu de tout reconstituer à chaque fois.
• Prénégocier les conditions du fournisseur de modèle : savoir d'avance à quoi s'engagent OpenAI, Anthropic ou d'autres fournisseurs en matière de conservation des données et d'usage pour l'entraînement, puisque votre contrat client ne peut pas promettre plus que ce que permet votre contrat en amont.
• Construire un parcours human-in-the-loop pour tout ce qui touche à l'emploi, au crédit, à la santé ou aux décisions de sécurité, même si la fonctionnalité actuelle paraît à faible enjeu, car une reclassification se défend plus facilement que l'ajout rétroactif d'une supervision après un incident.

Pour un panorama pratique de la façon dont ces niveaux de risque se traduisent en obligations, le NIST AI Risk Management Framework (États-Unis, volontaire mais largement cité) complète solidement les règles contraignantes de l'UE, utile pour les éditeurs qui cherchent à bâtir un seul processus de gouvernance interne satisfaisant les deux logiques réglementaires.

À retenir

• La régulation de l'IA est passée du débat de politique publique au langage contractuel : les DPA et les questionnaires de sécurité interrogent désormais couramment la provenance du modèle embarqué, sa classification de risque et les flux de données.
• Les quatre niveaux de risque de l'AI Act européen (inacceptable, élevé, limité, minimal) s'appliquent à des cas d'usage précis, pas seulement aux modèles dans l'abstrait ; le même LLM peut être à faible risque dans une fonctionnalité et à risque élevé dans une autre.
• La régulation américaine reste fragmentée entre États (Colorado, Californie et d'autres), alors que l'UE dispose d'un cadre contraignant unique, ce qui crée une complexité supplémentaire pour les éditeurs vendant sur les deux marchés.
• Déployer un modèle tiers ne transfère pas la responsabilité : les éditeurs SaaS héritent des obligations de classification, de transparence, de supervision humaine et de gouvernance des données, même sans avoir construit le modèle sous-jacent.
• Les éditeurs qui tiennent un inventaire de leurs fonctionnalités d'IA et prénégocient les conditions des modèles en amont avancent plus vite dans les achats enterprise en 2026 que ceux qui traitent chaque questionnaire au cas par cas.