AI Act et open source : exemptions, obligations et cas particuliers

L'open source occupe une place particulière dans l'AI Act. Après de vives controverses pendant les négociations — certains acteurs craignaient que les obligations étouffent l'open source IA — le règlement final a ménagé des exemptions spécifiques. Mais ces exemptions ont des limites, et les entreprises qui construisent sur des modèles open source doivent bien les comprendre.

L'exemption open source dans l'AI Act : le principe

L'AI Act exempte les fournisseurs de modèles GPAI open source (dont les paramètres/poids sont publics) des obligations de documentation et de transparence vers les intégrateurs. Cette exemption ne s'applique pas si le modèle open source est : utilisé dans un système à risque élevé, ou présente un risque systémique (>10²⁵ FLOPs d'entraînement).

L'article 53 paragraphe 2 de l'AI Act prévoit que les fournisseurs de modèles GPAI à usage général publiés sous licence open source sont exemptés des obligations de documentation et de transparence envers les intégrateurs, à condition que les paramètres du modèle — y compris les poids — soient rendus publics.

Cette exemption est fondée sur un argument convaincant : si le modèle complet est public, n'importe qui peut l'auditer. La transparence est structurellement garantie par l'ouverture du code.

Les limites de l'exemption open source

L'exemption n'est pas totale. Plusieurs conditions la restreignent.

Limite 1 — Le risque systémique : les modèles open source dépassant le seuil de 10²⁵ FLOPs d'entraînement (les modèles les plus puissants) ne bénéficient pas de l'exemption. Ils restent soumis aux obligations GPAI complètes, y compris les évaluations de risques systémiques et les tests adversariaux.

Limite 2 — L'usage dans un système à risque élevé : si un modèle open source est intégré dans un système à risque élevé (IA de recrutement, système de crédit, outil médical...), le développeur de ce système assume pleinement les obligations liées au risque élevé. Le fait que le modèle de base soit open source ne change rien.

Limite 3 — Les pratiques interdites : un modèle open source utilisé pour une pratique interdite (manipulation subliminale, scoring social, etc.) reste illégal. L'open source n'exempte pas des interdictions absolues.

SituationExemption open sourceObligations restantes
Modèle open source < 10²⁵ FLOPs, usage généralOui — exemption complèteDroit d'auteur, obligations interdictions
Modèle open source > 10²⁵ FLOPsNonToutes obligations GPAI y compris risque systémique
Modèle open source intégré dans système risque élevéNon (pour l'intégrateur)Obligations risque élevé à la charge de l'intégrateur
Modèle open source utilisé pour pratique interditeNonInterdiction absolue s'applique
Modèle open source fin-tuned et redistribuéOui si poids redistribuésLe fine-tuner devient fournisseur

Ce que Llama, Mistral et les autres doivent (ou ne doivent pas) faire

Concrètement, que change l'AI Act pour les principaux modèles open source ?

Meta Llama : les modèles Llama (7B, 13B, 70B, Llama 3...) sont distribués avec leurs poids. Ils bénéficient de l'exemption pour les obligations GPAI standard. Meta doit néanmoins respecter les obligations GPAI si ses modèles dépassent le seuil de risque systémique.

Mistral AI : ses modèles open source (Mistral 7B, Mixtral 8x7B) bénéficient de l'exemption. Mistral Large et ses modèles propriétaires sont soumis aux obligations GPAI classiques.

Falcon (Technology Innovation Institute, Abu Dhabi) : modèle publié sous licence Apache 2.0, bénéficie de l'exemption. Mais son fournisseur étant hors UE, des questions de compétence juridique se posent.

BLOOM (Hugging Face, BigScience) : modèle open source académique, probablement exempté.

La définition de 'open source' dans l'AI Act est précise : il faut que les paramètres (poids) soient publics. Un modèle dont le code est ouvert mais dont les poids sont propriétaires (comme c'était le cas pour GPT-2 d'OpenAI initialement) ne bénéficie pas de l'exemption.

Le fine-tuning de modèles open source : qui est responsable ?

L'une des questions pratiques les plus importantes concerne le fine-tuning : si je prends Llama, que je l'entraîne sur mes données, et que je déploie le résultat dans un service, qui est responsable ?

L'AI Act est clair sur ce point : le fine-tuner devient fournisseur du modèle résultant. Si ce modèle fine-tuné est utilisé dans un contexte à risque élevé, c'est le fine-tuner (pas Meta) qui doit respecter les obligations correspondantes.

En pratique : - Vous fine-tunez Llama pour créer un outil de scoring de crédit → vous êtes le fournisseur d'un système à risque élevé - Vous fine-tunez Llama pour créer un chatbot de service client standard → vous êtes potentiellement dans la catégorie risque limité (obligations de transparence) - Vous fine-tunez Llama pour usage interne uniquement → les obligations s'appliquent si vous déployez vers des tiers ou dans des contextes à risque élevé

IA générale GPAI : toutes les obligations

Les enjeux pour l'écosystème open source IA

Les exemptions open source ont été saluées par la communauté, mais des inquiétudes subsistent.

L'argument pour les exemptions : l'open source permet une recherche en sécurité plus efficace (n'importe qui peut auditer), stimule l'innovation (les startups peuvent construire sans partir de zéro), et réduit la concentration du marché (alternative aux GAFAM).

Les risques des exemptions : certains acteurs pourraient utiliser l'open source comme moyen de contourner les obligations, en publiant des modèles dont la finalité réelle est commerciale ou risquée.

L'évolution probable : le règlement prévoit une révision du seuil de 10²⁵ FLOPs et des critères d'exemption open source à la lumière de l'évolution technologique. Ce seuil, qui semblait ambitieux en 2024, pourrait être atteint par des modèles plus courants dans les prochaines années.

  • Vérifiez si les poids de votre modèle de base sont vraiment publics
  • Si vous fine-tunez pour un usage à risque élevé, vous devenez fournisseur
  • L'open source ne vous exempte pas des interdictions absolues
  • Pour les modèles > 10²⁵ FLOPs : obligations GPAI complètes même en open source
  • Documentez vos modifications et l'usage prévu de vos modèles fine-tunés

FAQ : AI Act et open source

Conclusion

L'exemption open source de l'AI Act représente un équilibre délicat entre favoriser l'innovation et assurer la responsabilité. Pour les développeurs utilisant des modèles open source, le message est clair : vous bénéficiez d'une exemption sur certaines obligations documentaires, mais vous restez pleinement responsable de l'usage que vous faites de ces modèles.

Questions fréquentes

Puis-je utiliser Llama commercialement sans respecter l'AI Act ?

Non. L'exemption open source de l'AI Act porte sur les obligations documentaires envers les intégrateurs. Elle ne vous exempte pas des obligations liées à votre propre usage. Si vous déployez Llama dans un service à risque élevé ou si vous l'utilisez pour des pratiques interdites, l'AI Act s'applique pleinement.

Hugging Face est-il soumis à l'AI Act ?

Partiellement. Hugging Face est une plateforme d'hébergement de modèles. En tant que plateforme, il facilite la distribution de modèles open source mais n'en est généralement pas le fournisseur au sens de l'AI Act. En revanche, les modèles qu'il développe lui-même (Bloom, StarCoder...) le soumettent aux obligations correspondantes.

Un modèle open source sous licence restrictive (non-commercial) bénéficie-t-il de l'exemption ?

La question n'est pas totalement tranchée. L'AI Act se réfère aux 'licences open source' sans préciser exactement quelles licences sont concernées. La Commission devrait clarifier ce point dans des lignes directrices. Il est prudent de considérer que seules les licences vraiment libres (MIT, Apache, GPL) sont concernées par l'exemption.

Les modèles d'IA open source sont-ils exemptés de l'AI Act ?

Partiellement. Les modèles GPAI open source dont les poids sont publics bénéficient d'une exemption des obligations de documentation envers les intégrateurs. Mais ils restent soumis aux interdictions absolues, et les développeurs qui les utilisent dans des systèmes à risque élevé doivent respecter les obligations correspondantes.