Gouvernance de l'IA en entreprise : les quatre questions d'un CIO
Chaque revue de direction des dépenses d'IA se ramène à quatre questions. Chaque réponse ici renvoie à un mécanisme livré, vérifiable — pas à une feuille de route.
Accorder l'accès aux modèles est facile ; le gouverner ne l'est pas. Les quatre questions ci-dessous décident si un programme d'IA passe son premier audit.
Qui utilise quel modèle, et combien ?
Chaque requête porte une clé, un groupe de clés et un modèle. GateLLM enregistre les tokens d'entrée, de sortie et de cache par requête à la minute, et expose des séries quotidiennes et mensuelles par clé, groupe et modèle. Le contrôle d'admission décide quels clients peuvent se connecter, selon l'en-tête de requête.
- •Usage et coûts se décomposent par personne, clé, groupe de clés et modèle — sans reconstruire de journaux.
- •Le contrôle d'admission filtre par User-Agent aux niveaux global, groupe et clé.
- •Les enregistrements par requête conservent l'identifiant nécessaire pour tracer un appel de bout en bout.
Combien cela coûte, et qui paie ?
La dépense est mesurée sur une grille tarifaire qui vous appartient, pas sur un prix de liste. Épinglez vos prix négociés, étiquetez les appels pour la refacturation, exportez des rapports par fenêtre et fixez des quotas quotidiens ou mensuels qui rejettent les requêtes quand le budget est épuisé. GateLLM n'ajoute aucune marge sur les tokens.
- •Des instantanés de grille par fenêtre gardent un ancien rapport reproductible.
- •La refacturation par étiquette transforme la dépense d'IA en registre imputable.
- •Les quotas quotidiens et mensuels renvoient 429 au plafond : un agent emballé s'arrête au montant que vous avez choisi.
Les données sont-elles sorties du réseau, et pouvons-nous le prouver ?
Vous exploitez la passerelle : le trafic des prompts et des réponses ne passe jamais par nous. En BYOK, les clés des fournisseurs ne vivent qu'en mémoire de la passerelle. Identifiants et données personnelles sont détectés sur le chemin de la requête et peuvent être journalisés, masqués ou bloqués selon la portée ; les corps stockés sont masqués à chaque point de sortie.
- •Les requêtes ne vont qu'aux points d'entrée de modèles configurés — y compris des amonts vLLM ou Ollama auto-hébergés.
- •Les journaux de requêtes sont désactivés par défaut ; la consultation brute est réservée aux administrateurs et auditée.
- •SSO via OIDC ou SAML, provisionnement SCIM, clés et quotas par locataire.
Si un fournisseur tombe ou si nous changeons de modèle, combien de code change ?
Un 5xx ou un délai dépassé est réessayé chez un autre fournisseur sans toucher au code applicatif. Quatre familles de protocoles de chat se traduisent dans les deux sens, donc un client garde son SDK. L'identité du modèle est mappée dans la passerelle — par clé d'accès, par en-tête ou par règle générique — et les métadonnées de capacité viennent d'un registre.
- •Repli entre fournisseurs sur 5xx ou délai dépassé, sans changement côté client.
- •Listes d'autorisation en entrée et mappages génériques gardent un nom de modèle stable quand le backend change.
- •Les métadonnées de capacité viennent d'un registre : la dérive des modèles ne demande pas de release.