How to Evaluate AI Medical Record Tools for HIPAA Compliance and Data Security

Medical records are among the most sensitive documents your firm handles.

Every intake packet, hospital bill, and treatment note contains protected health information.

When you upload that data to an AI tool, you are deciding who processes it, where it goes, and how long it stays.

Most PI firms understand HIPAA in the context of their own systems.

What many have not worked out is how HIPAA applies when a third-party AI platform processes that data on their behalf.

The rules are not different. But the risks are concentrated in new places.

A misconfigured vendor relationship can expose your firm to OCR investigations, client notification obligations, and malpractice claims — before you have reviewed a single document.

This guide covers every compliance question you should answer before selecting an AI medical record tool.

Why HIPAA Applies to Law Firms Using AI Tools

The Business Associate Agreement

HIPAA’s Privacy Rule requires covered entities to execute Business Associate Agreements with any vendor that creates, receives, maintains, or transmits PHI on their behalf.

Law firms are not covered entities in the traditional sense. But they regularly receive PHI from covered entities like hospitals and insurers.

When a PI firm sends medical records to an AI vendor for processing, that vendor becomes a business associate under 45 CFR § 164.502.

A BAA is not optional. Operating without one when PHI is involved is a HIPAA violation — regardless of whether a breach occurs.

The HIPAA BAA requirements are well-established, and OCR enforcement actions routinely cite missing BAAs as a standalone violation.

The agreement must specify permitted uses, require appropriate vendor safeguards, and include breach notification timelines — typically 60 days from discovery.

What PHI Means in the AI Context

Protected health information is broader than most firms realize.

Names, dates of service, diagnosis codes, treatment histories, policy numbers, and claim identifiers all qualify as PHI.

When intake staff uploads a records package to an AI platform, every document in that package is likely PHI.

The risk compounds when AI vendors use uploaded documents to train or fine-tune their models.

If a vendor’s terms of service permit training on client data, your firm has contributed PHI to a dataset used by other customers.

Most firms that discover this have already signed contracts permitting it.

Read the data processing addendum before signing — that is where LLM data retention terms typically appear.

The LLM Data Retention Problem

How General-Purpose AI Handles Your Data

General-purpose AI tools — ChatGPT, Claude, Gemini — were not designed for medical record workflows.

Their default configurations often retain conversation data, use inputs for model training, and cannot execute a HIPAA-compliant BAA.

Microsoft’s enterprise versions offer HIPAA-eligible configurations, but these require specific licensing and setup that most law firms have not implemented.

The core issue is not that general AI tools are insecure. It is that their architecture was designed for consumer and enterprise productivity use cases — not legal medical record workflows.

The risks of general-purpose AI for medical records go beyond accuracy gaps — the compliance exposure is significant on its own.

Even on enterprise tiers, these tools lack domain-specific safeguards: no source-linking, no human QA layer, no audit trail for legal discovery.

Security and accuracy failures compound each other. A platform that cannot cite its source cannot help you defend the output.

What Purpose-Built Platforms Do Differently

Purpose-built AI platforms for legal medical record review are designed to execute BAAs and restrict data processing to the scope of the engagement.

InQuery is built specifically for PHI handling.

Client data is isolated per engagement, retention is limited to the engagement window, and no uploaded documents flow into model training pipelines.

The key technical distinction is zero-retention architecture.

When records are uploaded to a purpose-built platform, they are processed for the specific output requested and then deleted on a defined schedule.

There is no ambient retention, no cross-customer data pooling, and no training use.

Ask any vendor to explain their data lifecycle explicitly: when records are ingested, where they are stored, how long they are retained post-delivery, and how deletion is confirmed.

If a vendor cannot produce a written data lifecycle document, that is a meaningful finding.

SOC 2 Compliance: The Security Baseline That Matters

Type I vs. Type II: Why the Distinction Matters

SOC 2 is an auditing framework developed by the AICPA that evaluates how a vendor manages data security.

A Type I report assesses whether controls are designed appropriately at a single point in time.

A Type II report assesses whether those controls operated effectively over a sustained period — typically six to twelve months.

Type I is relatively easy to obtain and says little about operational security.

A vendor can pass a Type I audit and still have controls that fail in practice.

For a law firm evaluating AI medical record platforms, a Type II report from within the last 12 months is the minimum standard.

Request the full report, not just the certification letter. The exceptions section — where controls fell short — is where the real security picture lives.

Five Trust Service Criteria to Evaluate

SOC 2 audits can cover five Trust Service Criteria. For medical record AI vendors, three matter most.

Security covers logical access controls, encryption, and incident response. It is the only criterion required for a SOC 2 audit.

Confidentiality covers controls to protect data identified as confidential — which PHI always is.

A vendor whose SOC 2 excludes the Confidentiality criterion has not been audited on the controls most relevant to your use case.

Privacy covers personal information handling consistent with commitments made to data subjects — a reasonable expectation for any vendor handling PHI.

Availability and Processing Integrity are less critical, though Processing Integrity matters if you rely on platform outputs for demand letters or settlement documents.

Vendor Due Diligence: Questions to Ask Before Signing

Security Architecture Questions

These questions should go into every vendor security conversation before a contract is signed — they align with the framework in the medical summarization platform evaluation guide.

• Does the vendor execute a HIPAA-compliant BAA as a standard part of their agreement?
• What encryption is used for data at rest and in transit — AES-256 and TLS 1.2+ at minimum?
• Is each client’s data isolated in a dedicated environment, or co-mingled in a shared database?
• Does the vendor use uploaded documents to train or fine-tune AI models?
• Who are the vendor’s subprocessors, and does the BAA extend to each of them?
• What is the data retention period, and how is deletion verified?
• What controls restrict vendor employees from accessing client data?

Write down the answers. If a vendor responds verbally but resists putting answers in writing, that is a signal.

Data Processing and Subprocessors

Many AI vendors use third-party infrastructure and model providers for inference.

Each relationship creates a subprocessor chain, and HIPAA requires PHI handled by subprocessors to be covered by BAAs extending through that chain.

Ask for the vendor’s complete subprocessor list and confirm each party has a BAA in place.

Vendors who use commercial model APIs need to confirm the specific tier and configuration is HIPAA-eligible. Not all tiers are.

Several AI legal tech vendors have been found routing PHI through model endpoints that are not HIPAA-eligible.

The law firms using those products were unknowingly in violation.

Incident Response and Breach Notification

The HIPAA Breach Notification Rule requires covered entities to notify affected individuals within 60 days of discovering a breach.

For business associates, the obligation is to notify the covered entity promptly enough that they can meet their notification timelines.

Ask vendors two questions: what is their documented incident response process, and what is their contractual notification commitment after a suspected breach?

A vendor who can point to a written incident response plan with defined escalation paths has invested in operational security.

A vendor who refers you to a general ToS paragraph has not.

Comparing AI Medical Record Platforms on Security

Security postures vary significantly across the AI medical record market. The table below reflects publicly available information as of mid-2026.

Platform	HIPAA BAA	SOC 2 Type II	Zero-Retention Arch.	Human QA Layer
InQuery	Yes	Yes	Yes	Yes
Wisedocs	Yes	Yes	Not confirmed publicly	No
DigitalOwl	Yes	Not confirmed publicly	Not confirmed publicly	No
EvenUp	Yes	Not disclosed	Not disclosed	Partial
Supio	Yes	Not disclosed	Not disclosed	No

Where Purpose-Built Tools Have the Edge

The security differentiator for purpose-built platforms is architecture, not just certification.

A platform designed for legal PHI handling enforces data isolation, zero-retention, and audit logging at the infrastructure level.

These controls are much harder to retrofit onto a general-purpose AI tool or a case management platform that added AI features as an afterthought.

InQuery’s security architecture is detailed on the security page.

The combination of SOC 2 Type II, zero-retention architecture, and a human QA layer addresses the three most common failure modes: unauthorized access, data persistence beyond the engagement, and undetected AI errors in the output.

When evaluating platforms for AI medical record review, security architecture should be weighted alongside accuracy and turnaround time.

A fast, accurate tool that puts client PHI at risk is not a good deal.

Encryption, Access Controls, and Audit Trails

Encryption Standards That Hold Up in Court

AES-256 is the current standard for encryption at rest. TLS 1.2 is the minimum for data in transit; TLS 1.3 is preferred.

These are not negotiating points — they are baseline requirements for any HIPAA-eligible system.

What matters as much as the standard is where encryption keys are managed.

Vendors who hold their own keys can decrypt your data.

Vendors who support customer-managed key management provide a stronger posture — few legal AI vendors offer this today, but it is worth asking.

Ask explicitly whether PHI is encrypted at the field level or only at the volume level. Volume-level encryption protects against physical storage theft but not a compromised application layer.

Access Controls and Role-Based Permissions

Access controls govern who within the vendor’s organization can view your client data — and under what circumstances.

Strong access controls mean vendor employees cannot access client records without a documented, logged reason tied to a support ticket or audit event.

Evaluate RBAC capabilities for your own team as well. The platform should let you restrict which staff can upload records, view outputs, or export documents.

Multi-factor authentication is non-negotiable. If a vendor’s platform does not require MFA for all accounts, do not use it for PHI.

Audit Logs for Legal Defensibility

Audit logs track every action taken on a document: who uploaded it, who accessed it, what AI processing occurred, and when outputs were generated.

A complete audit trail is valuable in two scenarios: a HIPAA investigation and a malpractice dispute.

In a HIPAA investigation, an audit log demonstrates that your firm had controls in place and can trace every instance of PHI access.

In a malpractice dispute, an audit log shows which records were reviewed, when, and what the AI system produced — establishing that your firm’s review process was thorough.

The AI records gap analysis is easier to defend when you can show exactly which records were analyzed. Audit logs make that automatic.

Building Your Firm’s AI Security Policy

Core Policy Elements for Medical Record AI

A written AI security policy is now a component of any defensible compliance posture.

The law firm AI policy framework covers the full structure, but for data security, these elements are essential.

Policy Element	What It Should Specify
Approved vendors	Named platforms with current confirmed BAA status
Prohibited tools	General-purpose AI tools for any PHI processing
Data classification	Which record types require what level of protection
Upload procedures	Who can upload records, to which platforms, under what conditions
Retention and deletion	When records must be deleted from firm systems post-delivery
Incident response	Who to contact and what not to do when a suspected breach occurs
Staff training	Frequency, format, and documentation requirements

Review the policy annually. Treat the approved vendor list as a living document requiring sign-off from a named partner or compliance owner.

Staff Training Requirements

A policy that staff have not read does not protect your firm.

Security training for AI tools should be integrated into your broader HIPAA training program and documented with sign-offs.

Training should cover three things:

First, which platforms are approved and why general-purpose tools are not.

Second, how to handle a suspected data incident — who to call and what not to do in the first hour.

Third, what social engineering looks like in a legal context — phishing attempts targeting PI firms with high-value cases are common and increasingly sophisticated.

Annual training is a minimum. When a new tool is added to the approved list, targeted training should happen before any staff member uses it for PHI.

Malpractice Exposure from Inadequate Controls

The compliance posture questions for law firms are professional liability questions, not just regulatory ones.

State bar ethics opinions on AI use are proliferating. Nearly all emphasize the duty of competence, which now includes understanding the tools the firm deploys for client work.

If your firm uses a non-HIPAA-compliant AI tool and a breach occurs, exposure is layered: OCR enforcement, client notification, and malpractice claims.

The malpractice insurer will ask whether your firm had a written policy, used an approved vendor, and trained staff — if the answer to any is no, coverage may be contested.

The cost of a written policy and a purpose-built vendor is far lower than a single OCR investigation.

Red Flags in a Vendor’s Security Posture

Warning Signs in Contracts and Terms of Service

Certain contract terms should trigger immediate scrutiny.

A data processing addendum that permits training on customer data is a red flag — even when an opt-out is included, because opt-outs are not always enforced in practice.

Broad subprocessor language — “we may use third-party service providers” without a named list — means you cannot assess the PHI chain.

Vague breach notification terms like “reasonable timeframes” without specific day counts give the vendor discretion you should not grant them for PHI incidents.

Limitation of liability clauses capping the vendor’s exposure at the value of your subscription are particularly problematic.

A breach affecting hundreds of clients will generate costs that dwarf a monthly SaaS fee.

Negotiate for uncapped liability on PHI incidents or breaches of the BAA.

The MOS Medical Record Review assessment of AI platforms notes that contract terms are often where the real security picture emerges — not in sales presentations.

Red Flags During the Demo and Trial Phase

Watch how vendors handle security questions during the sales process.

A vendor who deflects security questions to “our legal team will handle that” before you have signed anything is signaling that security is not embedded in their culture.

Ask to see the SOC 2 report during the trial phase, not after contract signature.

Ask whether data uploaded during a trial is subject to the same handling controls as production data — often it is not.

The Legalyze.ai roundup of AI medical record platforms notes that how vendors handle security disclosure during evaluation is a reliable signal of their operational maturity.

Frequently Asked Questions

Does my law firm need a HIPAA BAA with every AI tool used for medical records?

Yes, if the tool processes PHI on your behalf.

Any vendor that accesses, stores, or transmits medical records to perform services for your firm is a business associate and requires a BAA.

There are no exceptions for trial accounts, short-term use, or read-only access.

What is the difference between SOC 2 Type I and Type II for AI vendors?

A Type I report confirms controls were designed appropriately at one point in time.

A Type II report confirms those controls operated effectively over a sustained period — typically six to twelve months.

For evaluating AI medical record tools, request a Type II from within the last year. Type I alone is not meaningful assurance for a vendor handling PHI.

Can my firm use ChatGPT or Claude for medical record review if we are careful?

Not without enterprise configurations explicitly HIPAA-eligible and covered under a signed BAA.

Even then, general-purpose tools lack source-linking, audit trails, and QA layers that purpose-built platforms provide.

The accuracy and compliance gaps in general-purpose AI are well-documented. Being careful is not a substitute for appropriate architecture.

What should we do if a vendor refuses to share their SOC 2 report?

Walk away.

No reputable AI vendor handling PHI should refuse to share their SOC 2 report before contract signature.

Vendors with a clean Type II typically share it proactively during the sales process. Reluctance to disclose during evaluation is a reliable signal.

How does InQuery handle data security and HIPAA compliance?

InQuery operates under a HIPAA-compliant BAA, holds SOC 2 Type II certification, and uses zero-retention architecture.

Uploaded records are processed for the specific engagement and deleted on a defined schedule, with no use for model training.

Role-based access controls, MFA enforcement, and full audit logging are included as standard.

See the full details on the security page or get started to discuss your firm’s specific requirements.