O que faz um engenheiro de IA no dia a dia

O que faz um engenheiro de IA na prática: ferramentas para agentes, avaliação, custo, dados e deploy. Diferenças para ML engineer e exemplos reais.

Um engenheiro de IA constrói software que usa modelos de linguagem prontos (como os da OpenAI e da Anthropic) para fazer um trabalho real: responder com base em documentos, consultar dados, agir em sistemas de negócio. Ele não treina o modelo. Ele decide o que o modelo pode ver e fazer, mede se o resultado está certo e mantém tudo funcionando em produção com custo e latência sob controle.

Sou engenheiro de IA e CTO da DockPlus AI. Abaixo está o que esse trabalho é de verdade, com exemplos dos meus projetos.

Engenheiro de IA, ML engineer, cientista de dados e engenheiro de software

Os quatro cargos se cruzam, mas o centro de cada um é diferente.

• Cientista de dados responde perguntas com dados: análise, experimento, modelo estatístico. O produto final costuma ser uma conclusão ou um modelo para outra pessoa colocar em produção.
• ML engineer treina, ajusta e serve modelos. Cuida de dataset, pipeline de treino, features, deploy de modelo e monitoramento de drift.
• Engenheiro de software constrói sistemas determinísticos: a mesma entrada gera a mesma saída, e um teste diz se está certo.
• Engenheiro de IA parte de um modelo já treinado e constrói o sistema em volta dele. O desafio é que a saída não é determinística. A mesma pergunta pode gerar duas respostas, e uma delas pode estar errada com toda a confiança.

Na prática, o engenheiro de IA é um engenheiro de software que aprendeu a trabalhar com um componente que às vezes erra. Quase todo o trabalho é colocar limites, medir e dar ao modelo o contexto certo.

O que faz um engenheiro de IA no dia a dia

O trabalho se divide em algumas frentes que aparecem em quase todo projeto.

Desenhar ferramentas para o agente

Um agente é um modelo que pode chamar funções. Desenhar essas funções é boa parte do trabalho: nome, parâmetros, descrição, o que ela devolve e o que ela nunca deve fazer.

No LedgerJob, um SaaS para empreiteiras dos EUA, o agente tem 66 ferramentas: leads, orçamentos, projetos, faturas, agenda. A mesma lista serve ao chat interno e a um servidor MCP, então uma ferramenta nova aparece nos dois lugares no mesmo deploy. A descrição de cada ferramenta é escrita para o modelo, e ela pesa tanto quanto o código.

Colocar limites (guardrails)

O modelo vai tentar coisas que não deveria. O engenheiro de IA decide onde fica a barreira.

No LedgerJob, 16 das 66 ferramentas exigem confirmação humana. Enviar e-mail ou SMS, gastar com terceiros ou apagar dados não roda dentro do loop do agente: vira um card que o usuário confirma. A identidade vem da API key, nunca do modelo, então o agente não consegue se passar por outro usuário.

No Achado de Leilão, o servidor MCP tem uma ferramenta de SQL livre. O limite está no banco e no servidor, não no prompt: sessão somente leitura, timeout de 15 segundos e no máximo 200 linhas por consulta.

Nos dois casos, o limite não depende de o modelo obedecer a uma instrução. Ele está no código ou no banco.

Controlar custo e latência

Cada chamada ao modelo custa tokens e tempo. Um loop de agente sem teto pode gastar muito numa pergunta só.

O loop do LedgerJob tem teto de 8 iterações por turno, e o resultado de cada ferramenta é cortado em 6.000 caracteres. Uma listagem grande de faturas não estoura o contexto nem o custo. São números pequenos no código, mas são o tipo de decisão que separa um protótipo de um sistema que roda todo dia.

Avaliar e observar

Sem medição, não dá para saber se uma mudança de prompt ou de modelo melhorou ou piorou o sistema. Na DockPlus uso o Langfuse para acompanhar latência, custo de tokens e qualidade das respostas.

Num projeto de RAG sobre aulas em vídeo que fiz para uma escola online, cada etapa da busca (resposta hipotética com HyDE, busca híbrida, rerank, transcrição) vira um span no Langfuse. Quando uma resposta sai ruim, dá para ver em qual etapa o problema começou. O mesmo sistema avisa o aluno quando a melhor pontuação da busca fica abaixo de 0,65, em vez de responder com uma confiança que não tem.

Testes automatizados também entram aqui. O backend do LedgerJob tem 59 arquivos de teste com 347 casos declarados. A regra de negócio fica na camada de serviço, não na rota HTTP, porque o agente e o MCP não passam pelo validador da rota. Assim ela vale para todos os caminhos.

Preparar os dados

Um agente só responde bem sobre o que consegue consultar. Muitas vezes o projeto começa antes do modelo, num pipeline de dados.

No Cape Cod Permits, os alvarás de obra de Massachusetts estão em seis sistemas municipais sem API comum. Escrevi um coletor por plataforma, todos gravando numa base PostgreSQL com dados de 74 municípios. O servidor MCP é somente leitura e vem com um guia do dataset que o agente lê antes de analisar, porque os campos não são padronizados entre municípios e uma comparação ingênua leva a conclusão errada.

Integrar e colocar em produção

O modelo raramente é a parte difícil. A parte difícil é ligá-lo ao que o cliente já usa. O LedgerJob conversa com Stripe, QuickBooks Online, Twilio, Google Calendar, EagleView, Hover e CompanyCam. Cada integração tem autenticação, limites de uso e jeitos próprios de falhar.

Depois vem o deploy: containers, banco, filas, logs, alertas. Trabalho com infraestrutura desde 2005, com Linux, bancos de alta disponibilidade e Ansible. Isso não aparece na demo, mas é o que faz um agente continuar de pé depois do primeiro mês.

Como eu trabalho: Claude Code e specs

Desenvolvo com Claude Code. Eu arquiteto o sistema (no LedgerJob, o backend, o agente e o servidor MCP) e o Claude Code escreve o código comigo. No AgentLab, meu laboratório de estudos de arquitetura de agentes, o desenvolvimento partiu de 12 specs escritas por funcionalidade antes do código.

Isso muda o dia a dia de um engenheiro de IA de um jeito curioso: passo a usar agentes para construir agentes. As mesmas preocupações valem dos dois lados. O que o agente pode fazer sozinho, o que precisa de revisão e como saber se o resultado está certo.

Como se tornar engenheiro de IA: o que estudar

Não existe um caminho único. Este é o que eu recomendaria a partir do que uso todo dia.

1. Programação de verdade. TypeScript ou Python, bem. APIs REST, banco de dados, testes. Sem isso, o resto não se sustenta.
2. APIs de modelos. Chamada de função (tool calling), streaming, saída estruturada, limites de contexto. Faça um agente pequeno do zero, sem framework, para entender o loop.
3. RAG. Embeddings, chunking, busca vetorial com pgvector, busca híbrida e rerank. Aprenda a dizer "não sei" quando a busca não acha nada bom.
4. MCP. O Model Context Protocol é um protocolo aberto para expor ferramentas e dados a agentes, e clientes como o Claude já falam com ele. Escrever um servidor MCP pequeno ensina muito sobre desenho de ferramentas.
5. Avaliação e observabilidade. Traces, custo por chamada, conjuntos de teste para respostas. Langfuse é um bom ponto de partida.
6. Frameworks, depois. LangGraph e LangChain ajudam quando o fluxo tem vários passos com estado. Entender o loop sem eles primeiro faz você usar melhor.
7. Produção. Docker, Linux, PostgreSQL, filas e logs. É aqui que muito projeto de IA para.

Construir um projeto completo ensina mais do que qualquer curso. Escolha um problema real, coloque no ar e meça.

Resumo

O que faz um engenheiro de IA, em uma linha: transforma um modelo que às vezes erra num sistema em que dá para confiar. Isso significa desenhar ferramentas, colocar limites fora do prompt, controlar custo, medir qualidade, preparar dados e operar tudo em produção.

Veja os projetos, minha trajetória na página sobre ou o meu perfil técnico.

Quer conversar sobre uma vaga ou um projeto? fale comigo