HIPAA-ready AI-built apps: what to check before you handle patient data

Key takeaways

• HIPAA has no official certification. An AI-built app is compliant only when the platform, the hosting, and the way your team uses it all meet HIPAA rules.
• Every vendor that stores or processes protected health information (PHI) for you must sign a Business Associate Agreement (BAA). That includes the AI model provider.
• IBM's 2026 research found that healthcare breaches cost $6.64 million on average, the highest of any industry for the 13th year in a row.
• AI adds new places where PHI can leak, such as prompts, logs, and model training data.
• HHS's proposed HIPAA Security Rule update is still not final, but its focus on encryption and multi-factor authentication shows where expectations are heading.

AI app builders let a clinic or health startup build an intake form, a referral tracker, or a patient follow-up tool in a day. The next question is whether that app can safely hold patient data.

The answer depends on more than the app itself. HIPAA compliant AI apps need a compliant platform, a signed BAA with every vendor that touches patient data, and controls that your team actually uses. This guide covers what to check before an AI-built app handles real patient information.

Key numbers at a glance

• Healthcare data breaches cost an average of $6.64 million in 2026, according to IBM's Cost of a Data Breach Report, as reported by Becker's Hospital Review. No other industry costs more.
• The same report found that AI-driven attacks rose 56% year over year and added about $1 million to the cost of a malicious breach. AI features in your own apps need the same scrutiny.
• 53% of breached organizations had not encrypted sensitive data at rest and in transit, according to IBM's 2026 findings summarized by Saul Ewing. Encryption is one of the simplest checks on this list.

What makes an AI app HIPAA compliant?

An AI app is HIPAA compliant when it protects patient data according to the HIPAA Privacy Rule and Security Rule, and every vendor in the chain has signed a BAA. There is no government certificate for this. HHS does not certify software, so a "HIPAA certified" badge on a website is a marketing claim, not an official status.

HIPAA applies to two groups:

• Covered entities: Healthcare providers, health plans, and clearinghouses that handle patient data.
• Business associates: Vendors that create, receive, store, or send PHI for a covered entity, such as a software platform or a cloud host.

Protected Health Information (PHI) is any health information that can identify a person. Names, dates, phone numbers, email addresses, and medical record numbers all count when they are linked to health data.

The HIPAA Security Rule sets the safeguards for electronic PHI. It groups them into administrative safeguards like risk analysis and staff training, physical safeguards like device and facility controls, and technical safeguards like access control, audit logs, and encryption.

HIPAA compliant software is software that can be set up and used in a way that meets these rules. The same tool can be compliant in one setup and non-compliant in another.

Where do AI-built apps create new HIPAA risks?

AI-built apps follow the same rules as any other software. They also create new places where patient data can end up, and most of those places sit behind the screens users see. That makes healthcare data security harder to check by looking at the app alone.

Common risk points include:

• Prompts: Staff may paste patient details into an AI feature. If that prompt goes to a model provider without a BAA, PHI has left your control.
• Logs: Prompt and response logs often store full patient details. They need the same protection as the main database.
• Model training: Some AI services use customer data to improve their models. PHI should never be used this way without the right agreements and de-identification.
• Generated output: AI summaries and drafts can contain PHI and may be emailed, exported, or shared without the same controls.
• Third-party connectors: Integrations with email, messaging, or storage tools may send PHI to services that are not covered by a BAA.
• Broad access: An app built quickly may give every user access to every record.

For AI data privacy, map where patient data travels and confirm that every stop is covered.

HIPAA compliance checklist for AI-built apps

HIPAA-compliant app development starts before the first screen is built. Use this checklist before an AI-built app stores or processes real patient data. The first six checks cover the platform and infrastructure. The next six cover the AI features.

1. Signed BAAs with every vendor

Get a signed Business Associate Agreement (BAA) from the app platform, the cloud host, and any AI model provider that receives PHI. If a vendor will not sign one, do not send it PHI.

2. HIPAA-eligible hosting

Confirm the app runs on HIPAA-compliant cloud services covered by a BAA. Major cloud providers publish lists of HIPAA-eligible services, so check that every service your app uses is on that list.

3. Encryption at rest and in transit

All PHI should be encrypted when it is stored and when it is sent. Ask which encryption standards the platform uses and who manages the keys.

4. Role-based access controls

Each user should see only the patient data their role needs. Strong healthcare data access controls limit records by role, team, or location and remove access quickly when someone leaves.

5. Multi-factor authentication

Require MFA for every user who can access PHI. HHS's proposed Security Rule update would make it mandatory, and many cyber insurers already expect it.

6. Audit logs

The app should record who viewed, created, changed, or exported each patient record and when. Logs should be protected from editing and kept for your full retention period.

{CTA button:Start building free:https://www.codeblox.com/sign-up:Build healthcare apps with role-based access and audit trails from day one.}

AI-specific checks for healthcare apps

These checks protect patient data privacy in the areas that traditional software reviews often miss.

7. Know which AI model processes PHI

List every AI feature in the app and the model provider behind it. Confirm that each provider has signed a BAA and does not keep or train on your data.

8. Keep PHI out of prompts where you can

Design AI features to use only the data they need. A scheduling assistant may need a date and a clinic location, not a diagnosis.

9. De-identify data for testing and analytics

Use de-identified data for testing, demos, and analytics. HIPAA recognizes two methods: removing 18 specific identifiers or getting an expert to confirm that the risk of re-identifying anyone is very small.

10. Protect AI logs and outputs

Treat prompt logs, summaries, and generated documents as PHI. Store them with the same encryption, access rules, and retention policies as patient records.

11. Keep a person in charge of clinical decisions

AI suggestions that affect patient care should be reviewed by a qualified person before anyone acts on them. Record who approved what.

12. Add approval steps to automated actions

When AI triggers actions such as sending reminders or updating records, it routes sensitive steps through an approval rule. AI workflow automation with built-in approvals and logging keeps healthcare application development fast without skipping checks.

How does AI risk assessment support healthcare software compliance?

The HIPAA Security Rule already requires a risk analysis. An AI risk assessment extends that analysis to cover how AI features use, store, and share patient data.

A practical AI risk assessment answers these questions:

• Data flow: Which AI features touch PHI, and where does that data go?
• Vendors: Which providers process PHI, and have each one signed a BAA?
• Impact: What happens if the AI gives a wrong answer or exposes data?
• Controls: Which safeguards reduce each risk, and who checks them?
• Review cycle: How often is the assessment repeated, especially after a new AI feature launches?

What AI governance in healthcare looks like in practice

AI governance in healthcare means having clear rules for which AI tools staff may use, who approves new AI features, and how problems are reported. Even a small clinic benefits from a one-page AI policy and a named owner.

Healthcare software compliance is ongoing work. Each new feature, integration, or vendor should go through the same review before it touches patient data.

Questions to ask an AI app platform before you build

Before choosing a platform, ask for written answers to these questions:

• Will you sign a BAA, and which services and plans does it cover?
• Where is patient data hosted, and is that hosting covered by a BAA with the cloud provider?
• Which AI model providers process our data, and do they keep it or train on it?
• How is data encrypted at rest and in transit?
• Can we set permissions by role, record, or field?
• Do audit logs capture views, edits, and exports, and how long are they kept?
• How do we export or delete our data if we leave?

If a vendor cannot answer clearly, treat that as a warning sign. Teams building HIPAA-ready AI applications should have these answers in hand before any patient data goes into the system.

Is a HIPAA compliant platform enough on its own?

No. A compliant platform and HIPAA compliant cloud services give you the right foundation, and your organization is still responsible for how the app is set up and used.

Your team still needs to:

• Set permissions correctly for each role.
• Train staff on what data can go into AI features.
• Review access and audit logs on a regular schedule.
• Report and respond to breaches within HIPAA's notification deadlines.
• Keep policies, risk assessments, and BAAs up to date.

Healthcare cybersecurity also goes beyond HIPAA. State privacy laws may add their own rules, especially for apps that serve patients in several states.

What about the proposed HIPAA Security Rule update?

HHS proposed a major update to the Security Rule in January 2025. It would make encryption, MFA, and regular vulnerability testing mandatory. As of October 2026, the update is still not final, and HHS now targets July 2027 for final action, so the current Security Rule remains in force. Building to the proposed standard now means less rework if it is finalized.

‍