L'AI Act ne s'applique pas seulement aux fournisseurs de systèmes IA à haut risque (Annexe III). Il s'applique aussi, partiellement, aux fournisseurs en amont : ceux qui fournissent un composant IA, un modèle, un dataset à un fournisseur en aval qui en fait un système haut risque. Beaucoup de scale-ups françaises et européennes sont dans cette situation sans le savoir. Voici la lecture pratique.
Êtes-vous fournisseur en amont ?
Vous l'êtes si vous fournissez à un autre éditeur :
- Un modèle IA (foundation model, fine-tune, modèle spécialisé).
- Un composant IA (module de classification, NLP, vision, recommandation) qui est intégré dans un système plus large.
- Un dataset d'entraînement ou de test.
- Un service d'API que d'autres consomment pour bâtir leur produit.
Et que ce client en aval intègre votre composant dans un système qu'il commercialise comme "haut risque" au sens Annexe III (recrutement, scoring crédit, éducation, infrastructure critique, etc.).
Exemple concret : votre startup propose une API de classification de CV. Un client RH l'intègre dans son outil de filtrage de candidatures. Le système final est haut risque (Annexe III, recrutement). Vous êtes fournisseur en amont.
Les obligations imposées par l'article 25
L'article 25 de l'AI Act définit la chaîne de responsabilité. Vos obligations en amont :
1. Information
Vous devez fournir à votre client en aval :
- Description technique du composant : capacités, limites, performance, conditions d'usage prévues, hors-périmètre.
- Données d'entraînement : type, sources, biais connus, méthodes de collecte.
- Évaluation des risques que vous avez réalisée.
- Mesures de mitigation que vous avez mises en place.
2. Coopération
Vous devez coopérer avec votre client pour qu'il puisse remplir ses propres obligations AI Act :
- Répondre aux questions de conformité.
- Fournir les artefacts techniques nécessaires (model cards, datasheets).
- Notifier les changements significatifs (mise à jour majeure du modèle, dérive détectée).
3. Documentation conservée
Vous devez conserver :
- La documentation technique pendant 10 ans après la mise sur le marché.
- Les logs d'interaction si pertinents.
- Les preuves d'évaluation et tests.
4. Notification des incidents
Si vous découvrez un incident sérieux ou un dysfonctionnement de votre composant, vous devez en informer :
- Votre client en aval (qui notifiera les autorités).
- Selon les cas, directement les autorités de surveillance.
5. Pas l'obligation complète Annexe III
Vous n'avez pas à :
- Produire la documentation technique complète Annexe IV (c'est la charge du fournisseur en aval).
- Faire l'évaluation de conformité par tiers.
- Apposer le marquage CE-AI.
- Inscrire le composant à l'EU database.
C'est la charge de votre client. Vous l'aidez, mais le système final lui appartient.
Le cas particulier des modèles GPAI (General Purpose AI)
Si vous fournissez un modèle d'IA à usage général (GPAI) — typiquement un foundation model — vous tombez dans un régime spécifique (article 53-55).
Obligations GPAI :
- Documentation technique disponible aux autorités et aux fournisseurs en aval.
- Politique de respect du droit d'auteur documentée.
- Résumé public détaillé des données d'entraînement.
Pour les GPAI à risque systémique (modèles de très grande capacité, FLOPs > 10^25), obligations renforcées :
- Évaluation et tests d'attaques adversariales.
- Notification d'incidents systémiques.
- Cybersécurité renforcée du modèle et de son infrastructure.
Pour la grande majorité des startups françaises et européennes, vous n'êtes pas dans le périmètre GPAI à risque systémique. Mais vérifier : Mistral, par exemple, l'est probablement.
Les artefacts à produire
Pour faciliter votre rôle de fournisseur amont :
Model card
Document qui décrit votre modèle :
- Identité (nom, version, taille).
- Architecture, dataset d'entraînement.
- Performance (métriques, limites, bias).
- Use cases prévus, hors-périmètre.
- Comment évaluer la performance pour un nouveau use case.
Format de référence : Hugging Face model card.
Datasheet
Pour vos datasets :
- Provenance.
- Distribution statistique.
- Méthodes de collecte et d'annotation.
- Limites et biais connus.
- Procédure de mise à jour.
Format de référence : Datasheets for Datasets (Gebru et al.).
System card
Pour vos systèmes complets :
- Description fonctionnelle.
- Architecture sécurité.
- Tests effectués.
- Limitations contextuelles.
DPA spécifique IA
Adapter votre DPA pour couvrir :
- Politique de non-utilisation des inputs pour réentraînement.
- Délais de notification d'incident IA.
- Coopération avec votre client pour ses obligations AI Act.
La pratique : packs de conformité par client
Pour scaler votre activité de fournisseur amont, je recommande de préparer des packs de conformité par client :
- Pack standard : model card + datasheet + DPA + politique sécurité. Donné systématiquement à tout client utilisant vos services dans un contexte AI Act.
- Pack étendu : sur demande, pour les clients qui font un système haut risque. Contient en plus : tests d'évaluation détaillés, évaluation des biais, résultats de red-teaming.
- Support audit : mécanisme pour répondre aux audits client ou aux régulateurs si demandé.
Les questions DDQ types
Vos clients en aval vont vous demander :
- "Votre modèle est-il un GPAI ?"
- "Avez-vous fait une évaluation des risques ?"
- "Quelles sont les limites connues ?"
- "Comment notifiez-vous les incidents ?"
- "Avez-vous une politique de respect du droit d'auteur dans le training ?"
- "Combien de temps conservez-vous la documentation ?"
- "Avez-vous une démarche NIST AI RMF ou ISO 42001 ?"
Pré-rédiger les réponses dans un FAQ AI Act partagé avec vos commerciaux.
Le coût opérationnel
Pour une scale-up qui fournit des composants IA :
- Préparation initiale des artefacts : 2-4 mois, équipe IA + juridique + conformité.
- Maintenance annuelle : 0.2-0.5 ETP.
- Coût : essentiellement de la documentation et du process, peu de coût direct technique.
ROI : vos clients en aval sont obligés de choisir des fournisseurs amont conformes. C'est devenu un critère commercial actif en 2026.
Le piège — confondre amont et aval
Beaucoup de startups se positionnent comme "fournisseur uniquement amont, pas concerné par AI Act haut risque" alors qu'elles vendent en réalité directement le système final à leurs clients (ex: SaaS RH qui filtre les candidats).
Test simple : si vous mettez le marquage CE-AI sur le système, vous êtes fournisseur en aval (et toutes les obligations Annexe III s'appliquent). Si votre client met le marquage, vous êtes en amont.
En cas de doute, considérer que vous êtes en aval et appliquer les obligations complètes — c'est plus prudent qu'une découverte tardive.
