Business case para agente de IA: como escrever sem exagerar

Um business case para agente de IA é um documento curto que nomeia uma função, o problema que ela resolve hoje, os limites de aprovação em que o agente trabalha e as evidências observáveis que vão mostrar se ele é útil. Monte-o a partir do que você consegue observar e contar dentro da sua própria equipe, não a partir de estimativas de economia emprestadas de outros lugares. Uma proposta que um colega cético consegue conferir tem muito mais chance de ser aprovada do que uma que promete um número grande.

Principais pontos

• Proponha uma função bem delimitada, não uma ambição genérica de usar IA na empresa inteira.
• Troque estimativas de economia por critérios observáveis: o que o agente cobre, quanto tempo o trabalho fica parado, quanto o revisor corrige e onde ele escala para uma pessoa.
• Descreva o que o agente pode ler, redigir e enviar, e onde uma pessoa precisa aprovar, antes que alguém pergunte.
• Inclua um período de teste em que o agente trabalha sem autoridade, para que a evidência venha do seu próprio trabalho.
• Defina de antemão qual resultado levaria você a ajustar, pausar ou encerrar. Isso deixa a proposta mais crível, não menos.

O que um business case para agente de IA deve conter?

Quem decide raramente recusa uma proposta porque a tecnologia soa improvável. Recusa porque o documento deixa perguntas sem resposta. A maioria faz as mesmas perguntas, mais ou menos nesta ordem: que trabalho é esse, quem responde por ele, o que pode dar errado, como vamos saber se está funcionando e o que é preciso para operar e para parar.

Um bom documento responde a cada uma delas em linguagem simples, geralmente em uma ou duas páginas:

• A função: uma frase descrevendo o trabalho que o agente assume e a pessoa que é dona desse trabalho hoje.
• A situação atual: como o trabalho é feito agora, onde ele espera e o que você observou, em vez do que supôs.
• O contexto necessário: quais documentos, sistemas e histórico o agente precisa acessar para fazer o trabalho.
• Os limites: o que ele pode ler, o que pode redigir, o que pode enviar ou alterar e quem aprova o quê.
• Os critérios de sucesso: sinais observáveis, com uma pessoa nomeada para conferi-los.
• Os riscos e as condições de parada: o que você fará se o agente errar, for lento ou não for usado.
• O custo de manter em operação: quem mantém, revisa e responde por ele depois do lançamento.

Se você consegue preencher cada item com algo específico, você tem um business case. Se três ou quatro itens estão em branco, você tem uma ideia, e os itens que faltam são o seu próximo trabalho. Um checklist de prontidão para implantação de IA ajuda a encontrar essas lacunas antes de apresentar.

Por que evitar números de economia inventados?

O instinto comum é abrir com um número: horas economizadas, custo evitado, capacidade ganha. O problema é que esse número se apoia em premissas que ninguém verificou, como quanto tempo uma tarefa realmente leva, com que frequência o agente vai acertar e quantas pessoas vão usá-lo. Quando um colega questiona uma única premissa, o valor inteiro desmorona, e a sua credibilidade vai junto.

Um número inventado também vira uma promessa. Meses depois, alguém vai pedir que você o demonstre, e você estará defendendo uma estimativa feita antes de o agente existir. É uma posição ruim para quem patrocina o projeto.

Uma abordagem mais honesta é descrever a situação de partida em termos que as pessoas possam verificar. Onde o trabalho forma fila? Quanto tempo um pedido fica parado antes de alguém tocar nele? Com que frequência uma passagem de trabalho perde contexto? Com que frequência o revisor reescreve um rascunho? Essas observações vêm da sua própria equipe e qualquer pessoa pode conferi-las de novo. Elas também dão um ponto de comparação quando o agente estiver em operação.

O custo merece a mesma disciplina. Em vez de prometer uma economia, diga o que você vai medir: o custo total de operação dividido pelas tarefas que o agente de fato concluiu. O artigo sobre como medir o custo de IA por tarefa concluída explica por que números por mensagem enganam, e como medir o retorno de um fluxo de IA sem exageros mostra o que afirmar e o que deixar de fora.

Como escolher a única função a propor?

Propostas amplas fracassam porque ninguém sabe dizer como seria o sucesso. Uma função estreita pode ser observada, revisada e corrigida. Ela deve ser algo para o qual um funcionário novo poderia ser treinado com um documento curto, e com um dono claro do seu lado.

Use isto como guia de decisão. Uma função é boa candidata para começar quando a maior parte destes pontos é verdadeira:

• O trabalho se repete toda semana, então a evidência se acumula rápido.
• Existe uma fonte de verdade escrita para as respostas: uma política, uma tabela de preços, um procedimento, uma pasta de exemplos anteriores.
• Uma pessoa já revisa o resultado, então a revisão não precisa ser inventada.
• Os erros são recuperáveis: um rascunho errado custa alguns minutos, não um cliente perdido.
• Uma pessoa nomeada sente a dor do processo atual e vai conferir os resultados.
• As entradas chegam por canais que o agente alcança sem gambiarras.

Se o trabalho falha na fonte de verdade, resolva isso primeiro. Um agente que precisa adivinhar é um agente que vai produzir a coisa errada com muita confiança. Os guias sobre engenharia de contexto para agentes de negócio e sobre como preparar os documentos da empresa são pontos de partida práticos.

Pergunte também se o trabalho realmente precisa de um agente. Se os passos nunca variam, um fluxo fixo pode ser mais barato e mais previsível. Dizer isso na proposta mostra que você pesou as opções.

Quais critérios observáveis colocar na proposta?

Bons critérios são coisas que uma pessoa enxerga no próprio trabalho, sem um painel cheio de estimativas. Devem ser poucos, escritos antes do início do teste e combinados com quem vai julgá-los. Estes costumam se sustentar:

• Cobertura: dos pedidos que se encaixam na função, quantos o agente tratou ou preparou, e quantos ele corretamente deixou de lado.
• Tempo de espera: o intervalo entre a chegada de um pedido e a primeira resposta útil, lido em registros de data e hora que já existem.
• Esforço de revisão: com que frequência o revisor aceita o rascunho como está, edita de leve ou reescreve. Uma contagem simples em três categorias basta.
• Qualidade da escalada: quando o agente para e pergunta a uma pessoa, ele entrega a decisão com o contexto anexado, ou uma bagunça para desembaraçar? Veja escalonamento humano em falhas de agentes de IA.
• Respeito aos limites: o agente ficou dentro das permissões, sem nenhuma ação que não lhe era permitida?
• Uso real: as pessoas indicadas estão de fato trabalhando com ele? Se não, o que elas estão dizendo?
• Custo por tarefa concluída: custo de operação dividido pelo trabalho finalizado, acompanhado ao longo do tempo.

Para cada critério, escreva quem confere, com que frequência e onde a evidência fica guardada. Um critério sem responsável pela conferência é só um desejo. O material de FinOps sobre custo unitário (unit economics) é uma boa referência para ligar custo a uma unidade de trabalho entregue, e o NIST AI Risk Management Framework oferece um vocabulário neutro para a seção de riscos.

Passo a passo para escrever o business case

Você consegue redigir o documento em poucas sessões focadas. Siga esta ordem, porque cada passo alimenta o próximo:

• Passo um: descreva o trabalho como ele é feito hoje. Sente-se com quem o executa e anote os passos reais, não os oficiais.
• Passo dois: registre à mão a situação de partida por um período curto. Anote quando os pedidos chegam, quando recebem a primeira resposta e o que precisa ser refeito. Mantenha simples.
• Passo três: escolha a função única e escreva seus limites. Liste o que o agente lê, redige e envia, e marque cada ponto em que uma pessoa aprova. O artigo sobre quando o agente deve parar e perguntar pode orientar esta etapa.
• Passo quatro: escreva os critérios de sucesso a partir da lista acima e nomeie quem confere cada um.
• Passo cinco: proponha um teste em que o agente redige e uma pessoa decide. Rodá-lo antes de dar autoridade ao agente, como descrito em teste de um agente de IA em modo de observação, gera evidência a partir do seu próprio trabalho.
• Passo seis: escreva os riscos em termos operacionais. O que acontece se um rascunho estiver errado, se uma conexão expirar ou se um documento estiver desatualizado.
• Passo sete: nomeie o responsável depois do lançamento, o ritmo de revisão e as condições para ajustar, pausar ou encerrar.
• Passo oito: peça a um colega de fora do projeto que leia o documento e marque toda frase que ele não consegue verificar. Remova ou reescreva essas frases.

O último passo é o mais importante. Toda afirmação que sobrevive a um leitor cético é uma afirmação que você não precisará defender depois.

Como isso fica na prática? Um cenário ilustrativo

O que segue é um cenário ilustrativo, não um cliente real.

A gerente administrativa de uma pequena empresa de serviços percebe que os pedidos de orçamento ficam parados numa caixa de e-mail compartilhada até alguém ter uma hora livre. Ela propõe um agente que prepare as primeiras respostas. Durante algumas semanas, ela registra à mão quando cada pedido chega e quando a primeira resposta sai, e anota quais respostas exigiram a intervenção do dono.

A proposta dela não traz número de economia. Diz que o agente lê a tabela de preços e os últimos orçamentos parecidos, redige uma resposta e nunca envia nada. Uma pessoa revisa cada rascunho. Sucesso significa que, para os pedidos que o agente cobre, as primeiras respostas saem no mesmo dia útil, que o revisor aceita a maioria dos rascunhos com edições leves, segundo o julgamento dela, e que todo pedido que o agente não consegue tratar chega ao dono com o histórico relevante anexado. Condições de parada: se os revisores continuarem reescrevendo os rascunhos do zero, ou se a equipe parar de abrir os rascunhos, o teste é pausado e a causa é analisada.

O dono aprova porque a proposta é pequena, verificável e reversível. Ninguém precisou acreditar em uma previsão.

Como uma abordagem gerenciada trata isso?

A Be Human estrutura o primeiro projeto em torno destes elementos: uma função útil, a memória e as ferramentas de que ela precisa, os limites de aprovação e um critério de sucesso observável combinado desde o início. Com o agente em operação, a gestão pode incluir monitoramento, avaliações recorrentes, manutenção das integrações, revisão de permissões, resposta a incidentes e melhorias controladas, para que a evidência do seu business case continue sendo coletada em vez de ficar velha. O agente mantém identidade, memória e contas próprias, sob controle humano. Para uma visão mais ampla do trabalho recorrente envolvido, veja o que os serviços gerenciados de IA incluem.

Perguntas frequentes

Qual deve ser o tamanho de um business case interno para um agente de IA? Uma ou duas páginas costumam bastar. Se a função, os limites, os critérios e as condições de parada cabem nesse espaço, quem decide consegue ler tudo de uma vez. Coloque detalhes de apoio, como as anotações da situação de partida, em um anexo.

E se meu gestor insistir em um número financeiro? Ofereça a unidade que você vai medir, como o custo de operação por tarefa concluída, e explique que o valor virá do teste, não de uma previsão. Você também pode descrever o custo atual da demora em termos simples, por exemplo pedidos que esperam de um dia para o outro. Evite apresentar um palpite como se fosse resultado.

Quem deve ser o dono do agente depois da aprovação? Nomeie uma pessoa do lado do negócio que seja dona da função e dos resultados, e uma pessoa responsável por acessos e permissões. Se você trabalha com um parceiro externo, ele cuida da operação, mas a responsabilidade pelo trabalho continua com a sua equipe. O guia de governança leve de IA para médias empresas mostra como manter isso simples.

O que fazer se os resultados do teste forem mistos? Trate resultados mistos como informação. Veja quais critérios se sustentaram e quais não, ajuste o contexto, as ferramentas ou os limites e rode o teste de novo para a mesma função. Se a evidência ainda não sustentar o caso, parar é um resultado legítimo e barato de uma proposta honesta.

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