Liderança em Projetos de IA: 3 pilares e por que 95% das empresas travam

Mais cedo ou mais tarde, se você manja de IA dentro de uma empresa, vão te chamar pra liderar o projeto de IA. E aí cai a ficha: liderar projeto de IA não é como liderar qualquer outro projeto. Eu vi o Ronald Hall destrinchar isso num vídeo e bateu forte, porque é exatamente a parte que ninguém ensina pra gente que veio do técnico — a gente aprende a fazer funcionar, mas ninguém ensina a conduzir gente, expectativa e dinheiro em volta disso. Esse post é a minha leitura dos três pilares que ele propõe — qualificar, educar e decidir — com o que eu acho que importa de verdade pra quem é dev e quer dar esse passo.

A guerra da atenção: hype, stakeholder e a real necessidade

Toda indústria tem uma guerra por atenção, mas em IA isso vai pro talo. Todo dia tem notícia sensacionalista e promessa irreal — "automatize tudo em 24 horas", "demita o time inteiro". O problema é que quem banca o projeto, o seu stakeholder, está vendo essas mesmas manchetes e muitas vezes não consegue discernir o que é real. Forma-se uma barreira de atenção entre ele e a oportunidade concreta do negócio dele. E aqui vai o ponto que dói no dev: você não vence essa barreira debatendo no nível técnico. O stakeholder não quer saber o que você sabe, ele quer sentir segurança em você. Isso significa falar a língua dele e, sim, se portar como o mercado espera. Não é vender a alma — é entender que aparência e comunicação fazem parte do jogo de quem lidera.

Pilar 1: qualificar o cliente (e saber dizer não)

Qualificar é alinhar expectativa antes de qualquer linha de código: entender o que o cara pensa, diagnosticar a situação e escolher o projeto. Vale tanto pra quem tem consultoria quanto pra quem é CLT — nesse caso, o "cliente" é o seu chefe. O teste que o Ronald usa é simples e eu assino embaixo: o cliente chega dizendo que IA é prioridade máxima, que a empresa fatura milhões, mas o prazo é um mês pra um escopo gigante, não libera o dev sênior porque "está ocupado" e não tem budget pra contratar ninguém. São três red flags na mesma conversa. Ele quer algo ótimo e muito barato, embriagado de hype. Pra esses casos, nem proposta vale a pena — um obrigado e segue o jogo. Nem toda batalha merece ser lutada nas condições em que ela aparece, e saber recusar é parte de liderar.

Pilar 2: todo líder de IA é um educador

O segundo pilar é o que eu mais curti: liderar é educar. Tem muita gente dizendo que a IA mata a educação, e é o contrário — ela exige mais. Curso de tecnologia com "acesso vitalício" não faz sentido, porque o acervo envelhece rápido; o que a LLM entrega de graça não é o diferencial. O diferencial é você educar a equipe, educar o stakeholder, alinhar todo mundo na mesma visão. E aqui mora a explicação pra aquela estatística de que mais de 90% das empresas não conseguem colocar IA generativa em produção: elas tratam IA generativa como projeto comum, e não é. Ela bebe de engenharia de software e de dados, mas é uma terceira coisa, com necessidades próprias. Eu concordo que IA generativa merece um braço próprio na empresa, do lado de engenharia e de dados, não enfiada dentro do time de dados.

Pilar 3: decidir na prática e desbloquear pessoas

Decidir, na prática, é três coisas: desbloquear pessoas, testar hipótese e garantir a missão. Exemplo real: a sprint está montada, o dev está atolado numa feature, e no meio do caminho surge uma hipótese nova pra testar. O erro clássico é empilhar mais tarefa em cima do dev e ele não entregar nem uma coisa nem outra. O líder de hoje deveria conseguir testar essa hipótese ele mesmo. Você desbloqueia gente, conecta o front com o back porque entende a linguagem dos dois, e traduz tudo pro stakeholder. O preço disso é que liderança é solitária — você vai ser o cara que entende todo mundo e que quase ninguém entende de volta, e tudo bem. Liderança não é sobre você; é sobre fazer o projeto dar certo.

Por que conhecimento técnico não é opcional pra liderar

Tem gente que ouve "qualificar, educar, decidir" e acha que é só soft skill. Não é. Sem conhecimento técnico você cai na mesma armadilha do stakeholder: acredita no hype, não consegue discernir o que é verdade e o que é mentira, e ainda por cima não consegue comunicar. A divisão antiga de dev contra negócio acabou — o profissional que importa agora transita entre escrever código, falar de métrica e conversar com quem decide. Isso conversa direto com algo que eu já comentei por aqui: a análise de 400 mil sessões do Claude Code que mostrou que expertise de domínio pesa mais do que saber programar. E se você quer entender o lado de quem constrói essas soluções por dentro, vale ver como eu penso loop engineering e o desenho de sistemas que se automatizam — porque liderar bem exige saber o que de fato acontece quando o agente é acionado.

O que eu tiro disso pra quem é dev

Resumindo o que eu levo pra prática: (1) comunicação é skill que se aprende — abra a câmera na reunião, fale, saia do quarto, porque liderança não é dada, é conquistada; (2) venda faz parte do trabalho, e tão importante quanto a qualidade do código é a qualidade da venda, então largue a ideia de que vender é "moralmente inferior"; (3) liderança acontece antes, durante e depois do projeto — qualificar no começo, educar no meio, decidir o tempo todo e tirar lições no fim. Se você só pensa na entrega técnica, você está fazendo metade do trabalho.

Conclusão

No fim, o desenho que fecha tudo é simples: contexto (escopo, prazo e orçamento) somado a conhecimento (qualificar, educar e decidir) sustentado por uma base técnica de verdade. O nível do mercado vai subir, as soluções de brinquedo vão ficar pra trás e quem estiver bem capacitado prevalece. Se você veio do técnico e quer liderar, comece tratando comunicação, qualificação e educação como parte do ofício — não como distração. O vídeo do Ronald Hall sobre liderança em projetos de IA é o que disparou essa reflexão e vale o play inteiro.