Utah AI Policy Act Audit Evidence: Build the Complaint and Disclosure File

A Utah complaint can turn on one consumer exchange: the individual asked if the assistant was human, the supplier answered, and a hosted model produced the next message. The useful evidence package joins that exchange to the applicable disclosure trigger, approved notice, model route, policy version and release record.

The primary source has two layers. Senate Bill 149 created Utah's Artificial Intelligence Policy Act and took effect on 1 May 2024. Senate Bill 226 replaced the original consumer-facing provision with Utah Code Chapter 13, Chapter 75 from 7 May 2025 and extended the separate Artificial Intelligence Policy Act chapter. Current Utah AI Policy Act AI audit evidence should therefore preserve the 2025 trigger analysis instead of quoting the original rule as current text.

Start with a version and scope sheet

The first exhibit should identify the legal entity, supplier, service, Utah consumer connection, regulated-occupation status, model-backed feature, release version and accountable owner. Add the date range under review because SB 226 changed the operative structure after SB 149.

For each interaction type, record the applicable branch under Chapter 75: consumer transaction, regulated service, high-risk AI interaction, or an activity outside those definitions. SB 226 defines a high-risk interaction around sensitive personal information, personalized advice that could reasonably inform significant personal decisions, and other applications defined by Division rule.

Legal owns that classification. Product supplies the service design and AI inventory. The evidence package should retain the signed analysis and every fact that changes the branch, such as health data collection or medical advice.

Preserve the reactive consumer disclosure record

Utah Code Section 13-75-103 requires a supplier using generative AI in a consumer transaction to disclose that the individual is interacting with generative AI rather than a human when the individual makes a clear and unambiguous request about AI use.

Build a complaint exhibit with the consumer's question, the system's response, channel, timestamp, session identifier, approved wording and release version. The record should show how the application detected the request and delivered the answer. A current screenshot of the chatbot proves only the current design; it leaves the historical exchange unresolved.

The application owns this evidence. A routed LLM event can corroborate that generative AI participated in the session and identify the model destination. It cannot prove that the consumer's question met the legal trigger or that the disclosure appeared correctly without joined conversation and interface records.

Prove the regulated-service high-risk branch

Section 13-75-103 separately requires an individual providing services in a regulated occupation to disclose generative AI when its use constitutes a high-risk AI interaction. The disclosure must occur verbally at the start of a verbal interaction and in writing before a written interaction. The provider must also comply with the regulated occupation's requirements.

Create a branch file for every regulated service. Include the licence or certification basis, service description, data classes, advice type, high-risk conclusion, approved notice and timing test. Run a clean-session test for oral and written channels that records the exact first consumer-facing content.

The visual test is simple: on a review screen, the disclosure should appear above the first AI-written message, not buried beneath a settings link. Keep the recording or capture, test date, reviewer and release hash.

Build safe-harbor evidence separately

Section 13-75-104 establishes a safe harbor from an enforcement action for violating the disclosure section when the generative AI clearly and conspicuously identifies itself at the outset of covered interactions and throughout the interaction using one of the statutory descriptions. The Division may make rules specifying acceptable forms and methods.

Safe-harbor evidence needs stronger continuity than a single opening capture. Preserve the approved design, channel-specific implementation, every state change that can hide or replace the identifier, accessibility review and sampled sessions spanning the interaction. Record the rule version checked by legal.

My view is that safe-harbor reliance deserves its own signed approval. Treating it as a casual UI preference creates a brittle defense because a later redesign can remove the continuing identifier while leaving the opening notice intact.

Retain the consumer-protection and liability file

Section 13-75-102 states that generative AI making a violative statement, undertaking a violative act or being used in furtherance of a violation fails as a defense to statutes administered by the Division of Consumer Protection. Section 13-75-105 makes a Chapter 75 violation a consumer-protection violation and gives the Division administrative and court enforcement routes.

The evidence file should therefore extend beyond notice proof. Preserve the consumer claim, complete interaction, approved product representation, retrieved model requests and responses, human escalations, complaint triage, correction and legal assessment. A model output is an operating fact. Legal determines how consumer-protection law applies.

Runtime records are valuable here because they identify the authenticated caller, endpoint, policy and decision attached to a disputed request. They remain one layer in the case rather than a substitute for the full consumer record.

Keep the enforcement response reproducible

The enrolled SB 226 text authorizes Division administration, administrative fines, court actions, injunctions, disgorgement and other relief. Numeric penalty details belong in the legal response file and should be checked against the current code at the time of an inquiry.

Prepare a reproducible response package with a contents index, collection query, custodians, hashes, export date and reviewer. Select one complaint reference and reconstruct the service version, disclosure branch, notice state, model route, request outcome and remediation. Preserve failed test cases alongside clean retests.

A useful package lets a second reviewer repeat the collection without asking the original engineer which dashboard filter was used. The saved query and join keys carry more evidentiary weight than a polished screenshot.

Separate statutory and operating evidence

Utah Chapter 75 specifies disclosure, liability, safe-harbor and enforcement rules. It contains no universal requirement to retain every AI request. Per-decision records are recommended operating evidence because they can corroborate model use, route, policy, request classification, complaint scope and retest results.

Use two labeled folders:

• Statutory and legal evidence: scope analysis, trigger decision, regulated-occupation status, high-risk classification, approved disclosure, safe-harbor analysis and legal response.
• Operating evidence: session records, routed model events, policy decisions, release versions, tests, alerts, remediation and retests.

Link the folders through stable service, session, request, policy and release identifiers. That design keeps implementation advice distinct from Utah's text while making a complaint answer faster to assemble.

Evidence-package index

• Version and scope: SB 149 or SB 226 period, supplier, transaction, occupation, feature and owner.
• Reactive disclosure: clear consumer request, response, channel, time, release and approved wording.
• High-risk service: data or advice category, legal classification, licence basis and start-of-interaction proof.
• Safe harbor: opening and continuing identifier, channel state, accessibility review and legal approval.
• Consumer case: representation, full exchange, model event, escalation, complaint decision and correction.
• Reproduction: collection query, hashes, custodians, reviewer and clean retest.

DeepInspect

DeepInspect supplies the HTTP operating-evidence layer for authenticated users or agents calling LLM endpoints. It evaluates application-supplied identity context, request classification, destination and policy before transmission, then creates a signed, tamper-evident per-decision record outside the calling application's write path.

Those records can corroborate model use in a disputed session, identify the provider route, retrieve the policy applied, scope affected requests and preserve cure retests. DeepInspect leaves Utah scope analysis, regulated-occupation classification, high-risk determinations, consumer-facing disclosure, safe-harbor presentation and Division communications with the owners named above. Book a technical deep dive at deepinspect.ai.