Projetos de IA não são Projetos de IT
E a maioria das organizações ainda não percebeu isso.
Não se trata de falta de investimento. Nem de ausência de talento técnico. O problema está a montante: está no modelo mental com que as lideranças abordam estas iniciativas.
Quando uma organização trata um projeto de IA como um projeto de software, está implicitamente a assumir que sabe o que vai construir, como vai construir, e quando vai estar pronto. Está a assumir previsibilidade onde existe, fundamentalmente, incerteza.
Este pressuposto acaba por ter quase sempre um custo elevado em tempo, em dinheiro, e na confiança que os sponsors depositam neste tipo de iniciativas e, para piorar, esse impacto negative não é imediato nem dramático. É lento, cumulativo, e muitas vezes confundido com problemas técnicos quando, na verdade, é um problema de modelo de gestão.
1. O erro fundamental: Confundir engenharia com ciência
Nos projetos de IT tradicionais, o ponto de partida é, tipicamente, uma solução já concebida. Definem-se requisitos, desenha-se a arquitetura, constrói-se, testa-se e entrega-se. Se a engenharia for sólida, o resultado é largamente previsível. O trabalho do gestor de projeto é coordenar, controlar o âmbito e garantir que as entregáveis chegam a tempo e dentro do orçamento.
Os projetos de IA seguem uma lógica diferente. Não começam com uma solução, começam com uma hipótese.
Estas perguntas não se respondem com design. Respondem-se com experimentação.
É aqui que entra a relevância de frameworks como o CRISP-DM (Cross-Industry Standard Process for Data Mining), combinados com princípios Agile de entrega iterativa. Não porque prometam certeza. Mas porque oferecem uma estrutura disciplinada para navegar a incerteza. Para quem vem de contextos de IT, planear em ciclos curtos com objetivos de aprendizagem pode parecer contraproducente. Mas é exatamente isso que o contexto de IA exige.
O erro não está em usar metodologias. Está em usar as metodologias erradas para o tipo de trabalho que se pretende realizar.2. O que muda na prática: Planeamento, Risco e Sponsors
Esta diferença não é apenas conceptual. Tem implicações concretas e imediatas na forma como os projetos devem ser geridos.
No planeamento, a abordagem tradicional de definir um âmbito fixo desde o início raramente funciona em IA. O que se planeia são ciclos de exploração, não fases de construção. O gestor de projeto tem de aprender a planear com base em hipóteses e a ajustar o rumo à medida que os dados falam, mesmo que isso implique rever decisões tomadas nas semanas anteriores (soa a AGILE? Porque é AGILE).
Na gestão de risco, o risco técnico em IA é diferente do risco técnico em IT. Num projeto de software, o risco principal é o de construir mal o que foi especificado. Num projeto de IA, o risco é o de descobrir, já avançado o projeto, que os dados não suportam o modelo esperado, ou que o modelo não gera o valor de negócio antecipado. Este tipo de risco não se elimina com mais rigor no planeamento. Gere-se com ciclos curtos, revisões frequentes, e pontos de decisão explícitos onde se escolhe avançar, alterar o rumo, ou até mesmo parar.
Nas expectativas do sponsor, talvez seja aqui que o impacto seja mais visível, e mais delicado. Os sponsors habituados a projetos de IT esperam marcos claros, prazos definidos e entregáveis tangíveis. Em IA, muitas dessas certezas simplesmente não existem no início do projeto. O trabalho do gestor inclui, inevitavelmente, a gestão ativa dessas expectativas. E isso exige uma comunicação diferente, mais orientada à aprendizagem do que à entrega.
Esta frase sintetiza algo que a maioria dos gestores de projeto evita dizer diretamente: o sponsor não é apenas o financiador do projeto. É a pessoa que, em última análise, é responsável perante a organização pelas decisões tomadas ao longo do processo. Num contexto de IA, isso significa que o sponsor precisa de estar envolvido não apenas nos marcos de entrega, mas nos pontos de decisão onde a incerteza é alta e onde o rumo pode mudar.
Ignorar isso é uma das razões mais comuns para o fracasso silencioso dos projetos de IA, aqueles que tecnicamente "entregam" algo, mas que nunca geram valor real para o negócio.3. O verdadeiro sistema: feedback vs. previsão
Há uma distinção que raramente é feita de forma explícita, mas que separa as organizações que conseguem tirar valor real da IA daquelas que ficam presas em pilotos intermináveis.
A diferença está entre sistemas de previsão e sistemas de feedback.
Um sistema de previsão tenta antecipar o futuro com base em informação disponível. É útil, mas essencialmente estático: produz uma resposta que depois se entrega. Um sistema de feedback aprende continuamente com os resultados das suas próprias ações e ajusta o comportamento em consequência. É dinâmico: quanto mais ópera, mais aprende … e mais valioso se torna.
A maioria das organizações está a construir projetos de IA como se fossem sistemas de previsão. Definem um problema, treinam um modelo, fazem um piloto, e entregam. Mas o verdadeiro valor da IA nas organizações emerge quando se constroem sistemas de feedback, ciclos contínuos que conectam a descoberta técnica com a decisão de negócio, e a decisão de negócio com nova aprendizagem.
Trabalhei diretamente num projeto com um orçamento na ordem dos €22 milhões onde esta distinção fez toda a diferença. A iniciativa estava estruturada como um projeto de entrega clássico: um modelo seria desenvolvido, validado e implementado. O problema surgiu a meio do projeto, quando os dados revelaram padrões completamente diferentes dos que tinham sido assumidos na fase de conceção. Numa lógica de IT, isso seria um desvio ao plano, potencialmente um problema de âmbito com implicações de custo e prazo. Numa lógica de sistema de feedback, era precisamente o tipo de sinal que o projeto existia para descobrir.
A diferença entre as duas abordagens não estava na tecnologia utilizada. Estava na forma como a liderança estava estruturada para interpretar esses sinais e agir sobre eles, e na capacidade de envolver o sponsor nessa decisão sem que o projeto naufragasse. O que salvou a iniciativa não foi um modelo mais sofisticado. Foi a capacidade de reconhecer o que os dados estavam a dizer e tomar uma decisão organizacional difícil em tempo útil.
O que a maioria das organizações ainda não percebeu é que liderar um projeto de IA não é, no seu núcleo, uma competência técnica. É uma competência de sistema, a capacidade de orquestrar aprendizagem, decisão e alinhamento organizacional em simultâneo, enquanto o problema, os dados e a solução continuam a evoluir.4. Não é tecnologia. É liderança.
Não é uma questão de tecnologia. É uma questão de modelo de liderança.
As organizações que estão a ter dificuldades com os seus projetos de IA não são, na maior parte dos casos, aquelas que têm piores dados ou modelos menos sofisticados. São as que continuam a aplicar modelos de liderança concebidos para um tipo de trabalho diferente, e a esperar resultados que esse modelo simplesmente não consegue produzir.
Liderar uma iniciativa de IA exige a capacidade de orquestrar aprendizagem e decisão em simultâneo. De traduzir o que a ciência de dados está a descobrir numa linguagem que o negócio consegue usar. De saber quando há evidência suficiente para agir, e quando a incerteza é apenas o sinal de que é preciso continuar a explorar. E de manter o sponsor alinhado não em torno de um plano fixo, mas em torno de um propósito claro e de uma lógica de aprendizagem partilhada.
Isso não é gestão de projeto no sentido operacional. É liderança que cria as condições para que a execução aconteça, mesmo quando o caminho não está totalmente definido.
As organizações que fecharem este gap mais cedo não terão necessariamente os melhores modelos ou os maiores volumes de dados. Terão algo mais valioso: pessoas capazes de transformar ambos numa vantagem competitiva sustentável.
E isso começa por uma mudança de modelo mental. Não amanhã. Hoje.
