How to Use Sensitive Claims Data Safely With AI

Data Security · AI Governance

16 min read

Insurance claims contain some of the most sensitive information an organization can hold.

A single claim file may include medical records, Social Security numbers, wage information, employment history, bank details, legal correspondence, recorded statements, photographs, diagnostic reports, settlement discussions, and information about family members. In workers' compensation, the file may also contain years of treatment records that reach well beyond the immediate injury.

As claims organizations adopt artificial intelligence, more of this information is being processed by document-review tools, generative AI systems, predictive models, workflow platforms, and third-party vendors.

The value is easy to understand. AI can help claims teams organize large files, prepare summaries, identify missing information, draft routine communications, and reduce repetitive administrative work.

The data risk is just as real.

A claims organization needs to know exactly what information an AI system receives, where that information goes, how long it remains there, who can access it, and whether it may be used for any purpose beyond the assigned claims workflow.

Safe adoption begins with controlling the movement of claims data.

Claims data does not stay in one place

Most claims organizations already manage information across several systems.

The official claim file may sit inside a claims management platform, while supporting information arrives through email, provider portals, legal correspondence, employer systems, shared drives, spreadsheets, and vendor applications.

Introducing AI adds another layer to that environment.

For example, an adjuster may upload a medical report into a summarization tool. That tool may send the document to a separate model provider. The model provider may rely on additional infrastructure providers for storage, monitoring, or processing. Copies of the document or generated output may remain in logs, backups, temporary storage, or support systems.

From the user's perspective, one document was uploaded into one application.

From a data-governance perspective, several organizations and systems may have handled the information.

Before approving an AI claims workflow, the organization should map the full data path:

Where does the information originate?
What information is sent to the AI system?
Which vendors and subprocessors receive it?
Where is the information processed and stored?
How long is it retained?
Is the information used to train or improve any models?
Who can access it?
How is it returned, deleted, or archived?
What records remain after the workflow is complete?

This exercise often reveals risks that are difficult to see in a product demonstration.

Start by identifying what is actually sensitive

Claims teams sometimes treat an entire file as one category of information. In practice, different data elements carry different levels of risk.

A claim file may include:

Personally identifiable information
Protected health information
Financial account information
Employment records
Government identification numbers
Attorney-client communications
Attorney work product
Confidential settlement information
Information about witnesses or family members
Internal fraud indicators
Credentials or system-access information

Some workflows need only a small portion of this data.

A document-routing tool may need the claim number, document type, and date received. It probably does not need the claimant's complete medical history. A system preparing an appointment reminder may need contact information and scheduling details, but not reserve information or litigation strategy.

The safest data is data the system never receives.

Data minimization reduces the number of people and systems exposed if an account is compromised, a vendor is breached, or information is used outside its intended purpose. The NIST Privacy Framework includes data minimization as part of managing privacy risk across the data lifecycle.

Claims organizations should define the minimum information required for each AI workflow instead of giving every tool access to the complete claim file.

HIPAA is only one part of the analysis

Many discussions about claims data begin and end with HIPAA. That can create a false sense of certainty.

HIPAA applies to covered entities and their business associates. Whether it applies to a particular claims organization, employer, vendor, or workflow depends on the role each party is performing and how the information was received.

The HIPAA Privacy Rule permits certain disclosures of protected health information for workers' compensation purposes without the individual's authorization. Those disclosures remain tied to the workers' compensation system and the authority provided by applicable law. Permission to receive medical information for a claim does not make the information unrestricted or suitable for every secondary use.

When a HIPAA-covered entity or business associate uses a cloud provider to create, receive, maintain, or transmit electronic protected health information, HHS generally treats that cloud provider as a business associate. A compliant business associate agreement may therefore be required, even when the provider stores encrypted information and cannot view the contents.

Claims organizations may also be subject to:

State insurance privacy laws
State insurance data-security requirements
General consumer privacy laws
Workers' compensation confidentiality rules
Cybersecurity regulations
Contractual confidentiality obligations
Employer policies
Litigation protective orders
Professional duties governing legal or medical information

The NAIC Insurance Data Security Model Law provides a framework for protecting nonpublic information held by insurers and other insurance licensees. It calls for an information-security program based on the organization's size, activities, use of third-party service providers, and the sensitivity of the information involved.

Applicable requirements vary by state, type of organization, and use case. Legal and compliance teams should evaluate the specific workflow rather than relying on a general statement that a platform is "HIPAA compliant."

For a closer look at how HIPAA specifically applies to AI tools, see HIPAA Compliance in the Age of AI.

Use approved AI environments

One of the most common risks begins with convenience.

An employee receives a long medical report and copies it into a public AI assistant to create a summary. The employee may be trying to save time, but the organization may have no agreement with the provider, no control over retention, no record of the upload, and no way to verify whether the information will be used for another purpose.

Claims data should only be processed through environments the organization has reviewed and approved.

That review should establish:

Whether customer data is used for model training
Whether training is disabled by default or by contract
How prompts, uploads, and outputs are retained
Whether administrators can control retention settings
Whether data is encrypted in transit and at rest
Which countries or regions process the data
Whether vendor personnel can access customer information
Which subprocessors participate in the service
Whether the organization can retrieve audit logs
How data is deleted after termination
How the vendor reports security incidents

A strong contract should match the actual technical behavior of the system. Contract language has limited value when nobody has confirmed how the product handles data in practice.

Separate production data from testing

AI pilots often begin with a few real claim files because real files provide realistic examples.

That choice can expose sensitive information before the organization has completed its security review.

Early testing should use synthetic, anonymized, or carefully de-identified data whenever possible. If real claim information is necessary, the pilot should operate inside an approved environment with defined access, retention, and deletion procedures.

The testing team should also consider what appears in:

Screenshots
Screen recordings
Error messages
Developer logs
Support tickets
Demonstration environments
Analytics dashboards
Quality-assurance systems
Internal chat channels

Sensitive information can leave the primary platform through ordinary debugging and support activity. A secure production system can still create exposure when employees paste a screenshot containing claimant information into an unapproved communication tool.

Give the AI only the access it needs

An AI system should have its own identity and permissions.

Sharing an adjuster's username and password with an automation tool makes it difficult to determine who took an action. It may also give the system access to claims, financial functions, or administrative controls that are unrelated to its assigned task.

Access should be limited by:

User role
Claim population
Business unit
Document category
Permitted action
Time period
Environment
Approval requirement

A document-intake tool may need permission to upload and classify records. It may not need permission to change reserves, issue payments, delete correspondence, or view every claim handled by the organization.

Multifactor authentication, credential rotation, session controls, and immediate access revocation should be considered for AI systems in the same way they are considered for employees and service providers.

The NAIC's data-security framework specifically addresses risk assessment, access controls, monitoring, audit trails, and oversight of third-party service providers that handle nonpublic information.

Protect the integrity of the claim file

Privacy and confidentiality receive most of the attention, but claims organizations also need to protect data integrity.

An AI system can create risk without exposing information to an outsider.

A medical summary may assign treatment to the wrong date. A correspondence tool may insert the wrong claimant's name. A document classifier may upload a report to the wrong file. A generated claim note may state that a provider imposed restrictions when the report only discussed possible restrictions.

These errors can affect claim handling, litigation, payments, return-to-work activity, or regulatory compliance.

Every AI workflow should distinguish between:

Information copied directly from a source
Information transformed or summarized by the system
Information inferred by the system
Recommendations generated from available information
Actions approved by a person
Actions completed automatically

Source-linked outputs are particularly important in claims work. An adjuster reviewing a summary should be able to return to the page, document, or communication supporting the statement.

The NIST AI Risk Management Framework encourages organizations to govern, map, measure, and manage AI risks throughout the system lifecycle. Testing should examine accuracy, reliability, security, privacy, transparency, and the consequences of system failure.

Match human review to the consequence of the action

Not every AI-assisted task needs the same level of review.

A system that renames an incoming document creates a different level of risk than a system that drafts a denial letter or recommends changing a reserve.

Claims organizations can classify workflows by consequence.

Lower-consequence workflows

These may include:

Document naming
Duplicate detection
File organization
Appointment extraction
Preparing internal task lists
Identifying missing fields
Formatting an internal summary

These workflows may still need monitoring and exception handling, but they can often operate with lighter approval requirements.

Moderate-consequence workflows

These may include:

Drafting claim notes
Summarizing medical reports
Updating work-status information
Preparing external correspondence
Identifying possible inconsistencies
Recommending follow-up activity

These uses generally benefit from human review before the output enters the official claim file or reaches an external party.

Higher-consequence workflows

These may include actions or recommendations involving:

Claim acceptance or denial
Benefit eligibility
Reserve changes
Treatment authorization
Fraud referrals
Settlement strategy
Payment decisions
Legal positions

These workflows require more rigorous governance, testing, documentation, and qualified human oversight. The NAIC's AI Model Bulletin states that insurers remain responsible for consumer-impacting decisions that are made or supported by AI and that those decisions must comply with applicable insurance laws and unfair-trade-practice requirements.

A person clicking "approve" is not always meaningful oversight. The reviewer needs enough information, time, and authority to evaluate the output independently.

Keep a record of what the AI did

Claims organizations should be able to reconstruct an AI-assisted workflow after it occurs.

A useful audit trail may include:

The claim or document accessed
The user or system that initiated the task
The version of the AI system used
The information provided to the system
The output generated
Sources referenced
Fields changed
Documents uploaded or downloaded
Communications prepared or sent
Human approvals
Overrides or corrections
Errors and exceptions
Date and time of each action

Logging supports several needs at once. It helps the organization investigate errors, respond to complaints, monitor vendor performance, conduct audits, and demonstrate that employees maintained control over consequential decisions.

Logs also contain sensitive data. They should follow the same access, retention, and security standards as the underlying claim information.

Ask vendors direct questions

A security questionnaire can become a formality. Claims teams should ask vendors questions that reveal how the product actually works.

Data use

Is customer data used to train any shared or external model?
Can training be disabled contractually?
Does the vendor use customer inputs to evaluate or improve its product?
Are generated outputs treated as customer confidential information?

Infrastructure

Which model providers, cloud platforms, and subprocessors handle the data?
Where is the data stored and processed?
Can the customer limit processing to a specific geographic region?
Does the system create temporary or cached copies?

Access

Can vendor employees view claim information?
Under what circumstances?
How is employee access approved and recorded?
Does the platform support role-based access and single sign-on?

Retention and deletion

How long are documents, prompts, outputs, logs, and backups retained?
Can retention periods be configured?
What happens to the data when the contract ends?
How long does deletion from backups take?

Security and incidents

How is data encrypted?
What security testing is performed?
What certifications or independent assessments are available?
How quickly will the vendor report a suspected incident?
Will the vendor provide enough information to support the organization's own legal and regulatory obligations?

AI performance

How does the system identify uncertainty?
Can outputs be traced to source documents?
How are model changes tested?
Will the customer be notified before a material model or workflow change?
How are errors recorded and corrected?

Third-party software can reduce internal workload, but responsibility for the claims process does not disappear when the work is outsourced. The NAIC's AI governance guidance specifically calls for controls around third-party AI systems and data.

Plan for mistakes before deployment

A claims organization should assume that some AI workflows will fail.

The relevant question is how quickly the failure can be detected, contained, corrected, and explained.

An incident-response plan should address situations such as:

Information uploaded to the wrong claim
Unauthorized access to a claim
Sensitive data sent to an unapproved vendor
Incorrect information entered into the claim system
A generated communication sent without required approval
Failure to delete data according to policy
Exposure of credentials
A vendor security incident
A model update that materially changes output quality
Repeated inaccuracies affecting a class of claims

The organization should define who receives the escalation, who can suspend the system, how affected claims are identified, and how corrections are documented.

AI-specific incidents should fit into the organization's existing privacy, cybersecurity, compliance, legal, and claims-quality processes.

A practical checklist before using claims data with AI

Before launching an AI workflow, a claims organization should be able to answer the following questions:

Purpose

What specific claims task will the system perform?
What problem is it expected to solve?
How will success and failure be measured?

Data

What information does the system require?
Can any fields or documents be removed?
Does the workflow involve medical, financial, employment, or legal information?

Legal and compliance

Which laws, regulations, contracts, and internal policies apply?
Is a business associate agreement or other data-protection agreement required?
Are there state-specific restrictions?

Vendor

Who receives or processes the data?
Is the data used for training?
What are the retention and deletion terms?
What happens if the vendor changes its model or subprocessors?

Security

How is access controlled?
Are credentials dedicated to the system?
Are actions logged?
Can access be revoked immediately?

Accuracy

Can the output be traced to its sources?
How was the workflow tested?
What happens when information is missing or contradictory?
How are errors identified and corrected?

Oversight

Which actions require human approval?
Who is qualified to review them?
Can the reviewer see what information the system relied on?

Incident response

Who is responsible when something goes wrong?
Can the workflow be paused quickly?
Can the organization identify every affected claim?

If these questions cannot be answered clearly, the workflow is not ready for production claims data.

Safe AI adoption begins with a narrow purpose

Claims organizations do not need to open the entire claim file to AI in order to gain value.

A safer starting point is a narrow workflow with limited data, clear permissions, measurable output, and a defined human-review process.

For example, an organization might begin by using AI to identify and classify incoming documents. Once that process performs reliably, it may expand into extracting specific fields or preparing a source-linked summary for review.

Each expansion should introduce only the data and authority required for the next task.

This approach gives claims teams time to understand how the system performs, where it fails, and which controls are needed before the technology reaches more consequential parts of the claim.

AI can help insurers, TPAs, self-insured employers, medical providers, and legal teams handle information more efficiently. The long-term value will depend on whether those organizations can preserve the confidentiality, accuracy, and accountability that claims work requires.

Sensitive claims data can be used safely with AI. It requires disciplined data governance, careful vendor selection, limited access, source verification, and a clear understanding of who remains responsible for every action taken on the claim.

This article provides general information about insurance operations, privacy, and artificial intelligence. It does not constitute legal, regulatory, cybersecurity, or compliance advice. Requirements vary by jurisdiction, organization, and use case.