State AI Laws Compared: What Differs and What Overlaps

US state AI rules differ in form but overlap in what they assume. Once you have an inventory, assessments, differential-outcome testing, and disclosure, most state requirements become a mapping exercise. This guide compares the main approaches, drawing on FISTA Solutions' AI enablement work. This article is general guidance, not legal advice.

What are the main types of state rule?

Four broad categories, with several states combining more than one.

Type	What it requires
Biometric consent	Written consent before collection, retention schedule
Hiring audit and notice	Independent bias audit, published results, notices
Assessment-based	Risk assessment for consequential decisions, notice, appeal
Disclosure	Telling people they are dealing with AI
Training data transparency	Disclosure about data used to train systems
Consumer protection	Applies to AI claims and outputs everywhere

Which duties bite hardest?

Biometric consent and hiring audits, for different reasons.

Biometric rules in at least one state carry a private right of action, which changes the exposure from regulator enforcement to class litigation. Hiring audits produce a dated artefact: either a current audit exists or it does not. Both are binary and visible rather than arguable. See Illinois AI and biometric laws.

What do assessment-based regimes require?

Broadly: identifying systems used in consequential decisions — employment, lending, housing, insurance, education, healthcare — assessing them for risks including discriminatory outcomes, documenting the reasoning, notifying affected people, and in some cases providing an appeal route.

The documented reasoning is the substance. An assessment concluding a system is fine, without saying what was examined and against what, is not evidence of anything.

Should you build per state or to the strictest?

To the strictest combination, almost always.

Per-state variants multiply flows, produce gaps when someone's location is misidentified or changes, and create inconsistencies between documents that are themselves a finding. One consent flow, one assessment template, one testing regime, and one disclosure pattern built to the highest bar is cheaper to run and easier to defend.

The exception is where a strict requirement genuinely cannot be met everywhere for product reasons, which is rarer than teams assume.

What evidence do you need?

An inventory with named owners and the states each system touches, assessments with documented reasoning, testing evidence for differential outcomes, consent records where biometric data is involved, audit reports with dates, and notice records.

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 four things into the build: consent before collection, version records tying tools to decisions, differential-outcome testing as a standing job, and disclosure at the point of interaction.

All four are cheap when designed in and expensive afterwards, and all four are what any plausible federal approach would also ask for.

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?

Building per-state variants. Treating a vendor's audit as your own. Assessing without documenting reasoning. Running differential-outcome testing once rather than continuously. And assuming a system is out of scope because it only assists a decision.

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 federal law interact?

It stacks, and in several areas it is stricter. Credit decisions, employment, health data, and children's data carry federal obligations regardless of state rules, and those are frequently the binding constraint.

An organisation building to the relevant federal requirements plus the strictest state position generally has little left to do per state, which is the efficient way to run a multi-state programme.

What should you do first?

Build the inventory and tag each system with the states it touches and whether it influences a consequential decision. That table drives everything else. See what is an ai inventory.

How FISTA Solutions helps

FISTA Solutions builds AI systems so the evidence exists when it is needed: one consent, assessment, testing and disclosure pattern built to the strictest applicable requirement rather than per-state variants, 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 AI and employment law.