L’AI Act introduit une approche graduée des systèmes d'IA, fondée sur le niveau de risque du système d’intelligence artificielle.

Mais une chose est claire : tout fournisseur de système d’IA est désormais concerné et doit intégrer des éléments à ses contrats, y compris lorsque le système n’est pas qualifié de « haut risque ».

Le contrat SaaS classique, même complété par un DPA, ne suffit plus. Il doit être enrichi par des clauses ou une annexe IA dédiée, afin de refléter les nouvelles obligations issues de l’AI Act et de sécuriser la relation avec les clients.

Pourquoi prévoir une annexe IA ?

Même pour :

  • des systèmes d’IA « à risque limité »,
  • des outils d’aide à la décision,
  • des moteurs de recommandation,
  • ou des fonctionnalités IA intégrées dans un SaaS,

le fournisseur doit désormais :

  • décrire le fonctionnement du système,
  • encadrer les usages autorisés,
  • préciser la répartition des responsabilités,
  • organiser la transparence et la conformité.

Une annexe IA permet de centraliser ces obligations, sans alourdir inutilement le contrat principal.

Clarifier les rôles : fournisseur, déployeur, utilisateur

Le premier enjeu contractuel posé par l’AI Act est la qualification des rôles.

Le contrat doit clairement identifier :

  • le fournisseur du système d’IA,
  • le déployeur (le client qui l’utilise),
  • et, le cas échéant, les fournisseurs de modèles ou sous-traitants IA.

Cette clarification est indispensable, quel que soit le niveau de risque du système. Elle permet d’éviter que le fournisseur ne supporte des obligations qui relèvent en réalité de l’usage fait par le client.

Définir l’objet et la destination du système d’IA

Un système d’IA ne doit jamais être décrit de manière générique.

Le contrat ou l’annexe IA doit préciser :

  • la finalité du système,
  • les usages prévus,
  • les usages exclus,
  • le rôle du système dans la prise de décision.

Cette précision est essentielle pour :

  • limiter la responsabilité du fournisseur,
  • empêcher des détournements d’usage,
  • cadrer les attentes du client.

Plus le système se rapproche d’un usage sensible, plus cette description doit être précise.

Gouvernance et gestion des risques : une obligation graduée

L’AI Act impose un niveau de gouvernance proportionné.

Tous les fournisseurs doivent démontrer :

  • qu’ils ont identifié les risques liés à leur système,
  • qu’ils ont mis en place des mesures de contrôle adaptées,
  • qu’ils surveillent les performances du système dans le temps.

Pour un système à haut risque, ces obligations sont formalisées et documentées. Pour les autres systèmes, la logique reste la même, mais avec un niveau d’exigence proportionné.

Contractuellement, il est pertinent de prévoir :

  • l’existence d’un cadre de gestion des risques,
  • l’accès à des informations de conformité,
  • une mise à jour régulière en cas d’évolution du système.

Données, biais et qualité : un point central pour tous les systèmes

La question des données est critique.

Le contrat doit encadrer :

  • la nature des données utilisées,
  • les garanties mises en place pour éviter les biais manifestes,
  • la responsabilité du client dans la configuration du système.

Un point ressort de manière transversale : le fournisseur ne doit pas être responsable des choix opérés par le client, notamment lorsque celui-ci paramètre des critères ayant un impact juridique ou éthique.

Documentation et transparence : trouver le bon niveau

L’AI Act impose une obligation de transparence graduée.

Pour tous les systèmes d’IA, le fournisseur doit être capable de fournir :

  • une documentation compréhensible,
  • des instructions d’utilisation,
  • des informations sur les limites du système.

Cette documentation n’est pas obligatoirement intégrée directement au contrat. Elle peut être mise à disposition via un trust center, sur demande, sous réserve de confidentialité.

Cette approche protège à la fois :

  • la propriété intellectuelle du fournisseur,
  • la confiance du client.

Supervision humaine et contrôle de l’usage

La supervision humaine n’est pas réservée aux systèmes à haut risque.

Dès lors qu’un système d’IA influence une décision, le contrat doit préciser :

  • si une validation humaine est requise,
  • qui en est responsable,
  • à quel moment elle intervient.

Plus le système est critique, plus cette exigence devient structurante. Mais même pour des systèmes plus simples, l’absence totale de supervision peut poser problème.

Sécurité, robustesse et incidents

Tous les fournisseurs d’IA doivent prévoir contractuellement :

  • un niveau minimal de sécurité,
  • des mécanismes de détection des incidents,
  • une procédure d’information du client.

Le contrat doit éviter toute ambiguïté sur :

  • ce qui constitue un incident,
  • les délais de notification,
  • les rôles respectifs des parties.

Encadrer strictement l’usage des données et l’entraînement

Un point est devenu central dans toutes les négociations IA : l’entraînement des modèles.

Il est fortement recommandé de préciser que :

  • les données du client ne sont pas utilisées pour entraîner des modèles mutualisés,
  • les outputs restent la propriété du client,
  • seules des données agrégées et anonymisées peuvent être exploitées par le fournisseur.

Cette clause est aujourd’hui déterminante pour la confiance commerciale.

Sous-traitance et chaîne IA

L’AI Act impose une vision élargie de la chaîne de valeur IA.

Le contrat doit identifier :

  • les fournisseurs de modèles,
  • les sous-traitants techniques,
  • les mécanismes de notification en cas de changement.

Même pour des systèmes simples, cette transparence est devenue une attente forte des clients.

Conclusion

L’AI Act ne concerne pas uniquement les systèmes d’IA à haut risque. Il impose à tous les fournisseurs de systèmes d’IA de repenser leur contractualisation.

Le bon réflexe consiste à :

  • compléter le contrat SaaS,
  • structurer une annexe IA proportionnée,
  • clarifier les rôles et responsabilités,
  • anticiper les usages et les risques.

Nos autres ressources


Blog image
Pourquoi se faire accompagner par un avocat pour déployer un CLM en startup ?

Pourquoi et comment un avocat peut structurer le déploiement d’un CLM en startup, sécuriser les contrats, les templates et les playbooks sans équipe juridique interne.

Blog image
Contrat de développement logiciel : les clauses indispensables à intégrer au contrat

Checklist des clauses essentielles d’un contrat de développement logiciel : livrables, recette, propriété intellectuelle, paiements, responsabilité et sécurité juridique.

Avançons ensemble pour accélérer votre activité