AI reading résumés in production: what we learned from 4,932 résumés in 4 weeks

Between August 14 and September 10, 2026, a language model read 4,932 résumés on the job portal of a nationwide recruitment network. It was not a pilot or a demo: real candidates sent real files, and the extracted data fed the database recruiters use to search and screen.

This post covers what the AI does in that flow, how the architecture was built, what went wrong, what we measured and what we decided not to apply. Every number comes from the technical audit we ran on September 10, 2026 over the code and the production database. The client appears only by industry.

The problem: résumés arrive in any format

A job portal runs on résumés. They arrive as well designed PDFs, scanned documents, files exported from other sites, sometimes as something that is not a résumé at all. For the recruiter, each of these files has to become the same thing: name, contact, dated work history, education, target role. Only then can candidates be searched, filtered and compared.

Done by hand, that is data entry. With fixed rules (regular expressions, reading PDFs by position), it breaks on the first unusual layout. A language model handles that middle ground well: it reads unstructured text and returns structured data. The question that matters is not whether AI can read one résumé, but whether it can handle thousands a month without stalling, without waste and without writing garbage to the database.

What the AI does in the flow

Résumé reading is the main function, but not the only one. In the measured period, the portal had these functions using the model:

• Résumé reading and extraction: the file goes to the model, which returns JSON with 13 fields defined by a schema. It runs when a candidate uploads, on sign up through the landing page, on social login and in a scheduled queue. 4,932 readings.
• Interview script: generated when a job opening is approved, with questions tied to the requirements. 70 runs.
• Structured job description: also generated on approval. 70 runs.
• Job promotion kit and company culture fit: support texts for the recruiter to review. 71 and 76 runs.
• Automatic screening: screening questions registered on the opening and answers evaluated in a queue. 3 runs in the period, since the feature was new.
• Final interview report: reads an attachment and drafts an assessment, delivered on September 10. 3 runs.

All functions other than résumé reading added up to about 340 operations. Résumé reading was 94% of the volume. That was the first lesson: usage and risk were not spread across screens, they were concentrated in one spot. And since that is where the whole file goes to the model, input tokens were more than four times the output.

High level architecture

What lets AI run in production without surprises has less to do with the model and more to do with what surrounds it.

A single API client

Every text function goes through one API client. That is where the timeout (45 seconds), low temperature (0.1), mandatory JSON response and the schema the model must follow live. A single entry point makes everything else easier: retry, circuit breaker, measurement. The only function that called the API outside that client, image generation, was exactly the one that left no trace in the log.

Queue with lock and spacing

A résumé uploaded by a candidate does not need to be read within the same second. Most go into a scheduled queue. After the audit, the queue got its own lock, atomic claiming of each item (only whoever marked it proceeds), a ten minute window to recover orphaned items, growing wait per attempt and 400 ms between items.

Limits and circuit breaker

When the provider reports an exhausted quota, a circuit breaker marks the AI as unavailable for 15 minutes and the portal stops insisting. Sign-up keeps working; the reading waits. It applies to every path that calls the AI, not only the queue.

Retry with backoff and a backup model

Transient errors (rate limit, server instability, network failure) deserve a new attempt with exponential backoff and jitter, honoring the wait the provider asks for. Definitive errors (invalid request) are not repeated. There is a backup model, but it is the last resort, not the first reaction: switching models at every hiccup changes extraction quality without anyone noticing.

Cache by file content

Keeping a hash of each uploaded file makes it possible to skip rereading an identical PDF, which goes straight at the main source of consumption. Applying it requires a business rule: when to reprocess (updated résumé, new prompt, a correction made by the candidate).

People decide

The AI extracts, organizes and suggests. Candidates have a review screen to check what was read, and the decision on who moves forward belongs to the recruiter. The AI approves or rejects no one.

What we adjusted after the audit

With the portal already in production, we audited the code and the call log to make the operation faster and more predictable. Three adjustments made the difference.

One request per operation

Each model accepts its own set of parameters. When the API client sends a parameter the model in use does not recognize, the call has to be made again, and that doubles the work without anyone noticing from the outside.

The adjustment was to send each parameter only to the model that accepts it. Before changing it, we tested with real calls to confirm nothing was lost in the response. Requests per operation dropped from two to one: less latency, less quota used and more predictability.

A queue with limits and a backup at the right time

Résumés arrive in waves. The queue got a concurrency limit and a single point of control, so two processes never pick up the same item. The backup model now kicks in only after a wait, not at the very instant of the first failure, so peaks are spread out instead of passed along.

The August 24 peak

August 24 had 744 résumés read, 2.2 times the second busiest day (340, on August 25), with 1,738 requests. The first hypothesis was the bulk candidate import done the same day. The code proved it wrong: résumés from spreadsheets are turned into PDFs from already structured data and never go through the AI. The exact cause of the peak was recorded as not measured. We prefer that to inventing an explanation.

The lean prompt we measured and did not apply

The reading prompt repeated instructions: "do not invent dates" appeared three times, three examples taught the same month conversion and a single subfield took 26% of the text. We wrote a lean version with the same 13 fields and measured both on an evaluation set of six synthetic résumés, in twelve real calls:

The input savings were real, but three résumés came out different. In one, the professional headline was shortened, because the example that taught the model to keep the whole line had been cut. In another, where the source lacked accents, the current prompt corrected them and the proposed one copied the source. The first draft of the lean prompt was worse: written without accents, it made the model return unaccented words even for accented résumés. Without the evaluation set, that would have reached the database. Decision: one more round before applying.

Privacy (LGPD) and human review

A résumé is personal data from start to finish: name, phone, work history, sometimes address. The project decisions start from that.

• Measurement without personal data: each call records function, model, attempt, status, tokens and time, and no résumé content. Error messages are scrubbed of emails and long digit sequences before going to the log.
• Evaluation with synthetic data: the six résumés in the test set are fictional and cover hard cases (operational profile without email, three date formats in one text, nearly empty résumé, a document that is not a résumé). No real candidate data enters the repository.
• Ask only for what you use: every extracted field needs a purpose. Reviewing the schema is part of the routine.
• Review before changing content: changes that affect what the AI extracts only go in after the evaluation set, a structure comparison and human review.
• Human decision: the AI organizes information; approving or rejecting a candidate is the recruiter's call.

For the legal and process side, our guide on LGPD in practice for systems and apps covers legal basis, consent and data subject rights.

Metrics that matter

Whoever puts AI into production usually looks only at the bill. The numbers below show why that is not enough: volume, input size and response time say more about the operation than cost does.

After the fix, every call records in its own table the calling function, model, attempt, status, input, output, cache and reasoning tokens, and time. The function is detected from the call stack, so any new entry point is measured from birth. Without that, no future savings could be proven.

The four metrics we recommend tracking from day one: requests per operation (should be 1), success rate per function, error distribution by type and input tokens per processed item. Total cost follows from those four.

When it pays off for a small business

This case is a portal with thousands of résumés a month, but the pattern fits any company that receives unstructured documents: orders by email, invoices, reports, contracts, registration forms.

• Worth it when the volume is recurring and someone today types or copies data from documents into a system.
• Worth it when errors are tolerable because there is review: the candidate checks, the agent approves, finance validates.
• Worth it when documents vary too much for fixed rules, but the result fits a closed schema.
• Not worth it when the data already arrives structured. The spreadsheet import in this case does not go through the AI, and that is right.
• Not worth it without measurement. If nobody knows how many requests each operation uses, nobody knows whether the AI is working or just looks like it.

If the question is where to start, our guide on generative AI for small businesses helps size the usage, and the one on AI process automation shows other flows where the same design applies.

Conclusion

Reading 4,932 résumés in 4 weeks with AI did not require a better model. It required a single API client, a locked queue, retry only for transient errors, a circuit breaker covering every path and per function measurement. Every new adjustment is measured first.

AI in production is software like any other: it breaks in predictable places, and whoever measures finds them.

Frequently asked questions

Does the AI decide who passes the hiring process?

No. In this case, the AI reads the résumé, extracts the data, suggests an interview script and organizes screening. The candidate reviews what was read and the decision on who moves forward belongs to the recruiter. Letting a language model approve or reject people on its own is a legal and quality risk we do not recommend.

How long does the AI take to read a résumé?

On the evaluation set of six synthetic résumés, reading took about 2.2 seconds per résumé (2,241 ms with the current prompt and 2,101 ms with the proposed one). In production, most readings go into a queue, so candidates do not wait for it to finish signing up.

Should you switch models when usage goes up?

Not always. Switching models changes extraction quality and requires a new evaluation round. First look at the surroundings: repeated calls, an uncontrolled queue, immediate retries and identical files read again. Switching only makes sense after measuring.

How does privacy law apply to résumés going through AI?

A résumé is personal data, so minimization and purpose apply. In this case, the measurement log stores no résumé content, error messages are scrubbed, tests use synthetic résumés and unused generated fields are listed for removal. Also review the API provider's contract and data policy.

My company receives few documents a month. Does it make sense?

It depends on how much time your team spends typing data from those documents and how much an error costs. At low volume, the gain is usually less about scale and more about standardization. What does not change: closed schema, human review and measurement from the first call.