Texas TRAIGA AI Audit Evidence: Build the Eight-Part Attorney General File

Texas House Bill 149 took effect on 1 January 2026. The enacted Texas Responsible Artificial Intelligence Governance Act gives the Attorney General exclusive enforcement authority and creates a complaint-driven investigation path. Business & Commerce Code § 552.103 then lists eight categories of information the Attorney General may request through a civil investigative demand.

That list is the backbone for Texas TRAIGA AI audit evidence. The statute contains targeted duties and prohibitions rather than a universal per-decision logging command. I would still prepare the eight-part file before a complaint, because sixty days is a poor time to discover that the deployment team and legal team use different names for the same system.

Scope the exact system and role

Chapter 551 applies the subtitle to a person conducting business in Texas, producing a product or service used by Texas residents, or developing or deploying an AI system in Texas. Chapter 552 defines developers and deployers separately. The statute defines an AI system as a machine-based system that infers from inputs how to generate outputs such as content, decisions, predictions or recommendations that can influence physical or virtual environments.

The first exhibit should identify the legal entity, developer or deployer role, system name, version, Texas use and accountable owner. Attach an architecture diagram naming each HTTP model route. This role-and-system sheet prevents evidence from one model version or affiliated entity being presented as proof for another.

Assemble the eight statutory folders

After a complaint, the Attorney General may request eight categories of information under § 552.103. Build one folder for each:

• Purpose, intended use, deployment context and associated benefits
• Data used to program or train the system
• Categories of data processed as inputs
• Outputs produced by the system
• Performance metrics used by the person
• Known system limitations
• Post-deployment monitoring and user safeguards, including a deployer's oversight, use and learning process
• Other relevant documentation reasonably necessary for the investigation

The statute asks for high-level descriptions in several fields. Support each description with a named source artifact, owner and last-review date. Approved use cases belong in the purpose folder. Link the input and output folders to observed request classes. Monitoring evidence should connect alerts, tests, issue reviews and policy changes.

Preserve proof of the duties that apply

Business & Commerce Code § 552.051 requires clear and conspicuous disclosure for a governmental agency making an AI system available to interact with consumers, including plain language and freedom from dark patterns. It also sets a disclosure timing rule where an AI system is used in relation to health care service or treatment. The targeted prohibitions in §§ 552.052 through 552.057 concern intentional encouragement of harm or crime, governmental social scoring, certain biometric uses, constitutional rights, intentional unlawful discrimination and specified sexual content.

Evidence should match the applicable provision. For disclosure, retain the approved text, interface capture, deployment date and interaction record. A prohibited-intent file should preserve design approvals, system instructions, red-team cases, issue handling and change history. Governmental biometric use calls for records of purpose, source, consent and rights analysis.

An evidence file that treats every organization as subject to every subsection obscures the case. Applicability belongs at the front of each folder.

Use testing as statutory evidence

Business & Commerce Code § 552.105 creates liability rules and identifies testing as one route through which a defendant may discover a violation. It expressly mentions adversarial testing and red-team testing. The same subsection references substantial compliance with the current NIST Generative AI Profile or another recognized AI risk framework, paired with an internal review process.

For each applicable prohibition, retain the test objective, model and policy version, test input, observed output, reviewer, severity and remediation. Include requests that policy refused as well as cases escalated to a human. A screenshot of a red-team dashboard carries little weight by itself; the useful record links the finding to the control change and retest.

My view is that § 552.105 rewards teams that find their own problems with disciplined testing. That makes the failed test record valuable evidence rather than an embarrassing artifact to delete.

Build the 60-day cure dossier now

Business & Commerce Code § 552.104 requires written notice before an Attorney General action and provides a 60-day cure path. To use it, the person must cure the identified violation and provide a written statement confirming the cure, supporting documentation showing how it was cured, and necessary internal-policy changes aimed at preventing recurrence.

Create a cure template with five linked fields: allegation, affected system version, containment, permanent correction and prevention policy. Add approval, deployment and retest evidence. On a conference-room screen, the whole chain should fit into one timeline with the complaint at the left and the clean retest at the right.

The civil penalty structure raises the value of that preparation. An uncured curable violation or breach of a cure statement carries $10,000 to $12,000 per violation; an uncurable violation carries $80,000 to $200,000; a continuing violation carries $2,000 to $40,000 per day under § 552.105. State licensing agencies can add sanctions after the required findings and recommendation.

Keep evidence tied to intent

Several TRAIGA prohibitions use an intent element. Business & Commerce Code § 552.052 addresses intentional aims to incite or encourage self-harm, harm to another person or criminal activity. Sole intent appears in § 552.055 for constitutional impairment. Intentional unlawful discrimination is addressed in § 552.056, which states that disparate impact by itself is insufficient to show intent.

Evidence therefore has to preserve design purpose and operating decisions. Keep product requirements, system instructions, safety policy, approval history, testing and known-limitations reviews. Runtime records can show what a particular request did and which policy applied. They provide one part of the intent analysis rather than a legal conclusion.

This distinction also protects accuracy. A harmful output can trigger investigation and remediation while the statutory intent question remains a separate legal assessment.

Separate statutory evidence from operating evidence

TRAIGA names the investigation materials the Attorney General may request. It never converts every LLM call into a statutory record obligation. Per-request records remain useful operating evidence because they substantiate the high-level descriptions, monitoring safeguards, incident scope and cure results.

Use a two-layer file that keeps legal interpretation beside operating facts. The statutory layer follows the eight § 552.103 requests and the applicable substantive provision. The operating layer contains sampled requests, policy decisions, tests and changes. Legal owns the first; product, security and platform produce much of the second.

That separation prevents a common overclaim in state AI compliance writing: treating sensible audit architecture as verbatim statutory text.

DeepInspect

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

The resulting per-decision records provide evidence for the input-category, output-handling, post-deployment-monitoring and user-safeguard descriptions requested under § 552.103. They also preserve blocked test cases, affected requests, policy versions and retest outcomes for a § 552.104 cure package. DeepInspect leaves purpose definition, training-data documentation, performance metrics, known-limitations analysis, disclosure design and legal intent determinations with their accountable owners. Book a technical deep dive at deepinspect.ai.