A proposed HIPAA Security Rule update would make encryption, MFA, and network segmentation mandatory, not optional. Here is what that means for AI features handling patient data.
A significant update to the HIPAA Security Rule has been sitting in proposed form for over a year, and it is worth being precise about that status before anything else. As of mid-2026, the rule has not been finalized, and federal timelines have already slipped once, with OMB's Unified Agenda now targeting July 2027 for final action, pushed back from an earlier spring 2026 target. That said, the direction of the proposal is not really in question, and it points squarely at the kind of technical gaps AI features tend to introduce.
The proposal removes the long standing distinction between "required" and "addressable" security specifications, making nearly every safeguard mandatory rather than a judgment call. The headline changes include mandatory encryption of electronic PHI at rest and in transit, required multi factor authentication for any system accessing ePHI, mandatory network segmentation, annual penetration testing, and vulnerability scanning at defined intervals. It would also shorten the incident reporting window considerably compared to current norms and add new documentation requirements around business associate oversight. That last point matters more than it might seem. Under the current rule, a covered entity or business associate has some flexibility to justify why an addressable specification does not apply to their specific situation. The proposal largely removes that flexibility, which means a compliance posture built around reasonable judgment calls, this control does not really apply to our setup, would need to be rebuilt around concrete implementation instead. For AI features specifically, that shift closes off a common justification teams currently use to defer security work on newer AI infrastructure.
Every one of these proposed requirements maps directly onto gaps that are common in AI built healthcare features specifically. Encryption at rest and in transit sounds straightforward until an AI feature's logging pipeline, embeddings store, or a debug configuration left over from development turns out to hold plaintext patient data somewhere nobody accounted for. Multi factor authentication requirements typically focus on user facing systems, but AI features often introduce service to service connections, an application calling a model API, a retrieval system querying a vector store, that need the same rigor applied to how those connections authenticate. Network segmentation matters because AI infrastructure, vector databases, embedding pipelines, model hosting, frequently gets bolted onto an existing architecture without being placed behind the same boundaries as the rest of a system handling ePHI.
Waiting is the more common instinct, and it is also the weaker strategy for two reasons. First, a coalition of more than 100 hospital systems and provider groups, including names like Cleveland Clinic and Yale New Haven Health, have formally asked HHS to withdraw or scale back the proposal, which means the final version could look meaningfully different from what was originally proposed, or could be delayed further, or could theoretically be withdrawn entirely. Second, and more importantly, OCR has already been enforcing based on the spirit of these requirements under the current rule's general risk analysis obligations, treating encryption, MFA, and segmentation gaps as exactly the kind of finding that supports a willful neglect determination even without a new rule requiring them explicitly. The regulatory uncertainty does not remove the practical exposure.
Regardless of when or whether the rule finalizes, a few things are worth confirming now rather than later. Every AI feature's data flow, including embeddings and retrieval systems, needs to be checked for whether patient data is encrypted both at rest and in transit, not assumed to be based on a general platform level encryption policy that may not extend to every AI specific component. Service to service authentication between an application and any AI vendor or internal AI infrastructure needs review, since MFA policies built around human logins do not automatically cover machine to machine connections. And AI infrastructure needs to sit inside the same network segmentation boundaries as the rest of a system handling ePHI, rather than existing as a separate, loosely connected layer that was added after the fact.
A platform running an AI powered clinical note summarization feature discovers, during a review prompted by this exact proposal, that its vector store holding embeddings of session notes sits on a separate cloud account from the rest of its infrastructure, with a broader set of engineers holding access than the production database itself requires. Encryption at rest was enabled on the primary database from day one, but nobody had specifically verified it on the newer vector store, since it was added later by a different team working quickly to ship the AI feature. Nothing about this was intentional negligence. It was simply a gap that formed the way AI infrastructure often gets added, quickly and somewhat separately from the rest of the security review process the core platform already goes through.
Getting a straight answer requires actually mapping every AI data flow against these specific requirements, rather than relying on a general assumption that the platform's existing security posture automatically extends to newer AI components. This is a core part of what our AI Acceleration Sprint reviews, checking AI specific infrastructure against the same rigor the rest of a HIPAA compliant platform is expected to meet.
Preparing ahead of a final rule costs considerably less than retrofitting encryption, segmentation, and authentication into AI infrastructure that has already scaled across several features. Our pricing page lays out what that proactive review looks like, and our FAQ page addresses a few more questions specific to this proposed rule.
Resolve Health Tech reviews AI infrastructure against the security standards this proposal points toward, regardless of when or whether it finalizes. Contact us to find out where your own AI stack stands today.
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.