AI recruiting vendor due diligence: the security, data, and control questions buyers should ask.

Ask an artificial intelligence (AI) recruiting vendor a security question, and the two easiest answers it can give are a logo on a pricing page and a yes on a sales call. Neither one is a document. This AI recruiting vendor checklist is six questions I’d send to every vendor on a shortlist, alongside your security questionnaire, with the documents that answer each one. General security posture, such as System and Organization Controls (SOC) 2, role-based access, and consent flows, gets one link below.

The six fall into the title’s three groups. The security questions ask who processes your candidates’ data and how fast you’ll hear about a breach. The data questions ask whether the vendor trains models on your data and what the product learns from your team’s decisions, then how long it keeps recordings and notes and how deletion works. The control questions ask where a person can override each AI output and what evidence sits behind it.

My position: an answer counts only if it points to a document.

The AI recruiting vendor checklist, in one table.

Each of the six rows is a question to put to the vendor in writing, the documents that answer it, and the kind of answer that sounds like one and falls short. The first question comes in two parts.

The table leaves one thing out on purpose. General security posture, from SOC 2 to role-based access and consent flows, sits in a separate guide, the interview-first buying matrix for AI recruitment tools.

Does the vendor train on your data, and what does the product learn from your decisions?

Ask this first, and get a separate answer to each of its two parts, because a vendor can answer one part and sound as if it has answered both.

The first is about model training: does your candidates’ data, or a model provider’s use of it, train a model? The second is about the product: does it change how it behaves based on your team’s decisions, such as which applications a recruiter progresses and which ones they reject? A tool can do the second without the first, and a buyer can’t tell which from a sentence on a call.

Three documents answer the two halves between them:

• A contract clause that says whether your data trains any model, the vendor’s own or a provider’s.
• A published statement you can quote back to the vendor later.
• For a product that adapts to your team’s decisions, the product screen where that change shows up, and where a person accepts or declines it.

Keep the two halves apart in your notes on each vendor. It’s easy to treat a no-training answer as closing the whole question, but it answers only the first half. If the product adapts to your recruiters’ decisions, you still want to know where that adaptation is stored, whether it stays with your account, and who signs it off before it changes what the next recruiter sees.

Who are the sub-processors, and where does each one process data?

A call answers this question worst of the six, because the full answer is a list of companies, and a list is something to read rather than something to hear. The sub-processor list names the companies a vendor passes your data to so it can run the product, with each one’s purpose and location. For an AI recruiting tool, the entries to read closely are the model and transcription providers. A recording that one company transcribes and another company’s model summarizes has passed through two sub-processors before anyone reads the notes.

Location splits into two answers as well. Hosting is where the data is stored. Processing is where each provider on the list runs the transcription or the language model. A vendor can host in one region and use providers that process in others, and a hosting answer on its own won’t show it.

The list also changes over time, so the version you read during the trial may not be the one in force a year later. That makes it a dated document, and how the vendor tells customers about a change is part of the same written answer.

How fast will you hear about a breach?

A breach notice is useful as a deadline, and a spoken promise to tell you quickly has no deadline in it. The first thing to get is the number of hours, and the second is whether it’s written into the contract or the DPA as well as on a published page.

What the notice contains comes next, for example the scope of the incident, its impact, and the steps taken to fix it. So does its reach. An AI recruiting tool depends on model and transcription providers, and it’s worth asking whether an incident at one of them triggers the notice as well as one inside the vendor.

I wouldn’t tell you how many hours to accept. That depends on your own notification duties, which your privacy or legal team owns. Ask for the number in writing and read it against those duties.

Retention and deletion on demand.

Retention and deletion each need their own written evidence: a stated default for retention, and written confirmation that a deletion request was completed. For retention, ask how long recordings, transcripts, and notes are kept if no one changes the retention default, and whether it can be set to match your company’s policy. For deletion on demand, ask what a request covers, who can make one, including a request made on behalf of a candidate, and whether completion is confirmed in writing and how quickly.

The notes are where AI changes this question. When a product writes them from a recording, they’re a separate record. Ask whether a deletion request reaches AI-generated notes as well as the recording, and get the answer in the same document as the rest.

Where a person can override each AI output.

List every output the tool produces and ask, output by output, where a person can override it and what happens when no one acts. A fit rating on an application, a drafted scorecard, and a set of interview notes are three outputs with three different answers. The question to press is whether any output ever moves a candidate forward or out without a person taking the action.

A good answer points to the screen where a person takes each action and says plainly what happens if no one does. The strongest version is that nothing moves on its own: an application waits until someone progresses or rejects it, and a drafted scorecard stays a draft until the interviewer submits it.

What falls short is a general statement that humans stay involved, or an answer that covers who can override a rating but not what happens to the application if no one looks at it. That second gap hides whether a candidate can move without anyone deciding.

Under the AI hiring laws in New York City, Colorado, and the European Union, a person making the final call doesn’t, by itself, take a tool out of the laws’ scope: New York City and Colorado look at what the tool’s output does to the decision, and the European Union looks at what the system is for. So the override answer goes to your legal team as well.

This is Metaview’s guide, so here’s how Metaview answers the override question. In Metaview’s Application Review, which reads each application against the role’s ideal candidate profile and sorts it into a great, good, okay, or poor fit bucket, the recruiter makes every progress and reject decision. Application Review never auto-rejects.

Across the decisions captured on Metaview, the better the fit bucket, the more often a recruiter progressed the application. Of great-fit applications a recruiter progressed or rejected, 17.2% were progressed. The rate falls to 12.1% for good fit and 7.8% for okay fit, and of poor-fit ones, 5.6% were progressed, each on a recruiter’s call.

All four rates count only applications with a recorded recruiter decision, so they leave out everything still waiting. Recruiters rejected most applications in every bucket, great fit included, and still progressed some poor-fit ones. That’s recruiters acting against the buckets in both directions, and it’s the kind of evidence to ask every vendor for: how often a person progresses or rejects what the tool sorts into each category. The data records who acted, not how those candidates did later, so it can’t say whether the bucket or the recruiter was right. Interviews have their own outputs. The Notetaker, Metaview’s interview recorder, drafts a scorecard from the conversation, and the interviewer reviews it and submits it.

What evidence sits behind each score, rating, or flag?

Ask what a reviewer can open behind each output, and check the answer yourself during the trial. Evidence a reviewer can open is what makes an output quick to check, and I’d expect a check that takes as long as the original work to get skipped. Shahriar Tajbakhsh, Metaview’s co-founder and chief technology officer, put the cost plainly when writing about sourcing results:

A good answer puts the evidence beside the output, in the product, where the reviewer already works: the reasoning behind a rating, why a flag was raised and how serious the tool thinks it is, and the part of the interview a note came from.

The answers that fall short are a score with nothing behind it, evidence the reviewer has to request from the vendor, or a flag that moves an application before anyone has opened it. Ask how the vendor describes a flag, too. A reviewer who reads a flag as a verdict has stopped checking, so the answer to look for is that a flag starts a check rather than ending one.

Fraud flags, which mark an application that may come from a fake candidate, need the same evidence behind them, and this episode of Metaview’s 10x Recruiting podcast covers the problem behind them: host Nolan Church and Metaview co-founder Siadhal Magos talk through the rise of AI-powered fake candidates and what’s working when recruiting teams fight back.

Here’s how Metaview, the vendor behind this guide, answers the evidence question. Application Review shows the reasoning behind each fit bucket, and it also assesses every application for signs of identity deception and application automation. Each flagged application includes a risk level and a plain-language explanation. A fraud flag is a prompt to look closer, and a flag is not confirmed fraud. Across organizations using Application Review, 28.59% of the 905,562 applications assessed were flagged as medium or high risk by the fraud-detection model.

With that share of applications flagged, a reviewer can’t treat every flag as fraud, so the explanation beside it is what tells them where to look closer.

When an interview is recorded, the Notetaker captures every spoken word and transcribes it, so a reviewer can check a line in the notes against the transcript instead of against someone’s memory of the call.

Raines International, an executive search firm, is a Metaview customer whose interview notes are tied back to its evaluation criteria, the standard a reviewer checks an output against. From its case study: “Candidate interviews are being transcribed and structured according to scorecards which are tied back to evaluation criteria.” It also reports: “Consistency has also advanced. Every follow-up, scorecard and report looks and sounds the same.”

If your security questionnaire already asks about sub-processors, breach notice, and deletion.

Then keep it. This checklist doesn’t replace it, and I see no reason to send a vendor two documents that ask the same thing.

Half of the six are about something else: training and learning, override, and evidence. They exist because the product is AI, and they go to the vendor alongside the questionnaire. For the rest, the useful move is to add a clause to questions you already ask:

• Whether model and transcription providers appear on the sub-processor list.
• Whether a breach at a model provider triggers the notice.
• Whether deletion reaches AI-generated notes.

Your security team knows its questionnaire better than any vendor’s blog does, and the three additions are small enough to fit into it without a rewrite.

What Metaview publishes on retention, deletion, and security.

The same test applies to Metaview, so here’s what its public pages say on those questions, each attributed to the page it comes from. Put the training question to Metaview in writing, as you would to every vendor on your list.

On retention, Metaview’s integrations page says the default retention period is two years and that Metaview will match your company’s policy on request. On deletion, the integrations page says: “You own your interview data and have full control to delete any recordings at any time.” That covers recordings, so ask in writing whether deletion also reaches the AI-generated notes, as you would with any vendor.

Override and evidence are covered in the two sections above. In Application Review, Metaview never auto-rejects, so no application moves out without a recruiter’s action. Last, the integrations page covers security in one line, naming SOC 2, the General Data Protection Regulation (GDPR), and the California Consumer Privacy Act (CCPA), and your security questionnaire should test that line the way it would any vendor’s: “Metaview is SOC 2 Type II certified and fully compliant with GDPR and CCPA.”

A vendor that can only answer out loud has not answered.