Yes, AI can be used in HIPAA-compliant ways, but only when PHI handling, contracting, and technical safeguards meet specific requirements. There is no such thing as a HIPAA-certified AI product, since HHS does not certify software. There is only a defensible combination of a signed Business Associate Agreement, documented technical safeguards, and an audit trail that would survive a records subpoena or an Office for Civil Rights (OCR) inquiry.
For anyone reviewing medical records under workers' compensation, personal injury, or med-legal deadlines, the stakes are immediate. If a paralegal pastes a claimant's psychiatric history into a public chatbot to summarize it, that record may now sit on a server with no contract governing its use, no audit log, and no guarantee it will not train a future model. That is a reportable exposure, not a shortcut.
Three things need to happen before AI touches a single page of protected health information (PHI):
- Stop sending PHI to any AI tool that has not signed a BAA covering that specific use case.
- Start or update a security risk analysis (SRA) that names AI tools as a distinct risk category.
- Confirm that any BAA in place explicitly covers sub-processors, not just the primary vendor.
The NIST AI Risk Management Framework offers a workable structure for that risk analysis, and OCR's own guidance on sharing mental health information makes clear that the Privacy Rule does not relax just because a tool is labeled "AI." ChartInsight's accuracy testing shows what a defensible alternative looks like in practice: structured outputs where every fact traces back to a specific page in the source record.
Key Takeaways
HIPAA-compliant AI use depends on a signed BAA, documented technical safeguards, and an audit trail that can withstand an OCR review or a deposition challenge.
| Point | Details |
|---|---|
| No AI is HIPAA-certified | Compliance depends on contracts and controls, not a vendor's marketing claim. |
| BAAs must name sub-processors | A generic corporate BAA that omits the AI feature or its downstream vendors leaves gaps. |
| Psychotherapy and Part 2 records need separate handling | Explicit authorization and segregated workflows apply, with the Part 2 compliance deadline set for February 16, 2026. |
| Redaction before ingestion beats after-the-fact masking | Pre-ingestion PHI detection prevents exposure to training pipelines entirely. |
| ChartInsight page-cites every extracted fact | Reviewers verify chronologies, vitals, and medication tables against the source PDF without leaving the platform. |
Table of Contents
- How HIPAA Applies to AI Tools That Touch PHI
- Vendor Evaluation Checklist Before Approving AI for PHI
- Handling Psychotherapy Notes and 42 CFR Part 2 Records
- Technical Safeguards AI Systems Need Under the Security Rule
- Contracting and Breach Response for AI Vendors
- Rolling Out a HIPAA-Compliant AI Pilot Step by Step
- What ChartInsight's Accuracy Studies Show
- What the Compliance Playbook Gets Wrong
- A Citation-First Way to Handle Med-Legal Record Review
- Sources
- FAQ
How HIPAA Applies to AI Tools That Touch PHI
The first question compliance officers need answered is not "is this AI good?" It's "what role does HIPAA assign to this vendor, and does that role match what the vendor is actually doing with the data?"
A covered entity is the hospital, clinic, insurer, or provider that holds the PHI in the first place. A business associate is any vendor that creates, receives, maintains, or transmits PHI on the covered entity's behalf, which includes most AI tools used for transcription, summarization, or record review. If an AI vendor performs any of those functions and has not signed a BAA, the covered entity (or the law firm and claims team using the tool) is out of compliance the moment PHI is uploaded.
The trickier question for AI specifically is what counts as PHI once it passes through a model. Names, dates of birth, and medical record numbers are obvious identifiers. Less obvious: a model's output can become re-identifiable even after de-identification, particularly with rare diagnoses, unusual injury patterns, or small geographic areas where a handful of details narrow the field to one person. HHS distinguishes two paths to de-identification: the Safe Harbor method, which strips 18 specific identifier categories, and Expert Determination, which requires a qualified statistician to certify a low re-identification risk. Neither path is automatic just because a vendor claims its outputs are "anonymized."
Training data is the other trap. Some AI vendors reserve the right to use customer inputs to improve their models. If PHI enters that training pipeline, it can resurface in another customer's outputs months later; that risk alone disqualifies a huge share of consumer AI tools for clinical or legal use. Before approving any tool, confirm in writing:
- The vendor's role (business associate vs. subcontractor vs. non-covered software provider).
- Whether the tool retains or trains on submitted data, and for how long.
- Whether outputs could plausibly re-identify a patient even after redaction.
- Whether HIPAA Security Rule elements, meaning access controls, audit controls, and transmission security, are documented in the vendor's technical specifications, not just marketing copy.
Peer-reviewed analysis of AI chatbots in healthcare settings backs up the concern about training data. A review published in PMC found that developer and vendor obligations under HIPAA are frequently underspecified in consumer-facing AI products, leaving covered entities to absorb compliance risk the vendor never fully disclosed.
Vendor Evaluation Checklist Before Approving AI for PHI
Compliance officers evaluating an AI tool for medical record review need a checklist that survives an OCR audit, not a vendor's sales deck. Here is what to require, in the order it should be verified.
- A signed BAA that names the specific product, not a generic corporate BAA that predates the AI feature. Confirm the BAA explicitly covers the AI workflow itself, not just the vendor's core platform.
- Sub-processor disclosure. Ask which third-party model providers, cloud hosts, or analytics tools receive PHI downstream, and confirm each one is either covered by the primary BAA or has its own.
- A written prohibition on using customer data to train models. This should be a contract clause, not a FAQ page answer.
- Data residency and processing location. Confirm whether PHI is processed in U.S. data centers, whether it crosses borders, and whether the vendor offers private inference (a dedicated instance that does not share infrastructure with other customers) versus shared multi-tenant processing.
- Customer-managed encryption keys, where available, so the vendor cannot access decrypted PHI without the customer's involvement.
- Pre-ingestion PHI detection and redaction. Does the tool scan and mask identifiers before content reaches a model, or does raw PHI hit the model first with redaction applied afterward? The former is materially safer.
- Real-time data loss prevention (DLP) that flags or blocks unauthorized PHI transmission, not just after-the-fact reporting.
- Tamper-proof, user-attributed logs that record who accessed what record, when, and what the AI returned, retained for the HIPAA-required six years.
- Independent security attestations, such as SOC 2 Type II or, for government-adjacent work, FedRAMP authorization, plus evidence of recent penetration testing.
- Least-privilege access controls and role-based permissions, so a paralegal cannot pull records outside their assigned matters and a peer reviewer cannot access unrelated case files.
Every item on that list maps to something HHS/OCR already expects from any business associate handling PHI. AI does not get a separate, looser standard. It gets the same standard applied to a system that is harder to inspect from the outside, which is exactly why the checklist needs to be more explicit, not less.
Pro Tip: Ask the vendor for a sample audit log before you sign anything. If they can't produce one that shows a user, timestamp, source document, and page-level citation for a specific output, the tool likely wasn't built for a defensible legal or clinical record review workflow.
Enterprise offerings from major model providers illustrate both the promise and the limits here. OpenAI's healthcare-focused product line now offers BAAs, data residency controls, and a commitment not to train on customer content for eligible deployments, which is a meaningful shift from consumer ChatGPT. But "eligible deployment" is doing a lot of work in that sentence. The contract terms, configuration, and specific product tier all determine whether a given use case actually qualifies, so nothing about the underlying model name guarantees compliance.
Handling Psychotherapy Notes and 42 CFR Part 2 Records
Psychiatric and substance-use records carry protections that go beyond standard HIPAA, and treating them the same as a general medical record is one of the fastest ways to create a reportable problem.
Psychotherapy notes, meaning a treating clinician's separately maintained personal notes about a counseling session, are excluded from HIPAA's routine treatment, payment, and operations disclosures. Under 45 CFR 164.508, a covered entity generally needs a specific, signed patient authorization before disclosing them, even to another treating provider. Feeding those notes into an AI summarization tool without that authorization on file is a disclosure the patient never approved.
Substance use disorder (SUD) records carry a separate layer of federal protection under 42 CFR Part 2. A 2024 final rule aligned many Part 2 provisions with HIPAA, added breach notification requirements, and set a compliance deadline of February 16, 2026, after which OCR gains expanded authority to receive and act on Part 2 complaints. For any workers' comp or personal injury file that touches substance use treatment history, that deadline is not an academic detail. It changes how those records must be tracked, disclosed, and redisclosed starting now.
Practical controls for both categories:
- Segregate psychotherapy notes and Part 2 records into a distinct workflow with its own access list, separate from the general medical record.
- Require documented, specific authorization before any AI tool ingests either record type, and log that authorization alongside the file.
- Limit redisclosure. Part 2 records generally cannot be forwarded to a second party without a new consent, even if the first disclosure was proper.
- For the most sensitive files, consider on-premises or air-gapped processing rather than any cloud-based AI tool, regardless of the vendor's BAA terms.
A QME conducting a psychiatric evaluation who needs a chronology built from a claimant's treatment history should assume the psychotherapy notes require separate handling from the rest of the chart, not a single pass through the same AI workflow. ChartInsight's psychiatric record review capability was built around that distinction.
Technical Safeguards AI Systems Need Under the Security Rule
The HIPAA Security Rule was written for servers and fax machines, but its four safeguard categories, administrative, physical, technical, and organizational, map cleanly onto AI infrastructure once you know what to look for.
Redaction before the model sees anything. The safest architectural pattern detects and masks identifiers before content reaches an AI model, rather than relying on the model to selectively ignore PHI it has already processed. A recommendation from enterprise AI vendors themselves confirms this: platforms built for regulated data increasingly redact at ingestion specifically to avoid PHI exposure to any downstream training pipeline.
Encryption standards that are actually verifiable. Data in transit should run on TLS 1.2 or higher. Data at rest should use AES-256 encryption, and where the vendor supports it, customer-managed keys mean the vendor's own staff cannot decrypt PHI without the customer's cooperation. Ask for the specific standard in writing; "we encrypt your data" without a protocol name is not an answer a security risk analysis can rely on.
Immutable, attributed logging. Every prompt sent to an AI system and every response it returns should be logged with a user ID, timestamp, and the specific record accessed, retained for the HIPAA-mandated six years. A log that only records "AI query executed" with no user attribution will not hold up if OCR asks who accessed a specific claimant's file and why.
Deployment model matters as much as the model itself. A private inference environment, whether that is a dedicated VPC, a GovCloud instance, or fully on-premises processing, keeps PHI off shared infrastructure. Multi-tenant public endpoints are harder to audit and harder to defend if a breach investigation asks exactly where the data went.
- Confirm workspace isolation so one client's or matter's records are never visible to another account, even within the same firm.
- Require role-based access control tied to specific matters or cases, not blanket account-wide access.
- Verify the vendor integrates with, or exports logs to, a security information and event management (SIEM) system your own IT team can monitor independently.
- Confirm real-time DLP scanning catches PHI in outbound content, not just inbound uploads.
Recent federal rulemaking reinforces that the bar on technical safeguards is rising, not holding steady. The Federal Register's proposed HIPAA Security Rule update pushes toward mandatory encryption and stronger cybersecurity baselines for ePHI, which means the vendors treating these safeguards as optional today are the ones most likely to fall short of tomorrow's floor.
Pro Tip: Don't accept "we're HIPAA compliant" as a standalone answer during a vendor demo. Ask them to walk through what happens, step by step, from the moment a PDF is uploaded to the moment a summary appears on screen. If they can't name the redaction point, the encryption standard, and the log destination without checking with engineering, the safeguards likely aren't built in at the architecture level.
Contracting and Breach Response for AI Vendors
A signed BAA is the starting line, not the finish line. The specific clauses inside it determine whether your organization is actually protected when something goes wrong.
Insist on contract language that names sub-processors explicitly, prohibits training on customer PHI without a separate opt-in, grants your organization audit rights (the ability to request security documentation or conduct a review), and sets a specific notification window, ideally 24 to 72 hours, for any suspected breach involving your data. Vague language like "commercially reasonable efforts" around breach notification should be a dealbreaker, since HIPAA's own breach notification rule runs on fixed timelines, not vendor discretion.
Before signing, request:
- A current SOC 2 Type II report, which reflects controls tested over a period of months rather than a point-in-time snapshot.
- FedRAMP authorization, if the vendor markets to government or serves agencies that require it, as a signal of a more rigorous security review process.
- Documentation of the vendor's most recent penetration test, including remediation status for any findings.
- The vendor's specific privacy policy language on data retention, deletion timelines, and what happens to PHI if the contract ends.
For guidance on structuring the BAA itself, a practical breakdown of business associate agreement requirements for SaaS and security vendors covers the clauses most compliance teams overlook on a first read.
When a vendor changes ownership, adds a new sub-processor, or updates its model architecture, that is a material change requiring a fresh look at the BAA and the risk analysis, not a routine software update to ignore. Document every such change and keep that documentation on file. OCR audits routinely ask not just whether a BAA exists, but whether the covered entity can show ongoing oversight of the relationship.
If a breach happens, the clock starts immediately. Preserve every log, access record, and communication touching the incident before anything else happens, then confirm your vendor's contractual notification obligations match the timeline HIPAA's breach notification rule requires for your own reporting to HHS and, where applicable, affected individuals.
Rolling Out a HIPAA-Compliant AI Pilot Step by Step
A rushed AI rollout is how PHI ends up somewhere it shouldn't. A structured pilot catches problems while the blast radius is still small.
- Scope the use case narrowly. Pick one workflow, such as chronology generation for a single case type, rather than attempting a firm-wide rollout on day one.
- Run or update the security risk analysis with the AI tool named as a distinct line item, per the NIST AI RMF structure.
- Complete vendor due diligence using the ten-item checklist above before any contract is signed.
- Execute the BAA with sub-processor and training-use language confirmed in writing.
- Start the pilot with synthetic or fully de-identified records first, then introduce minimally necessary PHI fields only after logging and DLP performance are validated.
- Train staff on what the tool can and cannot be used for, including a clear rule against uploading anything to a non-approved tool "just this once."
- Go live with active monitoring, reviewing logs weekly during the first month rather than waiting for a quarterly audit cycle.
Set acceptance metrics before the pilot starts, not after. A reasonable bar: zero unredacted PHI leakage events across the test set, complete audit log coverage for every query, and an error rate on extracted facts (dates, medications, providers) low enough that a reviewer can spot-check rather than re-verify the entire output line by line.
| Step | What it confirms |
|---|---|
| Synthetic data first | Whether the tool functions correctly before any real PHI is at risk |
| Log review after week one | Whether every query has a complete, user-attributed audit trail |
| Redaction spot-check | Whether PHI masking happens before model access, not after |
What ChartInsight's Accuracy Studies Show
Med-legal reviewers need more than a compliance checkbox. They need output they can defend line by line in a deposition or a DWC hearing. ChartInsight's 433-record indexing accuracy study measured how reliably the platform locates and categorizes events across large, multi-provider files, the kind of stitched-together record common in workers' comp claims spanning years and multiple treaters.
A companion analysis, the Prescribing Hazard case study, tested medication-extraction accuracy specifically, since a missed or mischaracterized prescription can shift an apportionment analysis or an AME's opinion on causation.
The value isn't the summary. It's whether a reviewer can click any sentence in that summary and land on the exact page of the PDF that supports it, without downloading a file or losing their place in the record.
That is the mechanism ChartInsight's page citations provide: every fact in the chronology, the nine-section narrative, the vitals table, and the medications table carries a live link back to its source page. For a QME building a permanent and stationary (P&S) report, or an attorney preparing for cross-examination on a medical timeline, that citation trail is what separates a summary someone might challenge from one they can defend.
- Workspace isolation keeps each matter's records separate.
- Templates keep report structure consistent across similar case types.
- Exports to DOCX or PDF preserve every citation.
- A research assistant answers case-specific questions with the same page-level sourcing.
What the Compliance Playbook Gets Wrong
Most compliance advice on AI treats the BAA as the finish line. It isn't. A signed BAA with no sub-processor disclosure and no training-use prohibition is a document that looks protective and does almost nothing. The research bears this out: OCR enforcement actions repeatedly cite missing audit logs and unencrypted transfers, not missing paperwork, as the actual failure point.
The bigger blind spot is psychotherapy notes and Part 2 records. Firms handling workers' comp psychiatric claims often run every record type through the same AI workflow, treating a general orthopedic file and a substance-use treatment history as equivalent risk. They are not, and the February 2026 Part 2 deadline makes that gap harder to ignore.
If there is one priority to act on first, it is this: demand a sample audit log before signing anything. A vendor that cannot produce a user-attributed, page-cited log on request almost certainly was not built for regulated record review, no matter how polished the demo looks.
— The ChartInsight Team
A Citation-First Way to Handle Med-Legal Record Review
Attorneys and QMEs evaluating AI tools for record review are usually choosing between two bad options: a generic AI summarizer with no citation trail, or days of manual page-flipping to build a chronology from scratch. ChartInsight is built for the middle ground those alternatives miss, a tool where every extracted fact, from a vitals reading to a medication dose to a line in the narrative summary, links directly back to the exact page it came from.
That live PDF viewer means a reviewer preparing a P&S report or a chronology for an AME never has to take an AI output on faith. Click the citation, the source page opens inside the app, and the verification takes seconds instead of a re-read of the entire file. Teams using ChartInsight for large, multi-provider records report the work dropping from days to hours, with the citation trail intact for deposition or cross-examination.
If your team is evaluating AI tools against the checklist in this article, the fastest way to see how ChartInsight measures up is to book a demo and run it against one of your own multi-provider records.
This article is general information, not a substitute for advice from a qualified doctor. Consult a qualified healthcare professional about your own circumstances before acting on anything here.
Sources
- HHS: HIPAA Privacy Rule and sharing information related to mental health
- NIST: AI Risk Management Framework
- Federal Register: HIPAA Security Rule to strengthen the cybersecurity of ePHI
- AI chatbots and challenges of HIPAA compliance for AI developers and vendors (PMC)
FAQ
Is there any AI that is HIPAA compliant?
No AI product is HIPAA-certified, since HHS does not certify software. A tool can be used in a HIPAA-compliant way when a signed BAA covers the specific use case, PHI is redacted before model ingestion, and audit logs meet the six-year retention standard.
Can ChatGPT be HIPAA compliant?
Standard consumer ChatGPT is not covered by a BAA and should never receive PHI. Enterprise healthcare-focused tiers from OpenAI now offer BAAs and data controls for eligible deployments, but compliance depends entirely on the specific contract and configuration in place.
Is GPT-5 HIPAA compliant?
No specific model version is inherently HIPAA compliant or noncompliant. Compliance depends on the deployment: whether a BAA is signed, whether PHI is redacted before processing, and whether audit logging and encryption meet Security Rule standards.
Is AI prohibited under HIPAA?
AI is not prohibited under HIPAA. The Privacy and Security Rules apply to AI the same way they apply to any other technology handling PHI, requiring a BAA, technical safeguards, and documented risk analysis before deployment.
How does ChartInsight support HIPAA-compliant record review?
ChartInsight page-cites every extracted fact back to its source PDF, preserving a verifiable audit trail for chronologies, narrative summaries, vitals, and medication tables used in med-legal review.