Como uma consultoria de IA cobra: diagnóstico, projeto e recorrência

Como uma consultoria de IA cobra: diagnóstico, projeto e recorrência

Uma consultoria de IA costuma cobrar de três formas: diagnóstico com escopo fechado, projeto com entregas definidas e recorrência para operar e manter o que foi implantado. A forma certa depende do estágio da empresa, e cada modelo precisa entregar algo verificável: uma decisão no diagnóstico, um fluxo funcionando no projeto e continuidade controlada na recorrência. Este texto explica cada modelo, o que exigir dele e como evitar contratar o formato errado, sem citar valores.

Principais pontos

• Os três modelos respondem a perguntas diferentes: o que vale fazer (diagnóstico), como fazer e provar que funciona (projeto) e como manter funcionando (recorrência).
• Cobrar só por horas, sem entrega definida, transfere todo o risco para quem contrata. Peça sempre entregáveis e critério de aceite.
• Custos variáveis, como uso de modelos de IA e provedor de WhatsApp, devem aparecer separados do trabalho da consultoria.
• Recorrência sem relatório, sem log e sem revisão periódica vira mensalidade por disponibilidade, não por resultado operacional.
• Todo contrato deve prever como terminar: documentação, acessos devolvidos e transferência do que foi construído.

Por que o modelo de cobrança importa tanto em IA

Em software tradicional, o escopo costuma ser mais estável: você descreve telas, regras e integrações, e o trabalho se aproxima disso. Em IA, existe incerteza real. Só se sabe se um agente atende bem depois de testar com conversas reais, dados reais e exceções reais. Por isso, um contrato que prometa tudo de uma vez costuma esconder risco, e um contrato que cobre apenas horas costuma esconder falta de compromisso.

O bom modelo de cobrança divide a incerteza em etapas. Primeiro se reduz a dúvida sobre o que fazer, depois se constrói uma parte pequena e mensurável, e só então se decide manter e expandir. Cada etapa tem um entregável que a empresa consegue conferir sozinha, sem depender da palavra do consultor.

Outro ponto é que o trabalho não termina na entrega. Agentes de IA dependem de modelos que mudam, de regras de negócio que mudam e de clientes que escrevem de formas imprevisíveis. Quem contrata precisa saber, desde o início, quem cuida disso depois e sob quais condições.

Diagnóstico: o que é e o que deve entregar

O diagnóstico é a etapa curta e de escopo fechado em que a consultoria olha o processo atual e diz o que vale automatizar, o que não vale e por onde começar. Normalmente é cobrado como pacote, com prazo e entregas definidos, porque o esforço é previsível.

Um diagnóstico sério entrega, no mínimo:

• Mapa do processo atual, com quem faz o quê, em quais ferramentas e onde estão os gargalos.
• Linha de base: como o processo funciona hoje, para que um piloto futuro tenha algo contra o que ser comparado.
• Lista de candidatos a automação, ordenada por valor e risco, com justificativa.
• Inventário de dados e sistemas envolvidos, com atenção ao que contém dados pessoais e aos requisitos da LGPD.
• Recomendação de arquitetura em alto nível, incluindo o que deve ser fluxo determinístico e o que realmente precisa de julgamento de IA.
• Proposta de piloto: um fluxo, uma métrica de sucesso, limites de ação e critério para continuar ou parar.

O diagnóstico também deve ter a honestidade de dizer não. Se o processo é raro, mal definido ou se os dados não existem, a resposta útil pode ser que a empresa ainda não deve investir em IA naquele ponto. Um diagnóstico que sempre conclui por um projeto grande merece desconfiança.

O documento final deve ser seu. Se você puder levá-lo a outro fornecedor e pedir uma segunda proposta, o diagnóstico cumpriu seu papel. Para estruturar essa comparação, vale ter em mãos um modelo de RFP para agentes de IA.

Projeto ou piloto: o que deve entregar

O projeto é o modelo em que a consultoria constrói algo. Pode ser cobrado por escopo fechado, por marcos ou por fases. Em IA, o formato mais saudável costuma ser o piloto de um fluxo real, com início, fim e uma decisão formal ao final, em vez de um projeto amplo que só mostra resultado no último dia.

O que um projeto bem contratado deve entregar:

• Um fluxo real funcionando, por exemplo o atendimento de uma classe de perguntas no WhatsApp, e não uma demonstração com dados de mentira.
• Limites explícitos: quais dados o agente acessa, quais ações pode executar, quando passa para um humano e o que exige aprovação.
• Registro de decisões (logs) que permita auditar o que o agente fez e por quê.
• Conjunto de testes com casos reais e casos difíceis, para repetir a avaliação a cada mudança. A Anthropic descreve essa lógica em Demystifying evals for AI agents.
• Relatório final contra a métrica combinada no início, com recomendação clara: expandir, ajustar ou parar.
• Documentação e treinamento para que a equipe da empresa entenda como o sistema funciona.

O critério de aceite precisa estar escrito antes de começar. Para isso, ajuda usar um modelo de plano piloto de IA e definir métricas e pontos de decisão como em como medir um piloto de automação com IA.

Cuidado com projetos que cobram tudo por antecipação e entregam só no final. Prefira marcos com entregas conferíveis e pagamentos ligados a eles.

Recorrência: pelo que você está pagando

Recorrência é o modelo de monitoramento e manutenção contínuos. Ela faz sentido quando o sistema já está em produção e precisa de alguém cuidando dele. O erro mais comum é contratar recorrência sem saber o que ela cobre.

Uma recorrência útil deve descrever, por escrito:

• O que é monitorado: qualidade das respostas, falhas de integração, volume, custos de uso e transbordos para humanos. Conceitos de observabilidade ajudam a definir isso, como no guia de observabilidade do OpenTelemetry.
• Com que frequência a empresa recebe relatório e o que ele contém.
• Quais tipos de ajuste estão incluídos (regras, textos, base de conhecimento) e quais viram novo projeto.
• Tempo de resposta para incidentes, descrito em termos operacionais e sem promessas absolutas.
• Revisão periódica dos limites e permissões do agente, inclusive quando houver mudança de modelo, de provedor ou de processo interno.
• Quem é o responsável do lado da empresa para aprovar mudanças.

A recorrência também precisa de saída. Se a empresa decidir internalizar ou trocar de fornecedor, o contrato deve garantir acesso à documentação, aos prompts, às configurações, aos logs e aos testes. Sem isso, a recorrência vira dependência.

Quando a operação é gerenciada por uma plataforma, como acontece nas operações entregues pela Be Human, vale perguntar exatamente o que fica sob responsabilidade de cada parte, inclusive permissões, aprovações e rastreabilidade.

Qual modelo escolher? Um guia de decisão

Use as perguntas abaixo para saber em qual modelo a sua empresa está.

• Se você ainda não sabe qual processo automatizar, nem tem certeza de que os dados existem: comece pelo diagnóstico.
• Se você já tem um processo claro, dono definido e uma métrica possível, mas nunca testou IA nele: contrate um projeto no formato de piloto.
• Se o piloto atingiu a métrica combinada e a empresa quer manter o fluxo vivo sem montar uma equipe interna: contrate recorrência.
• Se a empresa tem equipe técnica e só precisa de orientação pontual: considere uma consultoria avulsa por sessões, com pauta e registro de decisões.
• Se o fornecedor pede recorrência antes de qualquer piloto: peça para ver o que seria monitorado. Sem sistema em produção, não há o que manter.
• Se o fornecedor propõe um projeto grande sem diagnóstico: pergunte como o escopo foi definido e quais premissas ainda não foram testadas.

Esse guia não elimina a necessidade de comparar fornecedores. Para isso, o scorecard para avaliar uma empresa de desenvolvimento de agentes de IA ajuda a organizar critérios técnicos e comerciais.

Cenário ilustrativo: uma distribuidora que quer atender pedidos no WhatsApp

Este é um cenário ilustrativo, sem relação com cliente real. Uma distribuidora recebe pedidos e dúvidas de entrega por WhatsApp e a equipe comercial gasta boa parte do dia respondendo perguntas repetidas. O dono quer "colocar IA", mas não sabe por onde.

No diagnóstico, a consultoria mapeia o atendimento, separa perguntas de status de pedido (repetitivas, com dados em um sistema) de negociações de preço (sensíveis, melhores com humanos) e registra como o atendimento funciona hoje. A recomendação é piloto apenas para status de pedido, com leitura de dados e sem nenhuma ação de escrita.

No projeto, a equipe constrói esse fluxo com limites claros: o agente só consulta, nunca altera pedidos, e passa para um atendente quando a pergunta foge do escopo ou o cliente demonstra insatisfação. Há log de cada decisão e um conjunto de conversas reais para teste. No fim, o relatório compara o resultado com a linha de base e recomenda ajustar, expandir ou parar.

Só depois, se a decisão for expandir, entra a recorrência: monitoramento das respostas, revisão mensal das falhas e aprovação de qualquer ampliação de permissões. Cada etapa tem entregável próprio, e a empresa poderia parar ao final de qualquer uma delas sem ficar refém das seguintes.

Para quem está nesse tipo de fluxo, vale ler também como integrar IA no WhatsApp da sua empresa.

Como ler uma proposta: checklist e método

Antes de assinar, confira se a proposta responde a estas perguntas:

• Qual é o entregável de cada etapa e como vou conferi-lo?
• Qual métrica de sucesso foi combinada e quem mede?
• Quais dados e sistemas o agente acessará, e com que permissões?
• O que acontece quando o agente erra ou não sabe responder?
• Quais custos variáveis existem (modelos de IA, provedor de WhatsApp, infraestrutura) e como aparecem separados?
• O que está incluído na manutenção e o que vira novo escopo?
• O que eu recebo se encerrar o contrato?

Sobre custos variáveis, a ideia de economia unitária, descrita pela FinOps Foundation, ajuda: em vez de olhar um total opaco, relacione o custo ao volume de trabalho entregue, como cada conversa resolvida. Isso torna a discussão sobre expansão muito mais objetiva.

Também vale pedir que a proposta mencione como os riscos serão gerenciados. O AI Risk Management Framework do NIST é uma referência de vocabulário para essa conversa, sem exigir que a empresa adote um processo formal pesado.

O método de trabalho que seguimos tem a mesma lógica das etapas acima: mapear o processo atual e a linha de base, limitar dados e ações, pilotar um fluxo real com logs e uma métrica combinada, e transferir o que foi construído para então decidir se expande, ajusta ou para. Os modelos de contratação são apenas a forma comercial dessas etapas.

Perguntas frequentes

Quanto tempo dura cada modelo de contratação? Não há prazo universal. O diagnóstico tende a ser a etapa mais curta, o projeto ou piloto depende da complexidade do fluxo e das integrações, e a recorrência continua enquanto o sistema estiver em produção. O importante é que cada etapa tenha data de início, entregáveis e ponto de decisão por escrito.

Posso pular o diagnóstico e ir direto ao projeto? Pode, se a empresa já tem processo mapeado, dono definido, métrica e clareza sobre dados e sistemas. Se qualquer um desses itens estiver em aberto, o diagnóstico evita que o projeto gaste seu tempo descobrindo o que deveria ter sido definido antes.

A consultoria cobra à parte pelos custos de modelo de IA e de WhatsApp? Em geral esses custos são variáveis e dependem do volume de uso, então o mais saudável é que apareçam separados do trabalho da consultoria e que você tenha acesso ao consumo. Confirme também em nome de quem ficam as contas e contratos com os provedores, para não perder acesso ao encerrar.

Como evitar ficar preso a um fornecedor na recorrência? Exija, no contrato, a entrega de documentação, configurações, testes, logs e acessos, além de um prazo razoável de transição. Prefira arquiteturas em que as contas e credenciais pertençam à sua empresa, e revise periodicamente se alguém do seu lado entende o que está em produção.

Fontes

• Anthropic: Demystifying evals for AI agents
• FinOps Foundation: unit economics
• NIST AI Risk Management Framework
• OpenTelemetry: observability concepts