In February 2024, the Office for Civil Rights settled with Montefiore Medical Center for $4.75 million. An employee had stolen and sold protected health information from over 12,000 patients. The data included names, addresses, Social Security numbers, and medical information.
The breach itself was bad. What made it worse was that Montefiore's internal controls failed to catch it for years. The employee accessed records they had no business viewing, and the audit systems that should have flagged this behavior didn't exist or didn't work.
This was OCR's largest HIPAA settlement of 2024. But here's what makes it relevant to AI: the core failures were access control and audit logging. The same two things that break when you start feeding patient documents into Claude or ChatGPT.
The Change Healthcare breach later that year affected over 100 million patients and cost an estimated $2.87 billion. The attack vector was a lack of multi-factor authentication. Basic security hygiene failures at massive scale.
These aren't exotic attacks. They're failures of fundamental security controls. And when your "AI strategy" involves employees pasting clinical notes into consumer AI tools, you're creating the same category of exposure.
The short version: If you need to redact sensitive documents before they reach AI systems, PaperVeil handles that layer. The rest of this article explains where it fits in the broader governance architecture.
What HIPAA Actually Requires for AI
HIPAA wasn't written with AI in mind. The Privacy Rule dates to 2000, the Security Rule to 2003. But the requirements apply whether you're using a filing cabinet or a large language model.
In January 2025, HHS OCR proposed the first major update to the HIPAA Security Rule in twenty years. The proposed changes explicitly address modern technology, including AI systems. Until those changes are finalized, here's what the current requirements mean for AI document processing.
The 18 PHI Identifiers
Protected Health Information under HIPAA includes health information combined with any of these 18 identifiers:
- Names
- Geographic data smaller than a state
- All dates (except year) related to an individual
- Phone numbers
- Fax numbers
- Email addresses
- Social Security numbers
- Medical record numbers
- Health plan beneficiary numbers
- Account numbers
- Certificate and license numbers
- Vehicle identifiers and serial numbers
- Device identifiers and serial numbers
- Web URLs
- IP addresses
- Biometric identifiers
- Full-face photographs
- Any other unique identifying number, characteristic, or code
A single clinical note can easily contain a dozen of these. Patient name, date of birth, medical record number, diagnosis dates, treatment dates, phone number for the callback. Process that document through an AI that isn't HIPAA-compliant, and you've likely committed a violation.
Business Associate Requirements
Any entity that handles PHI on behalf of a covered entity is a business associate. This includes AI vendors.
When you send patient data to OpenAI, Anthropic, or Google for processing, those companies become business associates. You need a Business Associate Agreement (BAA) in place before any PHI touches their systems.
Here's the problem: consumer tiers of AI tools don't offer BAAs. ChatGPT Free, Claude Pro, Gemini personal accounts: none of these have BAA coverage. Using them with PHI is a violation, full stop.
Enterprise tiers are different. OpenAI offers BAAs for Enterprise customers. Anthropic's Claude for Healthcare launched in January 2026 with HIPAA-ready infrastructure. But even with enterprise tiers, you need to verify the specific data handling terms and ensure your configuration matches compliance requirements.
The Minimum Necessary Standard
HIPAA requires that you limit PHI access to the minimum necessary for the intended purpose. This applies to AI processing too.
If you're using AI to summarize a clinical note, do you need to send the full patient name? The Social Security number? The complete address? In most cases, no. The AI can work with placeholders just as well as real identifiers.
This is where redaction becomes not just a security measure but a compliance requirement. Sending more PHI than necessary to an AI system violates the minimum necessary standard.
Audit Controls
The Security Rule requires audit controls that record and examine access to PHI. When you use AI to process patient documents, you need to log:
- What data was sent
- When it was sent
- Who authorized the processing
- What AI system received it
- What the system returned
Most AI workflows don't have this. A staff member pastes text into a chat window, gets a response, and there's no record of what PHI was transmitted.
Why AI Creates HIPAA Exposure
The core problem is data transmission. When you send a document to an AI for processing, that data leaves your control. It travels over the internet to servers you don't manage, operated by companies whose internal security practices you can't audit.
Consumer AI Tiers
Consumer tiers of AI tools are explicitly not HIPAA-compliant. Here's what that means in practice:
Data retention: Most consumer AI services retain conversation data for weeks or months. That clinical note you pasted? It's sitting on their servers.
Training data: Consumer accounts may have data used for model training. Even if the company says they "filter sensitive data," you're trusting their filtering to catch every PHI element. They won't.
Access controls: Consumer accounts don't have the access logging, SSO integration, or admin controls needed for HIPAA compliance.
No BAA: Without a Business Associate Agreement, using the service with PHI is a violation regardless of their technical security.
Enterprise AI Tiers
Enterprise tiers address many of these issues but create their own compliance considerations:
BAA availability: Enterprise tiers typically offer BAAs, but you need to actually execute one. Having an enterprise account doesn't automatically mean you're covered.
Configuration requirements: Many enterprise AI services require specific configurations for HIPAA compliance. Zero data retention settings, specific deployment regions, particular feature restrictions. If you're not configured correctly, the BAA may not apply.
Transmission exposure: Even with a BAA, data still transmits to external servers. Your privacy notices and patient consent practices need to account for this.
Shadow AI
The biggest compliance risk isn't your official AI deployment. It's the 71% of healthcare workers who admit to using personal AI accounts for work.
Staff members paste patient notes into ChatGPT because it's faster than your approved workflow. They upload documents to Claude because the official system is down. They use Gemini to help draft a patient letter because the enterprise tool doesn't have the feature they need.
Each of these creates HIPAA exposure. And you have no audit trail, no BAA, no technical controls.
Where Your Data Goes
Let's trace the path of a clinical note processed through a typical AI workflow.
Step 1: User input. A staff member copies text from the EHR and pastes it into an AI chat interface. The full note, including patient name, MRN, dates, diagnoses.
Step 2: Transmission. The text travels over HTTPS to the AI provider's servers. It passes through your network, your ISP, potentially multiple CDN nodes, and eventually reaches the AI company's infrastructure.
Step 3: Processing. The AI processes the request. The data exists in memory on their servers while the request is being handled.
Step 4: Storage. Depending on the service tier and settings, the conversation may be logged. It might be stored for troubleshooting, for abuse detection, or for model training. Retention periods vary from days to years.
Step 5: Response. The AI sends back a response. This response may include or reference the original PHI.
At every step, the data exists on systems you don't control. Staff at the AI company might have access for support purposes. The data might be used in aggregate analysis. It might persist in backups long after the retention period officially expires.
For HIPAA compliance, you need to either control this entire data flow or ensure it doesn't contain PHI in the first place.
Building a Compliant AI Workflow
There are three paths to HIPAA-compliant AI document processing:
Path 1: Enterprise AI with Full Compliance Stack
Use a HIPAA-ready AI service with proper agreements and configuration:
- Select an AI provider with HIPAA-eligible offerings (OpenAI Enterprise, Claude for Healthcare, Azure OpenAI)
- Execute a Business Associate Agreement
- Configure zero data retention where available
- Deploy through approved interfaces only
- Implement access controls and audit logging
- Train staff on approved usage patterns
- Update privacy notices to disclose AI processing
This is the straightforward path if you're committed to a specific AI vendor. The trade-off is vendor lock-in and typically significant cost.
Path 2: Cloud Provider Deployment
Deploy AI within your existing HIPAA-compliant cloud infrastructure:
- Use Claude via AWS Bedrock, Azure OpenAI, or Google Cloud Vertex AI
- Configure within your existing compliance boundary
- Apply your standard access controls and audit logging
- Data stays within your cloud environment
- Inherit your existing BAA with the cloud provider
This works well if you already have mature cloud security. The AI becomes another workload within your existing compliance framework.
Path 3: Redact Before Processing
The most flexible approach: remove PHI before data reaches any AI system.
- Build a preprocessing layer that detects and redacts PHI
- Replace identifiers with consistent placeholders
- Send redacted content to any AI (even consumer tiers)
- Re-associate outputs with original identifiers if needed
- AI never sees actual PHI
This approach decouples AI capability from PHI exposure. You can use any AI tool because the data isn't protected health information anymore. It's just text with placeholders.
Implementation Checklist
Here's a step-by-step implementation for the redaction approach:
Step 1: Document Ingestion
Define your input sources:
- EHR system exports
- Scanned documents via OCR
- Email attachments from patient portals
- Faxed documents (yes, healthcare still uses faxes)
Build or configure an intake pipeline that routes documents to your redaction system before any AI processing.
Step 2: PHI Detection
Implement multi-layer detection:
Pattern matching: Regular expressions for structured data. SSNs follow XXX-XX-XXXX. MRNs follow your organization's format. Phone numbers, emails, and dates all have recognizable patterns.
Named entity recognition: ML models that identify names, addresses, and other entities that don't follow predictable patterns.
Custom rules: Your organization has unique identifiers. Patient account numbers, policy numbers, physician IDs. Add detection rules for your specific patterns.
Contextual analysis: "Smith" alone might not be PHI. "Patient Smith" definitely is. Consider surrounding context when flagging ambiguous terms.
Step 3: Consistent Redaction
Replace each detected identifier with a consistent placeholder:
[PATIENT-1]for patient names[MRN-1]for medical record numbers[DOB-1]for dates of birth[PHONE-1]for phone numbers[ADDRESS-1]for addresses
Consistency matters. If "John Smith" appears five times in a document, all five instances should become [PATIENT-1]. This preserves the document's logical structure while removing identifying information.
Step 4: AI Processing
Send the redacted document to your AI with instructions that acknowledge the placeholders:
Summarize this clinical note for the care coordination team.
Note: Patient identifiers have been replaced with placeholders.
Maintain these placeholders in your output.
[Redacted clinical note content]
The AI processes the content and returns output containing only placeholders where PHI would appear.
Step 5: Output Handling
If you need to reconstitute identifiers (for a patient letter, for example), your secure system maps placeholders back to original values. This happens within your controlled environment. The AI never saw the actual PHI.
Step 6: Audit Trail
Log everything:
- Document received (timestamp, source, document type)
- PHI detected (count and types of identifiers found)
- Redaction applied (mapping of original values to placeholders)
- AI processing (which service, what prompt, what response)
- Output handling (whether identifiers were reconstituted, who accessed)
This audit trail is essential for compliance documentation and breach response. If OCR asks what happened to a particular patient's data, you can show exactly how it was handled.
Documentation Requirements
HIPAA requires documentation of your security practices. For AI workflows, this means:
Policies and Procedures
Document your AI usage policies:
- Which AI tools are approved
- What types of data can be processed
- Who can authorize AI processing
- How requests are logged and audited
Risk Analysis
Before deploying AI with any patient data, conduct a risk analysis:
- What PHI will the system access?
- How is data transmitted and stored?
- What are the potential risks?
- What controls mitigate those risks?
- What residual risk remains?
The proposed Security Rule updates make risk analysis even more explicit. Organizations will need to maintain written risk analyses and demonstrate that they've addressed identified risks.
Training Documentation
Document that staff understand AI compliance requirements:
- What training was provided
- Who completed training
- When training occurred
- What topics were covered
Incident Response
Have a documented plan for AI-related incidents:
- How to identify a potential breach involving AI
- Who to notify
- How to assess scope
- Breach notification procedures
OCR takes documentation seriously. In enforcement actions, organizations that can't produce documentation of their security practices face harsher penalties.
The Cost of Getting This Wrong
OCR collected $9.9 million in HIPAA penalties across 22 enforcement actions in 2024. Beyond Montefiore's $4.75 million, penalties included:
- Heritage Valley Health System: $950,000 for ransomware-related failures
- Plastic Surgery Associates of South Dakota: $500,000 for no risk analysis
- Green Ridge Behavioral Health: $40,000 for access failures
The common thread in most enforcement actions is failure of basic controls. Risk analysis not conducted. Access controls not implemented. Audit logs not maintained. Training not documented.
AI doesn't change these requirements. It just adds another vector where the same failures can occur. If you're not logging who uses your AI systems, you have the same exposure as Montefiore. If you're not conducting risk analysis before AI deployment, you have the same exposure as Plastic Surgery Associates.
Moving Forward
HIPAA compliance for AI isn't optional, and it isn't going away. The proposed Security Rule updates make AI considerations more explicit. Enforcement continues to increase. Breach costs continue to rise.
The organizations getting this right share common characteristics:
- They've defined approved AI use cases with clear boundaries
- They've deployed technical controls alongside policy
- They've trained staff on both approved tools and the risks of shadow AI
- They've built audit capability into AI workflows from the start
- They treat AI compliance as continuous, not one-time
The organizations at risk are the ones assuming that enterprise licensing equals compliance. It doesn't. The gap between "we have an enterprise account" and "we're actually HIPAA-compliant" is where breaches happen.
If you're using AI in healthcare today, audit your current state. Who's using what tools with what data? Then build the architecture that makes compliant usage the default, not the exception.
PaperVeil lets you redact all your sensitive information from PDFs in a simple drag and drop flow. Detect and remove PII, match custom patterns, strip metadata, and generate audit trails. The redaction layer that makes AI document processing actually safe.