Illinois AI and Biometric Laws: BIPA and Employment

Illinois has the most consequential biometric statute in the United States, largely because individuals can sue directly. That single feature makes the exposure different in kind from states relying on regulator enforcement. This guide covers what applies, drawing on FISTA Solutions' AI enablement work. This article is general guidance, not legal advice.

What applies in Illinois?

Three sources that matter most for AI systems, with the biometric statute dominant.

Source	What it requires
Biometric statute	Written consent, retention schedule, security
Private right of action	Individuals may sue directly
Video interview rules	Notice, explanation, consent, deletion
Employment discrimination law	Addresses AI use in hiring decisions
State privacy obligations	Personal data handling generally
Federal sector rules	Credit, health, employment on top

What does the biometric statute require?

Informed written consent before collecting biometric identifiers, a publicly available retention and destruction schedule, reasonable security, and restrictions on disclosure and on profiting from biometric data.

The order matters: consent comes before collection. A system that captures a voiceprint and then asks permission has already created the exposure, and the record of that capture is the evidence.

What counts as a biometric identifier?

Broadly retina or iris scans, fingerprints, voiceprints, and scans of hand or face geometry.

Ordinary products bring systems into scope more often than teams expect. Call analytics that build voice profiles, verification flows matching a selfie against an identity document, and access systems using face recognition all raise the question, and the answer depends on what the system actually computes and stores rather than on what it is called.

What do the video interview rules require?

Notice that AI will be used, an explanation of how it works and what characteristics it evaluates, consent before use, limits on who the video may be shared with, and deletion within a defined period on the applicant's request.

The explanation requirement is the hard one. An employer using a vendor tool needs the vendor to supply an explanation the employer can give to applicants, which is a procurement question as much as a legal one.

What evidence do you need?

Written consent records tied to individuals with timestamps, a published retention and destruction schedule with evidence it is actually followed, deletion records, notices and explanations given to applicants, and testing evidence for systems influencing hiring decisions.

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 consent capture, retention enforcement, and deletion to the front of any product touching face or voice. Consent before collection is a flow design decision; automatic deletion on schedule is an engineering one.

Retention in particular is where organisations fail: a published schedule that the system does not enforce is worse than none, because it documents what should have happened. Build deletion as an enforced job rather than a policy.

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?

Capturing biometric data before consent. Publishing a retention schedule the system does not enforce. Assuming a vendor's compliance covers yours. And deploying a hiring tool without an explanation you can give applicants.

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 should multi-state operators handle this?

By building to the Illinois standard wherever biometric data is involved, because it is the strictest and the private right of action makes it the highest-exposure.

Per-state variants in consent flows are expensive to maintain and produce gaps when someone's location is misidentified. One flow that meets the strictest requirement is cheaper and safer. See state AI laws comparison.

What should you do first?

Check whether any system computes or stores face geometry, voiceprints, or similar identifiers, and whether written consent precedes collection in every case. That check is short and frequently uncomfortable.

How FISTA Solutions helps

FISTA Solutions builds AI systems so the evidence exists when it is needed: consent captured before collection by design, retention and deletion enforced by scheduled jobs rather than stated in policy, 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 state AI laws comparison.