Como este tema funciona na sua empresa
Frequentemente aceitam SLA como vem de fornecedor, sem análise crítica. Desafio: não têm expertise para identificar armadilhas. Abordagem: checklist simples de armadilhas comuns (disponibilidade ambígua, sem penalidade, força maior genérica) e revisar com consultor antes de assinar contrato.
Analisam SLA mas podem cair em armadilhas sutis (ex: SLA com exceções genéricas que permitem fornecedor escapar). Desafio: detalhe contratual. Abordagem: análise profunda da linguagem do SLA, busca por brechas, negociação ponto a ponto antes de assinatura.
Risco é menos de não identificar armadilha óbvia, mais de aceitar SLA complexo demais ou com múltiplas brechas sutis. Desafio: orquestração de riscos. Abordagem: processo formal de revisão legal/técnica de SLA com expert internos e externos.
Armadilhas em SLA são brechas, ambiguidades ou cláusulas desfavoráveis em contratos de nível de serviço que permitem fornecedor não cumprir comprometimento, geram disputas, ou deixam cliente desprotegido[1].
Por que SLA ruim é pior que nenhum SLA
SLA ruim cria falsas expectativas. Cliente acredita estar protegido (há um SLA!), mas o SLA tem tantas brechas que fornecedor não pode ser responsabilizado. Resultado: frustração maior que se não houvesse SLA. Pesquisa Gartner mostra 60% dos SLAs têm brechas significativas que impedem cumprimento ou geram disputas. O diferencial de bem avaliar SLA antes de assinar é imediato: não há retrabalho posterior, não há conflito, não há disputa custosa.
As oito armadilhas mais comuns em SLA
1) Uptime exclui manutenção programada: "99.9% de disponibilidade excluindo manutenção programada." Brecha: fornecedor agenda muita manutenção, inflando uptime real. Solução: "Manutenção programada máximo 4h/mês, comunicada com 72h de antecedência, fora de horário de negócio." 2) Sem fórmula explícita: "99% disponibilidade" mas como calcula? Uptime = tempo up / tempo total? Ou "número de acessos bem-sucedidos"? Fornecedor e cliente calculam diferente. Solução: fórmula explícita no contrato. 3) "Melhor esforço" vs. "garantir": "Fornecedor fará melhor esforço para disponibilidade" = não é SLA real, fornecedor não é responsável. Solução: "Fornecedor garante 99%..." 4) Sem remediação: "Violação não gera consequência." Sem desconto, sem crédito. Fornecedor não se importa com cumprimento. Solução: sempre incluir penalidade. 5) Exclusão genérica "força maior": "Sem responsabilidade por força maior." Pode ser usada para qualquer falha. Solução: definir específico (terremoto, mas não queda de energia em datacenter). 6) SLA é limite máximo de performance atual: Se sistema hoje tem 98%, SLA de 98% não oferece margem de segurança. Solução: SLA deve exigir melhoria (ex: 99.5%). 7) Ninguém mede SLA: SLA em contrato, mas ninguém mede, ninguém valida. Papel morto. Solução: incluir responsável de medição, ferramenta de monitoramento. 8) SLA viola legislação: LGPD exige notificação em 72h de violação de dados, mas SLA permite resposta em 7 dias. Ilegal. Solução: validar contra legislação aplicável.
Checklist simples antes de assinar: (1) SLA tem fórmula explícita de cálculo? (2) Penalidade é clara (desconto X%)? (3) Exclusões são específicas (não "força maior" genérica)? (4) Tempo de resposta e resolução estão definidos? (5) "Melhor esforço" aparece no texto? Se sim, remover. Envolver advogado externo para breve revisão se contrato > R$50k.
Análise profunda: (1) validar fórmula contra realidade do sistema (é alcançável?), (2) revisar cada exclusão (é específica ou genérica?), (3) calcular impacto de violação (penalidade compensa risco?), (4) validar contra legislação (LGPD, conformidade setorial), (5) comparar com SLAs de fornecedores similares (benchmarking), (6) testar cálculo com dados históricos (se fornecedor violaria SLA com performance passada?)
Processo formal: (1) equipe legal + técnica + procurement revisa SLA, (2) modelo de risco quantificado (custo de SLA breach vs. custo de negócio), (3) negociação ponto a ponto de exclusões e penalidades, (4) auditoria de conformidade com regulações, (5) ferramenta de monitoramento de SLA em ITSM, (6) auditoria anual de compliance do fornecedor.
Como questionar fornecedor sobre armadilhas
Não seja confrontacional; seja inquisitivo. "Como você calcula uptime? Pode compartilhar fórmula exata?" Escuta a resposta. Se é vaga ("a gente sabe quando está up"), é sinal de que não há processo formal. "O que conta como 'manutenção programada'? Quantas horas mês são aceitáveis?" Se fornecedor não tem resposta pronta, ele não pensou nisto. "Se SLA for violado, qual é a penalidade?" Se não há penalidade documentada, negocie agora. "Quando você acionou 'força maior' nos últimos 2 anos?" Peça exemplos. Você entende o padrão de como usam exclusão.
Validação pré-assinatura: como testar SLA
Se possível, simule SLA com dados históricos: "Usando uptime de 2024, qual seria seu SLA breach rate?" Se fornecedor não consegue responder, SLA não é mensurável. Peça para ver como medem com clientes atuais: "Você pode compartilhar relatório de SLA de cliente similar?" Isso mostra se processo é maduro. Converse com clientes de referência: "Como é acompanhamento de SLA com esse fornecedor? Eles cumprem? Como lidam com violações?" Essa conversa é ouro puro — revela realidade que contrato não mostra.
Sinais de que seu SLA tem armadilhas
Se você se reconhece em três ou mais cenários abaixo, revise SLA antes de assinar ou implemente controles imediatos.
- SLA não tem fórmula explícita de cálculo; é ambíguo como vai ser medido
- Linguagem inclui "melhor esforço", "razoável esforço" em vez de "garante"
- Exclusão por "força maior" não tem definição clara (pode cobrir qualquer coisa)
- Violação não gera penalidade documentada (sem desconto, sem crédito, sem remediação)
- SLA é o mesmo para serviços críticos e operacionais (falta diferenciação por severidade)
- Ninguém na empresa consegue explicar como SLA é medido (falta propriedade)
- SLA já foi violado 3+ vezes em 6 meses, mas relação continua intacta (penalidade é inócua)
- Fornecedor relata SLA em números que parecem irrealisticamente altos (ex: 99.99% em sistema que você sabe que teve problemas)
Caminhos para auditar e corrigir SLA
Viável se você tem expertise jurídica/técnica.
- Perfil necessário: gestor de TI + analista jurídico ou procurador
- Tempo estimado: 2-4 semanas para revisão de SLA existente + teste com dados históricos
- Faz sentido quando: SLA já está em vigor; você quer identificar fraquezas atuais
- Risco principal: viés — equipe responsável pela implementação pode não questionar SLA que ela mesma aceitou
Recomendado para SLA crítico ou antes de assinar novo contrato.
- Tipo de fornecedor: consultores jurídicos especializados em TI, consultores de ITIL, auditores independentes
- Vantagem: revisão objetiva, identificação de armadilhas sutis, proteção legal
- Faz sentido quando: contrato é grande, SLA é crítico, você quer garantia de proteção
- Resultado típico: 4-6 semanas, auditoria completa, relatório de armadilhas identificadas, propostas de correção
Precisa auditar SLA para armadilhas?
O oHub conecta você gratuitamente a consultores jurídicos especializados em contratos de TI, especialistas em ITIL e auditores independentes de SLA. Descreva seu SLA (tipo de serviço, criticidade, preocupações atuais) e receba propostas em menos de 3 minutos, sem compromisso.
Encontrar fornecedores de TI no oHub
Sem custo, sem compromisso. Você recebe propostas e decide se e com quem avançar.
Perguntas frequentes
Como identificar armadilha de "manutenção programada"?
Pergunte: "Como você define 'manutenção programada'? Pode incluir atualizações de segurança? Patches?" Se resposta é ampla, há brecha. Negocie limite: "Máximo 4 horas por mês de manutenção programada, comunicada com 72 horas de antecedência, fora de horário comercial."
Fornecedor propõe SLA muito ambicioso. É sempre problema?
Sim, é sinal de que fornecedor pode não estar pensando criticamente. Se SLA é impossível de atingir, fornecedor frequentemente violará, cliente fica frustrado, relacionamento piora. Melhor: SLA realista que fornecedor cumpre consistentemente. Pesquisa mostra satisfação 75%+ com SLA realista vs. 40% com ambicioso.
Como proteger contra "força maior"?
Não use "força maior" genérica. Defina específico: "Força maior = terremoto > 5.0, furacão categoria 3+, guerra, lei marcial. NÃO inclui: falha de fornecedor de internet, queda de energia em datacenter, erros operacionais, epidemia (previsível)." Seja muito específico no contrato.
O que fazer se fornecedor relata SLA suspeito de alto?
Audite. Peça logs e fórmula de cálculo. Compare com dados históricos de incidentes (você sabe quando sistema teve problema). Se números não batem, escale: "Números reportados não correspondem aos dados de incidentes. Solicito revisão da metodologia de cálculo."
Posso mudar SLA depois que contrato está em vigor?
Formalmente, SLA é contratual. Mudança requer emenda assinada por ambos. Na prática, você pode negociar: "SLA atual não está funcionando para ambos. Vamos revisá-lo?" Fornecedor pode ser receptivo se clima é bom. Negocie mudança em renovação de contrato (mais fácil que mudar no meio).
Como validar que SLA é mensurável antes de assinar?
Pergunta-chave: "Como você vai medir isto? Qual ferramenta? Quem é responsável? Com que frequência reporta?" Se fornecedor tem processo claro (sistema de monitoramento, responsável designado, frequência definida), é bom sinal. Se resposta é vaga, SLA é letra morta.