Um SLA de gateway de IA pode parecer simples até o primeiro incidente com um modelo. Um comprador vê uma porcentagem de disponibilidade, um endereço de suporte e uma promessa de que o gateway roteia as solicitações. A equipe de produção ainda precisa responder a perguntas mais difíceis: qual endpoint está coberto, qual provedor upstream falhou, se o fallback alterou o contrato do modelo, quais evidências o suporte precisa e se alguma solução é automática.
Use esta lista de verificação de SLA de gateway de IA para transformar a linguagem do fornecedor em um arquivo de evidências. O objetivo não é negociar por slogans. O objetivo é saber o que o SLA cobre, o que ele exclui, como o roteamento e o fallback são comprovados e o que sua equipe deve revisar antes da renovação.
Especificamente para o Flatkey, o Contrato de Nível de Serviço público, verificado em 6 de julho de 2026, diz que o escopo coberto é o painel hospedado, o gateway de API, o roteamento, a medição e os serviços de conta que o Flatkey opera diretamente. Ele visa 99,5% de disponibilidade mensal para os endpoints cobertos, exclui interrupções de provedores de modelos de IA de terceiros e falhas do lado do provedor, solicita que os clientes enviem IDs de solicitação, carimbos de data/hora, erros, endpoint, e-mail da conta e resumo do impacto para o suporte, e não cria créditos automáticos, a menos que um acordo por escrito separado diga o contrário. Trate isso como a evidência inicial e, em seguida, verifique sua conta, classe de tráfego, política de fallback e processo de suporte antes que o tráfego de produção dependa disso.
Resposta Rápida: Perguntas sobre SLA de Gateway de IA
| Área do SLA | Pergunte isto antes de assinar ou renovar | Evidências a serem guardadas | |---|---|---| | Serviço coberto | Quais funções de painel, gateway de API, roteamento, medição, conta e suporte estão cobertas? | URL do SLA atual, cronograma do contrato, lista de endpoints e capturas de tela datadas. | | Cálculo da disponibilidade | A disponibilidade é medida pelo monitoramento do fornecedor, sondas do cliente, status público ou um relatório contratual? | Relatório de disponibilidade mensal, log de sondas, exportação de incidentes e método de cálculo. | | Provedores de terceiros | Interrupções de modelos upstream, limites de taxa, restrições regionais, alterações de modelo e falhas do lado do provedor são excluídas? | Links de status do provedor, corpos de erro do modelo, logs de rota e texto de exclusão do fornecedor. | | Roteamento | Qual modelo, provedor, conta, região ou grupo foi tentado primeiro? | ID da solicitação, rota selecionada, ID do modelo, família de endpoints, proprietário da chave e carimbo de data/hora. | | Fallback | Quais erros acionam o comportamento de nova tentativa, fallback, enfileiramento ou falha fechada (fail-closed)? | Política de fallback, rastreamento de rota, contagem de novas tentativas, modelo final e prova de saída aceita. | | Suporte | Quais evidências devem ser enviadas e qual caminho de severidade se aplica? | Modelo de ticket, IDs de solicitação, endpoint, carimbos de data/hora, erros, resumo do impacto e cronograma de resposta. | | Soluções | Os créditos de serviço são automáticos, caso a caso ou apenas em um acordo por escrito separado? | Cláusula de solução do SLA, aditivo contratual, solicitação de crédito e aprovação financeira. | | Renovação | O que deve ser revisado antes do próximo período? | Registro de incidentes, exceções de fallback, resultados de suporte, eventos de cota, alterações de preços e aprovações de rota. |
A resposta prática sobre o SLA de gateway de IA é esta: separe a responsabilidade do gateway da responsabilidade do provedor upstream e, em seguida, teste a rota. Se o comprador não puder inspecionar a rota, o fallback, o ticket de suporte e as evidências de disponibilidade mensal, o SLA não está pronto para a governança de produção.
Separe o Tempo de Atividade do Gateway da Disponibilidade do Modelo Upstream
A primeira pergunta sobre o SLA de gateway de IA é se o fornecedor está prometendo o gateway, o modelo upstream ou o resultado final completo para o usuário. Essas são camadas diferentes.
O SLA público atual do Flatkey torna essa separação explícita: os serviços operados pelo Flatkey cobertos estão no escopo, enquanto provedores de modelos de terceiros, interrupções de provedores, limites de taxa de provedores, alterações de políticas, restrições regionais, comportamento do modelo e falhas do lado do provedor estão fora do SLA. Isso é comum o suficiente na compra de gateways para que o setor de compras nunca deva tratar uma única porcentagem de tempo de atividade como "todas as solicitações de modelo serão bem-sucedidas".
Use esta divisão no arquivo de evidências:
| Camada | O que pode falhar | Evidência do comprador | |---|---|---| | Cliente e SDK | URL base incorreta, chave incorreta, endpoint não suportado, tempo limite muito baixo, erro de análise. | Configuração do cliente, versão do SDK, corpo da solicitação, tempo limite e logs locais. | | Gateway | Autenticação, roteamento, medição, endpoint do gateway, painel, log de uso, serviços de conta. | SLA do gateway, ID da solicitação, rastreamento de rota, status, registro de uso e ticket de suporte. | | Provedor upstream | Interrupção do provedor, cota do provedor, desativação do modelo, bloqueio regional, rejeição de política, comportamento específico do modelo. | Status do provedor, página de cota do provedor, corpo do erro upstream, ID do modelo e decisão de fallback. | | Fluxo de trabalho de negócios | Impacto no usuário, profundidade da fila, saída degradada, objetivo interno não alcançado. | Cronograma do incidente, classe de tráfego afetada, resumo do impacto no cliente, decisão de reversão. |
É aqui que um SLA de gateway de IA se torna operacional. O comprador deve solicitar um rastreamento no nível da rota, não apenas um número de tempo de atividade mensal.
Perguntas sobre Roteamento e Fallback
O roteamento é a parte de um SLA de gateway de IA que mais frequentemente é subespecificada. Um gateway pode suportar vários modelos e provedores, mas a confiabilidade da produção depende de qual rota foi permitida para cada classe de tráfego.
A documentação oficial de gateway de outros fornecedores mostra por que os detalhes são importantes. A documentação do AI Gateway da Vercel descreve o roteamento de provedores e os fallbacks de modelos, incluindo controle sobre a ordem de roteamento e o comportamento de fallback. Sua documentação de fallback de modelo diz que backups podem ser tentados em ordem quando um modelo principal falha ou está indisponível. A documentação do Pydantic AI Gateway descreve grupos de roteamento onde a prioridade e o peso decidem o failover ou o balanceamento de carga, com fallthrough quando um membro de maior prioridade está indisponível, com limite de taxa ou com erros. Estes são exemplos de categorias úteis, não garantias do Flatkey. Eles mostram as perguntas que um comprador deve fazer a qualquer gateway, incluindo o Flatkey.
Use esta tabela de roteamento antes de aprovar o fallback automático:
| Sinal de falha | Pergunta padrão do comprador | Evidência segura | |---|---|---| | Gateway 401 ou 403 | O escopo da chave, conta, ambiente ou política estava errado? | Proprietário da chave, ambiente, erro de autenticação e registro de negação de política. | | Modelo não encontrado | O modelo solicitado existia no catálogo atual para esta conta? | Linha do catálogo, ID do modelo, família de endpoints e prova de data de publicação ou data de teste. | | Provedor 429 | A cota desta conta, região, modelo ou implantação foi esgotada? | Página de cotas, corpo do erro upstream, dados de retry-after e política de fallback. | | Provedor 5xx ou timeout | O gateway deve tentar novamente, mudar para uma rota do mesmo modelo, enfileirar ou falhar fechado? | Rastreamento de rota, contagem de tentativas, limite de timeout, resultado final e registro de custo. | | Limite de contexto ou entrada não suportada | O fallback é permitido se o modelo de backup alterar o contexto, as ferramentas, a visão ou o comportamento de mídia? | Contrato do modelo, teste de funcionalidade, verificação de saída aceita e aprovação do proprietário do produto. | | Rejeição por política ou segurança | Outro provedor tem permissão para receber a mesma solicitação? | Limite de dados, aprovação do provedor, classificação do prompt e aprovação de conformidade. | | Falha desconhecida | Qual é a condição de parada? | Runbook de incidentes, número máximo de tentativas, regra de falha fechada e escalonamento para o suporte. |
A evidência mais forte de SLA de um gateway de IA é um rastreamento de rota que nomeia a rota inicial, a regra de fallback, a rota final e o motivo de cada transição ter ocorrido.
O Fallback Nem Sempre é uma Vantagem de Confiabilidade
O setor de compras frequentemente pergunta se o gateway possui fallback automático. As equipes de plataforma devem responder com uma segunda pergunta: fallback para quê?
Uma troca automática de uma conta para outra para o mesmo modelo aprovado pode ser razoável. Uma troca de uma família de modelos para outra pode alterar a qualidade, o tratamento de dados, a latência, o formato de saída, o comportamento das ferramentas, a política de imagem ou vídeo e o custo. Parte do tráfego deve falhar fechado porque um fallback oculto pioraria o incidente.
Defina o fallback por classe de tráfego:
| Classe de tráfego | Postura de fallback | Por quê | |---|---|---| | Chat com o cliente | Use apenas rotas equivalentes aprovadas ou retorne um erro controlado. | A qualidade e a segurança voltadas para o usuário devem permanecer previsíveis. | | Resumo interno | Tente novamente, enfileire ou use uma rota aprovada de menor custo. | A latência pode ser trocada por custo e conclusão. | | Avaliações e benchmarks | Falhar fechado. | Mudanças ocultas no modelo corrompem os dados de comparação. | | Trabalhos em lote sensíveis a finanças | Enfileire ou exija aprovação antes do fallback. | Novas tentativas e modelos de backup podem multiplicar os gastos. | | Fluxos de trabalho de agentes com ferramentas | Fallback somente após o comportamento da chamada de ferramenta ser testado. | Os esquemas de ferramentas e o comportamento de streaming podem diferir por provedor. | | Tráfego regulamentado ou isolado do cliente | Falhar fechado, a menos que o provedor e a região de backup sejam pré-aprovados. | O limite de dados e a evidência de aquisição são mais importantes do que a conclusão automática. |
Este é o teste de propriedade do comprador: execute o mesmo prompt pela rota principal e pela rota de fallback proposta e, em seguida, compare a forma da resposta, os logs, o custo, a latência, a saída aceita e a evidência de suporte. Não trate um SLA de gateway de IA como completo até que a evidência de fallback exista.
Perguntas de Suporte para o Pacote de Evidências
O SLA atual da Flatkey pede aos clientes que entrem em contato com o suporte com o e-mail da conta, o endpoint afetado, os IDs de solicitação, se disponíveis, os carimbos de data/hora, as mensagens de erro e o resumo do impacto. Esse é um modelo útil para qualquer processo de suporte de SLA de gateway de IA.
Antes do lançamento, crie um pacote de suporte com estes campos:
| Campo | Por que é importante | |---|---| | E-mail da conta e workspace | Permite que o suporte encontre o tenant, a chave e o direito corretos. | | Endpoint afetado | Separa incidentes de chat, respostas, mensagens, imagem, vídeo e painel. | | IDs de solicitação | Conecta os logs do aplicativo aos rastreamentos do gateway e upstream. | | Carimbos de data/hora com fuso horário | Impede que a disponibilidade mensal e as janelas de incidentes se desloquem. | | ID do modelo e classe de rota | Mostra qual política de rota e família de provedores estavam envolvidas. | | Mensagens de erro e códigos de status | Separa falhas de autenticação, cota, timeout, provedor e analisador. | | Resumo do impacto | Explica os usuários afetados, receita, trabalhos, profundidade da fila ou fluxo de trabalho interno. | | Novas tentativas do lado do cliente | Mostra se tentativas duplicadas aumentaram o custo ou a carga. | | Ação necessária | Esclarece se você precisa de diagnóstico, desativação de rota, revisão de crédito ou acompanhamento de contrato. |
Vincule este pacote de suporte ao seu processo de uso da API de IA para logs de auditoria. Se os IDs de solicitação e as evidências de rota não estiverem disponíveis após um incidente, o processo de suporte se torna um exercício de memória.
Perguntas sobre Reparação e Crédito
A seção de reparação de um SLA de gateway de IA é importante porque geralmente define o que o comprador pode realmente recuperar. Uma meta de 99,5% sem uma cláusula de crédito é diferente de um SLA comprometido com créditos de serviço automáticos, requisitos de notificação por escrito, exclusões e prazos para reivindicação.
O SLA público da Flatkey afirma que não há créditos de serviço automáticos, reembolsos, penalidades ou multas contratuais, a menos que um acordo por escrito separado forneça uma reparação diferente. Qualquer ajuste de boa vontade, correção de saldo ou remediação de suporte é tratado caso a caso sob o contrato do usuário e as políticas aplicáveis.
Isso não torna o SLA inutilizável. Significa que o setor de compras deve fazer as perguntas certas:
- O SLA público é o acordo completo ou existe um cronograma empresarial separado?
- Se existirem créditos, qual é o prazo para solicitação?
- Que evidências o cliente deve fornecer?
- As interrupções do provedor upstream são excluídas, mesmo quando o gateway selecionou esse provedor?
- A manutenção programada e as ações de segurança de emergência são excluídas?
- A latência, a qualidade do modelo, o throttling e o comportamento de fallback estão cobertos ou apenas a disponibilidade?
- A solução se aplica a saldo pré-pago, créditos em faturas, reembolsos, remediação de suporte ou direitos de rescisão de contrato?
- Quem no departamento financeiro aprova a solicitação final?
A resposta deve estar no mesmo arquivo do fornecedor que a avaliação de risco do fornecedor de API de IA. Os departamentos jurídico e financeiro precisam das mesmas evidências que os engenheiros de plataforma usam durante a revisão de incidentes.
Cotas, Limites de Taxa e Dependências de Provedores
Um SLA de gateway de IA pode ser válido enquanto uma solicitação ainda falha porque uma cota de provedor upstream foi esgotada. É por isso que a evidência de cota pertence à revisão do SLA.
A documentação de cotas do Azure OpenAI da Microsoft diz que os limites de tokens por minuto e solicitações por minuto são definidos por região, assinatura e tipo de modelo ou implantação. A documentação do AWS Bedrock direciona as equipes de forma semelhante para as cotas de serviço para recursos do Bedrock e observa que a inferência do modelo é controlada por cotas de uso de tokens. Esses fatos dos provedores não são promessas da Flatkey. São lembretes de que a configuração da conta upstream pode decidir se o fallback estará disponível durante um incidente real.
Adicione estas verificações ao arquivo de lançamento:
| Verificação de dependência | Evidência | |---|---| | Escopo da cota upstream | Região, conta ou assinatura, modelo, tipo de implantação, TPM/RPM ou equivalente do provedor. | | Escopo da cota do gateway | Chave, equipe, ambiente, grupo de modelos, teto orçamentário e janela de redefinição. | | Orçamento para novas tentativas | Número máximo de novas tentativas, política de jitter/backoff e barreira de proteção de custos. | | Capacidade de fallback | Cota da rota de backup, disponibilidade do modelo e aprovação do provedor. | | Comportamento de throttling | Código de erro, sinal de retry-after, escalonamento para o suporte e tratamento voltado para o usuário. |
Se a cota não for medida pelo mesmo proprietário do roteamento, a revisão do SLA do gateway de IA perderá o modo de falha mais comum: a rota existe, mas a conta não consegue absorver o tráfego de produção.
Revisão de Staging da Flatkey
Para a Flatkey, a prova pública do produto verificada em 6 de julho de 2026 suporta um gateway de API de IA, uma chave de API, a URL base do roteador compatível com OpenAI https://router.flatkey.ai/v1, visibilidade de uso e faturamento orientada por painel, revisão de preços e posicionamento relacionado ao roteamento. O snapshot da API de preços ao vivo retornou success: true, versão de preços a42d372ccf0b5dd13ecf71203521f9d2, 45 linhas de modelo, 48 fornecedores, metadados de endpoint suportados para mensagens Anthropic, Gemini generateContent, geração de imagens, conclusões de chat OpenAI e solicitações de vídeo, além de estados de disponibilidade de available e unknown_failure em todas as linhas.
Use isso apenas como evidência pública datada. Não comprova a solução de SLA da sua conta, nível de suporte, sucesso da rota, elegibilidade para fallback, disponibilidade permanente do modelo, latência, escopo de conformidade ou preços específicos da conta.
Uma revisão de staging do SLA do gateway de IA da Flatkey deve incluir:
- Abra a página de preços atual e selecione o modelo exato ou a família de rotas.
- Confirme a linha do modelo e a família de endpoints em sua conta ou painel.
- Execute uma solicitação de baixo risco através de
https://router.flatkey.ai/v1. - Capture o ID da solicitação, ID do modelo, endpoint, timestamp, status, unidades de uso, evidência de custo e proprietário da chave.
- Execute um teste de falha aprovado: modelo incorreto, limite de cota, timeout ou fallback desativado.
- Confirme onde a evidência de suporte aparece nos logs.
- Decida quais classes de tráfego podem usar fallback e quais devem falhar sem alternativa (fail closed).
- Adicione os campos do pacote de suporte ao runbook de incidentes.
- Salve o SLA atual, preços, prova de rota e caminho de suporte na pasta de evidências do fornecedor.
Quando essa evidência existe, as equipes de plataforma, compras e finanças podem avaliar o mesmo arquivo em vez de discutir com base em capturas de tela.
Checklist de Gatilho de Renovação
Não revise um SLA de gateway de IA apenas uma vez. Adicione gatilhos de renovação para que o arquivo do comprador permaneça atualizado.
| Gatilho | O que verificar novamente | |---|---| | Atualização da página de SLA ou do contrato | Escopo, exclusões, soluções, processo de suporte e detalhes de contato. | | Nova família de modelos | Endpoint, provedor, cota, limite de dados, unidade de preço e política de fallback. | | Nova classe de tráfego de produção | Postura de failover, severidade do suporte e aprovação do proprietário. | | Incidente ou quase acidente | Rastreamento da rota, cronograma de suporte, impacto no usuário, impacto no custo e ação preventiva. | | Mudança na cota do provedor | Capacidade de backup, comportamento de throttling e alocação de tráfego. | | Mudança de preço | Custo por solicitação, orçamento para novas tentativas, custo do modelo de fallback e limite financeiro. | | Revisão de segurança ou conformidade | Escopo de logging, retenção, aprovação do provedor e revisão de acesso. |
Vincule este checklist de volta ao checklist de gateway de API de IA empresarial. O SLA é uma parte do pacote de evidências empresariais, não um selo de confiança autônomo.
Erros Comuns
| Erro | Por que prejudica | Verificação recomendada | |---|---|---| | Tratar uma meta de tempo de atividade do gateway como uma garantia de sucesso do modelo | Provedores upstream, cota, política e comportamento do modelo podem ser excluídos. | Divida as evidências do gateway, do provedor, do cliente e do fluxo de trabalho de negócios. | | Perguntar se existe fallback, mas não para o que ele muda | Modelos de backup podem alterar a saída, o limite de dados, os recursos e o custo. | Aprove o fallback por classe de tráfego e contrato de modelo. | | Não manter IDs de solicitação | O suporte não consegue conectar os logs do cliente aos logs de rota de forma confiável. | Adicione a captura de ID de solicitação a cada rota de produção. | | Ignorar o escopo da cota | Uma rota de backup pode existir, mas ainda assim sofrer limitação durante o pico de tráfego. | Armazene as evidências de cota do upstream e do gateway juntas. | | Presumir que os créditos são automáticos | Muitos SLAs exigem um acordo separado, processo de reivindicação ou revisão caso a caso. | Salve os termos de reparação e o responsável pela reivindicação antes do lançamento. | | Revisar apenas no momento da compra | Catálogos de modelos, cotas e caminhos de suporte mudam. | Adicione gatilhos de renovação e novas verificações orientadas por incidentes. |
Perguntas Frequentes
O que é um SLA de gateway de IA?
Um SLA de gateway de IA define a meta de disponibilidade, o escopo, as exclusões, o processo de suporte e as reparações para os serviços de gateway que um fornecedor opera. Ele pode não cobrir interrupções de provedores de modelos de terceiros, limites de cota, comportamento do modelo, configuração do cliente ou todos os resultados de fallback.
Um SLA de gateway de IA garante que todas as solicitações de modelo sejam bem-sucedidas?
Não. Um SLA de gateway de IA pode cobrir a disponibilidade do gateway, excluindo falhas do provedor upstream, limites de taxa do provedor, alterações de política, comportamento do modelo, credenciais do cliente, manutenção programada ou problemas do lado do cliente. Verifique o texto de exclusão e as evidências da rota.
O que o setor de compras deve perguntar sobre o fallback de modelos?
O setor de compras deve perguntar quais erros acionam o fallback, quais modelos ou provedores são backups aprovados, se o fallback altera o tratamento de dados ou o comportamento da saída, como as novas tentativas são cobradas e onde as evidências da rota são armazenadas após um incidente.
Quais evidências o suporte deve receber durante um incidente de SLA?
O suporte deve receber o e-mail da conta, o endpoint afetado, os IDs das solicitações, os carimbos de data/hora, as mensagens de erro, o ID do modelo, a classe da rota, o resumo do impacto e o comportamento de nova tentativa do cliente. O SLA público da Flatkey atualmente solicita vários desses campos, incluindo endpoint, IDs de solicitação, carimbos de data/hora, erros e resumo do impacto.
Os créditos de serviço são automáticos?
Nem sempre. O SLA público da Flatkey afirma que créditos de serviço automáticos, reembolsos, penalidades ou multas por danos liquidados não são criados, a menos que um acordo por escrito separado diga o contrário. Os compradores devem confirmar a cláusula de reparação, o prazo de reivindicação e o caminho de aprovação.
Com que frequência as equipes devem revisar um SLA de gateway de IA?
Revise um SLA de gateway de IA na compra, na renovação, em grandes mudanças de rota, na adoção de uma nova família de modelos, em uma nova classe de tráfego de produção, em mudanças de preço, em mudanças de cota e após cada incidente material ou quase acidente.
Recomendação Final
Um SLA de gateway de IA só é útil quando se torna testável. Comece com o SLA público ou contratado, separe o escopo do gateway do escopo do provedor upstream, execute testes de rota e fallback, salve os IDs das solicitações, defina as evidências de suporte e adicione gatilhos de renovação.
A Flatkey pode ajudar as equipes a centralizar o acesso ao modelo, o roteamento, a revisão de preços e as evidências de uso por trás de um único fluxo de trabalho de gateway. Antes do lançamento em produção, verifique o modelo exato, o endpoint, o comportamento da rota, o processo de suporte e as evidências de SLA para sua conta. Em seguida, obtenha uma chave quando estiver pronto para testar um fluxo de trabalho de SLA de gateway de IA com tráfego real de preparação.
