Questions you should not ask your interview data: a query policy for recruiting AI assistants.

A recruiter on your team can open any interview record you’ve granted them. That was a permissions decision, and you made it months ago. Your team probably hasn’t decided what it’s allowed to ask the artificial intelligence (AI) assistant that answers questions across your recorded interviews. An interview transcript search policy is where that decision gets made.

Your team can put a question in plain language to the conversations it owns and get an answer back in a sentence. Your access model still says yes or no to a record. It says nothing about whether “which candidates brought up childcare” is a fair question to ask of two hundred records at once.

My guess is that most teams find this gap through a curious colleague rather than a careless one. The question that gets you in trouble is typed by somebody with every right to read each record it touches, which is why an access model can’t catch it. The trouble is the answer: a written record of your team considering a protected subject, such as health or pregnancy, across a population.

So here’s the document I’d write before turning natural-language search on for a hiring team: a written query policy with three tiers and real example questions, covering what anyone can ask, what needs a sign-off, and what’s never asked at all. Below is how I’d build it, and where I expect a team to push back.

Why an interview transcript search policy is not a permissions setting.

Access control is a question about documents. Can this person open this interview? Your applicant tracking system (ATS) has answered that for years, and the answer travels one record at a time.

A natural-language query asks about patterns instead. Ask what two hundred engineering candidates said about compensation and you get back something no single interview contains. The recruiter was entitled to read all two hundred transcripts by hand. No one ever did, so the entitlement stayed theoretical. It stops being theoretical once anyone can ask the question.

These are two different controls: one governs reach, and the other governs purpose, which is the part your permissions model was never built to read.

Where your team already has an AI policy for recruiting, the query policy sits underneath it as the more specific rule for questions asked across interview records.

What a question can reach once the archive is years deep.

Before you can rule a question in or out, be honest about what sits in the record. A transcript is a written record of a human conversation, and human conversations wander. Unprompted, candidates mention things like:

• a new baby, or a partner’s job in another city
• a visa timeline
• a health scare, theirs or a parent’s
• a church group, a union role, or a political campaign they volunteered on

None of it was asked for. All of it is in there, searchable, for as long as you keep it. If your team has recorded interviews for three years, a question about “our candidates” reaches all three years unless you say otherwise. Retention sets the outer limit of every question your team can ask.

None of that is a reason to stop recording. Metaview captures every spoken word of an interview, which gives a debrief a record to check instead of memory and half-written notes. That same record is why the questions your team asks of it need rules. The company’s chief executive goes further:

Tier one: questions any recruiter can ask without checking.

Tier one should cover the working majority, and a policy that keeps this tier small is likely to be ignored within a week. The test I’d use is whether the answer would be at home in a scorecard, a market brief, or an intake document, and whether you’d be comfortable with the candidate reading it.

For a recruiter:

• Which compensation range came up across the last twenty backend screens?
• Which competitors do candidates name when they describe their current stack?
• How did candidates describe the take-home exercise?

For a hiring manager:

• Which competencies did the panel probe for this role?
• Where did two interviewers reach opposite conclusions?

For a talent acquisition (TA) leader:

• Which stages generate the most candidate questions we can’t answer?
• Which stated criteria does the panel assess consistently for this role?

Each of those turns on the role, the market, or the hiring process rather than on one colleague’s performance, which is where tier two starts. Getting the role’s criteria straight at the start makes these questions easy to answer, and that’s the whole argument for a properly run intake call.

Catawiki’s recruiting team is the clearest published example I have of tier one doing real work. Its Amsterdam recruiters were hiring into Lisbon without knowing the local market, so they put the question to their own conversations. Lead tech recruiter Justin den Hamer described it plainly: “If we spoke to 20 backend engineers, we could just ask the AI assistant to build a report based on the average salary expectations discussed in those calls.” The alternative was the one his team had been living with: “We had a manual process going through 20 candidate scorecards and extracting that data to an Excel sheet.” His verdict on the change, in Catawiki’s case study, is the line I’d put in front of any team debating whether this is worth governing: “Now we have a report in two clicks. That’s a completely different story.”

Salary expectations discussed in a screen and market norms for a city are job-related, which is why they sit in tier one. Reasons for rejection belong there too when they’re measured against the role’s stated criteria. It’s also why the tier needs writing down, because at two clicks the next question gets asked before anyone has weighed it.

Catawiki also appears in a short customer film on Metaview’s channel. It covers the step that makes a query possible at all: what having every interview captured changed for the team’s interviewers and for its hiring decisions.

Tier two: questions that need a sign-off first.

Tier two exists because some questions are legitimate and consequential at the same time. They aren’t banned, only slow on purpose. Three kinds belong here.

1. Questions about a colleague. How does this interviewer rate candidates compared with the rest of the panel? Who talks most in our debriefs? These are among the most useful questions in tier two: comparing how interviewers rate the same candidates is one of the better tools you have for reducing subjectivity across a panel. It’s still performance data about an employee, gathered through a tool they were told was for hiring, and it needs your people team before it needs an answer.
2. Questions whose answer leaves the team. A report built for a board pack or an external audit stops being an internal working note the moment it’s sent.
3. Questions that cut a population thin. “What did candidates say about relocation” is tier one. “What did the three candidates from that one employer say about relocation” needs a sign-off, because with three people, the pattern is three identifiable people’s answers.

Tier two only works with one named owner who can approve or reject a question inside a day. A sign-off step that takes a week is a step your team will route around, and then you have a policy that exists and a practice that ignores it.

Tier three: subjects that stay out of the search box.

Tier three is short, and it’s written as a list of subjects rather than a list of phrasings. No one asks your interview archive about a candidate’s:

• race, color, ethnic origin, or national origin
• religion or philosophical belief
• political opinion, or trade union membership
• health or disability
• pregnancy or family plans
• sex, sexual orientation, or sex life
• genetic or biometric information
• age

That list isn’t my invention, though drawing the line at the search box is my call. It draws on five laws:

• Article 9(1) of the General Data Protection Regulation (GDPR) treats racial or ethnic origin; political opinions; religious or philosophical beliefs; trade union membership; genetic data; biometric data used to identify someone; health; sex life; and sexual orientation as special categories, and prohibits processing them unless an exception in Article 9(2) applies.
• In the United States, Title VII (the employment-discrimination part of the Civil Rights Act) covers race, color, religion, sex, and national origin, and it counts discrimination because of pregnancy, childbirth, or related medical conditions as discrimination because of sex.
• The Americans with Disabilities Act (ADA) bars disability inquiries before an offer, while allowing questions about a person’s ability to do the job.
• The Genetic Information Nondiscrimination Act (GINA) bars requesting genetic information, and it counts family medical history as genetic information.
• The Age Discrimination in Employment Act (ADEA) covers people aged 40 and over.

Article 5(1)(b) of the GDPR is the rule that reaches every query, whatever it asks about: personal data is collected for specified, explicit, and legitimate purposes, and not processed further in a way incompatible with them. Querying is processing, so the purpose you wrote down when you started recording is the purpose your questions have to stay inside.

Title VII, the ADA, and the ADEA prohibit discrimination in how you treat applicants and employees, and the ADA also limits what you ask before an offer. Those prohibitions don’t mention searching records you already hold, so read the three laws as the authoritative account of which subjects are protected rather than as a ban on the search itself. The exposure a query creates is different in kind: a written record of your team considering a protected subject across a population. GINA reaches further: its regulations count an internet search on a person that’s likely to turn up genetic information as requesting it, and the same goes for searching someone’s personal effects to find it.

Read together, those laws point at one rule you can apply without reaching for the statute each time: ask about the job, never about who the candidate is. Whether a candidate can meet the travel requirement of a role is a question about the job. Why they might struggle to travel is a question about who they are, and it’s the kind that can hand you a protected answer in writing.

Two practical notes, because tier three is where policies get written badly. First, candidates volunteer this information unprompted. A rule claiming “this data is not in our records” is false and will be found out; the rule you want says the records are not queried on these subjects. Second, a subject list survives rewording, where a banned-phrase list doesn’t. Anything you’re unsure about goes to your people team or legal counsel first, and nothing in this article is legal advice.

How to make the policy arrive before the question does.

A policy only works if people know it before they type the question. Five things make the difference between a document and a practice.

1. Write it on a single page. Give tiers one and two five example questions each, in the words your team would use, and make tier three a subject list. If it runs to four pages, the examples are doing too little and the prose is doing too much.
2. Put it where the query happens. The policy belongs in the onboarding for anyone given search access, and in the same place your team goes to learn the tool, rather than filed in a compliance folder they visit once a year.
3. Save the good questions. A tier one question worth asking twice becomes a standing report with a named owner, who reviews the wording once before it’s saved, so the reviewed version is the one people reuse.

4. Review it when the reach changes. Extend access to a new group, add a data source, or lengthen retention, and the same three tiers now cover a bigger surface.
5. Read the saved questions every quarter. None of the three tiers catches a question whose purpose drifts, because it’s a tier one question on the day it’s written. The only thing that catches it is someone rereading the standing reports and asking what each one is now being used for. Put a date on that review, or it won’t happen.

In Metaview’s 2026 survey of 505 recruiting leaders and hiring managers, 79% took a positive view of where AI is heading in hiring. That’s a view of AI in hiring generally, not a count of teams searching their interview archives. If your team shares that positive view, write the policy now: it’s far easier to write before somebody has a question they want answered today.

Is this too much governance for a search box?

Here’s the place I expect a team to push back on me. The obvious objection is that this is a lot of governance for a search box, and that a sensible recruiter needs no document to know not to ask about somebody’s pregnancy. I agree about the sensible recruiter. This policy is for the week a new coordinator gets access, a hiring manager asks them something reasonable-sounding under pressure, and the answer lands in a Slack thread that outlives the search. The policy earns its keep in the ambiguous middle rather than on the obvious cases. Plain-language reporting makes a question across the whole archive cheap to ask. Cheap questions are why the policy has to exist before the archive is queryable, rather than after somebody asks the wrong one.