Texas HB 149 vs EU AI Act: A CTO's Engineering Compliance Playbook

This article is an engineering and governance analysis, not legal advice. Legal applicability and interpretation should be reviewed with qualified counsel.

The Engineering Problem Underneath Two Different Laws

Production AI does not stand still after a compliance checklist is completed. The model changes. A vendor replaces an underlying model. Retrieval data changes. A prompt changes. An engineer adds another tool. Someone increases an autonomy setting. A team begins using the same system for a use case that was never part of the original review.

The application that legal approved six months ago may no longer be the application running today.

That is why engineering leaders should approach laws such as the Texas Responsible Artificial Intelligence Governance Act, or TRAIGA, enacted through Texas HB 149, and the EU AI Act as specifications that eventually have to meet a running system. Not as two collections of forms.

Both laws, despite their structural differences, ultimately require the same engineering capabilities: know what AI you deployed, why it is allowed to operate, what changed, what evidence exists, and whether the system is still behaving inside its approved boundaries. For a broader framework on production AI governance, see seven layers of AI compliance.

Where the Laws Actually Stand in August 2026

Texas HB 149 took effect on January 1, 2026. TRAIGA applies broadly to persons who conduct business in Texas, provide products or services used by Texas residents, or develop or deploy AI systems in the state. (Texas Legislature Online)

The EU AI Act has followed a phased implementation. Prohibited practices and AI-literacy provisions began applying in February 2025. Governance rules and obligations for providers of general-purpose AI models began applying in August 2025. Article 50 transparency requirements became applicable on August 2, 2026. (Digital Strategy in Europe)

The EU's July 2026 AI Omnibus changed the high-risk timeline. High-risk AI systems in areas such as employment, education, biometrics, and critical infrastructure are now scheduled for their high-risk requirements from December 2, 2027. High-risk systems embedded in regulated products have until August 2, 2028. (Digital Strategy in Europe)

An engineering team that believes the entire EU high-risk regime went live in August 2026 may build the wrong remediation plan. Urgency should come from what actually applies, not from a headline.

Texas and Europe Are Solving Different Regulatory Problems

Calling TRAIGA the Texas version of the EU AI Act is convenient and misleading. The EU AI Act creates a broad risk-based regulatory framework with four categories: prohibited uses, high-risk systems, systems subject to transparency obligations, and minimal or no-risk systems. (Digital Strategy in Europe)

TRAIGA does not create an equivalent general-purpose risk-tier system. Texas instead combines broad applicability, specific prohibited uses, particular disclosure requirements, biometric provisions, anti-discrimination rules, government-specific restrictions, an Attorney General enforcement mechanism, a cure process, and liability protections tied in part to testing and recognized risk-management frameworks.

The first mistake in a compliance architecture would be trying to force Texas systems into an EU-style high-risk or low-risk classification and assuming the classification itself satisfies Texas law. It does not.

Texas HB 149 Is Narrower Than People Assume

TRAIGA's disclosure obligation illustrates how summaries can mislead. The law specifically requires a covered governmental agency making an AI system available to interact with consumers to disclose that the consumer is interacting with AI. It also establishes disclosure requirements when AI is used in connection with covered healthcare services or treatment. (Texas Legislature Online)

That is materially different from a universal commercial chatbot disclosure requirement. The EU transparency regime is broader in different directions. As of August 2, 2026, Article 50 includes obligations around certain direct AI interactions and AI-generated or manipulated content. (Digital Strategy in Europe)

TRAIGA also does not prohibit AI bias in the abstract. The statute prohibits developing or deploying an AI system with the intent to unlawfully discriminate against a protected class. Disparate impact alone is not sufficient by itself to demonstrate intent. (Texas Legislature Online) An engineering dashboard claiming a fairness metric outside threshold equals a TRAIGA violation would be inventing a legal standard the statute does not contain.

The 60-Day Cure Period Makes Auditability Strategically Valuable

TRAIGA's cure process is one of its most operationally important provisions. If the Texas Attorney General determines that a person has violated the law, the AG must provide written notice. The AG generally may not bring an action before the 60th day after that notice. If the organization cures the violation, it must provide a written statement, supporting documentation, and information about changes made to internal policies to prevent recurrence. (Texas Legislature Online)

Read those requirements from an engineering perspective: identify the violation, remediate it, produce supporting documentation, change internal controls, and demonstrate how recurrence will be prevented. That is an incident-response workflow.

Sixty days is generous only if you already know which system is implicated, who owns it, what version is deployed, which model is running, what data it uses, what controls were active, what changed, and how to reproduce the behavior. If your organization has to discover all of that after receiving the notice, much of the 60-day window will be spent reconstructing its own architecture.

When investigating a complaint, the Texas AG may request information including the AI system's purpose, deployment context, training data, input categories, outputs, performance metrics, known limitations, post-deployment monitoring, user safeguards, and oversight processes. (Texas Legislature Online) That is close to a specification for the minimum AI system record you should maintain internally.

Texas Enforcement and Penalties

TRAIGA gives the Texas Attorney General primary enforcement authority and does not create a private right of action. For uncured violations, the law provides different civil-penalty ranges: $10,000 to $12,000 for each violation a court determines to be curable, $80,000 to $200,000 for each violation determined to be uncurable, and $2,000 to $40,000 per day for a continuing violation. The AG can also seek injunctive relief and recover specified costs. (Texas Legislature Online)

The EU AI Act's penalty structure is on a different scale: up to 35 million EUR or 7% of worldwide annual turnover for certain prohibited-practice violations, up to 15 million EUR or 3% for a range of other obligations, and up to 7.5 million EUR or 1% for supplying incorrect or misleading information to authorities. Lower comparative thresholds apply to SMEs. (Digital Strategy in Europe)

The numbers differ. The architectural lesson does not. Evidence matters.

consider two companies receive a Texas notice on the same day. Company A has no AI inventory, shared API keys, unversioned prompts, unknown model revisions, no deployment evidence, no red-team history, and no owner map. Company B has a system inventory, deployment history, versioned control results, known owners, model lineage, evaluation history, a change log, and documented monitoring. Both receive the same statutory period. They do not have the same amount of time. Company B spends its time correcting the problem. Company A spends its time discovering what exists. Compliance engineering converts regulatory response from archaeology into incident management.

NIST Gives Texas Organizations Something Concrete

TRAIGA contains an important connection to the NIST Artificial Intelligence Risk Management Framework: Generative AI Profile. The law's liability section addresses situations in which a defendant discovers a violation through mechanisms including feedback, adversarial or red-team testing, or an internal review process associated with substantial compliance with the current NIST Generative AI Profile or another nationally or internationally recognized AI risk-management framework. (Texas Legislature Online)

Substantial compliance with NIST does not mean every action your company takes is automatically TRAIGA-compliant. The statutory protection is more specific and should be interpreted with counsel. But Texas has explicitly connected recognized AI-risk-management practices, internal review, and testing to its liability framework. That is a significant engineering signal.

NIST does not describe the AI RMF as a checklist. The framework is organized around four functions: GOVERN, MAP, MEASURE, and MANAGE. NIST explicitly says the activities are not necessarily sequential checklist steps. Risk management is intended to be continuous across the AI lifecycle. (NIST AI Resource Center)

That makes it more useful for engineering. GOVERN defines who owns the system and which policies apply. MAP documents what the system does and who is affected. MEASURE evaluates whether identified risks are materializing. MANAGE determines which controls are required and what happens when they fail. For a deeper operational framework, see the HAIEC modular governance framework.

The EU AI Act Asks for a More Formal Lifecycle

When the relevant high-risk requirements begin applying under the updated timeline, providers of covered high-risk systems face a considerably more prescriptive structure. The Commission summarizes requirements including risk assessment and mitigation, data-quality requirements, activity logging, technical documentation, information for deployers, human oversight, robustness, cybersecurity, and accuracy. (Digital Strategy in Europe)

Providers must retain certain technical documentation for ten years, and automatically generated logs under their control must generally be kept for at least six months unless other applicable law provides differently. (EUR-Lex) The Regulation also requires providers to establish and document post-market monitoring designed to collect and analyze performance information across the system's lifetime so continued compliance can be evaluated.

Those are not merely policy-writing requirements. They create system-design consequences: logging architecture, retention policies, documentation pipelines, and monitoring systems must all be built to satisfy these obligations.

The Inventory Is the Foundation

Before building an AI compliance CI/CD gate, build an AI inventory. A minimal system record should be machine-readable, versioned, and attributable:

system_id: customer-support-assistant
owner:
  business: customer_operations
  technical: platform_ai
jurisdictions:
  - texas
  - european_union
role:
  texas:
    deployer: true
    developer: false
  eu:
    provider: false
    deployer: true
purpose:
  approved:
    - answer_customer_questions
    - retrieve_order_status
prohibited_use:
  - autonomous_credit_decision
  - employment_screening
model:
  provider: example-provider
  model_id: model-x
  revision: "2026-07-21"
data:
  personal_data: true
  biometric_data: false
  retrieval_sources:
    - approved_support_kb
human_oversight:
  escalation_required: true
monitoring:
  latency: enabled
  safety_evaluations: enabled
  output_sampling: enabled
evidence:
  risk_review_id: RR-2026-184
  deployment_id: DEP-8371

If the organization cannot answer which AI systems are currently affecting Texans or EU users, the rest of the compliance program is operating on assumptions. For production readiness fundamentals, see 12 production readiness checks for AI pilots.

Compliance Becomes Architecture: Moving Governance Into the Deployment Path

Most companies add AI governance alongside their CI/CD pipeline as a separate process. Legal writes a PDF. Engineering deploys code. The two systems barely interact.

             AI SYSTEM RECORD
                    |
                    v
CODE --> BUILD --> CONTROL EVALUATION
                    |
                    +--> Security tests
                    +--> Risk tests
                    +--> Disclosure requirements
                    +--> Human-oversight controls
                    +--> Model/version checks
                    +--> Jurisdiction rules
                    +--> Evidence generation
                    |
                    v
               RELEASE GATE
               /          \
            PASS          FAIL
             |              |
             v              v
          DEPLOY        REMEDIATE
             |
             v
      POST-DEPLOY MONITORING
             |
             v
       VERSIONED EVIDENCE

Neither TRAIGA nor the EU AI Act mandates this exact CI/CD architecture. The benefit is that legal requirements stop existing only as prose. They become testable conditions in the deployment path.

Deterministic Gates vs Legal Judgments

Some compliance questions can become deterministic gates. Suppose a healthcare AI service in Texas requires a disclosure before the relevant service is provided. A deployment can fail if healthcare_ai = true and disclosure_enabled = false. That is deterministic. No language model needs to decide whether it feels compliant.

But not every legal question should become a Boolean. Texas's prohibition on intentionally using AI to unlawfully discrimination cannot be reduced to if fairness_score > 0.91: traiga_compliant = True. Instead, the system can verify that required governance steps were performed: approved use case, protected class review completed, fairness evaluation completed, legal review approved, model version tested. The tool proves the workflow happened. It does not pretend the mathematical test conclusively answered the legal question.

The Right Unit of Automation Is the Control, Not the Law

Instead of one giant EU_AI_ACT = PASS or TRAIGA = 92% without being able to explain the denominator, the architecture should trace a chain:

Law
  |
  v
Requirement
  |
  v
Applicability decision
  |
  v
Control
  |
  v
Technical check
  |
  v
Evidence

For example: EU Article 50, then AI-interaction transparency applies, then UI disclosure required, then disclosure test, then PASS, then screenshot plus test result plus build hash. The compliance conclusion remains a governance decision. The technical result becomes reproducible.

A deterministic gate for a healthcare AI disclosure in Texas might look like:

control_id: TX-AI-DISCLOSURE-HEALTHCARE

applies_when:
  jurisdiction: texas
  healthcare_ai: true

require:
  disclosure_enabled: true
  disclosure_version: approved
  disclosure_event_test: passed

Now a deployment fails if healthcare_ai = true and disclosure_enabled = false. No language model needs to decide whether it feels compliant. A lawyer or governance owner determines the rule. The pipeline verifies whether the agreed technical condition exists.

The Deployment Gate I Would Build

def evaluate_release(system, deployment, controls):
    failures = []
    if not system.owner:
        failures.append('AI system owner missing')
    if not deployment.model_revision:
        failures.append('Model revision not recorded')
    for control in controls.required_for(system):
        result = control.evaluate(system=system, deployment=deployment)
        evidence.store(result)
        if result.blocking and not result.passed:
            failures.append(control.id)
    if failures:
        return {'decision': 'BLOCK', 'reasons': failures}
    return {'decision': 'ALLOW', 'evidence_id': evidence.bundle_id}

The release decision and the evidence supporting it should be generated from the same control execution. Not reconstructed months later.

Do Not Let Compliance Automation Blindly Stop Deployment

A governance gate that can block production becomes a production dependency. It needs its own availability design, versioning, rollback, exception process, separation of duties, change approval, and audit history. Suppose a compliance rule is incorrectly configured and blocks every production deployment on Friday afternoon. You now have a governance incident.

An exception should not mean turning compliance off. It should mean: named owner, reason, approver, scope, expiration, and compensating control. That is how ordinary enterprise change management already works. AI governance does not need to reinvent it.

Where AI Can Still Help

None of this means compliance engineering should avoid AI. AI can classify systems for review, summarize regulatory changes, suggest likely control mappings, analyze policy documents, help investigators search logs, identify missing evidence, generate test cases, and assist with red-team exploration.

But three responsibilities should remain distinct: AI assists interpretation, deterministic system enforces approved control, and qualified human owns legal conclusion. Conflating them is how a compliance assistant quietly becomes a compliance authority.

Drift Detection: Configuration Before Statistics

At least four things can drift: model drift (provider version changes), data drift (input distribution changes), behavior drift (outputs change under same evaluation), and configuration drift (prompts, tools, retrieval sources, safety controls change).

For many LLM applications, the highest-value monitoring does not require a sophisticated ML drift algorithm. Start with configuration drift:

Yesterday:
model = x-2026-07
prompt_hash = A84...
retrieval_index = v12
tools = [search, booking]
temperature = 0.2

Today:
model = x-2026-08
prompt_hash = 9BC...
retrieval_index = v13
tools = [search, booking, refund]
temperature = 0.7

That is a material change detected deterministically. A deployment gate can require rerunning evaluations when configuration changes. In the EU high-risk framework, post-market monitoring must actively and systematically collect and analyze performance data across the system's lifetime. (EUR-Lex) Drift detection supports that process. It is not synonymous with it.

Evidence Should Be Generated When the System Changes

A common compliance architecture produces evidence once per audit. That is backwards for software. Most meaningful evidence is easiest to produce when the change happens. At deployment time, capture: system identifier, application version, model provider and revision, prompt and configuration version, tool and retrieval configuration, control-set version, test results, required disclosures, approval identities, deployment timestamp, artifact hashes, exceptions, and known limitations.

A stronger evidence artifact tells you: control ID, result, system, deployment, commit hash, model version, rule version, test file, timestamp, executor, and artifact hash. The question becomes answerable precisely: this exact deployment passed this exact version of the control at this time. That is the difference between documentation and provenance.

The Board Does Not Need Another AI Risk Score

Most AI governance dashboards present a single composite score: AI Governance Score: 87. That number does not tell a board member anything useful. It does not tell a CTO what to fix. It does not tell an auditor what was checked. It does not tell a regulator what evidence exists.

A stronger dashboard answers specific questions: Which systems are deployed in Texas? Which have completed disclosure tests? Which have pending exceptions? Which have unresolved drift alerts? Which have overdue evaluations? Which have missing owners? Which have model changes since last approval?

The composite score is a communication artifact. The specific answers are an operating artifact. Boards need both. Engineering teams need the second one.

Not Every Model Update Should Be Treated Equally

A model version change from x-2026-07 to x-2026-08 might be a patch release with no behavioral change or a major release with new capabilities. A prompt change might add a clarification or remove a safety instruction. A retrieval index update might add new documents or remove a critical policy document.

change_classification:
  model:
    patch: rerun_safety_eval
    minor: rerun_safety_eval + fairness_eval
    major: full_reapproval
  prompt:
    cosmetic: log_only
    behavioral: rerun_eval
    safety_control_removed: full_reapproval
  retrieval:
    add_documents: log_only
    remove_documents: rerun_eval
    policy_change: full_reapproval

The point is not the exact classification. The point is that a deployment gate should treat material changes differently from cosmetic ones. A blanket rule that blocks every change creates noise. A blanket rule that allows every change creates risk. The classification itself should be governed and versioned.

A Practical 10-Control Starting Set

1. AI inventory completeness: Every production AI system has owner, purpose, jurisdiction, model, data classes, deployment context.
2. Role classification: For each jurisdiction, determine developer, provider, deployer, government entity, or healthcare provider status.
3. Approved-use boundary: The system has explicitly allowed and prohibited uses.
4. Model provenance: Record provider, model, and version.
5. Material-change detection: Detect changes to models, prompts, tools, retrieval, or safety configuration.
6. Required disclosure test: Where applicable, verify actual user-facing behavior.
7. Evaluation evidence: Required safety and performance tests execute before deployment.
8. Human oversight: Where a workflow requires human control, prove the control exists.
9. Post-deployment monitoring: Track metrics and limitations tied to the system's risk profile.
10. Incident and remediation history: When a control fails, record what happened, what changed, who approved it, and what proves remediation.

These ten controls will not make an organization automatically compliant. They will make it substantially easier to operate a serious compliance program. For immutable audit trail patterns, see implementing immutable audit trails for SOC 2 AI compliance.

A Cross-Jurisdictional Control Architecture

Organizations operating in both Texas and the EU should not build two separate compliance programs. They should build one control layer with jurisdiction-specific applicability rules.

     SHARED AI SYSTEM RECORD
              |
              v
     SHARED CONTROL LAYER
     /                    \
  TEXAS RULES          EU RULES
     |                    |
  TX disclosure       EU transparency
  TX cure process     EU high-risk
  TX AG inquiry       EU post-market
     |                    |
     +--------+-----------+
              |
              v
     SHARED EVIDENCE STORE
              |
              v
     JURISDICTION-SPECIFIC
     REPORTING OUTPUTS

The controls are shared. The applicability decisions differ. The evidence is shared. The reporting outputs differ. This avoids duplicating engineering work while respecting that the legal requirements are not identical.

What Changes Between Texas and Europe

Both jurisdictions ultimately require you to know what AI you operate, why it is permitted, what changed, and what evidence exists. The emphasis differs:

NIST can become the common operational language. TRAIGA explicitly references the NIST Generative AI Profile. The EU AI Act references risk management systems and conformity assessment but does not mandate NIST specifically. An organization that builds its control architecture around NIST GOVERN, MAP, MEASURE, and MANAGE can map those controls to both Texas and EU requirements without maintaining two separate frameworks.

Compliance Becomes More Difficult When AI Becomes Agentic

Most current AI compliance assumes a relatively static system: one model, one prompt, one retrieval source, one deployment. Agentic AI systems break that assumption. An agent might call multiple models, use different tools depending on context, modify its own prompts, select retrieval sources dynamically, and chain calls in ways that were not explicitly designed.

The compliance question shifts from did we approve this system? to is this system still operating within its approved boundaries? That requires runtime monitoring, not just deployment-time gates. The system graph, not the spreadsheet, becomes the compliance artifact.

The Future Compliance Artifact Is a Deployment Graph

When an auditor asks show me the evidence for system X on date Y, the answer should not require reconstructing a year of Slack messages and Jira tickets. The answer should be a query against a deployment graph: system, version, model, controls, results, evidence, exceptions, approvals, and timeline.

That graph is built incrementally. Every deployment adds nodes. Every control execution adds edges. Every exception adds metadata. The graph becomes the living compliance record. The audit becomes a traversal.

My Test for Whether an AI Control Belongs in CI/CD

1. Can the condition be evaluated deterministically from system configuration, deployment metadata, or test results?
2. Does failing the condition create a real compliance or safety risk, not just a documentation gap?
3. Can the check be versioned, reviewed, and rolled back like any other code change?
4. Can an exception be granted with named owner, reason, approver, scope, and expiration?
5. Does the check produce evidence that an auditor or regulator would accept?

If the answer to all five is yes, the control belongs in the deployment gate. If not, it belongs in a governance workflow that feeds into the gate but does not block it directly.

The Real Difference Between a Policy Program and a Compliance System

A policy program says: We have a policy that requires AI risk assessment before deployment. A compliance system says: Deployment DEP-8371 passed control TX-AI-DISCLOSURE-HEALTHCARE v3.2 at 2026-08-08T14:03:22Z, evidence stored as EV-4471, approved by j.smith, model revision x-2026-08, no active exceptions.

The first statement is necessary. The second statement is what an auditor, a regulator, and a court will actually ask for.

The 90-Day CTO Playbook

Days 1-30: Know what exists. Build the inventory. For every production AI system, identify owner, use, geography, role, model and provider, affected people, data, autonomy, integrations, and existing controls. Do not begin by buying a compliance dashboard. Begin by establishing ground truth.

Days 31-60: Map obligations to controls. Work with legal, security, and product to create the chain: Requirement, then Applicability, then Control, then Owner, then Evidence. Start with currently applicable requirements and the highest-risk use cases.

Days 61-90: Move controls into engineering. Add model and configuration versioning, deployment-linked evaluations, disclosure tests, change detection, approval gates, exceptions, evidence generation, and post-deployment alerts.

The result after 90 days will not be finished compliance. That is the wrong target. The result should be a system that makes continued compliance easier to operate.

The Strongest Compliance Architecture

Texas HB 149 and the EU AI Act are not two versions of the same law. TRAIGA is comparatively targeted: specific duties, prohibited practices, AG enforcement, a defined cure process, and an unusual connection between testing and recognized AI risk-management frameworks. The EU AI Act is broader lifecycle regulation with a formal risk-based structure, transparency rules already applicable, GPAI obligations underway, and a high-risk regime whose major technical requirements now arrive later under the 2026 AI Omnibus.

Strip away the legal vocabulary and look at both from the system architecture layer. The questions converge: What AI do we operate? Why is this use permitted? Which model and configuration are actually deployed? Which requirements apply? Which controls enforce them? What changed? Did the required tests run? What happened after deployment? Can we reproduce the evidence? Who approved the exceptions?

Those questions cannot be answered reliably by an annual spreadsheet. They have to become part of the engineering lifecycle. The strongest AI compliance architecture is not the one with the longest checklist. It is the one that can connect a legal requirement to a technical control, a technical control to a specific deployment, and that deployment to evidence you can still reproduce when somebody finally asks for it.

If you are operating AI systems across Texas and EU jurisdictions and need an independent systems advisor to audit your compliance architecture, schedule a strategic evaluation.