Healthcare has always operated in a data-sensitive environment. Every patient encounter generates protected health information. Every claim submitted carries demographic, diagnostic, and financial data that is subject to strict regulatory controls. Every vendor that touches that data on behalf of a provider is bound by law to protect it. None of that is new.

What is new is the scale and speed at which AI tools are now interacting with that data inside the revenue cycle. Eligibility checks, clinical documentation, charge capture, coding decisions, prior authorization submissions, denial appeals — all of these functions are being automated through AI systems that read, process, and act on protected health information at a volume and velocity that manual workflows never approached. The efficiency gains are real. So are the data security obligations that come with them.

For providers evaluating or currently using AI tools in their revenue cycle, understanding the intersection of HIPAA, data security, and AI is no longer a compliance exercise that can be deferred to legal counsel. It is an operational requirement. And the regulatory environment around it is changing in ways that are directly relevant to every AI tool a billing team currently uses or is considering deploying.

According to IBM’s 2025 Cost of a Data Breach Report, the average healthcare data breach costs $7.42 million, the highest of any industry for 14 consecutive years. Healthcare remains the most expensive sector for breach costs not because its security teams are less capable, but because the data it holds is uniquely valuable, uniquely sensitive, and subject to regulatory consequences that amplify the financial impact of every incident. In that context, how AI tools access, process, and transmit patient data is not a secondary concern. It is a primary one.

What HIPAA Actually Requires When AI Touches Patient Data

HIPAA has been the governing framework for healthcare data privacy and security in the United States since 1996. Its core structure has remained relatively stable: covered entities and their business associates must protect the confidentiality, integrity, and availability of protected health information, and must apply administrative, physical, and technical safeguards appropriate to the sensitivity of that data.

AI tools did not exist when HIPAA was written. But HIPAA is explicitly technology-neutral by design, which means its requirements apply to AI systems just as they apply to EHRs, billing software, and every other technology that processes patient data. The Office for Civil Rights has been unambiguous on this point: the HIPAA Security Rule governs electronic PHI used in AI training data, AI algorithms developed by regulated entities, and any AI system that creates, receives, maintains, or transmits ePHI.

This has a direct practical implication. When a provider deploys an AI coding tool that reads clinical notes, or an eligibility verification agent that checks insurance coverage using patient demographics, or an appeal writing system that generates letters containing diagnosis codes and clinical details, all of those tools are interacting with ePHI. All of them are subject to HIPAA’s security and privacy requirements. And all of them require the same foundational controls: a signed Business Associate Agreement with the vendor, documented risk analysis that includes the AI system, appropriate access controls, audit logs, and encryption of data in transit and at rest.

The Business Associate Agreement Is Non-Negotiable

The Business Associate Agreement, or BAA, is the legal instrument that extends HIPAA obligations to third-party vendors who access or process PHI on behalf of a covered entity. When an AI vendor’s system reads clinical documentation to generate billing codes, that vendor is functioning as a business associate. Without a signed BAA, the provider is in violation of HIPAA regardless of how secure the vendor’s system actually is.

A well-constructed BAA specifies how the vendor may use PHI, what security controls they are required to maintain, how breaches must be reported, and what happens to patient data at the end of the relationship. For AI tools specifically, the BAA should also address whether patient data is used to train the AI model. Using identifiable PHI to train a model that serves other clients is a use case that falls outside the standard treatment, payment, and operations framework and typically requires explicit patient authorization. This is a point that many providers miss when evaluating AI billing vendors.

Risk Analysis Must Include AI Tools

HIPAA’s Security Rule has always required covered entities to conduct an accurate and thorough risk analysis of their systems. What has changed is the regulatory clarity around the fact that AI tools are included in that requirement. HHS’s proposed regulation explicitly states that entities using AI tools must include those tools as part of their risk analysis and risk management compliance activities.

This means that when a provider adds an AI coding agent or an AR follow-up automation tool to their revenue cycle workflow, they are not just making a technology decision. They are creating a new risk surface that must be assessed, documented, and managed under their existing HIPAA compliance program. Failure to include AI systems in a risk analysis is not a technical oversight. It is a compliance gap that OCR’s enforcement priorities are increasingly likely to surface.

The 2025 Proposed HIPAA Security Rule Update: What It Means for AI in RCM

On January 6, 2025, the HHS Office for Civil Rights published the first proposed update to the HIPAA Security Rule since 2013 in response to a dramatic increase in healthcare cyberattacks. From 2018 to 2023, OCR observed a 102% increase in large healthcare data breaches, with more than 167 million individuals affected in 2023 alone. The proposed rule responds to that trend with significant updates to security requirements, several of which are directly relevant to AI tools used in the revenue cycle.

All Safeguards Become Required

Under the current HIPAA Security Rule, implementation specifications are divided into two categories: required and addressable. Required specifications must be implemented. Addressable specifications must be considered, but an organization can choose not to implement them if it documents a reasonable alternative.

The proposed rule eliminates this distinction entirely. Every implementation specification becomes required, with very limited exceptions. For providers using AI tools, this means that controls that may have previously been treated as optional, including multi-factor authentication for all systems accessing ePHI, network segmentation, and encryption of ePHI both in transit and at rest, are no longer judgment calls. They are mandatory. Any AI vendor whose system does not meet these standards would represent a compliance gap under the proposed framework.

Technology Asset Inventory Must Include AI Systems

The proposed rule requires covered entities to develop and maintain an accurate, written inventory of all technology assets that may affect the confidentiality, integrity, or availability of ePHI. HHS has explicitly stated that AI software that creates, receives, maintains, or transmits ePHI would be included in this inventory requirement.

For a provider using multiple AI billing agents across eligibility, coding, charge capture, and AR functions, this means each of those tools must be individually inventoried, with documentation of how they access and handle patient data. Organizations that have deployed AI tools on a department-by-department basis without centralized tracking are likely to find compliance gaps when this requirement is applied systematically.

Annual Compliance Audits

The proposed rule mandates compliance audits at least once every 12 months to verify adherence to the Security Rule. In March 2025, OCR confirmed that it had already commenced the third phase of its HIPAA compliance audit program, with an initial cohort of 50 covered entities and business associates. The most commonly cited violation in 2025 enforcement actions, appearing in 13 of the 20 settlements OCR announced through September 2025, was failure to conduct an adequate risk analysis.

For providers using AI tools, the implication is direct. If the AI systems currently deployed in the revenue cycle are not included in the organization’s risk analysis, and if the vendor relationships are not governed by current BAAs with appropriate AI-specific provisions, those gaps are exactly the kind of findings that the HIPAA audit process is designed to surface.

The Security Standards That Matter Most for AI in the Revenue Cycle

Beyond the HIPAA framework, AI tools used in healthcare billing are evaluated by reference to several security standards that serve as benchmarks for what adequate data protection looks like in practice.

SOC 2 Type II

SOC 2 Type II certification is one of the most meaningful signals of security posture for AI vendors handling healthcare data. Unlike SOC 2 Type I, which certifies that controls are designed appropriately at a point in time, SOC 2 Type II certifies that those controls have been operating effectively over an extended period, typically six months to a year. For a provider evaluating an AI billing vendor, SOC 2 Type II certification provides independent third-party assurance that the vendor’s security controls are not just documented but consistently applied.

The specific trust service criteria evaluated in SOC 2 include security, availability, processing integrity, confidentiality, and privacy. For AI tools handling ePHI in the revenue cycle, security and confidentiality are the most directly relevant. A vendor with current SOC 2 Type II certification has demonstrated those controls through external audit, not just internal attestation.

Encryption in Transit and at Rest

Encryption of ePHI both when it is being transmitted between systems and when it is stored is a foundational data security requirement. Under the proposed HIPAA Security Rule update, encryption becomes a required safeguard rather than an addressable one. The relevant standards are AES-256 for data at rest and TLS 1.3 for data in transit.

For AI tools in the revenue cycle, this requirement applies to every point where patient data moves. When an eligibility agent checks insurance coverage, when a coding agent reads a clinical note, when an AR follow-up system accesses account information, the data involved must be encrypted throughout the process. Providers should verify explicitly with AI vendors that end-to-end encryption is implemented across all data movement within the system, not just at the external transmission layer.

Access Controls and Audit Trails

Granular access controls govern who within an organization can see patient data and under what conditions. Role-based access, meaning that each user role has access only to the data necessary for their function, is a core HIPAA requirement that becomes particularly important in AI-enabled environments where data may be accessed across multiple automated workflows simultaneously.

Audit trails document every interaction with ePHI: who accessed what data, when, and what action was taken. For AI systems, this requirement extends to the system’s own interactions. Every time an AI agent reads a patient record, validates a claim, or generates a billing output, that action should be logged in a format that is accessible for compliance review. Without this logging, an organization cannot demonstrate to regulators that its AI tools are handling patient data appropriately.

What to Verify Before Deploying Any AI Tool in Your Revenue Cycle

The practical risk management question for any provider evaluating AI billing tools is what to verify before deployment. A few specific checkpoints address the most consequential compliance risks.

Business Associate Agreement in place and current. This is the baseline requirement. If a vendor is not willing to sign a BAA, or if the BAA does not specifically address AI’s interaction with PHI and the prohibition on using patient data for model training without authorization, it is not a compliant vendor relationship under HIPAA regardless of the vendor’s other security certifications.

SOC 2 Type II certification active and current. Request the most recent audit report and verify the certification covers the systems that will handle your patient data. A SOC 2 report that is more than 12 months old does not reflect the vendor’s current security posture.

Encryption documented across all data flows. Ask the vendor to specify how ePHI is encrypted in transit between your systems and theirs, how it is stored within their environment, and what encryption standards they use. AES-256 at rest and TLS 1.3 in transit are the current benchmarks.

Audit logs accessible and comprehensive. Verify that the system generates a complete audit trail of every AI interaction with patient data, that those logs are accessible to your compliance team on request, and that they are retained for a period consistent with your HIPAA obligations.

AI system included in your risk analysis. Before any AI tool goes live in your revenue cycle, update your HIPAA risk analysis to include it. Document what data the system accesses, how it is protected, what the residual risk is, and how that risk is being managed. This documentation is what an OCR audit would expect to see.

Data use limited to your operations. Confirm in writing that the vendor does not use your patients’ data to train models for other clients or for the vendor’s own product development without your explicit authorization. This is a point that should be addressed in the BAA and confirmed during vendor due diligence.

How ImpactRCM Approaches Data Security

ImpactRCM is built on the principle that the obligations around patient data are not a compliance layer added on top of the platform. They are built into its architecture.

The platform is HIPAA compliant and SOC 2 Type II certified, with end-to-end encryption covering data both in transit and at rest. Access controls are role-based and granular, meaning each user type within a practice, billing company, or health system has access scoped to their specific function. For multi-client billing company environments, data segregation ensures that patient data from different client organizations is kept structurally separate.

Every AI agent interaction is logged through a comprehensive audit trail that is accessible to compliance teams. When the Code Audit Agent reviews a coded encounter, when the Eligibility Verification Agent checks coverage, or when the AR Follow-Up Agent processes an account, those interactions are recorded. The audit trail exists not as a retrospective reconstruction but as a continuous, real-time log that supports both internal compliance review and external audit readiness.

For providers and billing companies evaluating whether AI tools in their revenue cycle meet the security standard that the current and proposed regulatory environment requires, these controls address the specific requirements that OCR’s audit program and the proposed Security Rule update are focused on.

The Direction of AI Compliance in Healthcare

The regulatory trajectory is clear even if the timeline for specific rule finalization is not. AI tools that interact with ePHI are subject to HIPAA today, and the proposed Security Rule update would make the standards that currently represent best practice into mandatory requirements. The organizations that treat this transition as an opportunity to build security into their AI deployments from the start will be in a substantially better position than those that wait for final rulemaking to begin addressing the gaps.

The question for most providers is not whether HIPAA applies to the AI tools they are using. It clearly does. The question is whether their current vendor relationships and internal compliance programs have kept pace with how significantly AI has changed the data access landscape in the revenue cycle. The volume of ePHI flowing through AI systems today is categorically different from what compliance programs designed for manual workflows were built to govern.

Healthcare data security in an AI-enabled revenue cycle requires the same foundational controls that HIPAA has always required, applied at a scale and with a specificity that reflects how these systems actually work. BAAs, risk analysis, encryption, access controls, and audit trails are not new concepts. Their application to AI systems requires the same rigor that has always applied to every other technology category that handles patient data.

Conclusion

HIPAA and AI in RCM are not in tension. AI tools can be deployed in the revenue cycle in a way that is fully compliant with data security requirements, but only when the vendor’s security architecture, legal framework, and operational practices actually meet those requirements. The stakes are high enough that verifying this at the outset, rather than discovering gaps during an audit or a breach, is the only responsible approach.

The regulatory environment around AI compliance in healthcare is evolving quickly. The proposed HIPAA Security Rule update signals a direction, if not yet a final compliance deadline. The IBM breach cost data signals the financial consequence of gaps in healthcare data security. Together, they make the case that for any provider deploying AI tools in the revenue cycle, security due diligence is not a one-time check. It is an ongoing operational responsibility.

Want to understand how ImpactRCM’s security architecture meets HIPAA, SOC 2, and data privacy requirements for AI-driven RCM? Schedule a demo with ImpactRCM and see how the platform protects patient data at every stage of the revenue cycle.