Porque é que o teu piloto de IA morreu na gaveta

"Fizemos um piloto de IA no ano passado. Correu bem na apresentação. Depois ninguém voltou a pegar naquilo."

Se já disseste uma frase destas, não estás sozinho. Há um relatório, uma demonstração que impressionou numa reunião, talvez uma fatura de consultoria. E há uma pasta algures, física ou no servidor, onde o projeto ficou a dormir. Ninguém o matou. Simplesmente deixou de ser usado.

Este artigo não é para te convencer a tentar outra vez com mais força. É para perceber porque é que aquilo morreu. Assim, o próximo passo pode ser mais pequeno e ficar vivo.

Primeiro: isto é o normal, não um atraso teu

O estudo de prontidão para IA do SAS com a IDC ouviu mais de 1.600 líderes em 28 países. Coloca cerca de 70% das PME nos estágios "experimental" ou "oportunista". Na prática, isto quer dizer que se experimenta aqui e ali, sem que nada passe a fazer parte do trabalho de todos os dias. Portugal aparece no mesmo estudo como um caso de "adoção rápida, alicerces fracos": experimentamos depressa, mas os ganhos nem sempre ficam.

Os números sobre pilotos que falham variam muito de estudo para estudo, e convém não os tratar como leis. Uma consultora neerlandesa acompanhou mais de 50 projetos de IA em PME e estima que entre 60% e 80% nunca passam da fase de piloto. Um estudo da RAND de 2025 fala em cerca de 80% de projetos que não entregam o valor pretendido. As amostras são diferentes, mas todos apontam na mesma direção: um piloto que morre é a regra, não a exceção.

O mais interessante é o motivo. Quase nunca é a tecnologia. É a forma como o piloto foi montado.

As cinco causas de morte mais comuns

Olhando para o que se sabe sobre pilotos que morreram em PME, as causas repetem-se. Nenhuma tem a ver com o algoritmo.

1. Era grande demais. O piloto tentou resolver "as vendas" ou "a previsão de stock" de uma só vez. Com um âmbito grande, os meses passam antes de alguém ver resultado. E um projeto sem resultado ao fim de três meses perde a atenção de toda a gente.

2. Não tinha dono dentro da empresa. Quem o puxava era a consultora ou o fornecedor. Quando o contrato acabou, ninguém lá dentro achava que aquilo era seu.

3. Vivia fora do dia-a-dia. Era um painel novo, uma app nova, um endereço para guardar nos favoritos. Para o usar, a pessoa tinha de se lembrar de ir lá. Ninguém se lembra. O comercial na estrada abre o WhatsApp dezenas de vezes por dia e o painel nenhuma.

4. Media tudo e, por isso, nada. Cinco ou seis indicadores, definidos em abstrato no início, que ninguém acompanhou. Não havia uma pergunta simples do tipo "isto está a ser usado?".

5. Não tinha critério de continuar ou parar. Como ninguém decidiu à partida o que seria sucesso, também ninguém decidiu que tinha falhado. O projeto não acabou. Foi para a gaveta.

Repara que nada disto é falta de inteligência ou de vontade. São problemas de desenho, e resolvem-se com desenho.

Um exemplo, para ficar concreto

Imagina uma distribuidora de material elétrico com 30 pessoas e PHC há dez anos. (O exemplo é ilustrativo e não é um caso real, mas vais reconhecê-lo.)

O piloto que morreu. Em 2025 contrataram um projeto de "previsão de vendas com IA". Durou quatro meses. Foi preciso exportar dados do ERP para um sistema à parte e limpar as famílias de artigos. No fim havia um painel bonito com cinco indicadores. O diretor comercial viu-o na apresentação. Os comerciais abriram-no duas vezes. Em janeiro, os dados do painel já estavam dois meses desatualizados, porque a exportação era manual. Ninguém reparou até ao verão.

O passo que ficou vivo. Em setembro, a mesma empresa escolheu uma coisa muito mais pequena: deixar os comerciais perguntarem pelo WhatsApp coisas que antes pediam ao escritório. "Que encomendas em aberto tem o cliente Silva & Filhos?" "Quanto é que este cliente comprou este ano face ao ano passado?" "Há stock do disjuntor X no armazém?" As respostas vêm diretamente do PHC, na hora, sem exportações. O dono do projeto é a pessoa do escritório que atendia esses pedidos. É ela quem mais ganha se funcionar.

Não há aqui nada de espetacular. Mas ao fim da primeira semana já se consegue responder à única pergunta que interessa: estão a usar?

O que um primeiro passo tem de ter para não morrer

Invertendo as cinco causas, fica uma lista curta:

• Âmbito de uma pergunta, não de um departamento. Começa pelas perguntas que já se fazem todos os dias e que hoje obrigam alguém a interromper o que está a fazer.
• Dados que já existem. Se o ERP já tem as encomendas, o stock e as horas, não precisas de um projeto de dados antes de começar. O alicerce já lá está.
• Um dono interno com nome. Uma pessoa, não um comité. De preferência, quem sente a dor.
• Dentro de uma ferramenta que já se abre. Se o primeiro passo exige aprender uma app nova, estás a juntar duas mudanças numa só.
• Resultado visível em dias. Uma pergunta respondida na terça-feira vale mais do que um roteiro de doze meses.

Como saber se está vivo (sem cinco KPIs)

Aqui a honestidade conta mais do que a sofisticação. Para um primeiro passo, bastam três sinais, e todos se medem sem folhas de cálculo complicadas:

1. Uso real. Quantas perguntas por semana? Quantas pessoas diferentes perguntaram? Se a segunda semana tem menos uso do que a primeira, tens um problema. É melhor sabê-lo cedo.
2. Pedidos que deixam de chegar. Durante uma semana, antes de começar, a pessoa do escritório faz um risco num caderno por cada pedido de números que recebe. Repete o exercício um mês depois. A diferença é o teu retorno, em minutos.
3. Tempo até à resposta. Antes: "vejo isso quando chegar ao escritório". Depois: a resposta chega na hora, ainda com o cliente ao telefone.

Define também, à partida, o critério de paragem. Por exemplo: "se ao fim de quatro semanas menos de metade da equipa comercial tiver feito perguntas, paramos e percebemos porquê". Parar de propósito não é falhar. Falhar é deixar o projeto morrer sem que ninguém decida nada.

"Mas se a IA inventa, o comercial deixa de confiar"

É a objeção certa, e é a que mata mais pilotos em silêncio. Basta um número errado dado a um cliente para a equipa deixar de usar a ferramenta, e com razão.

As ferramentas de IA genéricas, as conversacionais que toda a gente já experimentou, funcionam a prever texto plausível. Se não sabem o saldo do cliente, podem dar-te um número com ar credível na mesma. Não é má vontade. É a forma como foram construídas.

Uma ferramenta ligada ao ERP tem de funcionar de outra maneira. Não adivinha: vai buscar o número à base de dados e responde com base no que lá encontrou. Se a informação não existe, diz que não sabe. Esta diferença entre "prever" e "consultar" é o que decide se o comercial pergunta uma vez ou cem.

Onde entra a Nemea

A Nemea foi desenhada para ser esse primeiro passo pequeno e difícil de matar. Liga-se ao ERP que já tens (PHC à cabeça, mas também Sage, Primavera e Artsoft) e deixa a equipa perguntar pelo WhatsApp. As respostas vêm dos dados reais da empresa.

Olhando para as cinco causas de morte:

• Não é uma app nova. É o WhatsApp que a equipa já abre dezenas de vezes por dia.
• Arranca em horas, não em meses. A camada que traduz perguntas em linguagem de negócio para os dados do ERP já vem construída. Não há um projeto de dados à cabeça.
• É só de leitura. Consulta, não altera. Não há o risco de um primeiro passo estragar uma fatura.
• Não inventa. Cada resposta vem de uma consulta real à base de dados. Se não houver dados para responder, diz isso mesmo.
• Fica tudo registado. Cada pergunta, cada resposta e o custo de cada mensagem ficam auditados. Ou seja, a métrica de "está a ser usado?" já vem de origem.

Exemplos por função, para escolheres por onde começar

• Dono ou gestor: "Quanto faturámos este mês face ao mesmo mês do ano passado?" "Quais são os cinco clientes com mais valor em atraso?"
• Comercial: "Que encomendas em aberto tem o cliente X?" "Quando foi a última compra dele?"
• Armazém: "Quanto stock há da referência Y e em que armazém?" "Há alguma encomenda de fornecedor a caminho?"
• Técnico de campo: "Quantas horas registei esta semana?" "Que intervenções tenho para amanhã?"

Não precisas de ativar todas. Escolhe uma função, com um dono, e vê a primeira semana.

Começar pequeno, de propósito

O teu piloto anterior não falhou porque a tua empresa "não está preparada para IA". Falhou porque era grande, estava longe do dia-a-dia e não tinha ninguém lá dentro a puxar por ele. O próximo pode ser o contrário: uma pergunta, um dono, uma ferramenta que já se usa e um número honesto ao fim de uma semana.

Se quiseres ver como isso fica com os dados da tua empresa, pede uma demonstração em nemea.pt. Começamos por uma pergunta.