IA lendo currículos em produção: o que aprendemos com 4.932 currículos em 4 semanas

Entre 14 de agosto e 10 de setembro de 2026, um modelo de linguagem leu 4.932 currículos no portal de vagas de uma rede nacional de recrutamento. Não foi piloto nem demonstração: foram candidatos reais enviando arquivos reais, e a leitura alimentando o banco que os recrutadores usam para buscar e triar.

Este texto conta o que a IA faz nesse fluxo, como a arquitetura foi montada, o que deu errado, o que medimos e o que decidimos não aplicar. Todos os números vêm da auditoria técnica que fizemos em 10/09/2026 sobre o código e a base de produção. O cliente aparece só pelo setor.

O problema: currículo chega em qualquer formato

Portal de vagas vive de currículo. Ele chega em PDF bem diagramado, em documento escaneado, em arquivo exportado de outro site, às vezes em algo que nem é currículo. Para o recrutador, cada um desses arquivos precisa virar a mesma coisa: nome, contato, experiências com datas, formação, cargo pretendido. Só assim dá para buscar, filtrar e comparar candidatos.

Feito à mão, isso é digitação. Com regras fixas (expressões regulares, leitura de PDF por posição), quebra no primeiro layout diferente. Um modelo de linguagem resolve bem esse meio-termo: lê texto sem estrutura e devolve dados estruturados. A pergunta que importa não é se a IA consegue ler um currículo, e sim se ela aguenta milhares por mês sem travar, sem desperdiçar e sem gravar lixo no banco.

O que a IA faz no fluxo

A leitura de currículo é a função principal, mas não a única. No período medido, o portal tinha estas funções usando o modelo:

• Leitura e extração de currículo: o arquivo vai para o modelo, que devolve um JSON com 13 campos definidos por schema. Dispara no envio pelo candidato, no cadastro pela página de captação, no login social e numa fila processada por agendamento. Foram 4.932 leituras.
• Roteiro de entrevista: gerado quando a vaga é aprovada, com perguntas ligadas aos requisitos. 70 execuções.
• Descrição estruturada da vaga: também gerada na aprovação da vaga. 70 execuções.
• Kit de divulgação da vaga e fit cultural da empresa: textos de apoio para o recrutador revisar. 71 e 76 execuções.
• Triagem automática: perguntas de triagem cadastradas na vaga e respostas avaliadas em fila. 3 execuções no período, porque a função era recente.
• Relatório final da entrevista: leitura de anexo e parecer, entregue em 10/09. 3 execuções.

Somadas, todas as funções que não são leitura de currículo deram cerca de 340 operações. A leitura de currículo respondeu por 94% do volume. Esse foi o primeiro aprendizado: o consumo e o risco não estavam espalhados pelas telas, estavam concentrados num único ponto. E como é nesse ponto que o arquivo inteiro vai para o modelo, a entrada de tokens era mais de quatro vezes a saída.

Arquitetura em alto nível

O desenho que deixa uma IA rodar em produção sem sustos tem menos a ver com o modelo e mais com o que fica em volta dele.

Um cliente único para a API

Todas as funções de texto passam por um único cliente da API. É nele que ficam o timeout (45 segundos), a temperatura baixa (0,1), a resposta obrigatória em JSON e o schema que o modelo tem que respeitar. Ponto único facilita tudo o que vem depois: retry, disjuntor, medição. A única função que chamava a API por fora desse cliente, a de geração de imagem, foi justamente a que ficou sem rastro no log.

Fila com lock e espaçamento

Currículo enviado por candidato não precisa ser lido no mesmo segundo. A maior parte entra numa fila processada por agendamento. Depois da auditoria, a fila ganhou lock próprio, reivindicação atômica de cada item (só processa quem conseguiu marcar), janela de dez minutos para recuperar item que ficou órfão, espera crescente por tentativa e 400 ms entre itens.

Limites e disjuntor

Quando o provedor acusa cota esgotada, um disjuntor marca a IA como indisponível por 15 minutos e o portal para de insistir. O cadastro continua funcionando; a leitura fica para depois. Vale para todos os caminhos que chamam a IA, não só para a fila.

Retry com espera e modelo de reserva

Erro transitório (limite de taxa, instabilidade do servidor, falha de rede) merece nova tentativa com espera exponencial e variação aleatória, respeitando o tempo que o provedor pede. Erro definitivo (requisição inválida) não se repete. Existe um modelo de reserva, mas ele é o último recurso, não a primeira reação: trocar de modelo a cada soluço muda a qualidade da extração sem ninguém perceber.

Cache pelo conteúdo do arquivo

Guardar um hash de cada arquivo recebido permite não reler um PDF idêntico, o que ataca direto a fonte dominante do consumo. Aplicar exige uma regra de negócio: quando reprocessar (currículo atualizado, prompt novo, correção feita pelo próprio candidato).

Quem decide é gente

A IA extrai, organiza e sugere. O candidato tem uma tela de revisão para conferir o que foi lido, e a decisão sobre quem avança no processo é do recrutador. A IA não aprova nem reprova ninguém.

O que ajustamos depois da auditoria

Com o portal já em produção, fizemos uma auditoria do código e do registro de chamadas para deixar a operação mais rápida e previsível. Três ajustes fizeram a diferença.

Uma requisição por operação

Cada modelo aceita um conjunto próprio de parâmetros. Quando o cliente de API envia um parâmetro que o modelo em uso não reconhece, a chamada precisa ser refeita, e isso dobra o trabalho sem ninguém perceber de fora.

O ajuste foi enviar cada parâmetro só para o modelo que o aceita. Antes de mudar, testamos com chamadas reais para confirmar que nada se perdia na resposta. As requisições por operação caíram de duas para uma: menos latência, menos consumo de cota e mais previsibilidade.

Fila com limite e reserva no momento certo

Currículo chega em ondas. A fila ganhou limite de concorrência e um único ponto de controle, para que dois processos nunca peguem o mesmo item. O modelo de reserva passou a entrar só depois de uma espera, e não no mesmo instante da primeira falha, para espaçar os picos em vez de repassá-los.

O pico de 24/08

O dia 24/08 teve 744 currículos lidos, 2,2 vezes o segundo maior dia (340, em 25/08), com 1.738 requisições. A primeira hipótese era a importação em massa de candidatos feita no mesmo dia. O código desmentiu: currículo vindo de planilha é convertido em PDF a partir dos dados já estruturados e nunca passa pela IA. A causa exata do pico ficou registrada como não medida. Preferimos isso a inventar uma explicação.

O prompt enxuto que medimos e não aplicamos

O prompt de leitura repetia instruções: "não invente datas" aparecia três vezes, três exemplos ensinavam a mesma conversão de mês e um único subcampo ocupava 26% do texto. Escrevemos uma versão enxuta com os mesmos 13 campos e medimos as duas num conjunto de avaliação com seis currículos sintéticos, em doze chamadas reais:

A economia de entrada era real, mas três currículos saíram diferentes. Num deles, o título profissional foi encurtado, porque o exemplo que ensinava a preservar a linha inteira tinha sido cortado. Em outro, onde a origem estava sem acento, o prompt atual corrigia e o proposto copiava. A primeira versão do prompt enxuto era pior: escrita sem acentos, fez o modelo devolver palavras sem acento mesmo em currículo acentuado. Sem o conjunto de avaliação, isso teria ido para o banco. Decisão: mais uma rodada antes de aplicar.

LGPD e revisão humana

Currículo é dado pessoal do começo ao fim: nome, telefone, histórico profissional, às vezes endereço. As decisões do projeto partem disso.

• Medição sem dado pessoal: cada chamada registra função, modelo, tentativa, status, tokens e tempo, e nenhum conteúdo do currículo. A mensagem de erro é higienizada contra e-mail e sequências longas de dígitos antes de ir para o log.
• Avaliação com dados sintéticos: os seis currículos do conjunto de teste são fictícios e cobrem casos difíceis (perfil operacional sem e-mail, três formatos de data no mesmo texto, currículo quase vazio, documento que nem é currículo). Nenhum dado de candidato real entra no repositório.
• Pedir só o que se usa: cada campo extraído precisa ter finalidade. A revisão do schema faz parte da rotina.
• Revisão antes de mudar conteúdo: mudanças que afetam o que a IA extrai só entram depois do conjunto de avaliação, da comparação de estrutura e de revisão humana.
• Decisão humana: a IA organiza a informação; aprovar ou recusar candidato é do recrutador.

Para o lado jurídico e de processos, o guia de LGPD na prática em sistemas e apps cobre base legal, consentimento e direitos do titular.

Métricas que importam

Quem coloca IA em produção costuma olhar só a fatura. Os números abaixo mostram por que isso não basta: volume, tamanho da entrada e tempo de resposta dizem mais sobre a operação do que o custo.

Depois da correção, toda chamada passou a gravar numa tabela própria a função que chamou, o modelo, a tentativa, o status, os tokens de entrada, saída, cache e raciocínio, e o tempo. A função é descoberta pela pilha de chamada, então qualquer ponto novo já nasce medido. Sem isso, nenhuma economia futura seria comprovável.

As quatro métricas que recomendamos acompanhar desde o primeiro dia: requisições por operação (deveria ser 1), taxa de sucesso por função, distribuição de erros por tipo e tokens de entrada por item processado. O custo total é consequência dessas quatro.

Quando vale a pena para uma PME

O case é de um portal com milhares de currículos por mês, mas o padrão serve para qualquer empresa que recebe documentos sem estrutura: pedidos por e-mail, notas, laudos, contratos, fichas de cadastro.

• Vale quando o volume é recorrente e alguém hoje digita ou copia dados de documentos para um sistema.
• Vale quando o erro é tolerável porque existe revisão: o candidato confere, o atendente aprova, o financeiro valida.
• Vale quando o documento varia demais para regra fixa, mas o resultado cabe num schema fechado.
• Não vale quando o dado já chega estruturado. A importação por planilha deste case não passa pela IA, e está certo assim.
• Não vale sem medição. Se ninguém sabe quantas requisições cada operação gasta, ninguém sabe se a IA está funcionando ou só parecendo funcionar.

Se a dúvida é por onde começar, o guia de IA generativa para PMEs ajuda a dimensionar o uso, e o de automação de processos com IA mostra outros fluxos onde o mesmo desenho se aplica.

Conclusão

Ler 4.932 currículos em 4 semanas com IA não exigiu um modelo melhor. Exigiu um cliente único para a API, fila com lock, retry só para o que é transitório, disjuntor valendo para todos os caminhos e medição por função. Cada novo ajuste passa antes por medição.

IA em produção é software como outro qualquer: dá errado em lugares previsíveis, e quem mede encontra.

Perguntas frequentes

A IA decide quem passa no processo seletivo?

Não. Neste case, a IA lê o currículo, extrai os dados, sugere roteiro de entrevista e organiza a triagem. O candidato revisa o que foi lido e a decisão sobre quem avança é do recrutador. Deixar um modelo de linguagem aprovar ou reprovar pessoas sozinho é um risco jurídico e de qualidade que não recomendamos.

Quanto tempo a IA leva para ler um currículo?

No conjunto de avaliação com seis currículos sintéticos, a leitura levou cerca de 2,2 segundos por currículo (2.241 ms com o prompt atual e 2.101 ms com o proposto). Em produção, a maior parte das leituras entra em fila, então o candidato não espera por ela para concluir o cadastro.

Vale a pena trocar de modelo quando o consumo sobe?

Nem sempre. Trocar de modelo muda a qualidade da extração e exige nova rodada de avaliação. Antes, vale olhar o entorno: chamadas repetidas, fila sem controle, reenvio imediato e arquivos idênticos lidos de novo. Só faz sentido trocar depois de medir.

Como fica a LGPD com currículos passando por IA?

Currículo é dado pessoal, então valem minimização e finalidade. No case, o log de medição não guarda conteúdo do currículo, as mensagens de erro são higienizadas, os testes usam currículos sintéticos e os campos gerados sem uso estão na lista para remoção. Revise também o contrato e a política de dados do provedor da API.

Minha empresa recebe poucos documentos por mês. Faz sentido?

Depende de quanto tempo sua equipe gasta digitando dados desses documentos e de quanto custa um erro. Com volume baixo, o ganho costuma estar menos na escala e mais na padronização. O que não muda: schema fechado, revisão humana e medição desde a primeira chamada.