Business case de IA para finanças: as perguntas que o CFO vai fazer

Um business case de IA para finanças pronto para o financeiro compara o que uma tarefa concluída custa hoje com o que ela custa quando um agente cuida de parte dela, incluindo o tempo que as pessoas gastam conferindo o resultado. Ele nomeia um dono para o resultado, um dono para os controles e um dono para o gasto, e marca uma data de revisão em que as evidências serão examinadas. Este artigo percorre as perguntas que o líder financeiro costuma fazer e mostra como responder a cada uma com resultados medidos por tarefa, e não com promessas gerais.

Principais pontos

• Construa o caso em torno de uma tarefa recorrente com resultado mensurável, e não em torno da plataforma ou do modelo.
• Divida o custo total de operação pelo número de resultados aceitos, para que o retrabalho e a revisão humana entrem no cálculo.
• Nomeie um dono do resultado, um dono dos controles e um dono do gasto antes de liberar qualquer orçamento.
• Escreva os limites de aprovação e as evidências que serão revisadas dentro da própria proposta.
• Apresente o primeiro caso como um teste do modelo operacional, com data de revisão fixa, e não como previsão do valor total.

O que o líder financeiro está realmente decidindo

O líder financeiro raramente pergunta se a tecnologia é impressionante. A decisão é mais estreita: se um custo específico pode ser ligado a um resultado específico, se o gasto pode ser reduzido ou interrompido caso esse resultado não apareça, e quem vai perceber quando algo sair do esperado. A maioria das conversas de aprovação se resume a quatro perguntas: qual é a linha de base, qual mudança é esperada, quanto custa manter a solução em funcionamento e qual é a consequência de estar errado.

Essa forma de olhar muda o que a proposta precisa conter. Um slide que descreve capacidades não responde a nenhuma das quatro. Um documento curto que nomeia a tarefa, o custo atual, a meta, a condição de parada e a data de revisão responde a todas.

Comece por uma tarefa com fim claro

Escolha uma tarefa que se repete, produz uma saída visível e tem uma pessoa capaz de dizer se a saída estava certa. Encaminhar solicitações de fornecedores, redigir respostas para uma categoria padrão de suporte ou conciliar uma lista semanal de exceções são candidatos comuns. Evite tarefas que dependem de julgamento que ninguém escreveu, porque o caso passará a se apoiar em opinião e não em evidência.

Antes de escrever qualquer número de custo, documente o trabalho como ele acontece hoje:

• Descreva o gatilho, as entradas, as etapas e a saída em frases simples.
• Registre quem faz a tarefa, com que frequência ela chega e onde costumam aparecer atrasos e erros.
• Liste a memória, os documentos e os sistemas de que o trabalho precisa, e os dados que o agente nunca deve ver.
• Defina um critério de sucesso que alguém consiga verificar nos seus próprios sistemas, e não em um relatório do fornecedor.
• Decida o que o agente pode fazer sozinho, o que ele só pode propor e o que ele nunca deve fazer.

Essa lista também é o primeiro rascunho da sua declaração de escopo. Se não for possível escrevê-la em uma página, a tarefa provavelmente é ampla demais para uma primeira implantação. O guia sobre fases de implementação de um agente de IA explica por que uma única tarefa delimitada deve provar seu valor antes de o escopo crescer.

Como medir resultados por tarefa concluída?

A unidade útil é o custo de um resultado aceito. A orientação de unidade econômica da FinOps Foundation faz um ponto parecido para gastos em nuvem: a fatura total diz pouco até ser ligada à atividade de negócio que ela sustenta. Aplique essa lógica aqui. Some o uso do modelo, a infraestrutura, a manutenção das integrações, o tempo de monitoramento e o tempo humano gasto revisando a saída, e divida pelo número de resultados concluídos e aceitos sem retrabalho. Retrabalho e escalonamentos pertencem ao cálculo, não a uma nota de rodapé.

Cenário ilustrativo: uma equipe de operações de clientes trata pedidos de reembolso. Hoje, um coordenador lê cada pedido, confere o registro do pedido e redige a resposta. A proposta faz o agente preparar a checagem do pedido e o rascunho, enquanto uma pessoa aprova cada reembolso. O líder financeiro não aceitará a afirmação genérica de que o trabalho ficou mais barato. Ele vai perguntar quanto custa uma decisão de reembolso aceita, com que frequência um rascunho precisou de reescrita substancial, quantos casos foram escalonados e o que a equipe fez com o tempo liberado. Se o retrabalho subir, o caso enfraquece, e a data de revisão é o momento em que essa decisão é tomada.

Quem é dono do resultado, dos controles e do gasto?

Um caso sem donos nomeados tende a falhar no primeiro incidente, e não na reunião de aprovação. Três papéis devem aparecer na proposta. O dono do resultado é o líder de negócio que aceita o desfecho e decide se a tarefa deve continuar automatizada. O dono dos controles é a pessoa responsável por permissões, registros e mudanças, normalmente de operações, TI ou segurança. O dono do gasto aprova o custo recorrente, que pode ficar em um orçamento central ou na área que se beneficia. Onde esse dinheiro deve ficar é uma decisão real, e o artigo sobre quem deve pagar pela IA na empresa apresenta as compensações envolvidas.

Coloque os três nomes em uma mesma página, com a autoridade que cada um tem. Inclua quem pode pausar o agente sem consultar ninguém, porque o financeiro vai querer saber com que rapidez a atividade e o gasto podem ser interrompidos.

Quais controles o financeiro vai pedir?

O financeiro raramente lê modelos de permissão, mas precisa saber que o acesso é limitado e que esses limites são verificados. O acesso deve seguir o princípio do menor privilégio: o agente recebe apenas as ferramentas e os registros que sua tarefa exige, cada um com finalidade declarada. A orientação de autorização da OWASP trata o acesso como uma decisão que precisa ser aplicada de forma consistente, por isso ele deve ser revisado em calendário, e não apenas na configuração inicial. As etapas da revisão trimestral de permissões oferecem um formato concreto para reunir essas evidências.

A avaliação é o segundo controle. A orientação de engenharia da Anthropic sobre avaliação de agentes descreve a execução de tarefas de teste fixas, a correção dos resultados e a repetição dessas checagens conforme o sistema muda. O AI Risk Management Framework do NIST oferece um vocabulário comum para mapear, medir e gerir riscos, o que ajuda quando o líder financeiro e o responsável por riscos precisam falar sobre a mesma coisa. Use essas referências como base da seção de evidências e mantenha a redação simples.

As perguntas que o líder financeiro costuma fazer são estas:

• Qual tarefa exata esta mudança afeta, e qual é a linha de base atual?
• Quanto custa um resultado aceito, com revisão e retrabalho incluídos?
• Quais sistemas o agente pode ler, e quais ele pode alterar?
• Quem pode pausá-lo, com que rapidez, e quem é avisado quando isso acontece?
• Quais evidências serão apresentadas na data de revisão, e quem decide o que elas significam?

Como apresentar o caso e definir a data de revisão?

Escreva a proposta como um documento curto de decisão, e não como uma apresentação. Inclua a descrição da tarefa, a linha de base, a meta, os limites de escopo, os donos, a estrutura de custos, o método de avaliação e a data em que os resultados serão revisados. Declare as condições que levariam à interrupção. Um caso que nomeia suas condições de parada é mais fácil de aprovar, porque o risco fica limitado por escrito.

Defina a primeira revisão cedo o bastante para agir e tarde o bastante para mostrar um padrão. O financeiro deve ver resultados aceitos e casos com falha lado a lado, com o motivo de cada falha e a mudança que se seguiu. Se a revisão mostrar que a tarefa não vale a pena ser automatizada, isso também é um resultado útil, e a decisão de pausar faz parte da mesma disciplina operacional. As etapas para encerrar um piloto sem desperdiçar o trabalho já feito mostram esse caminho.

A Be Human trata isso como um serviço gerenciado. Uma primeira implantação define um papel útil, a memória e as ferramentas de que ele precisa, seus 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 das integrações, revisão de permissões, resposta a incidentes e mudanças controladas, cada uma registrada para que os donos tenham evidências em cada data de revisão. O trabalho é entregue remotamente, em inglês ou em português, e o escopo permanece tão pequeno quanto a primeira tarefa exigir. O que costuma acontecer nos primeiros meses é descrito em a rotina de operação de um agente gerenciado.

Se ainda não está claro qual tarefa deve ir primeiro, o diagnóstico gratuito de IA da Be Human foi feito para ajudar a encontrá-la.

Perguntas frequentes

E se nunca medimos o custo atual da tarefa? Comece com uma amostra curta de tempo em um período normal, registrando quanto tempo cada etapa leva e onde o trabalho fica parado. Uma estimativa com método declarado é mais útil para o líder financeiro do que um número preciso sem fonte. Mantenha o método na proposta para que a linha de base possa ser medida novamente na data de revisão.

Basta o custo por tarefa, ou também precisamos do total? Você precisa dos dois. O valor por tarefa mostra se o trabalho está melhorando, e o total mostra se o gasto é sustentável no volume que você espera. O total deve incluir custos de operação, como monitoramento e manutenção das integrações, que são fáceis de esquecer na fase de aprovação.

Quem deve decidir parar o agente? O dono do resultado deve decidir com base no desempenho, e o dono dos controles deve poder pausar o agente imediatamente quando o acesso ou o comportamento parecerem errados. Escreva os dois direitos na proposta para que ninguém precise pedir permissão durante um incidente. O financeiro se beneficia de saber que a decisão de parada já está atribuída.

Em que isso difere de um business case de software comum? Um caso de software normalmente pressupõe um conjunto estável de funcionalidades. O comportamento de um agente depende de sua memória, ferramentas e permissões, que mudam com o tempo, então o caso precisa tratar a avaliação e a revisão de permissões como custos recorrentes e decisões recorrentes. É por isso que os donos, a data de revisão e as condições de parada devem estar dentro da própria proposta.

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