As enterprises roll out their first AI agents, they are also discovering a harder problem: how to govern the interactions between models, applications and data. A new software category, AI Gateways, is positioning itself as the control plane for these architectures. Like API Gateways two decades ago, this layer could reshape how CIOs build AI infrastructure — if it delivers on its promises.

The pattern echoes earlier shifts in enterprise IT. In the early 1990s, firewalls became the mandatory gateway between corporate networks and the internet. In the early 2000s, the rise of service-oriented architectures and microservices created demand for centralized control of application-to-application traffic, and API Gateways emerged to authenticate calls, enforce security policies and provide visibility. A decade later, cloud expansion drove the rise of modern IAM platforms, CASB, SASE and CNAPP tools to address new governance needs. Generative AI appears to be following the same trajectory.

The first phase of enterprise GenAI was centered on choosing a strong language model. The current phase is about managing a much more complex ecosystem: multiple models coexisting, AI agents making decisions, and far more dynamic interactions with the information system.

The shift from single-model to multi-model is already visible in production. Between 2023 and 2024, most experiments relied on one vendor and one API call path. By 2026, the picture has changed sharply. According to Vercel’s analysis of production usage, the share of teams running five models or more rose from 29% to 37% in one year. That is a structural change, not a marginal adjustment.

A modern assistant may now combine a proprietary model for text generation, a local open-source model for confidential processing, a specialized model for document analysis, and a multimodal engine for image or video. Three forces are driving this diversification. Economically, token pricing varies widely across vendors, and the race to the bottom is pushing CIOs to optimize rather than depend on a single supplier; several commercial gateways — Vercel, OpenRouter, Cloudflare and LiteLLM — removed token margins in 2026, shifting competition toward reliability and governance. Regulators are also pushing firms to retain control over sensitive processing or favor providers with stronger data-localization guarantees as the AI Act comes into force progressively. Finally, operational reliability is now a real concern: Vercel cites data showing that major LLM providers each accumulated roughly 20 incidents and nearly 180 hours of downtime in December 2025 alone, strengthening the case for multi-vendor setups and automatic failover.

That creates a new administrative challenge: how do you manage an environment where hundreds of applications use multiple models at once, without multiplying API keys and one-off integrations?

AI agents make the problem more acute. A chatbot answers a question; an agent can plan and execute a sequence of actions — query a knowledge base, interrogate an ERP, create an ITSM ticket, send an email, then hand the result to another agent. It does not just respond; it acts. That changes enterprise traffic patterns, because interactions are no longer limited to known applications but involve components that can choose tools dynamically based on context.

The Model Context Protocol (MCP) is standardizing how models access external tools and now underpins much of this exchange. But its rapid adoption also expands the attack surface, since every MCP connector can become a potential entry point into an internal system. In many companies, each application still talks directly to the model chosen by its development team. That works when the number of projects is small, but it becomes unmanageable once dozens of applications use multiple providers, each with its own API keys, security policies, consumption limits, logging requirements, version changes and compliance rules. As the number of agents grows, so does the number of interactions — and the familiar risk of uncontrolled point-to-point sprawl returns.

AI Gateways are emerging as the answer. Positioned as a proxy between applications and model providers such as OpenAI, Anthropic, Google, Azure or self-hosted open-source models, they expose a single entry point and can add multi-model routing, automatic failover, semantic caching to reduce cost and latency on similar requests, quotas and budgets by team or user, token-level logging, and security functions such as personal-data masking or prompt-injection detection.

The market has moved quickly in 2026, but with distinct approaches. LiteLLM is an open-source, self-hosted proxy supporting more than 100 providers, attractive for organizations wanting full data control, though it comes with high internal operational overhead and a supply-chain vulnerability identified in early 2026. Portkey focuses on governance, observability and advanced security for highly regulated environments, but its May 2026 acquisition by Palo Alto Networks means its product direction and pricing bear watching. Cloudflare and Vercel offer native integration into their existing edge infrastructure with very little deployment effort, but that also creates strong ecosystem lock-in. Kong AI Gateway extends an established enterprise API Gateway to unify traditional REST traffic, AI and MCP, though it can be heavy if the company is not already using Kong. TrueFoundry, Bifrost and Helicone are more specialized pure-plays, targeting niches such as data sovereignty, ultra-low latency and observability, but their smaller size makes consolidation or acquisition likely.

Analysts broadly support the category. Gartner’s 2025 and 2026 research — including its Market Guide for AI Gateways and updated Market Overview — positions the layer as a future component of enterprise AI architectures, responsible for managing connections to AI services, enforcing security policies, distributing requests across models and improving cost visibility. Gartner places AI Gateways within its broader AI TRiSM framework (Trust, Risk and Security Management), which it estimated at about $3.1 billion in 2025, with projected annual growth of around 35% through 2030. That figure should be treated as an analyst order of magnitude rather than a certainty, especially as forecasts are revised while the market consolidates.

The NIST AI Risk Management Framework points in the same direction, even if it does not use the term AI Gateway: it emphasizes governance, traceability and continuous monitoring across the AI lifecycle. The Cloud Security Alliance takes a similar view, arguing that AI governance can no longer be handled only at the application layer.

Regulation strengthens the case, though the timeline shifted in 2026. The Digital Omnibus package, definitively adopted at the end of June 2026, pushed most obligations for high-risk systems under Annex III — including hiring, credit, education, justice and biometrics — to 2 December 2027. However, most transparency obligations under Article 50 remain in force from 2 August 2026: users must be informed when they are interacting with AI, and AI-generated or AI-modified content must be identified. For systems that remain under the high-risk regime, Article 12 requires automatic, tamper-proof event logging with minimum retention of six months, or 24 months for biometrics, while Article 14 requires effective human oversight. The AI Act also states in recitals 99 and 100 that in an AI-agent chain, compliance obligations extend to each agent performing a high-risk function. Those are exactly the capabilities — centralized logging, per-call traceability and human control points — that an AI Gateway can industrialize across dozens of applications instead of forcing each project team to rebuild them. The delay removes short-term urgency, but not the need to prepare an architecture capable of producing compliance evidence.

The concept still has clear limits. The market is young and unstable: Portkey’s acquisition, LiteLLM’s security incident and the more than 160 vendors listed by some specialized directories point to rapid consolidation rather than maturity, meaning any CIO adopting a gateway today is also betting on the vendor’s longevity. Centralizing all AI traffic in one layer creates a new single point of failure: if the gateway goes down, all enterprise AI applications stop even if the underlying models are healthy. There is also a latency penalty, though usually modest — independent comparisons put it at a few milliseconds to a few tens of milliseconds, negligible compared with multi-second model calls unless the implementation is poor. The boundary with existing infrastructure is also blurry, since many claimed functions — authentication, quotas, logs — can already be handled by a traditional API Gateway, raising the question of whether a dedicated AI layer is really needed or whether an extension of current infrastructure is enough. Kong and Zuplo, which blend both worlds, show that the line between API Gateway and AI Gateway is still unsettled. Finally, governance can become superficial: a gateway can log and control traffic, but it does not by itself solve the root causes of enterprise AI incidents. Gartner estimates that a large majority of unauthorized AI transactions come from internal misuse rather than malicious attacks, which is an organizational problem as much as a technical one.

For CIOs, the lesson is familiar. Firewalls, API Gateways and CASB layers, once adopted, are hard to remove. As organizations deploy multiple models and begin experimenting with agents, the question is no longer whether centralized governance will be needed, but when to introduce it and how tightly to couple it to existing infrastructure. A sensible starting point is to map current and planned AI use cases, assess whether the existing API Gateway can be extended in the short term, and only commit to a dedicated vendor after evaluating its security model, financial durability and the degree of lock-in it introduces. In a market consolidating as quickly as it is growing, vendor prudence matters almost as much as the decision to adopt the layer itself.

Les entreprises déploient leurs premiers agents et découvrent aussi comment gouverner les interactions entre les modèles, les applications et les données ?

Une nouvelle catégorie de logiciels, les AI Gateways, ambitionne de devenir le point de contrôle de ces architectures. À l’image des API Gateways il y a vingt ans, cette couche pourrait redéfinir la manière dont les DSI construiront leurs infrastructures d’intelligence artificielle. A condition qu’elle tienne ses promesses.

L’histoire des systèmes d’information est jalonnée de ruptures technologiques qui ont progressivement fait apparaître de nouvelles couches d’infrastructure.

Au début des années 1990, la priorité était de connecter les réseaux tout en les protégeant : les pare-feu sont devenus le point de passage obligé entre l’entreprise et Internet.

Au début des années 2000, la généralisation des architectures orientées services puis des microservices a fait émerger une autre nécessité : contrôler les échanges entre applications. Les API Gateway se sont imposées pour authentifier les appels, appliquer des politiques de sécurité et fournir une visibilité centralisée.

Une décennie plus tard, l’explosion du cloud a donné naissance aux plateformes IAM modernes, aux CASB (Cloud Access Security Broker) aux solutions SASE et aux plateformes CNAPP (Cloud-Native Application Protection Platform, des outils de sécurisation des applications cloud) pour répondre à de nouveaux besoins de gouvernance.

L’IA générative semble suivre le même chemin. Après une première phase centrée sur le choix d’un modèle de langage performant, les entreprises découvrent qu’elles doivent désormais administrer un écosystème où plusieurs modèles coexistent, où des agents IA prennent des décisions, et où les interactions avec le système d’information deviennent plus nombreuses et plus dynamiques.

Du mono-modèle au multi-modèle

Entre 2023 et 2024, la plupart des expérimentations reposaient sur un seul fournisseur : une application appelait un modèle via une API, point final. Cette architecture reste simple.

En 2026, le changement d’échelle est net. Selon une analyse de Vercel portant sur les usages en production, la part des équipes exploitant cinq modèles ou plus est passée de 29 % à 37 % en un an. Un basculement structurel plutôt qu’un ajustement marginal.

Un assistant bureautique peut désormais mobiliser un modèle propriétaire pour la génération de texte, un modèle open source exécuté localement pour des traitements confidentiels, un modèle spécialisé pour l’analyse documentaire et un moteur multimodal pour l’image ou la vidéo.

Cette diversification répond à trois logiques :

Économique : les tarifs varient fortement d’un fournisseur à l’autre, et le « race to the bottom » sur le prix au token pousse les DSI à arbitrer plutôt qu’à dépendre d’un seul acteur. Plusieurs gateways commerciales (Vercel, OpenRouter, Cloudflare, LiteLLM) ont d’ailleurs supprimé toute marge sur les tokens en 2026, déplaçant la concurrence vers la fiabilité et la gouvernance.

Réglementaire : avec l’entrée en application progressive de l’AI Act, certaines entreprises veulent conserver la maîtrise de traitements sensibles ou privilégier des fournisseurs offrant davantage de garanties sur la localisation des données.

Fiabilité opérationnelle : les incidents chez les grands fournisseurs de modèles ne sont plus anecdotiques. Selon des données citées par Vercel, les principaux fournisseurs de LLM ont chacun cumulé une vingtaine d’incidents et près de 180 heures d’indisponibilité sur le seul mois de décembre 2025. Un argument concret en faveur du multi-fournisseur et du failover automatique.

Cette évolution fait apparaître une difficulté nouvelle : comment administrer un environnement où plusieurs modèles sont utilisés simultanément par des centaines d’applications, sans multiplier les clés d’API et les intégrations ad hoc ?

Les agents IA changent la nature du système d’information

La généralisation des agents constitue un second facteur de rupture.

Un chatbot traditionnel répond à une question. Un agent peut planifier une série d’actions : consulter une base documentaire, interroger un ERP, créer un ticket dans un outil ITSM, envoyer un courriel, puis transmettre le résultat à un autre agent. Il ne produit plus seulement une réponse : il agit.

Pour les équipes d’architecture, cela change la nature des flux. Les échanges ne s’effectuent plus uniquement entre applications connues : ils impliquent des composants capables de choisir eux-mêmes quels outils utiliser selon le contexte.

Le protocole MCP (Model Context Protocol), qui standardise la façon dont un modèle accède à des outils externes et structure une bonne partie de ces échanges. Cependant, son adoption rapide crée aussi une nouvelle surface d’exposition, puisque chaque connecteur MCP est potentiellement une porte d’entrée vers un système interne.

Dans de nombreuses entreprises, chaque application dialogue encore directement avec le modèle retenu par son équipe de développement. Cette approche fonctionne tant que les projets restent peu nombreux mais elle devient difficile à maintenir dès que plusieurs dizaines d’applications utilisent plusieurs fournisseurs. Chaque équipe doit alors gérer séparément les clés d’API, les politiques de sécurité, les limites de consommation, la journalisation, les changements de version des modèles et les règles de conformité propres à chaque fournisseur.

Plus le nombre d’agents augmente, plus le nombre d’interactions explose, avec un risque bien connu : la multiplication incontrôlée de connexions point à point, que l’histoire des systèmes d’information a déjà vu se reproduire à chaque rupture technologique.

Une nouvelle couche apparaît : l’AI Gateway

Concrètement, une AI Gateway se place comme un proxy entre les applications et les fournisseurs de modèles (OpenAI, Anthropic, Google, Azure, modèles open source auto-hébergés).

Elle expose un point d’entrée unique et ajoute, selon les offres, du routage multi-modèle, du failover automatique en cas de panne d’un fournisseur, du cache sémantique pour réduire coûts et latence sur des requêtes similaires, des quotas et budgets par équipe ou par utilisateur, de la journalisation au niveau du token, ainsi que des fonctions de sécurité comme le masquage de données personnelles ou la détection de tentatives d’injection de prompt.

Le marché s’est structuré très vite en 2026, avec des positionnements différenciés :

Acteur

Positionnement

Point d’attention

LiteLLM

Proxy Open Source auto-hébergé supportant +100 fournisseurs. Idéal pour garder le contrôle total des données.

Charge d’exploitation interne élevée ; vulnérabilité supply chain identifiée début 2026.

Portkey

Gouvernance, observabilité et sécurité avancées pour environnements très réglementés.

Racheté par Palo Alto Networks (mai 2026) : évolution produit et politique tarifaire à suivre.

Cloudflare / Vercel

Integration native à l’infrastructure edge existante avec très peu d’effort de déploiement.

Couplage fort à leur écosystème cloud respectif (risque de vendor lock-in).

Kong AI Gateway

Extension d’une API Gateway entreprise établie, unifiant trafic REST classique, IA et protocole MCP.

Infrastructures parfois lourdes si l’entreprise ne possède pas déjà l’écosystème Kong.

TrueFoundry / Bifrost / Helicone

Pure-players spécialisés sur des niches (souveraineté des données, ultra-basse latence, observabilité).

Acteurs de taille plus modeste avec risque fort de consolidation ou de rachat à court terme.

Cette diversité montre que le terme « AI Gateway » recouvre encore des réalités différentes selon l’éditeur : certains sont d’abord des routeurs de coûts, d’autres des plateformes de gouvernance, d’autres des extensions d’API Gateway existantes.

Ce qu’en disent les analystes

Gartner a publié en 2025 et 2026 plusieurs travaux dédiés (Market Guide for AI Gateways et  Market Overview actualisé en 2026) qui positionnent cette couche comme un composant des futures architectures d’IA d’entreprise, chargé de gérer les connexions vers les services d’IA, d’appliquer des politiques de sécurité, de répartir les requêtes entre plusieurs modèles et d’améliorer la visibilité sur les coûts.

Le cabinet inscrit plus largement l’AI Gateway dans son cadre AI TRiSM (Trust, Risk and Security Management), dont il estimait le marché à environ 3,1 milliards $en 2025, avec une croissance annuelle projetée de l’ordre de 35 % jusqu’en 2030. Un chiffre à prendre comme un ordre de grandeur d’analyste plutôt qu’une certitude, la firme elle-même révisant régulièrement ses prévisions à mesure que le marché se consolide.

Le NIST AI Risk Management Framework converge sur le fond. Sans employer le terme « AI Gateway », il insiste sur la nécessité de mécanismes de gouvernance, de traçabilité et de surveillance continue tout au long du cycle de vie des systèmes d’IA. Des fonctions qu’une gateway peut techniquement porter, sans que le référentiel ne prescrive cette architecture en particulier.

La Cloud Security Alliance défend une lecture proche, estimant que la gouvernance de l’IA ne peut plus être traitée uniquement au niveau applicatif.

Ce que l’AI Act rend concrètement nécessaire

L’argument réglementaire mérite d’être précisé, car le calendrier a changé courant 2026.

Le paquet Digital Omnibus, adopté définitivement fin juin 2026, a reporté au 2 décembre 2027 la plupart des obligations pesant sur les systèmes à haut risque de l’annexe III (recrutement, crédit, éducation, justice, biométrie). Reste en vigueur au 2 août 2026 l’essentiel des obligations de transparence de l’article 50 : informer les utilisateurs qu’ils interagissent avec une IA, et identifier les contenus générés ou modifiés par IA.

Pour les systèmes qui resteront soumis au régime haut risque, l’article 12 impose une journalisation automatique et infalsifiable des événements, avec une conservation minimale de six mois (vingt-quatre mois pour la biométrie), et l’article 14 exige une supervision humaine effective.

Ce sont précisément les fonctions ( journalisation centralisée, traçabilité au niveau de chaque appel et points de contrôle humain ) qu’une AI Gateway peut industrialiser à l’échelle de dizaines d’applications, plutôt que de les faire reconstruire par chaque équipe projet. Le règlement précise aussi, dans ses considérants 99 et 100, que dans une chaîne d’agents IA, l’obligation de conformité s’étend à chaque agent exécutant une fonction à haut risque. Un argument de poids pour centraliser la gouvernance plutôt que de la disperser.

Le report ne change donc pas la logique de fond : il retire simplement l’urgence à très court terme, sans annuler la nécessité d’anticiper une architecture capable de produire ces preuves de conformité.

Les limites du concept

Cette convergence d’analyses ne doit pas masquer les zones d’incertitude.

Un marché encore jeune et instable. Le rachat de Portkey par Palo Alto Networks, l’incident de sécurité touchant LiteLLM et le nombre élevé d’éditeurs recensés (plus de 160 selon certains annuaires spécialisés) suggèrent une consolidation rapide plutôt qu’un marché mature. Une DSI qui adopte aujourd’hui une gateway prend un pari sur la pérennité de son éditeur.

Un nouveau point de défaillance unique. Concentrer tout le trafic IA sur une seule couche crée mécaniquement un single point of failure : si la gateway tombe, c’est l’ensemble des applications IA de l’entreprise qui s’arrête, même si les modèles sous-jacents fonctionnent normalement.

Une latence ajoutée, mais généralement marginale. Plusieurs comparatifs indépendants estiment le surcoût d’une gateway bien opérée à quelques millisecondes à quelques dizaines de millisecondes. Ceci est négligeable face à un appel de modèle qui dure plusieurs secondes, sauf en cas de mauvaise implémentation.

Une frontière floue avec l’existant. Une partie des fonctions revendiquées (authentification, quotas, logs) peut aussi être portée par une API Gateway classique déjà en place, ce qui pose la question : faut-il une brique dédiée ou une extension de l’infrastructure API existante ? Les offres de type Kong ou Zuplo, qui fusionnent les deux mondes, illustrent que la frontière entre « API Gateway » et « AI Gateway » n’est pas encore stabilisée.

Le risque de gouvernance en façade. Une gateway journalise et contrôle les flux, mais elle ne résout pas à elle seule les causes profondes des incidents d’IA en entreprise. Gartner estime qu’une large majorité des transactions IA non autorisées proviennent de mauvais usages internes plutôt que d’attaques malveillantes. Un problème davantage organisationnel que technique, qu’un outil ne suffit pas à traiter.

Ce que cela signifie pour les DSI

L’histoire des pare-feu, des API Gateway puis des CASB montre que ces couches d’infrastructure, une fois qu’elles s’imposent, deviennent difficiles à retirer.

Pour une DSI qui déploie aujourd’hui plusieurs modèles et commence à expérimenter des agents, la question n’est plus de savoir si une gouvernance centralisée sera nécessaire, mais quand l’introduire et avec quel degré de couplage à l’infrastructure existante.

Un point de départ raisonnable consiste à cartographier les usages IA actuels et à venir, à évaluer si une extension de l’API Gateway déjà en place suffit à court terme, et à ne s’engager sur un éditeur dédié qu’après avoir mesuré son modèle de sécurité, sa pérennité financière et le degré de lock-in qu’il introduit.

Dans un marché qui se consolide aussi vite qu’il grossit, la prudence sur le choix du fournisseur compte au moins autant que la décision d’adopter la brique elle-même.

Sources :

> Gartner (Market Guide for AI Gateways, 2025 ; Market Overview for AI Gateways, 2026 ; Market Guide for AI Trust, Risk and Security Management, 2025

> NIST AI Risk Management Framework 1.0

> Cloud Security Alliance

> Règlement (UE) 2024/1689 (AI Act)

> Paquet Digital Omnibus adopté fin juin 2026

The post AI Gateway : la prochaine bataille des infrastructures IA appeared first on Silicon.fr.