What is the Texas TRAIGA safe harbor, and how does NIST AI RMF relate to it?

Texas HB 149 (TRAIGA) has a defense, not a blanket safe harbor. Under Section 552.105(e), a company can't be found liable for a violation it discovers through an internal review process while substantially complying with the most recent NIST Generative AI Profile, a companion to AI RMF 1.0, or another recognized AI risk framework.

Does one documentation set really satisfy the EU AI Act too?

For the shared core, yes. EU AI Act Article 11 requires technical documentation for high-risk AI systems, Article 9 requires a risk management system, Article 14 requires human oversight measures, and Article 73 requires incident reporting. These requirements map closely to NIST AI RMF's Map, Measure, and Manage functions.

What if my organization is not a "high-risk" AI deployer under the EU AI Act?

For limited-risk and minimal-risk AI systems under the EU AI Act, the mandatory documentation requirements are less extensive. You still need Article 50 transparency notices for certain user-facing AI (like chatbots), but Annex IV technical documentation and formal risk management systems are not required.

How much work is the shared core versus the framework-specific additions?

The shared core is the bulk of the work, roughly 70-80% of the total effort. The AI tool inventory, risk assessments, human oversight documentation, incident log, and vendor records are the heavy lifting. Framework-specific additions are mostly reformatting, cross-referencing, and adding required notices.

Do I need a lawyer to build this documentation?

For the documentation structure and templates, no. You can build the framework using this guide and adapt it to your organization. For the actual content of each section, legal review is advisable before treating your documentation as a compliance defense, particularly for the fundamental rights impact assessment and any determinations about high-risk classification under the EU AI Act.

How often does the documentation need to be updated?

The AI tool inventory and risk assessments should be reviewed whenever a new AI tool is adopted, when an existing tool changes materially (new model version, expanded use case, new user population), or at minimum annually. The incident log is updated on a rolling basis. The human oversight documentation should be reviewed quarterly or when process changes occur.

One Documentation Set for EU AI Act, NIST AI RMF and TRAIGA

TL;DR: Build the shared documentation core once. The EU AI Act and NIST AI RMF need the same five things at their foundation, and the same records give Texas TRAIGA's internal-review defense something to stand on. Add framework-specific sections on top. The master table of contents is at the bottom of this article.

The problem with treating each framework separately

Organizations that have EU customers, US operations in Texas, or employees in states with AI employment laws are facing three overlapping compliance frameworks, each with its own documentation requirements. Most published guidance treats them in isolation. A consultant hired for EU AI Act compliance builds Annex IV technical documentation. A separate engagement for NIST AI RMF builds a risk register and playbook. The Texas team starts fresh with a TRAIGA memo.

The result is three partially overlapping documentation sets, maintained by different teams, telling slightly different stories about the same AI tools. Auditors and regulators are not impressed. Internal teams spend time reconciling documents that should never have been separate.

The better approach: identify the overlapping core requirements, build documentation that satisfies all of them once, and add framework-specific sections where the requirements actually diverge. This is not a shortcut; it is the architecturally correct way to build a compliance documentation program for an organization operating across multiple AI governance frameworks.

The shared core: what the frameworks ask for

Much of the documentation across the EU AI Act and NIST AI RMF covers the same ground, and TRAIGA asks for far less than either. The five shared core components are:

1. AI tool inventory

Every framework requires you to know what AI systems you are using and in what context.

EU AI Act Article 11: Technical documentation must identify the AI system, its purpose, and its deployment context.
NIST AI RMF (Govern/Map functions): The "Map" function begins with categorizing AI systems by risk profile and intended use.
Texas TRAIGA: No inventory duty, but you need one to answer an Attorney General investigative demand, which can ask for each system's purpose, training data, inputs, outputs, metrics and limitations (Sec. 552.103(b)).

One inventory document, formatted to capture the fields required by each framework, satisfies all three. See AI tool register template for small teams for a base format to adapt.

2. Risk assessment for each AI tool

All three frameworks require documented risk assessment as the foundation for governance decisions.

EU AI Act Article 9: A risk management system including risk identification, evaluation, and mitigation measures.
NIST AI RMF (Measure function): Risk measurement processes, including identification of AI risks and their likelihood and severity.
Texas TRAIGA: No risk assessment duty. A recurring review that screens each system against the banned uses and logs findings supports the Section 552.105(e) defense.

A single risk assessment template, completed for each AI tool in your inventory, can be structured to capture the fields each framework expects. The EU AI Act version will include fundamental rights impact assessment fields for high-risk systems. The NIST version will include playbook cross-references and core function mapping. The TRAIGA version will include the prohibited AI use check (see below).

3. Human oversight procedures

All three frameworks require evidence that humans are involved in consequential AI decisions.

EU AI Act Article 14: High-risk AI systems must have human oversight measures. Deployers must assign oversight responsibility to individuals with the authority and ability to intervene.
NIST AI RMF (Manage function): The Manage function covers accountability, including human roles in overseeing AI outputs and the ability to override or correct AI decisions.
Texas TRAIGA: No human oversight duty for private companies. Keep this section for the EU AI Act and other state laws.

Document your oversight procedures once: who reviews AI outputs for which decisions, what override authority they have, how overrides are documented, and what escalation path exists when the AI output is disputed.

4. Incident log

All three frameworks require tracking of AI-related incidents and, in some cases, reporting to regulators or affected individuals.

EU AI Act Article 73: Serious incidents involving high-risk AI systems must be reported to market surveillance authorities. Deployers must maintain records.
NIST AI RMF (Manage function): Incident response and ongoing monitoring are part of the Manage function. Playbooks should address how AI incidents are identified, contained, and documented.
Texas TRAIGA: No incident response duty. But the Section 552.105(e) defense turns on violations you discover through feedback, testing or internal review, so an incident log that records how each problem surfaced is useful evidence.

A single incident log covering all AI systems, with fields for incident type, affected AI system, affected parties, response taken, and regulatory reporting status, covers all three frameworks. The EU-specific column tracks whether the incident met the threshold for Article 73 reporting.

5. Vendor and supply chain records

All three frameworks require documentation of AI vendor relationships.

EU AI Act Article 26: Deployers must obtain instructions for use from providers, review the provider's conformity documentation, and implement use within stated conditions.
NIST AI RMF (Map/Govern functions): The supply chain risk management components of the framework require identifying AI vendors and assessing the risk they contribute.
Texas TRAIGA: Vendor and customer records help with the defense for misuse of your system by another person (Sec. 552.105(e)(1)).

One vendor record per AI system: provider name, model or product version, date of last documentation review, data processing agreement status, any known limitations or restrictions from the provider's instructions for use.

Desk with organized paperwork representing compliance document management

Framework-specific additions

Once the shared core exists, the framework-specific additions are relatively contained.

EU AI Act additions

If any of your AI systems are classified as high-risk under Annex III of the EU AI Act, you need:

Annex IV technical documentation: A structured document covering the AI system's purpose, development methodology, training data, performance metrics, and monitoring procedures. This goes beyond what NIST or TRAIGA require in specificity.
Article 50 transparency notices: Written user notices required for chatbots and other AI systems that interact with individuals in ways that could be mistaken for human communication. These are brief, user-facing documents, not internal governance records.
Fundamental rights impact assessment (FRIA): For deployers of high-risk AI systems, an assessment of the potential impact on fundamental rights. This includes reviewing the AI system's potential to produce discriminatory outcomes, privacy harms, and limitations on access to services.

For limited-risk AI systems (like chatbots covered by Article 50 disclosure requirements), the main EU-specific addition is the transparency notice itself, not the full Annex IV package.

See EU AI Act deployer evidence gaps SME August 2026 for common gaps in EU AI Act deployer documentation.

NIST AI RMF additions

If you are using NIST AI RMF as the primary framework (and pairing it with the Generative AI Profile for the Texas TRAIGA defense), structure your documentation with explicit NIST core function mapping:

Govern: Add a governance policy document describing your organization's AI governance structure, roles, and accountability framework. The shared core covers many Govern requirements, but a standalone governance policy with executive sign-off is standard for NIST compliance programs.
Map: Add a context characterization for each AI system, documenting the organizational context, user population, and potential impacts. This is the "why are we using this AI and for whom" document.
Measure: Add a risk measurement playbook describing the methods you use to evaluate and test AI risk. For each AI system, this includes testing procedures, metrics tracked, and thresholds for escalation.
Manage: Add explicit playbook cross-references in your risk assessment and incident response documentation so auditors can trace each risk management action to its NIST function.

See the Texas TRAIGA safe harbor guide for the review records the Texas defense depends on. TRAIGA itself doesn't require any NIST documentation.

Texas TRAIGA additions

TRAIGA has no documentation requirement as such. Two records still earn their place:

Banned use screen: TRAIGA bans AI that intentionally aims to incite self-harm, harm to others or crime; AI built with the sole intent to infringe constitutional rights; AI used with intent to unlawfully discriminate; and AI built with the sole intent to produce sexual deepfakes or child sexual abuse material (Secs. 552.052-552.057). Social scoring and biometric identification bans apply only to government entities. A dated screen per system, reviewed by counsel, shows you checked.
Internal review and findings record: The Section 552.105(e) defense covers violations you discover through an internal review while substantially complying with NIST's Generative AI Profile or another recognized framework. Keep review dates, what each review found, what you changed, and the cure statement template Section 552.104(b)(2) describes.

The master document table of contents

Copy this structure as the starting point for your master AI governance documentation set. Each numbered section maps to at least one shared core requirement plus framework-specific needs. Framework tags in brackets indicate which framework specifically requires that section: [ALL] means all three, [EU] means EU AI Act only, [NIST] means NIST AI RMF only, [TX] means Texas TRAIGA only.

AI Governance Master Documentation [Organization Name] | Version: [X.X] | Last reviewed: [Date]

PART 1: GOVERNANCE STRUCTURE [ALL] 1.1 AI governance policy (executive-approved) 1.2 AI governance roles and responsibilities matrix 1.3 AI governance review calendar

PART 2: AI SYSTEM INVENTORY [ALL] 2.1 AI system registry (master list) 2.2 Per-system context characterization sheets [NIST/MAP] 2.3 Risk tier classification for each system [EU/Art.9, NIST/Measure, TX] 2.4 Prohibited use compliance check [TX]

PART 3: RISK ASSESSMENTS [ALL] 3.1 Risk assessment methodology 3.2 Per-system risk assessment records 3.3 Fundamental rights impact assessment (high-risk systems) [EU/Art.9A] 3.4 Risk measurement playbook and metrics [NIST/Measure]

PART 4: HUMAN OVERSIGHT PROCEDURES [ALL] 4.1 Oversight role assignments per AI system 4.2 Override and escalation procedures 4.3 Training records for AI oversight staff 4.4 Override event log

PART 5: INCIDENT RESPONSE AND LOG [ALL] 5.1 AI incident response plan 5.2 Incident log (rolling) 5.3 Serious incident report tracker [EU/Art.73] 5.4 Post-incident review records

PART 6: VENDOR AND SUPPLY CHAIN RECORDS [ALL] 6.1 Vendor registry with documentation status 6.2 Data processing agreements (DPA) index [EU/Art.26, GDPR/Art.28] 6.3 Provider instructions-for-use records [EU/Art.26] 6.4 Vendor change notification log

PART 7: EU AI ACT SPECIFIC [EU] 7.1 Annex IV technical documentation (per high-risk system) 7.2 Article 50 transparency notices (per user-facing AI system) 7.3 EU market surveillance authority contact register

PART 8: NIST AI RMF SPECIFIC [NIST] 8.1 NIST AI RMF core function mapping table 8.2 AI RMF playbook cross-references by system 8.3 Govern function evidence (meeting records, policy sign-offs)

PART 9: TEXAS TRAIGA SPECIFIC [TX] 9.1 Internal review and findings record (framework named, review dates, findings, fixes) 9.2 Banned use screen per system (signed) 9.3 Cure statement template and investigative demand answer pack

Requirement-by-requirement mapping: one document, three frameworks

The table below maps each shared documentation artifact to the specific article, function, or requirement in each framework. Use this when an auditor or regulator asks which document satisfies a specific requirement.

Document	EU AI Act	NIST AI RMF	Texas TRAIGA
AI system registry	Article 11 (technical documentation basis); Article 49 (registration in EU database for high-risk)	Govern 1.1 (policies and accountability); Map 1.1 (context is established)	Not required; supports answers to an investigative demand (Sec. 552.103(b))
Risk assessment per system	Article 9 (risk management system); Annex IV point 2 (intended purpose and risk)	Measure 2.1 (AI risks identified and evaluated); Map 2.1 (scientific and established methods for risk identification)	Banned use screen; internal review findings for the Sec. 552.105(e) defense
Fundamental rights impact	Article 27 (FRIA for deployers in public services, education, employment)	Not required, but Govern 6.1 (policies for human rights impacts) is analogous	Not required
Human oversight procedures	Article 14 (human oversight measures documented); Article 26 (deployer implements oversight per provider instructions)	Manage 4.2 (incident response includes human escalation); Govern 4.1 (oversight roles defined)	Not required
Incident log	Article 73 (serious incident reporting records must be kept); Article 12 (logging obligation for high-risk systems)	Manage 2.4 (events documented in incident log); Manage 3.1 (responses to AI risks)	Not required; records how violations were discovered (Sec. 552.105(e)(2))
Vendor / DPA index	Article 26 (instructions for use and conformity documentation from provider); GDPR Article 28 (DPA with processors)	Map 5.1 (AI supply chain risks identified); Govern 6.2 (vendor risk management policies)	Not required; supports the misuse-by-another-person defense (Sec. 552.105(e)(1))
Acceptable use policy	Article 13 (transparency to deployers and users); Article 50 (transparency to affected persons)	Govern 1.2 (accountability for AI decisions); Govern 2.2 (internal accountability policies)	Not required; should name the banned uses
Training records for oversight staff	Article 4 (AI literacy, deployers must ensure staff have sufficient AI knowledge); Article 26(6) deployer obligations	Govern 5.2 (organizational teams committed to AI risk management); Govern 5.1 (roles defined)	Not required
Post-incident review	Article 73 (follow-up notification after serious incident); Article 12 (logging for post-incident analysis)	Manage 3.2 (identified risks incorporated into governance); Manage 4.1 (response and recovery applied)	Cure statement: cure, supporting documentation, policy changes (Sec. 552.104(b)(2))

Three cells that auditors always check first:

EU AI Act Article 73: Your incident log must show that for each serious incident, a notification was sent to the relevant national market surveillance authority within 15 days (or immediately for life-threatening events). The log entry should include the notification date and reference number.
NIST AI RMF Govern 1.1: This function requires documented accountability, specifically, named individuals responsible for each AI system and their authority to intervene. A risk assessment without named owners does not satisfy this function.
Texas TRAIGA internal review: The defense covers violations your review discovers, so the record needs findings with dates, not only proof that the review exists. The law doesn't define "substantially complies," and the Attorney General hasn't published guidance on it. Part 9 above is where that record lives.

How to implement this without a large team

For small and mid-size organizations, the full master document table of contents can look daunting. Here is how to sequence implementation:

Week 1-2: Complete Part 2 (AI system inventory). You cannot do anything else without knowing what AI systems you have and how they are classified.

Week 3-4: Complete Part 6 (vendor records). Pull your DPAs and vendor contracts. This surfaces gaps quickly.

Week 5-8: Complete Part 3 (risk assessments) for each AI system. Start with your highest-risk systems.

Week 9-10: Complete Part 4 (human oversight procedures) and Part 5 (incident response). These are process documents, not research projects.

Week 11-12: Add framework-specific sections. If you have EU customers, add Part 7. If you operate in Texas, flesh out Part 8 and complete Part 9.

Ongoing: Update Part 2 when new AI tools are adopted, update Part 5 on a rolling basis, review the rest annually or after major system changes.

For the AI system inventory format, start with the AI tool register template for small teams. For the broader governance program structure, see AI governance guide for small teams and the AI governance checklist 2026.

Correction (October 20, 2026): Earlier versions said TRAIGA gives a safe harbor for substantial compliance with NIST AI RMF 1.0, requires a governance program with inventory, risk, human oversight, incident and vendor elements, bans real-time biometric surveillance and social scoring for everyone, and that 60-70% of its documentation overlaps with the other frameworks. HB 149 has no governance program or documentation duty; the social scoring and biometric bans apply to government entities; and its defense names NIST's Generative AI Profile or another recognized framework, for violations found through internal review (enrolled text). We also corrected the fundamental rights impact assessment citation to Article 27.

For Texas TRAIGA requirements and the NIST safe harbor specifics, see Texas TRAIGA safe harbor NIST AI RMF checklist. For how NIST AI RMF compares to ISO 42001 for smaller organizations, see ISO 42001 vs NIST AI RMF for small teams. For common gaps in EU AI Act deployer documentation that auditors actually look for, see EU AI Act deployer evidence gaps SME August 2026. For the full EU AI Act compliance guide, see EU AI Act compliance guide for small teams. For Annex IV documentation specifics, see EU AI Act high-risk AI documentation templates August 2026. For Colorado's upcoming AI framework that may also require documentation overlap, see Colorado AI Act SB 189 2027 employer guide. The AI governance checklist 2026 covers the full governance program.