Em resumo: A maioria dos projetos de IA nas empresas não falha porque o modelo é fraco. Falha na última milha: a ligação aos sistemas, aos dados, às permissões e às pessoas reais. Esse trabalho não se faz à distância. Precisa de engenheiros dentro da sua organização até o sistema funcionar no dia a dia, e de um plano para que saiam.
1. A pergunta que um CEO deve fazer
Olho para a IA como para qualquer investimento. Compensa? Quando? E de quem é o resultado quando o fornecedor se vai embora?
A maioria dos pilotos de IA não passa nesse teste. Não porque a demo fosse fraca. A demo costuma ser a parte fácil. Falham porque ninguém orçamentou o trabalho entre «funciona num portátil» e «as pessoas usam-no todas as manhãs».
Essa lacuna tem nome no setor. A Palantir construiu o seu modelo à volta dela há anos, com engenheiros que trabalham dentro de cada cliente para implementar e adaptar as suas plataformas. Hoje, laboratórios de IA como a OpenAI e a Anthropic contratam para essa mesma função: o forward deployed engineer.
2. Onde se perde o dinheiro
A última milha não tem glamour. São permissões que ninguém documentou. Um campo do CRM que significa três coisas diferentes. Uma equipa jurídica que tem de aprovar os prompts. Um processo que só funciona porque uma pessoa conhece as exceções.
Nada disso entra no âmbito do piloto. Por isso o piloto termina, o diapositivo diz «sucesso» e o orçamento para produção passa a ser uma nova negociação. Passam os meses. O patrocinador muda de prioridades.
| O que o plano do projeto assume | O que acontece de facto na última milha | Quem paga |
|---|---|---|
| Os dados ficam prontos quando são extraídos | Acesso, qualidade e significado negociam-se sistema a sistema | A sua equipa, em atrasos |
| A integração é uma tarefa técnica | É organizacional: responsáveis, aprovações, segurança | O patrocinador, em credibilidade |
| Os utilizadores adotam uma boa ferramenta | Adotam a que encaixa na forma como já trabalham | O business case |
| A passagem de testemunho é um documento | A passagem são pessoas que o construíram elas próprias | A sua organização, sempre que algo muda |
3. O que muda com engenheiros lá dentro
Um forward deployed engineer trabalha onde está o problema. Nos seus sistemas. Com a sua equipa. Até funcionar.
Isso muda três coisas que me importam.
- Tempo até ao valor. A solução é construída no ambiente onde vai viver, por isso não é preciso um segundo projeto para a «industrializar».
- Risco. Integração, permissões e controlos resolvem-se nas primeiras semanas, em vez de serem descobertos depois de o contrato ser aceite.
- Propriedade. A sua equipa constrói ao lado. Quando o projeto termina, consegue operar e alterar o que foi construído.
Não é barato por semana. O trabalho é sénior e prático. Mas a comparação que importa não é a tarifa semanal. É o custo até ter um sistema em uso diário. Um projeto mais barato que nunca chega à produção é a opção mais cara. Comparamos os dois modelos no nosso guia de decisão (EN).
4. Como contratar sem criar dependência
As equipas integradas têm a sua própria armadilha: podem tornar-se permanentes. Antes de assinar, peça quatro coisas.
- Um responsável identificado do seu lado, que vai ficar com o sistema.
- Tudo nos seus repositórios desde o primeiro dia: código, prompts, conjuntos de avaliação e documentação.
- Sucesso medido pelo uso, não por entregáveis: quem usa, com que frequência e com que resultado.
- Uma saída com data, com procedimentos de operação e uma passagem de testemunho que a sua equipa ensaiou.
Se um fornecedor resistir a algum destes quatro pontos, trate isso como um sinal.
5. Perguntas frequentes
P: O que é um forward deployed engineer?
R: Um engenheiro de software que trabalha dentro da organização do cliente, sobre os seus sistemas e dados, até uma solução funcionar em produção. O modelo foi popularizado pela Palantir e hoje é comum nas empresas de IA.
P: É o mesmo que contratar uma consultora?
R: Não exatamente. Um projeto tradicional é muitas vezes desenhado e construído pela equipa da consultora e entregue no fim. Os forward deployed engineers constroem no seu ambiente, ao lado da sua equipa, e ficam até funcionar.
P: Quanto tempo deve durar um projeto destes?
R: O necessário para ter um primeiro caso de uso a funcionar no dia a dia e a sua equipa capaz de o operar, com uma passagem de testemunho com data. Não haver um fim previsto é um sinal de alarme.
P: Quando é melhor um modelo por projeto?
R: Quando o âmbito é claro e independente, a integração é leve e precisa de um preço fechado. Nem toda a necessidade de IA exige engenheiros no terreno.
6. Conclusão
A IA não cria valor numa demo. Cria valor quando funciona dentro do negócio, todos os dias, nas mãos de quem a usa.
É assim que trabalhamos na Thinkia: como uma só equipa com a sua, dentro dos seus sistemas, com a saída planeada desde o início. Se tem pilotos que nunca chegaram à produção, é assim que abordamos o tema (EN).