A adoção de IA não precisa de mais formação em sala. Precisa de expertise Forward Deployed.

A maioria das empresas já não precisa de ser convencida de que a IA importa.

Os colaboradores estão a experimentar o ChatGPT, o Claude, o Copilot e dezenas de ferramentas especializadas. As equipas de gestão discutem estratégias de IA. Os fornecedores de formação enchem calendários com workshops, sessões de prompt engineering e dias de inspiração.

E, no entanto, muitas organizações continuam, alguns meses depois, presas à mesma pergunta:

Onde está o impacto mensurável?

O problema não é necessariamente a falta de conhecimento de IA. É a lacuna entre saber o que a IA pode fazer e aplicá-la ao trabalho, aos sistemas, às restrições e às prioridades específicas de uma organização.

Essa lacuna é a razão pela qual acredito que uma abordagem que tem ganho terreno na indústria tecnológica vai entrar cada vez mais também na consultoria e nos serviços profissionais: Forward Deployed Engineering.

O nome pode soar técnico. O princípio é notavelmente simples.

Em vez de explicar a IA às pessoas à distância, coloque alguém com forte expertise em IA e em negócio ao lado das pessoas que fazem o trabalho real.

Compreenda o trabalho. Identifiquem oportunidades em conjunto. Priorizem-nas com a gestão. Depois construam.

O que é Forward Deployed Engineering?

O Forward Deployed Engineering, ou FDE, tornou-se conhecido através de empresas tecnológicas como a Palantir e está agora a ser adotado de forma muito mais ampla na indústria da IA.

A OpenAI, por exemplo, construiu uma organização dedicada de Forward Deployed Engineering. Os seus FDEs trabalham lado a lado com os clientes na discovery, no scoping técnico, no desenho de sistemas, na construção e no rollout para produção, com o sucesso medido pela adoção e pelo impacto mensurável nos workflows. A EY lançou os seus próprios papéis de Forward Deployed Engineer no Reino Unido e na Irlanda em 2026, posicionando-os explicitamente como uma forma de levar use cases de IA da experimentação para a produção.

A parte importante não é o título da função.

É o modelo operativo.

A consultoria tradicional separa frequentemente análise, recomendação e implementação. Uma equipa analisa a organização, produz recomendações, outra equipa traduz essas recomendações em requisitos e, eventualmente, alguém constrói alguma coisa.

Com a IA, essa sequência pode ser cada vez mais comprimida.

Pode observar-se um processo de manhã, prototipar uma alternativa à tarde e deixar o utilizador testá-la no dia seguinte.

Isso muda o que uma boa consultoria deve ser. (Para uma comparação mais aprofundada do FDE com agências, freelancers e fornecedores, veja O que é Forward Deployed Engineering?)

A adoção de IA começa no terreno

Pense em alguém das vendas que passa todas as manhãs a combinar informação de um sistema ERP, de emails e de folhas de cálculo antes de decidir que clientes contactar.

Ou em alguém das operações a ler manualmente encomendas em PDF e a transferir a informação para outro sistema.

Ou num colaborador de marketing a pesquisar prospects online e a preparar outreach personalizado.

Ou em alguém do prepress a passar horas em idas e vindas com clientes para pôr os ficheiros no formato certo.

Pode levar todas estas pessoas para uma sala e ensinar-lhes prompting, agentes e large language models.

Algumas sairão inspiradas. Algumas começarão a usar as ferramentas. Poucas tornar-se-ão muito boas nelas.

Mas continua sem ter redesenhado nenhum daqueles workflows.

Uma abordagem Forward Deployed começa noutro sítio.

Sente-se ao lado do colaborador e observe o trabalho a acontecer.

Que informação precisam?

De onde vem essa informação?

Que decisões exigem juízo?

Que partes são repetitivas?

Onde fazem copy-paste?

Que exceções tornam complicado o processo aparentemente simples?

Que sistemas estão envolvidos?

Que dados são sensíveis?

O que faz um cliente ou colega ligar a esta pessoa porque "só ela sabe como funciona"?

Estas perguntas revelam oportunidades que raramente emergem de uma sessão de formação em IA ou de um workshop de gestão isolado.

E há outra vantagem importante: o colaborador traz algo que o especialista de IA não tem.

Expertise de domínio.

A pessoa que executa o trabalho todos os dias compreende as exceções, o comportamento dos clientes, as decisões históricas, os dados maus e o contexto organizacional. O especialista de IA compreende o que se tornou recentemente possível do ponto de vista técnico.

A implementação de IA funciona melhor quando se juntam estas duas formas de expertise.

Um modelo diferente de implementação de IA

Na ScopeRight, o modelo que estamos a desenvolver é deliberadamente leve.

Não começa com um programa de transformação de seis meses.

Começa com um intake curto para compreender a estratégia, os objetivos, os sistemas e a maturidade atual de IA da empresa.

Depois começa o trabalho a sério.

1. Intake: compreender o contexto estratégico

Antes de procurar use cases de IA, é preciso compreender o que a organização está a tentar alcançar.

A prioridade é o crescimento?

A melhoria de margem?

Reduzir a carga administrativa?

Escalar sem aumentar o headcount?

Melhorar o serviço ao cliente?

Encurtar os prazos de entrega?

Reduzir a dependência de expertise escassa?

As oportunidades de IA não devem existir isoladas destas prioridades.

O intake cria, portanto, um enquadramento estratégico. Identifica também restrições óbvias de governação: dados sensíveis, requisitos de segurança, escolhas tecnológicas existentes e iniciativas já em curso.

Sem este passo, os programas de IA transformam-se facilmente numa coleção de experiências interessantes.

2. Meio dia ao lado dos colaboradores-chave

A seguir, um especialista de IA passa tempo focado com um pequeno número de colaboradores em funções estrategicamente relevantes.

Não a entrevistá-los a partir de uma sala de reuniões.

A observar realmente como o trabalho é feito.

Meio dia já pode revelar surpreendentemente muito quando o objetivo não é documentar cada processo, mas identificar onde a IA poderia mudar fundamentalmente a forma como o trabalho acontece.

O especialista de IA combina compreensão do negócio com profundidade técnica suficiente para reconhecer de imediato diferentes padrões de solução.

Algumas oportunidades podem exigir apenas usar corretamente uma ferramenta de IA existente.

Outras podem exigir ligar sistemas existentes.

Algumas podem ser resolvidas através de um agente configurável.

Outras justificam uma pequena aplicação à medida.

E, por vezes, a conclusão certa é não construir nada, porque a Microsoft, a Salesforce, a Adobe ou outra plataforma provavelmente vai resolver o problema de forma nativa.

A independência importa aqui.

O objetivo não é vender uma plataforma de IA em particular.

É encontrar a melhor forma de criar valor.

3. Construir a long list de oportunidades

O output não é imediatamente um enorme roadmap de IA.

É primeiro uma long list prática.

Para cada oportunidade, é preciso compreender pelo menos:

• Que problema estamos a resolver?
• Quem sente o problema?
• Como é o workflow atual?
• O que poderia a IA mudar?
• Quão grande poderia ser o impacto?
• Quão difícil é a implementação?
• Que dados e sistemas são necessários?
• Quais são as implicações de segurança ou governação?
• Devemos comprar, configurar, construir ou esperar?
• Como seria a versão útil mais pequena?

Esta última pergunta é particularmente importante.

Porque, em vez de definir imediatamente a solução acabada, define-se um Minimum Viable Agent — um MVA.

Do use case ao Minimum Viable Agent

O MVA é para a implementação de IA o que o MVP se tornou para o desenvolvimento de produto.

É a mais pequena versão de um workflow habilitado por IA capaz de provar se a ideia cria valor real.

Imagine uma organização de vendas com a ambição de criar um "assistente de vendas com IA".

Isso poderia tornar-se um projeto gigantesco.

Integração com o CRM. Integração de email. Research de contas. Lead scoring. Preparação de reuniões. Follow-up. Forecasting. Criação de propostas.

Em vez disso, o primeiro MVA poderia simplesmente fazer isto:

Todas as manhãs, analisar a informação disponível de clientes e prospects e dar a cada vendedor dez contas que vale a pena contactar hoje, juntamente com a razão e uma sugestão de mensagem de abertura.

Isso é suficientemente estreito para construir.

E suficientemente específico para medir.

O vendedor usa-o?

A informação é relevante?

Poupa tempo?

A atividade aumenta?

Leva a mais conversas?

Se a resposta for sim, expanda.

Se a resposta for não, aprendeu algo valioso sem gastar seis meses e um grande orçamento de transformação.

4. Debrief com a gestão: selecionar o que realmente importa

A long list volta então à gestão.

Este passo é crítico porque a descoberta bottom-up sem priorização top-down cria outro problema familiar: dezenas de ideias de IA interessantes a competir por atenção.

A gestão precisa de fazer escolhas.

Que oportunidades apoiam a nossa estratégia?

Onde está o valor económico?

Que problemas são genuinamente dolorosos?

Onde podemos aprender depressa?

O que não devemos ainda tocar por causa de segurança, qualidade de dados ou dependências?

Que iniciativas devem simplesmente usar um produto off-the-shelf?

E que workflows são suficientemente diferenciados para justificar algo à medida?

O resultado deve ser um pequeno número de MVAs deliberadamente selecionados, não um catálogo de possíveis experiências de IA.

Isso cria alinhamento estratégico antes de o desenvolvimento começar. (É exatamente isso que um AI Use Case Prioritisation & Scoping Workshop foi desenhado para produzir.)

5. Construir em sprints curtos de MVA

Uma vez selecionado um MVA, o modelo Forward Deployed não produz mais um deck de recomendações.

Constrói.

Idealmente num sprint medido em semanas, não em meses — o formato de um Minimal Viable Agent Sprint.

O colaborador que originalmente demonstrou o processo permanece envolvido ao longo desse sprint. Testa versões iniciais, explica exceções, desafia suposições e ajuda a moldar a solução.

O MVA evolui, portanto, dentro do ambiente onde acabará por ser usado.

Isso tem várias consequências importantes.

A aplicabilidade está embutida no processo, porque a solução nasce do trabalho real e não de um use case teórico.

O alinhamento estratégico está embutido, porque a gestão escolhe que oportunidades merecem investimento.

Os resultados chegam cedo, porque cada oportunidade selecionada tem de se tornar algo utilizável em vez de permanecer uma recomendação.

E, talvez o mais importante:

A formação acontece automaticamente.

A melhor formação em IA pode não parecer formação

Este é um dos aspetos do modelo que acho mais interessante.

As empresas sentem, compreensivelmente, que precisam de formar as suas pessoas em IA.

Mas enviar vinte colaboradores para uma sala durante um dia tem um custo substancial.

Vinte pessoas a passar oito horas em formação representam 160 horas de trabalho antes de qualquer coisa ter mudado operacionalmente.

E a transferência do conhecimento geral para o comportamento do dia a dia é incerta.

A implementação embebida inverte esse modelo.

Em vez de primeiro ensinar às pessoas tudo o que a IA poderá fazer, ensina-as enquanto resolvem um problema que lhes interessa.

Um colaborador trabalha ao lado do especialista de IA.

Aprende porque é que uma abordagem funciona e outra não. Vê o que o prompting consegue alcançar, o que é um agente, onde os dados se tornam importantes, porque é que as integrações importam, que restrições de segurança têm de ser consideradas e quando faz sentido uma construção à medida.

Mais importante ainda, começa a aprender a reconhecer, ele próprio, novas oportunidades de IA.

Isso cria um tipo de capacidade muito diferente.

O objetivo não é que todos se tornem especialistas em IA.

É que os colaboradores se tornem melhores a combinar a sua expertise de domínio com a compreensão do que a IA já consegue fazer.

Esta é a competência de que as organizações realmente precisam.

Da formação em IA à transformação contínua

Há outra razão pela qual o modelo tradicional de formação está em dificuldades.

A IA muda demasiado depressa.

Um currículo construído há seis meses pode já omitir capacidades importantes. Produtos que no ano passado exigiam desenvolvimento à medida podem tornar-se funcionalidade standard este ano. Os custos caem. Os modelos melhoram. As interfaces mudam. Surgem novas capacidades agênticas.

Portanto, a capacidade de IA não pode ser tratada como algo que uma organização aprende uma vez.

Precisa de um ciclo de feedback.

Observar.

Identificar oportunidades.

Priorizar.

Implementar.

Medir.

Aprender.

E repetir.

Algumas empresas acabarão por desenvolver esta capacidade internamente.

Outras continuarão a combinar especialistas de domínio internos com especialistas de IA externos e independentes que periodicamente trazem a perspetiva tecnológica mais recente.

De qualquer forma, a capacidade em si torna-se permanente.

Isto vai mudar a consultoria

Espero que este modelo influencie a consultoria muito para lá da IA.

Durante décadas, a economia da consultoria assentou em parte na escassez: a expertise era cara, a análise demorava e a implementação exigia grandes equipas.

A IA está a mudar essas restrições.

Equipas pequenas com forte juízo de negócio, conhecimento profundo do domínio e capacidades técnicas habilitadas por IA conseguem, cada vez mais, passar do problema ao protótipo a uma velocidade extraordinária.

A distinção entre consultor de estratégia, tecnólogo e especialista de implementação começa, assim, a esbater-se.

Isso não torna a estratégia menos importante.

Torna a distância entre estratégia e execução muito mais curta.

O consultor do futuro poderá passar menos tempo a produzir recomendações sobre o que uma empresa deve fazer e mais tempo a trabalhar ao lado dos colaboradores para determinar, construir e testar como a empresa poderia realmente funcionar de forma diferente.

Forward Deployed Engineering é um nome para essa mudança.

Para as PME, suspeito que a terminologia acabará por importar menos do que a promessa:

Levar a expertise de IA até ao trabalho, em vez de levar as pessoas para uma sala de formação de IA.

Partir de processos reais.

Combinar expertise de domínio com expertise de IA.

Alinhar as oportunidades com a gestão.

Construir a solução útil mais pequena.

Medir o que acontece.

E tornar a organização mais inteligente pelo caminho.

Esse é, para mim, um caminho muito mais convincente da ambição em IA para o impacto com IA.

---

Curioso sobre o que uma abordagem Forward Deployed revelaria na sua organização? Marque uma sessão de intake gratuita de 30 minutos. Ajudamos a encontrar os workflows onde a expertise de IA ao lado do trabalho — não numa sala de formação — cria impacto mensurável.