A IA Vai Substituir os Engenheiros de PLN? A IA de Linguagem Remodelar Seus Próprios Construtores

Se você constrói sistemas de processamento de linguagem natural (PLN) para viver, aqui está um número que provavelmente o mantém acordado à noite: 73%. Essa é a pontuação de exposição à IA para engenheiros de Processamento de Linguagem Natural (PLN) — a mais alta de qualquer categoria de especialistas em IA que acompanhamos. Tradução: quase três quartos do que um engenheiro de PLN faz hoje pode ser tocado, acelerado ou parcialmente executado por um grande modelo de linguagem. A mesma tecnologia que você constrói está auditando sua descrição de cargo em tempo real.

Mas antes de atualizar seu currículo, observe o segundo número: 48% de risco de automação. Isso é alto para uma função tecnológica, mas está bem abaixo da pontuação de exposição. A lacuna entre os dois é onde toda a história vive. A IA pode fazer muito trabalho de PLN. A IA não consegue fazer todo o trabalho de PLN. O quarto restante é onde as carreiras serão feitas ou perdidas nos próximos cinco anos.

Este artigo percorre o que realmente está mudando para os engenheiros de PLN em 2025, quais tarefas estão sendo consumidas primeiro, quais estão se tornando mais difíceis (não mais fáceis) e como a função está se transformando em algo que não existia há três anos. Os dados aqui são extraídos da análise de nível de tarefa do O\*NET, do Índice Econômico da Anthropic e de relatórios recentes do mercado de trabalho da Brookings Institution e da Organização para a Cooperação e Desenvolvimento Econômico (OCDE).

Os Dois Números que Definem Seu Trabalho

Vamos decifrar os dados principais. Exposição à IA mede quanto do inventário de tarefas de uma função se sobrepõe ao que os sistemas de IA atuais podem realizar. Risco de automação estima quanto dessa sobreposição se traduzirá realmente em deslocamento de emprego dentro de cinco anos, considerando o julgamento humano, o atrito regulatório e os incentivos econômicos.

Para os engenheiros de PLN, a exposição é de 73% porque quase tudo que você faz envolve linguagem — e a linguagem é o território dos grandes modelos de linguagem. Tokenização, geração de embeddings, ajuste fino de modelos, engenharia de prompts, avaliação, análise de erros — cada um desses tem um assistente no estilo Transformer Pré-treinado Generativo (GPT) ou uma ferramenta especializada que pode lidar com uma fatia significativa do trabalho. A pontuação de exposição está essencialmente medindo o quanto o campo foi invadido pelo seu próprio produto.

O risco de automação de 48% é menor por três razões. Primeiro, o trabalho de PLN está se tornando cada vez mais crítico para a segurança: documentação médica, contratos jurídicos, moderação de conteúdo. Os erros acarretam responsabilidade. As empresas não vão remover o humano do ciclo rapidamente. Segundo, os problemas de PLN raramente são bem especificados. Os clientes vêm com intuições vagas ("torne nosso chatbot mais inteligente") e alguém precisa traduzir isso em um conjunto de dados rotulado, um framework de avaliação e um plano de implantação. Esse trabalho de tradução é profundamente humano. Terceiro, o campo está evoluindo tão rapidamente que os engenheiros de PLN são necessários para avaliar quais modelos, prompts e arquiteturas realmente funcionam para um determinado problema — e essa avaliação requer julgamento, não apenas computação.

Portanto, 73% de exposição com 48% de risco é a assinatura de uma função sendo transformada, não eliminada. [Alegação] Esse padrão é consistente com a literatura de pesquisa mais ampla: [Fato] o OECD Employment Outlook 2023 constatou que as ocupações mais _expostas_ à IA são as de habilidades elevadas, cognitivas não rotineiras — precisamente a categoria que a engenharia de PLN ocupa — ainda assim a exposição raramente se traduz um a um em deslocamento, porque essas funções também concentram as tarefas de julgamento e responsabilidade que a IA gerencia pior (OECD Employment Outlook 2023).

O Que a IA Já Está Fazendo ao Trabalho de Engenharia de PLN

Vamos nomear os fatos. Eis o que está genuinamente automatizado em 2025:

Código de treinamento de modelo padrão. Configurar um script de ajuste fino de transformer costumava ser um exercício de meio dia. Agora o Hugging Face Transformers mais um assistente de geração de código fornece um loop de treinamento funcional em doze minutos. [Fato] Segundo o Índice Econômico da Anthropic, o desenvolvimento de software é o uso mais comum do Claude em todos os países estudados, e no agente Claude Code especificamente 79% das conversas são classificadas como "automação" — onde a IA realiza a tarefa diretamente, em vez de apenas auxiliar o desenvolvedor (Índice Econômico da Anthropic, 2026). A engenharia de PLN, que é fortemente orientada por código, está no centro dessa onda de automação.

Engenharia de prompts para tarefas simples. Elaborar prompts para classificação, extração e sumarização em conjuntos de dados padrão é agora algo que os gerentes de produto fazem sem ajuda de engenharia. O nível do que conta como "engenharia" subiu.

Geração de dados sintéticos. Precisa de um conjunto de treinamento com 50.000 consultas de atendimento ao cliente? Os grandes modelos de linguagem as produzirão, com distribuição controlada de estilo e tópico, mais rapidamente do que você pode escrever as diretrizes de rotulagem.

Pipelines de avaliação padrão. BLEU, ROUGE, BERTScore, acurácia de correspondência exata — todas as métricas clássicas estão a uma chamada de ferramenta de distância. Até padrões de avaliação mais sofisticados, como LLM-como-juiz, agora estão modelados.

Documentação e relatórios. Escrever cartões de modelo, redigir resumos de experimentos, produzir narrativas de painel. A IA lida com 70% desse trabalho em equipes de PLN bem gerenciadas, com o engenheiro revisando a precisão.

O que isso significa concretamente: um engenheiro de PLN júnior em 2025 produz aproximadamente a produtividade de um engenheiro de nível médio de 2022. As ferramentas absorveram o trabalho cognitivo de rotina.

O Que a IA Conspicuamente Não Está Fazendo

Agora, o outro lado. Eis onde os engenheiros de PLN passam mais tempo do que nunca:

Enquadramento do problema. A maioria das falhas de PLN não são falhas de modelagem — são falhas de enquadramento. O cliente queria vinculação de entidades, não extração de entidades. O classificador foi treinado com dados limpos e implantado em um domínio com 30% de entrada fora da distribuição. Identificar essas incompatibilidades requer sentar com as partes interessadas e dissecar o que elas realmente querem. A IA é ruim nisso porque requer a leitura de um ambiente social.

Análise forense de qualidade de dados. Quando um modelo ajustado se comporta mal, descobrir o porquê quase sempre se resume a inspecionar exemplos de treinamento. Os rótulos estão errados. Os duplicados distorcem a distribuição. O conjunto de validação vaza para o treinamento. Esse trabalho é ficção de detetive com arquivos de valores separados por vírgulas (CSV), e os humanos ainda são muito melhores nisso.

Design de avaliação para problemas novos. Quando sua tarefa não tem um benchmark padrão, você precisa inventar um. Como é "bom" para um escriba médico de inteligência artificial? E para um analisador de contratos jurídicos? Construir rubricas, recrutar anotadores, calcular o acordo entre avaliadores e depois convencer a liderança de que seus números significam o que você diz que significam — essa é uma habilidade real que a IA não tocou.

Depuração de modelos em produção. Um modelo que funcionou perfeitamente na avaliação offline pode falhar espetacularmente na produção por razões que incluem: deriva de prompt, mudança de distribuição, envenenamento de cache, falhas de recuperação ou simplesmente má sorte com casos extremos. Rastrear qual desses é o culpado real é trabalho de engenharia prático.

Revisões de ética e segurança. Cada vez mais, os engenheiros de PLN são convocados para revisões onde a questão não é "isso funciona?" mas "isso deveria existir?" Auditorias de viés, red-teaming, documentação regulatória sob o Ato de IA da União Europeia (EU). Esse trabalho está se expandindo, não encolhendo.

As Tarefas Específicas com Maior Risco

Observando as tarefas do O\*NET para a função, o maior risco de automação se concentra em cinco áreas. Escrever scripts padrão de treinamento de modelos está aproximadamente 85% automatizado; o engenheiro agora é um editor que revisa código gerado por IA. Implementar pipelines clássicos de processamento de linguagem natural, como tokenização, marcação de classes gramaticais e reconhecimento de entidades nomeadas, é igualmente absorvido — todos os principais frameworks têm esses recursos prontos para uso. A exploração inicial de conjuntos de dados, o tipo onde você carrega um corpus e produz estatísticas resumidas, leva noventa por cento menos tempo com assistência de IA. A análise de erros de primeira passagem nas saídas do modelo agora é uma conversa de chat em vez de uma sessão de notebook. E redigir seções de artigos de pesquisa, incluindo trabalhos relacionados, descrições de métodos e até narrativas iniciais de resultados, é assistido por IA para 70% dos pesquisadores de PLN, segundo pesquisas recentes. [Estimativa]

Juntas, essas cinco categorias representam aproximadamente 45% do que costumava preencher a agenda de um engenheiro de PLN. Esse trabalho não desapareceu — ele se comprimiu. Onde você costumava passar três dias, agora passa três horas. O tempo restante é realocado para trabalho de maior alavancagem ou — cada vez mais — para lidar com uma área de responsabilidade maior.

As Tarefas que Ficaram Mais Difíceis

Aqui está a parte contraintuitiva. Algumas tarefas de PLN ficaram mais difíceis quando a IA melhorou. Especificamente:

Avaliação sob incerteza do modelo. Quando você tinha um único modelo fixo, avaliá-lo era simples. Agora você tem um sistema que chama múltiplos modelos, alterna entre eles com base em custo e latência, e produz saídas não determinísticas. Avaliar essa complexidade requer sofisticação estatística que o campo não precisava há três anos.

Otimização de custo-desempenho. Escolher entre GPT-4o, Claude Sonnet, um modelo de código aberto de 70B ajustado internamente ou um modelo pequeno com aumento de recuperação requer uma compreensão holística de orçamentos de latência, limites de precisão, restrições regulatórias e a posição de negociação da sua empresa com os fornecedores. Isso é parte economia, parte engenharia, parte política organizacional.

Depuração de prompt e cadeia. Um sistema de PLN moderno é frequentemente um grafo direcionado de chamadas de modelo de linguagem, cada um com seu próprio prompt, etapa de recuperação e lógica de validação. Quando o sistema se comporta mal, o bug pode estar em qualquer nó ou na orquestração entre eles. Rastrear esses sistemas é mais difícil do que depurar um modelo ajustado porque o espaço de estados é muito maior.

Responsabilidade por alucinações. Quando um sistema de Geração com Aumento de Recuperação (RAG) fornece uma resposta errada a um cliente, alguém tem que explicar por quê e evitar a recorrência. Isso agora faz parte do trabalho de um engenheiro de PLN, e requer entender não apenas seu modelo, mas todo o pipeline de recuperação, classificação e geração de resposta.

O efeito líquido: o _patamar_ do trabalho de um engenheiro de PLN subiu. As tarefas de rotina são feitas pela IA. O que sobra é genuinamente mais difícil do que o que a função costumava envolver.

Salário, Demanda e a Realidade do Mercado

O mercado de trabalho está enviando sinais mistos. Os dados salariais do Levels.fyi e do Glassdoor mostram que a remuneração dos engenheiros de PLN está 14% acima em comparação ao ano anterior nas empresas de primeira linha, com engenheiros de PLN sênior em laboratórios de fronteira recebendo remuneração total de $400.000 a $700.000. Mas as vagas para funções de PLN de nível básico estão 23% abaixo em comparação a 2023, segundo dados do LinkedIn Economic Graph. [Fato]

O padrão é claro: engenheiros de PLN experientes estão em maior demanda do que nunca, enquanto o pipeline de nível básico se estreitou acentuadamente. As empresas querem profissionais sênior capazes de arquitetar sistemas de IA e conduzi-los por avaliação, implantação e resposta a incidentes. Elas estão menos dispostas a pagar por engenheiros júnior cujo trabalho a IA agora realiza.

Para um engenheiro de PLN que lê isso, a implicação é desconfortável, mas acionável. Se você é sênior, seu valor está aumentando. Se você é júnior, precisa avançar rapidamente para habilidades de nível sênior: design de sistemas, rigor de avaliação, depuração sob incerteza e comunicação com as partes interessadas. Habilidades que eram "agradável ter" há dois anos agora são obrigatórias.

No Que se Concentrar Nos Próximos Três Anos

Um roteiro prático baseado no que realmente está dando resultado nas equipes de PLN atuais:

Torne-se um especialista em avaliação. A maioria das equipes de PLN não tem alguém capaz de avaliar rigorosamente um sistema de produção. Se você conseguir, torna-se indispensável. Leia a pesquisa da Anthropic sobre avaliação de modelos, o framework de Avaliação Holística de Modelos de Linguagem (HELM) e o trabalho de grupos acadêmicos sobre metodologia de avaliação. Construa protótipos de frameworks de avaliação para tarefas novas em sua empresa.

Domine a pilha de recuperação. Quase todos os sistemas de PLN interessantes em produção hoje envolvem recuperação. Bancos de dados vetoriais, busca híbrida, reranking, reescrita de consultas, fragmentação semântica. As equipes que acertam na recuperação lançam produtos confiáveis; as que improvisam lançam desastres propensos a alucinações. Aprenda essa camada profundamente.

Fique confortável com a infraestrutura de implantação. Saber como implantar um modelo atrás de um balanceador de carga, configurar o escalonamento automático, monitorar latência e custo e reverter quando algo quebra — é isso que distingue um engenheiro capaz de lançar produtos de um pesquisador que não consegue. Também é o que os assistentes de IA ainda não conseguem fazer por você.

Desenvolva profundidade de domínio. O trabalho genérico de PLN é o mais automatizável. A PLN aplicada a um domínio específico — saúde, jurídico, finanças, biologia — requer compreensão desse domínio. Escolha um e vá fundo. Os engenheiros que sobreviverão aos próximos cinco anos serão aqueles capazes de traduzir entre modelos de linguagem e um setor específico.

Pratique a escrita. Documentação interna, documentos de design, revisões pós-incidente, decisões para as quais não há precedente. Escrever com clareza é o que distingue engenheiros sênior, e a IA não pode fazer isso por você — não porque a IA não consiga gerar texto, mas porque o ato de escrever força o pensamento, e é pelo pensamento que a empresa está pagando.

A Visão Honesta de Longo Prazo

Daqui a cinco anos, como será o trabalho de um engenheiro de PLN? Provavelmente mais parecido com um gerente de produto para um sistema de IA do que com um engenheiro de software no sentido clássico. Você passará menos tempo escrevendo código de modelo e mais tempo definindo o que o sistema deve fazer, avaliando se ele o faz e conduzindo-o pela implantação e operações.

Alguns engenheiros de PLN atuais vão adorar essa evolução. Outros vão detestá-la. Se a parte do trabalho que você apreciava era a implementação elegante de modelos e código limpo, você encontrará essa parte do trabalho erodida. Se a parte que você apreciava era resolver problemas reais para usuários reais, este é provavelmente o melhor momento da história para estar no campo.

A função não está morrendo. Está mutando. Os engenheiros que reconhecem isso e se adaptam encontrarão suas carreiras mais interessantes e mais bem pagas do que nunca. Aqueles que não o fizerem se verão gradualmente pressionados para fora à medida que a IA lida com mais do que costumavam fazer.

Para dados mais detalhados, incluindo análises de automação no nível de tarefa, tendências salariais por região e uma linha do tempo das mudanças esperadas, consulte nosso perfil de ocupação de Engenheiros de Processamento de Linguagem Natural.

---

Análise baseada na modelagem de automação no nível de tarefa do ONET, no Índice Econômico da Anthropic (2025), nos relatórios do mercado de trabalho da Brookings Institution e nos dados do Observatório de Políticas de IA da OCDE. Pesquisa e redação assistidas por IA; revisão e edição humana pela equipe editorial do AIChangingWork.*