HIPAA is not the strictest rule your AI features answer to. Here is how 42 CFR Part 2 changes what behavioral health platforms can build.
Most healthcare software teams eventually get their arms around HIPAA. Far fewer have internalized 42 CFR Part 2, the federal confidentiality rule governing substance use disorder treatment records, and almost none have thought through what it means for their AI features. If your platform is used by addiction treatment programs, integrated behavioral health providers, or any organization that touches SUD treatment data, Part 2 is not optional reading. It imposes requirements stricter than HIPAA in ways that directly constrain how AI integrations can be architected.
Part 2 dates back to the 1970s and exists for a specific reason. People avoid addiction treatment when they fear their records will be used against them in custody disputes, employment decisions, criminal proceedings, or simply in how their community sees them. Congress decided the public health interest in people seeking treatment outweighed the normal flow of medical information, so SUD treatment records from federally assisted programs received extra protection. The core of that protection is consent. Where HIPAA permits broad disclosure for treatment, payment, and operations without patient authorization, Part 2 historically required specific written consent for most disclosures of SUD records, with each disclosure needing to fit what the patient actually agreed to. This distinction matters more in practice than it sounds on paper. A general medical record can move between a primary care provider, a specialist, and a billing department under HIPAA's normal treatment and operations exceptions, largely without the patient signing off on each individual transfer. An SUD treatment record historically could not move that freely, because Part 2 was built around the idea that patients should retain more control over exactly who sees evidence that they sought addiction treatment in the first place. That extra layer of control is precisely what an AI feature can undermine without anyone intending it to, simply by moving data through a pipeline that was designed with HIPAA's more permissive rules in mind.
A final rule effective April 16, 2024 brought Part 2 into closer alignment with HIPAA, notably allowing a single consent for future treatment, payment, and operations uses, and aligning enforcement and breach notification with HIPAA's framework. Full compliance with the updated rule was required by February 16, 2026, so this is a live rule, not a legacy one. Alignment is not equivalence, though. Consent remains the gate, redisclosure remains restricted, and the use of SUD records in legal proceedings against patients remains sharply limited. For software vendors, the practical takeaway is that SUD data is a distinct, higher protection class of data flowing through your systems, and your architecture needs to know which records those are.
AI integrations create four points of friction with Part 2 that do not exist, or exist less sharply, under HIPAA alone. Consent scope was not written with a model vendor in mind. Disclosures of Part 2 records generally have to trace back to patient consent. When a platform sends a therapy note containing SUD information to an LLM API for summarization, that is a disclosure to a third party. Whether the consent on file actually covers it depends on how that consent was drafted and how the AI processing is characterized. If nobody has asked the question yet, the honest status is unknown, and unknown is not a compliance posture. Segmentation: your AI has to know what it is touching. The single biggest architectural implication of Part 2 is data segmentation. If a platform serves integrated behavioral health providers, some records in the system are Part 2 protected and some are not. An AI feature that is fine for HIPAA only data may not be fine for the identical flow with SUD records mixed in. That means the AI layer needs record level awareness across summarization pipelines, retrieval systems, and any job generating embeddings. A vector search across all clinical notes that surfaces SUD content into a response for a user whose access was never consented is a Part 2 problem produced by an architecture that never considered the distinction. Redisclosure travels with the data, including into AI outputs. Part 2 restricts redisclosure of protected records by recipients. When an AI generates output derived from SUD records, a summary, a letter, a care coordination note, that output can carry Part 2 protected information into new contexts. Output surfaces need the same segmentation awareness as inputs, or a generated artifact quietly inherits sensitivity nothing in the product tracks or labels. Vendor chains need more than a BAA. Under the updated rules, agreements analogous to BAAs cover Part 2 relationships, but the substance still has to reflect Part 2's own restrictions, particularly around redisclosure and use limitations. An AI vendor relationship that is adequately papered for HIPAA is not automatically adequate for SUD records.
Five questions define the work for teams building or already running AI features on platforms that touch SUD data. Can the system identify Part 2 protected records programmatically, at the record or field level? Do the AI data flows respect that flag, excluding, gating, or specially handling protected content? Do the consents customers collect plausibly cover the AI processing the product performs, and can that processing be described clearly enough for customers to make the call themselves? Do vendor agreements address Part 2 data specifically? And do generated outputs preserve, rather than erase, the sensitivity of their sources? If the answer to the first question is no, every downstream answer defaults to no as well. Segmentation is the foundation, and retrofitting it is far cheaper before an AI feature scales than after. This is exactly the kind of gap our AI Acceleration Sprint is built to find early, before it compounds.
Treatment programs and integrated providers live under Part 2 every day, and their compliance officers are increasingly fluent in AI risk. Vendors who can answer segmentation and consent questions crisply tend to shorten diligence rather than lengthen it. Vendors who respond with generic HIPAA language signal they have not done the work, and in behavioral health, buyers notice. Part 2 competence is becoming a differentiator in exactly the deals where contract sizes are largest, which is worth weighing against what our pricing covers for a full review.
Does Part 2 apply to us if we are a software vendor, not a treatment program? If your customers include Part 2 programs and their protected records flow through your systems, you are in the chain, typically under agreements that bind you to Part 2's restrictions. Your obligations flow from those agreements and the regulation's redisclosure rules.
Did the recent rule changes make Part 2 basically the same as HIPAA? No. The updates aligned consent mechanics, penalties, and breach notification more closely with HIPAA, but heightened protections, especially around legal proceedings and redisclosure, remain. Treat aligned as less divergent, not identical.
Can we just exclude SUD data from AI features entirely? It is a legitimate strategy and often the right first posture, but it still requires reliable segmentation to enforce, which is the same foundational work either way. Our FAQ page walks through a few more scenarios like this one.
How long do we have to bring our systems into line with the updated rule? The final rule took effect on April 16, 2024, and full compliance was required by February 16, 2026, so this is not a future deadline anymore. If segmentation and consent mapping have not been addressed yet, that work is already overdue rather than upcoming.
Part 2 exposure is an architecture question, and it hides in retrieval systems, embeddings, and prompt pipelines. Resolve Health Tech traces every AI data flow in a product, including whether SUD records can reach places they should not, in a six week sprint. Contact us to see where your own product stands.
Sana is a Technical Content Specialist at Resolve Health Tech. She specializes in breaking down complex architectural patterns, nearshore hiring trends, and software engineering workflows into actionable, human-friendly guides. Working alongside Resolve Health Tech's tech team, Sana ensures every piece of content is both highly readable and technically precise.