Healthcare organizations that want to automate document processing with AI land in the same spot: "this only works if it is HIPAA‑compliant." That phrase gets used loosely. Here is what it actually means and what to check when evaluating a document processing platform.
This guide is written for operations and IT leaders — not lawyers. If you have specific questions about your particular deployment, talk to your privacy officer and your vendor's compliance team.
What HIPAA actually requires
HIPAA's Security Rule breaks into three control families:
- Administrative safeguards. Policies, training, access management, incident response.
- Physical safeguards. Facility access, workstation security, device disposal.
- Technical safeguards. Access control, audit logs, integrity, transmission security.
For an AI document processing vendor, the practical implications are:
- You need a Business Associate Agreement (BAA) with the vendor, because they handle Protected Health Information (PHI).
- The vendor must have access controls (SSO/SAML, MFA, role‑based permissions).
- Audit logs must record who accessed what and when.
- Encryption in transit and at rest is required.
- Data retention and disposal must be policy‑driven, not ad hoc.
- Workforce training for anyone touching PHI.
For the broader security picture, see document security for teams: access controls that actually matter.
What PHI looks like in documents
PHI is not just patient names. It includes 18 identifiers defined by HIPAA, any of which makes a record a PHI record:
- Names, addresses (below the state level), dates (birth, admission, discharge, death), phone numbers, fax numbers, email addresses, Social Security numbers, medical record numbers, health plan beneficiary numbers, account numbers, certificate numbers, vehicle identifiers, device identifiers, URLs, IP addresses, biometric identifiers, photographs, and any other unique identifier.
Most healthcare documents — intake forms, claims, EOBs, lab reports, referral letters, handwritten notes — contain multiple of these. Processing them with AI means PHI passes through the AI pipeline. That is why the BAA matters.
The BAA question
A Business Associate Agreement is a legal contract that makes the vendor responsible for HIPAA compliance on the PHI they process on your behalf. Without a BAA, processing PHI on a vendor's platform is a HIPAA violation — full stop.
What to ask every vendor:
- Do you sign a BAA, and does it cover all of the services I would use?
- Is the BAA available to all customer tiers, or only enterprise?
- Does the BAA cover all subprocessors (including AI model providers)?
That third question matters. Most AI document processing platforms use third‑party AI providers — OpenAI, Anthropic, Google, Azure OpenAI, AWS Bedrock. The vendor's BAA only protects you if they have upstream BAAs with those providers.
Heads up
Running PHI through a public OpenAI API key (or any provider without a signed BAA) is a HIPAA violation, regardless of what your SaaS vendor promises. Always confirm the full chain — your BAA with the vendor, their BAA with the model provider.
The AI model question
Not all AI models are HIPAA‑eligible, even when the underlying provider is. Two common patterns:
- Azure OpenAI with a BAA. Microsoft signs BAAs for Azure OpenAI Service. Models provisioned inside your Azure tenant can be HIPAA‑eligible if configured correctly.
- AWS Bedrock with a BAA. AWS signs BAAs for Bedrock. Specific foundation models are HIPAA‑eligible; others are not.
PaperAI runs on Azure OpenAI via an enterprise Azure tenant, with no model training on customer data and no logging of prompts/completions beyond what is required for billing and abuse prevention. That is the architecture that makes HIPAA‑eligible document processing possible.
For more on model selection, see how to choose an AI model for document processing.
Access controls: the minimum bar
A HIPAA‑aligned document platform needs to enforce access controls that limit PHI exposure to the minimum necessary:
- SSO / SAML via your identity provider (Okta, Entra ID, Google Workspace).
- Role‑based access control (owner, admin, member, reviewer) with the ability to restrict access to specific folders or document types.
- MFA required for all privileged accounts.
- Session timeouts aligned with your policy.
- IP allowlisting for admin actions, optional for general access.
If a vendor can only enforce access by "everyone in the workspace sees everything," that does not meet minimum necessary access for larger deployments. For how PaperAI does this see our team workspaces docs.
Audit logs
Every PHI access — view, extract, approve, download, delete — needs to land in an audit log that:
- Records who (user ID), what (document ID, action), and when (timestamp).
- Is tamper‑evident (append‑only, ideally with hash chains).
- Is retained per your policy (often 6 years for HIPAA).
- Is exportable for your own SIEM / compliance tooling.
This is the boring part of HIPAA, and the part auditors care about most.
Data retention and disposal
Define up front:
- How long do documents live in the platform after processing?
- Are deleted documents purged from backups, and on what schedule?
- What happens to documents if your contract ends?
A platform that does not give you explicit controls on retention is a platform that will eventually be a compliance problem.
See data retention policies for AI‑processed documents for the operational playbook.
The HIPAA checklist for evaluating a document AI vendor
Use this when talking to any vendor:
Legal
- [ ] BAA available at your plan tier
- [ ] Subprocessor list with upstream BAAs in place
- [ ] Data Processing Agreement for any non‑US customers
Security architecture
- [ ] Encryption in transit (TLS 1.2+) and at rest (AES‑256)
- [ ] SSO/SAML support
- [ ] MFA enforced for privileged users
- [ ] Role‑based access control with folder/document scoping
- [ ] Tamper‑evident audit logs
AI model handling
- [ ] HIPAA‑eligible AI model (confirm with upstream provider)
- [ ] No training on customer data
- [ ] No retention of prompts/outputs beyond what you configure
- [ ] Regional deployment options if required
Operational
- [ ] Incident response and breach notification process
- [ ] Data retention controls configurable by you
- [ ] Export and deletion on demand
- [ ] Uptime SLA appropriate for clinical workflows
Third‑party assurance
- [ ] SOC 2 Type II report available (or equivalent)
- [ ] HIPAA Security Rule gap assessment
- [ ] Penetration test summary
Where PaperAI fits
PaperAI's architecture supports HIPAA‑aligned deployments:
- Runs on Azure OpenAI via a dedicated enterprise tenant — Microsoft signs BAAs for this service.
- No customer data used for model training.
- SSO/SAML (Enterprise), RBAC, audit logs.
- Region options for data residency.
- BAA available on qualifying plans.
If you process PHI — intake forms, claims, medical records, referral letters — this is the architecture you want. For the healthcare use case in depth see document processing for insurance companies and document digitization in healthcare.
Tip
Before going to production with PHI, run a tabletop exercise: simulate a breach of one document and walk through your notification obligations. This usually reveals gaps in the operational side that no checklist will catch.
Summary
HIPAA‑compliant document processing with AI is real and deployable in 2026, but only on platforms that have the right architecture and paperwork in place. Check for four things: a signed BAA with your vendor, upstream BAAs with any AI model providers they use, enforced access controls with audit logs, and configurable data retention. Vendors that cannot answer those four questions clearly are not ready for PHI.
Ready to evaluate? Talk to our team about a HIPAA‑aligned PaperAI deployment, or start free on non‑PHI documents while the BAA process runs in parallel.
This article is general guidance, not legal advice. Work with your privacy officer and legal counsel on specific compliance decisions.