Almost every recruitment platform now has an AI feature on its roadmap, and most agencies and in-house teams have at least been asked about it. CV screening, candidate matching, drafting job adverts and summarising interview notes are all on offer, often as a button in software the team already uses.
Some of these features save real time. Others create more work than they remove, because someone still has to check every output. The difference is rarely the technology itself. It usually comes down to whether anyone asked a few plain questions before the feature went live.
Start with the problem, not the feature
A recruiter who spends hours each week rewriting job adverts has a clear, contained problem, and a language model is well suited to a first draft that a person then edits. A team that wants software to pick the best candidate has a much harder problem, and one where a wrong answer has consequences for a real person.
It helps to write down what a good result looks like before anything is switched on. If the aim is to shorten time spent on first-round admin, measure that. If nobody can say what would count as success, the feature will be judged on impressions, and it will be difficult to remove once people are used to it.
There is also a fair chance the answer is not AI at all. Duplicate records, poor search filters and manual status updates are common complaints in recruitment systems, and ordinary software fixes them more reliably and more cheaply than a model will.
Know where the candidate data goes
CVs are full of personal data, and a recruiter's database holds years of it. Before any of that is sent to an outside AI service, a team should know exactly which provider receives it, where it is stored, how long it is kept and whether it can be used to train that provider's models.
These are ordinary questions for a supplier, and a good one will answer them in writing. It is also worth bringing in whoever is responsible for data protection early, rather than presenting them with a finished feature. Candidates may also want to know when automated tools played a part in a decision about them, so the team should agree what it will say if asked.
Decide who checks the output
Language models produce confident answers whether or not they are right. A summary of an interview can leave out the one point that mattered, and a screening score can look precise while resting on very little.
So the useful question is not whether the model is accurate in general, but who reviews its work and how they catch a mistake. Anything that influences who gets an interview deserves a person making the decision, with enough time to disagree with the software. Run a sample of past roles through the tool and compare the results with what your consultants actually did. Look closely at who it ranks lower, because bias in hiring data has a way of being repeated at scale.
Keep a record of what the tool recommended and what the consultant decided. It gives the team evidence of whether the feature is helping, and an answer if a candidate or client later asks how a decision was made.
Choose between buying, integrating and building
Once a use case holds up, the next decision is how to deliver it. Many teams will be best served by the features already inside their applicant tracking system. Others connect an existing model to their own data through a developer, which gives more control without the cost of training anything.
Building a custom model is rarely justified for a recruitment business, and the language around these options can blur together in sales conversations. Before signing anything, make sure everyone understands how integrating an AI model differs from building one, because the two carry very different budgets, timelines and risks. Whichever route a team takes, ask for a small trial on real roles first, and ask who owns the prompts, the data connections and the results if the supplier relationship ends.
Plan for what changes after launch
AI features do not stay still. Providers retire model versions and change their pricing, and an update can alter how a feature behaves with no change on your side. Costs usually rise with usage too, so a pilot that looks cheap with five consultants may look different across the whole business.
Ask who monitors quality after launch, who is told when a provider changes something, and how the team can switch the feature off if it starts causing problems. A clear exit matters as much as a clear start.
None of this is an argument against using AI in recruitment. Teams that ask these questions early tend to end up with fewer features, chosen more carefully, that people actually trust and use.
