La loi européenne sur l'IA est entrée en vigueur en août 2024, avec des dispositions mises en œuvre progressivement sur une période de deux à trois ans [1][2]. Jusqu'à présent, la plupart des discussions sur la conformité en entreprise se sont concentrées sur la question de savoir si un flux de travail relève ou non de la catégorie « à haut risque ». À la mi-2026, la discussion évolue vers une question plus pratique : étant donné que le flux de travail est dans le champ d'application, quelles architectures de déploiement permettent réellement de satisfaire les obligations du déployeur, et lesquelles ne le permettent pas discrètement ?

C'est cette seconde question qui fait que le déploiement sur site cesse d'être une préférence stylistique pour devenir un choix structurel.

Ce que la loi demande aux déployeurs d'IA à haut risque

La loi distingue entre le fournisseur d'un système d'IA et le déployeur de celui-ci [1]. Une banque utilisant une API LLM tierce pour évaluer des demandes de prêt est le déployeur, pas le fournisseur. Les déployeurs de systèmes à haut risque ont des obligations incluant : assurer une supervision humaine, surveiller le fonctionnement du système, conserver des journaux pendant une période appropriée, suspendre l'utilisation si le système présente un risque pour les droits fondamentaux, et démontrer ces capacités sur demande.

Plusieurs de ces obligations sont simples lorsque le déployeur contrôle l'exécution. L'obligation de « conserver des journaux pendant une période appropriée » est mécaniquement simple si l'inférence se fait sur un serveur appartenant au déployeur et que les journaux sont intégrés au SIEM du déployeur. L'obligation de « suspendre l'utilisation » est également triviale si le déployeur peut arrêter le modèle sur sa propre infrastructure.

Ces 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. La suspension de l'utilisation nécessite la coopération du fournisseur. La démonstration, en temps réel, des données ayant transité par le système nécessite de faire confiance au pipeline du fournisseur.

La place des API LLM cloud dans la réglementation

Rien de tout cela ne rend les API LLM cloud non conformes. Article par article, les fournisseurs et les déployeurs d'IA hébergée dans le cloud peuvent satisfaire aux obligations du Règlement. La friction est opérationnelle, non juridique : le déployeur doit assembler, auditer et démontrer la conformité à travers une frontière fournisseur, souvent pour des flux de travail exécutant des milliers d'inférences par jour.

L'indice longitudinal de l'IA de Stanford HAI a suivi le changement correspondant dans les dépenses des entreprises [3] : la croissance la plus forte entre 2023 et 2025 ne concernait pas l'IA générative à usage général, mais les outils de support — observabilité, gouvernance, journalisation des prompts, classification de contenu, détection de jailbreak. La majeure partie de ces dépenses vise à combler l'écart entre ce que les API LLM cloud exposent nativement et ce qu'un déployeur doit démontrer dans un contexte réglementaire.

Cet écart constitue l'avantage structurel d'exécuter l'inférence sur un matériel appartenant au déployeur. Chaque question « cela s'est-il produit ? » se réduit à une question à laquelle le déployeur peut répondre à partir de ses propres journaux.

Ce que l'on-premise ne vous offre pas gratuitement

Trois obligations pour les déployeurs issues du AI Act sont pas automatiquement satisfaits par un déploiement sur site, et il vaut la peine de les nommer explicitement :

  • Supervision humaine. La loi exige une surveillance significative de l'IA à haut risque, avec des humains capables d'interpréter les résultats et d'intervenir. Exécuter le modèle localement ne place pas un humain dans la boucle ; c'est la conception du flux de travail qui le fait.
  • Surveillance des dérives et des comportements dangereux. Le déployeur doit surveiller en continu le système. Le déploiement sur site rend le plomberie trivial (les données sont locales), mais la politique (« à quoi ressemble la dérive pour ce flux de travail ? ») doit encore être définie.
  • Obligations du fournisseur transmises. Lorsque le déploiement sur site est basé sur un modèle tiers (par exemple, un modèle à poids ouvert sous licence non commerciale, ou un modèle fournisseur livré sous forme binaire), le déployeur doit toujours afficher les divulgations requises par le fournisseur.

L'avantage structurel de l'on-prem réside dans la gestion des données et la démontrabilité, et non dans la politique. La politique doit être rédigée et appliquée indépendamment de l'emplacement du GPU.

Comment cela s'articule avec les juridictions des États-Unis, du Royaume-Uni et d'autres

Le règlement européen sur l'IA est le plus prescriptif parmi les principaux cadres. Le cadre de gestion des risques en IA du NIST américain [4] adopte une approche volontaire basée sur un cadre, et l'Observatoire des politiques en IA de l'OCDE [5] suit la manière dont les gouvernements nationaux hors UE convergent vers des principes globalement similaires (supervision basée sur 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 détermine l'architecture. Si un flux de travail doit satisfaire à la loi européenne sur l'IA pour les utilisateurs européens, ce même flux de travail ne contreviendra pas aux obligations des États-Unis, du Royaume-Uni, du Japon ou de Singapour s'il est conçu selon les exigences européennes. Concevoir le déploiement selon la norme la plus stricte — y compris la capacité du déployeur à justifier la gestion des données par requête — est ce qui fait de l'on-premise la solution par défaut structurellement plus simple pour l'IA d'entreprise en 2026.

À quoi ressemble un déploiement d'IA sur site prêt pour la conformité 2026

La forme que nous livrons — et que les examinateurs de conformité avec lesquels nous travaillons demandent — est la suivante :

  • Inférence locale chez le 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. Chaque action administrative est enregistrée avec horodatage + acteur ; aucun prompt ni réponse n'apparaît dans la ligne d'audit. La ligne d'audit constitue la preuve ; le contenu appartient au déployeur qui le conserve selon sa propre politique de rétention.
  • Identification via l'IdP du client. OIDC contre Microsoft Entra ID ou Google Workspace, avec les contrôles d'accès existants du déployeur appliqués sans changement.
  • Aucun locataire d'inférence exploité par un fournisseur. Software Tailor n'exploite pas le runtime du modèle ni ne reçoit de prompts, réponses ou documents clients sur ce chemin. L'identité de l'organisation, la licence, la politique, l'état du serveur, l'usage agrégé, les enregistrements d'audit et de support peuvent toujours utiliser un plan de contrôle fournisseur et doivent être évalués comme une dépendance distincte.

Cette dernière propriété d'inférence est celle que les API LLM cloud ne peuvent pas reproduire structurellement. Cela ne rend pas automatiquement un produit sur site conforme ni ne supprime la nécessité d'évaluer son plan de contrôle, ses voies de support, sa chaîne d'approvisionnement du modèle et les responsabilités opérationnelles du client.

Le contexte sur notre conception autour de cela dès le départ se trouve dans Pourquoi nous livrons l'IA sous forme de binaires installables, et non en SaaS cloud. Les fonctionnalités qui implémentent l'audit, l'identité et la surface politique résident dans AI Admin Console.

Références

  1. Commission européenne. « AI Act — Cadre réglementaire sur l'IA. » https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai. Consulté le 15-06-2026.
  2. Commission européenne. « Entrée en vigueur de l'AI Act. » https://digital-strategy.ec.europa.eu/. Consulté le 15-06-2026.
  3. Stanford HAI. « Rapport AI Index. » https://aiindex.stanford.edu/. Consulté le 15-06-2026.
  4. NIST. « Cadre de gestion des risques liés à l'IA (AI RMF 1.0). » https://www.nist.gov/itl/ai-risk-management-framework. Consulté le 15-06-2026.
  5. Observatoire des politiques d'IA de l'OCDE. « Politiques nationales en matière d'IA. » https://oecd.ai/. Consulté le 15-06-2026.