Durante três anos, o debate sobre porque é que a IA não aterra nas empresas respondeu-se a olhar para o modelo. Que era o contexto, que eram as alucinações, que o próximo já ia ser o bom. E o próximo chegou, e chegou outro, e o processo da tua empresa continua a fazer-se à mão. Em 2026 o mercado deixou de fingir que o problema era o modelo e pôs nome ao que faltava: uma pessoa.
A tese numa frase: não precisas de contratar um forward deployed engineer. Precisas da função que esse papel representa, comprada em frações e amarrada a um workflow concreto em vez de a uma plataforma. E essa distinção, que soa a pormenor, é a diferença entre gastar um orçamento anual e ter um processo a funcionar em seis semanas.
O que é um forward deployed engineer e porque é que o nome aparece agora
Um forward deployed engineer é um engenheiro que trabalha dentro do cliente: percebe o processo real, constrói a solução colada aos sistemas que já existem e não se vai embora enquanto aquilo não correr em produção. Metade engenheiro, metade consultor de terreno. A Palantir tem a figura há duas décadas; a definição canónica, com responsabilidades, competências e quando NÃO o contratar, está na ficha de forward deployed AI engineer do nosso catálogo de funções, e aqui não a vamos repetir.
O que convém explicar é porque é que o título explodiu agora, e a resposta tem data. A 11 de maio de 2026 a OpenAI anunciou a OpenAI Deployment Company, uma unidade de negócio independente criada, nas suas palavras, para poder desenvolver o modelo operativo, o ritmo e o foco no cliente que este trabalho exige. A função declarada é incrustar forward deployed engineers em organizações que resolvem problemas complexos em ambientes exigentes. E para não começar do zero, no mesmo anúncio acordou a compra da Tomoro, uma consultora de IA aplicada que traz cerca de 150 FDEs e especialistas de implementação desde o primeiro dia. Fonte: OpenAI launches the OpenAI Deployment Company, OpenAI, 11 de maio de 2026.
Lê outra vez, porque aquilo é uma confissão. A empresa que fabrica o modelo mais vendido do mundo decidiu que, para o seu produto funcionar dentro de uma empresa, é preciso montar outra empresa e comprar cento e cinquenta pessoas. O estrangulamento deixou de ser a inteligência. É a aterragem.
O que o papel não é, e porque é que a confusão te custa dinheiro
Há hoje três perfis que se vendem com o mesmo discurso e fazem coisas diferentes. Distingui-los é o que evita comprar o errado:
- Não é um consultor. O consultor entrega um documento com o que devias fazer. O FDE entrega o processo feito. Se no fim do trabalho o que tens é uma apresentação, compraste consultoria com nome novo.
- Não é um AI engineer. O AI engineer constrói o sistema; o FDE constrói o sistema e descobre qual era o problema, que é a parte que ninguém tem escrita em lado nenhum e a que come 70 % do calendário.
- Não é customer success. O customer success garante que usas o que compraste. O FDE muda o que compraste até encaixar na forma como a tua gente trabalha a sério, e não como o manual diz que trabalha.
O teste decisivo é uma pergunta só: esta pessoa vai escrever código contra os meus sistemas, ou vai escrever sobre os meus sistemas? Tudo o resto são títulos.
O problema: a modalidade enterprise não foi feita para ti
Aqui chega a parte incómoda. O papel é real, é o que funciona, e a forma como se vende foi desenhada para o outro extremo do mercado. A versão enterprise é uma equipa dedicada durante meses, incrustada na organização, com um compromisso plurianual e —quase sempre— amarrada à plataforma de quem a implementa. Funciona. E uma empresa de 50 a 500 pessoas não a consegue comprar, por dois motivos diferentes que convém não misturar.
O primeiro é óbvio: o preço. O segundo é menos óbvio e é pior. Mesmo que pudesses pagá-lo, não tens trabalho suficiente para um posto a tempo inteiro, e um FDE sem fila de problemas transforma-se num empregado caro à espera. A necessidade da tua empresa não é contínua: é intensa durante seis ou oito semanas por processo, e depois desce a manutenção. Contratar para o quadro uma procura com essa forma é exatamente o erro que andas há anos a cometer com outros perfis.
E há um terceiro motivo, silencioso, que só aparece no ano seguinte: a amarra à plataforma. Se quem se incrusta na tua operação cobra pelo consumo do seu próprio produto, a solução que vai desenhar corre sobre o seu produto. Não por má-fé — por gravidade. É a mesma armadilha que se explica em plataformas para criar agentes de IA: o custo de saída não se paga quando assinas, paga-se no mês 7.
Não precisas do posto, precisas da função
A saída não é abdicar do papel. É comprá-lo com outra forma: em frações, por workflow e com um fim escrito. Em vez de um engenheiro incrustado indefinidamente, um trabalho limitado a um processo —o que mais dói— com uma data em que esse processo corre sozinho e uma pessoa da tua casa que fica como dono.
A diferença prática é que o objeto de compra deixa de ser tempo de uma pessoa e passa a ser um processo em produção. Muda quem assume o risco. Se o projeto se arrasta, no modelo de horas pagas mais; no modelo de resultado, não. É a mesma lógica que aplicamos ao montar agentes de IA para empresas, e a razão pela qual a primeira conversa é sempre sobre o processo e nunca sobre o modelo.
O trabalho real, além disso, parece-se muito pouco com o que a demonstração promete. A maior parte do calendário vai-se a integrar a IA com os sistemas que já tens —o ERP de 2011, o CRM com campos que ninguém se lembra para que servem, o Excel que na verdade é a base de dados da empresa— e a descobrir que o processo documentado e o processo real não se parecem nada. Isso não é um modelo melhor que resolve. Resolve-o alguém sentado ali.
As três coisas a exigir por escrito antes de assinar
Tanto faz quem contratas —fornecedor grande, boutique, freelancer, nós—. Se estas três não estiverem escritas antes de começar, o que compraste foi tempo, não resultado:
- Que processo fica em produção, com nome. Não «capacidades de IA na área comercial». O nome do processo, com o seu gatilho e a sua saída: «a classificação e a resposta inicial aos emails que entram no suporte». Se não cabe numa frase, não está delimitado.
- Como se mede, com o número de hoje. O indicador e o seu valor atual, medidos antes de começar. Sem a linha de base, daqui a três meses a discussão sobre se funcionou é uma discussão de opiniões, e essa ganha-a sempre quem fatura.
- Quem o opera quando quem veio se for embora. Nome e apelido do teu lado, formado durante o trabalho e não na última semana. É esta a que mais se salta e a única que decide se o sistema continua vivo no ano seguinte.
A terceira merece um parágrafo à parte, porque é onde morre a maioria das implementações que tecnicamente correram bem. Um processo automatizado sem dono interno não falha no primeiro mês: falha no dia em que muda uma regra de negócio e ninguém sabe onde se mexe. É o problema inteiro de quem mantém os agentes de IA, e não se resolve com documentação: resolve-se com uma pessoa que esteve à frente enquanto aquilo se construía.
O que este nome novo confirma
Que o mercado invente um título e monte uma unidade de negócio para o sustentar não é uma moda de nomenclatura: é a admissão pública de que o software sozinho não se implanta. Se o fabricante do modelo precisa de cento e cinquenta pessoas incrustadas nos seus clientes para o produto render, a pergunta a fazer ao teu fornecedor de IA deixa de ser que modelo usa e passa a ser quem se senta contigo e até quando.
Nós temos esse modelo desde o início, sem o título: empregados de IA que entregam um processo a funcionar, com dono interno e com a métrica escrita antes de começar. Se quiseres o vocabulário arrumado antes dessa conversa, está no glossário de AI Operations. A IA não se apresenta. Implementa-se —e alguém tem de estar lá no dia em que aquilo se parte—.