HIPAA Technical Safeguards Checklist for Local AI Deployment

The practices OCR fines aren't the ones that tried and failed. They're the ones that didn't know they were supposed to try.

Nobody in an independent practice sat down one morning and decided to deploy AI. What happened is a physician got tired of finishing notes at ten at night, somebody in billing found a tool that drafts an appeal letter in forty seconds instead of forty minutes, and now there's software in the building touching ePHI that nobody's written into a risk analysis. The HIPAA Security Rule's administrative, physical, and technical safeguards apply in full to AI systems that process protected health information, which means assessing risks, implementing appropriate controls, and ensuring the confidentiality, integrity, and availability of PHI whether the thing doing the processing is a person or an algorithm. (HIPAA Journal) That's just what the rule says, not a scare tactic.

And the enforcement data isn't ambiguous. In 2025, 76% of all OCR enforcement actions included a penalty for a risk analysis failure, with fines ranging from $25,000 to $3 million, and OCR's confirmed its enforcement priorities in 2026 will be largely the same. (HIPAA Journal) Sit with that number a second. Three quarters of a year's enforcement, and it's turning on a document rather than a breach.

The Rule That's Already Coming

One thing before the list, because it's about to move the goalposts. On December 27, 2024, HHS issued a Notice of Proposed Rulemaking proposing to remove the distinction between "required" and "addressable" implementation specifications and make all implementation specifications required with specific, limited exceptions, and to require encryption of ePHI at rest and in transit, multi-factor authentication, vulnerability scanning at least every six months, penetration testing at least annually, and network segmentation. (HHS.gov) The final rule's expected sometime in 2026 with a six-month grace period behind it. (HIPAA Journal)

So read every "Addressable" label below as a countdown. The gap between what a small practice can currently document its way around and what it'll have to implement outright is closing on a published schedule.

The Checklist: 45 CFR §164.312

1. Unique User Identification (Required)

Every workforce member, contractor, and system process that interacts with ePHI gets its own ID. Shared or generic accounts are incompatible with audit trail requirements and there's no reconstructing accountability out of them after the fact. (AccountableHQ) Run inference in the building and the authentication layer's yours to configure. The physician, the medical assistant, the coder, the AR follow-up rep grinding a denial worklist: each one queries under their own credentials, and every query lands in the log against their user ID. No shared logins. No practice-wide password. Nobody's query hiding inside somebody else's session. Cloud platforms sold on team seats blur this constantly, and the blur's exactly what an OCR investigator asks you to explain.

2. Emergency Access Procedure (Required)

You've got to establish and implement as needed procedures for obtaining necessary electronic protected health information during an emergency. (eCFR) In practice that's a documented break-glass protocol: who gets in when primary authentication's unavailable, on what authority, logged how, reviewed by whom afterward. A cloud tool that's unreachable during a mass casualty event is your patient care problem, not your vendor's, and it's your name on the corrective action plan. On-premises means the whole procedure sits inside your own operational control, which is the only place it's worth anything. You're not filing a support ticket at 2 a.m. to find out what your break-glass procedure was.

3. Automatic Logoff (Addressable, Trending Required)

Configure timeouts proportionate to risk and location. Application and workstation inactivity timers, re-authentication to resume access to ePHI, shorter timers on the public, shared and kiosk-mode devices sitting in intake and the exam rooms. (AccountableHQ) With the proposed rule treating this as effectively required, local deployment lets you set the timeout at the application, the operating system and the network at once, instead of waiting on somebody else's product roadmap to ship a control you're already required to have.

4. Encryption and Decryption (Addressable, Trending Required)

The proposed 2025 rule requires encryption of ePHI at rest and in transit, with limited exceptions. (HHS.gov) Here's the item I'd want every practice manager to stop cold on. Send patient data to an outside AI service and you're leaning on that vendor's key management, that vendor's cipher choices and that vendor's continued BAA compliance to satisfy a control you're personally accountable for. Keep it in the building and the data at rest is encrypted on drives you own, under keys your privacy officer can hold up in an audit, and "in transit" means the hop from an exam room workstation to a server down the hall. It's the same control either way. What changes is who you're trusting to run it, and whether you'd know if they stopped.

5. Audit Controls (Required)

Log all security-relevant events: authentication success and failure, access to patient records, create, update, delete operations, privilege changes, policy and configuration changes, and data exports. Then protect the log itself with time synchronization, tamper-evident storage, hashing, and restricted administrative access. (AccountableHQ)

This is where cloud AI gets genuinely treacherous for a small practice. When a physician queries an outside model with patient context, the record of that interaction lives on somebody else's infrastructure. Producing it for an OCR audit or a breach investigation runs on the vendor's cooperation, the vendor's timeline, and the vendor's idea of what a complete log is. In 2022, 55% of OCR's financial penalties were imposed on small medical practices. (Sprinto) The practices that came out of those investigations intact are the ones that could produce a clean, complete trail on demand. The ones that couldn't took a corrective action plan on top of the fine, and that's a rough seat to argue from. That governed, tamper-evident trail is exactly what the Woven Security & Governance Fabric is built to enforce, and it ships woven through the deployment rather than bolted on afterward.

6. Integrity Controls (Addressable, Trending Required)

Checksums, hashes or digital signatures to detect unauthorized changes to files and records, plus file integrity monitoring on any server holding ePHI, alerting on unauthorized edits and permission changes. (AccountableHQ) An AI that drafts clinical documentation, summarizes a record, or puts a modifier 25 next to an E/M level is touching data whose integrity is a patient safety question before it's ever a compliance question. On your own hardware you can write-protect the model's output log, version the AI-assisted edits, and verify integrity yourself instead of accepting a third party's attestation that nothing moved. It's cheap to prove when you own the box.

7. Person or Entity Authentication (Required)

Implement procedures to verify that a person or entity seeking access to electronic protected health information is the one claimed. (eCFR) Under the proposed 2025 rule, regulated entities would be required to apply multi-factor authentication through verification of at least two of three categories of factors: something the user knows, something the user has, or something the user is. (Duo Security) Locally you enforce MFA at the application, the network and the workstation simultaneously, and you're not negotiating with anybody about whether their platform speaks to your identity provider. You implement it, you document it, and the documentation walks straight into the risk analysis as evidence.

8. Transmission Security (Addressable, Trending Required)

Apply encryption at rest to endpoints, servers, databases, backups, and cloud storage, and use strong, validated cryptography with sound key management. (AccountableHQ) On the transmission side that's the segment between clinical workstations and the inference server, TLS on the internal API calls, and no path anywhere in the building where PHI crosses a wire in the clear. That's it. That's the control. And it's far simpler to implement, verify and document when both ends sit inside your four walls than when the path runs through internet routing to a third-party data center, an HTTPS configuration you didn't set up, and key management you can't inspect.

9. Business Associate Agreement (Required for Any Vendor Touching PHI)

A Business Associate Agreement's required whenever a vendor creates, receives, maintains, or transmits PHI on behalf of a covered entity, including when the vendor uses AI to perform regulated functions. It's got to describe permitted and required uses of PHI, require the vendor to maintain safeguards, and establish a timeline for notifying the covered entity of unlawful exposure or a data breach. (Texas Medical Association) The provision that matters most with an AI provider is a flat prohibition on the use of patient data for training or retraining models without patient authorization. (Mcneeslaw) A tool with no signed BAA, or a BAA carved out to permit training on your patients, that's direct liability the second any PHI touches it. Inference on hardware in your own building takes that question off the table, because there's no third party in the loop to sign with.

Which is where I'll concede the obvious. It doesn't take the BAA question off the table for anything else. Your EHR vendor, your clearinghouse, your release-of-information vendor, your transcription service, they all still need one. Local inference shortens the list. It doesn't empty it, and I'd distrust anybody who tells you otherwise.

10. Organization-Wide Risk Analysis (Required)

A comprehensive, organization-wide risk analysis is vital for security, and OCR launched a risk analysis enforcement initiative in 2025 whose 2026 successor carries the same focus and evolves to cover risk management as well. (Ogletree) Standing up AI means standing up a new system that processes ePHI, which triggers a mandatory update to that analysis. The update has to name the threats specific to this system: model poisoning, prompt injection, unauthorized access to query logs, exfiltration through an API endpoint, inference attacks that reconstruct patient data out of model outputs. Local deployment narrows that surface hard, and it's the cheapest risk reduction on the whole list. You're not assessing a multi-tenant platform serving millions of customers on a security posture you'll never be allowed to audit, because you can't audit what you're not allowed to look at. You're assessing a machine you can walk over and put a hand on.

What I Won't Tell You Until I've Watched You Work

This is the point where a vendor usually hands you a configuration. I won't, and it isn't modesty.

I don't know which payer's prior authorization form your PA coordinator is rekeying the same clinical history into for the fourth time this week, chart notes and imaging attached, peer-to-peer already scheduled. I don't know which CARC and RARC pair your denial rep decodes from memory because the worklist won't explain itself. I don't know what your HIM technician does to strip psychotherapy notes and 42 CFR Part 2 content out of a records release, or how many hours your credentialing specialist loses re-attesting CAQH and resubmitting the same DEA and malpractice face sheet on each payer's own form so claims stop denying as non-par. Those people have run that job for fifteen or twenty years and the knowledge barely lives in the documentation.

So the order runs backwards from how this normally gets sold. I show up, sit down next to them, and shut up until I understand the work the way they run it instead of the way the SOP describes it. Discovery turns up the use cases already sitting in the building, most of which nobody's said out loud yet. Only then do I recommend a stack, and what I recommend is whatever the work turned out to need. Then we deploy and configure it together on site, and I onboard your team on the workflows and the agentic orchestration a practice really runs on. Not a lunch-and-learn on prompting. That last part's what decides whether any of this is still running a year after I've gone.

Architecture Over Convenience

Here's the structural point the whole checklist's been building toward. HIPAA's technical safeguards were written for a world where a healthcare organization controls its own systems, and every one of the ten items above is satisfied more completely, more verifiably and more defensibly when the AI sits inside your facility, on your hardware, under your administrative control. That's an observation about how evidence works once an investigator starts asking, not an ideological position.

Now the fair version of the other side. Cloud platforms can satisfy a good number of these, some of the time, under some configurations, if you read the BAA carefully, monitor the vendor's certifications continuously, and accept that a third party's security posture sits outside your direct control. Plenty of large health systems run exactly that way on purpose and they're nobody's fools; they've got a vendor risk team to do the watching. The independent practice doing the same thing has quietly taken on a supervision job it has nobody to staff, and the "addressable" column it's been leaning on is scheduled for deletion. For the frameworks beyond HIPAA, my compliance briefs carry the same architecture argument into ITAR, the CLOUD Act, and tribal data sovereignty.

Build it where you can put a hand on it. Every item on this list gets easier from there.