SaaS et IA : clauses contractuelles essentielles pour les acheteurs

L’acquisition de solutions d’intelligence artificielle en mode SaaS (Software as a Service) est devenue le mode predominant d’acces a l’IA pour les entreprises. Chatbots, outils d’analyse predictive, systemes de recommandation, solutions de traitement automatise du langage naturel : la majorite des systemes d’IA deployes en entreprise sont fournis par des editeurs tiers sous forme d’abonnement. Cette externalisation presente des avantages operationnels evidents mais cree des risques juridiques specifiques que seul un cadre contractuel rigoureux peut maitriser.

Le AI Act et le RGPD imposent des obligations tant au fournisseur qu’au deployeur (l’acheteur). L’acheteur d’une solution SaaS d’IA ne peut pas se decharger de ses responsabilites en invoquant le recours a un prestataire : il reste responsable de l’utilisation du systeme et des decisions prises sur la base de ses resultats. Le contrat d’acquisition constitue donc l’instrument juridique essentiel pour repartir les responsabilites, garantir la conformite et proteger les interets de l’acheteur.

Le cadre juridique applicable

Les obligations de l’acheteur-deployeur au titre du AI Act

L’acheteur d’une solution SaaS d’IA est un “deployeur” au sens du AI Act. Pour les systemes a haut risque, le deployeur a des obligations propres qui ne peuvent etre satisfaites que si le contrat les prend adequatement en compte.

Le deployeur doit utiliser le systeme conformement aux instructions d’utilisation (article 26), s’assurer que les personnes chargees du controle humain disposent des competences et de l’autorite necessaires, s’assurer que les donnees d’entree sont pertinentes et representatives, surveiller le fonctionnement du systeme et signaler les incidents au fournisseur, realiser une analyse d’impact sur les droits fondamentaux (pour les deployeurs publics et les entites fournissant des services publics), enregistrer son utilisation du systeme dans la base de donnees de l’UE (pour les deployeurs publics) et conserver les journaux de bord automatiquement generes par le systeme.

Les obligations au titre du RGPD

L’acheteur qui utilise une solution SaaS d’IA pour traiter des donnees personnelles est generalement responsable de traitement au sens du RGPD. Le fournisseur SaaS est sous-traitant lorsqu’il traite des donnees personnelles pour le compte de l’acheteur. L’article 28 du RGPD impose alors un cadre contractuel detaille, dont le contenu est analyse dans notre guide sur la sous-traitance IA.

L’acheteur doit s’assurer que le fournisseur presente des garanties suffisantes, que le contrat contient les clauses obligatoires de l’article 28, que les droits des personnes concernees sont effectivement exercables et qu’une AIPD est realisee lorsque le traitement presente un risque eleve.

Les clauses contractuelles essentielles

1. Clause de definition et de qualification du systeme d’IA

Le contrat doit qualifier precisement le systeme d’IA fourni : sa nature (apprentissage automatique, systeme expert, modele de langage, etc.), sa finalite prevue, son niveau de risque au sens du AI Act, les performances declarees et les limites connues du systeme.

Cette qualification est determinante car elle conditionne le regime d’obligations applicable. Si le systeme est qualifie de systeme a haut risque, l’ensemble des obligations des articles 8 a 15 du AI Act s’appliquent. La qualification doit etre claire et non ambigue pour eviter les contentieux posterieurs.

Le contrat doit egalement preciser les cas d’utilisation autorises et interdits. Le AI Act prevoit que le deployeur qui utilise un systeme d’IA en dehors des cas d’utilisation prevus par les instructions peut devenir fournisseur et assumer les obligations correspondantes. La clause de definition des cas d’utilisation protege l’acheteur contre ce risque de requalification.

2. Clause de transparence et de documentation

L’acheteur doit obtenir du fournisseur l’acces a la documentation technique du systeme, aux instructions d’utilisation, aux metriques de performance declarees et aux limites connues. Cette clause est indispensable pour permettre au deployeur de satisfaire ses propres obligations de transparence vis-a-vis des personnes affectees par le systeme.

La clause doit prevoir la fourniture initiale de la documentation technique (ou d’un resume suffisamment detaille), la communication des mises a jour de la documentation lors de chaque evolution du systeme, l’acces aux metriques de performance en temps reel ou a intervalles reguliers et la notification des limites et des biais connus du systeme.

Pour les systemes relevant du RGPD, la clause de transparence doit egalement couvrir les informations necessaires pour satisfaire les obligations d’information des personnes concernees (articles 13 et 14 du RGPD) et les demandes d’explication des decisions algorithmiques.

3. Clause relative aux donnees

La clause relative aux donnees est l’une des plus critiques du contrat SaaS d’IA. Elle doit couvrir plusieurs dimensions.

Les donnees d’entree : le contrat doit preciser les categories de donnees que l’acheteur peut soumettre au systeme, les conditions de traitement de ces donnees par le fournisseur, les mesures de securite applicables et les conditions de suppression a l’issue du traitement.

L’utilisation des donnees pour l’entrainement : c’est un point de negociation crucial. De nombreux fournisseurs SaaS d’IA utilisent les donnees de leurs clients pour ameliorer leurs modeles. Le contrat doit clairement preciser si le fournisseur est autorise a utiliser les donnees de l’acheteur pour l’entrainement ou l’amelioration de son modele. Si cette utilisation est autorisee, les conditions doivent etre detaillees : anonymisation prealable, donnees synthetiques, agregation, garanties de non-re-identification.

La propriete et la portabilite : le contrat doit garantir que l’acheteur conserve la propriete de ses donnees, qu’il peut les recuperer dans un format exploitable en cas de changement de fournisseur et que les donnees sont effectivement supprimees par le fournisseur a l’issue du contrat.

4. Clause d’audit et de controle

Le droit d’audit est un element essentiel du contrat SaaS d’IA. L’article 28(3)(h) du RGPD impose que le contrat de sous-traitance prevoie le droit du responsable de traitement de realiser des audits. Le AI Act renforce cette exigence pour les systemes a haut risque en imposant un systeme de surveillance continue.

La clause d’audit doit prevoir le droit pour l’acheteur de realiser ou de faire realiser des audits de conformite (RGPD et AI Act), les modalites pratiques (preavis, frequence, acces, confidentialite des resultats), l’obligation pour le fournisseur de fournir les resultats de ses propres audits internes (rapports SOC 2, certifications ISO, audits de non-discrimination) et le droit d’acces aux journaux de bord (logs) du systeme.

Un point de vigilance : de nombreux fournisseurs SaaS refusent les audits sur site et proposent a la place des rapports d’audit tiers (SOC 2 Type II). Ces rapports, bien qu’utiles, ne suffisent pas a couvrir les aspects specifiques a l’IA (equite, non-discrimination, explicabilite). L’acheteur doit negocier un droit d’audit complementaire couvrant ces aspects.

5. Clause de performance et de niveaux de service (SLA)

Le contrat doit inclure des engagements de performance specifiques a l’IA, au-dela des SLA traditionnels de disponibilite et de temps de reponse. Les metriques de performance du systeme d’IA doivent etre definies contractuellement : precision, rappel, taux de faux positifs, taux de faux negatifs et toute metrique pertinente pour le cas d’usage.

Le contrat doit prevoir les seuils minimaux de performance en dessous desquels le fournisseur est en defaut, les mecanismes de mesure et de verification de la performance, les consequences du non-respect des seuils (penalites, droit de resiliation) et les obligations de maintien de la performance dans le temps (degradation du modele).

6. Clause de gestion des modifications et des mises a jour

Les systemes d’IA evoluent frequemment : mises a jour de l’algorithme, reentrainement du modele, modification des donnees d’entrainement. Ces evolutions peuvent affecter la performance, l’equite et la conformite du systeme.

Le contrat doit prevoir l’obligation pour le fournisseur de notifier l’acheteur de toute modification substantielle du systeme, un delai de preavis suffisant pour permettre a l’acheteur d’evaluer l’impact de la modification, le droit pour l’acheteur de refuser une modification et de maintenir la version precedente, les procedures de test et de validation des modifications et la mise a jour de la documentation technique et des instructions d’utilisation.

Pour les systemes a haut risque, une modification substantielle peut necessiter une nouvelle evaluation de conformite. Le contrat doit repartir les responsabilites et les couts associes a cette reevaluation.

7. Clause de responsabilite et d’indemnisation

La repartition de la responsabilite entre le fournisseur et l’acheteur est un enjeu central du contrat SaaS d’IA. Le contrat doit preciser la responsabilite du fournisseur en cas de defaut du systeme (erreurs, biais, discriminations, violations de donnees), la responsabilite de l’acheteur en cas d’utilisation non conforme aux instructions, les mecanismes d’indemnisation en cas de sanctions ou de condamnations resultant d’un defaut du systeme, la couverture assurantielle du fournisseur et les limites de responsabilite et les exclusions.

Les plafonds de responsabilite classiques des contrats SaaS (generalement limites au montant de l’abonnement annuel) sont souvent inadequats au regard des risques lies a l’IA. Les sanctions RGPD et les sanctions AI Act peuvent atteindre des montants considerablement superieurs. L’acheteur doit negocier des plafonds de responsabilite adaptes aux risques reels.

8. Clause de sortie et de reversibilite

La dependance a un fournisseur SaaS d’IA (vendor lock-in) est un risque strategique majeur. Le contrat doit prevoir les conditions de restitution des donnees, les conditions de transfert des modeles et des configurations, les delais de preavis et de transition, l’assistance du fournisseur pendant la periode de transition et les formats de donnees et les interfaces de portabilite.

Le registre des systemes IA doit etre mis a jour lors de tout changement de fournisseur, et les obligations de conformite IA-RGPD doivent etre verifiees pour le nouveau systeme.

Les points de negociation prioritaires

La hierarchie des enjeux

Tous les points contractuels n’ont pas la meme criticite. Les points de negociation prioritaires, dans l’ordre, sont l’interdiction d’utilisation des donnees pour l’entrainement du modele du fournisseur (sauf accord explicite et encadre), le droit d’audit effectif couvrant les aspects specifiques a l’IA, la notification des modifications substantielles avec droit de refus, la transparence sur les metriques de performance et les biais connus, la couverture de responsabilite adequate et les conditions de sortie et de portabilite des donnees.

La strategie de negociation

Pour les solutions SaaS standardisees proposees par de grands editeurs, la marge de negociation est souvent limitee. L’acheteur doit identifier les clauses non negociables du fournisseur, evaluer si ces clauses sont compatibles avec ses obligations legales, documenter les risques residuels acceptes et mettre en place des mesures compensatoires internes le cas echeant.

La CNIL a souligne que le responsable de traitement ne peut pas invoquer le refus du sous-traitant de modifier ses conditions contractuelles pour justifier un defaut de conformite. Si les conditions du fournisseur ne permettent pas de satisfaire les obligations du RGPD, l’acheteur doit changer de fournisseur.

Le cadre legal est consultable sur Legifrance pour le droit national et sur EUR-Lex pour le droit europeen.

FAQ

Le fournisseur SaaS d’IA peut-il utiliser mes donnees pour entrainer son modele ?

L’utilisation des donnees du client pour l’entrainement du modele du fournisseur est une pratique repandue mais juridiquement sensible. Si les donnees concernees sont des donnees personnelles, cette utilisation constitue un traitement distinct du traitement realise pour le compte du client. Le fournisseur ne peut pas l’effectuer en tant que simple sous-traitant au titre de l’article 28 du RGPD : il doit disposer de sa propre base legale (generalement l’interet legitime ou le consentement), informer les personnes concernees et respecter l’ensemble des obligations du RGPD. Le contrat doit clairement distinguer les traitements realises en tant que sous-traitant (pour le compte du client) et les traitements realises pour les propres finalites du fournisseur. En cas de doute ou de risque excessif, l’acheteur doit exiger contractuellement l’interdiction d’utilisation des donnees pour l’entrainement.

Comment verifier que le systeme d’IA SaaS n’est pas discriminatoire ?

La verification de la non-discrimination d’un systeme SaaS d’IA requiert une approche combinant les audits contractuels et les tests operationnels. Sur le plan contractuel, l’acheteur doit obtenir du fournisseur les resultats des tests d’equite realises sur le systeme, les metriques de non-discrimination calculees (taux de selection differentiel, egalite des chances), la description des mesures de debiaisage mises en oeuvre et le droit de realiser ses propres tests sur le systeme. Sur le plan operationnel, l’acheteur doit mettre en place un suivi continu des resultats du systeme, ventile par groupes demographiques pertinents, analyser les ecarts et signaler les biais detectes au fournisseur. L’audit algorithmique periodique doit couvrir la dimension de non-discrimination. Pour les systemes de recrutement ou de credit, classes a haut risque par le AI Act, ces verifications sont juridiquement obligatoires.

Que faire si le fournisseur SaaS refuse de modifier ses clauses contractuelles standard ?

Le refus du fournisseur de modifier ses clauses ne decharge pas l’acheteur de ses obligations legales. Plusieurs options s’offrent a l’acheteur. Premierement, evaluer si les clauses standard du fournisseur, meme non ideales, satisfont les exigences minimales du RGPD et du AI Act. Deuxiemement, documenter les risques residuels lies aux clauses non modifiees et les mesures compensatoires internes mises en place (controles renforces, limitations d’usage, formation des utilisateurs). Troisiemement, negocier des amendements cibles sur les points les plus critiques (utilisation des donnees pour l’entrainement, droit d’audit, notification des modifications). Quatriemement, si les clauses standard sont incompatibles avec les obligations legales (par exemple, absence de clause conforme a l’article 28 du RGPD), l’acheteur doit changer de fournisseur. La documentation de l’analyse et de la decision est essentielle pour demontrer la diligence de l’acheteur en cas de controle.