IRDAI AI Governance for Indian Insurers: Underwriting, Claims, and the DPDP Act

Indian insurers are deploying AI across underwriting, claims automation, fraud detection, and customer service, and the governance question they get wrong most often is assuming IRDAI has written an AI-specific rulebook to comply with. It hasn't — not yet, as a standalone binding regulation. . What insurers actually answer to is a set of general regulations applied to an AI use case, stacked on top of the DPDP Act's unusually strict rules for health and biometric data. That stack is harder to satisfy than banking's, and this piece sets out why, where the real obligations sit, and what an insurer should build.

Why insurance AI governance is harder than banking AI governance

Banks face a demanding AI landscape too — RBI's digital lending rules, the DPDP Act, SEBI for market-facing models — but a bank's core data is overwhelmingly financial. Insurers process health records, biometric capture, medical history, and in some underwriting lines, family medical history that edges toward genetic information. The DPDP Act classifies essentially all of this as data warranting heightened purpose-limitation and consent discipline, which raises the bar well above what a comparable banking AI deployment faces.

The practical consequence is that a single insurance AI use case — say, AI-assisted health underwriting — sits inside at least four overlapping regimes at once: IRDAI's policyholder-protection and product-approval framework, the DPDP Act, the Insurance Act's record-keeping obligations, and, for insurers with EU-linked business, the EU AI Act's high-risk classification. Under EU AI Act Annex III, risk-assessment and pricing systems for life and health insurance are explicitly listed as high-risk — general and motor insurance pricing AI is not automatically caught the same way, a distinction worth getting right if you're scoping EU exposure. An insurer that has mapped its RBI-equivalent obligations (there isn't one — IRDAI is the only regulator in the room) but hasn't mapped its product-filing obligations is the insurer that gets a market-conduct order, not a data-breach notice.

The product-approval gate that decides whether your AI underwriting model can even launch

This is the part generic compliance content skips, and it's the part that actually gates an AI-priced product to market. Most life and health products today launch under IRDAI's Use-and-File procedure: an insurer with a Board-approved underwriting and pricing policy on file can launch a product and notify IRDAI afterward, rather than waiting for prior approval under the older File-and-Use route, which IRDAI still requires for novel or higher-risk product categories. If your AI model sets the price or the underwriting decision, the model's logic — at least its criteria, inputs, and bounds — needs to be reflected in that Board-approved policy document before launch, because an inspector who finds the live model doing something the filed policy doesn't describe treats that as a filing misrepresentation, not merely a model-governance gap.

The second overlooked piece is IRDAI's Outsourcing of Activities by Indian Insurers framework, which applies the moment underwriting, claims assessment, or fraud scoring runs on a third-party AI vendor's model rather than something built in-house. Outsourcing an AI capability does not outsource the insurer's accountability for its output — IRDAI's outsourcing regulations require due diligence, a written agreement covering data handling and audit rights, and ongoing oversight of the vendor, which means "the vendor's AI made that underwriting call" is never an acceptable answer to a policyholder complaint or an IRDAI inspection query.

Regulatory landscape for insurance AI

Underwriting AI: where the explainability gap turns into a complaint-redress failure

AI underwriting systems assess risk, recommend premiums, and trigger exclusions, and they carry the highest governance stakes in insurance because their output determines whether a customer gets covered at all and at what price. The failure pattern I see repeatedly: a policyholder disputes a premium loading through the insurer's grievance channel, the grievance officer asks underwriting for the basis, and underwriting cannot produce a feature-level reason because the model is a vendor black box validated only by the vendor's own attestation.

Key governance risks:

• Discriminatory premium-setting via proxies — postal code standing in for socioeconomic or religious composition, social-media activity standing in for undisclosed health status
• Health data used beyond the specific purpose it was consented for — pre-existing-condition data collected for one underwriting product repurposed for another without fresh consent
• A vendor underwriting model accepted into production on the vendor's attestation alone, with no independent validation of its actual decision logic

Required controls:

• Bias testing: strip proxy features for protected characteristics before production, and run disparate-impact testing across gender, age, health status, and disability
• DPDP consent mapping: tie each health-data field to the specific underwriting purpose it was consented for, and block cross-purpose use at the system level
• Decision-level explainability (SHAP/LIME or equivalent), retrievable for both a policyholder's complaint-redress request and an IRDAI inspection
• Independent validation of every AI component in underwriting, including vendor models, before it touches a live policy decision
• A human-review pathway with a defined SLA for borderline cases and every adverse decision

Claims automation: auto-rejection without a human in the loop is the fastest way to a market-conduct finding

AI claims systems process documents, assess validity, recommend settlement amounts, and in more advanced builds auto-approve or auto-reject claims below a threshold. Auto-rejection is where this gets dangerous, because the 2024 Protection of Policyholders' Regulations expect a human-review pathway for adverse decisions, and an insurer running volume auto-rejection without one is building a systemic complaint-redress failure, not an isolated bad outcome.

Key governance risks:

• Automated rejection at scale with no human review before the policyholder is notified
• Document-extraction hallucination — the model misreads a claim form and processes the wrong amount or the wrong event, directly harming the policyholder
• Inconsistent application of policy-clause interpretation across claimants, which becomes a discrimination exposure the moment two similar claims get different outcomes for no disclosed reason

Required controls:

• Continuous monitoring of document-extraction hallucination rate on medical terms, amounts, and dates
• Fraud-document screening before claims documents enter the AI processing pipeline
• A mandatory human-confirmation gate on every auto-rejection before it reaches the policyholder
• Consistency monitoring to confirm the same claim scenario produces the same outcome regardless of the claimant's demographic profile
• Data minimisation on medical fields in claims documents — process only what the specific claim requires, mask the rest

Fraud detection: the sensitive-data retention trap that doesn't exist in banking fraud models

Insurance fraud detection AI flags suspicious claims and, in agentic deployments, can hold a claim pending investigation. The data context — health records, treating-physician details, hospital billing data — creates a DPDP obligation that banking fraud detection simply doesn't face, because none of that data is "sensitive personal data" in a banking context the way it is here.

Key governance risks:

• Health data retained past the investigation's purpose, which is a straightforward DPDP purpose-limitation violation once it happens at volume
• False-positive fraud flags landing disproportionately on certain demographic segments — an indirect discrimination exposure hiding inside what looks like a neutral fraud score
• Biometric fraud checks (face-matching on health claims) run without the separate, explicit consent DPDP requires for biometric processing specifically

Required controls:

• Enforce purpose limitation: fraud-investigation data doesn't get repurposed for underwriting or marketing without fresh, separate consent
• Monitor false-positive rates by demographic segment, not just in aggregate
• Require explicit, separate consent before any biometric face-matching or fingerprint step runs
• Put a human-review SLA on any claim hold — a claim cannot sit indefinitely on an AI flag with no escalation deadline
• Delete fraud-investigation data on resolution, consistent with DPDP retention limits, while keeping an audit log of the deletion itself

Customer service and advisory AI: the line between "explaining a product" and "selling one"

Insurance customer-service AI handles policy queries, renewal reminders, claims status, and product comparisons, and the critical boundary is distribution licensing: the moment an AI assistant moves from describing a product to recommending a specific one for a specific customer's health or financial situation, it has crossed into activity that ordinarily requires a licensed distributor under IRDAI's intermediary framework.

Key governance risks:

• An AI assistant giving what amounts to unlicensed insurance advice for a specific customer situation
• Hallucinated statements about policy terms, exclusions, or coverage limits — a direct mis-selling and complaint-redress exposure
• Health-related conversation data retained past the session without consent covering that retention

Required controls:

• A hard guardrail that routes any specific-situation product recommendation to a licensed advisor, or clearly discloses the AI's non-advisory limits before the conversation goes further
• Quarterly monitoring of hallucination rate against actual policy documentation for product-term, exclusion, and coverage statements
• No retention of health-related conversation content beyond the session absent explicit consent
• A 24-hour escalation SLA for any complaint citing AI output inaccuracy, consistent with IRDAI's complaint-resolution expectations

The DPDP Act amplifier: why insurers carry a heavier consent burden than banks

Banks process financial data, which DPDP treats as ordinary personal data. Insurers process health, biometric, and in some cases genetic-adjacent data, all of which DPDP treats as warranting materially stricter handling:

• Explicit, purpose-specific consent for each processing purpose — a general terms-and-conditions clause does not cover AI processing of health data
• Fresh consent for each new purpose — health data collected for underwriting cannot feed marketing analytics without separate consent
• Enhanced data-principal rights, including correction and deletion of AI-derived health-risk scores, not just the underlying raw data
• Data localisation for sensitive processing — running health-insurance AI on foreign cloud infrastructure needs its own DPDP compliance review, not an assumption that the general cloud contract covers it

No other obligation in the Indian BFSI AI landscape creates a consent and minimisation burden at this level. An insurer that has solved for IRDAI and left DPDP's sensitive-data provisions as an afterthought has a real, examinable gap — not a theoretical one.

Action checklist for an insurer's Chief Risk Officer or Compliance Head

1. Trace every AI-priced or AI-underwritten product back to its filed underwriting policy. If the live model's logic has drifted from what's on file under Use-and-File or File-and-Use, treat that as a filing problem to fix before it's an inspection finding.
2. Audit every vendor AI model against the Outsourcing framework — due diligence file, data-handling terms, audit rights, and ongoing oversight evidence, not just a vendor certification letter.
3. Build decision-level explainability into the claims-redress and underwriting-dispute workflow now, so your grievance officer can actually answer a policyholder's "why" instead of escalating to a vendor who won't answer either.
4. Map every health and biometric data field to its specific DPDP consent purpose, and block cross-purpose reuse at the system level, not just in a data-governance policy document.
5. Put a human-confirmation gate on every auto-rejection and every AI-initiated claim hold, with a defined SLA — this is the single fastest route to an IRDAI market-conduct finding if it's missing.

AI governance built for Indian insurers

Zytra maps the real regulatory stack — IRDAI product approval, outsourcing, policyholder protection, and the DPDP Act's sensitive-data rules — to the AI controls that actually hold up in an inspection.