AI Security and Governance for Insurance Companies: Shadow AI, Claims Data, EU AI Act, GDPR and DORA

AI governance in insurance is not one problem.

A claims handler pasting customer correspondence into an unmanaged AI assistant creates a different risk from an insurer deploying an internal claims summarization application. Both are different again from AI that influences life-insurance pricing, and from an autonomous agent that can retrieve policyholder data, call APIs and initiate business actions.

A useful insurance governance model therefore separates four environments:

A. Employee use of public or general-purpose AI tools. The primary concerns are Shadow AI, inappropriate disclosure, unmanaged accounts, data loss, confidentiality and lack of evidence.

B. Internally developed AI applications. The focus shifts to application security, data access, prompt and model controls, testing, runtime monitoring, third-party dependencies and traceability.

C. AI embedded into regulated business decisions. Governance needs to address the decision itself: intended purpose, data quality, fairness, explainability, human oversight, testing, documentation and applicable legal obligations.

D. Autonomous or semi-autonomous AI agents. The control problem expands from what AI can *say* to what AI can *do*: which systems it may access, which tools it may call, what authority it has and when human approval is required.

That distinction matters because neither the EU AI Act, GDPR nor DORA treats all AI use inside an insurer identically.

The EU AI Act applies across sectors, including insurance. But the insurance-specific category explicitly identified as high-risk in Annex III is narrower than is sometimes claimed: AI systems intended to be used for risk assessment and pricing in relation to natural persons in life and health insurance. It does not automatically classify every claims, fraud, customer-service or general underwriting application as high-risk merely because an insurer uses it.

GDPR remains relevant whenever personal data is processed. Claims workflows can involve identifiers, financial information, health data and other highly sensitive records. Data minimisation, purpose limitation, accountability, security and-in relevant cases-rules around automated decision-making and data protection impact assessments remain separate obligations from the AI Act.

DORA, meanwhile, is not an AI regulation. It is a digital operational resilience regime. AI becomes relevant to DORA when it forms part of an insurer's ICT environment, creates an ICT dependency, relies on ICT third parties, supports critical or important functions, or becomes relevant to incident management and operational resilience. DORA has applied since 17 January 2025.

The practical objective is therefore not to put every AI system through the same governance process. It is to know which AI is being used, what data it processes, what business function it affects, what decisions or actions it can make, what rules apply, what controls operate in production, and what evidence exists afterwards.

AI governance in insurance is the system of ownership, policies, technical controls, oversight, monitoring and evidence used to manage how AI processes insurance data, supports decisions and performs actions across the insurance lifecycle.

It includes-but is not limited to-model governance.

An insurer may need to govern:

employees using ChatGPT, Claude, Copilot, Gemini and other AI interfaces;

internal copilots and knowledge assistants;

AI-enabled claims systems;

fraud analytics;

underwriting and pricing systems;

software-development assistants;

third-party AI services;

generative AI features embedded in SaaS products;

AI agents capable of interacting with internal systems.

EIOPA's August 2025 Opinion on AI governance and risk management reflects this broader lifecycle view. It highlights risk-based and proportionate governance and identifies areas including data governance, record-keeping, fairness, cybersecurity, explainability and human oversight. Importantly, EIOPA describes the Opinion as clarification of existing insurance-sector governance expectations rather than as a new standalone body of AI law.

The implication for an insurer is simple: govern the actual use case, not the word "AI."

The same model can present very different risks depending on where it is used.

A language model summarizing publicly available regulatory text is not equivalent to the same model receiving a full medical claim. An AI system drafting a claims-handler note is not equivalent to an AI system autonomously determining the amount payable to a policyholder.

This is why insurance AI inventories should identify not only the model or vendor, but also the workflow, data, users, decision impact, integrations and operating environment.

These controls are not legal classifications. They are a practical starting point for matching control strength to operational risk.

Claims teams are attractive candidates for generative AI because much of the work is document-heavy.

AI can summarize adjuster reports, classify incoming documents, extract information from claims forms, generate customer correspondence, compare submitted information against policy language and help employees navigate long case files.

But a single claim can contain far more sensitive information than the employee intends to disclose.

Depending on the insurance product, the AI input might contain a customer's name, address, phone number, bank account, vehicle registration, accident details, medical records, diagnoses, photographs, witness statements, legal correspondence or information about third parties.

Health data receives special protection under Article 9 GDPR.

The first governance question should therefore not be:

> "Is ChatGPT secure?"

It should be:

> "Is this employee authorised to send this specific claims information to this specific AI service, using this specific account, for this specific purpose?"

For approved workflows, controls may include data minimisation before submission, masking direct identifiers, restricting file uploads, enforcing approved enterprise AI environments and maintaining sufficient records to reconstruct material processing.

For AI influencing the actual outcome of a claim, additional governance is appropriate. A system that merely summarizes evidence presents a different risk from a system whose output effectively determines whether a claimant receives payment.

EIOPA has explicitly used this distinction to illustrate proportionality: document retrieval can pose less risk than an AI system used to determine claim payouts.

Customer-service AI commonly connects to CRM systems, policy databases and internal knowledge bases.

The largest security problem is often not the base model. It is context access.

If a chatbot can retrieve policyholder records, governance needs to determine:

who the user is;

which customer records they are authorised to access;

which systems can be queried;

whether information retrieved for one customer can leak into another interaction;

and whether the output is advice, an explanation, a recommendation or merely a draft for an employee.

A secure internal assistant should generally inherit or respect existing authorization boundaries rather than receiving broad access simply because it is an "AI system."

Grounding also matters. For insurance questions, an answer based on a current policy document is materially different from a plausible answer invented by a language model.

For higher-impact interactions, retain enough evidence to identify the model or application version, relevant retrieved sources, material output, user or system identity and any human escalation.

Insurance organisations process enormous volumes of policy documents, contracts, endorsements, regulatory material and customer correspondence.

Generative AI can be highly effective here, but document upload creates a simple governance trap: permission to access a file internally does not necessarily imply permission to disclose it to an external AI service.

The insurer should distinguish approved internal document analysis from ad hoc uploads to personal or unmanaged AI accounts.

Technical controls can therefore operate before disclosure: classify the file, identify sensitive data, determine the destination and account type, and allow, mask, warn, require approval or block according to policy.

Underwriting requires the strongest distinction between AI assistance and AI decision-making.

AI may summarize applications, identify missing documentation or provide information to an underwriter without determining a customer's risk or price.

At the other end of the spectrum, AI can directly evaluate characteristics of a natural person and materially influence eligibility, risk classification, premiums or policy conditions.

The regulatory treatment depends on the precise use.

Under Annex III of the EU AI Act, AI intended for risk assessment and pricing in relation to natural persons in life and health insurance is explicitly listed as high-risk.

That does not mean the AI Act automatically designates all insurance underwriting, all insurance pricing or all insurance AI as high-risk.

For example, the insurance-specific Annex III category does not itself name general property or commercial insurance claims processing, internal policy summarization or fraud investigation.

Other AI Act categories can still apply independently. An insurer using AI in employment, biometric processing or another Annex III context must analyse that use under the relevant category rather than assuming that only "insurance AI" rules matter.

The AI Act also contains Article 6(3), under which certain Annex III systems may not be treated as high-risk when they do not pose a significant risk to health, safety or fundamental rights and satisfy specified conditions, such as performing a narrow procedural or preparatory task. Systems performing profiling of natural persons remain high-risk under that provision. Providers relying on the exception must document the assessment.

Classification should therefore happen at the use-case and intended-purpose level, with legal review where the boundary is material.

AI can identify unusual claims patterns, connected entities or inconsistencies that investigators would otherwise need to find manually.

But fraud detection creates two governance risks.

The first is technical: false positives can cause legitimate claims to receive unnecessary scrutiny.

The second is procedural: an anomaly score can quietly become a de facto automated decision even when the organisation describes it as "only a recommendation."

A sensible control model keeps the purpose explicit: AI identifies signals; authorised investigators evaluate evidence.

The distinction between meaningful human review and rubber-stamping matters elsewhere in EU data-protection law as well. GDPR Article 22 addresses decisions based solely on automated processing that produce legal or similarly significant effects, subject to its conditions and exceptions. EDPB guidance stresses that nominal human involvement is not necessarily meaningful human review.

An internal insurance copilot may appear low risk because the model is not exposed directly to customers.

But it can become one of the broadest internal data-access interfaces in the company.

A knowledge agent connected simultaneously to SharePoint, claims systems, product documentation, legal repositories and ticketing tools may expose information across boundaries that previously required separate permissions.

The relevant security principle is therefore not "the model is internal."

It is least-privilege retrieval.

The system should know whose request it is processing, which data sources that identity may access and which downstream actions are allowed.

Legal and compliance teams can use AI to summarize regulations, compare contracts, analyse policy language or prepare first drafts.

These workflows need particular attention to confidentiality, source accuracy and review.

HR introduces an additional AI Act issue. Annex III includes certain employment and worker-management AI systems. Therefore, an insurer's HR AI may fall into a high-risk category for reasons completely unrelated to the fact that the organisation sells insurance.

This illustrates why an organisation-wide AI inventory should classify use cases, not business units.

AI security in insurance also includes developers.

Engineers can inadvertently paste proprietary code, API credentials, database schemas, vulnerability reports or customer-derived test data into coding assistants.

Developer AI policy should distinguish safe code assistance from disclosure of secrets or production data.

Secret detection, approved coding environments, repository-aware rules and code review should sit alongside-not be replaced by-AI governance.

Actuaries and finance teams can use AI for research, data transformation, code generation, scenario explanation and analytical assistance.

The central risk here is often false confidence.

Language models can produce explanations that sound more precise than the underlying calculation warrants.

Material actuarial or financial outputs should therefore preserve reproducibility: data source, assumptions, analytical code or model, version and human validation should remain distinguishable from generated narrative.

Consider a realistic scenario.

A claims specialist receives a 30-page file containing customer correspondence, an accident report, names and addresses, medical information and internal adjuster notes.

The employee wants a quick summary.

Instead of using an approved insurer workflow, they upload the PDF into an unmanaged AI account and ask:

"Summarise the case and identify inconsistencies."

The productivity benefit is obvious.

The governance problem begins before the AI answers.

The insurer may need to establish what data left the corporate environment, through which service and account, under which contractual terms, for what purpose, with what retention settings, whether the disclosure was authorised and what evidence exists.

This is where two statements must not be confused:

"The provider does not use our enterprise data to train its models."

and

"This information is appropriate for us to disclose to this service in this context."

They answer different questions.

Provider training policies are relevant to vendor risk and data handling. They do not independently determine whether an employee was authorised to disclose a claims document, whether the processing was necessary for the purpose, whether the account was company-controlled or whether appropriate contractual, privacy and security controls existed.

This is why Shadow AI is fundamentally a visibility and policy-enforcement problem.

An insurer cannot meaningfully classify, investigate or govern AI use that it cannot see.

A practical endpoint policy can take into account the tool, account identity, data type and business context before a prompt or file leaves the device. Depending on policy, the action might be allowed, logged, masked, require approval or be blocked.

As of September 2026, the EU AI Act is already broadly applicable, but implementation remains phased.

The Act entered into force on 1 August 2024. Prohibited-practice and related early provisions began applying in 2025, general application began on 2 August 2026, and following the 2026 AI Omnibus changes the main Chapter III requirements for Annex III high-risk systems are scheduled to apply from 2 December 2027. High-risk systems linked to Annex I regulated products have a later date of 2 August 2028.

For insurers, the critical Annex III language is specific:

AI systems intended to be used for risk assessment and pricing in relation to natural persons in the case of life and health insurance.

EIOPA has repeatedly highlighted the same scope.

Therefore:

An AI claims summarizer is not automatically high-risk under the insurance-specific provision.

A general customer-service chatbot is not automatically high-risk.

An internal knowledge assistant is not automatically high-risk.

A fraud detection system is not automatically high-risk merely because an insurance company operates it.

AI performing risk assessment and pricing for natural persons in life or health insurance falls directly within the insurance category, subject to the Act's detailed classification rules.

And an insurer may operate AI caught by another Annex III category-for example employment AI-even when it has nothing to do with insurance underwriting.

The correct process is classify each AI system against its intended purpose and actual use, not declare the insurer itself "high-risk."

Most insurance AI governance programmes will overlap heavily with GDPR because insurance workflows frequently involve personal data.

Article 5 establishes core principles including purpose limitation and data minimisation: personal data should be collected for specified purposes and limited to what is necessary for those purposes. Controllers are also responsible for, and must be able to demonstrate, compliance with those principles.

That matters directly to generative AI.

Giving an AI system "more context" may improve output quality, but GDPR does not create an exemption from minimisation simply because additional data improves the prompt.

For health and life insurance, Article 9 deserves particular attention because health, genetic and certain biometric data fall within special categories of personal data and require an applicable legal basis and conditions for processing.

Automated decision-making also requires separate analysis. GDPR Article 22 gives individuals a right not to be subject to certain decisions based solely on automated processing that produce legal or similarly significant effects, subject to its exceptions and safeguards.

A DPIA may also be required for processing likely to result in high risk. Article 35 specifically identifies systematic and extensive automated evaluation used for legally or similarly significantly affecting decisions, and large-scale processing of special-category data, among the situations requiring a DPIA.

AI governance technology can help generate controls, logs and evidence.

It does not by itself make the processing GDPR compliant.

DORA should not be described as "the EU AI security regulation."

Its subject is digital operational resilience.

DORA covers ICT risk management, ICT-related incident management, resilience testing, information sharing and ICT third-party risk. Insurance and reinsurance undertakings are within its financial-entity scope, while the Regulation contains specific exclusions, including certain exempt insurers and SME insurance intermediaries.

So when does AI matter?

Consider an insurer that deploys a third-party generative-AI service inside claims operations.

If the service becomes operationally relevant, the organisation may need to understand its ICT dependency, data flows, failure modes, provider relationship, business-continuity implications and incident evidence as part of the broader DORA framework.

DORA requires financial entities to maintain a documented ICT risk-management framework, monitor ICT systems, identify ICT dependencies and manage ICT third-party risk. It also requires processes for detecting, managing, logging and following up ICT-related incidents.

That does not mean every employee prompt sent to ChatGPT is automatically a "DORA incident."

A user's casual interaction with an AI tool and a major ICT-related incident affecting a critical insurance function are plainly not the same thing.

But unmanaged AI can still matter to DORA-related governance where it creates unknown ICT dependencies, confidentiality or integrity problems, incident evidence gaps, or use of external ICT services outside the organisation's established risk-management process.

Potentially-but not automatically.

Employee ChatGPT use becomes relevant to DORA when it intersects with the insurer's ICT risk, third-party dependency, security, operational resilience or incident-management responsibilities.

For example, an employee pasting sensitive claims data into an unmanaged AI account may create a security and governance event. Whether that event reaches a DORA reporting threshold is a separate classification question.

Likewise, widespread reliance on an external AI service for a critical operational workflow raises a materially different DORA question from an employee using AI to rewrite a non-sensitive email.

This is another reason AI governance should preserve context instead of treating every AI interaction as equivalent.

A mature insurer will rarely solve AI governance with one control point.

The architecture should follow the four major surfaces where AI operates.

This is where Shadow AI occurs.

Controls should identify AI services and-where technically possible and proportionate-apply policy to prompts, copied text, file uploads and unmanaged accounts before sensitive information leaves the insurer.

Typical policy decisions include allow, warn, mask, require approval and block.

Internally developed copilots, claims applications and customer-facing AI require controls closer to the runtime.

A gateway or SDK can apply policy before model execution, inspect inputs and outputs, identify prompt-injection or sensitive-data risks, enforce model or provider restrictions and produce runtime telemetry.

The organisation needs a shared governance layer connecting runtime activity to ownership, policy, risk classification and evidence.

The important question is not merely whether logs exist.

It is whether the organisation can reconstruct:

what system operated;

which version and policy were active;

what happened;

what control executed;

whether it allowed, changed, blocked or escalated the action;

and who reviewed relevant exceptions.

AI agents introduce one additional question:

What is this system authorised to do?

An insurance agent may retrieve claims data, query customer records, call an underwriting API, draft correspondence or initiate downstream workflows.

Each autonomous agent should therefore have a defined owner, purpose, identity, scope, permitted tools, data-access boundaries, limits, approval requirements and retained action history.

Governance moves from prompt control to authority control.

The governing principle should be proportionality.

An AI-generated draft that a claims handler independently checks should not receive the same governance process as an AI system materially determining a life-insurance premium.

For decision-support systems, insurers should make the relationship between AI and the final decision explicit.

Who has decision authority?

Can the human reviewer genuinely disagree?

What information is shown to the reviewer?

What evidence supports the recommendation?

Are reviewers trained to identify model errors rather than simply approve machine output?

Can the insurer reconstruct what the system recommended at the time?

What happens when the model, prompt, data source or policy changes?

For material automated decisions, this governance layer should be coordinated with legal assessment under the AI Act, GDPR, insurance-sector regulation and applicable national law.

A checkbox labelled "human in the loop" is not the objective.

Meaningful oversight is.

Insurance governance teams often start with policies:

"Employees must use approved AI."

"Sensitive data must not enter public AI tools."

"AI decisions require human oversight."

These policies matter.

But during an incident, audit or supervisory review, the harder questions are operational:

Which AI service was used?

Was the account managed?

What information was submitted?

Which policy was active?

Did a preventive control execute?

Was data masked?

Was an exception approved?

Which version of the application produced the result?

What did the AI recommend?

Who made the final decision?

What changed afterwards?

Strong AI governance therefore connects policy intent to runtime evidence.

EIOPA's insurance AI Opinion similarly emphasises documentation, record-keeping and governance alongside technical and human controls.

1Can you govern both employee AI use and our internally developed AI applications? A browser-only product and an API-only product solve different problems.

2Can policy execute before sensitive information is submitted? Detection after disclosure is useful for investigation; preventive enforcement is a different capability.

3Can you distinguish approved enterprise accounts from unmanaged or personal accounts? The application logo alone does not define the governance context.

4Can you inspect text and file uploads? Claims data frequently leaves as PDFs, spreadsheets and documents rather than only typed prompts.

5How do you handle health data, PII, credentials, source code and company-specific sensitive information? Ask for the detection and policy architecture, not a generic "AI DLP" label.

6Can the platform govern custom applications at runtime? Look for pre-execution policy enforcement, observability, traceability and integration into the actual AI execution path.

7What evidence is retained? Ask to see an example showing the system, user or agent, policy, runtime event, decision, approval or exception, timestamp and relevant versions.

8How do you govern AI agents and tool calls? Logging prompts is insufficient when agents can access databases, invoke APIs or execute business actions.

9Can we export evidence into our existing security, compliance and audit workflows? AI governance should integrate with the insurer's existing operating model rather than create another isolated dashboard.

10Where does your responsibility stop? Be cautious when a vendor claims that installing software makes the insurer "GDPR compliant," "DORA compliant" or "EU AI Act compliant." Technology can enforce controls and generate evidence. Legal classification, governance accountability and compliance responsibility remain broader organisational processes.

The most effective model combines policy and technical enforcement at the point of use.

First, define which AI tools, accounts, data classes and workflows are approved.

Then enforce that policy where employees actually interact with AI.

For a claims document this can mean inspecting the file or prompt before transmission, detecting customer or health information, checking whether the destination and account are authorised and then allowing, masking, escalating or blocking according to the insurer's policy.

The objective is not necessarily to prohibit AI.

It is to prevent the wrong data from reaching the wrong AI environment in the wrong context.

AI governance in insurance is the combination of ownership, risk classification, policies, technical controls, monitoring, human oversight and evidence used to govern AI across workflows such as claims, underwriting, customer service, fraud detection, employee AI use and autonomous agents. A proportionate programme applies stronger controls as the sensitivity of data, impact on customers and authority of the AI system increase.

Yes. The EU AI Act is cross-sector legislation and applies to insurers when they fall within its scope. However, not every insurance AI application is classified as high-risk. Annex III specifically identifies AI used for risk assessment and pricing of natural persons in life and health insurance as a high-risk insurance use case, subject to the Act's classification rules. Other insurer systems may fall into other AI Act categories depending on their purpose.

It can be relevant to DORA but is not automatically a DORA incident. DORA concerns ICT risk, operational resilience, ICT incidents and third-party dependencies. Employee AI use becomes DORA-relevant when it intersects with those responsibilities-for example through an unmanaged ICT service, sensitive-data exposure, operational dependency or an ICT incident. Whether an event is reportable requires separate classification under DORA.

Governance should increase with decision impact. Insurers should document intended purpose, data and model dependencies, decision authority, testing, human oversight, explainability appropriate to the use case, monitoring and retained evidence. Systems affecting natural persons may require additional assessment under the EU AI Act, GDPR Article 22, sectoral insurance rules and national law.

Use a combination of approved-tool policy, account governance and technical controls at the employee endpoint or browser. Sensitive text and file uploads can be inspected before submission and then allowed, masked, warned, escalated or blocked depending on the data category, service, account and business purpose.

Insurance companies do not need a single rule saying "AI is allowed" or "AI is prohibited."

They need a control model that can distinguish:

an employee asking a public AI assistant a generic question;

a claims handler uploading a sensitive claim;

an internal assistant retrieving policy documents;

a fraud model prioritising an investigation;

a life-insurance system calculating customer risk;

and an autonomous agent accessing production systems.

Those are six different governance problems.

The strongest insurance AI programmes connect the layers rather than treating them independently:

Endpoint controls govern employee AI use and Shadow AI.

Gateway and runtime controls govern custom AI applications.

A governance control plane connects systems, policies, owners and evidence.

Agent identity and runtime permissions govern what autonomous AI is allowed to do.

The resulting architecture does not eliminate legal, privacy or operational risk.

It makes those risks visible, controllable and reviewable.

That is the practical objective of AI governance in insurance.