Consultoria de inteligência artificial

Uma consultoria de inteligência artificial existe para responder a uma pergunta que a empresa raramente consegue responder sozinha: onde, dentro desta operação específica, a IA muda o custo, a velocidade ou a qualidade de um processo o bastante para justificar o trabalho de mudá-lo. O entregável é um diagnóstico do que a empresa faz hoje, uma escolha de prioridade defendida com números da própria casa, uma arquitetura de dado e integração que sustente a solução, e um caminho até o processo novo virar rotina — inclusive depois que o consultor sai da sala. Ferramenta instalada e time treinado em prompts aparecem como consequência desse percurso, geralmente no fim dele.

Dito isso, vem a parte que não aparece nas propostas comerciais. Na minha leitura do mercado, uma fatia grande do que se vende como consultoria de IA é treinamento de ferramenta com capa de estratégia — e digo isso como opinião formada em projeto, não como levantamento de mercado. O roteiro é reconhecível. Workshop de meio dia sobre prompts, licença corporativa de algum assistente, três casos de uso genéricos tirados de um catálogo que serviria a qualquer empresa do país, e um relatório final com a palavra “transformação” no título. Meses depois, o uso caiu, ninguém sabe dizer o que mudou no resultado, e a diretoria conclui que a IA “ainda não está madura”. O que não estava maduro era o trabalho.

O diagnóstico é o produto, e ele começa longe da ferramenta

Um diagnóstico sério não pergunta qual modelo a empresa quer usar. Pergunta quais processos consomem mais hora-humana repetitiva, quais decisões dependem de informação que já existe mas está espalhada, onde o erro custa caro e onde o erro é barato, e quem tem autoridade para mudar o desenho de cada um deles. Só depois de mapear isso é que faz sentido discutir tecnologia — porque a tecnologia é a variável mais fácil de trocar e a menos determinante do resultado.

O trabalho tem uma ordem, e ela é o inverso da ordem em que a tecnologia costuma ser apresentada. Primeiro se acompanha um caso real de ponta a ponta: como um pedido entra, por quantas mãos ele passa, onde fica parado esperando, o que faz ele voltar atrás. Depois se mede o que esse percurso custa em tempo, em retrabalho e em exceção tratada no braço. Só no terceiro movimento entra a pergunta sobre qual parte do percurso uma máquina poderia assumir — e a essa altura o nome do modelo importa pouco, porque o desenho do processo já restringiu as opções viáveis a duas ou três. Vale o mesmo cuidado com o excesso de vocabulário: quando a discussão vira uma sequência de siglas, o glossário de IA resolve a tradução e devolve a conversa ao lugar certo, que é o processo.

Há um efeito colateral bem-vindo no diagnóstico bem-feito. Ele frequentemente descobre que dois ou três dos problemas listados não precisam de IA nenhuma — precisam de um campo obrigatório no formulário, de uma integração entre dois sistemas que já se falam mal há anos, ou de alguém decidindo qual das quatro planilhas é a versão oficial. Consultoria que nunca devolve esse tipo de resposta desconfortável está otimizando a própria fatura.

O que trava um projeto de IA quase nunca é o modelo

Nos projetos que acompanho, o ponto de travamento raramente é a qualidade do modelo. Trava porque o dado necessário estava em PDF escaneado, em campo livre preenchido por quinze pessoas com quinze convenções diferentes, ou em um sistema cujo acesso depende de um contrato antigo que ninguém consegue reabrir. O modelo é a parte comoditizada da equação; o dado e o processo são a parte que só existe dentro da sua empresa — e é exatamente por isso que ninguém consegue vendê-los prontos.

Isso vale especialmente para o padrão mais comum em uso corporativo, que é dar à IA acesso ao conhecimento interno da empresa via busca em base própria. A qualidade da resposta fica limitada pela qualidade do acervo. Se a política vigente convive com três versões antigas do mesmo documento e nada indica qual está valendo, o sistema vai recuperar a errada com total convicção. O gargalo aí é de gestão documental, e ele já existia antes de qualquer projeto de IA entrar na empresa.

O processo entra pelo mesmo caminho. Automatizar um fluxo mal desenhado produz um fluxo mal desenhado rodando mais rápido, com menos gente entendendo por que ele é assim. A ordem correta é: descrever o processo, cortar o que não deveria existir, e só então decidir o que a máquina assume. Quem pula a etapa do meio compra velocidade para o próprio erro.

Do piloto à capacidade instalada

O piloto mede o teto: dados escolhidos a dedo, usuários motivados, consultor presente para corrigir o que trava na hora. A operação real vive no piso — o pedido atípico, o anexo corrompido, o usuário que descreve o problema de um jeito que ninguém previu. É o piso que define o contrato, porque é ele que decide se a equipe volta a fazer tudo no braço na primeira exceção. Por isso, na fase de piloto, interessa menos o percentual de acerto e mais o inventário do que ficou de fora da amostra: quais exceções não foram testadas, com que frequência elas aparecem num mês real de operação, e quem cuida delas quando o sistema já estiver rodando sozinho.

Um piloto honesto já vem com a rota de escape desenhada. O que o sistema faz quando não tem confiança suficiente para decidir, para onde o caso é devolvido, quanto tempo o humano leva para retomá-lo sem perder contexto, e como isso tudo é registrado para virar melhoria na semana seguinte. Sem essa rota, o que se testou foi uma demonstração em condições de laboratório.

Capacidade instalada significa outra coisa. Significa que existe alguém interno que sabe por que o sistema foi desenhado assim, que consegue avaliar se ele está funcionando, que sabe ajustar o que degradou e que tem autoridade para desligar o que virou risco. Uma consultoria que não transfere isso está criando dependência, e dependência tem nome comercial: retainer permanente para manter algo que a empresa nunca aprendeu a operar.

Daí sai um critério de escopo que vale escrever no começo do projeto, não no relatório final: o que exatamente continua funcionando na empresa noventa dias depois que o time externo sai. A resposta precisa ser nominal — este processo, com este dono, medido por este indicador, com este procedimento quando o resultado degrada. Capacidade instalada é essa lista, e é a parte do trabalho que sobrevive à troca de modelo, de plataforma e de moda.

Governança é condição para escalar

Empresa nenhuma coloca IA em contato com cliente, contrato ou dado sensível sem responder três perguntas: o que o sistema pode decidir sozinho, o que precisa de humano no meio, e quem responde quando ele erra. Sem essas respostas, o jurídico bloqueia — corretamente — e o projeto morre na antessala, depois de todo o investimento técnico.

A parte técnica do risco é conhecida e tratável. Modelos de linguagem produzem afirmações erradas com a mesma fluência das corretas, e existe um repertório de práticas que reduz alucinação sem eliminá-la: ancorar em fonte, exigir citação verificável, restringir escopo, manter revisão humana onde o erro é caro. A parte organizacional é mais difícil, porque é uma questão de cadeia de responsabilidade. Alguém precisa responder, com nome e cargo, pelo que a máquina decidiu — e para responder precisa ter como saber o que foi decidido, quando e com base em quê. Isso é restrição de projeto: obriga o sistema a registrar decisão e a permitir reversão, e obriga o desenho a definir de antemão em que ponto uma saída automática passa a produzir efeito sobre um cliente, um contrato ou um pagamento. O detalhe operacional de quais classes de dado podem entrar em qual modelo, e o que se guarda por quanto tempo, é matéria de política de uso, e está desdobrado em consultoria em IA generativa. Quem já estruturou um programa de segurança reconhece o terreno — é a mesma lógica de liderança executiva em risco, aplicada a um vetor novo.

O erro comum aqui é tratar governança como etapa final, o carimbo que se busca depois que a solução está pronta. Ela entra no desenho e frequentemente muda a arquitetura escolhida. Descobrir na véspera do lançamento que aquele dado não podia sair do país é caro de um jeito evitável.

Retorno se mede em processo

A pergunta “qual o ROI de IA” costuma ser mal formulada porque mistura duas coisas. Existe o retorno de uma implantação específica — que é mensurável, desde que a métrica exista antes do projeto — e existe o valor difuso de as pessoas usarem assistentes no dia a dia, que é real mas praticamente impossível de auditar. É assim que a organização acaba com uma narrativa de sucesso sem uma linha de evidência.

Medir bem exige disciplina chata. Escolher o indicador antes de começar, registrar a linha de base, isolar o que mudou além da IA, e aceitar que parte do ganho aparece como capacidade ociosa liberada, não como custo cortado. Tempo de ciclo, custo por atendimento, taxa de retrabalho e percentual de casos resolvidos sem escalada humana são os números que sobrevivem a uma pergunta cética do conselho. “A equipe sente que ganhou tempo” não sobrevive.

Vale ainda distinguir economia de capacidade. Muitos projetos não reduzem custo: permitem atender um volume maior com a mesma estrutura, ou responder em horas o que levava dias. É um ganho legítimo, mas precisa ser declarado como tal desde o começo, senão vira decepção no fim, quando alguém procura a redução de headcount que nunca foi o objetivo.

Quando não contratar consultoria de IA

Esta é a seção que quase nenhuma página comercial escreve, e é a que dá credibilidade ao resto. Há situações em que contratar consultoria em inteligência artificial é queimar dinheiro, e reconhecê-las cedo poupa o constrangimento posterior.

Não contrate se o processo-alvo não estiver descrito em lugar nenhum e ninguém conseguir explicá-lo de ponta a ponta numa reunião. Não contrate se não houver um dono interno com autoridade e agenda para mudar esse processo — sem contraparte, o melhor diagnóstico do mundo vira PDF arquivado. E não contrate se o problema central é dado bagunçado, sistema legado sem API e cadeia de aprovação confusa: IA sobre desordem produz desordem em escala, mais rápida e mais difícil de rastrear.

Existe também o caso em que a resposta certa não é consultoria, e sim produto. Se a necessidade é bem delimitada e já existe uma solução consolidada no mercado, contrate a solução. Vale olhar o que já se faz por aqui antes de encomendar algo sob medida — o mapa de empresas de inteligência artificial no Brasil resolve boa parte das dúvidas de escopo. Consultoria se justifica quando a decisão é ambígua, o contexto é específico e o custo de errar a escolha é alto. Fora dessas condições, comprar pronto costuma ser a saída mais barata e mais rápida.

O que permanece depois do projeto

Consultoria de IA madura é, no fundo, consultoria de processo com competência técnica suficiente para saber o que a tecnologia consegue e o que ela não consegue fazer. A parte de IA envelhece rápido: o modelo de hoje será o padrão barato do ano que vem. A parte de processo, dado e governança é o que permanece, e é a única que continua rendendo depois que a novidade passa. Para quem já está na etapa seguinte, comparando propostas concretas, o critério de escolha está desenvolvido em empresa especialista em inteligência artificial.

---

Se você está tentando descobrir por onde um projeto de IA começa a fazer sentido na sua operação, é essa a frente que conduzo no Grupo WYS, com o BrainPilot como metodologia proprietária de diagnóstico, arquitetura e implantação. O primeiro movimento costuma ser simples: mapear o processo que dói, checar se ele tem dado utilizável e dono definido, e estimar o que muda se parte dele passar para a máquina — e dá para começar pelo contato. Quando a decisão envolve muita gente, uma palestra coloca o time inteiro na mesma base de vocabulário e de expectativa antes de qualquer proposta entrar na mesa.