TRAIGA 552.105(e): Turn NIST Compliance Into a Safe Harbor

Texas did something in House Bill 149, the Texas Responsible AI Governance Act, that most state AI laws haven't bothered to do: it wrote a specific, named technical framework directly into the liability defense. Not "reasonable measures." Not "industry standards" left for a judge to define after the fact. It named NIST's Generative AI Profile, by title, in the statute itself (Tex. Bus. & Com. Code § 552.105(e)(2)(D)).

That's Section 552.105(e), and it took effect January 1, 2026 along with the rest of TRAIGA. If you run generative AI systems that touch Texas consumers, this is the clause that decides whether a documented NIST AI RMF program is a paperwork exercise or a courtroom asset. This article walks through exactly what it says, what it doesn't say, and what "substantial compliance" has to look like before an enforcement action, not during one.

What Section 552.105 Actually Covers

Section 552.105 is TRAIGA's penalty-and-defense engine. Subsection (a) sets the civil penalty ranges the attorney general can seek: $10,000 to $12,000 per violation the court finds curable, $80,000 to $200,000 per violation the court finds uncurable, and $2,000 to $40,000 per day for a violation that continues. (Figures drawn from the enrolled text of H.B. 149, 89th Leg., R.S. (2025); readers should verify against the codified Texas Business & Commerce Code § 552.105(a), available at capitol.texas.gov.) Subsection (b) gives the attorney general standing to sue, seek injunctive relief, and recover fees. Subsection (c) creates a rebuttable presumption that a person exercised reasonable care — which matters because it puts the burden on the state to rebut that presumption rather than on the defendant to prove innocence from a standing start.

Then comes (e), the subsection this article is about, which lays out the specific conduct that removes liability outright rather than merely shifting a burden.

Notice what (e) does that (c) doesn't. The presumption in (c) is rebuttable — the state can still overcome it with evidence. The conditions in (e) are closer to an affirmative defense: if you meet them, the statute says you are not liable, full stop. That distinction is the reason 552.105(e) is worth building a program around rather than treating as one bullet point in a policy memo.

The Four Doors Into the Safe Harbor

Subsection (e) gives you two structurally different routes to the same protection, and the second route branches into four discovery methods. Read narrowly, here's what it protects:

(e)(1) — Third-party misuse. A defendant isn't liable if another person uses that defendant's affiliated AI system in a manner the chapter prohibits. This is the "someone else broke it" defense — you built and deployed the system properly, and a third party's misuse is what created the violation.

(e)(2) — Self-discovery. A defendant isn't liable if the defendant discovers a violation through one of four named channels:

• (A) Feedback from a developer, deployer, or other person.
• (B) Testing, explicitly including adversarial testing or red-team testing.
• (C) Following applicable state agency guidelines.
• (D) Substantially complying with "the most recent version of the Artificial Intelligence Risk Management Framework: Generative AI Profile published by the National Institute of Standards and Technology or another nationally or internationally recognized risk management framework," combined with an internal review process. (Quoted from H.B. 149, 89th Leg., R.S. (2025), § 552.105(e)(2)(D); verify the enrolled text at capitol.texas.gov before relying on this language.)

Route (D) is the one worth building your program around, because it's the only one of the four that you can establish proactively, on a schedule you control, before any violation exists to discover. Feedback and testing are reactive — you find out because something already went wrong or a red-teamer already surfaced it. State agency guidelines are outside your control and, as of this writing, still developing. NIST AI RMF Generative AI Profile compliance is a framework you can implement, document, and demonstrate on your own timeline. It's the one door you get to open before anyone knocks.

Why NIST's Generative AI Profile Specifically

The statute doesn't just say "a risk management framework." It names the Generative AI Profile by title (see § 552.105(e)(2)(D), H.B. 149). That profile is NIST AI 600-1, published by NIST in July 2024 as a companion to the broader AI Risk Management Framework (NIST AI 100-1). AI 600-1 organizes generative AI risk into twelve categories — including confabulation, information integrity, harmful bias, data privacy, and CBRN information — and maps each one to specific actions under the RMF's Govern, Map, Measure, and Manage functions. A detailed breakdown of what an auditor actually expects to see documented against each of the twelve categories is worth reviewing before building your evidence file, because "substantial compliance" is not a phrase Texas courts have had occasion to interpret yet, and you don't want to be the test case for what it means.

Here's the point I'd want a general counsel to sit with: Texas didn't write a vague "adopt good practices" clause — it wrote a named NIST publication into a statutory liability defense. That means your GenAI Profile documentation is no longer just a governance artifact; it's potential trial evidence. That's a different posture than most companies bring to their AI RMF work today, where the framework gets treated as a maturity checklist rather than as something a court might eventually examine line by line.

What "Substantial Compliance" Requires in Practice

"Substantial compliance" is doing a lot of work in this statute, and it's undefined by TRAIGA itself. In the absence of Texas case law construing the phrase, the safest reading borrows from how substantial compliance has been treated in other regulatory contexts: not perfect, contemporaneous, documented adherence to every control, but a good-faith, reasonably complete implementation that a neutral reviewer could verify against the framework's actual text.

For the NIST Generative AI Profile, that means you need artifacts mapped to the framework's structure, not a policy statement that gestures at it. At minimum:

1. A GenAI risk inventory that identifies which of the twelve AI 600-1 risk categories apply to each deployed system, and why.
2. Govern-function documentation — policies, roles, and accountability structures, the same evidence an ISO/IEC 42001:2023 clause 5 audit would expect.
3. Map-function records showing you identified context, intended use, and foreseeable misuse for each system before deployment.
4. Measure-function evidence — actual testing results, not just a testing policy. This is also where (e)(2)(B)'s adversarial and red-team testing overlaps with (e)(2)(D)'s framework compliance; a well-run program satisfies both doors at once.
5. Manage-function records showing how identified risks were tracked, mitigated, or accepted, with dates and owners.
6. An internal review process, which the statute requires in addition to framework compliance — this is the part organizations skip. Substantial compliance with the framework isn't enough on its own; (e)(2)(D) requires "and" an internal review process, not "or."

If you're running an ISO 42001 AI management system already, most of this evidence already exists as a byproduct — the two frameworks overlap heavily on governance structure even though they're built for different purposes, and A separate breakdown covers where they diverge and where they reinforce each other. The gap most companies actually have isn't the framework, it's the internal review process the statute demands on top of it — a documented, recurring practice of checking the system against its own risk inventory, not a one-time implementation project you can point to and call done.

How the Safe Harbor Interacts With the Cure Period

TRAIGA layers 552.105(e) on top of a separate cure mechanism in Section 552.104, which gives a person 60 days to cure a violation after the attorney general provides notice. The safe harbor in (e) and the cure period in 552.104 are not the same protection, and this is where confusion most commonly arises. The cure period is a chance to fix a known violation before penalties attach. The (e) safe harbor is a defense that you never had liability in the first place, because you met one of the four conditions. A well-run NIST GenAI Profile program should make you less likely to need the cure period at all, because your internal review process is the thing that's supposed to catch the violation before the attorney general's office does.

Notably, unlike the 552.104 cure mechanism, subsection (e) doesn't impose its own separate cure deadline — the protection attaches to how the violation was discovered and handled, not to a fixed clock the safe harbor itself starts running.

What the Safe Harbor Does Not Cover

Don't oversell this to your own leadership. A few limits matter:

• It's a defense, not immunity from investigation. The attorney general's complaint portal, required under Section 552.102 of H.B. 149 and due to go live no later than September 1, 2026 (per the enrolled text; verify the current deadline at capitol.texas.gov), is the front door to enforcement. Meeting (e) doesn't stop a complaint from being filed or investigated — it's the defense you raise once you're in the process.
• "Substantial compliance" is untested. No Texas court has yet ruled on what quantum of NIST AI RMF implementation clears that bar. Treat the standard as closer to "complete and verifiable" than "good enough for now" until case law says otherwise.
• It doesn't reach every TRAIGA obligation. The safe harbor sits inside the civil-penalty structure of 552.105. Other TRAIGA duties — like the healthcare AI disclosure requirements — carry their own compliance logic and aren't cured by a NIST RMF program alone.
• Framework compliance plus internal review, not either alone. This bears repeating because it is the most commonly missed condition: the statute's text reads "substantially complying with the ... Generative AI Profile ... and maintaining a program of ongoing internal review." Both halves are required.

A Practical Roadmap

If you're building toward the 552.105(e)(2)(D) defense rather than discovering it exists after a complaint lands, the recommended sequence looks like this:

1. Inventory every generative AI system touching Texas consumers or Texas-domiciled data, and classify each against the twelve NIST AI 600-1 risk categories — producing a dated, system-level risk inventory document for each.
2. Stand up the Govern function first. Roles, accountability, and policy — this is the foundation an auditor or investigator checks before anything else. Evidence artifacts: written AI governance policy, role assignments with named owners, and board- or executive-level sign-off records.
3. Document Map and Measure activity contemporaneously, not retroactively. A risk assessment written after a complaint is filed reads very differently to an investigator than one dated months before. Evidence artifacts: pre-deployment context assessments, foreseeable-misuse analyses, and timestamped testing results (including any adversarial or red-team outputs).
4. Build the internal review cadence as a standing practice — quarterly at minimum for anything customer-facing — and keep the records that prove it ran on schedule. Evidence artifacts: meeting minutes or review logs with dates, attendees, findings, and disposition of each identified risk.
5. Cross-reference against ISO 42001 if you're pursuing certification anyway; the overlap in required evidence means you're not duplicating work, you're reusing it. Map ISO 42001 clause 5 outputs directly to the Govern-function artifacts above.

Every one of these steps produces the same artifact type: dated, specific, verifiable evidence of a system that existed and ran before anyone asked to see it. That's what "substantial compliance" is going to mean in practice, whatever a Texas court eventually says about the phrase.

FAQ

What does TRAIGA Section 552.105(e) actually protect against? It removes liability for a civil penalty action under 552.105 when a defendant either had its AI system misused by a third party in a prohibited way, or discovered a violation through named channels — feedback, adversarial/red-team testing, following state agency guidance, or substantially complying with the NIST Generative AI Profile alongside an internal review process.

Is NIST AI RMF compliance mandatory under TRAIGA? No. TRAIGA doesn't require any company to adopt the NIST framework. It's one of several optional paths to the 552.105(e) safe harbor, but it's the only one an organization can establish proactively rather than discover after the fact.

What is the NIST Generative AI Profile named in the statute? The statute names the Generative AI Profile by title in § 552.105(e)(2)(D) (H.B. 149). That profile is NIST AI 600-1, published by NIST in July 2024 as a companion to the NIST AI Risk Management Framework (NIST AI 100-1), organizing generative AI risk into twelve categories mapped to the RMF's Govern, Map, Measure, and Manage functions.

Does the safe harbor apply if my company only has a written AI policy? Not on its own. The statute requires substantial compliance with the framework's actual structure plus a maintained internal review process — a policy document without mapped evidence and a recurring review cadence is unlikely to meet either half of that standard.

When does TRAIGA enforcement actually start? TRAIGA took effect January 1, 2026. The attorney general's online complaint mechanism, required under Section 552.102 of H.B. 149, is required no later than September 1, 2026 (per the enrolled text; verify at capitol.texas.gov), and complaints through that portal are the statutory precondition for an investigation under Section 552.103.

If you're building a Texas-facing generative AI program and want the NIST GenAI Profile evidence mapped correctly the first time, an AI risk assessment is the right starting point — it's the same inventory-and-mapping work this safe harbor requires, done before an investigator asks for it rather than after. For the underlying framework detail auditors and investigators actually check line by line, see our breakdown of the twelve NIST AI 600-1 risk categories.

Last updated: 2026-09-12