HIPAA compliance for generative AI solutions on AWS

In the race to harness the transformative power of generative AI, Healthcare and Life Sciences (HCLS) organizations face a critical challenge: how to innovate rapidly while navigating complex regulatory requirements. Promising generative AI solutions are being developed to revolutionize everything from patient care to drug discovery. However, many organizations find themselves paralyzed at the intersection of innovation and compliance.

The stakes are particularly high in the United States (US), where the Health Insurance Portability and Accountability Act (HIPAA) and Health Information Technology for Economic and Clinical Health Act (HITECH) regulations safeguard sensitive patient information.

Yet, the path to compliant generative AI deployment doesn’t have to be a roadblock to innovation.

We will:

• Demystify healthcare compliance requirements.
• Clearly delineate the responsibilities between Amazon Web Services (AWS) and our customers.
• Provide actionable best practices for implementing secure, compliant generative AI solutions that drive real business value.

In the US, HIPAA and HITECH are crucial regulations for ensuring security and privacy of electronically protected health information (ePHI). Conformance to HIPAA and HITECH (referred to only as HIPAA going forward) is of paramount concern for any company working with ePHI.

AWS has developed its generative AI services, including Amazon SageMaker AI, Amazon Bedrock and Amazon Q Business, so customers can deploy secure, scalable applications in conformance with HIPAA requirements.

Note: This blog is not intended to provide legal or compliance advice. This blog’s purpose is to help demystify compliance requirements, clarify how AWS services are architected to support compliance efforts, and provide guidance in line with AWS best practices. It is important for customers to seek legal, compliance, and regulatory advice from their own counsel.

Shared Responsibility model

Firstly, a quick recap that security and compliance is a shared responsibility between AWS and the customer. This Shared Responsibility model relieves the customer’s operational burden, as AWS operates, manages and controls security of the cloud while the customer owns responsibility for security in the cloud. The use of generative AI and agentic solutions adds an additional layer of shared responsibility between AWS, AWS customers, third-party model providers, and those who run agents within their systems.

The specific responsibilities will vary by service type and other factors. For Infrastructure as a Service, such as Amazon Elastic Compute Cloud (Amazon EC2), AWS manages the components—from the host operating system, and the virtualization layer, down to the physical security of the facilities in which the service operates. The customer assumes responsibility and management of the guest operating system (including updates and security patches) and other associated application software. This delineation is illustrated in the following figure.

Figure 1 – Shared Responsibility model

Understanding the customer’s responsibilities of the Shared Responsibility model for each service is an important consideration in planning a secure and compliant solution. For further information refer to the AWS documentation on the Shared Responsibility model and AWS Cloud Security.

HIPAA eligible compared to HIPAA compliant

HIPAA compliance refers to the actual implementation at a specific point in time and use of services in a manner that meets HIPAA requirements. Customers do not automatically inherit HIPAA compliance by using HIPAA eligible services—they must configure and implement controls within these services to achieve compliance.

AWS offers over 166 HIPAA eligible services, with new services added frequently, architected for use in conformance with HIPAA requirements. AWS verifies the security of the underlying infrastructure and provides the necessary services and features (such as data encryption capabilities, access controls, and AWS Key Management Service (AWS KMS)) so customers can implement required security measures.

Organizations working with ePHI choose HIPAA eligible services for workloads that process, store or transmit protected health information. Organization should review their specific Business Associate Addendum with AWS, and any other application agreements, to understand their compliance obligations. AWS services, which are not designated as HIPAA eligible, can still be used as part of a HIPAA compliant solution if those services do not process, store or transmit ePHI.

Examples include:

• Resource tags for Financial Operations (FinOps). Tagging APIs are not part of the HIPAA eligibility list, therefore, for this product the customer should not process or store ePHI in resource tags.
• Amazon Q Developer can be used within the software development lifecycle with the understanding that ePHI should not be present in coding and feature development environments. While Amazon Q Business is HIPAA eligible, Amazon Q Developer is not designed to transmit, store, or process ePHI. Customers are responsible for confirming Amazon Q Developer is never used with ePHI data and that all development environments and Developer Security Operations (DevSecOps) services and tooling remain compliant.

Further information on AWS compliance offerings and HIPAA compliance program can be found at AWS Compliance and AWS Cloud Security – HIPAA Compliance.

HITRUST CSF

The Health Information Trust Alliance Common Security Framework (HITRUST CSF) incorporates nationally and internationally accepted security frameworks such as ISO27001 and NIST 800-53 to create a comprehensive set of controls tailored to US healthcare. AWS offers over 177 HITRUST CSF certified services that have been third-party attested. While HCLS companies processing ePHI in the US must abide by HIPAA as a legal requirement, HITRUST certification is an industry framework that can streamline compliance efforts and reassure stakeholders about data protection.

With HITRUST certified services, AWS verifies the compliance of the underlying infrastructure and provides necessary services and features for customers to deploy controls for their applications. Customers can inherit AWS certification for controls under the HITRUST Shared Responsibility matrix, though they remain responsible for third-party attestation.

Note, companies typically update HITRUST certificates annually. This may create additional overhead within attestation periods or require adjustments to your generative AI strategy. Regarding the Shared Responsibility model, customers must confirm they use products with appropriate controls and configurations for both HIPAA and HITRUST requirements.

Key considerations for achieving and maintaining HIPAA-eligible applications

AWS Business Associate Addendum
The first step in verifying compliance is to acknowledge the Business Associate relationship between AWS and the customer. Under HIPAA, cloud service providers (CSPs), such as AWS, are considered business associates when they create, receive, maintain, or transmit ePHI on behalf of a covered entity or another business associate. AWS offers a standardized Business Associate Addendum (AWS BAA) for customers subject to HIPAA. Customers who execute an AWS BAA may use any AWS service in an account designated as a HIPAA account, but they may only process, store and transmit ePHI using HIPAA eligible services. Organizations can accept a BAA with AWS for all accounts in their AWS organization through the self-service Business Associate Addendum process.

VPC configurations
The Amazon Virtual Private Cloud (Amazon VPC) is the first architecture element to be deployed. Standard best practices apply here: Use private and public subnets to isolate resources from the internet, use a multi-layered, Zero Trust-centric network security approach with security groups, network access control lists (ACLs) and VPC endpoints. Applications hosted in AWS can be accessed directly over secure connections such as HTTPS. Connectivity between cloud-based and on-premises data sources can be established through encrypted connects such as AWS Site-to-Site VPN or AWS Direct Connect.

AWS provides comprehensive guidance on managing security responsibilities for Amazon VPC, AWS Privacy Reference Architecture sample policies, and AWS Security Reference Architecture perimeter security. Healthcare organizations can also leverage the Landing Zone Accelerator on AWS for healthcare and establish private networks for data movement in generative AI.

Secure access controls
Establishing secure AWS Identity and Access Management (IAM) controls is necessary to verify that only authorized users have access to applications and data. SageMaker AI, Amazon Bedrock and other AWS generative AI services are tightly integrated with IAM.

They should be deployed using IAM best practices such as least privilege, multi-factor authentication, role-based access, and other secure practices as established in the AWS Well-Architected Framework. Organizations can also use AWS IAM Identity Center to manage access across multiple AWS accounts and applications, provide single sign-on, and to integrate with external identity providers.

Encryption of data at rest
Encryption of ePHI stored in or transmitted using HIPAA eligible services in accordance with guidance from the Secretary of the U.S. Department of Health and Human Services (HHS) is strongly recommended for HIPAA compliance. The current regulation does not explicitly require ePHI be encrypted at rest in all circumstances. It should be noted that under the HHS breach notification rule, covered entities and business associates must only provide the required notifications if the breach involved unsecured protected health information. The combination of encryption and access requirements makes encryption at rest a logical, if not necessary, requirement.

Additionally, encryption at rest may be required within business associated agreements between you, your customers, and your cloud providers. A detailed examination of this topic is beyond the scope of this blog. However, it should be noted that the proposed updates to HIPAA may increase encryption requirements.

ePHI for generative AI applications can be stored in:

• Amazon Simple Storage Service (Amazon S3)
• Amazon Relational Database Service (Amazon RDS)
• Amazon DynamoDB
• Amazon Bedrock Knowledge Bases
• Amazon Elastic File System (Amazon EFS)
• Amazon FSx

These services provide the ability to encrypt data at rest using AWS-managed or customer-managed encryption keys. Cryptographic keys can be stored in and managed with AWS KMS for protecting data at rest. It is a best practice to follow our AWS Well-Architected Framework data encryption security pillar documentation.

Key management
Proper management of encryption keys is essential to maintaining data security. Your locked home is not secure if you place the key under the front doormat. Similarly, loose key management practices represent a significant risk to your data and business. AWS-managed keys for services (such as Amazon S3 and Amazon RDS) confirm secure key management, as well as regular key rotation.

For customers wishing to manage their own cryptographic keys, AWS KMS gives you control over the cryptographic keys used to protect your data. AWS KMS provides you with centralized control over the lifecycle and permissions of your keys. You can create new keys, and control who can manage keys, separately from who can use them. The service is integrated with other AWS services, making it quick to encrypt data you store in these services and control access to the keys that decrypt it. For more information, read Amazon SageMaker AI Key Management and Encryption Best Practices for AWS Key Management Service.

Encryption in transit
It is a best practice to use only encrypted connections between application components, and from the client to the application. To protect data in transit, AWS encourages customers to leverage a multi-layered approach. Within the AWS Cloud, traffic between AWS data centers is transparently encrypted at the physical layer. Customers can implement application layer encryption using a protocol like Transport Layer Security (TLS). AWS service endpoint’s support TLS to create a secure HTTPS connection to make API requests.

AWS PrivateLink is a service that can privately connect a VPC to services and resources as if they were in the VPC, without an internet gateway, NAT device, public IP address, or AWS Direct Connect connection. Additionally, Amazon Bedrock only allows encrypted connections to the service. It is a best practice to follow our AWS Well-Architected Framework security pillar for protecting data in transit.

Logging and auditing
Set up monitoring and logging using both Amazon CloudWatch and AWS CloudTrail and encrypt log data stored in Amazon S3. Avoid having monitoring data include any ePHI, and where unavoidable make sure that encryption and access controls are in place for the log data. Use Amazon Macie to scan log data on Amazon S3 for personally identifiable information (PII) and ePHI. For additional information reference Data protection in Amazon CloudWatch Logs and Amazon SageMaker AI logging and monitoring.

Resiliency and backup
Implement a comprehensive data management and backup plan to confirm that all ePHI data is properly stored, backed up, and accessible in the event of a disaster or other incident. This may include the use of Amazon S3 or other HIPAA eligible storage services. For data stored in managed databases such as Amazon RDS, these services offer multi-availability zones (multi-AZs) and multi-Region features for maximum resiliency. For self-managed databases on Amazon EC2 instances, we recommend implementing a resilient architecture across availability zones or Regions for your security needs.

In addition to built-in multi-AZ fault tolerance, SageMaker AI supports cross-Region replication, provides built-in logs and metrics for comprehensive monitoring, and supports multi-variant model hosting for a Blue/Green deployment. For more guidance, refer to the AWS Well-Architected Framework reliability pillar and learn how to automate backup at scale across AWS services using AWS Backup.

LLM model restrictions
It is important to protect the data used for large language model (LLM) building and customization. For any model you are leveraging on Amazon Bedrock (including any first-party, third-party or AWS Marketplace models) it is important legal teams verify restrictions within the terms and acceptable use policies (AUP) for these models. There may be product restrictions or requirements (such as requiring human-in-the-loop) for certain HCLS use cases. For example, Anthropic lists additional requirements for high-risk use cases.

LLM model training
If your solution involves training a custom LLM using SageMaker AI, consider whether PII and ePHI can be included in the training data and what controls will be necessary to maintain security. You may need to remove PII and ePHI from training data so that the model will be incapable of returning a response that includes such restricted data.

If the training data includes PII and ePHI, appropriate guardrails must be set up to verify that any responses including PII and ePHI are properly handled to control access to the data. For additional security, consider large language model inference over confidential data using AWS Nitro Enclaves. Also review the HHS guidance regarding methods for de-identification of protected health information in accordance with the HIPAA privacy rule.

RAG data sources
With retrieval-augmented generation (RAG), an additional data source (usually proprietary company data) is used to enhance the prompt sent to the LLM. That data is processed by the LLM and may be included (in some form) in the LLM response, but will not be stored by or incorporated into the LLM after processing. If the RAG data sources include ePHI, it’s important to facilitate proper controls on that data (for example, guardrails to prevent a user accessing unauthorized data through the generative AI prompt). Consider removing PII from conversations by using sensitive information filters.

Prompt engineering and guardrails
If your application provides the user the ability to directly query the LLM, include guardrails to prevent users from making unauthorized queries or jailbreaking the LLM into providing unapproved responses. SageMaker AI and Amazon Bedrock Guardrails are highly configurable and can be used to help identify and filter ePHI. Your application should be thoroughly tested for all scenarios including prompt injection attacks. Learn how to build safe and responsible generative AI applications with guardrails.

Agentic AI
Some use cases may benefit from agentic AI capabilities within the generative AI solution. It fuses the decision-making and goal-directed behavior of agents with the language understanding and generation capabilities of LLMs to accomplish tasks. AWS provides healthcare organization flexibility for how to approach building agents, from fully managed Amazon Bedrock Agents with built-in compliance controls to the open-source SDK Strands Agents for custom development.

Healthcare organizations may lean towards open-source frameworks running on AWS to control more of the underlying components of an agentic solution, such as memory. Each approach requires different levels of oversight and validation processes. Data protection, access management, and audit logging remain key focus areas when leveraging these advanced automation capabilities.

Response validation
In addition to guardrails on AI prompt inputs, LLM responses can be reviewed and filtered using built-in or customized guardrails. In some cases, a human-in-the-loop approach may be necessary to minimize the risk of inadvertent ePHI disclosure.

Amazon Comprehend can be integrated with a generative AI solution to provide PII detection and trust and safety protections, which can reject responses with unacceptable content. You can also prevent factual errors from LLM hallucinations with mathematically sound Automated Reasoning checks.

Responsible AI
While technical controls like response validation are important, they’re one part to approaching responsible AI implementation. Healthcare organizations adopting generative AI face unique challenges in verifying ethical and safe outputs for both patients and providers. A responsible AI strategy should begin with clear policies and guidelines to build a framework for AI development and deployment within the organization. It should establish AI policy for the organization before exploring use cases so teams can reference back to the AI policy as they build. It’s important for healthcare organizations to make informed decisions about which services from AWS, as well as which LLMs, align with the organizations’ responsible AI goals.

AWS AI Service Cards, available for most AWS-hosted LLMs, are a resource to enhance transparency with a single place to find information on the intended use cases and limitations, responsible AI design choices, and performance optimization best practices. LLM providers may provide foundation model cards offering key information about model characteristics, intended use, and limitations to support responsible AI implementation.

When selecting use cases, teams should evaluate potential impacts and conduct risk assessments to define appropriate limitations for AI application in clinical settings or when working with patient data. For an example review the Anthropic system card for Claude 4.

Building responsible AI solutions requires careful attention to your training datasets, as data quality drives AI solution success. Focus on data diversity while implementing robust data cleansing and auditing processes. To maintain high quality training datasets and mitigate bias in the data, Amazon SageMaker Clarify can be used to detect potential bias in your datasets and model outputs. Teams can measure and improve fairness throughout the machine learning (ML) lifecycle. Further, models deployed for healthcare use cases should demonstrate both fairness and transparency in decision-making processes.

Model explainability is a feature of Amazon SageMaker Clarify and provides consumers of generative AI applications a way to understand how a model or AI application reached a response. While Amazon SageMaker Model Monitor tracks production metrics including model quality and bias drift.

Success with responsible AI requires collaboration across the organization and when working with AI providers, it’s important to understand their solution’s capabilities and limitations. Whether healthcare organizations are building custom models, consuming AI services or LLMs hosted on AWS, organizations should invest in staff training, participate in industry discussions and maintain diverse teams to identify potential bias in training datasets.

Design review
As with any new deployment, you should conduct a thorough review of your solution against the AWS Well-Architected Tool before deploying any ePHI. Consider leveraging AWS Professional Services or an AWS generative AI Competency Partner for an objective and comprehensive review. You might also want to explore the generative AI Application Builder on AWS to accelerate your development process.

Conclusion

While the integration of generative AI solutions in healthcare presents exciting opportunities for innovation and improved patient care, it also brings unique challenges in maintaining HIPAA compliance. By leveraging AWS services such as Amazon SageMaker AI and Amazon Bedrock, healthcare companies can confidently deploy secure, scalable, and compliant generative AI applications.

The key to success lies in understanding the Shared Responsibility model, implementing robust security measures, and following best practices for data protection, access control, and monitoring. The field of generative AI will continue to evolve. Staying informed about the latest developments in both technology and regulatory requirements will be crucial for healthcare organizations aiming to harness the power of AI, while safeguarding patient privacy and data security.

Contact an AWS Representative to know how we can help accelerate your business.

Further reading

• Learn how AWS helps healthcare organizations improve patient care
• How to safeguard healthcare data privacy using Amazon Bedrock Guardrails
• Responsible AI – Building AI Responsibly
• Navigating the security landscape of generative AI
• DMEA 2025 Exhibition Highlight AWS: Cloud technology for the future of healthcare