Os dois títulos soam quase iguais. Recrutadores trocam um pelo outro. Vagas misturam os dois. Até o LinkedIn agrupa "AI engineers (machine learning engineers)" numa única entrada no topo da sua lista de 2026 para os EUA.
Mas o trabalho é diferente. Contratar o errado raramente dá errado de forma barulhenta. Dá errado devagar: a pessoa é capaz, o projeto anda e, meses depois, o time percebe que a parte difícil nunca teve dono.
Veja como diferenciar os dois.
A versão curta
Um AI Engineer constrói aplicações sobre modelos que já existem. Pense em grandes modelos de linguagem, chamados por API ou hospedados por você. O trabalho é prompt, recuperação, avaliação, guardrails e integração ao produto.
Um ML Engineer constrói e opera modelos. Pense em modelos preditivos treinados com os seus dados: previsão, scoring, recomendação, classificação. O trabalho é treino, pipelines de features, deploy, monitoramento e retreino. Essa disciplina operacional se chama MLOps.
Um adapta um modelo genérico ao seu produto. O outro produz um modelo específico para o seu problema, e o mantém saudável.
Lado a lado
A pergunta central de cada um
- AI Engineer: "Como fazemos este modelo dar respostas boas, seguras e acessíveis dentro do nosso produto?"
- ML Engineer: "Como treinamos um modelo com os nossos dados e o mantemos preciso em produção?"
Trabalho típico
- AI Engineer: recuperação sobre documentos da empresa, desenho de prompt e contexto, avaliações de LLM, guardrails de saída, integração via API, ajuste de custo e latência.
- ML Engineer: engenharia de features, treino e validação de modelos, registro de modelos, inferência em lote e em tempo real, detecção de drift, retreino automatizado.
Ferramentas típicas
- AI Engineer: APIs de modelos, LangChain ou LlamaIndex, bancos vetoriais, FastAPI, serviços de AI em nuvem.
- ML Engineer: PyTorch, scikit-learn, MLflow, SageMaker ou Vertex AI, Databricks, Kubernetes, Airflow.
Como a qualidade é medida
- AI Engineer: conjuntos de avaliação com perguntas reais, pontuação humana e automática, taxa de respostas barradas por um guardrail.
- ML Engineer: acurácia, precisão e recall em dados separados para teste, e como essas métricas derivam com o tempo.
Os dois estão em alta
Não é uma escolha entre um papel da moda e um antigo. Os dois aparecem com força nos dados de mercado.
AI Engineer é o número um da lista Jobs on the Rise 2026 do LinkedIn nos EUA, e também o número um da lista de 2026 do LinkedIn no Brasil. Na análise da Lightcast sobre vagas de AI generativa, ML Engineer é o segundo título mais comum, com 2.951 vagas, logo depois de Data Scientist, com 3.301.
A demanda pelos dois é uma pista. Muitos projetos reais precisam de um pouco de cada.
Quatro perguntas para decidir
1. Você vai treinar um modelo ou usar um?
Se a resposta é "usar", comece com um AI Engineer. Se você precisa de um modelo que aprenda com o seu histórico, como prever demanda ou pontuar risco, precisa de um ML Engineer.
2. A saída é texto ou número?
Texto, resumos, respostas e conversas apontam para o AI Engineer. Scores, previsões, rankings e categorias apontam para o ML Engineer. É uma regra aproximada, não uma lei. Classificação dá para fazer dos dois jeitos, e a escolha depende de volume, custo e quantos dados rotulados você tem.
3. Onde ele quebra em produção?
Funcionalidades com LLM costumam quebrar em qualidade e custo: uma resposta errada, uma resposta lenta, uma conta que cresce. Modelos preditivos costumam quebrar por drift: o mundo muda, os dados mudam, a acurácia cai em silêncio. Contrate para a falha que você espera enfrentar.
4. Quem já está no seu time?
Se você tem cientistas de dados produzindo modelos que nunca saem do notebook, a lacuna é um ML Engineer. Se você tem desenvolvedores backend ligando APIs de modelo sem avaliação, a lacuna é um AI Engineer.
Quando você precisa dos dois
Alguns projetos cruzam a linha. Uma plataforma de suporte pode usar um LLM para rascunhar respostas e um modelo treinado para rotear chamados e prever escalonamento. Um fluxo de documentos pode usar um LLM para extrair campos e um classificador para detectar fraude.
A sobreposição mais comum é a produção. Uma funcionalidade com LLM em escala ainda precisa de monitoramento, versionamento, rollback e avaliação contínua. Essas são práticas de MLOps, e é o ML Engineer quem as traz. Levar pilotos para produção é um ponto fraco conhecido: na pesquisa da Deloitte, cerca de 70% das organizações tinham levado 30% ou menos dos seus experimentos de AI generativa para produção.
Por isso o Production Pod coloca um ML Engineer e um AI Architect no centro, com um AI Engineer reforçando o pipeline de AI. Para um produto novo, o AI Product Pod começa pelo AI Engineer.
Um erro comum de contratação
Muitos times contratam um ML Engineer para um produto com LLM porque o título soa sênior e familiar. A pessoa passa meses construindo pipelines de treino de que o produto nunca precisou. O contrário também acontece: pedem a um AI Engineer que mantenha um modelo de fraude, e ninguém percebe o drift até os números saírem errados.
Nenhuma das duas pessoas falhou. A combinação falhou. Escreva primeiro o problema mais difícil, depois escolha o papel.
Os vizinhos que vale conhecer
Outros dois papéis costumam entrar nessa decisão.
Data Scientist. Formula a pergunta de negócio, explora os dados e constrói os primeiros modelos. Forte em experimentos e análise. Muitas vezes é de quem o ML Engineer leva os modelos para produção.
Data Engineer. Constrói os pipelines que alimentam todos os outros. Se os dados não são confiáveis, nem o AI Engineer nem o ML Engineer vão longe.
Um jeito rápido de lembrar
- Construir com modelos de linguagem: AI Engineer.
- Treinar e operar seus próprios modelos: ML Engineer.
- Sem saber se o problema é dado, modelo ou produto: comece descrevendo o problema, não o título.
Títulos ajudam numa busca. Não definem um projeto. Compare os papéis pelo trabalho que fazem e escolha o que corresponde à parte mais difícil do seu.