Open source et AI Act : exemptions, obligations et pièges à éviter.
Le caractère open source ne place pas automatiquement un système ou un modèle hors de l’AI Act. Le règlement prévoit des adaptations et exemptions ciblées, dont les conditions doivent être lues avec le rôle, la mise sur le marché, la monétisation, la catégorie de risque et l’usage réel.
L’AI Act prévoit des régimes spécifiques pour certains composants et modèles diffusés sous licence libre et ouverte, mais les exemptions ne sont ni générales ni absolues. Elles peuvent cesser pour des systèmes à haut risque, des pratiques interdites, certains modèles à risque systémique ou une mise à disposition liée à une activité commerciale.
Cluster éditorial : Fournisseurs et chaîne de valeur · Intention : Comprendre les obligations AI Act applicables à l’open source
En bref
L’essentiel à retenir
01
Open source ne signifie pas hors périmètre
02
Conditions de licence et d’accès à vérifier
03
Exceptions limitées pour le haut risque et le risque systémique
04
Intégrateur responsable de son propre produit et usage
01
Vérifier les conditions avant d’invoquer une exemption
Documentez la licence, l’accès au code ou aux paramètres, la documentation fournie, les restrictions, la monétisation et les services associés. Un produit présenté comme « open » peut conserver des éléments fermés ou être mis à disposition dans le cadre d’une activité commerciale. La qualification dépend des conditions effectives, pas d’un slogan dans une page de téléchargement.
Identifiez aussi l’objet : composant logiciel, système d’IA, modèle à usage général, poids, bibliothèque ou application complète. Les obligations ne se distribuent pas de la même manière. Conservez la version de la licence et les preuves disponibles au moment de la décision. Une nouvelle licence ou un service payant peut modifier l’analyse.
Les adaptations prévues par le règlement comportent des limites, notamment lorsque des systèmes relèvent du haut risque ou de pratiques interdites. Pour les modèles à usage général, le risque systémique et certaines obligations restent déterminants. Il faut donc lire chaque exemption avec ses conditions au lieu d’appliquer une règle générale « open source égale exemption ».
Même lorsqu’une obligation ne pèse pas sur l’auteur initial, l’acteur qui intègre, adapte ou commercialise peut devenir fournisseur du système final. Le rôle évolue avec la marque, la finalité et la modification substantielle. Une organisation qui déploie le système conserve ses responsabilités d’usage, de maîtrise, de transparence et de protection des données.
Demandez une fiche de version, la provenance, les données connues, les évaluations, les limites, la sécurité, les dépendances et le processus de vulnérabilité. Reproduisez les tests importants dans votre contexte. Un classement public ou une carte de modèle est un point de départ, pas une garantie pour une langue, une population ou une finalité différente.
Analysez la communauté et la maintenance : rythme de publication, responsables, traitement des incidents, signatures, dépendances et correctifs. Préparez un gel de version et une solution de repli. Les mises à jour fréquentes peuvent améliorer la sécurité tout en changeant les performances ou les sorties, ce qui impose une revue coordonnée.
L’intégrateur décrit l’architecture, les composants, les licences, les adaptations, la finalité, les données et les tests. Il attribue les responsabilités de maintenance et d’incident. La documentation doit permettre de distinguer ce qui vient du projet open source et ce qui résulte de la configuration, du réglage, des données ou de l’interface locale.
Dans les achats et contributions, encadrez les secrets, la propriété intellectuelle, les obligations de redistribution et les données. Surveillez les vulnérabilités et les changements de gouvernance du projet. La transparence offerte par le code peut améliorer l’audit, mais elle ne remplace ni l’analyse du comportement ni les mesures organisationnelles autour du système.
