Le cadre de l'AI Act : trois acteurs, quatre niveaux de risque

Le Règlement (UE) 2024/1689 est le premier cadre juridique complet au monde sur l'intelligence artificielle. Il repose sur une approche par les risques : pratiques inacceptables (interdites), systèmes à haut risque (obligations lourdes), risque limité (transparence), risque minimal (aucune obligation). Comme le rappelle la Direction générale des Entreprises, le texte concerne toute organisation qui fournit, importe, distribue ou déploie un système d'IA utilisé dans l'Union.

Je ne détaille pas ici les obligations article par article — elles sont couvertes en profondeur ailleurs. Ce qui compte pour la question du cloud, ce sont les rôles. Le règlement distingue le fournisseur (celui qui développe ou fait développer un système et le met sur le marché sous son nom), le déployeur (celui qui l'utilise sous sa propre autorité dans un cadre professionnel), et l'importateur/distributeur. Un même acteur peut cumuler plusieurs rôles ; surtout, un déployeur peut basculer en fournisseur selon ce qu'il fait du système.

Le calendrier post-omnibus qu'il faut avoir en tête

Depuis l'accord « omnibus numérique » du 7 mai 2026, le calendrier d'application a été révisé. Les dates à retenir :

  • 2 février 2025 : interdictions (art. 5) et obligation de maîtrise/formation à l'IA (art. 4, « AI literacy ») — déjà applicables.
  • 2 août 2025 : règles pour les modèles d'IA à usage général (GPAI) et gouvernance (AI Office).
  • 2 août 2026 : transparence (art. 50), sanctions (art. 99), autorités nationales, application générale.
  • 2 décembre 2027 : systèmes à haut risque de l'annexe III (RH, scoring crédit, biométrie, éducation, justice, santé) — reporté du 2 août 2027 par l'omnibus.
  • 2 août 2028 : haut risque de l'annexe I (IA intégrée à des produits réglementés : dispositifs médicaux, machines).

Pour un panorama structuré des obligations par rôle et par niveau de risque, je renvoie au hub AI Act d'IAPRO.

L'infrastructure cloud est-elle un « système d'IA » ?

Non, et c'est fondamental. Un service d'infrastructure (IaaS) ou de plateforme (PaaS) — machines virtuelles, stockage objet, orchestration de conteneurs, GPU à la demande — est un socle de calcul, pas un système d'IA. L'AI Act définit un système d'IA par sa capacité à inférer, à partir d'entrées, des sorties (prédictions, contenus, recommandations, décisions) influençant des environnements. Un cluster GPU nu ne fait rien de tel : il exécute ce que vous y déployez.

En pratique, un fournisseur de services cloud (CSP) qui vend du calcul brut n'est donc pas fournisseur d'IA au sens du règlement. Sa responsabilité relève d'autres régimes : RGPD pour les données personnelles qu'il traite en tant que sous-traitant, obligations de sécurité, engagements contractuels de disponibilité. L'ANSSI distingue d'ailleurs clairement les exigences de cybersécurité pesant sur les fournisseurs cloud des responsabilités du commanditaire sur ce qu'il porte dans le cloud.

Le point de bascule : quand le CSP intègre de l'IA

La qualification change dès que le CSP incorpore une fonctionnalité d'IA dans un service qu'il commercialise : détection d'anomalies « intelligente » dans son monitoring, moteur de recommandation, assistant génératif intégré à sa console, ou — surtout — une API de modèle exposée aux clients. Dans ce cas, pour ce service précis, le CSP devient fournisseur d'IA (ou fournisseur de GPAI) et porte les obligations correspondantes. La frontière n'est donc pas « cloud vs pas cloud » : elle passe à l'intérieur du catalogue du CSP, service par service.

GPAI : la responsabilité des géants du cloud sur les modèles de fondation

Les modèles d'IA à usage général (GPAI, general-purpose AI) — les grands modèles génératifs de fondation — font l'objet d'un régime spécifique depuis le 2 août 2025. La DILA rappelle que l'AI Act prévoit des obligations propres aux fournisseurs de ces modèles : documentation technique, information des acteurs en aval, politique de respect du droit d'auteur, résumé public des données d'entraînement, et — pour les modèles présentant un risque systémique — évaluation et atténuation de ces risques.

La question que je reçois le plus souvent : « si j'appelle l'API d'un modèle génératif hébergée chez un hyperscaler, qui est fournisseur du GPAI ? » La réponse dépend de la nature du service. Si le CSP se contente d'héberger et de facturer l'accès à un modèle édité par un tiers, l'éditeur du modèle reste fournisseur du GPAI. Si le CSP publie et distribue le modèle sous sa marque, il en devient fournisseur. Et vous, entreprise cliente, êtes en aval : ni l'un ni l'autre — tant que vous ne modifiez pas substantiellement le modèle.

Ce que les obligations GPAI ne couvrent PAS pour vous

Les obligations GPAI portent sur le modèle, pas sur votre usage du modèle. Le fournisseur du GPAI vous transmet la documentation nécessaire pour construire votre propre conformité, mais il ne répond pas de la manière dont vous branchez ce modèle sur un processus décisionnel. C'est exactement là que se situe le transfert de responsabilité que la plupart des entreprises sous-estiment. Pour comprendre comment ces briques s'articulent, notre glossaire IA détaille les notions de GPAI, fine-tuning et modification substantielle.

Le tournant du haut risque : quand l'entreprise devient fournisseur

Voici le cœur du sujet. L'AI Act prévoit qu'un déployeur devient fournisseur dans plusieurs cas : s'il appose son nom ou sa marque sur un système à haut risque déjà mis sur le marché, s'il modifie substantiellement un tel système, ou s'il modifie la finalité d'un système d'IA — y compris à usage général — de telle sorte qu'il devienne à haut risque au sens de l'annexe III.

Traduisons pour une PME. Vous prenez un modèle génératif générique via une API cloud. Tant que vous l'utilisez pour rédiger des brouillons de courriers, vous êtes déployeur d'un système à risque limité. Mais si vous l'intégrez dans un outil qui filtre les CV et présélectionne les candidats, vous basculez dans le domaine RH de l'annexe III : votre application devient un système à haut risque, et c'est vous, l'entreprise, qui en êtes le fournisseur — pas l'éditeur du modèle, pas le CSP. À la clé : système de gestion des risques, gouvernance des données, documentation technique, marquage CE, enregistrement dans la base de données européenne, supervision humaine.

C'est un renversement contre-intuitif : l'entité la moins équipée juridiquement (la PME) hérite des obligations les plus lourdes, parce qu'elle est celle qui donne au système sa finalité à haut risque. Les conditions exactes qui déclenchent cette requalification — critères de l'annexe III, seuil de modification substantielle, articulation du marquage CE — sont détaillées dans le guide de référence sur les systèmes à haut risque de Regulia. Avant tout projet touchant au recrutement, au crédit, à la santé ou à la biométrie, c'est la première lecture à faire.

La matrice de responsabilité partagée : cloud vs AI Act

Les DSI connaissent le modèle de responsabilité partagée du cloud : le CSP sécurise l'infrastructure « du » cloud, le client sécurise ce qu'il met « dans » le cloud. L'AI Act superpose une seconde matrice, orthogonale à la première. Les deux ne se recouvrent pas.

Enjeu Cloud (responsabilité partagée classique) AI Act (responsabilité par rôle)
Disponibilité, patching infra CSP Hors périmètre AI Act
Chiffrement, contrôle d'accès données Partagé CSP / client Contribue à la gouvernance des données
Qualité et représentativité des datasets Client Fournisseur du système à haut risque
Documentation technique du système — Fournisseur
Supervision humaine des décisions — Déployeur
Information des personnes concernées — Déployeur (art. 50)
Biais discriminatoire préjudiciable — Fournisseur et/ou déployeur selon l'origine

Le piège : croire qu'une clause de responsabilité partagée cloud vous couvre sur l'AI Act. Elle ne le fait pas. Un contrat cloud peut préciser qui gère le chiffrement des données d'entraînement, mais il ne décide pas qui est « fournisseur » au sens du règlement — cette qualification découle du texte, pas du contrat. Une IA qui hallucine et produit un préjudice engage la responsabilité de qui a conçu ou déployé sans supervision adéquate, indépendamment de l'hébergeur. Pour estimer ce que cette double gouvernance coûte réellement à mettre en place, notre calculateur de ROI IA intègre le poste conformité.

Souveraineté et conformité : l'apport de la doctrine « Cloud au centre »

La stratégie française « Cloud au centre » fait du cloud le mode d'hébergement par défaut de l'État, avec une exigence forte : pour les données sensibles dont la violation menacerait l'ordre public, la santé ou la propriété intellectuelle, l'offre commerciale retenue doit être qualifiée SecNumCloud et immunisée contre tout accès non autorisé par des autorités d'États tiers. C'est écrit noir sur blanc dans la doctrine publiée par la DINUM.

Pourquoi cela compte pour l'AI Act ? Parce que la conformité au règlement suppose de prouver la maîtrise de la donnée : traçabilité, localisation, protection contre les accès non maîtrisés. Un cloud souverain qualifié SecNumCloud fournit une base probante solide sur ces points, et il neutralise le conflit potentiel entre une loi extraterritoriale (type CLOUD Act) qui exigerait la transmission de données et les obligations européennes de protection. Je constate sur le terrain que ce conflit de lois est le trou noir que personne ne veut ouvrir tant qu'un incident n'a pas eu lieu.

SecNumCloud ne vaut pas conformité AI Act

Attention à ne pas surinterpréter. L'ANSSI précise que la qualification SecNumCloud « ne préjuge pas du niveau de sécurité des services numériques des clients » portés par l'offre. Autrement dit : SecNumCloud sécurise le socle et protège la donnée, mais votre système d'IA reste à mettre en conformité par vous. La souveraineté est un socle de confiance, pas un certificat de conformité AI Act. C'est précisément la position d'IAPRO : installer souverain d'abord, documenter la conformité ensuite.

Gouvernance des données et auditabilité en environnement multi-cloud

L'AI Act, dans son volet haut risque, exige traçabilité (journalisation/logging), robustesse et gouvernance des données. Ces exigences se heurtent frontalement aux architectures multi-cloud, où les données d'entraînement et de fine-tuning peuvent transiter par plusieurs juridictions. La question opérationnelle devient : où sont physiquement mes données pendant l'inférence et l'apprentissage, et qui peut y accéder ?

Trois principes que j'applique dans nos installations :

  • Localiser pour prouver : garder les données d'entraînement et de fine-tuning dans un périmètre géographique et juridique maîtrisé simplifie radicalement la démonstration de gouvernance, en supprimant les transferts hors UE à documenter.
  • Journaliser de bout en bout : conserver des logs horodatés des inférences, des versions de modèle et des jeux de données, de façon inaltérable, pour reconstituer une décision contestée des mois après.
  • Cloisonner par sensibilité : séparer les traitements sensibles (santé, données RH) des usages banals, plutôt que d'appliquer le régime le plus lourd à tout le système d'information.

La CNIL, sur le volet données personnelles, a publié des recommandations utiles sur le développement de systèmes d'IA respectueux du RGPD ; je renvoie au dossier IA de la CNIL. RGPD et AI Act se cumulent : la conformité à l'un ne dispense pas de l'autre. Notre hub solutions par métier décline ces contraintes secteur par secteur.

Risques juridiques du « Shadow AI » : modèles tiers sans supervision

Le risque montant que je vois exploser dans les PME, c'est le Shadow AI : des collaborateurs qui branchent des outils d'IA grand public sur des données de l'entreprise, sans validation, sans supervision, sans contrat. C'est le pire des deux mondes : vous héritez de la responsabilité de déployeur (voire de fournisseur si l'usage bascule en haut risque) sans aucun des garde-fous exigés.

L'AI Act impose au déployeur une surveillance humaine effective : une personne compétente doit pouvoir comprendre, superviser et, le cas échéant, contredire ou arrêter les sorties d'un système à haut risque. Un modèle qui tourne en continu dans le cloud, sans humain dans la boucle, ne satisfait pas cette exigence. Les conséquences d'un dérapage — décision discriminatoire, fuite de données, préjudice à un tiers — se rangent alors sous la responsabilité civile de l'entreprise, et potentiellement pénale selon les faits. L'ANSSI promeut d'ailleurs une approche par les risques sur toute la chaîne de valeur de l'IA, précisément pour éviter ces angles morts.

Feuille de route pour identifier son statut juridique avant de déployer

Voici la méthode IAPRO, appliquée telle quelle dans nos audits, pour savoir si vous êtes déployeur ou fournisseur avant de mettre en production.

  1. Cartographier les flux IA : lister tout système d'IA en usage (officiel et shadow), les données qu'il consomme, les modèles sous-jacents (GPAI tiers ? modèle interne ?) et l'hébergement (cloud public, souverain, on-premise).
  2. Classer le risque par la finalité : ce n'est pas la technologie qui détermine le haut risque, c'est l'usage final. Un même modèle est risque limité pour de la rédaction et haut risque pour du tri de candidatures.
  3. Analyser les contrats en aval et en amont : que dit le contrat du CSP sur la localisation et l'accès aux données ? Que garantit l'éditeur du modèle GPAI sur la documentation transmise ? Où le contrat vous laisse-t-il porter seul une obligation ?
  4. Statuer sur le marquage CE : si l'usage relève de l'annexe III et que vous en êtes fournisseur, planifier l'évaluation de conformité, la documentation technique et l'enregistrement européen, avec le cas échéant un audit tiers.

Une PME industrielle de 80 salariés que j'accompagne pensait n'être « qu'utilisatrice » d'un outil de maintenance prédictive ; l'étape 2 a révélé un usage RH connexe (évaluation de la charge des opérateurs) qui la plaçait en zone annexe III. Sans cette cartographie, elle aurait déployé en fournisseur non déclaré. Pour évaluer les aides mobilisables sur ce type de mise en conformité, voyez notre hub des aides au financement.

Conclusion : vers une architecture cloud « AI Act Ready »

La leçon centrale est simple : dans le cloud, la responsabilité AI Act ne suit pas l'infrastructure, elle suit le rôle — et le rôle suit l'usage. Un CSP en IaaS n'est pas fournisseur d'IA ; un éditeur de GPAI l'est pour son modèle ; une PME peut le devenir dès qu'elle donne une finalité à haut risque à une brique tierce. Aucune clause contractuelle ne transfère cette qualification, qui découle du Règlement (UE) 2024/1689 lui-même. La bonne approche est le by design : penser la souveraineté, la localisation des données et la supervision humaine dès l'architecture, pas après. C'est la conviction d'IAPRO — la souveraineté est le socle de confiance sans lequel l'adoption massive et sécurisée de l'IA en Europe ne tiendra pas.

FAQ — AI Act, cloud et responsabilité

Qui est légalement responsable si une IA déployée sur un cloud tiers produit un résultat discriminatoire ?

La responsabilité se répartit selon les rôles : le fournisseur répond de la conception du système et de la qualité des données d'entraînement, le déployeur de la supervision humaine et de l'usage. L'hébergeur cloud, s'il ne fournit que l'infrastructure, n'est généralement pas responsable du biais. En pratique, l'entreprise qui a donné sa finalité au système est souvent en première ligne.

Un fournisseur de cloud (CSP) peut-il être tenu responsable des biais d'un modèle GPAI qu'il héberge ?

Non, s'il se limite à héberger et facturer l'accès à un modèle édité par un tiers : l'éditeur reste fournisseur du GPAI et répond de ses obligations. Le CSP ne devient responsable du modèle que s'il le distribue sous sa propre marque ou le modifie substantiellement. La simple mise à disposition d'infrastructure ne transfère pas la responsabilité du modèle.

Quelles obligations pour une entreprise qui utilise une API d'IA générative dans son application métier ?

Tant que l'usage reste à risque limité, l'obligation principale est la transparence (art. 50) : informer que le contenu est généré par IA. Mais si l'application sert une finalité de l'annexe III (RH, crédit, santé), l'entreprise peut basculer en fournisseur de système à haut risque et devoir assurer gestion des risques, gouvernance des données et supervision humaine. L'usage détermine le régime.

Le marquage CE est-il obligatoire pour toutes les applications IA utilisant le cloud ?

Non. Le marquage CE ne concerne que les systèmes d'IA à haut risque au sens des annexes I et III du règlement. Une IA à risque limité ou minimal n'y est pas soumise. L'hébergement cloud n'a aucune incidence sur cette obligation : c'est la finalité du système, et non son infrastructure, qui déclenche ou non l'exigence de marquage CE.

Comment la qualification SecNumCloud aide-t-elle à respecter l'AI Act ?

SecNumCloud, la qualification de l'ANSSI, protège les données sensibles contre les accès non autorisés et les lois extraterritoriales, ce qui fournit une base probante solide pour la gouvernance et la localisation des données exigées par l'AI Act. Attention : elle sécurise le socle mais ne vaut pas conformité AI Act. Votre système d'IA reste à mettre en conformité indépendamment.

Quelle différence entre un « déployeur » et un « fournisseur » dans une solution SaaS intégrant de l'IA ?

Le fournisseur conçoit le système d'IA et le met sur le marché sous son nom ; l'éditeur SaaS qui intègre l'IA est généralement fournisseur de sa solution. Le déployeur est le client professionnel qui l'utilise sous sa propre autorité. Le déployeur peut toutefois devenir fournisseur s'il modifie substantiellement le système ou en change la finalité vers un usage à haut risque.

Quelles sanctions en cas de non-conformité aux règles de transparence des modèles GPAI ?

Le régime de sanctions de l'AI Act (art. 99) s'applique pleinement à partir du 2 août 2026 et prévoit des amendes administratives élevées, modulées selon la gravité et la taille de l'entreprise. Les manquements aux obligations GPAI et de transparence exposent les fournisseurs à des sanctions financières significatives. Le détail des montants et de leur graduation relève des dispositions dédiées du règlement.

La localisation géographique du serveur cloud influence-t-elle le statut de fournisseur au sens de l'AI Act ?

Non pour la qualification de rôle : être fournisseur ou déployeur dépend de ce que vous faites du système, pas de l'emplacement du serveur. En revanche, la localisation conditionne fortement la conformité pratique — transferts de données hors UE, exposition aux lois extraterritoriales, capacité à prouver la gouvernance des données. Un hébergement souverain simplifie donc la démonstration de conformité sans changer votre statut juridique.

Comment assurer une supervision humaine effective sur des systèmes d'IA tournant en continu dans le cloud ?

Il faut désigner des personnes compétentes, formées, dotées de l'autorité et des outils pour comprendre, interrompre ou contredire les sorties du système. Cela suppose des seuils d'alerte, une journalisation exploitable, des points de contrôle humains sur les décisions sensibles et une procédure d'escalade. Un système automatisé sans humain capable d'intervenir ne satisfait pas l'exigence de supervision de l'AI Act.

Quelles premières étapes pour auditer sa chaîne de valeur IA/cloud face aux nouvelles règles européennes ?

Commencez par cartographier tous les usages d'IA, y compris le Shadow AI, avec leurs données et modèles sous-jacents. Classez ensuite chaque usage par sa finalité pour repérer les zones à haut risque. Analysez les contrats CSP et éditeurs pour identifier les responsabilités que vous portez seul. Enfin, statuez sur les obligations déclenchées et le besoin éventuel d'un audit tiers.

Pour aller plus loin avec IAPRO

Vous ne savez pas si votre projet IA fait de vous un simple déployeur ou un fournisseur soumis au marquage CE ? C'est exactement ce que notre audit de chaîne de valeur IA/cloud clarifie, avant tout déploiement. IAPRO installe des solutions d'IA souveraines on-premise et documente votre conformité de bout en bout. Contactez-nous pour cadrer votre statut juridique et sécuriser votre architecture.

Liens utiles