Session 14: Generative AI in Insurance

1. The GenAI Landscape and LLMs

Generative AI represents a fundamental shift in what machines can do with language. Unlike previous AI models that classified or predicted, generative models create — they produce text, summaries, code, analysis, and conversation that is often indistinguishable from human output. For insurance — an industry built on language (policies, terms, conditions, claims, regulations, correspondence) — this capability has profound implications.

1.1 What Are Large Language Models?

An LLM is a neural network trained on a vast corpus of text — trillions of words from books, articles, websites, code repositories, and documents. Through training, the model learns statistical patterns in language: which words follow which other words, how concepts relate, and what constitutes a coherent paragraph, explanation, or argument. When you give an LLM a prompt, it predicts the most likely continuation of that text — one token at a time — generating a response that is statistically plausible based on its training data.

This "next token prediction" mechanism has two critical implications for insurance use:

• The model does not "know" anything in the human sense. It has no understanding of truth, accuracy, or consequences. It generates text that looks like the text it was trained on. If the training data contained conflicting information about a topic, the model may reproduce the conflict — or arbitrarily choose one version.
• Hallucination is not a bug — it is the core architectural feature. An LLM that only generated text matching exactly what was in its training data would be a search engine, not a generative model. The ability to combine concepts, rephrase, and produce novel text is the same mechanism that produces both brilliant synthesis and confident falsehoods. You cannot have one without the other.

1.2 The Major Models and Their Insurance Capabilities

2. Prompt Engineering for Insurance

Prompt engineering is the practice of designing inputs to LLMs to produce reliable, accurate, and useful outputs. In insurance, where the cost of a wrong answer can be measured in crores, prompt engineering is not a nice-to-have — it is the difference between a useful assistant and a liability. The following four patterns cover 90% of insurance use cases.

2.1 The Four Essential Prompt Patterns

Pattern 1 — Role-Based Prompt: Define a specific professional role and context before asking the question. The model tailors its response to the role's knowledge and communication style.

You are a Senior Insurance Underwriter at a general insurance company in India.
You have 15 years of experience underwriting motor, health, and property insurance.
You are training a new junior underwriter.

The junior asks you:
"What are the top 5 risk factors to check when underwriting a private car insurance policy in India?"

Please provide your answer as a numbered list with a brief explanation of each factor and
why it matters for the loss ratio. Use simple language suitable for a junior underwriter.

Pattern 2 — Few-Shot Prompt: Provide examples of the desired input-output format before asking the model to process new input. Essential for extracting structured data from unstructured text.

Extract structured claim information from the following customer descriptions.

Example 1:
Input: "My car was hit from behind at the signal near Andheri station yesterday evening around 6 PM. The bumper is damaged and the left tail light is broken. The other driver admitted fault and his insurance details are attached."
Output:
  Claim Type: Motor — Third Party
  Damage Location: Rear bumper, Left tail light
  Fault: Other driver (admitted)
  Location: Andheri station, Mumbai
  Time: Evening (~6 PM)
  Documents Needed: Police FIR, Other driver insurance details, Photos of damage

Example 2:
Input: "I slipped and fell in my bathroom this morning. I think I might have fractured my wrist. I'm going to the hospital now. I have had this health insurance policy for 2 years."
Output:
  Claim Type: Health — Accident
  Nature of Injury: Possible wrist fracture (undiagnosed)
  Location: Home (bathroom)
  Urgency: Immediate (on the way to hospital)
  Documents Needed: Hospital admission papers, Doctor's report, X-ray reports, Policy card

Now process the following:
Input: "Someone broke into my house last night while we were sleeping. They took my wife's jewellery worth about 3 lakhs and my laptop. I have a home insurance policy but I'm not sure if theft is covered. Please help."
Output:

Pattern 3 — Chain-of-Thought Prompt: Ask the model to show its reasoning step by step before giving a final answer. Reduces errors on multi-step insurance calculations and regulatory analysis.

An insurance company has the following financial data for the year:
— Gross Written Premium: ₹500 crore
— Reinsurance Ceded: ₹75 crore
— Claims Paid: ₹320 crore
— Change in Outstanding Claims Reserve: +₹15 crore
— Operating Expenses: ₹120 crore
— Investment Income: ₹40 crore

Step-by-step, calculate:
1. Net Written Premium
2. Net Earned Premium (assume change in UPR = 5% of NWP)
3. Incurred Claims
4. Loss Ratio
5. Expense Ratio (use GWP as the denominator for expense ratio)
6. Combined Ratio
7. Underwriting Result
8. Profit Before Tax

Show each step with the calculation before moving to the next step.
After all calculations, provide a one-paragraph assessment of the company's financial health.

Pattern 4 — Structured Output Prompt: Request output in a specific format (JSON, table, XML) for programmatic consumption or easy transcription.

Analyse the following IRDAI regulation and produce a structured summary in JSON format with these exact keys:

{
  "regulation_name": "Full name of the regulation",
  "effective_date": "When it came into effect",
  "key_requirements": ["List of 3-5 key requirements"],
  "affected_stakeholders": ["Who is affected — insurers, intermediaries, customers"],
  "penalty_for_noncompliance": "Description of penalties",
  "impact_on_insurtech": "One-sentence summary of what this means for InsurTech startups"

  Regulation text: [Paste IRDAI circular or regulation text here]

2.2 Prompt Engineering Guidelines for Insurance

• Be specific about the Indian context: LLMs default to US/UK insurance knowledge unless explicitly told otherwise. Include "in India", "under IRDAI regulations", "for the Indian market" in every insurance-related prompt.
• Specify the output format: Never accept free-form text when you need structured data. Specify "table format", "JSON with these keys", or "numbered list with a one-sentence explanation for each item."
• Ask for sources and confidence: Prompt the model to indicate its confidence level and whether it is certain about each claim. Example: "After each statement, add a confidence tag: [HIGH] if you are certain based on your training data, [MEDIUM] if you have some relevant information, [LOW] if you are guessing or synthesising from related topics."
• Use negative prompting to prevent errors: "Do not include specific premium amounts without verifying. If you are not certain about a legal or regulatory statement, say 'I am not certain — please verify with the current IRDAI circular.'"

3. Insurance Chatbot Design

A well-designed insurance chatbot is not a "chatbot" — it is a conversational interface to a carefully bounded set of capabilities, with clear guardrails for when to escalate to a human. The most common failure of insurance chatbots is not that they answer badly — it is that they answer confidently beyond their scope, making promises the insurer cannot keep or giving incorrect coverage advice that creates legal liability.

3.1 The Architecture of an Insurance Chatbot

┌─────────────────────────────────────────────────────────────────────┐
│                    INSURANCE CHATBOT ARCHITECTURE                    │
├─────────────────────────────────────────────────────────────────────┤
│                                                                     │
│  USER INPUT (Text or Voice)                                        │
│         │                                                           │
│         ▼                                                           │
│  1. CLASSIFICATION                                                  │
│     ┌─────────────────────────────────────────────────────┐         │
│     │ What type of query is this?                         │         │
│     │ • Policy Inquiry → Route to Policy QA               │         │
│     │ • Claim Status → Route to Claim Lookup              │         │
│     │ • New Purchase → Route to Quote Engine              │         │
│     │ • Complaint → Route to Human (immediate escalation) │         │
│     │ • Complex/Unclear → Route to Human                  │         │
│     └─────────────────────────────────────────────────────┘         │
│         │                                                           │
│         ▼                                                           │
│  2. KNOWLEDGE RETRIEVAL (RAG)                                       │
│     ┌─────────────────────────────────────────────────────┐         │
│     │ • Retrieve relevant policy clauses from vector DB    │         │
│     │ • Retrieve FAQ answers from approved document store  │         │
│     │ • NEVER generate coverage answers from model memory  │         │
│     │ • Only answer based on retrieved documents           │         │
│     └─────────────────────────────────────────────────────┘         │
│         │                                                           │
│         ▼                                                           │
│  3. RESPONSE GENERATION                                             │
│     ┌─────────────────────────────────────────────────────┐         │
│     │ • Use LLM to compose response from retrieved docs    │         │
│     │ • Include policy clause references in the response   │         │
│     │ • Add disclaimers: "This is a general explanation."  │         │
│     │ • If uncertain → "I need to connect you to a human." │         │
│     │ • Log every response for audit and quality review    │         │
│     └─────────────────────────────────────────────────────┘         │
│                                                                     │
│  ESCALATION TRIGGERS:                                               │
│  • Customer expresses dissatisfaction or anger                      │
│  • Query involves a coverage denial or claim rejection              │
│  • Query involves a legal dispute or potential litigation           │
│  • Customer uses words like "lawyer", "ombudsman", "complaint"      │
│  • LLM confidence score below threshold                             │
│  • Customer asks the same question 3+ times (indicates frustration) │
└─────────────────────────────────────────────────────────────────────┘

3.2 The System Prompt for an Insurance Chatbot

The system prompt is the foundational instruction that defines the chatbot's behaviour, scope, and limits. It is the single most important piece of prompt engineering for production chatbots.

SYSTEM PROMPT — INSURANCE CUSTOMER SERVICE CHATBOT

You are "Suraksha", a customer service assistant for SecureSure General Insurance,
an Indian general insurance company offering motor, health, property, and travel insurance.

YOUR CAPABILITIES:
1. Answer questions about policy coverage based on provided policy documents only.
2. Check claim status when the customer provides their claim ID.
3. Explain insurance terms and processes in simple Hindi and English (Hinglish).
4. Guide customers through the claims process step-by-step.
5. Provide information about SecureSure's products (general descriptions, not personalised quotes).

YOUR LIMITATIONS (NEVER DO THESE):
1. NEVER provide a coverage decision ("Is this covered?") without quoting the specific policy clause.
2. NEVER promise a specific claim payment amount or timeline.
3. NEVER make up policy terms or coverage details.
4. NEVER share customer data with anyone without verification.
5. NEVER express frustration or impatience with the customer — always be respectful and helpful.

ESCALATION RULES:
If the customer:
- Asks about a claim rejection or coverage denial → Say: "I understand this is important. Let me connect you with a claims specialist who can review your situation in detail."
- Expresses anger or frustration → Say: "I'm sorry you're experiencing this. Let me connect you with a supervisor who can help resolve your concern."
- Uses legal language ("lawsuit", "ombudsman", "lawyer") → Say: "I recognise this is a serious matter. I will immediately connect you with our customer relations team."
- Repeats the same question 3+ times → Say: "I want to make sure you get the right help. Let me connect you with a team member who can assist further."

Always respond in the language the customer uses. If they use Hinglish, respond in Hinglish.
If they use English, respond in English. If they use Hindi, respond in Hindi.

Begin every response by acknowledging the customer's concern before answering.
End every response by asking if there is anything else you can help with.

3.3 Testing the Chatbot — Five Scenarios

Before any insurance chatbot goes live, it must be tested against a standardised set of scenarios covering the most common customer interactions. Here are five essential test scenarios:

4. Policy Document Q&A & Summarization

Insurance policies are famously long, dense, and difficult for customers to understand. A standard motor insurance policy in India runs 12–20 pages. A health insurance policy can be 25–40 pages. A corporate insurance programme can run hundreds of pages. Generative AI can transform this by enabling: (a) natural language Q&A over the policy ("Is water damage covered?"), and (b) plain-English policy summaries that highlight what matters most to the customer.

4.1 The RAG Architecture for Policy Q&A

Retrieval-Augmented Generation (RAG) is the architecture that makes policy Q&A reliable. Instead of asking the LLM to answer from its training memory (which may have incorrect or outdated insurance knowledge), RAG first retrieves the relevant policy clauses from a vector database containing the actual policy document, and then asks the LLM to answer based ONLY on the retrieved text. This grounds the LLM's response in the actual policy wording — dramatically reducing hallucination.

ARCHITECTURE: RAG for Insurance Policy Q&A

1. DOCUMENT INGESTION
   • Parse policy PDF → Extract text by section
   • Chunk text into segments (e.g., by clause/clause sub-section)
   • Generate vector embedding for each chunk
   • Store in vector database (Pinecone, Weaviate, pgvector)

2. QUERY PROCESSING
   • User asks: "Does my motor policy cover engine damage from waterlogging?"
   • Generate embedding of the question
   • Retrieve top 3–5 most relevant chunks from vector DB
   • The retrieved chunks contain the actual policy wording on water damage

3. ANSWER GENERATION
   • LLM receives: Retrieved chunks + User question
   • LLM instructed: "Answer ONLY based on the provided text.
     If the provided text does not contain the answer, say
     'Your policy document does not clearly address this.
     Please contact our claims team for clarification.'"
   • LLM generates response with clause references

4. AUDIT LOG
   • Every Q&A is logged with: question, retrieved chunks, LLM response
   • Enables quality monitoring and continuous improvement

4.2 The Policy Summary Prompt

Generating a plain-English policy summary is one of the most useful GenAI applications in insurance. A well-designed prompt produces a summary that a customer can actually understand, highlighting what is covered, what is not, and what they need to do.

You are an insurance policy advisor. Your job is to translate complex insurance policy
language into plain, simple English that a non-expert customer can understand.

Read the following policy clauses and produce a structured summary in this format:

## What This Policy Covers
[List the main coverages in simple bullet points. Use "up to ₹X" language where applicable.]

## What This Policy Does NOT Cover (Exclusions)
[List the most important exclusions that a typical customer might expect to be covered.
Focus on exclusions that surprise people. Use plain English.]

## Important Conditions
[Things the customer MUST do to keep the policy valid — timely premium payment,
disclosure requirements, claim notification timelines, etc.]

## Key Numbers
| Item | Amount | Notes |
| Sum Insured | ₹X | Maximum the policy pays |
| Premium | ₹X/year | Current annual premium |
| Deductible | ₹X | Amount you pay before insurance starts |
| No Claim Bonus | Up to X% | Discount for claim-free years |

## One-Line Summary
[A single sentence that captures the essence of what this policy does.]

POLICY TEXT:
[Paste the key clauses of the policy here — typically the "Coverage" section,
"Exclusions" section, and "Conditions" section]

References

1. National Association of Insurance Commissioners (NAIC), "Model Bulletin: Use of Artificial Intelligence Systems by Insurers," NAIC, Kansas City, MO, USA, 2023. [Online]. Available: https://content.naic.org/sites/default/files/call_materials/REGULATORY%20GUIDANCE%20PCKG%206-3-24.pdf
2. MDPI Risks, "Algorithmic Bias Under the EU AI Act: Compliance Risk, Capital Strain, and Pricing Distortions in Life and Health Insurance Underwriting," Risks, vol. 13, no. 9, art. 160, 2025. [Online]. Available: https://www.mdpi.com/2227-9091/13/9/160
3. Insurance Business Magazine (Asia), "India's insurance regulator steps in to govern AI adoption," June 2026. [Online]. Available: https://www.insurancebusinessmag.com/asia/news/technology/indias-insurance-regulator-steps-in-to-govern-ai-adoption-579846.aspx
4. Baker Tilly, "The regulatory implications of AI and ML for the insurance industry." [Online]. Available: https://www.bakertilly.com/insights/the-regulatory-implications-of-ai-and-ml-for-the-insurance-industry

Required reading (Task G5): NAIC Model Bulletin [1] is this session's finance/governance anchor reading; Baker Tilly [4] is the complementary regulatory-analysis reading.