AI in Insurance 2026: Underwriting, Claims, Fraud, and a KVKK-Compliant Architecture

TL;DR — Insurance may be one of the sectors where AI delivers the most value, but it is also one that demands the most care. Risk scoring in underwriting, FNOL (first notice of loss) automation in claims, fraud detection, customer service assistants, actuarial pricing support, and regulatory RAG assistants for agents — the use cases are expanding fast. But this is a domain where health data flows, where anti-discrimination rules apply to pricing, and where SEDDK oversight and KVKK govern. In this piece I walk through the use cases I see in the field, why this sector is considered "high-risk," Turkey's regulatory framework, why the EU AI Act classifies pricing in life and health insurance as high-risk, and a KVKK-compliant reference architecture. At the end you will find a concrete 8-12 week pilot roadmap, the KPIs to watch, and the most common pitfalls.

I have spent years delivering corporate AI training and consulting. I have worked with many sectors: manufacturing, retail, banking, the public sector. But insurance has always held a special place for me. Because insurance is, at its core, already a business of data and probability. Actuaries have been modeling risk, computing prices, and balancing portfolios for over a century. So what AI "newly" brings is not the invention of a muscle that did not exist; it is running an already-working muscle far faster, with far broader data, and with far finer distinctions.

That is why insurance is one of the rare domains where generative AI and machine learning produce concrete value. But for exactly that reason, it is also one of the sectors where the most mistakes are made and the most confusion arises. Because here, a model's wrong decision is not an abstract "customer dissatisfaction"; it can mean a person's policy being unjustly rejected, their claim going unpaid, or their being discriminated against because of their medical history.

I am writing this piece by gathering the real questions I encounter in the field. "Which use case should I start with?", "How far does KVKK bind us?", "What would SEDDK say?", "If we do business in the EU, how does the EU AI Act affect us?", "How do I set up a pilot and which metrics do I track?" I will try to answer all of these in turn, as plainly and honestly as I can.

Let us first clarify the landscape. There are six main headings where AI proves useful in insurance, and separating them matters a great deal, because each has a different risk profile, data need, and regulatory sensitivity.

1. Underwriting and risk scoring

Underwriting is the heart of insurance. This is where you decide whether to accept an application, on what terms, and at what price. Traditionally this was a rules-and-tables process. AI does two things here: on one hand it can evaluate far more variables simultaneously, and on the other it can automatically read and summarize application documents, health reports, and expert files.

A caveat: a risk scoring model produces a decision that directly affects a person's life. So explainability here is not a luxury but a necessity. You cannot say "the model said so." You must be able to show which factors influenced the score and how, and even present a justification when you make an adverse decision.

2. Automated claims and FNOL processes

FNOL — "first notice of loss." When an accident happens, when a flood occurs, the moment the customer first reaches out to you. Traditionally this meant phone calls, emails, filling out forms, and then a long wait. Document AI is revolutionizing this: it automatically reads and classifies the photos, invoices, and reports the customer uploads, detects missing documents, and can assess simple claims almost instantly and start the payment process.

Damage estimation from a photo in a vehicle claim, invoice reading in a home policy, prescription and discharge-report analysis in a health claim — all of this is now technically possible. What matters is building a flow that automates the simple, low-risk cases while routing the complex and suspicious ones to a human.

3. Fraud detection

Insurance fraud is one of the sector's oldest and most expensive problems. Fake claims, inflated demands, organized rings. Machine learning is very powerful here through anomaly detection, network analysis (such as the same people appearing again and again across different files), and behavioral pattern recognition.

But there is a subtlety here too: when a fraud model flags someone as "suspicious," that does not mean the person is guilty. The model is a prioritization tool, not a court verdict. False positives harm honest customers and damage the brand. So fraud scores should always be an input to human review, never the final decision.

4. Customer service assistants

Policy inquiries, coverage explanations, claim status tracking, payment information — a large part of customer service consists of repetitive questions. Generative-AI-powered assistants can significantly ease this load. But in insurance, a chatbot wrongly saying "this is covered" can create serious liability. So assistants must be built on a source-citing (RAG) architecture grounded in policy and regulatory texts, and must be able to say "I don't know, let me transfer you to an expert."

5. Pricing and actuarial support

For actuaries, AI is a tool that enriches pricing models, refines segmentation, and sees portfolio risk more clearly. But pricing is the area where anti-discrimination rules apply most sharply. A model reflecting a prohibited discrimination category into price, directly or indirectly (through proxy variables), is a legal and ethical disaster. A variable that looks innocent like "postal code" actually representing ethnicity is the classic example. So bias testing in pricing models is non-negotiable.

6. Regulatory and policy RAG assistants

Agents, brokers, and internal teams must constantly consult regulations, general terms, and policy texts. These texts are long, technical, and constantly updated. A source-citing RAG assistant can answer "Is coverage Y valid in situation X?" by bringing the relevant clause along with its citation. This both saves time and lowers the risk of giving wrong information — provided it is built correctly.

Use case	Primary value	Risk profile	Most critical requirement
Underwriting / risk scoring	Speed + consistency	High	Explainability, fairness
FNOL / claims automation	Cost + customer experience	Medium-High	Human approval, audit trail
Fraud detection	Loss prevention	High	False-positive control
Customer assistant	Operational efficiency	Medium	Source citation, scope limit
Pricing / actuarial	Margin + competition	Very high	Bias testing, anti-discrimination
Regulatory RAG	Accuracy + speed	Low-Medium	Source citation, freshness

Now we come to the critical part. What separates AI in insurance from other sectors is that the cost of error is asymmetric. When an e-commerce recommendation engine suggests the wrong product, no one gets hurt. But when an insurance model decides wrongly, someone's health coverage, property, or future is affected.

So several principles in this sector are non-negotiable:

Explainability. You must be able to explain why a decision was made. To the customer (for the right to appeal), to the regulator (for audit), and to yourself (to be sure the model works correctly).

Fairness and bias control. Unlawful discrimination cannot occur in pricing and risk assessment. The model must not reflect protected categories such as gender, ethnicity, or religion into price, directly or indirectly. This is something that must be tested continuously — because models learn the biases in the data they are trained on.

Human oversight. Especially in adverse decisions (rejection, price increase, claim denial), a human must be in the loop. Fully automated, irreversible adverse decisions are problematic both ethically and legally.

Audit trail. A record must be kept of which model, which version, with which data, at which moment, made which decision. When an auditor arrives, you must be able to re-examine a decision from six months ago and see its justification.

"

No matter how accurate a model is, if you cannot explain its decision, cannot audit it, and cannot bring a human into the loop when needed, you should not put that model into production in insurance. This is not a technical preference, but a corporate responsibility.

When using AI in insurance in Turkey, you dance with two main regulatory worlds at once: sectoral supervision (SEDDK) and data protection (KVKK).

SEDDK oversight

SEDDK — the Insurance and Private Pension Regulation and Supervision Authority — is the sector's regulatory authority. The overseer of products, pricing, consumer rights, and financial soundness. When using AI, the models you deploy must align with the transparency, consumer protection, and fair-treatment principles SEDDK expects. So when building a pricing model, you must constantly ask not only "how accurate is it" but also "is it auditable, is it explainable, does it violate consumer rights."

KVKK and special-category data

This is the most sensitive point. Health insurance and life insurance, by their nature, work with health data. Under KVKK, health data falls into the "special-category personal data" class, and processing this category is subject to far stricter rules.

For special-category data, the rule is generally explicit consent or a legal basis expressly provided by law. So if you are going to use a customer's health data in an AI model, you must have clearly established its legal basis. Saying "we already had it on hand" is not enough.

A few practical headings:

• Legal basis and explicit consent. Clarify the legal basis for processing data on the health/life side. If explicit consent is to be obtained, it must truly be "explicit" (informed, freely given, specific).
• Data minimization. Process the data the model genuinely needs; do not collect everything "just in case."
• Data residency. Where data is stored and processed matters. Cross-border data transfer is subject to KVKK's special rules. Especially for special-category data, on-prem or domestic/sovereign cloud options can be a much safer choice.
• Automated decision-making. If a decision is made about a person entirely automatically and affects them significantly, this is a special area of sensitivity. For adverse decisions, you must establish human oversight and an appeal mechanism.

"

Data compliance in insurance is not a "legal department job" but a design principle that must be embedded into the architecture from the start. Thinking "now how do we make this compliant" after collecting the data is the most expensive and riskiest path.

If your company does business in the EU, works with an EU partner, or offers products to EU citizens, the EU AI Act concerns you directly — even if you are based in Turkey.

The EU AI Act is a regulation that classifies AI systems by risk level. And here is the critical point: AI systems used for risk assessment and pricing in life and health insurance are considered "high-risk" under Annex III.

What does high-risk classification mean? In practice, a series of obligations:

• Establishing and maintaining a risk management system
• Data governance — quality, representativeness, and bias control of training data
• Technical documentation and record-keeping
• Transparency and informing the user
• Human oversight mechanisms
• Accuracy, robustness, and cybersecurity standards

So if you have a life/health pricing model that touches the EU market, it does not end with building "a good model"; you must establish an entire compliance and documentation framework. For an insurer based in Turkey, this means: if there is any chance you will do business with the EU in the future, building your architecture close to these standards from the start saves you a large rebuild cost later.

What is interesting is this: what the EU AI Act demands for high-risk systems (audit trails, human oversight, bias control, documentation) largely overlaps with the good-practice expectations of KVKK and SEDDK. So it is possible to see these three frameworks not as enemies but as three lights looking in the same direction. Once you build the right architecture, you answer all of them at once.

Now I come to the most frequently asked question: "So how do we build this concretely?" Below I share the outline of the reference architecture I use for both generative AI assistants and decision-support models.

Layer 1: Data and PII management

Everything starts with data. At the bottom of the architecture lies how personal data (PII) and especially special-category health data are handled.

• Classification and labeling. Which data is PII, which is special-category, which is anonymous/aggregate — label this at the system level.
• Masking and tokenization. In the data going to the model, mask the personal identifiers that are not needed. A fraud model needs the customer's behavioral pattern, not their national ID number.
• Access control. Strictly limit which model and which team can access which data. The principle of least privilege.

Layer 2: RAG and source citation

For assistants, a RAG (retrieval-augmented generation) architecture is almost mandatory in insurance. Because the model "making things up" (hallucination) is unacceptable. RAG grounds the model's answer in documents you have approved (policy texts, general terms, regulations, internal procedures).

Critical feature: source citation. Every answer must show which document and which clause it is based on. This both increases trust and is gold for auditing. If you think an answer is wrong, you can go to its source and check.

Layer 3: Audit trail and logging

Every interaction, every decision, every model call must be logged. Who, when, with which input, with which model version, received which output? This is not just a technical need; SEDDK audit, KVKK compliance, and the EU AI Act all expect it. Without a good audit trail, your claim that "our model works fairly" has no evidential value.

Layer 4: Human-in-the-loop

In adverse and high-impact decisions, a human must be in the loop. I build the architecture like this: low-risk, simple, clear cases flow automatically. Cases above a certain threshold, adverse or suspicious, are automatically routed to a human. The human sees the model's recommendation and its justification, but makes the final decision themselves. This provides both legal assurance and feedback to improve the model over time.

Layer 5: Model monitoring and bias testing

Putting a model into production is not the end of the job but the beginning. Things you must monitor continuously:

• Performance drift. Does the model degrade over time? Has the input data changed?
• Bias testing. Is there systematically different treatment across protected groups? Test this regularly and with documentation.
• False positive/negative rates. Especially in fraud, how often do you wrongly flag honest customers?

Layer 6: Sovereign / on-prem deployment options

When working with special-category health data, where the data is processed is critical. There are three main options: public cloud (most flexible but the one to set up most carefully regarding data residency), sovereign/domestic cloud (the balance point), and on-prem (most controlled, highest cost). Which you choose depends on your data sensitivity, budget, and regulatory expectations. On the health and life side, domestic/sovereign or on-prem options often provide a more restful sleep.

Architecture layer	What it does	Which framework it serves
Data & PII management	Masking, classification, access	KVKK
RAG & source citation	Prevents hallucination, cites	SEDDK, accuracy
Audit trail	Records every decision	KVKK, SEDDK, EU AI Act
Human-in-the-loop	Gives adverse decision to human	All
Model monitoring & bias	Drift and discrimination testing	EU AI Act, fairness
Sovereign/on-prem	Data residency control	KVKK, data residency

Theory is nice, but if I do not answer "where do I start," this piece stays incomplete. I share an 8-12 week pilot framework I use in the field. The goal is not a grand transformation; it is to bring one use case to life end-to-end, in an auditable way, and to learn.

Weeks 1-2: Scope and selection. Choose a single use case. My advice: start with something low-risk but visibly value-producing. A regulatory/policy RAG assistant or document classification in FNOL are good starts. Do not put the most sensitive areas like underwriting and pricing in your first pilot — there the cost of error is very high and the compliance burden very heavy.

Weeks 2-3: Data and compliance design. Clarify the data you will use, its legal basis, and its PII status. Bring legal and compliance teams to the table at this stage, not later. Establish the data minimization and masking strategy.

Weeks 3-6: Build. Set up the RAG or model pipeline. Embed source citation, logging, and audit trail into the architecture from day one. Do not fall into the "let's make it work first, make it compliant later" trap.

Weeks 6-8: Human-in-the-loop testing. Run the system with real (or near-real) cases, but under human oversight. The model recommends, the human decides. Collect errors, analyze false positives.

Weeks 8-10: Bias and performance evaluation. Test the model's fairness. Is there systematic difference across groups? Is it meeting your performance targets? Document these findings.

Weeks 10-12: Decision and scaling plan. Look at the pilot's results and decide "do we go to production, stop, or redesign." If you decide to scale, clarify the real production compliance obligations (especially if the EU AI Act is in play).

Which KPIs to watch

Before declaring the pilot "successful," look at concrete metrics. They vary by sector and scenario, but the general frame is:

• Accuracy / quality metrics. Answer accuracy and source precision in a RAG assistant; precision/recall in a classification model.
• Process speed. Average processing time in FNOL; decision time in underwriting.
• Automation rate. What percentage of cases were completed without ever going to a human, but safely?
• Human intervention rate and reasons. Which cases went to a human and why? This is gold data for improving the model.
• False positive/negative rates. Critical especially in fraud and claim denial.
• Fairness metrics. Performance difference across groups.
• Customer experience. Satisfaction, appeal rate, resolution time.

There are mistakes I see repeated again and again in the field. If you know them upfront, you save a great deal of time and money.

Leaving compliance for last. The biggest and most expensive mistake. Saying "let's build the model first, think about KVKK later" usually means having to start over. Embed compliance into the architecture; do not bolt it on afterward.

Starting with the most sensitive scenario. Diving straight into underwriting or pricing with excitement. These are the highest-value but riskiest areas. First exercise your muscles on a low-risk scenario.

Ignoring explainability. A "black box" model that is highly accurate but never explainable is useless in insurance. You cannot grant the customer a right to appeal, nor present a justification to the auditor. Sometimes a slightly less "accurate" but explainable model is more valuable.

Thinking bias testing is "one-off." Models change over time, data changes, the world changes. Bias testing is not a one-time stamp of approval but a continuous monitoring process.

Removing the human entirely. "Full automation" is tempting, but removing the human from adverse, high-impact decisions is an ethical and legal bomb. A human-in-the-loop architecture looks expensive but protects you from far more expensive mistakes.

Underestimating hallucination. A customer assistant wrongly saying "yes, this is covered" can create direct liability. Do not put an assistant that does not cite sources and does not know its limits into production in insurance.

Not thinking about data residency. Processing special-category health data carelessly on some overseas service is one of the fastest routes to a compliance breach. Design where you process data from the start.

AI in insurance, to me, is no longer a "should we do it" question. You will do it — because your competitors will, because customer expectations are changing, because the value is so concrete. The real question is "how will we do it." And in insurance, the right answer is almost always "fast but responsible."

If I had to summarize this in three sentences, I would say: start with a low-risk, visibly valuable scenario and exercise your muscles there. Embed compliance, the audit trail, and human oversight into the architecture from the start — compliance added later is the most expensive compliance. And before moving to high-impact decisions like pricing and underwriting, make sure you have genuinely solved bias testing and explainability.

In Turkey the SEDDK and KVKK framework, and the EU AI Act if you touch the EU, all say the same thing in fact: be fast but traceable, be efficient but fair, be automated but keep the human in the loop. You can see this as an obstacle, or as a competitive advantage. I believe those who choose the latter will be at the front of the sector five years from now.

If you are thinking of starting this journey in your organization, the best first step is not a grand strategy document but a small, concrete, end-to-end pilot. Choose a use case, bring it to life in 8-12 weeks with the right architecture, measure, and learn. The rest follows from there.