Quand les obligations du fournisseur s'appliquent et quoi faire ensuite

Les obligations du fournisseur s'appliquent lorsqu'une entreprise SaaS est responsable d'un systeme d'IA ou d'un modele d'IA a usage general au titre de l'EU AI Act. La question ne se limite pas a l'auteur du code du modele. Elle porte aussi sur le developpement, la mise sur le marche sous son propre nom, la modification substantielle, le changement de finalite et la fourniture d'un modele GPAI.

La suite doit etre operationnelle: ouvrir un dossier d'obligations fournisseur, documenter l'actif IA, la finalite prevue, le role, la piste de risque, les obligations declenchees, le proprietaire des preuves et le gate de lancement.

Pourquoi c'est important

Ces obligations determinent qui doit prouver que le systeme a ete concu, documente, evalue, surveille et supporte. Pour les systemes a haut risque, l'article 16 couvre notamment le systeme qualite, la documentation technique, les logs, l'evaluation de conformite, la declaration UE de conformite, le marquage CE lorsque necessaire, l'enregistrement, les actions correctives et la cooperation avec les autorites.

Dans le SaaS, la question apparait souvent pendant le delivery: scoring IA, modele tiers integre, module rebrande, changement de finalite, API de modele ajuste. Chaque cas peut modifier le role.

Quand cela s'applique

Commencez par les roles. Une meme entreprise peut etre deployeur pour un outil interne, fournisseur pour une fonction client, distributeur pour un outil integre et fournisseur GPAI pour une API. Dire simplement "nous utilisons une IA vendor" ne suffit pas.

Les declencheurs courants sont les fonctions IA exposees aux clients, modules white-label, ranking ou scoring, recommandations automatisees, contextes haut risque, nouveaux modeles, nouvelles sources de donnees, nouveaux segments clients ou nouveau positionnement produit.

Que documenter d'abord

Le dossier minimum repond a six questions: quel actif IA, quelle finalite, quel role, quelle piste d'obligations, quelles preuves et quand reevaluer.

Incluez documentation technique, registre de risques, gouvernance des donnees, tests, decisions de logging, supervision humaine, instructions client, documents vendors, monitoring et approbations de release.

L'integrer au delivery

Le workflow doit vivre dans la discovery produit, la revue d'architecture, le vendor review, le release readiness et le monitoring post-lancement. Product decrit le cas d'usage. Engineering apporte les faits techniques. Legal ou compliance interprete les roles et obligations. Security valide les controles. Les equipes client utilisent des explications approuvees.

Erreurs courantes

La premiere erreur est de supposer que le vendeur du modele est toujours le fournisseur du systeme. Les autres erreurs sont les inventaires IA sans champs de role, les analyses juridiques ponctuelles, l'information downstream perdue pour les clients et les preuves separees du release.

FAQ

Quel est l'objectif pratique?

Identifier qui est responsable du systeme IA ou du modele GPAI et relier ce role a la documentation, aux controles de risque, aux informations client, au monitoring et aux preuves.

Quand cela s'applique-t-il au SaaS?

Lorsque l'equipe developpe, fait developper, commercialise sous son nom, met sur le marche, modifie substantiellement, change la finalite ou fournit un modele GPAI.

Par ou commencer?

Par un dossier qui couvre actif, finalite, role, piste de risque, obligations, responsable des preuves, emplacement documentaire, gate de lancement et declencheurs de reevaluation.