The Texas Responsible AI Governance Act took effect on January 1, 2026. It is, as state AI bills go, narrowly written — but the part that matters for caregiving software, and for any product that touches the doctor-patient encounter, is in the disclosure provisions. Licensed healthcare professionals practicing in Texas now have to give patients a written, visible disclosure about any use of artificial intelligence in their diagnosis or treatment. Not a buried checkbox. Not a clause in the new-patient packet. A meaningful, plain-language statement the patient can read and ask questions about, at the moment the AI is being used.
The bill is not the first state-level AI healthcare regulation — Colorado, California, and Illinois have all moved in similar directions over the past eighteen months — but TRAIGA is the cleanest example so far of what the post-2025 default is going to look like. The federal floor is coming next. HHS Office for Civil Rights guidance on AI and protected health information is expected mid-to-late 2026, and the FDA's evolving framework for AI-enabled medical devices is tightening in parallel. The direction is consistent across all of them: if AI is making or shaping a clinical decision, the patient has a right to know, in language they understand, and the institution using the AI has to be able to account for what the AI did.
Most software in our category is not designed for that world. We think it should be.
What "meaningful disclosure" actually requires
The phrase shows up across several of the recent rules without a single canonical definition, but the operational requirements that keep emerging are roughly four:
1. The patient is told, in plain language, that AI is being used. Not "we may use technology to enhance your care." Not "our system uses machine learning." The patient needs to know specifically that a software model produced or shaped the diagnostic suggestion, treatment plan, summary, translation, or risk score that is in front of them.
2. The disclosure happens at the point of use, not in a privacy policy. A patient who signed a stack of forms three months ago has not been meaningfully informed about an AI-generated visit summary they received yesterday. Disclosure has to land near the artifact, every time, in the workflow.
3. The clinician retains responsibility for the clinical decision. The AI is not the prescriber, the diagnostician, or the care planner. Its output is a draft, a suggestion, or a translation — and the clinician (or in caregiving software, the family member acting on the information) has to be the named decision-maker. "Human in the loop" is not jargon; it is a regulatory expectation.
4. The institution can account for what the AI did. If a patient asks "what did the model recommend, and why?", there has to be an answer. That means logs, prompts, model identifiers, and an audit trail that survives the moment.
These four requirements are not satisfied by a one-line footer that says "AI-generated content may contain errors." They require designing the disclosure into the workflow, not bolting it on after.
How caregiving software typically fails the test
Most consumer-facing caregiving software that uses AI today does one of the following:
-
Buries the AI use in the privacy policy. The patient (or the family caregiver) signs up, AI happens, the only mention is in a 6,000-word terms document nobody reads. Doesn't pass disclosure.
-
Shows AI output without labeling it as AI. The visit summary appears in the workspace, looking like it was written by a human. The translation appears in the patient's language without a marker that it was machine-generated. The medication-interaction warning appears without indicating that a model produced the warning. Patient and family treat the output as authoritative because nothing tells them otherwise.
-
Defaults AI features to on with no per-feature granularity. The product ships with AI summarization, AI translation, AI lab analysis, AI risk scoring all enabled by default; the user can turn them off in settings if they find the toggle. The default exposure to AI is treated as the path of least resistance for the product, not the patient.
-
Sends content to AI vendors without a BAA. Patient health information moves to a third-party AI API under a standard consumer terms-of-service. Nothing in the product workflow flags this to the family.
A product can have one of these problems, or all four, and the patient experience looks the same until something goes wrong. The first time something goes wrong — a mistranslation that contributed to a missed medication, a hallucinated symptom in an AI summary, a lab "flag" that turned out to be model error — the disclosure question becomes the regulatory question. "Did the patient know AI was being used? Was the use of AI on by default or opt-in? Is there a log of what the model produced?" If the answers are no, on, no, the product has a problem larger than the original error.
What we built for
The four design choices in Kintaria's AI surface, made before TRAIGA passed but calibrated to the same bar:
AI is off by default. Every workspace starts with AI summarization, AI translation, AI document extraction, and AI medication scanning disabled. The workspace owner has to turn them on, per feature, in Settings → AI Features. Until they do, no workspace content goes to any AI service. The friction of opting in is, intentionally, the load-bearing piece of the consent model.
Per-feature opt-in, not all-or-nothing. A family that wants AI visit summaries but not AI medication scanning can have exactly that. The choices are independent because the risk profiles are independent — summarizing a visit is a different proposition from flagging a drug interaction.
Visible AI banners on every AI-touched surface. When an AI summary, translation, or extraction is displayed, the surface is labeled — AI preview, machine-translated from English, AI-extracted from this document — so the family knows what they're looking at. Every surface that touches AI also explicitly reminds the user to review the result before acting on it. The label is in the workflow, not the privacy policy.
Per-vendor accountability. Our public security page names every external service that touches workspace content, including AI vendors, and the BAA status for each. We are not currently a HIPAA covered entity (we're pre-launch and the framework is still being built), and we say so. We don't pretend the AI vendor relationships are different than what they are.
These four together pass the TRAIGA disclosure test as we read it. They are also, we'd argue, the right way to build AI-enabled software for a context where the patient is on one side of the decision and the family is on the other.
What's coming next
Three pieces worth watching over the next six to twelve months:
The HHS-OCR HIPAA Security Rule updates expected late 2026. The proposed rule would require encryption of ePHI in transit and at rest (already standard at most current vendors), MFA for critical and remote systems, and explicit requirements for AI systems touching patient data — written inventories, continuous vulnerability monitoring, and accountability for AI-generated entries in the designated record set. Some analysts expect the current administration to tilt toward AI-innovation rather than new restriction, so timing may slip. But the direction is clear.
The patient-rights-to-explanation provisions percolating through state legislatures. If you've ever wondered why so many caregiving AI features include a "regenerate" button next to the AI output, it's partially because patient access to an explanation of how a model produced a particular output is increasingly an expected affordance. Regulators are starting to ask for it explicitly.
The Language Access for All Act and its AI-medical-interpretation provisions. The bill names AI translation in clinical settings as a regulated activity requiring accuracy benchmarks, quality monitoring, and documented human-in-the-loop pathways. If it advances in any form, every translation-enabled medical tool — caregiving software included — is going to have to defend its choices on those four axes.
What unites all three is the same shift TRAIGA already made in Texas: AI in healthcare is moving from "use it if you want, regulators will catch up later" to "you have to be able to account for it, in plain language, at the moment of use." The companies that built their products around that bar from the start will not have to redesign anything. The ones that didn't are going to have a year or two of catch-up work, and a window of regulatory exposure in the meantime.
Texas changed the default. The federal government has not yet, but it will. The right time to build for the disclosure-required, opt-in-required, accountable-AI world was about three years ago. The second-best time is now.