EU AI Act en 2026 : ce que le déploiement on-prem change à la conformité
Les obligations du déployeur pour les systèmes à haut risque issues de l'EU AI Act s'appliquent progressivement tout au long de 2026. Le déploiement on-prem n'élude pas la réglementation — mais il change celles des obligations qui sont concrètement satisfiables, et celles que le SaaS cloud ne peut tout simplement pas satisfaire.
L'EU AI Act est entré en vigueur en août 2024, avec des dispositions échelonnées sur une fenêtre de deux à trois ans [1][2]. Jusqu'ici, la plupart des conversations de conformité en entreprise ont porté sur la question de savoir si un workflow entre, ou non, dans la catégorie « haut risque ». À mi-2026, la conversation se déplace vers une question plus opérationnelle : étant donné que le workflow est dans le périmètre, quelles architectures de déploiement permettent réellement de satisfaire aux obligations du déployeur, et lesquelles ne le permettent pas, en silence ?
Cette seconde question est le point où le déploiement on-premises cesse d'être une préférence stylistique et devient un ajustement structurel.
Ce que l'Act demande aux déployeurs d'IA à haut risque de faire
L'Act distingue le fournisseur d'un système d'IA et son déployeur [1]. Une banque utilisant une API LLM tierce pour noter des demandes de prêt est le déployeur, pas le fournisseur. Les déployeurs de systèmes à haut risque portent des obligations qui incluent : assurer la supervision humaine, surveiller le fonctionnement du système, conserver les journaux pendant une durée appropriée, suspendre l'usage si le système présente un risque pour les droits fondamentaux et démontrer ces dispositifs sur demande.
Plusieurs de ces obligations sont simples à satisfaire lorsque le déployeur maîtrise le runtime. L'obligation de « conserver les journaux pendant une durée appropriée » est mécaniquement triviale si l'inférence se produit sur un serveur que le déployeur possède et que les journaux atterrissent dans le SIEM du déployeur. L'obligation de « suspendre l'usage » est tout aussi triviale si le déployeur peut éteindre le modèle sur sa propre infrastructure.
Les mêmes obligations deviennent plus difficiles lorsque l'inférence s'exécute sur une API LLM cloud que le déployeur n'opère pas. Les journaux que le déployeur peut produire sont limités à ce que le fournisseur expose. Suspendre l'usage requiert la coopération du fournisseur. Démontrer, de manière contemporaine, quelles données ont transité par le système requiert de faire confiance au pipeline du fournisseur.
Où se situent les API LLM cloud dans la réglementation
Rien de cela ne rend les API LLM cloud non conformes. Article par article, fournisseurs et déployeurs d'IA hébergée dans le cloud peuvent satisfaire aux obligations de l'Act. La friction est opérationnelle, pas juridique : le déployeur doit assembler, auditer et démontrer la conformité à travers une frontière fournisseur, souvent pour des workflows qui exécutent des milliers d'inférences par jour.
L'AI Index longitudinal de Stanford HAI a suivi la dérive correspondante des dépenses d'entreprise [3] : la croissance la plus marquée sur la période 2023-2025 ne portait pas sur l'IA générative à usage général, mais sur l'outillage qui la soutient — observabilité, gouvernance, journalisation des prompts, classification de contenu, détection de jailbreak. La majeure partie de ces dépenses existe pour combler l'écart entre ce que les API LLM cloud exposent nativement et ce qu'un déployeur doit pouvoir démontrer dans un contexte réglementaire.
Cet écart est l'avantage structurel du fait d'exécuter l'inférence sur du matériel que le déployeur possède. Chaque question « est-ce que cela a eu lieu ? » se réduit à une question que le déployeur peut résoudre à partir de ses propres journaux.
Ce que le on-prem ne vous offre pas gratuitement
Trois obligations du déployeur issues de l'AI Act ne sont pas automatiquement satisfaites par un déploiement on-prem, et il est utile de les nommer explicitement :
- Supervision humaine. L'Act exige une supervision significative de l'IA à haut risque, avec des humains capables d'interpréter les sorties et d'intervenir. Exécuter le modèle localement ne place pas un humain dans la boucle ; c'est la conception du workflow qui le fait.
- Surveillance de la dérive et des comportements dangereux. Le déployeur doit surveiller le système en continu. Le déploiement on-prem rend la plomberie triviale (les données sont locales), mais la politique (« à quoi ressemble une dérive pour ce workflow ? ») doit encore être définie.
- Obligations du fournisseur reportées. Lorsque le déploiement on-prem repose sur un modèle tiers (par exemple un modèle à poids ouverts sous licence non commerciale, ou un modèle fournisseur livré sous forme de binaire), le déployeur doit néanmoins relayer les divulgations exigées du fournisseur.
L'avantage structurel du on-prem porte sur les axes de gestion des données et de démontrabilité, pas sur la politique. La politique doit être écrite et appliquée, où que le GPU se trouve.
Comment cela s'articule avec les États-Unis, le Royaume-Uni et d'autres juridictions
L'EU AI Act est le plus prescriptif des grands cadres. Le NIST AI RMF américain [4] adopte une approche volontaire et fondée sur un cadre, et l'AI Policy Observatory de l'OECD [5] suit la manière dont les gouvernements nationaux hors UE convergent vers des principes globalement similaires (supervision par les risques, obligations de transparence, règles de gestion des données).
Pour un déployeur multinational, l'effet pratique est que la juridiction la plus stricte fixe l'architecture. Si un workflow doit satisfaire à l'EU AI Act pour des utilisateurs européens, le même workflow ne manquera pas aux obligations américaines, britanniques, japonaises ou singapouriennes s'il est conçu au niveau de la barre européenne. Concevoir le déploiement à la barre la plus stricte — y compris la capacité du déployeur à démontrer la gestion des données par requête — est ce qui fait du on-prem le défaut structurellement plus simple dans l'IA d'entreprise en 2026.
À quoi ressemble un déploiement d'IA on-prem prêt pour la conformité 2026
La forme que nous livrons — et la forme que demandent les évaluateurs conformité avec qui nous travaillons — est la suivante :
- Inférence locale au client. Soit sur l'appareil de l'utilisateur, soit sur un serveur exploité par le client. Aucun prompt ne quitte le périmètre.
- Journaux d'audit sans contenu. Toute action administrative est journalisée avec horodatage et acteur ; aucun prompt ni réponse n'apparaît dans la ligne d'audit. La ligne d'audit constitue la preuve ; le contenu reste à la main du déployeur, conservé selon sa propre politique de rétention.
- Identité via l'IdP du client. OIDC adossé à Microsoft Entra ID ou Google Workspace, les contrôles d'accès existants du déployeur s'appliquant sans changement.
- Pas de tenant côté fournisseur. Le fournisseur (nous) n'exploite pas le runtime, ne voit pas les données et n'est pas un point de défaillance pour la posture de conformité du déployeur.
Cette dernière propriété est celle que les API LLM cloud ne peuvent structurellement pas répliquer — et c'est la raison pour laquelle le déploiement on-prem est le schéma dominant dans la part « entreprise réglementée » du marché en 2026.
Le contexte sur la manière dont nous avons bâti notre offre autour de ce principe dès l'origine figure dans Pourquoi nous livrons l'IA sous forme de binaires installables, et non en SaaS cloud. Les capacités qui implémentent l'audit, l'identité et la surface de politique vivent dans AI Admin Console.
Références
- Commission européenne. « AI Act — Regulatory framework on AI. » digital-strategy.ec.europa.eu. Consulté le 2026-06-15.
- Commission européenne. « AI Act enters into force. » digital-strategy.ec.europa.eu. Consulté le 2026-06-15.
- Stanford HAI. « AI Index Report. » aiindex.stanford.edu. Consulté le 2026-06-15.
- NIST. « AI Risk Management Framework (AI RMF 1.0). » nist.gov/itl/ai-risk-management-framework. Consulté le 2026-06-15.
- OECD AI Policy Observatory. « National AI policies. » oecd.ai. Consulté le 2026-06-15.
Articles connexes
- Le basculement du cloud-first vers le residency-first dans les achats d'IA en entreprise
- OECD AI Policy Observatory : ce qui a changé sur les douze derniers mois
- AI Admin Console : ce que fait réellement chacune des six capacités
- Journaux d'audit sans contenu : comment nous prouvons ce que le modèle a fait sans conserver les prompts
- Pourquoi les déploiements d'IA on-prem s'enlisent en phase d'achats (et le cadrage qui débloque la situation)
- Pourquoi nous livrons l'IA sous forme de binaires installables, et non en SaaS cloud
- Tous les articles →
Déroulez les obligations du déployeur sur une charge de travail réelle.
Un pilote gratuit d'une semaine fait passer l'équipe conformité du client en revue des obligations du déployeur face à un véritable travail, sur de l'inférence locale, avec l'IdP et la piste d'audit du client.