AI and Employment Law: Hiring, Monitoring and Decisions

Employment law reaches AI through the decisions it influences rather than through the technology itself. The duty sits with the employer, and the evidence that defends a decision has to exist before the decision is challenged. This guide covers both, drawing on FISTA Solutions' AI enablement work. This article is general guidance, not legal advice.

Where does AI meet employment obligations?

At every decision about a person, plus monitoring of how people work.

Decision or activity	What applies
Screening and shortlisting	Discrimination duties, notice rules
Interview assessment	Discrimination duties, recording consent
Promotion and progression	Discrimination duties, transparency
Performance management	Accuracy, notice, review rights
Termination decisions	Documented basis, human judgement
Workplace monitoring	Notice, proportionality, consultation

Who is liable when a tool discriminates?

The employer making the decision, generally.

A vendor's assurance that a tool was tested does not transfer the duty, and pointing at the system is not a defence. That makes vendor claims something to verify rather than rely on, and it makes your own testing — against your applicant population — the evidence that matters. See New York City AI hiring law.

What is adverse impact testing?

Analysis of whether selection rates differ materially across protected groups, applied to the tool as the employer actually uses it.

The key phrase is 'as actually used'. A tool tested by the vendor on a general population says little about your applicant pool and your thresholds. It also needs repeating as the tool, the population, or the role changes, which makes it a standing job rather than a procurement step.

What limits apply to workplace monitoring?

Notice expectations, proportionality, and in several jurisdictions consultation with employee representatives before deployment.

Monitoring that infers emotional state or productivity from behavioural signals attracts particular scrutiny, and some such uses in workplaces are prohibited outright under the EU regime rather than merely regulated. Check the prohibition list before designing anything in this space.

What evidence do you need?

Adverse impact testing results with dates and populations, records of what the tool contributed to each decision, notices given to candidates and employees, human review records, and documentation of which tool version was in use when.

If that evidence exists as a by-product of how systems are built and operated, you are in good shape. If it exists only as documents written for a review, you are not, and the difference is visible to anyone who looks carefully.

How does this change engineering practice?

It pushes decision-basis capture and version tracking into HR systems that rarely have either. Recording which tool version scored which candidate, and what the human reviewer saw and decided, is what makes a decision defensible two years later.

It also argues for keeping the system's role advisory and visible: a reviewer who can see the basis and disagree produces both better decisions and better evidence.

How does it interact with other regimes?

Usually more than expected. The same system can attract questions from a data protection authority, a sector supervisor, and a general AI regulator, each starting from a different premise and arriving at overlapping requirements.

One evidence base mapped to several requirements answers all of them. Separate programmes produce separate documents describing the same systems, and inconsistencies between them are themselves a finding.

What does compliance cost?

Mostly the cost of good engineering practice: evaluation, documentation, logging, and oversight design. Built into a project, the incremental cost is modest and much of it is work the system needed anyway.

Retrofitted onto a live system it becomes a project, performed under a deadline you did not choose, on something people already depend on. See AI compliance audit cost.

What are the common mistakes?

Relying on a vendor's testing. Running impact analysis once at procurement. Recording outcomes without the basis. And deploying behavioural monitoring without checking prohibition lists.

Who owns this internally?

The function that owns the systems, with legal and compliance support. Ownership by compliance alone produces documents describing systems nobody changed; ownership by engineering alone produces good practice with no one accountable for the interpretation.

Name a person per system rather than a committee. Committees review; people decide.

What should you ask a supplier?

What documentation they provide about capabilities and limitations, what evaluation evidence they share, how they handle personal data, where processing happens, and what happens to your prompts and outputs.

Suppliers who have prepared answer those quickly. Suppliers who have not take weeks, and that delay is itself information about how the relationship will run.

How do you keep this current?

Assign someone to watch the sources that actually bind you rather than general commentary. Record what was checked and when, so the next review starts from a known point.

Rules in this area change, and a position taken eighteen months ago and never revisited is a risk in itself.

How does this interact with data protection?

Closely. Employee and candidate data is personal data, and processing it carries lawful basis, transparency, and rights obligations alongside the employment duties.

One evidence base serves both: notices, records of the basis, retention discipline, and the ability to explain a decision answer data protection and employment questions alike. Running them separately produces two sets of documents and one set of gaps.

What should you do first?

Take a recent rejection and try to explain, from records, what the system contributed and what the human decided. If you cannot, that is the gap a claim will find.

How FISTA Solutions helps

FISTA Solutions builds AI systems so the evidence exists when it is needed: tool versions and decision bases recorded per candidate so decisions remain explainable, impact testing run against your own applicant population on a schedule, evaluation results dated and versioned, oversight designed structurally rather than asserted in policy, and documentation produced during the build rather than reconstructed afterwards. Delivery runs through AI enablement, AI agents, and forward deployed engineers. The record is 150+ projects for 50+ companies across 12+ countries.

To align a system with these requirements, message FISTA on WhatsApp, or read New York City AI hiring law.