What AI Risks Belong in a HIPAA Security Risk Analysis (SRA)?
As therapists begin exploring AI tools, many eventually run into the same question: does this need to be included in the Security Risk Analysis?
The question makes sense. Most providers already understand that HIPAA requires a Security Risk Analysis, but AI creates uncertainty because it is being introduced into workflows that practices may have never needed to evaluate before.
Does AI Need to Be Included in a HIPAA Security Risk Analysis?
Short Answer
Yes, if the AI tool interacts with electronic protected health information (ePHI) or affects how ePHI is handled within the practice.
Full Explanation
Throughout this article, I use the term Security Risk Analysis (SRA), which is the terminology used by the Office for Civil Rights (OCR) and the HIPAA Security Rule. You may also see the process referred to as a Security Risk Assessment. While the terms are often used interchangeably, the HIPAA requirement is a risk analysis.
One of the foundational concepts within the HIPAA Security Rule is risk analysis. The Security Rule requires covered entities to conduct an accurate and thorough assessment of potential risks and vulnerabilities to electronic protected health information. See 45 CFR § 164.308(a)(1)(ii)(A).
The HHS Guidance on Risk Analysis Requirements Under the HIPAA Security Rule further explains that risk analysis is a foundational element of Security Rule compliance.
When AI enters a workflow that involves ePHI, it becomes part of that analysis.
One thing I have noticed is that therapists often assume AI needs to be evaluated separately from everything else in HIPAA. That assumption makes sense. AI is receiving so much attention right now that it can start to feel like an entirely new compliance category.
In practice, the more useful question is usually how the technology fits into existing workflows. Once AI begins interacting with electronic protected health information or affects how that information is handled, the conversation often becomes less about the technology itself and more about understanding the risks associated with its use.
The important question is not whether a technology is labeled as AI. The more important question is how that technology functions within the practice and whether it creates risks that need to be addressed.
AI does not need to be treated as a completely separate compliance issue. Like any other technology used within a practice, it should be reviewed based on how it is being used, what information it interacts with, and whether appropriate safeguards have been implemented.
A Security Risk Analysis is not evaluating whether AI is good or bad.
It is evaluating how a specific technology interacts with electronic protected health information and whether the risks associated with that use have been appropriately addressed.
How Should AI Be Evaluated in a HIPAA Security Risk Analysis?
Once it has been determined that an AI tool should be included in the SRA, the next step is understanding how the technology fits into the practice.
That does not mean documenting every feature, every setting, or every technical detail.
The purpose of the analysis is to understand how the technology affects the confidentiality, integrity, and availability of ePHI and whether any resulting risks have been appropriately addressed.
In some situations, the primary consideration may be the information being entered into the tool. In others, the focus may be how the technology has been configured, what systems it can interact with, or what authority it has been given within a workflow.
The specific considerations will vary depending on the technology. What matters is understanding how the tool is being used and whether that use creates risks that should be addressed within the SRA.
Why Does Context Matter More Than the Technology Itself?
One of the challenges with AI discussions is that people often want a simple answer about whether a particular platform is compliant.
That assumption is understandable.
The reality is that the same technology can create very different levels of risk depending on how it is being used.
A tool that is configured one way may create very different considerations than the same tool configured another way. Similarly, a platform being used for a limited administrative purpose may raise different concerns than one being used to process clinical information.
That is one reason risk analysis remains so important. This approach is also reflected in the NIST AI Risk Management Framework, which emphasizes evaluating AI systems within the context of how they are deployed and used rather than relying solely on the technology category itself. The review is not focused solely on the name of the platform. It is focused on how the technology functions within the practice and whether that use introduces risks that need to be addressed.
How Can AI Affect Risk Within a Practice?
The answer depends largely on how the technology is being used.
A documentation tool creates one set of considerations. A scheduling assistant may create another. An AI system that can access multiple connected systems introduces a very different conversation altogether. Some technologies may simply generate content, while others may process information, move information between systems, or take actions within an established workflow.
Those differences matter because different functions may introduce different risks.
The purpose of the SRA is not to determine whether AI is inherently safe or unsafe. The purpose is to understand how a specific technology functions within a specific practice and whether appropriate safeguards have been implemented.
Should Configuration, Monitoring, and Policies Be Reflected in the SRA?
Short Answer
In many situations, yes.
Full Explanation
Technology does not operate in isolation.
How a platform is configured, what safeguards are in place, how activity is monitored, and what policies guide its use can all affect risk.
The SRA does not need to become a technical manual or an AI policy. However, it may be appropriate for the analysis to reflect the safeguards that have been implemented to address identified risks.
The goal is not to document every setting or reproduce every internal procedure. The goal is to demonstrate that risks have been considered and that reasonable safeguards have been implemented to address them.
Stay Updated on Compliance Changes
Compliance expectations are constantly evolving, and most providers don’t hear about changes until they become a problem.
If you want clear, practical updates you can actually use, you can join my email list below.
Putting AI Into Practice
The purpose of an SRA is not to eliminate every possible risk. The purpose is to identify risks, understand how those risks may affect the practice, and implement reasonable safeguards to address them.
AI does not change that process.
As AI tools continue to evolve, specific platforms and features will inevitably change. The underlying responsibility remains the same: understanding how technology affects the confidentiality, integrity, and availability of ePHI and addressing the risks associated with that use.
For most practices, the question is not whether AI belongs in the SRA. The question is how the technology is being used and whether the associated risks have been appropriately addressed.
Frequently Asked Questions
Does every AI tool need to be included in a HIPAA Security Risk Analysis?
Not necessarily.
The more important question is whether the technology interacts with electronic protected health information (ePHI) or affects how ePHI is handled within the practice.
If it does, it should generally be considered as part of the Security Risk Analysis (SRA).
If an AI company offers a Business Associate Agreement (BAA), does that mean it belongs in the SRA?
Yes.
A Business Associate Agreement may be an important part of the evaluation process, but it does not replace the need for a Security Risk Analysis.
If the technology interacts with ePHI or affects how information is handled within the practice, it should still be considered within the SRA.
Do AI note-writing and documentation tools need to be included in the SRA?
In many situations, yes.
Documentation tools often interact directly with client information and may affect how information is processed, stored, transmitted, retained, or accessed.
Those considerations may be relevant to the SRA.
What about AI scribes or session recording tools?
These tools often involve additional considerations because they may process audio recordings, transcripts, summaries, or clinical documentation.
Whether a specific tool should be included in the SRA depends on how it functions and how it is being used within the practice.
Do AI tools built into an EHR need to be included in the SRA?
Potentially.
The fact that a feature is built into an EHR does not automatically remove the need to evaluate how it functions and whether it affects risk.
The focus remains on how the technology is being used and whether it introduces risks that should be addressed.
Do AI tools used only for administrative tasks need to be included in the SRA?
It depends.
If the technology does not interact with ePHI and does not affect systems that contain ePHI, it may not create the same considerations as tools that directly interact with protected information.
The analysis should be based on the actual use of the technology within the practice.
Should AI policies be part of the Security Risk Analysis?
The SRA and the AI policy generally serve different purposes.
The SRA identifies and analyzes risk. Policies and procedures help demonstrate how those risks are being addressed.
The full policy does not need to be included within the SRA, but it may be appropriate for the analysis to reflect safeguards that have been implemented.
How often should AI-related risks be reviewed?
AI-related risks should generally be reviewed whenever there is a significant change in the technology or the way it is being used.
Examples might include adopting a new platform, enabling new features, changing workflows, expanding access, or modifying how the technology interacts with information.
Is AI automatically a HIPAA risk?
Not automatically.
Like any other technology, risk depends on how the tool functions, how it is configured, what information it interacts with, and how it is being used within the practice.
Can AI ever be used in a HIPAA-compliant way?
Potentially, yes.
The answer depends on the specific technology, the way it is being used, the safeguards that have been implemented, and the overall compliance framework of the practice.
There is rarely a single factor that determines whether a technology can be used in a HIPAA-compliant manner.
Related Articles in This AI + HIPAA Series
Therapists exploring AI documentation often have additional questions that extend beyond progress notes alone.
Related topics include:
- AI + HIPAA: Resources Hub & Next Steps
- Is AI HIPAA Compliant for Therapists?
- Can Therapists Use ChatGPT for Progress Notes?
- Does a Business Associate Agreement Make AI HIPAA Compliant?
- Can Therapists Paste Client Information Into AI Tools?
- What Should an AI Policy Include for a Therapy Practice?
- Can Group Practices Allow Staff to Use AI Documentation Tools?
- Are AI Therapy Note Tools Safer Than Recording Sessions?
- What Happens to Client Information After AI Processes It?
Other Compliance Articles Coming Soon…
- Can Therapists Use AI for Treatment Plans?
- How Should Therapists Document AI Use in Practice?
Sources
HHS Guidance on Risk Analysis Requirements Under the HIPAA Security Rule
https://www.hhs.gov/hipaa/for-professionals/security/guidance/guidance-risk-analysis/index.html
45 CFR § 164.308(a)(1)(ii)(A)
https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.308
NIST AI Risk Management Framework
https://www.nist.gov/itl/ai-risk-management-framework
About the Author
Samantha Schalk, LMSW-C, LMSW-M, CAADC, CIMHP, BCP3
Samantha is a licensed mental health professional, private and group practice owner, and the founder of Guardian Clinical Essentials™.
She helps therapists and group practices understand how compliance, documentation, privacy, technology, and practice operations work together in real-world clinical settings. Her work focuses on turning complex requirements into practical systems, policies, workflows, and implementation strategies that providers can actually use.
Drawing from experience in both clinical practice and compliance consulting, Samantha specializes in helping mental health professionals build defensible, sustainable systems that support both quality care and regulatory compliance.
Learn more about Samantha and Guardian Clinical Essentials™.
Continue Exploring Guardian Clinical Essentials™
Looking for additional compliance, privacy, AI, documentation, and practice operations resources?
Explore the Guardian Clinical Essentials™ Resource Library for educational articles, implementation guidance, training opportunities, and practical resources designed specifically for mental health professionals.