Utah AI Disclosure Law: When You Must Say It Is AI

Utah's AI policy legislation is short, and its most important element is not the disclosure mechanics but the liability confirmation: consumer protection law applies to what your AI system says. This guide covers both, drawing on FISTA Solutions' AI agents work. This article is general guidance, not legal advice.

What does the law require?

Disclosure obligations that differ by context, plus a liability confirmation that applies everywhere.

Context	Obligation
General consumer interaction	Disclose generative AI when asked
Regulated occupations	Disclose proactively before interaction
Any AI output to consumers	Consumer protection law applies
Marketing claims	Substantiation required as for any claim
Records	Evidence of what was disclosed
Other states	Their own rules apply alongside

Why does the liability point matter most?

Because it confirms what many organisations had hoped was unsettled: you cannot avoid consumer protection liability by pointing at the model.

A misleading statement made by a system you deployed is a statement your organisation made. That has direct engineering consequences — it means constraining what the system may assert, grounding claims in verified sources, and preventing confident answers on topics where the system has no basis.

What counts as a regulated occupation?

Occupations requiring a state licence or certification, including healthcare, legal, and financial services roles.

Systems used in providing those services must disclose their nature proactively rather than only when asked, which means disclosure appears at the start of the interaction rather than in response to a question the user may never think to raise.

How should disclosure be implemented?

At the point of interaction, in plain language, in a form that survives the interface the user is actually in.

Disclosure buried in terms of service satisfies nobody and does not meet a proactive requirement. Products that treat this as a design problem rather than a legal checkbox generally end up better, because users behave differently — and more usefully — when they know what they are talking to. See EU AI Act transparency obligations.

What evidence do you need?

Records of what each interface discloses and when disclosure was introduced, evidence that regulated-occupation systems disclose proactively, and substantiation for claims the system makes to consumers.

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?

The liability confirmation pushes grounding and abstention into the design. A system that answers confidently on topics it has no basis for is a consumer protection exposure, not merely a quality problem.

That means retrieval-grounded answers where facts are involved, explicit abstention where the system does not know, and constraints on what it may assert about products, prices, and entitlements. See what is abstention in ai.

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?

Treating disclosure as the whole obligation and ignoring the liability point. Burying disclosure in terms of service. Letting a system make product or pricing claims it cannot substantiate. And assuming regulated-occupation rules do not apply because a licensed person reviews afterwards.

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 compare with other states?

It is lighter than regimes imposing assessment and audit duties, and it reaches something they sometimes do not: the plain confirmation that existing consumer law applies.

Organisations operating across states generally satisfy this by meeting stricter requirements elsewhere, but the liability point is worth internalising everywhere, because the same principle applies whether or not a statute spells it out. See state AI laws comparison.

What should you do first?

Check what each customer-facing system discloses at the start of an interaction, and separately check whether any of them can make a factual claim about your products that nobody verified.

How FISTA Solutions helps

FISTA Solutions builds AI systems so the evidence exists when it is needed: disclosure designed into the interaction rather than the terms, factual claims grounded in verified sources with explicit abstention where the system has no basis, 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.