The Messy, Human Problem Hiding Inside “Just Extract The Data”

Aug 20, 2026 | Blog

Reading Time: 4 minutes

On paper, it sounds like the easy part. Read a document, pull out a name, a designation, a joining date, a salary figure. A person does it in under a minute without thinking twice. Surely an AI model built to read and reason about language can do the same thing without breaking a sweat.

Then you actually try it, and you remember that "just read the document" is doing an enormous amount of hidden work.

ExtractThe fieldsCandidate nameEmployee IDDesignationClient nameDate of joiningAddress and CTCDecideEmployee groupStrictly BNP or MITS2Drives template choiceWrong value here meansthe wrong letterheadProveThe audit trailfirstCallResponse.jsonsaved beside the outputso a human can checkwhat the model believed
The hard part is not extraction. It is being able to prove months later what was read.

Real HR source documents are not clean. They're offer notes copy-pasted from an email thread, with a client's original formatting half-preserved and half-mangled. They're internal memos where the designation is mentioned once, informally, three paragraphs in. They're addresses that wrap across four lines with no consistent punctuation, dates written as "15th of March" in one document and "15/03/2026" in the next, and CTC figures sometimes written as "8.4 LPA" and sometimes as "₹8,40,000 per annum" for the exact same number. A rigid parser — the kind that looks for a label and grabs whatever comes after a colon — falls over instantly. There often isn't a label to find.

This is precisely the gap the MITS AI Letter Writer's first AI call is built to close, and it's worth being honest about what makes it hard, not just what makes it work.

The Prompt Is the Product

The extraction prompt handed to GPT-4o isn't a throwaway instruction — it's closer to a carefully maintained specification, because it is, in a very real sense, the most fragile and most important piece of the entire system. It has to tell the model exactly which fields to look for, exactly what shape to return them in, and exactly how to behave when a field simply isn't present in the source document, because guessing a candidate's date of joining is far worse than honestly returning nothing.

That prompt targets a strongly typed model, FirstCallResponse, on purpose. It would be easier, in the short term, to let the AI return a loose blob of freeform text and parse it downstream with regular expressions. It would also be fragile in exactly the way that breaks silently in production, months later, on one weird input nobody tested. Forcing a defined shape up front means the rest of the application — the salary engine, the template filler — can trust what it receives instead of defending against it.

The Field That Matters Most: Employee Group

Of every field the AI extracts, one carries outsized weight: Employee Group, which must resolve to exactly "BNP" or "MITS2" — not "bnp," not "Bnp Paribas," not "MITS 2." That single string decides which offer letter template gets selected for the entire letter set. Get it wrong and a BNP Paribas client employee receives a MITS2-branded offer letter, which is the kind of mistake that's obvious to a human in about two seconds and deeply embarrassing if it ships. The exact-case requirement isn't fussiness for its own sake — it's a guardrail placed exactly where a wrong answer would do the most damage.

The Second Call Is a Different Kind of Problem

Interestingly, the two AI calls in the pipeline aren't solving the same kind of problem at all. The first is extraction — finding facts that already exist in the text. The second is closer to judgment: reading roles-and-responsibilities notes and turning them into properly formatted letter prose, and deciding, letter by letter, whether the source document implies a Joining Bonus, a Conveyance Reimbursement, a Relocation Reimbursement, or Security Documents are needed for this specific candidate.

That second task is genuinely the harder one, because it's inferential rather than extractive. A document might mention relocation assistance in passing, in a sentence that isn't formatted as a clause, without ever using the word "reimbursement." Catching that correctly means the AI is doing something closer to what an experienced HR coordinator does when they read between the lines of a client email — which is exactly the skill this system was built to protect, by handling only the busywork around it and leaving the judgment calls with a real human review step downstream.

The Audit Trail That Makes All of This Trustworthy

Here's the detail that turns this from "a clever AI trick" into something an HR team can actually rely on: every single extraction gets written to firstCallResponse.json and saved right alongside the generated letters, in the same output folder, forever. If a letter is ever questioned — a client asks why a designation reads a certain way, a candidate flags a discrepancy — there's a complete, timestamped record of exactly what the AI believed it read from the source document, sitting right next to the document itself.

That's not a technical afterthought. That's the entire system earning the right to be trusted with something as sensitive as someone's employment paperwork. AI that can't show its work doesn't belong anywhere near a payslip, and MITS built the audit trail in from day one rather than bolting it on after the first awkward question.

Reading a document sounds like the easy part. It's actually where most of the real engineering effort went — not because the AI model is weak, but because human paperwork is wonderfully, chaotically inconsistent, and building something that reads it reliably means respecting that chaos instead of pretending it isn't there.

MITS AI Letter Writer · part 4 of 5Fourth in a five-part series. Next: what it takes to move a tool like this from "works on someone's laptop" to something an entire organization can depend on.