Is it safe to let AI read candidate CVs?
It can be, and whether it is depends on four things you can ask any vendor about in ten minutes: where the CV goes, whether it is used to train anything, what the software is allowed to decide on its own, and what it does when it is not sure.
A CV is one of the more sensitive documents an agency handles. It has a name, a home address, a phone number, an employment history, often a date of birth and sometimes far more than that, because candidates put things in CVs that nobody asked for. Your clients trust you with it, the candidate trusts you with it, and in most of the world you hold it under rules that give the candidate rights over it.
So the worry is reasonable. It is also worth separating into its parts, because "is AI safe" is four different questions with four different answers, and only one of them is genuinely difficult.
Where does the CV actually go when AI reads it?
The first question to ask is which companies the document passes through, because that list is the whole of your data protection exposure. When a CRM parses a CV, the file or its text is usually sent to a model provider, processed, and a structured answer comes back. Whether that provider is your vendor, a large model company, or several depends entirely on how the product was built.
Ask for the list by name and ask where each one processes the data. You want to know the companies, the regions, and whether the arrangement is covered by the contract you are about to sign or by a separate set of terms you have never read. A vendor who cannot answer this quickly has either not thought about it or does not want to say, and both are worth knowing.
Then ask the same question about every other AI feature, because the answer often differs. A product might process CVs in one place, transcribe calls somewhere else, and send email text to a third. Your clients' security questionnaires will eventually ask you this, and you will be answering on behalf of a stack you did not choose.
Will candidate data be used to train someone else's model?
This is the question with a clean answer, and you should insist on getting it in writing rather than in a demo. Serious providers of models for business use offer terms under which customer data is not used to train their models, and serious software vendors pass that through to you in the contract.
The reason to get it in writing is that the default in consumer products is often the opposite. A consultant who pastes a CV into a free chatbot on their own laptop is operating under different terms from your CRM, and that is the actual leak in most agencies. The software you buy is usually the controlled part. The tab a consultant opened themselves is not.
Which gives you a practical piece of policy work that costs nothing: tell your consultants where AI is allowed to happen, and make the sanctioned route better than the unsanctioned one. People paste CVs into chatbots because it saves them twenty minutes, and the only durable fix is that your own product saves them twenty five.
What is the software allowed to decide about a candidate?
This is the part that carries real risk, and it has almost nothing to do with where the data is stored. Reading a CV is a low risk activity. Deciding on the basis of that CV that a candidate is not suitable, and acting on the decision without a person involved, is a different thing entirely, and in most jurisdictions people have rights about decisions made about them by software alone.
Take your own legal advice on where the line sits for you. What you can do without a lawyer is find out what the product is capable of doing unsupervised, because that is a question of fact and the vendor knows the answer. Ask which actions the AI can take without a human confirming: can it reject, can it email a candidate, can it change a stage in the pipeline, can it write to a field that someone will later rely on.
Then ask what record is kept. If the software scored a candidate, you want to know that it scored them, when, on what, and what the consultant did next. A candidate who asks why they were not put forward is a question you can answer well or badly, and the difference is whether the system wrote down its reasoning at the time.
The other reason to care about this is bias, which is not a new problem introduced by AI but is very easily scaled by it. Software trained on patterns will reproduce patterns, including ones you would not defend if they were written down as a rule. Keeping a person on the decision is the practical control that most agencies can actually implement.
What happens when the AI is not sure?
The safest products are the ones that are allowed to be unsure, and this is the question that separates them fastest. A model asked to extract a field will produce a value whether or not the information was there. The output looks identical either way, which is what makes it dangerous.
Put concretely, a CV with an employer name in a footer and dates written in three different formats will yield an employment history that looks perfectly reasonable and may have a year wrong. Nothing on the record says which parts were read and which were inferred. A year later somebody builds a shortlist on it.
Ours reports how sure it is on every judgement and hands anything below three quarters back to a recruiter, so the uncertain cases arrive as work rather than as facts. That is the arrangement to look for whatever product you buy. On a demo, hand them a genuinely awkward document and watch what appears in the fields it could not read.
| Question for the vendor | A good answer | A warning sign |
|---|---|---|
| Which companies process a CV, and where | A named list, by region, covered in the contract | Vague reassurance, or a different answer per feature |
| Is our data used to train models | No, and it is written into the terms | "We would never" with nothing in writing |
| What can the AI do without a human | A short, specific list of actions | An answer that describes intentions rather than permissions |
| What is recorded when AI judges a candidate | The judgement, the time, the basis, and what the recruiter did | No audit trail, or one you cannot read |
| What happens when it is unsure | A confidence score and a threshold under which a person decides | Every field always filled |
| How is retention and deletion handled | Deleting the record removes the derived data too | Copies in a system the vendor does not control |
What should you tell candidates about AI in your process?
Tell them plainly that you use software to read and organise applications, and tell them where a person makes the decisions. Candidates are far less troubled by AI reading a CV than by the suspicion that they were filtered out by a machine and nobody will admit it.
Your privacy notice is the place for the formal version, and your own adviser should write it. The version that matters in practice is what a consultant says on the phone when asked. If your people can explain in two sentences what the software does and where a human takes over, you are in a far better position than an agency whose consultants do not know.
Be similarly clear internally. Consultants who do not know what the AI is allowed to do will either distrust everything it produces or trust all of it, and both are expensive.
So is it safe
Letting AI read CVs is about as safe as the arrangements around it, which is an unsatisfying answer and a true one. The reading itself is routine. The risks live in where the document travels, what the software is permitted to decide alone, and whether it is honest about the cases it did not understand.
My own view from building this is that the confidence question is the one to lead with, because everything else is a contract and that one is architecture. A vendor can sign whatever data processing terms you put in front of them by Friday. Building a product where every judgement carries a score, where there is a line below which nothing gets written, and where the uncertain cases go back to a person, takes considerably longer and cannot be added to a sales deck the week you ask for it.
Siva is an engineer at Recruitly.



