Skip to main content

Texas TDPSA: AI Data Privacy Compliance

Texas does not have a standalone AI law, but the Texas Data Privacy and Security Act changes how AI systems should be governed whenever they process personal data, sensitive data, or profiling outputs tied to people. The TDPSA took effect on July 1, 2024 and gives the Texas Attorney General a broad consumer privacy enforcement baseline that matters immediately for enterprise AI. The law's treatment of sensitive data, data protection assessments, and profiling with legal or similarly significant effects creates a practical governance problem for any team deploying copilots, assistants, or decision support routes at scale.

That problem shows up in the runtime path. A company may have a privacy program on paper, but the same shared AI route still handles support transcripts, account notes, employee records, and recommendation outputs with no differentiated controls. Keeptrusts helps by reducing unnecessary personal data before model calls, limiting provider selection to declared handling requirements, escalating higher-impact workflows for review, and preserving evidence that can support an internal assessment. It does not replace the TDPSA notice, rights-response, or assessment obligations themselves.

Use this page when​

  • You need a TDPSA-aligned technical control model for AI routes handling Texas consumer or employee data.
  • You are assessing profiling, recommendation, or support workflows that could have significant effects on individuals.
  • You want a precise way to connect privacy assessment work to live gateway behavior.

Primary audience​

  • Primary: Compliance officers, privacy leaders, platform engineers
  • Secondary: product counsel, security teams, AI governance leads

The problem​

TDPSA-sensitive AI governance usually fails because organizations flatten very different uses into one platform decision. They buy or approve an AI provider once, then route every use case through the same lane. That may work for generic drafting. It breaks down for workflows involving sensitive data or profiling.

The statute matters here because it explicitly raises the bar for certain processing activities. Sensitive data under the TDPSA includes categories such as precise geolocation, racial or ethnic origin, religious beliefs, mental or physical health diagnosis, sexuality, citizenship or immigration status, genetic data, biometric data processed for unique identification, and personal data collected from a known child. The law also requires data protection assessments for activities including the processing of sensitive data, sale of personal data, targeted advertising, and profiling that presents a reasonably foreseeable risk of unfair or deceptive treatment, financial or physical injury, reputational injury, or intrusion upon solitude.

AI systems hit those triggers faster than teams expect. A marketing assistant may infer interests for targeted advertising. A case-routing assistant may rank customer complaints. A workforce copilot may summarize health or accommodation information. A fraud assistant may rely on biometric or geolocation signals. When those routes all use one generic provider path, the business cannot show that privacy risk actually changed the live system design.

The biggest failure mode is not that the organization lacks a policy. It is that the runtime route quietly ignores it. Provider fallbacks remain open, sensitive content reaches upstream systems without minimization, and outputs that should have been reviewed are delivered directly. That is a weak position for any internal assessment and an even weaker position if the Attorney General asks how the system behaves in practice.

The solution​

The practical answer is to align the route with the assessment. If a TDPSA review says a route processes sensitive data or supports higher-impact profiling, the gateway should behave differently from a low-risk drafting assistant.

Keeptrusts gives you the right primitives for that split. Use pii-detector and route-specific custom patterns to minimize personal data at the request boundary. Use data-routing-policy to enforce provider requirements such as zero-data-retention, training opt-out, retention limits, tokenized-input support, and internet-egress restrictions. Use human-oversight when a route should not deliver a final answer without human review because it influences a material decision. Then preserve the route's behavior with audit-logger, event exports, and evidence handoff workflows.

This does not turn TDPSA compliance into a configuration-only exercise. You still need notices, request handling, vendor contracting, and formal assessment work. What Keeptrusts does is make the system's actual behavior match the declared risk posture. That is the part many privacy programs leave ambiguous.

Implementation​

For a Texas-sensitive AI route, the rollout discipline matters almost as much as the final policy. A narrow validation loop is the safest way to avoid shipping a route that looks compliant in YAML but falls back to the wrong provider at runtime.

kt policy lint --file texas-tdpsa-sensitive.yaml
kt gateway run --config texas-tdpsa-sensitive.yaml
curl -X POST "$KEEPTRUSTS_URL/v1/exports/jobs" \
  -H "Authorization: Bearer $KEEPTRUSTS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "format": "json",
    "time_window": {
      "start": "2026-05-31T00:00:00Z",
      "end": "2026-05-31T23:59:59Z"
    }
  }'

In practice, the policy file behind that command typically includes a strict routing lane for sensitive or high-impact traffic: pii-detector to remove obvious identifiers from request text, data-routing-policy with require_zero_data_retention: true and on_no_compliant_provider: block, and human-oversight for routes that should never make a straight-through recommendation. That pattern gives the assessment team something concrete to review. If a provider does not match the declared posture, the route blocks. If a workflow needs review, the answer escalates.

The export step matters because TDPSA assessments are easier when the evidence packet is tied to real runtime behavior. Instead of arguing from architecture diagrams alone, the team can attach a time-bounded evidence set showing which route ran, which controls applied, and whether an escalation occurred.

Results and impact​

Once organizations move to this model, the privacy conversation gets sharper. Teams can distinguish low-risk summarization from significant-effect decision support. Privacy leaders can challenge whether a route truly belongs in a direct-delivery lane. Engineers can explain exactly what happens if the approved provider set is unavailable.

That improves more than legal defensibility. It reduces operational drift. A route that starts life as a harmless assistant is less likely to become an unreviewed profiling engine because the gateway makes escalation and fail-closed routing visible. Over time, that is what turns privacy governance from an annual exercise into an operating discipline.

Key takeaways​

  • TDPSA matters for AI even without a separate Texas AI statute because sensitive-data and profiling obligations map directly onto live routes.
  • The right unit of control is the route, not the vendor contract alone.
  • data-routing-policy is the core enforcement layer for provider posture, and human-oversight is the right backstop for higher-impact uses.
  • Evidence exports make internal assessments more credible because they reflect real runtime behavior.
  • Notices, rights handling, and the assessment document still sit outside Keeptrusts and must be handled separately.

Next steps​