The HIPAA Security Rule: what AI use leaves in the record your security officer reviews.
For the privacy officer, security officer or compliance lead at a covered entity, and business associates handling ePHI, this page sets out what the Security Rule asks of audit and integrity controls and what a Verillian record shows when staff use AI on enrolled devices.
What the rule asks, clause by clause
| What the rule asks | A Verillian record shows | It does not show |
|---|---|---|
| Conduct 'an accurate and thorough assessment of the potential risks and vulnerabilities' to ePHI, then implement security measures 'sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level'. Both are Required. 164.308(a)(1)(ii)(A) and (B) | Which governed AI services staff used from enrolled devices, and what your policy ruled. That is an input to your analysis. | The risk analysis or the risk management plan. Both are yours to write and keep. |
| 'Implement procedures to regularly review records of information system activity, such as audit logs, access reports, and security incident tracking reports.' Required. 164.308(a)(1)(ii)(D) | Entries your reviewers can search and export from the admin console that your organization hosts. | The review procedure, how often it runs, who does it, or what they found. |
| Identify and respond to suspected or known security incidents, mitigate harmful effects, and 'document security incidents and their outcomes'. Required. 164.308(a)(6)(ii) | A dated entry for each captured request, which can serve as a source when you look into an incident. | Whether an entry is an incident, what was done about it, or the outcome. |
| Allow access only to 'those persons or software programs that have been granted access rights', and 'assign a unique name and/or number for identifying and tracking user identity'. Required. 164.312(a)(1) and (a)(2)(i) | The user and device as the checkpoint reports them. | The user and device the checkpoint reports. It does not grant or remove access in your systems. |
| 'Implement a mechanism to encrypt and decrypt electronic protected health information.' This specification is Addressable: you assess whether it is reasonable and appropriate, then implement it or document why not and what you did instead. 164.312(a)(2)(iv), 164.306(d)(3) | Entry content is encrypted with AES-256-GCM, and your organization holds the key. Even Verillian cannot read content. | Whether your other systems encrypt ePHI, or the decision your assessment reached. Redaction is a separate step and is best effort. |
| 'Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information.' 164.312(b) | One record per captured AI request that an enrolled device sends to a provider named in your signed policy, marked allowed, redacted or blocked. The text names no AI tool. | Whether an AI service is an information system that contains or uses ePHI in your environment. That scoping is yours. |
| 'Implement policies and procedures to protect electronic protected health information from improper alteration or destruction.' An Addressable specification adds electronic mechanisms to 'corroborate' that ePHI 'has not been altered or destroyed in an unauthorized manner'. 164.312(c)(1) and (c)(2) | The device signs every entry and hash-links it to its predecessor. A changed signed field is detectable, because your own admin server checks each entry as it arrives. | The state of ePHI in your EHR or other systems. Removal of the newest entries leaves no gap to see, and neither does removal by someone who controls the host. |
| Guard against unauthorized access to ePHI 'being transmitted over an electronic communications network'. Two Addressable specifications cover integrity controls and encryption 'whenever deemed appropriate'. 164.312(e) | Which values your policy replaced before the request left the device, and the ruling. | Whether the connection to the AI service was encrypted, or whether you deemed it appropriate. |
| A covered entity may let a business associate handle ePHI only after it obtains 'satisfactory assurances' that the business associate 'will appropriately safeguard the information', documented in a written contract. 164.308(b), 164.502(e)(1)(i) and (e)(2) | Which AI services your enrolled devices reached, and when. | Whether a contract exists with any of them, or what it says. That stays with your counsel. |
| Retain 'the documentation required by paragraph (b)(1)' for '6 years from the date of its creation or the date when it last was in effect, whichever is later'. Paragraph (b)(1) covers the written policies and procedures and any action, activity or assessment the subpart requires to be documented. The text does not name audit logs. 164.316(b)(1) and (b)(2)(i) | Entries sit on infrastructure you operate. No retention setting is stated on this page. | Whether your program treats an entry as required documentation, or the period you apply to it. |
| Limits | Only requests from enrolled devices to providers your signed policy lists. Any provider the policy omits is not governed. Redaction is best effort, and screening is verified on the Claude API format only. | Completeness, anything within a vendor's own cloud, or whether a prompt carried ePHI. Verillian is not a HIPAA compliance product, does not decide what counts as ePHI or what a business associate contract must contain, and gives no legal advice. |
Source: 45 CFR Part 164, Subpart C (and the definitions and disclosure sections cited), on eCFR, which showed the text current as of October 6, 2026. Read on October 8, 2026, and checked that day: 164.306, 164.308, 164.312, 164.316, 164.402, 164.502. Quoted text is from those sections.
Built for HIPAA-regulated environments. Not certified: there is no HIPAA certification. This is not legal advice. Your counsel and your compliance program decide what satisfies the rule.
To read an entry beside these clauses, bring a sample request to a demo. We read every request and reply.
Questions about HIPAA and AI records
Does HIPAA require audit logs for AI tools?
The audit controls standard, 164.312(b), asks for hardware, software or procedural mechanisms that record and examine activity in information systems that contain or use ePHI. It names no AI tool and no log format. Whether an AI service is such a system in your environment is a scoping call for your security officer and counsel. Where it is, the activity review at 164.308(a)(1)(ii)(D) also applies.
Is pasting patient data into an AI tool a breach?
The answer sits with your counsel and your privacy officer. The rule defines a breach at 164.402 as an acquisition, access, use or disclosure of protected health information in a manner not permitted under the Privacy Rule that compromises its security or privacy. Such an event is presumed a breach unless a risk assessment shows a low probability of compromise, and the text names four factors for it. Whether a given disclosure was permitted can turn on a business associate arrangement under 164.502(e).
Does using Verillian satisfy the HIPAA Security Rule?
No. There is no HIPAA certification, and compliance rests on your risk analysis, your agreements and how your organization runs its program. Verillian is built for HIPAA-regulated environments and keeps a signed record of AI use on the devices you enroll for your reviewers to read. The ruling on any entry is yours.
Where do the records live?
Your own infrastructure hosts the admin server and the signed record. The key that encrypts content is yours, and Verillian never receives your data. A model a vendor calls from its own hosted service is outside what an enrolled device sends.
See an entry next to these clauses.
Thirty minutes. Bring a sample request, watch it ruled live, and open the signed record together.