Un SLA de passerelle IA peut sembler simple jusqu'au premier incident de modèle. Un acheteur voit un pourcentage de disponibilité, une adresse de support et une promesse que la passerelle achemine les requêtes. L'équipe de production doit encore répondre à des questions plus difficiles : quel point de terminaison est couvert, quel fournisseur en amont a échoué, si le repli a modifié le contrat du modèle, quelles preuves le support nécessite et si une solution est automatique.
Utilisez cette checklist de SLA de passerelle IA pour transformer le langage du fournisseur en un dossier de preuves. L'objectif n'est pas de négocier à coups de slogans. L'objectif est de savoir ce que le SLA couvre, ce qu'il exclut, comment le routage et le repli sont prouvés, et ce que votre équipe devrait examiner avant le renouvellement.
Pour Flatkey spécifiquement, le Contrat de Niveau de Service public, vérifié le 6 juillet 2026, indique que le périmètre couvert inclut le tableau de bord hébergé, la passerelle API, le routage, la mesure et les services de compte que Flatkey opère directement. Il vise une disponibilité mensuelle de 99,5 % pour les points de terminaison couverts, exclut les pannes des fournisseurs de modèles d'IA tiers et les défaillances côté fournisseur, demande aux clients d'envoyer les ID de requête, les horodatages, les erreurs, le point de terminaison, l'e-mail du compte et un résumé de l'impact pour le support, et ne crée pas de crédits automatiques sauf si un accord écrit séparé en dispose autrement. Considérez cela comme la preuve de départ, puis vérifiez votre compte, votre classe de trafic, votre politique de repli et votre processus de support avant que le trafic de production n'en dépende.
Réponse rapide : questions sur le SLA de la passerelle IA
| Domaine du SLA | À demander avant de signer ou de renouveler | Preuves à conserver | |---|---|---| | Service couvert | Quelles fonctions de tableau de bord, de passerelle API, de routage, de mesure, de compte et de support sont couvertes ? | URL du SLA actuel, calendrier du contrat, liste des points de terminaison et captures d'écran datées. | | Calcul de la disponibilité | La disponibilité est-elle mesurée par la surveillance du fournisseur, les sondes du client, le statut public ou un rapport contractuel ? | Rapport de disponibilité mensuel, journal des sondes, export des incidents et méthode de calcul. | | Fournisseurs tiers | Les pannes de modèles en amont, les limites de débit, les restrictions régionales, les changements de modèles et les défaillances côté fournisseur sont-ils exclus ? | Liens vers le statut du fournisseur, corps des erreurs de modèle, journaux de routage et texte d'exclusion du fournisseur. | | Routage | Quel modèle, fournisseur, compte, région ou groupe a été tenté en premier ? | ID de la requête, route sélectionnée, ID du modèle, famille de points de terminaison, propriétaire de la clé et horodatage. | | Repli | Quelles erreurs déclenchent une nouvelle tentative, un repli, une mise en file d'attente ou un comportement de type fail-closed ? | Politique de repli, trace de la route, nombre de tentatives, modèle final et preuve de la sortie acceptée. | | Support | Quelles preuves doivent être envoyées et quel chemin de gravité s'applique ? | Modèle de ticket, ID des requêtes, point de terminaison, horodatages, erreurs, résumé de l'impact et chronologie des réponses. | | Recours | Les crédits de service sont-ils automatiques, au cas par cas ou uniquement dans un accord écrit séparé ? | Clause de recours du SLA, avenant au contrat, demande de crédit et approbation financière. | | Renouvellement | Que faut-il examiner avant la prochaine période ? | Registre des incidents, exceptions de repli, résultats du support, événements de quota, changements de prix et approbations de routes. |
La réponse pratique concernant le SLA d'une passerelle IA est la suivante : séparez la responsabilité de la passerelle de celle du fournisseur en amont, puis testez la route. Si l'acheteur ne peut pas inspecter la route, le repli, le ticket de support et les preuves de disponibilité mensuelle, le SLA n'est pas prêt pour la gouvernance de la production.
Séparer la disponibilité de la passerelle de la disponibilité du modèle en amont
La première question concernant le SLA d'une passerelle IA est de savoir si le fournisseur promet la passerelle, le modèle en amont ou le résultat final pour l'utilisateur. Ce sont des couches différentes.
Le SLA public actuel de Flatkey rend cette séparation explicite : les services couverts opérés par Flatkey sont dans le périmètre, tandis que les fournisseurs de modèles tiers, les pannes de fournisseurs, les limites de débit des fournisseurs, les changements de politique, les restrictions régionales, le comportement des modèles et les défaillances côté fournisseur sont en dehors du SLA. C'est assez courant dans l'achat de passerelles pour que le service des achats ne traite jamais un simple pourcentage de disponibilité comme signifiant que « toutes les requêtes de modèle réussiront ».
Utilisez cette répartition dans le dossier de preuves :
| Couche | Ce qui peut échouer | Preuves de l'acheteur | |---|---|---| | Client et SDK | URL de base incorrecte, clé incorrecte, point de terminaison non pris en charge, délai d'attente trop bas, erreur d'analyse. | Configuration du client, version du SDK, corps de la requête, délai d'attente et journaux locaux. | | Passerelle | Authentification, routage, mesure, point de terminaison de la passerelle, tableau de bord, journal d'utilisation, services de compte. | SLA de la passerelle, ID de la requête, trace de la route, statut, enregistrement d'utilisation et ticket de support. | | Fournisseur en amont | Panne du fournisseur, quota du fournisseur, retrait du modèle, blocage régional, rejet de politique, comportement spécifique au modèle. | Statut du fournisseur, page de quota du fournisseur, corps de l'erreur en amont, ID du modèle et décision de repli. | | Flux de travail métier | Impact sur l'utilisateur, profondeur de la file d'attente, sortie dégradée, objectif interne manqué. | Chronologie de l'incident, classe de trafic affectée, résumé de l'impact client, décision de restauration. |
C'est là qu'un SLA de passerelle IA devient opérationnel. L'acheteur devrait demander une trace au niveau de la route, et pas seulement un chiffre de disponibilité mensuelle.
Questions sur le routage et le repli
Le routage est la partie d'un SLA de passerelle IA qui est le plus souvent sous-spécifiée. Une passerelle peut prendre en charge plusieurs modèles et fournisseurs, mais la fiabilité en production dépend de la route qui a été autorisée pour chaque classe de trafic.
La documentation officielle des passerelles d'autres fournisseurs montre pourquoi les détails sont importants. La documentation de la passerelle IA de Vercel décrit le routage des fournisseurs et les replis de modèles, y compris le contrôle de l'ordre de routage et du comportement de repli. Sa documentation sur le repli de modèles indique que des sauvegardes peuvent être essayées dans l'ordre lorsqu'un modèle principal échoue ou n'est pas disponible. La documentation de la passerelle IA de Pydantic décrit des groupes de routage où la priorité et le poids décident du basculement ou de l'équilibrage de charge, avec un passage au suivant (fallthrough) lorsqu'un membre de priorité supérieure n'est pas disponible, est limité en débit ou génère des erreurs. Ce sont des exemples de catégories utiles, pas des garanties de Flatkey. Ils montrent les questions qu'un acheteur devrait poser à n'importe quelle passerelle, y compris Flatkey.
Utilisez cette table de routage avant d'approuver le repli automatique :
| Signal d'échec | Question par défaut de l'acheteur | Preuve fiable | |---|---|---| | Passerelle 401 ou 403 | La clé, le compte, l'environnement ou la portée de la politique étaient-ils incorrects ? | Propriétaire de la clé, environnement, erreur d'authentification et enregistrement du refus de la politique. | | Modèle non trouvé | Le modèle demandé existait-il dans le catalogue actuel pour ce compte ? | Ligne du catalogue, ID du modèle, famille de points de terminaison et preuve de la date de publication ou de la date de test. | | Fournisseur 429 | Le quota de ce compte, de cette région, de ce modèle ou de ce déploiement était-il épuisé ? | Page des quotas, corps de l'erreur en amont, données retry-after et politique de repli. | | Fournisseur 5xx ou timeout | La passerelle doit-elle réessayer, changer de route pour le même modèle, mettre en file d'attente ou échouer en circuit fermé ? | Trace de la route, nombre de tentatives, seuil de timeout, résultat final et enregistrement des coûts. | | Limite de contexte ou entrée non prise en charge | Le repli est-il autorisé si le modèle de secours modifie le contexte, les outils, la vision ou le comportement des médias ? | Contrat du modèle, test de fonctionnalité, vérification de la sortie acceptée et approbation du propriétaire du produit. | | Rejet de politique ou de sécurité | Un autre fournisseur est-il autorisé à recevoir la même requête ? | Frontière des données, approbation du fournisseur, classification du prompt et validation de la conformité. | | Échec inconnu | Quelle est la condition d'arrêt ? | Procédure d'incident, nombre maximal de tentatives, règle d'échec en circuit fermé et escalade au support. |
La preuve la plus solide pour un SLA de passerelle IA est une trace de routage qui nomme la route de départ, la règle de repli, la route finale et la raison de chaque transition.
Le repli n'est pas toujours un gain de fiabilité
Le service des achats demande souvent si la passerelle dispose d'un repli automatique. Les équipes de la plateforme devraient répondre par une deuxième question : un repli vers quoi ?
Un basculement automatique d'un compte à un autre pour le même modèle approuvé peut être raisonnable. Un changement d'une famille de modèles à une autre peut modifier la qualité, le traitement des données, la latence, le format de sortie, le comportement des outils, la politique d'image ou de vidéo et le coût. Certains trafics devraient échouer en circuit fermé, car un repli masqué aggraverait l'incident.
Définissez le repli par classe de trafic :
| Classe de trafic | Posture de repli | Pourquoi | |---|---|---| | Chat client | Utiliser uniquement des routes équivalentes approuvées, ou renvoyer une erreur contrôlée. | La qualité et la sécurité côté utilisateur doivent rester prévisibles. | | Résumé interne | Réessayer, mettre en file d'attente ou utiliser une route approuvée à moindre coût. | La latence peut être échangée contre le coût et l'achèvement. | | Évaluations et benchmarks | Échouer en circuit fermé. | Les changements de modèle masqués corrompent les données de comparaison. | | Tâches par lots sensibles aux finances | Mettre en file d'attente ou exiger une approbation avant le repli. | Les nouvelles tentatives et les modèles de secours peuvent multiplier les dépenses. | | Workflows d'agents avec des outils | Repli uniquement après que le comportement d'appel d'outil a été testé. | Les schémas d'outils et le comportement de streaming peuvent différer selon le fournisseur. | | Trafic réglementé ou isolé par client | Échouer en circuit fermé, sauf si le fournisseur et la région de secours sont pré-approuvés. | La frontière des données et les preuves d'achat sont plus importantes que l'achèvement automatique. |
Ceci est le test appartenant à l'acheteur : exécutez le même prompt via la route principale et la route de repli proposée, puis comparez la forme de la réponse, les journaux, le coût, la latence, la sortie acceptée et les preuves de support. Ne considérez pas un SLA de passerelle IA comme complet tant que la preuve de repli n'existe pas.
Questions pour le dossier de preuves du support
Le SLA actuel de Flatkey demande aux clients de contacter le support en fournissant l'e-mail du compte, le point de terminaison affecté, les ID de requête si disponibles, les horodatages, les messages d'erreur et un résumé de l'impact. C'est un modèle utile pour tout processus de support de SLA de passerelle IA.
Avant le lancement, créez un dossier de support avec ces champs :
| Champ | Pourquoi c'est important | |---|---| | E-mail du compte et espace de travail | Permet au support de trouver le bon locataire, la bonne clé et les bons droits. | | Point de terminaison affecté | Sépare les incidents de chat, de réponses, de messages, d'image, de vidéo et de tableau de bord. | | ID de requête | Relie les journaux d'application aux traces de la passerelle et en amont. | | Horodatages avec fuseau horaire | Empêche les dérives des fenêtres de disponibilité mensuelle et d'incident. | | ID du modèle et classe de route | Montre quelle politique de routage et quelle famille de fournisseurs étaient impliquées. | | Messages d'erreur et codes de statut | Sépare les échecs d'authentification, de quota, de timeout, de fournisseur et d'analyseur. | | Résumé de l'impact | Explique les utilisateurs affectés, le chiffre d'affaires, les tâches, la profondeur de la file d'attente ou le workflow interne. | | Nouvelles tentatives côté client | Montre si les tentatives en double ont augmenté le coût ou la charge. | | Action requise | Clarifie si vous avez besoin d'un diagnostic, d'une désactivation de route, d'un examen de crédit ou d'un suivi contractuel. |
Liez ce dossier de support à votre processus d'utilisation de l'API IA des journaux d'audit. Si les ID de requête et les preuves de routage ne sont pas disponibles après un incident, le processus de support devient un exercice de mémoire.
Questions sur les recours et les crédits
La section sur les recours d'un SLA de passerelle IA est importante car elle définit souvent ce que l'acheteur peut réellement récupérer. Un objectif de 99,5 % sans clause de crédit est différent d'un SLA engagé avec des crédits de service automatiques, des exigences de notification écrite, des exclusions et des délais de réclamation.
Le SLA public de Flatkey stipule qu'il n'y a pas de crédits de service automatiques, de remboursements, de pénalités ou de dommages-intérêts liquidés, sauf si un accord écrit distinct prévoit un recours différent. Tout ajustement commercial, correction de solde ou remédiation par le support est traité au cas par cas en vertu du contrat d'utilisation et des politiques applicables.
Cela ne rend pas le SLA inutilisable. Cela signifie que le service des achats doit poser les bonnes questions :
- Le SLA public constitue-t-il l'intégralité de l'accord, ou existe-t-il un contrat d'entreprise distinct ?
- S'il existe des crédits, quelle est la période de réclamation ?
- Quelles preuves le client doit-il fournir ?
- Les pannes des fournisseurs en amont sont-elles exclues même lorsque la passerelle a sélectionné ce fournisseur ?
- La maintenance planifiée et les actions de sécurité d'urgence sont-elles exclues ?
- La latence, la qualité du modèle, la limitation du débit et le comportement de repli sont-ils couverts, ou seulement la disponibilité ?
- Le recours s'applique-t-il au solde prépayé, aux avoirs sur facture, aux remboursements, aux mesures de support correctives ou aux droits de résiliation du contrat ?
- Qui, au sein du service financier, approuve la réclamation finale ?
La réponse doit se trouver dans le même dossier fournisseur que l'évaluation des risques liés aux fournisseurs d'API d'IA. Les services juridiques et financiers ont besoin des mêmes preuves que celles utilisées par les ingénieurs de plateforme lors de l'examen des incidents.
Quotas, limites de débit et dépendances des fournisseurs
Un SLA de passerelle IA peut être valide alors même qu'une requête échoue parce qu'un quota de fournisseur en amont est épuisé. C'est pourquoi les preuves de quota doivent faire partie de l'examen du SLA.
La documentation sur les quotas d'Azure OpenAI de Microsoft indique que les limites de jetons par minute et de requêtes par minute sont définies par région, abonnement et type de modèle ou de déploiement. La documentation d'AWS Bedrock dirige de la même manière les équipes vers les quotas de service pour les ressources Bedrock et note que l'inférence de modèle est contrôlée par des quotas d'utilisation de jetons. Ces faits concernant les fournisseurs ne sont pas des promesses de Flatkey. Ce sont des rappels que la configuration du compte en amont peut déterminer si le repli est disponible lors d'un incident réel.
Ajoutez ces vérifications au dossier de lancement :
| Vérification de la dépendance | Preuve | |---|---| | Portée du quota en amont | Région, compte ou abonnement, modèle, type de déploiement, TPM/RPM ou équivalent du fournisseur. | | Portée du quota de la passerelle | Clé, équipe, environnement, groupe de modèles, plafond budgétaire et fenêtre de réinitialisation. | | Budget de nouvelles tentatives | Nombre maximal de nouvelles tentatives, politique de gigue/backoff et garde-fou des coûts. | | Capacité de repli | Quota de la route de secours, disponibilité du modèle et approbation du fournisseur. | | Comportement de limitation du débit | Code d'erreur, signal retry-after, escalade au support et gestion côté utilisateur. |
Si le quota n'est pas mesuré par le même propriétaire que le routage, l'examen du SLA de la passerelle IA passera à côté du mode de défaillance le plus courant : la route existe, mais le compte ne peut pas absorber le trafic de production.
Examen de pré-production Flatkey
Pour Flatkey, la preuve de produit publique vérifiée le 6 juillet 2026 prend en charge une passerelle API d'IA, une clé API, l'URL de base du routeur compatible OpenAI https://router.flatkey.ai/v1, une visibilité de l'utilisation et de la facturation orientée tableau de bord, un examen de la tarification et un positionnement lié au routage. L'instantané de l'API de tarification en direct a renvoyé success: true, version de tarification a42d372ccf0b5dd13ecf71203521f9d2, 45 lignes de modèles, 48 fournisseurs, des métadonnées de points de terminaison prises en charge pour les messages Anthropic, Gemini generateContent, la génération d'images, les complétions de chat OpenAI et les requêtes vidéo, ainsi que des états de disponibilité available et unknown_failure sur l'ensemble des lignes.
Utilisez cela uniquement comme une preuve publique datée. Cela ne prouve pas le recours de votre SLA, le niveau de support, le succès de la route, l'éligibilité au repli, la disponibilité permanente du modèle, la latence, le périmètre de conformité ou la tarification spécifique à votre compte.
Un examen de pré-production du SLA de la passerelle IA Flatkey devrait inclure :
- Ouvrez la page de tarification actuelle et sélectionnez le modèle exact ou la famille de routes.
- Confirmez la ligne du modèle et la famille de points de terminaison dans votre compte ou votre tableau de bord.
- Exécutez une requête à faible risque via
https://router.flatkey.ai/v1. - Capturez l'ID de la requête, l'ID du modèle, le point de terminaison, l'horodatage, le statut, les unités d'utilisation, la preuve de coût et le propriétaire de la clé.
- Exécutez un test d'échec approuvé : mauvais modèle, limite de quota, délai d'attente ou repli désactivé.
- Confirmez où les preuves pour le support apparaissent dans les journaux.
- Décidez quelles classes de trafic peuvent utiliser le repli et lesquelles doivent échouer en circuit fermé (fail closed).
- Ajoutez les champs du dossier de support au guide d'intervention en cas d'incident (runbook).
- Enregistrez le SLA actuel, la tarification, la preuve de route et le chemin de support dans le dossier des preuves du fournisseur.
Lorsque ces preuves existent, la plateforme, les achats et le service financier peuvent évaluer le même dossier au lieu de débattre à partir de captures d'écran.
Checklist des déclencheurs de renouvellement
N'examinez pas le SLA d'une passerelle IA une seule fois. Ajoutez des déclencheurs de renouvellement pour que le dossier de l'acheteur reste à jour.
| Déclencheur | Quoi revérifier | |---|---| | Mise à jour de la page SLA ou du contrat | Portée, exclusions, recours, processus de support et coordonnées. | | Nouvelle famille de modèles | Point de terminaison, fournisseur, quota, frontière des données, unité de tarification et politique de repli. | | Nouvelle classe de trafic de production | Posture de basculement, sévérité du support et approbation du propriétaire. | | Incident ou quasi-incident | Trace de la route, chronologie du support, impact sur l'utilisateur, impact sur les coûts et action préventive. | | Changement de quota du fournisseur | Capacité de secours, comportement de limitation du débit et allocation du trafic. | | Changement de tarification | Coût au niveau de la requête, budget de nouvelles tentatives, coût du modèle de repli et seuil financier. | | Examen de sécurité ou de conformité | Portée de la journalisation, rétention, approbation du fournisseur et revue des accès. |
Reliez cette checklist à la checklist pour les passerelles API d'IA d'entreprise. Le SLA est une partie du dossier de preuves de l'entreprise, pas un badge de confiance autonome.
Erreurs courantes
| Erreur | Pourquoi c'est préjudiciable | Meilleure vérification | |---|---|---| | Traiter un objectif de disponibilité de la passerelle comme une garantie de succès du modèle | Les fournisseurs en amont, les quotas, les politiques et le comportement du modèle peuvent être exclus. | Séparer les preuves de la passerelle, du fournisseur, du client et du flux de travail métier. | | Demander s'il existe un repli, mais pas vers quoi il bascule | Les modèles de secours peuvent modifier la sortie, les limites des données, les fonctionnalités et le coût. | Approuver le repli par classe de trafic et contrat de modèle. | | Ne conserver aucun ID de requête | Le support ne peut pas connecter de manière fiable les journaux clients aux journaux de routage. | Ajouter la capture de l'ID de requête à chaque route de production. | | Ignorer la portée du quota | Une route de secours peut exister mais être tout de même limitée pendant les pics de trafic. | Stocker ensemble les preuves de quota en amont et de la passerelle. | | Supposer que les crédits sont automatiques | De nombreux SLA nécessitent un accord séparé, un processus de réclamation ou un examen au cas par cas. | Enregistrer les conditions de recours et le responsable de la réclamation avant le lancement. | | N'examiner qu'au moment de l'achat | Les catalogues de modèles, les quotas et les chemins de support changent. | Ajouter des déclencheurs de renouvellement et des revérifications basées sur les incidents. |
FAQ
Qu'est-ce qu'un SLA de passerelle IA ?
Un SLA de passerelle IA définit l'objectif de disponibilité, la portée, les exclusions, le processus de support et les recours pour les services de passerelle qu'un fournisseur exploite. Il peut ne pas couvrir les pannes des fournisseurs de modèles tiers, les limites de quota, le comportement du modèle, la configuration du client ou tous les résultats de repli.
Un SLA de passerelle IA garantit-il que chaque requête de modèle réussit ?
Non. Un SLA de passerelle IA peut couvrir la disponibilité de la passerelle tout en excluant les défaillances des fournisseurs en amont, les limites de débit des fournisseurs, les changements de politique, le comportement du modèle, les identifiants clients, la maintenance planifiée ou les problèmes côté client. Vérifiez le texte d'exclusion et les preuves de routage.
Que devrait demander le service des achats à propos du repli de modèle ?
Le service des achats devrait demander quelles erreurs déclenchent le repli, quels modèles ou fournisseurs sont des sauvegardes approuvées, si le repli modifie le traitement des données ou le comportement de sortie, comment les nouvelles tentatives sont facturées et où les preuves de routage sont stockées après un incident.
Quelles preuves le support doit-il recevoir lors d'un incident SLA ?
Le support doit recevoir l'e-mail du compte, le point de terminaison affecté, les ID de requête, les horodatages, les messages d'erreur, l'ID du modèle, la classe de route, le résumé de l'impact et le comportement de nouvelle tentative du client. Le SLA public de Flatkey demande actuellement plusieurs de ces champs, y compris le point de terminaison, les ID de requête, les horodatages, les erreurs et le résumé de l'impact.
Les crédits de service sont-ils automatiques ?
Pas toujours. Le SLA public de Flatkey stipule que les crédits de service automatiques, les remboursements, les pénalités ou les dommages-intérêts ne sont pas créés à moins qu'un accord écrit distinct n'en dispose autrement. Les acheteurs doivent confirmer la clause de recours, le délai de réclamation et le processus d'approbation.
À quelle fréquence les équipes doivent-elles examiner un SLA de passerelle IA ?
Examinez un SLA de passerelle IA lors de l'achat, du renouvellement, d'un changement de route majeur, d'une nouvelle famille de modèles, d'une nouvelle classe de trafic de production, d'un changement de tarification, d'un changement de quota et après chaque incident matériel ou quasi-incident.
Recommandation finale
Un SLA de passerelle IA n'est utile que lorsqu'il devient testable. Commencez par le SLA public ou contractuel, séparez la portée de la passerelle de celle du fournisseur en amont, exécutez des tests de routage et de repli, enregistrez les ID de requête, définissez les preuves de support et ajoutez des déclencheurs de renouvellement.
Flatkey peut aider les équipes à centraliser l'accès aux modèles, le routage, l'examen des prix et les preuves d'utilisation derrière un seul flux de travail de passerelle. Avant le déploiement en production, vérifiez le modèle exact, le point de terminaison, le comportement de routage, le processus de support et les preuves de SLA pour votre compte. Ensuite, obtenez une clé lorsque vous êtes prêt à tester un flux de travail de SLA de passerelle IA avec un trafic de pré-production réel.
