What deployers must tell consumers after an adverse AI decision under state AI laws

What a post-adverse-decision notice asks of a deployer

Typical notice elements include the following. Each one can be treated as an evidence requirement: if the notice says it, the deployer should be able to show a stored record that supports it.

• Principal reasons for the adverse decision.
• Role of the AI system in the decision.
• Data used to reach the decision.
• Options to correct data or appeal.

Mapping each notice element to the records that support it

Why agentic and tool-calling workflows make reconstruction harder

In a single-model scoring system, a decision record can be one row: inputs, score, outcome. In an agentic workflow, a decision may pass through several systems. An agent may retrieve data through one tool, call a model through another, apply a rule in a third system, and hand off to a human reviewer in a fourth. Each system may keep its own logs in its own format, with its own retention period and no shared decision identifier.

That fragmentation shows up as a specific failure at notice time. The team can see that an adverse outcome occurred but cannot say which inputs were used, which model version responded, whether a policy check ran, or whether a person reviewed it. A principal-reasons explanation written from memory or from a partial log risks being inaccurate, and an inaccurate notice is harder to defend than a late one.

Ownership compounds the problem. Evidence may sit with platform engineering, the business unit, a vendor, and the compliance team. Deciding in advance who owns the end-to-end decision record is an operational decision, and it is easier to make before a consumer request arrives.

What to confirm for each applicable state law

Exact content, timing, and delivery differ by law and must be confirmed against statutory text. For each applicable law, confirm at least the following:

• The content the notice must include.
• When notice is due.
• How notice must be delivered.
• Which jurisdiction's requirements applied to the decision.

Evaluating whether your workflows can produce a defensible notice

1. Can you retrieve the exact inputs, model output, and model version for that decision?
2. Can you show which policy checks ran and what each one returned?
3. Can you identify any human review step, the reviewer, and the action taken?
4. Can you trace the decision across every system and tool it touched using one identifier?
5. Can you tell which jurisdiction's requirements applied and when notice was due?
6. Can you preserve the original decision state while handling a correction or appeal?

Where runtime governance supports evidence collection

Runtime policy enforcement and audit logging can support evidence collection for agent-driven decisions, so that the records behind each notice element exist before a consumer request arrives.