Consultoria em IA: como um projeto acontece

Um projeto de consultoria em IA acontece em fases que se encadeiam por dependência, não por calendário: imersão no processo como ele funciona de fato, priorização com risco e premissa escritos, arquitetura de dado e integração, prova de conceito para matar o risco técnico mais caro, piloto dentro da operação real e, por último, adoção com encerramento. Cada fase termina em um artefato que alguém usa sem ter participado da reunião — mapa de processo, matriz de priorização, desenho de arquitetura, protótipo funcionando, plano de adoção. Ao lado disso corre uma agenda de rituais curtos cuja função é produzir decisão, não informar status.

O que decide o resultado, na minha leitura, não é a metodologia do consultor. É a agenda do cliente. Projeto de IA morre com muito mais frequência por falta de gente alocada do lado de dentro do que por escolha errada de modelo, e o sinal aparece cedo, quando a pessoa que conhece o processo é remarcada pela segunda vez seguida. Quem ainda está uma casa atrás — o que esse tipo de trabalho é, por que ele trava em dado e processo, como se mede retorno — encontra o quadro inteiro em consultoria de inteligência artificial. Esta página fica com a parte de dentro: o que acontece em cada fase, o que precisa sair dela por escrito, quem da empresa tem de estar na sala e como o trabalho termina sem virar relatório.

A imersão não é uma rodada de entrevistas com a diretoria

A primeira fase serve para descobrir como o trabalho realmente acontece, e essa informação quase nunca está com quem tem a visão do organograma. O diretor descreve o processo como ele foi desenhado. O analista descreve o processo como ele é executado, com os desvios que a operação inventou para dar conta de prazo, exceção e sistema que não conversa. A diferença entre as duas descrições é o material mais valioso da imersão, e ela só aparece se as duas pessoas forem ouvidas separadamente.

Precisam estar na sala, então, quatro perfis. Quem executa o processo todo dia, porque conhece as exceções. Quem tem autoridade para mudar o desenho dele, porque sem essa pessoa o diagnóstico não vira ação. Alguém de dado ou TI que saiba onde a informação mora e o que impede o acesso a ela — questão que decide viabilidade antes de qualquer discussão sobre modelo. E, quando a saída toca cliente, contrato ou pagamento, alguém de jurídico desde a primeira semana, não na véspera do lançamento.

O erro mais comum aqui é fazer imersão por questionário. Formulário devolve o processo oficial, que é a versão já documentada e que já se sabe não funcionar. Imersão útil é observação, e ela acontece na tela de quem executa: acompanhar casos reais de ponta a ponta, ler uma amostra de pedidos sem filtro, cronometrar onde o trabalho fica parado esperando aprovação, contar quantas exceções entram num mês normal. Sai dessa fase um mapa de processo com tempos e pontos de espera, e um inventário de dado com fonte, dono e o que hoje impede o acesso.

Artefato é o que sobrevive à reunião

Vale um critério duro para separar entrega de teatro: artefato é o que alguém usa sem ter estado na sala quando ele foi produzido. Slide de apresentação não passa nesse teste, porque depende do narrador. Mapa de processo, matriz de priorização, diagrama de arquitetura, runbook e plano de adoção passam, desde que escritos para serem lidos depois, por outra pessoa, sem contexto oral.

A matriz de priorização é a peça em que a maioria se engana. Ela costuma ter dois eixos — impacto e esforço — e faltam duas colunas. A primeira é risco: o que acontece se o sistema errar neste caso de uso, e quanto custa esse erro. A segunda, mais importante, é a premissa: o que precisa ser verdade para o caso funcionar. “A base de políticas tem versão vigente identificável”, “a API do ERP expõe o campo de status”. Priorização sem premissa explícita é ranking de desejo, e desejo não sobrevive ao primeiro contato com o dado.

A arquitetura de dado vem em seguida, e o artefato dela é uma decisão registrada, não um desenho ilustrativo: de onde a informação sai, quem a atualiza e com que frequência, o que fica indexado, o que é consultado ao vivo e o que fica de fora por escolha. Boa parte dos casos corporativos cai no padrão de dar ao modelo acesso ao acervo interno por busca em base própria, e esse documento só fecha quando cada linha dele tem dono nominal: quem responde pelo acervo, quem concede permissão por perfil, quem retira da base o que foi revogado. Enquanto essas respostas ficam em aberto, a fase não terminou — foi empurrada para dentro do piloto, onde o mesmo problema custa muito mais caro.

Prova de conceito responde uma pergunta; piloto sobrevive a um mês ruim

Prova de conceito existe para eliminar o risco técnico mais caro do projeto, e por isso precisa de uma pergunta escrita e de um critério de aceite acordado antes da primeira linha de código. “Testar a IA” não é prova de conceito. “Recuperar a cláusula correta do contrato certo, com fonte citável, numa amostra de casos difíceis selecionados pelo jurídico” é. Quando a saída é texto gerado, o critério precisa dizer também qual erro é tolerável e qual não é, e a amostra precisa ser montada pelos casos que costumam dar errado, não pelos que ilustram bem — o repertório que reduz alucinação entra no desenho da prova, não como remendo depois que ela passou.

Ela roda fora da produção, com dado real mas em amostra, sem usuário final envolvido, e tem permissão explícita para falhar. Falhar cedo é o entregável: uma prova que derruba o caso de uso antes da integração poupa todo o custo que viria depois dela. O que encerra a fase não é a entrega do protótipo, é uma reunião de corte de pauta única, em que o critério escrito lá atrás é conferido contra o resultado obtido e a decisão de seguir ou parar sai registrada com autor e razão. Quando essa reunião não existe, a inércia promove qualquer protótipo — a essa altura já há gente animada e trabalho investido, e ninguém quer ser quem interrompe.

O piloto é outra fase, e quase tudo muda nela. O ambiente passa a ser o de produção, com registro de execução, monitoramento e alguém de plantão. O dado deixa de ser amostra escolhida e passa a ser o que chega. O usuário é real e não escolheu participar. A janela cobre um período completo de operação, com o pico e a semana ruim dentro dela. Muda até quem toca no código: o protótipo que provou o ponto vira trabalho de engenharia de software, com integração, permissão, tratamento de erro e sustentação.

Por isso a fase tem condição de entrada — destino definido para o caso que o sistema não resolve e reversão testada, não apenas descrita. E muda a pergunta em jogo: a prova de conceito responde se a tecnologia dá conta; o piloto responde se o processo novo se sustenta quando ninguém está olhando. Chamar de piloto uma prova de conceito estendida, com a mesma amostra e os mesmos usuários entusiasmados, é pular justamente a fase que responde à segunda pergunta.

O projeto falha na agenda do cliente, não na do consultor

É o que vejo em projeto com regularidade: a proposta prevê “apoio da equipe interna” e ninguém traduz isso em horas. Apoio genérico significa participar nas brechas, validar saída com pressa entre duas reuniões e assinar o que não se leu. A validação apressada contamina tudo o que vem depois, porque o critério de qualidade do sistema passa a ser o de quem estava atrasado.

Alocação de verdade é nominal e contratada: quatro papéis, com nome, horas por semana e aval do gestor de cada um. Dono do processo, que decide mudança de desenho. Operador de referência, que valida saída e responde dúvida de negócio — o papel mais subestimado e o que mais determina qualidade. Alguém de dado ou TI, que resolve acesso, ambiente e integração. E um patrocinador, que aparece pouco mas desempata quando o projeto disputa agenda com a operação. Junto disso, uma exigência que raramente é feita: o gestor precisa retirar carga equivalente da pessoa alocada. Somar projeto sem subtrair rotina é uma forma educada de não alocar ninguém.

Falta ainda a pergunta que quase ninguém faz na assinatura: por quanto tempo. A carga do lado do cliente não é constante, e contratar como se fosse é o que produz a frustração do meio do caminho. Imersão e piloto são as fases pesadas para a empresa — na primeira porque tudo depende de observar o trabalho de quem executa, na segunda porque cada saída do sistema precisa ser conferida enquanto ninguém ainda confia nela. A prova de conceito é a fase leve, quase toda do lado do consultor. Quem dimensiona a alocação pela média das fases descobre o erro exatamente na semana em que o piloto entra no ar, que é a pior semana possível para descobrir.

Há um sinal precoce que vale tratar como dado, não como contratempo. Se a reunião de imersão é remarcada duas vezes seguidas, o problema não é agenda cheia: é prioridade declarada por comportamento, e o momento de recontratar escopo, prazo e alocação é esse — não depois, quando a conversa já virou cobrança.

Ritual serve para decidir, não para informar

A cadência que funciona tem três camadas e nenhuma é longa. Um encontro semanal curto com o núcleo operacional — dono do processo, operador de referência, técnico — com pauta de três itens: o que ficou pronto, o que está travado e qual decisão precisa sair desta semana. Um encontro quinzenal com o patrocinador, que não é status: leva números, alternativas e o que exige dinheiro, prioridade ou mudança de escopo. E, só durante a janela quente de prova de conceito e piloto, uma checagem diária que morre quando a janela fecha.

O registro importa mais do que a reunião. Cada decisão fica anotada com data, dono e a razão pela qual as outras opções foram descartadas. Seis meses depois, quando alguém perguntar por que a arquitetura ficou assim, esse documento é a diferença entre uma resposta em dois minutos e uma semana de arqueologia. E vale um teste de saúde do ritual: se em quatro semanas seguidas nenhuma decisão saiu da reunião, ela virou relatório falado — ou muda quem está na sala, ou se devolve a hora para a operação.

Encerramento é uma prova, não uma apresentação

Transferência de conhecimento não é entregar documentação e conduzir um treinamento; isso é distribuição de arquivo. Transferência acontece quando, nas últimas semanas, a mão se inverte: o time interno roda o ciclo completo — opera, mede, trata exceção, ajusta o que degradou — e o consultor assiste sem intervir, respondendo só quando é perguntado. É desconfortável para os dois lados, e é por isso que funciona: expõe o que só existia na cabeça de quem está saindo.

O encerramento tem, então, um teste de saída em vez de uma cerimônia: um caso de exceção real, ou uma falha provocada de propósito, resolvido pelo time da empresa sem ajuda. Se conseguem, a capacidade ficou instalada. Se não conseguem, o projeto acabou em treinamento, e é honesto dizer isso antes de assinar o encerramento.

O pacote que acompanha o teste — procedimento para quando o resultado degrada, critério de desligamento, painel com o indicador escolhido lá no começo, registro de decisões e backlog do que ficou de fora — sustenta o conhecimento transferido, mas não o substitui. Fecham o ciclo uma data de revisão já marcada em calendário, com o mesmo indicador medido de novo, e a política de uso escrita para quem entrar depois, assunto desdobrado em consultoria em IA generativa. Vale inverter esse teste para quem ainda está escolhendo com quem trabalhar: a pergunta sobre como o projeto termina cabe na primeira reunião, e a resposta separa quem entrega operação transferida de quem entrega dependência — os outros critérios de escolha estão em empresa especialista em inteligência artificial.

---

Se a dúvida é quem precisa estar alocado, o que cada fase tem de entregar e como saber se o piloto está pronto para virar operação, vale conversar antes de assinar o escopo. É esse desenho de execução que conduzo com o BrainPilot, metodologia de diagnóstico, arquitetura e implementação que uso no Grupo WYS. O começo costuma ser uma conversa curta sobre o processo que dói, e ela abre pelo contato.