Un SLA de gateway de IA puede parecer simple hasta el primer incidente con un modelo. Un comprador ve un porcentaje de disponibilidad, una dirección de soporte y la promesa de que el gateway enruta las solicitudes. El equipo de producción todavía tiene que responder preguntas más difíciles: qué endpoint está cubierto, qué proveedor ascendente falló, si el respaldo cambió el contrato del modelo, qué evidencia necesita el soporte y si alguna solución es automática.
Utilice esta lista de verificación de SLA de gateway de IA para convertir el lenguaje del proveedor en un archivo de evidencia. El objetivo no es negociar con eslóganes. El objetivo es saber qué cubre el SLA, qué excluye, cómo se demuestran el enrutamiento y el respaldo, y qué debe revisar su equipo antes de la renovación.
Específicamente para Flatkey, el Acuerdo de Nivel de Servicio público, verificado el 6 de julio de 2026, establece que el alcance cubierto incluye el panel de control alojado, el gateway de API, el enrutamiento, la medición y los servicios de cuenta que Flatkey opera directamente. Apunta a una disponibilidad mensual del 99.5% para los endpoints cubiertos, excluye las interrupciones de proveedores de modelos de IA de terceros y las fallas del lado del proveedor, solicita a los clientes que envíen ID de solicitud, marcas de tiempo, errores, endpoint, correo electrónico de la cuenta y un resumen del impacto para el soporte, y no genera créditos automáticos a menos que un acuerdo escrito por separado indique lo contrario. Considere eso como la evidencia inicial, luego verifique su cuenta, clase de tráfico, política de respaldo y proceso de soporte antes de que el tráfico de producción dependa de ello.
Respuesta rápida: Preguntas sobre el SLA del Gateway de IA
| Área del SLA | Pregunte esto antes de firmar o renovar | Evidencia a conservar | |---|---|---| | Servicio cubierto | ¿Qué funciones de panel de control, gateway de API, enrutamiento, medición, cuenta y soporte están cubiertas? | URL del SLA actual, cronograma del contrato, lista de endpoints y capturas de pantalla con fecha. | | Cálculo de la disponibilidad | ¿La disponibilidad se mide mediante el monitoreo del proveedor, sondeos del cliente, estado público o un informe contractual? | Informe de disponibilidad mensual, registro de sondeos, exportación de incidentes y método de cálculo. | | Proveedores de terceros | ¿Están excluidas las interrupciones de modelos ascendentes, los límites de tasa, las restricciones regionales, los cambios en los modelos y las fallas del lado del proveedor? | Enlaces de estado del proveedor, cuerpos de error del modelo, registros de ruta y texto de exclusión del proveedor. | | Enrutamiento | ¿Qué modelo, proveedor, cuenta, región o grupo se intentó primero? | ID de solicitud, ruta seleccionada, ID del modelo, familia de endpoints, propietario de la clave y marca de tiempo. | | Respaldo | ¿Qué errores desencadenan reintentos, respaldo, encolamiento o comportamiento de fallo cerrado (fail-closed)? | Política de respaldo, traza de ruta, recuento de reintentos, modelo final y prueba de salida aceptada. | | Soporte | ¿Qué evidencia se debe enviar y qué ruta de severidad se aplica? | Plantilla de ticket, ID de solicitud, endpoint, marcas de tiempo, errores, resumen del impacto y cronograma de respuesta. | | Soluciones | ¿Los créditos de servicio son automáticos, caso por caso o solo mediante un acuerdo escrito por separado? | Cláusula de solución del SLA, enmienda del contrato, solicitud de crédito y aprobación financiera. | | Renovación | ¿Qué se debe revisar antes del próximo período? | Registro de incidentes, excepciones de respaldo, resultados de soporte, eventos de cuota, cambios de precios y aprobaciones de ruta. |
La respuesta práctica sobre el SLA de un gateway de IA es esta: separe la responsabilidad del gateway de la responsabilidad del proveedor ascendente y luego pruebe la ruta. Si el comprador no puede inspeccionar la ruta, el respaldo, el ticket de soporte y la evidencia de disponibilidad mensual, el SLA no está listo para la gobernanza de producción.
Separe el tiempo de actividad del gateway de la disponibilidad del modelo ascendente
La primera pregunta sobre el SLA de un gateway de IA es si el proveedor está prometiendo el gateway, el modelo ascendente o el resultado completo para el usuario final. Esas son capas diferentes.
El SLA público actual de Flatkey hace esa separación explícita: los servicios cubiertos operados por Flatkey están dentro del alcance, mientras que los proveedores de modelos de terceros, las interrupciones de proveedores, los límites de tasa de proveedores, los cambios de política, las restricciones regionales, el comportamiento del modelo y las fallas del lado del proveedor están fuera del SLA. Esto es lo suficientemente común en la compra de gateways como para que el departamento de adquisiciones nunca deba tratar un único porcentaje de tiempo de actividad como si significara que "todas las solicitudes de modelo tendrán éxito".
Utilice esta división en el archivo de evidencia:
| Capa | Qué puede fallar | Evidencia del comprador | |---|---|---| | Cliente y SDK | URL base incorrecta, clave incorrecta, endpoint no compatible, tiempo de espera demasiado bajo, error del analizador (parser). | Configuración del cliente, versión del SDK, cuerpo de la solicitud, tiempo de espera y registros locales. | | Gateway | Autenticación, enrutamiento, medición, endpoint del gateway, panel de control, registro de uso, servicios de cuenta. | SLA del gateway, ID de solicitud, traza de ruta, estado, registro de uso y ticket de soporte. | | Proveedor ascendente | Interrupción del proveedor, cuota del proveedor, retiro del modelo, bloqueo regional, rechazo de política, comportamiento específico del modelo. | Estado del proveedor, página de cuotas del proveedor, cuerpo del error ascendente, ID del modelo y decisión de respaldo. | | Flujo de trabajo del negocio | Impacto en el usuario, profundidad de la cola, salida degradada, objetivo interno no cumplido. | Cronología del incidente, clase de tráfico afectada, resumen del impacto en el cliente, decisión de reversión (rollback). |
Aquí es donde un SLA de gateway de IA se vuelve operativo. El comprador debe solicitar una traza a nivel de ruta, no solo una cifra de tiempo de actividad mensual.
Preguntas sobre enrutamiento y respaldo
El enrutamiento es la parte de un SLA de gateway de IA que con mayor frecuencia no se especifica lo suficiente. Un gateway puede admitir múltiples modelos y proveedores, pero la fiabilidad en producción depende de qué ruta se permitió para cada clase de tráfico.
La documentación oficial de gateways de otros proveedores muestra por qué los detalles importan. Los documentos del AI Gateway de Vercel describen el enrutamiento de proveedores y los respaldos de modelos, incluido el control sobre el orden de enrutamiento y el comportamiento de respaldo. Sus documentos sobre respaldo de modelos dicen que se pueden probar copias de seguridad en orden cuando un modelo primario falla o no está disponible. Los documentos del Pydantic AI Gateway describen grupos de enrutamiento donde la prioridad y el peso deciden la conmutación por error (failover) o el balanceo de carga, con paso al siguiente (fallthrough) cuando un miembro de mayor prioridad no está disponible, tiene un límite de tasa o presenta errores. Estos son ejemplos de categorías útiles, no garantías de Flatkey. Muestran las preguntas que un comprador debería hacer a cualquier gateway, incluido Flatkey.
Utilice esta tabla de enrutamiento antes de aprobar el respaldo automático:
| Señal de fallo | Pregunta predeterminada del comprador | Evidencia segura | |---|---|---| | Gateway 401 o 403 | ¿Estaba mal el alcance de la clave, la cuenta, el entorno o la política? | Propietario de la clave, entorno, error de autenticación y registro de denegación de política. | | Modelo no encontrado | ¿Existía el modelo solicitado en el catálogo actual para esta cuenta? | Fila del catálogo, ID del modelo, familia de endpoints y prueba de fecha de publicación o de prueba. | | Proveedor 429 | ¿Se agotó la cuota de esta cuenta, región, modelo o despliegue? | Página de cuotas, cuerpo del error ascendente, datos de reintento posterior y política de respaldo. | | Proveedor 5xx o tiempo de espera | ¿Debería el gateway reintentar, cambiar a una ruta del mismo modelo, encolar o fallar en cerrado? | Rastreo de ruta, recuento de reintentos, umbral de tiempo de espera, resultado final y registro de costos. | | Límite de contexto o entrada no admitida | ¿Se permite el respaldo si el modelo de copia de seguridad cambia el contexto, las herramientas, la visión o el comportamiento de los medios? | Contrato del modelo, prueba de características, verificación de salida aceptada y aprobación del propietario del producto. | | Rechazo por política o seguridad | ¿Se permite que otro proveedor reciba la misma solicitud? | Límite de datos, aprobación del proveedor, clasificación del prompt y aprobación de cumplimiento. | | Fallo desconocido | ¿Cuál es la condición de parada? | Manual de incidentes, intentos máximos, regla de fallo en cerrado y escalado a soporte. |
La evidencia más sólida del SLA de un gateway de IA es un rastreo de ruta que nombra la ruta de inicio, la regla de respaldo, la ruta final y la razón por la que ocurrió cada transición.
El respaldo no siempre es una ganancia en fiabilidad
El departamento de compras a menudo pregunta si el gateway tiene respaldo automático. Los equipos de plataforma deberían responder con una segunda pregunta: ¿respaldo a qué?
Un cambio automático de una cuenta a otra para el mismo modelo aprobado puede ser razonable. Un cambio de una familia de modelos a otra puede cambiar la calidad, el manejo de datos, la latencia, el formato de salida, el comportamiento de las herramientas, la política de imágenes o video y el costo. Parte del tráfico debería fallar en cerrado porque un respaldo oculto empeoraría el incidente.
Defina el respaldo por clase de tráfico:
| Clase de tráfico | Postura de respaldo | Por qué | |---|---|---| | Chat con clientes | Use solo rutas equivalentes aprobadas o devuelva un error controlado. | La calidad y seguridad de cara al usuario deben permanecer predecibles. | | Resumen interno | Reintente, encole o use una ruta aprobada de menor costo. | La latencia se puede intercambiar por costo y finalización. | | Evaluaciones y benchmarks | Fallo en cerrado. | Los cambios ocultos en el modelo corrompen los datos de comparación. | | Trabajos por lotes sensibles a las finanzas | Encole o requiera aprobación antes del respaldo. | Los reintentos y los modelos de respaldo pueden multiplicar el gasto. | | Flujos de trabajo de agentes con herramientas | Respaldo solo después de que se pruebe el comportamiento de la llamada a la herramienta. | Los esquemas de herramientas y el comportamiento de transmisión pueden diferir según el proveedor. | | Tráfico regulado o aislado del cliente | Fallo en cerrado a menos que el proveedor y la región de respaldo estén preaprobados. | El límite de datos y la evidencia de adquisición importan más que la finalización automática. |
Esta es la prueba propiedad del comprador: ejecute el mismo prompt a través de la ruta principal y la ruta de respaldo propuesta, luego compare la forma de la respuesta, los registros, el costo, la latencia, la salida aceptada y la evidencia de soporte. No trate un SLA de gateway de IA como completo hasta que exista la evidencia de respaldo.
Preguntas de soporte para el paquete de evidencia
El SLA actual de Flatkey pide a los clientes que se pongan en contacto con el soporte con el correo electrónico de la cuenta, el endpoint afectado, los ID de solicitud si están disponibles, las marcas de tiempo, los mensajes de error y el resumen del impacto. Esa es una plantilla útil para cualquier proceso de soporte de SLA de un gateway de IA.
Antes del lanzamiento, cree un paquete de soporte con estos campos:
| Campo | Por qué es importante | |---|---| | Correo electrónico de la cuenta y espacio de trabajo | Permite al soporte encontrar el inquilino, la clave y el derecho correctos. | | Endpoint afectado | Separa los incidentes de chat, respuestas, mensajes, imagen, video y panel de control. | | ID de solicitud | Conecta los registros de la aplicación con los rastreos del gateway y ascendentes. | | Marcas de tiempo con zona horaria | Evita que la disponibilidad mensual y las ventanas de incidentes se desvíen. | | ID del modelo y clase de ruta | Muestra qué política de ruta y familia de proveedores estuvieron involucradas. | | Mensajes de error y códigos de estado | Separa los fallos de autenticación, cuota, tiempo de espera, proveedor y analizador. | | Resumen del impacto | Explica los usuarios afectados, los ingresos, los trabajos, la profundidad de la cola o el flujo de trabajo interno. | | Reintentos del lado del cliente | Muestra si los intentos duplicados aumentaron el costo o la carga. | | Acción requerida | Aclara si necesita un diagnóstico, la desactivación de la ruta, una revisión de crédito o un seguimiento del contrato. |
Vincule este paquete de soporte a su proceso de registros de auditoría del uso de la API de IA. Si los ID de solicitud y la evidencia de la ruta no están disponibles después de un incidente, el proceso de soporte se convierte en un ejercicio de memoria.
Preguntas sobre compensación y crédito
La sección de compensación de un SLA de gateway de IA es importante porque a menudo define lo que el comprador puede recuperar realmente. Un objetivo del 99.5% sin una cláusula de crédito es diferente de un SLA comprometido con créditos de servicio automáticos, requisitos de notificación por escrito, exclusiones y plazos de reclamación.
El SLA público de Flatkey establece que no hay créditos de servicio automáticos, reembolsos, penalizaciones o daños y perjuicios a menos que un acuerdo escrito por separado proporcione una compensación diferente. Cualquier ajuste de buena voluntad, corrección de saldo o remediación de soporte se maneja caso por caso bajo el acuerdo de usuario y las políticas aplicables.
Eso no hace que el SLA sea inutilizable. Significa que el departamento de compras debe hacer las preguntas correctas:
- ¿El SLA público es el acuerdo completo o existe un programa empresarial por separado?
- Si existen créditos, ¿cuál es el plazo para reclamarlos?
- ¿Qué evidencia debe proporcionar el cliente?
- ¿Se excluyen las interrupciones del proveedor ascendente incluso cuando el gateway seleccionó a ese proveedor?
- ¿Se excluyen el mantenimiento programado y las acciones de seguridad de emergencia?
- ¿Están cubiertos la latencia, la calidad del modelo, la limitación de velocidad (throttling) y el comportamiento de respaldo, o solo la disponibilidad?
- ¿La compensación se aplica al saldo prepagado, créditos en factura, reembolsos, remediación de soporte o derechos de terminación de contrato?
- ¿Quién en el departamento de finanzas aprueba la reclamación final?
La respuesta debe residir en el mismo archivo de proveedor que la evaluación de riesgos del proveedor de API de IA. Los departamentos legal y financiero necesitan la misma evidencia que los ingenieros de plataforma utilizan durante la revisión de incidentes.
Cuotas, límites de velocidad y dependencias del proveedor
Un SLA de un gateway de IA puede ser válido mientras una solicitud sigue fallando porque se ha agotado una cuota del proveedor ascendente. Es por eso que la evidencia de la cuota pertenece a la revisión del SLA.
La documentación de cuotas de Azure OpenAI de Microsoft dice que los límites de token por minuto y solicitud por minuto se definen por región, suscripción y tipo de modelo o implementación. La documentación de AWS Bedrock dirige de manera similar a los equipos a las cuotas de servicio para los recursos de Bedrock y señala que la inferencia del modelo está controlada por cuotas de uso de tokens. Estos hechos del proveedor no son promesas de Flatkey. Son recordatorios de que la configuración de la cuenta ascendente puede decidir si el respaldo está disponible durante un incidente real.
Añada estas verificaciones al archivo de lanzamiento:
| Verificación de dependencia | Evidencia | |---|---| | Alcance de la cuota ascendente | Región, cuenta o suscripción, modelo, tipo de implementación, TPM/RPM o equivalente del proveedor. | | Alcance de la cuota del gateway | Clave, equipo, entorno, grupo de modelos, límite de presupuesto y ventana de reinicio. | | Presupuesto de reintentos | Número máximo de reintentos, política de jitter/backoff y barrera de protección de costos. | | Capacidad de respaldo | Cuota de ruta de respaldo, disponibilidad del modelo y aprobación del proveedor. | | Comportamiento de limitación (throttling) | Código de error, señal de reintento posterior (retry-after), escalamiento a soporte y manejo de cara al usuario. |
Si la cuota no es medida por el mismo propietario que el enrutamiento, la revisión del SLA del gateway de IA omitirá el modo de falla más común: la ruta existe, pero la cuenta no puede absorber el tráfico de producción.
Revisión de Staging de Flatkey
Para Flatkey, la prueba pública del producto verificada el 6 de julio de 2026 admite un gateway de API de IA, una clave de API, la URL base del enrutador compatible con OpenAI https://router.flatkey.ai/v1, visibilidad de uso y facturación orientada al panel de control, revisión de precios y posicionamiento relacionado con el enrutamiento. La instantánea de la API de precios en vivo devolvió success: true, versión de precios a42d372ccf0b5dd13ecf71203521f9d2, 45 filas de modelos, 48 proveedores, metadatos de endpoint compatibles para mensajes de Anthropic, generateContent de Gemini, generación de imágenes, completado de chat de OpenAI y solicitudes de video, además de estados de disponibilidad de available y unknown_failure en todas las filas.
Utilice eso solo como evidencia pública fechada. No prueba la compensación del SLA de su cuenta, el nivel de soporte, el éxito de la ruta, la elegibilidad para respaldo, la disponibilidad permanente del modelo, la latencia, el alcance de cumplimiento o los precios específicos de la cuenta.
Una revisión de staging del SLA del gateway de IA de Flatkey debería incluir:
- Abra la página de precios actual y seleccione el modelo exacto o la familia de rutas.
- Confirme la fila del modelo y la familia de endpoints en su cuenta o panel de control.
- Ejecute una solicitud de bajo riesgo a través de
https://router.flatkey.ai/v1. - Capture el ID de la solicitud, el ID del modelo, el endpoint, la marca de tiempo, el estado, las unidades de uso, la evidencia de costo y el propietario de la clave.
- Ejecute una prueba de falla aprobada: modelo incorrecto, límite de cuota, tiempo de espera o respaldo deshabilitado.
- Confirme dónde aparece la evidencia de soporte en los registros.
- Decida qué clases de tráfico pueden usar respaldo y cuáles deben fallar en estado cerrado.
- Añada los campos del paquete de soporte al manual de incidentes (runbook).
- Guarde el SLA actual, los precios, la prueba de ruta y la ruta de soporte en la carpeta de evidencia del proveedor.
Cuando esa evidencia existe, los departamentos de plataforma, adquisiciones y finanzas pueden evaluar el mismo archivo en lugar de discutir a partir de capturas de pantalla.
Lista de verificación de activadores de renovación
No revise el SLA de un gateway de IA solo una vez. Añada activadores de renovación para que el archivo del comprador se mantenga actualizado.
| Activador | Qué volver a verificar | |---|---| | Actualización de la página del SLA o del contrato | Alcance, exclusiones, compensaciones, proceso de soporte y detalles de contacto. | | Nueva familia de modelos | Endpoint, proveedor, cuota, límite de datos, unidad de precios y política de respaldo. | | Nueva clase de tráfico de producción | Postura de conmutación por error (failover), severidad del soporte y aprobación del propietario. | | Incidente o cuasi accidente | Rastreo de ruta, cronograma de soporte, impacto en el usuario, impacto en el costo y acción preventiva. | | Cambio en la cuota del proveedor | Capacidad de respaldo, comportamiento de limitación (throttling) y asignación de tráfico. | | Cambio de precios | Costo a nivel de solicitud, presupuesto de reintentos, costo del modelo de respaldo y umbral financiero. | | Revisión de seguridad o cumplimiento | Alcance del registro, retención, aprobación del proveedor y revisión de acceso. |
Vincule esta lista de verificación con la lista de verificación del gateway de API de IA empresarial. El SLA es una parte del paquete de evidencia empresarial, no una insignia de confianza independiente.
Errores comunes
| Error | Por qué es perjudicial | Mejor verificación | |---|---|---| | Tratar un objetivo de tiempo de actividad del gateway como una garantía de éxito del modelo | Se pueden excluir los proveedores ascendentes, la cuota, la política y el comportamiento del modelo. | Dividir la evidencia del gateway, el proveedor, el cliente y el flujo de trabajo empresarial. | | Preguntar si existe un respaldo, pero no a qué cambia | Los modelos de respaldo pueden cambiar la salida, los límites de datos, las características y el costo. | Aprobar el respaldo por clase de tráfico y contrato de modelo. | | No guardar los ID de solicitud | El soporte no puede conectar de manera confiable los registros del cliente con los registros de enrutamiento. | Agregar la captura de ID de solicitud a cada ruta de producción. | | Ignorar el alcance de la cuota | Puede existir una ruta de respaldo, pero aun así puede limitarse durante el tráfico pico. | Almacenar la evidencia de la cuota del proveedor ascendente y del gateway juntas. | | Asumir que los créditos son automáticos | Muchos SLA requieren un acuerdo por separado, un proceso de reclamación o una revisión caso por caso. | Guardar los términos de compensación y el propietario de la reclamación antes del lanzamiento. | | Revisar solo en el momento de la compra | Los catálogos de modelos, las cuotas y las rutas de soporte cambian. | Agregar activadores de renovación y nuevas verificaciones impulsadas por incidentes. |
Preguntas frecuentes
¿Qué es un SLA de gateway de IA?
Un SLA de gateway de IA define el objetivo de disponibilidad, el alcance, las exclusiones, el proceso de soporte y las compensaciones para los servicios de gateway que opera un proveedor. Puede que no cubra las interrupciones de proveedores de modelos de terceros, los límites de cuota, el comportamiento del modelo, la configuración del cliente o todos los resultados de respaldo.
¿Un SLA de gateway de IA garantiza que todas las solicitudes de modelo tengan éxito?
No. Un SLA de gateway de IA puede cubrir la disponibilidad del gateway mientras excluye fallas del proveedor ascendente, límites de velocidad del proveedor, cambios de política, comportamiento del modelo, credenciales del cliente, mantenimiento programado o problemas del lado del cliente. Verifique el texto de exclusión y la evidencia de la ruta.
¿Qué debería preguntar el departamento de adquisiciones sobre el respaldo de modelos?
El departamento de adquisiciones debería preguntar qué errores activan el respaldo, qué modelos o proveedores son respaldos aprobados, si el respaldo cambia el manejo de datos o el comportamiento de la salida, cómo se facturan los reintentos y dónde se almacena la evidencia de la ruta después de un incidente.
¿Qué evidencia debería recibir el soporte durante un incidente de SLA?
El soporte debería recibir el correo electrónico de la cuenta, el punto de conexión afectado, los ID de solicitud, las marcas de tiempo, los mensajes de error, el ID del modelo, la clase de ruta, el resumen del impacto y el comportamiento de reintento del cliente. El SLA público de Flatkey actualmente solicita varios de estos campos, incluyendo el punto de conexión, los ID de solicitud, las marcas de tiempo, los errores y el resumen del impacto.
¿Los créditos de servicio son automáticos?
No siempre. El SLA público de Flatkey establece que no se crean créditos de servicio automáticos, reembolsos, penalizaciones o daños liquidados a menos que un acuerdo escrito por separado indique lo contrario. Los compradores deben confirmar la cláusula de compensación, el plazo de reclamación y la ruta de aprobación.
¿Con qué frecuencia deben los equipos revisar un SLA de gateway de IA?
Revise un SLA de gateway de IA en el momento de la compra, la renovación, un cambio importante de ruta, una nueva familia de modelos, una nueva clase de tráfico de producción, un cambio de precios, un cambio de cuota y después de cada incidente material o casi incidente.
Recomendación final
Un SLA de gateway de IA solo es útil cuando se puede probar. Comience con el SLA público o contratado, separe el alcance del gateway del alcance del proveedor ascendente, ejecute pruebas de enrutamiento y respaldo, guarde los ID de solicitud, defina la evidencia de soporte y agregue activadores de renovación.
Flatkey puede ayudar a los equipos a centralizar el acceso a modelos, el enrutamiento, la revisión de precios y la evidencia de uso detrás de un único flujo de trabajo de gateway. Antes del lanzamiento a producción, verifique el modelo exacto, el punto de conexión, el comportamiento de la ruta, el proceso de soporte y la evidencia del SLA para su cuenta. Luego, obtenga una clave cuando esté listo para probar un flujo de trabajo de SLA de gateway de IA con tráfico real de preparación.
