How HR Tech Teams Build LLM Apps in 2026

The HR AI category went through a structural shift in the first four months of 2026. Mercor reached $10 billion valuation matching domain experts to AI training contracts at OpenAI, Anthropic, and Meta. The Eightfold FCRA class action filed January 20 reframed AI recruiting tools as potential consumer reporting agencies, threatening statutory damages of $100 to $1,000 per violation against a database the complaint describes as covering more than a billion profiles. Mobley v. Workday, certified as a national collective in May 2025, kept moving through discovery with an opt-in window that closed March 7, 2026, potentially scaling to "hundreds of millions" of class members. The New York State Comptroller's December 2025 audit of NYC Local Law 144 enforcement signaled that bias audit compliance is moving from posture to procurement requirement.

For engineers building AI hiring tools, the implications are concrete. Architectures that worked for the prototype phase fail enterprise security review and regulatory scrutiny. Vendors that built audit trails, demographic isolation, and continuous bias monitoring into the foundation get through procurement faster and survive litigation more cleanly. Vendors that bolted on compliance after the fact spend the next year in remediation that costs more than building it correctly the first time.

This post is the engineering view of the HR AI stack in 2026. It covers the five architectural patterns serious products converge on, the regulatory landscape that shapes them, and where the engineering discipline breaks down.

The market in one paragraph

By mid-2026, the HR AI market has split into five recognizable shapes. Sourcing and screening platforms like Eightfold, Paradox, hireEZ, and Findem score and rank candidates against open roles. AI talent marketplaces like Mercor connect specialized contractors with project-based work, increasingly for AI training. Assessment and skills evaluation tools like Maki People, Pymetrics, and HireVue replace or augment traditional assessments. Workforce intelligence platforms like Eightfold's enterprise tier and Beamery focus on internal mobility, succession planning, and skills inference. Conversational hiring assistants like Paradox's Olivia automate candidate engagement, scheduling, and FAQ at scale. Each shape has different audiences, different regulatory exposure, and different competitive moats. Engineers building for HR need to know which shape they are building, because the engineering implications diverge significantly.

Pattern 1: Resume parsing and structured extraction

Foundation pattern across every category in the market. The system takes unstructured resume content and produces a structured candidate representation: skills, experience, education, certifications, languages.

The mature implementation has stabilized:

• Format-aware parsing. PDF, Word, plain text, HTML each handled with format-preserving parsers. Layout matters because columns, tables, and section headers carry meaning.
• LLM-based field extraction with provenance. Each extracted field links to a textual source in the resume. A skill the system claims the candidate has but cannot trace to text is a hallucination and gets flagged.
• Schema-constrained output. Structured output (JSON schema, tool-call format) rather than free-form prose. Easier to validate and audit.
• Verification pass. Education credentials, certifications, and employment dates verified against external databases where possible. Verified vs unverified status surfaced.

The mature pattern that distinguishes serious products: parsing is itself a tracked, versioned, evaluated step. Hallucinated parsings (qualifications the candidate does not actually have) cause downstream scoring errors and direct candidate harm. Continuous evaluation against a labeled gold set catches parser regressions before they reach scoring.

The full schema and architecture for this layer is in Building an AI Sourcing and Screening Agent.

Pattern 2: Match scoring with calibration

The scoring layer takes a structured candidate and a structured job and produces a match score. This is where the legal exposure concentrates: the score is what employers use to filter and rank, and disparate impact lives at the score-to-decision threshold.

Three architectural variants are in production use:

What separates serious implementations:

• Calibration is monitored, not assumed. Reliability diagrams and Expected Calibration Error tracked over time, per demographic group. Drift triggers investigation.
• Feature attribution per score. Whether the model is gradient-boosted trees or LLM-based, every score has an explanation tied to specific features. This supports FCRA dispute response and Mobley-style "the algorithm did not cause the disparate impact" defenses.
• Multiple ground truth signals. Match accuracy measured against fast signals (recruiter clicks) for iteration and slow signals (retention) for calibration. Aggregate accuracy is not the headline metric.

The full evaluation framework is in Evaluating Recruiting LLMs.

Pattern 3: Demographic data isolation as architecture

The single most important architectural boundary in HR AI systems. Demographic data flows through one path; scoring inputs flow through another. The two paths join only at the audit and monitoring layer.

The pattern reflects a fundamental requirement of fair hiring law: a model that has read access to demographic data, even if it is "not used" in scoring, creates direct disparate treatment exposure. A model that physically cannot access demographic data has a much stronger defense.

Implementation requires:

• Separate database schemas for scoring inputs vs demographic data
• Infrastructure-layer access controls preventing scoring services from reading demographic schemas
• Code review and CI that flags any join between scoring and demographic data outside the audit layer
• Periodic access audits to verify the boundary holds

This is not a feature; it is the architecture. Building it later, after the system has shipped without it, requires teasing apart data flows that have already entangled. Building it from the start is much cheaper.

Pattern 4: Bias audit as continuous infrastructure, not annual project

NYC Local Law 144 mandates annual independent bias audits for AEDTs. Illinois HB 3773, Colorado AI Act, Texas TRAIGA, and the EU AI Act extend similar requirements through 2026. Enforcement is tightening: the December 2025 NY State Comptroller audit found NYC DCWP had 17 likely violations in companies it had cleared, prompting the agency to commit to substantially stronger enforcement.

What the law requires:

Serious products treat the annual audit as a downstream artifact of continuous monitoring infrastructure. The data the auditor needs is the data the team is already monitoring weekly. The audit becomes a smooth process rather than a fire drill. The vendors that built it this way produce clean audits year after year; the vendors that scrambled the first time spent quarters rebuilding their data pipelines under audit pressure.

The methodology, dataset construction, and operational practice are in Building Bias Audits for AI Recruiting.

Pattern 5: Audit trail and FCRA-defensible architecture

The Eightfold FCRA class action raised the stakes on audit trail design. If a court accepts that an AI Match Score is a "consumer report" under FCRA, every score becomes subject to:

• Permissible purpose verification (employer certification before scoring)
• Pre-scoring disclosure and authorization (candidate notification and consent)
• Maximum possible accuracy obligations (ongoing accuracy of underlying data)
• File access rights (candidate can see their score and the data behind it)
• Dispute and reinvestigation flow (candidate can contest data, vendor reinvestigates within 30 days)
• Pre-adverse action notification (copy of report and rights summary before rejection is final)
• Recordkeeping obligations (FCRA-mandated retention period)

Whether or not the Eightfold theory holds in court, the engineering implications are good architecture regardless. A platform that can produce, on demand, the complete decision history for any candidate evaluation has audit defensibility, FCRA compliance, GDPR data access compliance, and litigation defense capability all from the same infrastructure. The cost of building it is much lower than the cost of retrofitting.

The minimum record per evaluation, retention requirements, and pre-adverse action workflow are detailed in The Eightfold FCRA Lawsuit and What Algorithmic Hiring Engineers Need to Ship Now.

Where the loop usually breaks

Patterns that recur across teams shipping HR AI products in 2025 and 2026.

No tool versioning. Model and prompt changes ship without explicit versioning. The team knows roughly what is in production but cannot reconstruct historical state. The first audit reveals this; the team backfills versioning under deadline pressure.

Demographic data accessible to scoring. Feature engineering or training data includes fields that proxy for protected class. The team "knows" not to use them but access controls do not enforce it. Disparate treatment exposure is direct and difficult to defend.

Top-N filtering by default. Recruiter UI shows only top 10 candidates by default. The candidates ranked 11+ are theoretically available but practically invisible. The platform is functionally filtering candidates from review, which is the architectural argument that lost Workday's motion to dismiss.

Outcome data not captured. ATS webhooks not implemented; the platform records who it recommended but not who actually got hired. Bias audit can compute AEDT recommendation rates but not actual selection rates. The audit's defensive value is reduced.

Self-audit theater. Vendor publishes a "bias audit" performed in-house or by an affiliated party. LL 144's independence requirements are not met. Marketed as compliance, fails the law if examined.

Eval set frozen at launch. Evaluation runs against the same 200 cases that were assembled in month one. Production behavior diverges; drift goes undetected. Six months in, the eval is a snapshot of historical behavior, not current behavior.

No FCRA workflow. Employers reject candidates based on AI scores without pre-adverse notification flows. If the Eightfold theory holds, every rejection becomes a per-violation FCRA exposure.

What to expect in the next twelve months

A short list of trends that will shape engineering decisions:

Eightfold case progresses. Discovery, motion practice, and class certification fights through 2026. A win for plaintiffs accelerates FCRA-style architecture as the industry standard. A loss probably delays but does not eliminate; copycat litigation is highly likely regardless.

Mobley moves through discovery. With the collective certified and opt-in closed March 7, 2026, the case enters merits-stage discovery. Vendor liability under "agent" theory will be tested in detail. Other vendors are watching closely; depositions and document production are likely to surface industry patterns.

State law convergence. Illinois HB 3773 (effective January 2026), Colorado AI Act (February 2026), Texas TRAIGA (January 2026), New Jersey A4909 (proposed) all tighten obligations. California's draft regulations on automated decision systems are circulating. Vendors selling nationally have to operate to the strictest interpretation.

EU AI Act effective dates. Phased through 2026 with full effective date August 2026. AI in HR is high-risk; transparency, recordkeeping, and human oversight requirements apply. Vendors deployed in the EU need conformity assessment infrastructure.

LL 144 enforcement scaling. DCWP's commitment to operational fixes following the December 2025 Comptroller audit means more proactive surveillance, complaint investigation, and penalty assessment. Per-day penalty accumulation creates serious dollar exposure for non-compliant deployments.

Procurement requirements harden. Enterprise security reviews now ask for bias audit results, FCRA-style workflow capabilities, and audit trail demonstration. Vendors without these lose deals; vendors with them win.

Per-candidate transparency obligations. Across multiple jurisdictions, the trend is toward giving candidates direct access to information used in their evaluation. Building this in (FCRA-style file access, GDPR data access, Colorado AI Act consumer rights) becomes table stakes.

How to get started

If you are starting an HR AI build today, the priority order:

1. Audit trail and tool versioning first. Without per-evaluation records and explicit versioning, nothing else has defensibility. Build it before the first production deploy.

2. Demographic data isolation in infrastructure. Schema separation and access controls enforced at the infrastructure layer, not the policy layer. Code review and CI checks for join violations.

3. Continuous bias monitoring. Selection rate, impact ratio, calibration metrics computed on a weekly cadence with alerting. The annual audit is downstream of this.

4. Schema-constrained parsing and scoring. Structured outputs, provenance per claim, validation against source. Hallucinated qualifications cause downstream errors and direct candidate harm.

5. Pick one architectural pattern for scoring and ship it deep. LLM-primary, hybrid, or judge-of-feature-model. Each is defensible if implemented well; mixing patterns inconsistently is harder to defend.

6. FCRA-style workflow if you produce scores. Pre-scoring authorization, candidate-facing access, dispute flow, pre-adverse action. Build these even if you are uncertain about FCRA applicability; the architecture is good regardless.

The detailed engineering depth lives in the spoke posts:

• The Eightfold FCRA Lawsuit and What Algorithmic Hiring Engineers Need to Ship Now
• Building Bias Audits for AI Recruiting
• Evaluating Recruiting LLMs
• Building an AI Sourcing and Screening Agent

How Respan fits

The five HR AI patterns above (parsing, scoring, demographic isolation, continuous bias audit, FCRA-defensible audit trail) all rest on the same observability and evaluation substrate. Respan is built to be that substrate underneath teams shipping recruiting AI into Mobley-aware procurement and Eightfold-aware litigation environments.

• Tracing: every candidate evaluation captured as one connected trace from resume ingest through parsing, scoring, ranking, and recruiter action. Auto-instrumented for LangChain, LlamaIndex, Vercel AI SDK, CrewAI, AutoGen, OpenAI Agents SDK. When DCWP or an FCRA plaintiff asks for the complete decision history of a single candidate, the trace is the artifact you hand over, with provenance per parsed field and feature attribution per score already attached.
• Evals: ten built-in evaluators (faithfulness, citation accuracy, refusal correctness, harmfulness) plus LLM-as-judge and custom Python evaluators. Production traffic flows directly into datasets. CI-aware experiments block regressions on hallucinated qualifications, miscalibrated match scores, and four-fifths impact ratio drift before deploys ship.
• Gateway: 500+ models behind an OpenAI-compatible interface, semantic caching, fallback chains, per-customer spending caps. Routing decisions for scoring vs reasoning vs conversational Olivia-style assistants stay configurable without redeploys, and per-tenant caps protect enterprise contracts where assessment volume spikes during hiring cycles.
• Prompt management: versioned registry, dev/staging/prod environments with approval workflows, A/B testing in production with one-click rollback. Resume parsing prompts, job-to-candidate match rationales, and pre-adverse action explanation prompts all belong in the registry so every score in your audit trail ties back to an explicit prompt version.
• Monitors and alerts: selection rate per demographic group, four-fifths impact ratio, Expected Calibration Error drift, parser hallucination rate, FCRA dispute SLA breaches. Slack, email, PagerDuty, webhook. The annual LL 144 audit becomes a downstream artifact of weekly monitoring rather than a fire drill.

A reasonable starter loop for HR AI builders:

1. Instrument every LLM call with Respan tracing including parsing spans, scoring spans, rationale generation, and recruiter UI events.
2. Pull 200 to 500 production candidate evaluations into a dataset and label them for parsing accuracy, score calibration, and demographic balance.
3. Wire two or three evaluators that catch the failure modes you most fear (hallucinated qualifications, disparate impact below the 0.80 threshold, top-N filtering that buries qualified candidates).
4. Put your parsing, scoring, and pre-adverse action prompts behind the registry so you can version, A/B, and roll back without a deploy.
5. Route through the gateway so scoring traffic, conversational traffic, and verification traffic each hit the right model with the right caching and per-customer caps.

Wire this loop early and the next FCRA discovery request, NYC bias audit, or Mobley-style class certification motion finds clean data already in place rather than a retrofitting project under deadline.

To wire any of the patterns above on Respan, start tracing for free, read the docs, or talk to us.