Data Standards to Check with hunel Before AI Agents Join Hiring

Plenty of large enterprises adopt an AI recruiting agent and then find the same candidate recommended twice, or matching thrown off by job titles each affiliate names differently. Unlike a person, an AI agent does not look at odd data and stop to judge that something here is wrong. It learns the data as it stands and judges on that basis. The recruiting industry has consistently pointed out that a considerable share of the candidate records accumulated in an ATS are duplicates. That is why the data has to be checked before an AI agent is attached.

Section 1. Why the data has to come first

An AI agent autonomously writes job postings, matches candidates, and generates interview questions. But when the data feeding those judgments differs from affiliate to affiliate, the agent does not filter the errors out on its own. It propagates them as they are. Layering AI on top of unmaintained data is the same as automating the problem. In groups with many affiliates especially, this spreads not to one entity but across the entire group's recruiting data. A human recruiter senses a duplicate on instinct, thinking they have seen this candidate somewhere before, but AI treats the same person as two different people unless the data marks it explicitly. If a candidate applied to affiliate A early in the year and applied again to affiliate B in the second half, and the two application records are not linked, AI judges them as someone it is seeing for the first time, with no reference at all to their prior application history or assessment results. The problem is that errors like this do not stop at one instance. Because an AI agent learns the data the same way in every hiring round, a criterion distorted once keeps being applied to the next hire and the one after that. The point at which a recruiter notices the problem is usually after a complaint arrives from a candidate or a hiring department, and by then several rounds of hiring results have already been affected. Data preparation is therefore not a follow-up task to handle after AI adoption. It is a precondition that has to be finished before AI is attached. Take a group where five affiliates hire at the same time during peak season. It is common for each entity to use a different ATS, or to use the same ATS with different input rules. Attach an AI agent as is in that state, and the agent treats the five entities' data as five independent sets, so the duplication and matching errors described above occur simultaneously across as many entities as there are.

Section 2. Four data standards to check

What matters is checking them in order without skipping any. The table below sets out why each standard matters and what to confirm.

The order carries meaning too. Standardizing fields while the candidate identifier is still unresolved pulls duplicate records into the standardization work as well, doubling the workload. Keep to the order: clean the identifier, standardize the fields, build the log system, then limit the scope of application.

What happens when the order is skipped

Skip the four standards and apply the agent group-wide at once, and AI trained on affiliate A's criteria misjudges affiliate B's candidates, at group scale. By the time the problem is found, several entities' hiring processes have already been affected, and reversing it takes more time than the adoption did. That is why the order of verifying in one entity and one job family first, then widening the scope, has to be kept. Many organizations try to run the pilot and the group-wide rollout at the same time during peak hiring season, but without a long enough verification period the next hiring round starts before the errors are even found, and the problem can repeat twice or three times. Situations like this are not easy to unwind either. Tracing which parts of interviews and assessments already completed came from distorted data means recruiters have to go back through individual cases one by one. Applying it group-wide without verification looks attractive because adoption is fast, but once the time spent reversing the errors is added in, the overall schedule often ends up longer.

How to map job titles that differ by entity

The place standardization of affiliate recruiting data fields most often stalls is job titles. When work one entity calls "sales planning" another calls "business strategy," AI reads them as entirely different roles. In cases like this, rather than unifying the titles themselves, the practical approach is to build shared group job codes based on what the role actually does, and map each entity's existing title to that code. The names each entity has been using stay as they are, while the database links them under a single standard. This mapping work itself belongs to HR's job architecture work or to consulting. It is not something hunel performs automatically. When designing shared group job codes, similarity should be judged on the actual responsibilities and required capabilities in the job description, not on the job title. Whether "sales planning" and "business strategy" really cover similar work, or only differ in name, can be confirmed only by comparing each entity's job descriptions. Rather than mapping every job family at once, the practical approach is to map the core families with the highest hiring frequency first and widen the scope from there.

Section 3. Getting ready to run: the pilot and the record of judgment

How to design the pilot

Limiting the scope of application does not mean approaching it as vaguely as trying it small for now. That does not verify anything properly. Three things have to be set before designing a pilot. First, the comparison baseline. Before the pilot starts, measure baseline figures such as duplication rate, processing time, and screening pass rate from the existing recruiting data of the entity and job family in question. Without baseline figures there is no basis for judging what improved after AI came in and what got worse. Without them, all that remains once the pilot ends is an impression that things seem to have improved. Second, the duration. Set an observation period of roughly two to four weeks, and check matching accuracy, duplication rate, and any candidate complaints daily during that period. Third, the conditions for expansion. Extend to the next entity only when the pilot entity and job family reach the target figures, and where they fall short, identify the cause first. A pilot started without these three is no different from attaching it and dealing with problems as they come. The target figures should be agreed with the responsible executive from the start, so that there is no fresh argument about whether to expand once the pilot ends. With these three criteria in place, the decision to expand to the next entity after the pilot rests on figures rather than on sentiment. Conversely, if any one of baseline, duration, or expansion conditions is missing, the same pilot results often end with one side pushing to continue adoption and the other arguing to stop, each citing different grounds.

What the record of judgment has to contain

The third standard, the record of the basis for judgment, sounds abstract, but the items to keep are concrete. For each candidate: the score AI assigned, the factors that most influenced that score (years of experience, certifications held, particular keywords and so on), whether the recruiter accepted the score as given or revised it, and if revised, the reason. Once these four accumulate, they become the minimum basis for checking whether candidates from a particular group keep receiving low scores. If the log holds only the result, such as "score: 82," no one can explain why that result came out. Without these records accumulating, there is no way to confirm a pattern where candidates in a certain job family or a certain experience band keep being rated low. Recording all four for every case may feel burdensome to a recruiter, but compared with the time it takes to trace a cause backward after a problem occurs, it is a far smaller cost.

Section 4. Starting data preparation with hunel

hunel's recruiting management module standardizes each affiliate's recruiting site, online interview, application, and assessment data on shared group criteria. Once HR maps job titles and assessment items that ran differently by entity to shared group codes in the way described above, affiliate recruiters can keep entering data the way they always have, while at group level it aggregates against a single standard in hunel. Connecting elizax's Talent Acquisition Agent to recruiting data standardized this way makes it possible to compare job requirements against candidate resumes and receive recommendations of suitable talent, and to check quickly whether a candidate has applied across affiliates. Because hunel handles data standardization and elizax performs judgment and recommendation on top of it, the AI agent works in an environment where it can judge against consistent criteria across the whole hiring process. What to check before attaching AI is not the AI's performance but the state of the data it will reference. The difference between an organization that rushes AI adoption without preparing its data and one that keeps to the order and verifies step by step shows in the very first hiring season after adoption. The executive dashboard (EIS) reflects that standardization just as plainly. Being able to view headcount and labor cost trends by affiliate on a single screen comes down to data being organized on group standards day to day, and preparing recruiting data on the same principle greatly reduces the time it later takes to connect workforce data as a whole. The single candidate identifier issue covered in Section 2 is resolved on the same principle. When application history across affiliates is stored separately in each system, recruiters have to cross-check duplicate applications one by one, whereas in hunel affiliate recruiting data is linked under a single standard, so that check happens directly in the system. The record of the basis for judgment covered in Section 3 also carries meaning only on top of this standardized data. If data sits scattered across affiliates, logs accumulate separately by entity, so confirming a group-level pattern still requires gathering the scattered logs back together.