A compra de IA em empresa segue um guião conhecido: alguém mostra uma demo, o sistema responde bem três vezes seguidas, a sala acena e assina-se. Ninguém abre o separador do acordo de nível de serviço. Seis meses depois, numa terça-feira de manhã, o agente que responde a clientes deixa de responder —e aí começa a conversa que devia ter acontecido antes de assinar: quem arranja isto, em quanto tempo, e o que acontece se não o arranjar?
A tese numa frase: escolhes fornecedor pela demo e convives com ele pelo suporte. E o SLA que julgas ter comprado costuma falhar em três pontos ao mesmo tempo: não cobre o plano que estás a usar, mede disponibilidade em vez de medir se o sistema faz bem o seu trabalho, e não diz absolutamente nada sobre quanto tempo vai existir o modelo de que depende a tua operação.
O suporte e o SLA do teu fornecedor de IA não cobrem o que julgas
Comecemos pelo básico e menos verificado: quase nenhum plano de entrada traz SLA. O compromisso de disponibilidade vive no contrato enterprise, e os restantes clientes operam com o melhor esforço do fornecedor e um fórum. Não é uma suspeita: está escrito nas páginas deles.
Na OpenAI, os 99,9% de disponibilidade e os compromissos de latência estão amarrados ao Scale Tier, e a própria página di-lo sem rodeios: é uma oferta disponível para clientes Enterprise, a que se acede a falar com vendas. O pagamento por uso corrente não traz esse compromisso. Além disso, o veículo muda com a geração de modelo: o Scale Tier aplica-se a modelos anteriores ao GPT-5.6, e daí para a frente a conversa passa para o Reserved Tier. Se o teu contrato de nível de serviço está amarrado a um produto que se reforma com o modelo, a tua cobertura tem prazo de validade mesmo que o papel não o traga escrito.
O caso da n8n é ainda mais nítido, porque põe preço na fronteira. O plano Business custa 667 € por mês com faturação anual, e na própria página de preços lê-se que o Business é uma opção self-service e que o suporte dedicado só existe no Enterprise. Ou seja: podes estar a pagar quase oitocentos euros por mês e o teu canal de suporte oficial continua a ser o fórum da comunidade. Não é um abuso —está publicado e é coerente com o modelo deles— mas é exatamente o tipo de pormenor que ninguém olha na reunião de compra e que aparece no dia em que o fluxo crítico cai.
Um SLA mede que esteja ligado, não que acerte
Aqui está o ponto que sai mais caro, porque é conceptual e não se resolve a pagar mais. Um acordo de nível de serviço de IA mede disponibilidade e, com sorte, latência. A página do Scale Tier da OpenAI, por exemplo, publica compromissos de velocidade do tipo «99% acima de 50 a 100 tokens por segundo», medidos sobre a latência mediana em janelas de cinco minutos. É um compromisso sério e verificável. E não diz nada sobre se a resposta estava correta.
Leva-o ao extremo para o veres claro: um modelo que responde disparates a toda a velocidade e sem cair cumpre os 99,9% com distinção. O SLA está satisfeito; a tua operação, partida. A qualidade —que o agente classifique bem, que não invente, que não responda uma barbaridade a um cliente— não está em nenhum contrato de infraestrutura, porque não é um problema de infraestrutura. É teu. E por isso o trabalho de fixar o limiar aceitável e medi-lo com casos reais não se delega no fornecedor.
| O que julgas que o SLA cobre | O que cobre de verdade | Quem responde |
|---|---|---|
| Que o sistema funcione | Que o serviço esteja disponível | O fornecedor, com créditos |
| Que responda depressa | Às vezes, e só em planos altos | O fornecedor, se o assinaste |
| Que responda bem | Nada. A qualidade não está no SLA | Tu |
| Que o modelo continue a existir | Nada. Isso vai pela política de retirada | Tu, a migrar |
| Que a tua integração não parta | Nada. Os parâmetros também são descontinuados | Tu |
As duas últimas linhas são as que surpreendem, e merecem secção à parte.
O relógio que ninguém olha: quanto vive o modelo de que dependes
O teu sistema não depende «da IA»: depende de um modelo concreto, com nome e versão, que um dia é retirado. A Anthropic documenta-o com uma clareza que se agradece e que convém ler pelo que é —um compromisso mínimo, não uma promessa de permanência—: avisa com pelo menos 60 dias antes de retirar um modelo publicado aos clientes com implementações ativas.
Sessenta dias soam a muito até os olhares no calendário real. O próprio histórico de retiradas mostra-o: o Claude Opus 4.1 foi marcado como obsoleto a 5 de junho de 2026 e retirado a 5 de agosto de 2026. O Claude Sonnet 4 e o Opus 4 foram anunciados a 14 de abril de 2026 e retirados a 15 de junho. Dois meses, do aviso ao desligar. Nesse prazo tens de te aperceber, testar o substituto contra os teus casos reais, ver o que se degrada, ajustar os prompts que dependiam do comportamento do modelo velho e implementar. Se a tua operação descobre o email do aviso ao fim de quarenta dias, não tens dois meses: tens três semanas.
E há um pormenor que parte planeamentos inteiros: a data depende de onde compras. A documentação da Anthropic assinala que as plataformas operadas por parceiros —Amazon Bedrock e Google Cloud— fixam os seus próprios calendários de retirada, por isso o mesmo modelo pode ter estados e datas diferentes consoante o sítio por onde o consomes. Se o teu contrato de nuvem e o teu contrato de modelo são distintos, tens dois relógios e nenhum te avisa do outro.
A versão fina do problema nem sequer é o modelo: são os parâmetros. A Anthropic documenta que «temperature», «top_p» e «top_k» estão obsoletos a partir do Claude Opus 4.7 e devolvem um erro 400 se os puseres num valor diferente do predefinido. Traduzido: uma linha de código que funcionava há dois anos passa a partir a chamada. Isso não é uma queda de serviço —o SLA continua impecável— mas o teu agente deixou de trabalhar da mesma maneira.
As cinco perguntas que há mesmo que fazer antes de assinar
Não é preciso um departamento jurídico para te blindares. São precisas cinco perguntas, por escrito, e guardar as respostas:
- O SLA aplica-se ao meu plano? E se não, quanto custa o plano que o traz. Muitas vezes a resposta transforma uma compra barata numa decisão diferente.
- O que mede exatamente e como se reclama? Disponibilidade mensal, latência, ambas. E sobretudo: os créditos são automáticos ou tenho de os reclamar eu, com prova e dentro de uma janela? Se for a segunda —e costuma ser—, alguém da tua equipa tem de estar a monitorizar para poder reclamar.
- Qual é o canal de suporte real e o seu tempo de resposta? Fórum, email ou pessoa com nome. Um tempo de resposta comprometido por escrito vale mais do que um logótipo de «suporte 24/7» no site.
- Qual é a política de retirada de modelos e quanto aviso dão? E com a resposta na mão: a minha equipa tem capacidade de migrar e revalidar nesse prazo, com os meus casos reais?
- O que acontece aos meus dados se me for embora? Formato de saída, prazo de eliminação e se o fornecedor treina com o que lhe mandas. É a pergunta que mais incomoda e a que mais depressa revela com quem estás a lidar.
O que nenhum SLA te vai dar: o turno de piquete
Mesmo que assines o melhor contrato do mercado, fica um buraco que nenhum fornecedor cobre e que é o que de facto dói. Quando o teu agente deixa de funcionar, o normal não é que o fornecedor tenha caído: é que uma API ao lado mudou um campo, que o volume triplicou, que alguém mexeu num prompt ou que o caso raro apareceu por fim. Aí não há a quem ligar. A resposta é tua.
Isso significa quatro coisas nada glamorosas, que são exatamente o trabalho de operar IA: alguém que vigie e se aperceba antes do cliente, alguém de piquete com autorização para parar o sistema, um procedimento escrito do que se faz quando falha —a manutenção das automações não é opcional, é metade do projeto— e um enquadramento de controlo que decida quem pode desativar o quê, que é do que trata a governação e o controlo da automação. Se estas quatro peças não têm dono, o teu SLA é um papel bonito.
A nossa posição é simples e pouco comercial: o SLA do fornecedor cobre a parte dele, e a parte dele é a mais pequena. A grande —que o sistema faça bem o trabalho, que alguém se aperceba quando deixa de o fazer e que o negócio não pare enquanto se arranja— é uma função operacional contínua que há que montar. É precisamente o que fazemos com a gestão de incidentes de agentes de IA: turno, procedimento, contenção e postmortem, para que a queda seja um incidente gerido e não uma manhã perdida.
A conclusão, sem enfeite
Um SLA é uma transferência de risco muito parcial e muito bem delimitada: o fornecedor devolve-te uns créditos se o serviço dele não esteve disponível. Não te devolve o cliente que se foi, nem o fecho que atrasou, nem as três semanas que te comeu migrar de modelo à pressa. Lê-o a perceber isso e assinarás melhor. Lê-o à espera de que te proteja de tudo e levas a surpresa numa terça-feira de manhã.
Os outros escolhem fornecedor pela demo e descobrem o suporte quando já não há volta atrás. Tu podes fazer cinco perguntas antes de assinar e montar o turno de piquete que nenhum contrato inclui. Não é glamoroso. É o que faz com que o sistema continue a funcionar na terça-feira.