HR, recruiting & people operations
Guardrails for AI that reads CVs and employee records
HR teams and recruiting software putting CVs and employee records through a model.
The CV that went out in full
A screening assistant sends a candidate’s CV – name, home address, phone number, date of birth – to a model provider to be summarised. The summary comes back neat and readable, and states the candidate holds a certification they never listed. A recruiter forwards it to the hiring manager, who reads it as fact.
in/guard/out replaces personal details with placeholders before the CV leaves and restores them only inside your own app, so the provider never sees them. Claims the CV does not support are flagged before a recruiter reads them as fact.
A CV is a dense block of personal data – name, address, phone, dates, sometimes health or immigration detail – and screening AI sends the whole thing to a model provider by default. Employee records are worse. The exposure is the input, before any answer is generated.
in/guard/out screens those values into reversible placeholders before the request leaves your infrastructure, and puts the real ones back only in the response your own application receives. The provider sees a readable document with the identifying parts removed; your logs store the screened form by default.
The second failure is quieter. A summary that adds a qualification, shifts an employment date, or turns a claim into a certainty is indistinguishable from a good summary to the person reading it. Grounding matches figures and dates back to the document that was actually supplied, and a fact-check pass flags statements the CV does not support – so the recruiter sees the flag, not just the prose.
What can go wrong – and what in/guard/out does about it
Each problem teams like this run into, with its answer. In Block mode a failed check stops the request; in Fix & log it is repaired where that’s safe and recorded otherwise. Where something isn’t ours to control, we say so.
Candidate and employee data sent to the model provider
Personal data it detects is masked before the request leaves, and restored in your app.
Invented qualifications, dates or job titles in a summary
Dates and figures are matched to the source document; an optional fact-check judge flags other claims it can’t support.
Personal data leaving through tool calls or outbound email
Data in/guard/out masked is blocked from leaving in tool arguments, including email sends.
No record of what the AI was asked, or what it answered
Every request logs which checks ran and what they found.
Whether a hiring decision is fair
Outside in/guard/out in/guard/out checks how the AI handles data and facts, not the decision itself – bias review and hiring policy stay with your team.
The qualification nobody claimed
A screening summary states the candidate is “AWS certified since 2021.” The CV mentions AWS experience and no certification. Grounding finds no source for the date; the fact-check pass flags the claim as unsupported by the material. In fix mode the finding is attached to the exact sentence; in prevent mode the summary does not ship. The candidate’s name and address never reached the provider either way.
Frequently asked questions
Does candidate data reach the model provider?
No. Names, addresses, phone numbers, and other identifiers are replaced with placeholders before the request leaves, and restored only in the response your application receives. Taint tracking also blocks screened values from leaving through tool arguments or an email send.
How would we catch an invented qualification?
Claims in the summary are matched against the document supplied. Figures and dates are checked deterministically; broader statements go to a fact-check pass that flags what the source cannot support – attached to the exact sentence, so a reviewer can see it.
Does this audit our hiring model for bias?
No – and nothing here should be read as doing so. Bias auditing is a separate discipline with its own methods and, in some US jurisdictions, its own legal requirements. in/guard/out covers data exposure, unsupported claims, and an audit trail of what ran; it does not assess fairness of outcomes.
What do we have in writing afterwards?
Every request records which checks ran, what they found, and what was done about it. Transcripts are stored in their screened form by default, with raw storage available as a deliberate, audited opt-in.
Other clients
See it on your own traffic.
We’re running a limited demo – sign up and we’ll get you in as soon as we can.