Texas TRAIGA AI Compliance Checklist: 10 Tests for Enacted HB 149

Texas House Bill 149 took effect on 1 January 2026. The enacted Texas Responsible Artificial Intelligence Governance Act creates targeted duties and prohibitions, a consumer-complaint route and exclusive Attorney General enforcement. It also identifies eight categories of information the Attorney General may request through a civil investigative demand.

This Texas TRAIGA AI compliance checklist turns those provisions into ten tests. Each test names an accountable owner, evidence and a completion condition. The list deliberately avoids a common overstatement: enacted HB 149 contains no universal command to log every AI decision.

1. Confirm scope, system and legal role

Business & Commerce Code § 551.002 applies the subtitle to a person that conducts business in Texas, produces a product or service used by Texas residents, or develops or deploys an AI system in Texas. Chapter 552 defines developer and deployer separately.

Owner: Legal and the AI system owner.

Evidence: Legal-entity record, Texas nexus analysis, system inventory, developer-or-deployer classification and named accountable owner.

Done when: Every AI system with a Texas connection has one versioned scope sheet tying the legal entity, product, use, deployment state and role to an approved analysis. The inventory also distinguishes a deployed system because § 552.105 bars civil-penalty action against a system that has not been deployed.

2. Map each use to the applicable prohibition

Business & Commerce Code §§ 552.052 through 552.057 address intentional encouragement of self-harm, harm or crime; governmental social scoring; specified governmental biometric uses; sole-intent constitutional impairment; intentional unlawful discrimination; and specified sexual content involving children.

Owner: Legal, product and trust or safety.

Evidence: Applicability matrix linking each use case to the relevant subsection, legal rationale, product requirement and control owner.

Done when: Every deployed use has a reviewed yes, no or conditional determination for each targeted provision. A conditional row names the fact that changes the outcome, such as governmental-entity status, biometric purpose or statutory intent.

3. Preserve the intent analysis

Several HB 149 prohibitions turn on intent. Business & Commerce Code § 552.056 states that disparate impact by itself is insufficient to demonstrate intent to discriminate. The constitutional-impairment provision in § 552.055 uses a sole-intent threshold.

Owner: Legal and product leadership.

Evidence: Product requirements, approval minutes, system instructions, test plan, known-limitations review, issue history and change approvals.

Done when: A reviewer can trace the approved purpose and design decisions for every use mapped to an intent-based provision. Runtime outputs and request records sit beside that file as operating facts. Legal reaches the intent conclusion.

4. Deliver the disclosure where § 552.051 applies

Business & Commerce Code § 552.051 requires a governmental agency making an AI system available to interact with consumers to disclose the AI interaction before or at interaction time. The notice must be clear, conspicuous, in plain language and free of dark patterns. The same provision sets timing for AI used in relation to health care service or treatment, including an emergency qualification.

Owner: Legal, product and the governmental or health-care service owner.

Evidence: Approved notice, interface capture, notice version, deployment date and interaction sample.

Done when: A test consumer sees the correct notice at the statutory time and the captured interface matches the approved version. Private deployments outside this wording retain a documented applicability conclusion rather than a copied governmental disclosure rule.

5. Build the eight-part Attorney General file

Under § 552.103, a complaint can lead to a civil investigative demand covering eight categories: purpose and use; programming or training data; input categories; outputs; performance metrics; known limitations; post-deployment monitoring and user safeguards; and other relevant documentation reasonably necessary for the investigation.

Owner: Legal coordinates product, data science, security and AI platform contributors.

Evidence: Eight indexed folders, each with an owner, source artifact, system version and last-review date.

Done when: A tabletop produces all eight folders for one deployed system without relying on an engineer's memory. High-level descriptions reconcile to the underlying model card, route inventory, evaluation report and monitoring record.

6. Reconcile request classes with the system description

The Attorney General may request high-level descriptions of input categories and outputs under § 552.103. Those descriptions become weak when the approved design says “customer support text” while production routes also carry attachments, source code or health information.

Owner: AI platform, privacy and product.

Evidence: Approved input-output taxonomy, sampled HTTP AI requests, classification results and discrepancy tickets.

Done when: A sample across each approved model route matches the categories in the Attorney General file. Any new class receives an owner, an applicability review and a dated update before normal use continues.

7. Test targeted harms and safeguards

Business & Commerce Code § 552.105 expressly recognizes testing, including adversarial and red-team testing, as a route through which a defendant may discover a violation. It also refers to the current NIST Generative AI Profile or another recognized AI risk framework alongside an internal review process. That language creates a liability path rather than a universal NIST adoption mandate.

Owner: Security testing, product and legal.

Evidence: Test objective, model and policy version, input, observed output, reviewer, severity, remediation and retest.

Done when: Every applicable prohibition has positive and negative cases, a named expected result and a linked remediation path. The test file preserves failed cases because self-discovery can matter under § 552.105.

8. Operate post-deployment monitoring

The seventh § 552.103 category asks for a high-level description of post-deployment monitoring and user safeguards. For deployers, it includes the oversight, use and learning process established to address deployment issues.

Owner: Product operations and security.

Evidence: Monitoring specification, alert thresholds, review queue, user-report intake, issue decisions and policy-change history.

Done when: A seeded test event moves through detection, triage, decision, control change and retest under one case reference. A dashboard image alone fails this completion test because it omits the response chain.

9. Prepare the 60-day cure package

Business & Commerce Code § 552.104 requires written notice before an Attorney General action and creates a 60-day cure route. The person must cure the identified violation and provide a written statement, supporting documentation showing the manner of cure and necessary internal-policy changes aimed at reasonably preventing another violation.

Owner: Legal, with the affected control owner.

Evidence: Cure template, allegation, affected version, containment, permanent correction, policy change, deployment approval and retest.

Done when: A tabletop can place the written notice on the left side of a conference-room screen and the clean retest on the right, with every intermediate approval linked by date and system version.

10. Separate runtime evidence from legal conclusions

TRAIGA's investigative categories call for system descriptions, metrics, limitations, monitoring and safeguards. Per-request records can substantiate several of those descriptions, scope an incident and prove a retest. They remain operating evidence rather than a statutory log mandated for every call.

Owner: Legal owns interpretation; AI platform and security own runtime records.

Evidence: Two-layer index connecting each statutory folder to the relevant request samples, tests and policy decisions.

Done when: Every technical record has a stated evidentiary purpose, and every legal conclusion points to its legal owner. My view is that this separation is the strongest item on the checklist because it prevents sensible engineering practice from being misquoted as enacted Texas law.

For artifact packaging, use the Texas TRAIGA audit evidence guide, which follows the same enacted HB 149 source and separates statutory folders from operating evidence.

DeepInspect

DeepInspect contributes to items 5 through 10 for authenticated users or agents calling HTTP-based LLM endpoints. It evaluates application-supplied identity, request classification, route and policy before transmission, then writes a signed, tamper-evident per-decision record outside the calling application's write path.

Those records support input and output descriptions, route reconciliation, blocked test cases, monitoring, incident scope and cure retests. DeepInspect leaves legal scope, statutory intent, interface notices, training-data documentation, performance metrics and Attorney General communications with the owners named above. Book a technical deep dive at deepinspect.ai.