O que faz um engenheiro de IA: a rotina real em 2026

Em 2024, "Engenheiro de IA" era cargo inventado por recrutador no LinkedIn. Tinha post viral toda semana dizendo que era a próxima profissão do futuro. Em 2026, é o sênior mais disputado dos Estados Unidos.

A diferença é que agora ele entrega coisa de verdade. Não é prompt mágico. Não é "automatizar o trabalho com ChatGPT". É construir, operar e manter sistemas que rodam LLMs em produção, com eval, observability, custo controlado e produto em cima.

Neste post você vai entender, na prática, o que faz um Engenheiro de IA em 2026 — sem o hype de recrutador. Diferença para ML Engineer, desenvolvedor de IA e cientista de dados, as 5 entregas que aparecem em qualquer JD sênior, a rotina hora a hora de uma semana real e o stack típico do dia a dia.

TL;DR

• O que é: dev que constrói produtos sobre LLMs — do protótipo ao serviço em produção.
• Stack típico em 2026: LLM API + harness/orquestração + vector store + evals + observability.
• Mercado: #1 cargo que mais cresce nos EUA segundo o LinkedIn Jobs on the Rise 2026. Mediana de 3,7 anos de experiência prévia. Salário sênior US partindo de US$ 200k base.
• Origem mais comum: Software Engineer, Data Scientist, Full Stack — nessa ordem.

De cargo inventado pelo LinkedIn ao mais disputado de 2026

A briga sobre se "AI Engineer" era cargo de verdade ou marketing terminou. Os números resolveram.

O relatório LinkedIn Jobs on the Rise 2026 colocou Engenheiro de IA como o cargo que mais cresce nos Estados Unidos. Entre 2023 e 2025 o LinkedIn somou 639 mil vagas relacionadas a IA no país, das quais cerca de 75 mil eram especificamente para AI Engineer. A demanda cresceu 74% ano a ano em 2026, contra 38% para ML Engineer e 12% para Data Scientist.

Salário sênior nos EUA parte de US$ 200k base e vai até US$ 312k, com pacotes em big techs cruzando US$ 900k de total comp. No Brasil ainda é mais discreto — as três faixas reais (CLT, PJ e contrato gringo) estão abertas em quanto ganha um engenheiro de IA no Brasil em 2026 —, mas a curva está subindo no mesmo ritmo. Empresas que não fecham os US$ 200k base nos EUA estão levando 114 dias em média para preencher a vaga.

Não é hype. É escassez real de gente que sabe o que está fazendo.

AI Engineer não é ML Engineer e não é Data Scientist

A confusão entre os três cargos é a maior fonte de candidatura no lugar errado.

Resumo grosseiro mas útil:

• Data Scientist responde perguntas de negócio. Roda experimento, faz forecast, comunica para stakeholder. Saída do trabalho dele é insight.
• ML Engineer treina, deploya e opera modelos próprios em produção. Saída é o modelo servindo tráfego.
• AI Engineer embute LLM, RAG, agentes e tools dentro de aplicação. Saída é uma feature em produção que usa IA.

A análise da AI Shipping Labs sobre 889 JDs publicadas em janeiro de 2026 deixa explícito: 70% das vagas de AI Engineer são "AI-First" — trabalho direto com LLMs, RAG e agentes — e menos de 2% pedem ML clássico (treinar modelo, escolher algoritmo, ajustar hiperparâmetro).

Quem aplica para AI Engineer pensando que vai treinar modelo está candidato à vaga errada. Quem aplica para ML Engineer pensando que vai construir RAG, mesma coisa.

E a diferença para desenvolvedor de IA e cientista de dados

Os três títulos brigam pela mesma busca e pagam faixas diferentes. Vale separar.

Desenvolvedor de IA é o dev de produto que consome IA: chama a API, integra o SDK, entrega a feature. O escopo dele termina quando a resposta chega na tela. Engenheiro de IA responde pelo comportamento do sistema depois que ele está no ar — eval, trace, custo, fallback, regressão a cada deploy. A linha não é quem escreve mais código; é quem é acordado quando o sistema erra em produção. Abri as sete diferenças de escopo, skill, salário e carreira em desenvolvedor de IA vs engenheiro de IA.

Cientista de dados não é um nível abaixo nem acima: é outra profissão. Ele parte de dado histórico e produz insight, modelo estatístico, experimento com significância. O engenheiro de IA parte de um modelo pronto de terceiro e produz sistema. Um mede p-valor e lift; o outro mede taxa de alucinação, latência p95 e custo por requisição. Compartilham Python e rigor com métrica, e param por aí.

Na dúvida ao ler uma vaga, procure a palavra "produção". Se a entrega esperada é insight, dashboard ou relatório, é ciência de dados. Se é feature no ar, com SLA e alguém de plantão, é engenharia.

As 5 entregas que aparecem em qualquer JD sênior de AI Engineer

Olhando as JDs reais, sempre as mesmas cinco coisas:

1. Aplicação end-to-end alimentada por LLM. Do protótipo no notebook até o serviço com SLA. Backend, infra, fila, retry, observabilidade. Exatamente o trabalho de um SRE/backend dev, com a diferença de que parte da lógica é probabilística.

2. RAG sobre dados proprietários. Ingestão de documentos, chunking, embeddings, vector store, retrieval, reranking, montagem de contexto. Não é "plugar Pinecone e rezar". É decidir qual chunk size usa, qual reranker entra, como cita fonte, como mede recall.

3. Pipelines de avaliação e observability. Esse aqui separa o sênior do resto. Trace de cada chamada, eval automatizada, regressão antes de cada deploy, dashboard de drift. "Deu boa" não é métrica. Saber que o pipeline alucinou em 8% dos casos da última semana e cair pra 2% antes da próxima sprint é métrica.

4. Operação de APIs de modelos externos. Custo por requisição, latência p95, fallback entre provedores, rate limit, cache, retries com backoff. Quem nunca operou serviço externo em produção apanha aqui.

5. Workflows multi-step com agentes. Tools, function calling, orquestração de passos, guardrails, recuperação de erro no meio do loop. É onde harness aparece — o scaffolding que envolve o modelo e dá controle ao engenheiro.

Essas cinco entregas são o dia a dia. Não tem prompt mágico em nenhuma.

A rotina de um engenheiro de IA, hora a hora

Descrição de vaga lista atribuição no abstrato. Ninguém conta como o relógio realmente se parte — e é aí que mora quase toda a frustração de quem entra na área esperando uma coisa e encontrando outra.

A divisão que eu vejo numa semana de 40 horas, num time de produto com sistema de IA já no ar (não em protótipo):

• ~10h de código de aplicação. Backend, tools, integração, o harness em volta do modelo. Menos do que você imagina.
• ~8h de eval. Curar dataset, escrever critério de acerto, rodar a suíte, discutir por que o número mexeu.
• ~6h lendo trace. Um a um, no painel de observability. É debugging de comportamento, não de stack trace.
• ~6h de reunião. Refinamento, alinhamento com produto sobre o que conta como "resposta aceitável", review, incidente.
• ~5h de custo, latência e infra. Rate limit, cache, fallback entre provedores, deploy canário.
• ~5h de leitura. Release note de modelo, changelog de SDK, teste de versão nova. O chão muda a cada poucas semanas.

Repare no que isso significa: menos de um quarto do tempo é escrever código novo. Se a sua imagem do cargo era "programar o dia inteiro com IA", ela está errada por um fator de três.

O dia típico, em ordem:

9h — triagem de trace. Abro o painel filtrado pelas últimas 24h: casos com nota baixa do juiz automático, chamadas que estouraram a latência alvo, tool calls que voltaram erro. Leio de dez a trinta traces inteiros, do prompt de sistema até a última tool. Isso vira ticket, não relatório.

10h30 — bloco de código. A janela mais longa e contígua do dia, e a única em que dá pra pensar fundo. Aqui entra o que virou ticket ontem: uma tool nova, um guardrail, ou mudar o roteamento para mandar caso simples ao modelo barato e caso ambíguo ao modelo caro.

13h — eval. Rodo a suíte contra o dataset de regressão antes de qualquer merge. Algumas centenas de casos levam minutos e custam poucos dólares — e é isso que impede "melhorei o prompt" de virar regressão silenciosa em produção. Quando o número piora, volto pro trace em vez de chutar outro prompt.

15h — reunião. Quase sempre a mesma conversa: produto quer saber por que o sistema erra "coisa óbvia". O trabalho é traduzir probabilidade em decisão de produto — onde a gente aceita erro, onde exige que o sistema se abstenha, e onde pede confirmação humana antes de agir.

16h30 — custo e sobra. Olhar gasto por endpoint, achar o prompt que engordou sem ninguém notar, revisar alerta. É a meia hora mais barata do dia e a que mais paga: um cache de contexto bem colocado ou um roteamento por dificuldade corta a conta em dois dígitos percentuais.

As ferramentas que eu abro literalmente todo dia são poucas: o editor com um agente de código dentro, o painel de tracing (Langfuse, LangSmith ou Phoenix, tanto faz), a suíte de evals, o console do provedor para ver gasto e rate limit, e o Git. Vector store, notebook e console de infra entram por temporada, não diariamente.

E o que ninguém avisa que vai comer o seu tempo:

• Curar dataset de avaliação. Trabalho manual, chato e pouco delegável. Sem dataset você não tem métrica, e sem métrica você não tem engenharia: tem opinião com sotaque técnico.
• Reproduzir bug não-determinístico. O mesmo input devolve resposta diferente. Você aprende a raciocinar sobre distribuição de saída, rodando o caso N vezes, em vez de caçar "o" bug.
• Versionar prompt como código. Prompt em string solta espalhada pelo repositório é dívida que cobra juros na primeira troca de modelo.
• Troca de modelo. Sai versão nova, a antiga é depreciada, e parte dos seus prompts muda de comportamento sem aviso. Sem suíte de eval, essa migração vira fé.
• Explicar o mesmo trade-off cinco vezes. Custo contra qualidade contra latência, para produto, para liderança e para o time. Faz parte do cargo, não é interrupção dele.

Se essa rotina parece mais dura que a lista de atribuições da vaga, é porque é. O que trava quem está entrando não é o bloco de código das 10h30 — é todo o resto: roteamento, eval que não mente, leitura de trace, grounding, custo. A rotina acima é o conteúdo do Lab, na mesma ordem: tool calling, structured output, roteamento, memória, grounding, tracing, evals e custo, montando arquitetura de agente em produção. É a 3ª edição do AI Engineering Lab, 19 e 20/09/2026, das 9h às 13h, online ao vivo no Google Meet. Lote 1 a R$ 37.

O stack típico do AI Engineer em 2026

Da análise das 889 JDs, as skills mais pedidas em ordem:

Note o que essa tabela está dizendo: quatro das dez skills mais pedidas são puramente de engenharia de software (AWS, Docker, CI/CD, Kubernetes). Apenas duas são especificamente de IA (RAG, Prompt Engineering). PyTorch aparece, mas com peso menor que TypeScript.

Em 2026 o stack canônico de um time de AI Engineering tem cinco camadas:

• Modelo: LLM via API (Claude, GPT, Gemini), com fallback entre provedores. Fine-tuning ainda existe, mas é minoria das vagas.
• Harness: o scaffolding em volta do modelo. Loop de execução, ferramentas, contexto, memória, guardrails. A OpenAI formalizou o termo "harness engineering" em fevereiro de 2026, descrevendo como construíram seu próprio harness para rodar Codex em escala. Ryan Lopopolo, da OpenAI, resumiu: "construímos o Harness para oferecer um modo confiável de executar workloads em escala".
• Memória e retrieval: vector store (Pinecone, pgvector, Qdrant) + camada que decide quando puxar do vector e quando puxar da memória do agente.
• Evals: Braintrust (usado por Stripe, Notion, Dropbox, Perplexity), Langfuse (open-source), Promptfoo, RAGAS, DeepEval. Pelo menos um deles está em qualquer time sério.
• Observability: trace por requisição, custo, latência, taxa de erro, drift de qualidade. LangSmith, Langfuse, Phoenix, AgentOps.

Quem só sabe a primeira camada (chamar a API do modelo) é júnior. Sênior domina as cinco.

Por que a maioria dos AI Engineers veio de backend, não de Data Science

O LinkedIn Jobs on the Rise 2026 listou as três principais origens dos AI Engineers atuais: Software Engineer, Data Scientist e Full Stack Engineer — nessa ordem.

Isso surpreende quem achava que IA era território de PhD. Mas faz sentido quando você olha as cinco entregas acima. Quatro delas são, no fim, problemas de engenharia de sistemas distribuídos: deploy confiável, latência, retry, observability, custo. O backend dev já apanhou nessas dores antes. Falta aprender prompt design, RAG, harness e eval — semanas de estudo, não anos.

O Data Scientist tem a vantagem do raciocínio sobre dado e métrica, mas precisa aprender o lado de engenharia: CI/CD, container, infra, observability. Por isso a transição mais comum hoje é justamente DS → AI Engineer.

A mediana de experiência prévia é de 3,7 anos. Não é cargo de júnior recém-formado. É cargo de pleno virando sênior em uma especialização nova.

Como é o dia 1 num projeto real

Para tirar a poeira da abstração, dia 1 num projeto real costuma ser assim:

O ticket que cai na sua mesa não é "treine um modelo". É algo do tipo: "esse pipeline de RAG está alucinando em 8% dos casos do dataset de regressão. Investigue, baixe pra menos de 2%, sem aumentar custo de inferência."

Você abre o dashboard de tracing, filtra os casos que falharam, reproduz cada um. Descobre que três quartos dos erros vêm de retrieval ruim (chunk errado entrou no contexto), não de problema de prompt. Ajusta o reranker, reescreve dois prompts, adiciona um tool de validação no harness. Roda a suíte de evals offline, valida que o número caiu para 1,4%. Faz o deploy canário em 5% do tráfego, monitora por 24h, promove se a métrica online bater a offline.

Esse dia 1 é mais parecido com SRE que com pesquisador. E é exatamente isso que o mercado está pagando US$ 200k+ para encontrar — alguém que sabe construir, medir e operar um harness próprio sobre LLM, com a disciplina de quem já operou serviço crítico em produção. É esse pipeline inteiro — harness, evals, tracing, decisão de arquitetura — que vamos abrir ao vivo no Harness Engineering com Claude Code, do loop autônomo até o agente em produção.

Armadilhas do mercado e como ler uma JD

Nem toda vaga "AI Engineer" é vaga de AI Engineer. Como o cargo virou label quente, recrutador joga ele em qualquer coisa.

Sinais de vaga ruim:

• Pede "criar prompts e automações com ChatGPT" e nada de evals, observability ou produção. É vaga de prompt engineer com salário disfarçado.
• Não menciona métricas, custo, latência, regressão. Provavelmente é PowerPoint Engineer.
• Pede 5 anos de experiência em LLM (que tem 3 anos de existência prática).
• Faixa salarial junior para responsabilidades de sênior. Aproveitando o hype.

Sinais de vaga boa:

• Cita stack de eval (Braintrust, Langfuse, Promptfoo) ou observability (LangSmith, Phoenix).
• Menciona "production", "RAG", "agentes", "tools", "harness", "guardrails".
• Pede experiência com infra (AWS, Docker, K8s, CI/CD).
• Descreve o problema de negócio, não só a tecnologia.

Quando a JD cita as cinco entregas — end-to-end, RAG, eval, operação de API, agentes — está claro que tem alguém sênior do outro lado escrevendo. Vale entrar — e, se for entrar, a preparação é outra etapa: separei 30 perguntas de entrevista para AI engineer com a resposta que eu daria em cada uma e o red flag que entrega o júnior.

O que o engenheiro de IA NÃO faz

Vale fechar o desenho pelo negativo, porque boa parte do mal-entendido sobre o cargo vem de imaginar tarefas que ele não tem. Quatro coisas que quase nunca aparecem na rotina descrita acima:

• Treinar foundation model. Isso acontece em lab de pesquisa, com cluster de GPU e orçamento de centenas de milhões. O engenheiro de IA consome o modelo pronto e responde pelo que acontece em volta dele.
• Depender de PhD. Menos de 2% das 889 JDs pedem ML clássico. A vaga de produto pede engenharia, evals e operação — tese ajuda em research lab, não em time de feature.
• Viver de fine-tuning. Em 2026, prompt versionado, RAG bem medido e suíte de eval resolvem a maioria dos casos antes de qualquer peso ser ajustado. Fine-tuning existe, mas é minoria e chega por último.
• "Usar ChatGPT no trabalho". Pedir código pro assistente e colar não é engenharia de IA. O cargo é de quem constrói o produto com IA — arquitetura, contexto, avaliação e segurança — não de quem usa IA para trabalhar.

Se quiser esses quatro mitos abertos um a um, com o contraste contra o que a rotina de fato exige, estão em 4 mitos sobre o engenheiro de IA.

FAQ rápido

Preciso de mestrado ou PhD? Não. Para a maioria das vagas, conhecimento de produção e arquitetura pesa muito mais que paper. PhD ajuda em research labs, não em time de produto.

Tenho que aprender PyTorch? Bom de saber, mas só aparece em 22% das JDs. Se você não vai treinar modelo (e a maioria não vai), priorize Python, RAG, evals e observability.

LangChain ou direto na API? As duas. Para protótipo rápido, LangChain ou similar acelera. Para produção séria, muita gente caí no SDK direto do provedor para ter controle de tracing, custo e fallback. Saber escolher é o diferencial.

Vale migrar de Data Science para AI Engineer? Em 2026, é a transição mais popular nos EUA segundo o LinkedIn. A base estatística e Python transferem. O que precisa adicionar é engenharia de software de verdade: CI/CD, container, observability, retry, custo. É absorvível em meses, não anos.

Dá para entrar vindo de backend PHP/Laravel? Dá, e é um dos caminhos mais curtos. Quem já opera serviço em produção — fila, retry, deploy, alguém de plantão — chega com quatro das cinco entregas resolvidas na cabeça. O que falta é a camada de LLM: tool calling, RAG, harness e eval, e isso se aprende em semanas, não em anos. O raciocínio completo desse caminho está em 4 mitos sobre o engenheiro de IA.

Preciso de framework da moda para começar? Não. O primeiro projeto sério cabe em uma LLM API chamada direto, um caso real e um dataset de eval pequeno. LangGraph, CrewAI ou Agent SDK entram quando o fluxo cresce e a máquina de estado começa a doer na mão — não antes.

Conclusão

Engenheiro de IA em 2026 não é o cargo que o LinkedIn imaginou em 2024. É um papel técnico bem definido, com cinco entregas claras e um stack canônico: LLM API, harness, vector store, evals, observability. Cargo de pleno virando sênior, na faixa salarial mais agressiva do mercado, e ainda escasso de gente boa.

A parte do trabalho que mais separa o profissional do hype é exatamente o harness — o scaffolding em volta do modelo onde mora a engenharia de verdade. Quem domina harness deixa de ser "o cara que usa ChatGPT no trabalho" e passa a ser quem coloca IA em produção sem o time acordar de madrugada. Se você quer ver isso aplicado num projeto real, com loop autônomo, evals e agente de fato em produção, é o que vamos construir ao vivo no Harness Engineering com Claude Code.

A próxima onda do dev sênior não é virar pesquisador de IA. É construir o harness por trás do produto.