Consultoria em IA: por onde começar sem queimar orçamento em projeto que não sai do piloto

Existe um padrão que se repete com frequência incômoda nas empresas brasileiras de médio porte. A diretoria decide que precisa "fazer alguma coisa com IA". Monta-se um comitê. Contrata-se uma prova de conceito. Em oito semanas há uma demonstração bonita rodando no notebook de alguém. Todo mundo aplaude. E aí o projeto morre — não porque a tecnologia falhou, mas porque ninguém definiu antes quem seria o dono do resultado, de onde viriam os dados em produção e qual número precisava mudar.

Estudos de mercado apontam consistentemente que a maioria dos pilotos de IA corporativa nunca chega a produção. A causa raiz raramente é o modelo. É método.

Este artigo apresenta o método que usamos em projetos de consultoria em IA: como selecionar casos de uso, como avaliar viabilidade antes de gastar, como estruturar o primeiro ciclo e como evitar as armadilhas que consomem orçamento sem entregar valor.

Primeiro: separe as três famílias de IA

Boa parte da confusão nas discussões corporativas vem de tratar como uma coisa só o que são três famílias tecnologicamente distintas, com custos, riscos e prazos diferentes.

IA preditiva. Modelos que estimam um valor ou uma classe a partir de dados históricos: previsão de demanda, risco de inadimplência, probabilidade de churn, manutenção preditiva. Tecnologia madura, exige dados históricos estruturados e de qualidade. O retorno é geralmente mensurável com precisão.

IA generativa. Modelos de linguagem e multimodais que produzem texto, código, imagem ou áudio: assistentes internos, geração de documentos, atendimento, resumo de contratos, suporte à redação técnica. Barreira de entrada baixíssima, retorno rápido em produtividade, mas exige atenção redobrada a alucinação, confidencialidade e governança.

IA agêntica. Sistemas que não apenas respondem, mas executam sequências de ações em ferramentas reais: abrem chamado, consultam ERP, atualizam registro, disparam e-mail. É onde está o maior ganho potencial e também o maior risco operacional, porque o erro deixa de ser uma resposta ruim e passa a ser uma ação errada em sistema de produção.

A primeira pergunta de qualquer diagnóstico é em qual dessas famílias o problema do cliente se encaixa. Empresas que tentam resolver um problema preditivo com IA generativa — ou vice-versa — gastam meses descobrindo que escolheram a ferramenta errada.

O funil de seleção de casos de uso

Nem todo processo é candidato a IA. O filtro que aplicamos tem quatro peneiras, nesta ordem.

Peneira 1 — Volume e repetição

IA se paga em escala. Um processo executado três vezes por mês por um analista não justifica projeto, por mais tedioso que seja. Procure atividades com alta frequência e baixa variação estrutural: triagem de e-mails, classificação de documentos, resposta a dúvidas recorrentes, conferência de dados entre sistemas.

Regra prática: se o processo consome menos de 20 horas de trabalho humano por mês na organização inteira, ele provavelmente não deve ser o primeiro projeto.

Peneira 2 — Tolerância a erro

Esta é a peneira que mais projetos ignoram e a que mais mata iniciativas em produção. Pergunte: o que acontece se o sistema errar 5% das vezes?

Se a resposta for "um humano revisa e corrige em segundos", ótimo candidato. Se for "emitimos uma nota fiscal errada" ou "damos uma orientação clínica incorreta", o caso exige arquitetura muito mais cuidadosa, com validação determinística, e não deve ser o primeiro da fila.

Casos de uso ideais para começar são aqueles em que a IA propõe e o humano confirma. O ganho de produtividade é quase todo capturado e o risco fica contido.

Peneira 3 — Disponibilidade de dados

Aqui separa-se o discurso da realidade. Faça três perguntas concretas:

• Os dados necessários existem em formato digital acessível, ou estão em PDF escaneado, planilha local e conhecimento tácito?
• Existe um responsável que pode autorizar o uso desses dados?
• Há histórico suficiente? Para IA preditiva, tipicamente 12 a 24 meses de dados consistentes; para IA generativa sobre documentos, um corpus organizado e atualizado.

Se a resposta for negativa, isso não invalida o caso de uso — apenas indica que a primeira entrega do projeto é organizar dado, não treinar modelo. Melhor descobrir isso na semana dois do que no mês seis.

Peneira 4 — Dono do resultado

Todo caso de uso precisa de uma pessoa da área de negócio, com nome e cargo, que responda pelo indicador que o projeto pretende mudar. Não é o gerente de TI. É quem sofre a dor.

Sem esse dono, o projeto vira demonstração tecnológica e morre no primeiro conflito de prioridade.

A matriz de priorização que funciona

Depois de filtrar, posicione os casos sobreviventes em dois eixos: valor esperado (economia de horas, aumento de receita, redução de risco) e esforço de implantação (dados, integração, mudança de processo, complexidade regulatória).

Um erro comum é começar pelo caso mais estratégico. Estratégico normalmente significa complexo, e complexo no primeiro projeto significa alta chance de não entregar. Comece pelo quadrante superior esquerdo e use a credibilidade conquistada para financiar o restante.

Estruture o primeiro ciclo em 90 dias

Projetos de IA se beneficiam enormemente de ciclos curtos com escopo travado. O modelo que recomendamos:

Semanas 1–3: descoberta e baseline. Mapear o processo atual em detalhe e — este é o ponto crítico — medir o desempenho humano atual. Quanto tempo leva? Qual a taxa de erro hoje? Sem baseline, é impossível provar ganho, e o projeto fica refém de opinião.

Semanas 4–7: protótipo com dados reais. Não com dados sintéticos, não com exemplos escolhidos a dedo. Dados reais, incluindo os casos feios: documento mal escaneado, cliente com cadastro incompleto, pedido fora do padrão. O desempenho em casos limpos engana.

Semanas 8–10: avaliação estruturada. Monte um conjunto de avaliação com 100 a 300 casos representativos e resposta esperada validada por especialista. Meça acurácia, taxa de alucinação, cobertura e custo por operação. Este conjunto vira ativo permanente da empresa: ele será usado toda vez que o modelo ou o prompt mudar.

Semanas 11–13: piloto controlado em produção. Um subconjunto real de usuários, com supervisão humana, telemetria completa e canal fácil de reportar erro. Aqui aparece tudo o que o laboratório escondeu.

Ao final de 90 dias, a decisão é binária e baseada em número: escala ou encerra. Ambas são resultados legítimos. Encerrar um caso de uso ruim em 90 dias é muito melhor do que arrastá-lo por dois anos.

O que costuma custar mais do que se imagina

Integração, não o modelo. O custo de API de modelos caiu drasticamente. O custo de conectar o sistema ao ERP legado, tratar autenticação, respeitar permissões e lidar com dados inconsistentes é que domina o orçamento. Em projetos que acompanhamos, a divisão típica é 15% modelo, 35% integração e dados, 30% avaliação e ajuste, 20% mudança de processo e treinamento.

Gestão de mudança. Se o time acha que a ferramenta é uma ameaça ao emprego, a adoção não acontece — e a resistência raramente é declarada, ela aparece como uso baixo e reclamação vaga. Comunicação honesta sobre o que muda no trabalho de cada um é parte do projeto, não um extra.

Manutenção contínua. Modelos são depreciados, fornecedores mudam versões, o negócio muda de regra. Reserve orçamento recorrente. Um sistema de IA sem manutenção degrada silenciosamente, o que é pior do que falhar visivelmente.

A pergunta certa não é "quanto custa implantar IA?", e sim "quanto custa manter isso funcionando bem no terceiro ano?".

Riscos que precisam estar no contrato desde o dia zero

Confidencialidade. Onde os dados trafegam e ficam armazenados? Há treinamento do fornecedor com os seus dados? Qual a região de processamento? Para dados pessoais, a LGPD exige base legal definida e registro de tratamento.

Rastreabilidade. Toda saída relevante do sistema precisa ser reconstituível: qual versão do modelo, qual prompt, quais documentos foram consultados, quem aprovou. Sem isso, não há auditoria possível.

Dependência de fornecedor. Arquitete para trocar de modelo. Isso significa isolar a chamada ao modelo atrás de uma camada própria, manter o conjunto de avaliação independente e evitar recursos proprietários no caminho crítico.

Viés e justiça. Em qualquer decisão que afete pessoas — crédito, seleção, priorização de atendimento — é necessário testar desempenho por subgrupo, não apenas no agregado.

Como escolher um parceiro de consultoria em IA

Algumas perguntas revelam muito rapidamente com quem você está falando:

1. Peça para descrever um projeto que não deu certo e o que aprenderam. Quem nunca falhou nunca entregou.
2. Pergunte como medem qualidade. Se a resposta não incluir um conjunto de avaliação e métricas, é demonstração, não engenharia.
3. Pergunte o que acontece se o modelo do fornecedor mudar de preço ou for descontinuado.
4. Pergunte quem opera o sistema depois da entrega e como o time interno é capacitado.
5. Verifique se conseguem falar de processo de negócio com a mesma fluência com que falam de tecnologia.

Um bom parceiro vai, em algum momento da conversa, dizer que um dos seus casos de uso não deve ser feito. Consultoria que aprova tudo está vendendo horas.

Construir, comprar ou combinar

Toda empresa chega, em algum momento, à pergunta sobre desenvolver internamente, contratar uma plataforma pronta ou montar uma arquitetura híbrida. Não existe resposta universal, mas existem critérios claros.

Comprar faz sentido quando o processo é padronizado de mercado e não representa diferencial competitivo: assinatura eletrônica com extração de dados, transcrição de reuniões, ferramentas de produtividade individual. Pagar por algo que já existe e funciona bem é decisão racional; reconstruir é vaidade técnica cara.

Construir faz sentido quando o processo é específico do seu negócio, quando os dados envolvidos são sensíveis a ponto de restringirem fornecedores externos, ou quando a lógica de decisão é justamente aquilo que diferencia a empresa dos concorrentes.

Combinar é o que acontece na prática na maioria dos casos. Modelos de fornecedores estabelecidos, orquestração e regras de negócio próprias, integração desenvolvida sob medida. Essa arquitetura preserva velocidade sem criar dependência estrutural.

O critério decisivo costuma ser este: o que você não pode terceirizar é o conhecimento sobre por que o sistema decide o que decide. A infraestrutura pode ser de terceiros; o entendimento do comportamento precisa ser interno.

Três erros de escopo que aparecem em quase todo projeto

Escopo que cresce durante a execução. Começa como triagem de e-mail, e no mês dois alguém sugere que "já que estamos nisso" o sistema também responda automaticamente. Cada adição parece pequena e o conjunto inviabiliza a entrega. Congele o escopo do primeiro ciclo por escrito e coloque as ideias novas em uma lista para o ciclo seguinte.

Escopo definido pela tecnologia disponível. Quando a pergunta vira "o que dá para fazer com essa ferramenta?" em vez de "qual problema queremos resolver?", o projeto perde ancoragem no negócio e fica impossível de defender no orçamento seguinte.

Escopo sem critério de encerramento. Defina antes de começar o que significa sucesso e o que significa fracasso. Um projeto que não pode fracassar formalmente nunca termina — ele apenas consome recursos até que alguém desista em silêncio.

Um roteiro mínimo para as próximas quatro semanas

Se você quer sair do lugar sem ainda ter orçamento aprovado, comece por aqui:

1. Liste dez atividades repetitivas que consomem tempo de gente qualificada na sua empresa.
2. Para cada uma, estime horas mensais gastas e o que acontece se houver erro.
3. Marque as que dependem de dados que você sabe onde estão.
4. Escolha duas e converse com quem executa a atividade hoje — não com o gestor.
5. Defina, para cada uma, o número que precisaria mudar para o projeto valer a pena.

Você terá, ao final, algo muito mais valioso do que uma prova de conceito: um caso de uso escolhido com critério e um indicador acordado.

Conclusão

Consultoria em IA que entrega valor não começa por tecnologia. Começa por escolher bem o problema, medir a situação atual com honestidade e desenhar um ciclo curto o suficiente para errar barato.

A tecnologia disponível hoje já resolve uma quantidade enorme de problemas corporativos reais. O que separa as empresas que capturam esse valor das que acumulam pilotos abandonados não é acesso a modelo melhor — é disciplina de método.

A BHELP.tech conduz esse processo do diagnóstico à operação: seleção de casos de uso com critério, avaliação mensurável, integração com os sistemas que você já tem e capacitação do time interno para operar depois. Se a sua empresa está na fase de decidir por onde começar, é exatamente aí que a conversa deve acontecer.