Como criar um SaaS de IA para monitorar SLA de fornecedores
Eu explico como ligar contratos, chamados e telemetria para avisar antes do descumprimento, documentar a evidência e melhorar a próxima negociação.
Por Cesar A. Machado · · 4 min
A IA sugere cláusulas; uma regra aprovada calcula o cumprimento.
SLA contratual, SLO interno e indicador observado precisam permanecer separados.
O alerta deve chegar antes do prazo, com evidência e ação previstas no contrato.
O desperdício aparece depois da assinatura
Muitas empresas negociam prazo de atendimento, disponibilidade, tempo de solução e crédito por falha, mas voltam ao contrato apenas durante uma crise. Chamados ficam em um portal, métricas em outro e a cláusula em PDF. Quando alguém percebe o descumprimento, o prazo para contestar pode ter passado ou a evidência está incompleta. Eu vejo aí um bom problema para um SaaS: unir compromisso e evento enquanto a operação acontece.
O produto não deveria prometer “interpretar qualquer contrato sozinho”. Eu o definiria como um registro aprovado de obrigações, fontes e cálculos. A IA reduz o trabalho de localizar cláusulas, classificar chamados e resumir incidentes. Pessoas autorizadas confirmam a regra. Depois disso, o cálculo é determinístico e reproduzível.
Separe SLA, SLO e SLI
A documentação do Google Cloud define SLI como medida de desempenho, SLO como objetivo desejado e error budget como a parcela de falha tolerada: https://docs.cloud.google.com/stackdriver/docs/solutions/slo-monitoring. Eu acrescentaria uma terceira camada empresarial: o SLA é o compromisso contratual e pode conter calendário, exceções, consequência e procedimento de notificação. Misturar esses conceitos cria cobrança errada.
Camada
Exemplo
Quem aprova
SLI
Chamados respondidos em até 2 horas
Operação e dados
SLO interno
98% no mês
Gestor do serviço
SLA contratual
95% em horário comercial
Negócio e jurídico
Consequência
Crédito mediante contestação
Contrato aprovado
Um objetivo interno mais rigoroso pode avisar antes de o contrato ser violado. Isso é importante: um alerta que chega depois do fechamento do mês apenas documenta a perda; um orçamento de erro consumido rapidamente permite pedir correção, trocar rota ou preparar a contestação.
Use IA para extrair candidatos, não para criar obrigações
Eu enviaria o contrato para uma etapa de extração estruturada: serviço, métrica, limite, janela, calendário, exclusões, fonte aceita, consequência e prazo de reclamação. Cada campo mostraria página e trecho de origem. Se houver ambiguidade, o estado fica “requer revisão”; ele não vira regra ativa. O histórico conserva documento, versão, aprovador e data.
O NIST descreve o AI RMF como apoio para incorporar confiabilidade ao desenho, uso e avaliação de sistemas de IA: https://www.nist.gov/itl/ai-risk-management-framework. Para este produto, isso significa testar extração com contratos conhecidos, medir campos incorretos, impedir ativação silenciosa e revisar o desempenho quando modelos ou documentos mudarem.
Defina qual evidência manda em cada indicador
Disponibilidade pode vir de sondas independentes; tempo de resposta, do sistema de chamados; prazo de entrega, do ERP. Logs, métricas e traces observam aspectos diferentes, como resume a documentação do OpenTelemetry: https://opentelemetry.io/docs/concepts/signals/. Eu guardaria o evento bruto, o identificador do caso, o horário, a origem e a regra usada no cálculo.
Quando duas fontes discordam, o sistema não deve escolher escondido. A prioridade precisa estar no cadastro do indicador e refletir o contrato. Já expliquei esse princípio de fonte oficial em https://blog.cesarmachado.com/artigo/integracao-de-sistemas-fonte-da-verdade/. Uma medição que não pode ser reconstruída dificilmente sustenta uma cobrança séria.
Faça o motor antecipar, registrar e escalar
Eu executaria o cálculo em janelas idempotentes. O mesmo conjunto de eventos e a mesma versão de regra devem produzir o mesmo resultado. O alerta informa indicador, consumo do limite, casos responsáveis, prazo restante e ação prevista. Para evitar tempestade, um incidente aberto recebe atualizações; não nasce um novo alerta a cada leitura.
A escala pode ter três níveis. Primeiro, operação investiga dado ou incidente. Depois, gestão aciona o fornecedor. Por fim, compras ou jurídico avaliam crédito, rescisão ou renovação. Cada transição registra ator e comentário. A IA pode preparar um resumo com links para evidências, mas nunca enviar contestação contratual sem revisão.
Meça retorno sem contar alertas como economia
Em um exemplo hipotético, a empresa paga R$ 40 mil por mês a fornecedores críticos e identifica R$ 3 mil em créditos contratuais válidos, além de evitar uma parada por alerta antecipado. Eu não somaria o valor estimado da parada como dinheiro ganho sem uma metodologia aprovada. Compararia créditos efetivamente aceitos, horas de conferência reduzidas e melhora do cumprimento depois das ações.
Comece com um contrato e dois indicadores
Eu escolheria um fornecedor relevante, um contrato vigente e dois indicadores cuja fonte já existe. Faria a extração assistida, obteria aprovação interna e recalcularia três meses históricos. Se o resultado reproduzir a conferência manual, ligaria alertas apenas para a equipe responsável. Critérios de parada incluem cláusula ambígua, dado ausente, divergência recorrente e acesso além do necessário.
Se você quer avaliar esse SaaS na sua operação, envie o tipo de contrato, os indicadores e onde os eventos são registrados em https://blog.cesarmachado.com/contato. Eu começaria pelo compromisso que hoje exige mais conferência manual ou deixa mais dinheiro sem evidência.
Contrato guardado em PDF não protege margem. O compromisso precisa virar uma regra observável enquanto ainda existe tempo para agir.
Quer aplicar isso na sua empresa?
Converse comigo sobre o processo que você quer melhorar e os critérios para começar com segurança.
Os projetos são apresentados pelo problema e pela engenharia envolvida, preservando informações internas. O objetivo é mostrar como decisões de produto, arquitetura e operação se conectam.
Um projeto começa com uma pergunta de negócio, avança por uma primeira versão controlada e só cresce quando os dados mostram que a solução cabe na operação.
{{ item.num }}
{{ item.title }}
{{ item.text }}
LIMITES CLAROS
A confiança também está no que o sistema não promete.
Empresas de 20 a 100 pessoas, com um processo real para melhorar.
O ponto de partida é um processo específico, com responsável, volume e impacto identificáveis. A solução precisa caber na capacidade da equipe, produzir evidência e preservar controle sobre decisões importantes.
→{{ item }}
Tecnologias e camadas
A FERRAMENTA SEGUE O PROCESSO
{{ item }}
SE FIZER SENTIDO
Descreva um processo que você gostaria de entender melhor.
Envie o fluxo atual, o volume aproximado e o principal gargalo. A primeira conversa serve para entender o problema e avaliar o próximo passo mais proporcional.
Ferramentas
Clique em uma ferramenta para abrir. Conteúdo de cada uma a definir.
Kit atual
{{ t.num }}
{{ t.title }}
{{ t.desc }}
{{ t.state }}
Portfólio
Projetos de software e ecossistemas construídos com engenharia de IA. Conteúdo de cada caso a definir.
{{ caseCount }}
Projetos
capa do projeto{{ p.num }}
{{ p.kind }} · {{ p.year }}
{{ p.title }}
{{ p.desc }}
{{ tg.label }}
ABRIR CASO
{{ detail.num }}{{ detail.kind }}
{{ detail.title }}
{{ detail.desc }}
{{ m.k }}
{{ m.v }}
imagem principal do caso
{{ bl.title }}
{{ bl.hint }}
Briefing
3 PASSOS · CERCA DE 1 MINUTO
Toque nas opções que descrevem seu projeto. Só o último passo pede digitação.
Briefing recebido
Obrigado. Retorno pelo e-mail informado com as próximas perguntas.
