SLA para agentes de IA: o que definir por escrito e o que evitar

Um SLA para agentes de IA é um conjunto escrito de compromissos de serviço sobre aquilo que o fornecedor realmente controla: se o agente e suas conexões estão disponíveis, em quanto tempo os problemas são reconhecidos, o que o agente pode fazer, o que fica registrado e como os incidentes são tratados. Ele não deve prometer que toda resposta será correta, porque ninguém consegue garantir isso com honestidade. Escreva o serviço, os limites e as evidências, e trate a qualidade das respostas como algo que os dois lados medem em intervalos combinados.

Principais pontos

• Comprometa-se com o que o fornecedor controla: disponibilidade do serviço e das conexões, resposta a incidentes, controle de mudanças e registros.
• Não prometa que toda resposta está correta. Defina como a qualidade é medida, com que frequência e o que acontece quando os resultados pioram.
• Trate limites de aprovação e permissões como termos de serviço com responsáveis nomeados, e não como uma configuração que alguém mudou uma vez.
• Defina o que é um incidente para um agente, incluindo falhas silenciosas, como uma conexão expirada ou uma memória desatualizada.
• Inclua termos sobre dados, memória e saída, para que a configuração e o contexto do agente continuem utilizáveis pela sua empresa.

Por que a promessa comum de disponibilidade não basta para um agente?

Um SLA tradicional de software responde a uma única pergunta: o serviço está respondendo? Para um agente, essa é a pergunta menos interessante. Um agente pode estar totalmente no ar e ainda assim ser inútil, porque a conexão com a agenda expirou durante a noite, a memória guarda uma instrução que foi substituída no mês passado ou o modelo por trás dele mudou de comportamento após uma atualização.

Um agente é formado por várias partes trabalhando juntas: um modelo, um harness ao redor dele, memória, ferramentas, canais e permissões. Cada parte pode falhar sozinha, e cada uma tem um responsável diferente. Algumas delas, como o serviço do modelo, ficam com um terceiro que nem você nem seu fornecedor controlam. Um bom acordo não finge o contrário. Ele divide o agente em partes, diz quem responde por cada uma e deixa claro o que está fora do controle de todos e como isso será comunicado.

Há um segundo motivo para a promessa simples falhar. Donos de empresa muitas vezes leem o SLA como garantia de resultado. Se o documento diz que o agente vai “atender os chamados de suporte corretamente”, o que existe ali é uma esperança, não um compromisso, e você criou uma disputa à espera de acontecer. O objetivo é o oposto: compromissos estreitos o bastante para que os dois lados possam verificar se foram cumpridos.

Quais compromissos de serviço vale a pena escrever?

Comece pelos compromissos que podem ser observados e que o fornecedor consegue influenciar. Estes são os que merecem estar por escrito:

• Escopo de disponibilidade: quais componentes estão cobertos (o canal em que o agente fala, o harness que o executa, cada conexão com ferramentas) e quais ficam de fora, como quedas de terceiros, com a promessa de comunicá-las.
• Prazos de reconhecimento e resposta: em quanto tempo um incidente é reconhecido e em quanto tempo o trabalho começa, por gravidade e em quais horários. Use o horário em que sua equipe realmente trabalha.
• Expectativas de tempo por tarefa: uma faixa esperada para cada tipo de tarefa, apresentada como meta revisada em conjunto, não como garantia. Se precisar de um método para definir isso, veja o guia sobre orçamento de latência.
• Registros e retenção: o que cada execução grava, por quanto tempo os registros são mantidos e quem pode lê-los.
• Controle de mudanças: aviso prévio antes de alterações no modelo, nas instruções, nas ferramentas ou nas permissões, e a possibilidade de desfazer uma mudança.
• Frequência de avaliação: com que frequência o agente é testado contra um conjunto de casos combinado e como os resultados são compartilhados.
• Relatórios: um resumo periódico de incidentes, escalonamentos, aprovações e ações corretivas em aberto.
• Dados e saída: onde ficam a memória e a configuração, de quem são, como são exportadas e como são apagadas.

Repare no que falta: qualquer promessa sobre o conteúdo de uma resposta específica. Tudo nessa lista é promessa de serviço, de evidência ou de processo. Isso é proposital, e é o que torna a lista exigível.

O item de registros merece atenção extra, porque sem registros nenhuma outra cláusula pode ser verificada. Se você não sabe o que pedir, o texto sobre o que registrar na observabilidade de agentes apresenta um mínimo prático. Vale também conhecer a ideia geral de traces, métricas e logs descrita no material de introdução à observabilidade do projeto OpenTelemetry, na qual esses registros se apoiam.

Como tratar a qualidade sem garanti-la?

A qualidade é onde a maioria dos acordos sobre agentes erra, em uma de duas direções. Ou o fornecedor se recusa a dizer qualquer coisa sobre ela, e você fica sem recurso, ou o documento promete uma precisão que não consegue entregar. Existe um meio-termo viável: garanta o processo, não o resultado.

Na prática, isso significa três elementos escritos.

• Um conjunto de testes compartilhado. Você e o fornecedor combinam exemplos reais do seu trabalho, com o resultado que você considera aceitável para cada um. Montar esse conjunto é uma tarefa administrável, e o guia sobre conjunto de testes de referência explica como.
• Uma frequência e um limite. O fornecedor roda o conjunto de testes em um calendário definido e após qualquer mudança relevante. Os dois combinam de antemão qual nível de resultado dispara uma revisão. Escolham esse nível juntos, a partir da sua tolerância a erro, e não a partir de um número tirado de um folheto.
• Uma regra de ação corretiva. Quando os resultados ficam abaixo do limite, o acordo diz o que acontece: o fornecedor investiga, informa a causa, propõe uma correção e roda o teste de novo antes de a mudança entrar em produção.

Isso entrega algo mais forte do que uma promessa vaga de precisão. Entrega um sinal visível, um gatilho e uma obrigação de resposta. Para entender por que avaliar agentes é mais difícil do que avaliar uma única resposta de um modelo, vale ler o texto da Anthropic sobre avaliação de agentes de IA. O NIST AI Risk Management Framework oferece um vocabulário para medir e gerenciar risco que você pode adaptar com suas próprias palavras.

Combine isso com uma definição clara de pronto para cada tarefa. Se o agente informa que uma tarefa terminou, o acordo pode exigir evidência: o registro que foi atualizado, a mensagem que foi redigida, a fonte em que ele se baseou. Assim, “pronto” deixa de significar “o agente disse que sim”.

Quais termos de aprovação e permissão devem entrar no acordo?

Os limites de aprovação são a parte de um projeto com agentes que mais protege você, e costumam ser a menos documentada. Eles devem aparecer no acordo como termos, com responsáveis, e não como uma configuração feita uma vez e esquecida.

Escreva três listas para cada papel que o agente exerce:

• Ações que o agente pode executar sozinho, como ler um documento ou redigir uma resposta.
• Ações que exigem aprovação prévia de uma pessoa nomeada, como enviar uma mensagem a um cliente ou alterar um registro.
• Ações que o agente nunca deve executar, não importa como seja solicitado.

Depois acrescente os detalhes operacionais que as pessoas esquecem. Quem são os aprovadores, por nome ou por função? O que acontece quando o aprovador está ausente: o trabalho espera, passa para um substituto ou é escalonado? Por quanto tempo um pedido pode ficar parado antes de alguém ser lembrado? O texto sobre quando o agente deve parar e perguntar aprofunda como traçar essas linhas.

As permissões pedem o mesmo tratamento. O acordo deve dizer que o acesso começa no menor escopo útil, que cada conexão é documentada e que as permissões são revisadas em calendário, com um revisor nomeado do seu lado. O guia de autorização da OWASP (Authorization Cheat Sheet) é uma boa referência para os princípios por trás disso, como negar por padrão e menor privilégio. Uma cláusula que diz “o acesso será revisado periodicamente” é fraca. Uma cláusula que nomeia o revisor e o intervalo é uma que você consegue conferir.

O que conta como incidente e o que acontece depois?

Em um aplicativo comum, incidente é uma queda. Em um agente, as falhas que mais machucam costumam ser silenciosas. Defina categorias de incidente amplas o bastante para pegá-las:

• Falhas barulhentas: o agente está inacessível, um canal caiu, uma execução falha de forma visível.
• Falhas silenciosas: uma conexão expirou e o trabalho parou sem aviso, uma ação duplicada foi executada, o agente usou contexto desatualizado ou uma saída foi enviada ao destinatário errado.
• Falhas de limite: o agente tentou ou concluiu uma ação fora do escopo aprovado, ou expôs informação a alguém que não deveria vê-la.

Definidas as categorias, escreva no acordo um plano curto de resposta. Uma versão passo a passo fica assim:

• Detectar: diga como cada categoria é percebida, por monitoramento, pelo relato do próprio agente ou por uma pessoa da sua equipe.
• Conter: informe o que o agente faz enquanto o problema está aberto. Em geral, ele pausa a ação afetada, coloca o trabalho em fila e avisa uma pessoa. Um caso típico é o de uma conexão que expira.
• Notificar: nomeie quem é avisado, por qual canal e em quanto tempo, para cada gravidade.
• Passar a decisão: quando uma pessoa precisa decidir, o agente entrega a decisão com contexto, e não um monte de logs. O texto sobre escalonamento humano em falhas de agentes mostra o que uma boa passagem contém.
• Recuperar: descreva como o trabalho interrompido é retomado ou revertido e como duplicidades são evitadas.
• Revisar: após incidentes graves, o fornecedor escreve um relato curto com causa, impacto e a mudança feita, e você decide se a mudança é aceitável.

Esse plano vale mais do que qualquer número de tempo de resposta, porque diz a todos o que fazer antes de a pressão começar.

Como isso fica em um cenário ilustrativo?

O cenário a seguir é ilustrativo, não descreve um projeto real. Imagine uma pequena distribuidora com um agente que redige acompanhamentos de clientes e propõe atualizações nos cadastros. O dono quer um acordo de serviço curto e combina estas cláusulas com o fornecedor.

O agente redige os acompanhamentos sozinho, mas nunca os envia: um gerente de contas nomeado aprova cada um, e um substituto cobre quando essa pessoa está ausente. Alterações em registros são propostas, nunca gravadas, até que uma pessoa as aceite. A conexão com a caixa de e-mail e com o sistema de clientes é monitorada, e uma conexão expirada provoca uma pausa e um aviso ao dono em horário comercial. Cada execução registra as fontes usadas, o rascunho produzido e a decisão de aprovação. Todo mês, o fornecedor roda o conjunto de testes combinado, formado por conversas passadas com clientes, compartilha os resultados e abre uma ação corretiva se eles ficarem abaixo do nível definido pelo dono. As permissões são revisadas em calendário, pelo dono e pelo fornecedor em conjunto.

Nenhuma cláusula diz que os rascunhos serão perfeitos. Cada uma diz o que será feito, por quem e qual evidência vai mostrar isso. Se algo der errado, o dono consegue ver onde e apontar a cláusula que cobre o próximo passo.

Como uma operação gerenciada coloca isso em prática?

A Be Human projeta, implanta e opera agentes com identidade, memória, canais, ferramentas e permissões sob controle humano. Um primeiro projeto define um papel útil, a memória e as ferramentas de que ele precisa, os limites de aprovação e um critério de sucesso observável. A operação gerenciada pode então incluir monitoramento, avaliações recorrentes, manutenção de integrações, revisão de permissões, resposta a incidentes e melhorias controladas, o que se alinha aos compromissos acima. O que se escreve é o escopo desse trabalho e as evidências que ele produz, não uma garantia de resultados. O serviço é remoto, em português e inglês. Se você está comparando fornecedores, as perguntas para fazer ao fornecedor de agentes de IA antes de assinar ajudam a testar se os termos deles dizem essas coisas.

Perguntas frequentes

Um SLA para agentes de IA deve incluir metas de precisão? Tenha cuidado com qualquer meta que o fornecedor não controla. Uma abordagem melhor é combinar um conjunto de testes tirado do seu próprio trabalho, um calendário para rodá-lo e uma regra de ação corretiva quando os resultados caírem abaixo de um nível que você escolher. Isso torna a qualidade visível e acionável sem prometer um resultado que ninguém consegue garantir.

Quem responde quando o provedor do modelo tem uma queda? Em geral, nem você nem o fornecedor do agente controlam esse serviço, então o acordo deve dizer isso abertamente. Peça, em vez disso, aviso rápido, um comportamento de contingência declarado, como pausar e colocar o trabalho em fila, e um relatório depois. O compromisso é sobre como a queda é tratada, não sobre se ela pode ocorrer.

Com que frequência o acordo deve ser revisado? Revise-o sempre que o papel, as ferramentas ou as permissões do agente mudarem, e também em calendário regular, mesmo quando nada parece ter mudado. Os agentes se desgastam conforme documentos, conexões e regras de negócio mudam ao redor deles. Uma revisão recorrente mantém atualizados os limites, os responsáveis e o conjunto de testes.

Um SLA para agentes de IA tem validade jurídica? Isso depende de como ele é incorporado ao seu contrato e da lei aplicável, então peça a revisão de um advogado qualificado. Qualquer que seja o peso jurídico, escrever os compromissos em linguagem clara ajuda os dois lados a concordar sobre o que se espera. Quanto mais específica e verificável for cada cláusula, mais útil ela será na prática.

Orientação editorial Be Human. Exemplos são ilustrativos, salvo atribuição explícita. Fontes oferecem contexto; a implementação depende do seu processo.