Ask an engine for the best applicant tracking system and you get the answer you would expect. A few familiar names, a clause each, the usual shape. Now ask it the question an actual head of talent asks, the one with the clause on the end: the best applicant tracking system that will hold up when legal reviews it. Watch how much the answer changes, and watch which names quietly stop appearing.
That second query is the real one in this category, and it behaves differently from anything in developer tools or security software. HR and recruiting vendors keep running an AI search playbook built for categories where the buyer is asking what works. Their buyer is asking something else first.
Two things make this category different
The first is that the question arrives with a constraint attached. Buying software that touches hiring means buying something that can be challenged later, by a rejected candidate, by a regulator, by your own legal team. New York City requires bias audits for automated hiring tools. The EU treats employment and hiring uses of AI as a high-risk category with obligations attached. Whatever the specifics where your buyer sits, the effect on the query is the same: the question stops being purely about capability and starts carrying a clause about defensibility. Engines answer the whole question, clause included. A vendor that reads as capable but not defensible loses the qualified query even when it would win the generic one.
The second is stranger, and it catches AI-native vendors hardest. In most categories, having AI in your product is a selling point the engine can repeat approvingly. In hiring, your AI is also the thing the buyer has been warned about. Your prospect has read the stories about screening models filtering out good candidates on patterns nobody intended. So the same feature is simultaneously your differentiator and your risk, and when an engine assembles an answer about you it’s pulling from sources that argue both sides. The vendors who win here aren’t the ones who talk about their AI most confidently. They’re the ones whose AI is described somewhere credible as explainable, auditable, and overridable by a human.
Put those together and you get the category’s actual rule. The engine isn’t ranking hiring software on features. It’s ranking it on whether the sources it reads make the product look survivable under scrutiny.
Where that assessment gets made, and it isn’t on your site
Here’s the part that stings. Every vendor in this category already says the right things on their own site. There’s a trust page. There’s a paragraph about responsible AI. There’s a compliance section with the logos. It’s table stakes, it’s identical across every competitor, and an engine discounts a vendor’s self-assessment of its own risk exactly the way you would.
What actually moves the answer is the same claim made by someone who isn’t you. An analyst note that describes how your model is audited. A published bias audit summary that exists as a real, findable document rather than a sentence claiming one was done. A practitioner writing up an implementation and mentioning that legal cleared it without a fight. A review from a buyer in a regulated industry. A comparison page that has a compliance row and puts a real answer in your cell instead of a checkmark.
Those are the sources an engine leans on when a query carries a legal clause, because they’re the only ones that constitute evidence rather than assertion. If your defensibility story lives entirely on your own domain, then for the purposes of the query that matters, it doesn’t exist.
What I got wrong
The first time I worked a category where the buyer’s question had a legal clause in it, I treated the clause as noise. I read it as anxious language wrapped around a normal software decision, and I optimized for the normal software decision underneath: the capability comparison, the use case fit, the sources that describe what the product does well.
It moved the generic query and did nothing for the one that mattered. The engine kept handing the constrained version of the question to a competitor with a thinner feature set and a much thicker paper trail. I had assumed defensibility was a tiebreaker applied after capability. In that category it was the filter applied before it.
What changed the answer was unglamorous and slow. We stopped producing capability content and went and made the risk evidence exist outside the vendor’s own site, in forms a third party had put their name on. No new features shipped. The product had always been defensible. It had just never been described that way anywhere an engine would count.
How to actually do it in this category
Start by running the constrained queries, not the clean ones. Not “best recruiting software” but the versions with the clause: compliant with hiring regulations, safe to use for screening, defensible if a candidate challenges a decision, approved by legal. Note who the engine names and, more importantly, which source it leans on when it answers. That source is your target.
Then make the evidence liftable. If you have had a bias audit, publish something a third party can point to and quote, dated and specific, rather than a claim that an audit happened. If a customer in a regulated industry got you through their legal review, that story is worth more than a feature launch, and it needs to live somewhere other than your own case studies page. If your model can be explained and overridden, get that described in a comparison or a review where the person writing it isn’t you.
Be concrete about the human in the loop. The engine is reconciling contradictory sources about AI in hiring, and the thing that reliably resolves the contradiction in your favor is a clear, quotable description of where a person makes the call and what the software is and isn’t allowed to decide alone. Vagueness here reads as risk, and risk is exactly what the constrained query is filtering on.
And concede something. The vendors that read as trustworthy in this category are the ones whose sources say plainly what the product doesn’t do. Claiming to be safe at everything reads like every other vendor claiming to be safe at everything, and an engine discounts all of it equally.
Do that and you stop losing the only query with budget behind it to a competitor with a worse product and a better paper trail. In a category where the buyer’s real question has a clause on the end, the win goes to whoever made the answer to that clause easy to find and easy to quote.
If you want to find the constrained queries where your category is being decided, and build the outside evidence that answers them, that’s the work we do and the method we use.