Operationnaliser les modeles d'IA a usage general sans ralentir le produit

Les modeles d'IA a usage general deviennent gerables lorsque l'equipe les traite comme un workflow produit et fournisseur, non comme une note juridique separee. Il faut tenir un inventaire, cartographier le role de l'entreprise, revoir les changements importants, centraliser la documentation fournisseur et collecter les preuves pendant le travail produit.

Dans l'AI Act de l'UE, les obligations principales figurent au chapitre V. L'article 53 impose aux fournisseurs de modeles d'IA a usage general une documentation technique, des informations pour les downstream providers, une politique de copyright et un resume public du contenu d'entrainement. L'article 55 ajoute des obligations pour les modeles a risque systemique, notamment evaluation, attenuation des risques, declaration d'incidents graves et cybersecurite. L'article 51 explique la classification, y compris la presomption au-dela de 10^25 operations en virgule flottante pour l'entrainement.

La plupart des entreprises SaaS n'entrainent pas de modeles frontier. Elles peuvent pourtant integrer un modele, le fine-tuner, exposer des sorties aux clients, dependre d'un fournisseur ou devoir repondre aux acheteurs sur la gouvernance IA.

Commencer par l'inventaire

Incluez APIs hebergees, modeles open source, modeles fine-tuned, fonctionnalites fournisseurs, outils internes, copilotes produit, assistants support et workflows configurables par les clients. Pour chaque entree, notez le modele, le fournisseur, la version, l'hebergement, le cas d'usage, l'owner produit, les donnees, l'exposition client, la geographie et les modifications.

L'inventaire doit etre relie a l'intake produit et a la vendor review. Un nouveau feature IA, un changement de fournisseur, une nouvelle version, une nouvelle categorie de donnees ou un lancement UE doit mettre a jour le meme enregistrement.

Cartographier le role

Avant de discuter des obligations, determinez si l'entreprise est fournisseur du modele, downstream provider d'un systeme IA, deployer, distributeur ou cliente d'une fonctionnalite fournisseur. Les articles 53 et 55 concernent les fournisseurs de modeles, mais un SaaS downstream peut avoir d'autres obligations ou attentes de preuve.

Le role record doit expliquer qui met le modele ou systeme sur le marche, qui le controle, qui le modifie, qui definit l'usage prevu, qui voit les sorties et qui peut changer le comportement. En cas de fine-tuning, redistribution ou packaging, une revue juridique est necessaire.

Definir les declencheurs

Declenchez une revue lorsqu'un nouveau modele est ajoute, le fournisseur ou la version change, un fine-tuning est effectue, les sorties deviennent visibles par les clients, un usage sensible apparait, les parametres de retention ou d'entrainement changent, ou le fournisseur signale un risque systemique. La decision doit etre approuvee, approuvee avec conditions, bloquee ou en attente de faits.

Construire un dossier de preuves

Le dossier minimal comprend inventaire, role, cas d'usage, fournisseur, version, hebergement, donnees, exposition client, usages autorises et interdits, documentation fournisseur, privacy review, security review, logging, monitoring, processus de changement, fallback et position de disclosure client.

Si l'entreprise fournit ou modifie fortement un modele, ajoutez documentation technique, donnees d'entrainement ou fine-tuning, evaluations, limites, politique copyright, resume d'entrainement, documentation downstream, analyse de risque systemique, processus incident et cybersecurite.

Integrer l'article 53 a la vendor review

Meme downstream, l'equipe doit demander documentation technique, documentation d'integration, politique copyright, resume d'entrainement, notes de capacites et limites, restrictions d'usage, documentation safety et avis de mise a jour. Demander "etes-vous compliant?" ne suffit pas.

Router le risque systemique separement

Demandez au fournisseur s'il classe le modele comme systemique, s'il a notifie l'AI Office, quelles preuves safety et security sont disponibles et quels changements declenchent une notification client. Pour le produit, l'enjeu est le risque de dependance: disponibilite, politiques, limites et incidents peuvent affecter les engagements clients.

Utiliser le Code of Practice

Le General-Purpose AI Code of Practice est volontaire, mais utile comme reference operationnelle pour transparence, copyright, safety, security, documentation et gestion des risques. La signature du Code n'est pas toute la diligence, mais c'est un fait a consigner.

FAQ

Quel est le but pratique?

Savoir quels modeles l'entreprise utilise, quel role elle joue, quelles preuves existent et que faire quand le modele, le cas d'usage, le fournisseur ou le droit change.

Quand cela concerne-t-il les equipes SaaS?

Lorsqu'elles fournissent, integrent, deploient, configurent, fine-tunent ou utilisent un modele d'IA a usage general dans un produit, workflow interne ou partenariat fournisseur.

Que documenter d'abord?

Inventaire, role record, documentation fournisseur, cas d'usage, exposition client, donnees, version, reviews privacy et security, copyright, limites, monitoring et declencheurs de changement.

Sources

• Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence.
• European Commission AI Act Service Desk, Article 51.
• European Commission AI Act Service Desk, Article 53.
• European Commission AI Act Service Desk, Article 55.
• European Commission, Drawing-up a General-Purpose AI Code of Practice.