IRDAI's AI Audit Framework Is Being Drafted: The Documentation Insurers and Brokers Should Already Have

By order dated 17 June 2026, reference IRDAI/GA&HR/ORD/MISC/90/06/2026, IRDAI constituted a Working Group on Artificial Intelligence Governance in the Insurance Sector. Business Standard and Asia Insurance Post reported the constitution on 18 June 2026, along with the detail that matters most for planning: the group has three months to submit its recommendations. That puts the report in the regulator's hands around September 2026.

The composition signals how seriously IRDAI is treating this. The chair is Sandeep K. Shukla, Director of IIIT Hyderabad and a cybersecurity academic, with IRDAI's general manager and CISO Deepak Gaikwad as member convener. The remaining seats mix supervisory and industry perspectives: officials from CERT-In and Reserve Bank Information Technology (ReBIT), and executives from SBI Life, Star Health and ICICI Lombard.

Read that roster carefully. Two of the seven seats belong to security institutions, the chair is a security academic, and the convener is IRDAI's own CISO. Whatever this group produces will treat AI as a supervised technology risk in the same family as information security, where IRDAI already inspects, already asks for evidence, and already penalises gaps. It will not read like a discussion paper.

A three-month drafting window also means the group will not invent much from scratch. It will borrow from material already on the table, including the RBI committee's FREE-AI architecture that we covered in our analysis of the FREE-AI framework and the insurer AI inventory, and the national AI governance guidelines that route sectoral implementation through the sector regulator. Firms that assumed insurance-specific AI rules were years away now have a dated trigger to plan against.

Asia Insurance Post and (Re)in Asia reported the working group's terms of reference in June 2026. Set out as headings, the mandate covers:

1. Governance frameworks for AI use in the insurance sector.
2. Best practices and safeguards for AI deployment.
3. An AI audit framework, with the reporting suggesting both pre-deployment and post-deployment audit requirements.
4. The implications of frontier AI for the sector.
5. Controls against AI-driven automated attacks.
6. Sector-wide stress tests.

The same reporting named claims processing and fraud detection as priority functions.

Here is the practical move: stop treating this list as a description of the working group's job and start treating it as a description of yours. Each heading implies a question an IRDAI supervisor will eventually ask your firm, and each question implies a document. Governance frameworks imply a board-approved AI policy with a named owner. Safeguards imply recorded controls per system. An audit framework implies registers and evidence trails, which the next two sections unpack. Automated-attack controls and stress tests imply that your AI systems appear in your cyber and business-continuity documentation rather than living outside it.

None of these artefacts depends on the report's final wording. A model register does not change shape because the group phrases a recommendation one way or another. The firms that map the mandate onto their own AI estate now will spend the post-report period formatting evidence. The firms that wait will spend it discovering what they run.

For the wider sequence of Indian AI rulemaking that this group slots into, see how the India AI Governance Guidelines translate into IRDAI sectoral rules.

An audit framework with a pre-deployment leg presumes three things exist before any auditor arrives: an inventory of AI systems, a model register with real content, and an approval gate that fired before each system went live.

The inventory answers the first audit question, which is always "what do you run?" For each AI system: name, vendor, hosting location, use case, the named business owner, the data it touches, and whether it drafts, recommends or decides. Most broking firms cannot produce this today because tools arrived through SaaS subscriptions, features embedded in placement platforms, and individual analysts using public chatbots. An audit turns that informality from a culture problem into a findings list.

The model register goes one level deeper for systems that influence outcomes. For a claims triage model or a fraud score, it records what data trained or grounds the model, what the system is allowed to decide alone, its known failure modes, the validation performed before go-live, and the version history since. Vendor tools belong in the register too. "The vendor validated it" is an answer an auditor will test by asking for the vendor's documentation, so collect it at procurement, not at inspection.

The approval gate is the piece firms most often lack. Pre-deployment audit implies someone with authority reviewed the system against defined criteria and signed off before it touched a policyholder outcome, and that the sign-off is dated and retrievable. If your current process is that a team adopted a tool and told nobody, you cannot reconstruct that gate afterwards. You can only start running one now, and grandfather existing systems through a documented retrospective review.

The second leg of the suggested framework covers systems already in production, and it changes what counts as a control. A policy that says "a human reviews every AI output" is a claim. Post-deployment audit deals in evidence, and evidence means logs.

Three evidence trails matter most. First, records of human review: who looked at the AI's output, when, and whether they changed it. A claims recommendation queue where every AI suggestion is approved within seconds, untouched, is evidence that the human check is a rubber stamp, and an auditor who samples the log will say so. Firms should sample their own logs first and fix the review step before someone else measures it.

Second, performance and drift monitoring. A fraud model tuned on 2024 claim patterns degrades as fraud patterns shift. Post-deployment audit will ask when the model was last revalidated, what its current false-positive and false-negative behaviour looks like, and who is accountable for pulling it if performance decays. If nobody in your firm can name the person who owns that question for each production model, that is the gap to close.

Third, incident logs. A hallucinated clause in a client email, a triage model that wrongly fast-tracked a claim, a data slip into a public tool: each should exist as a dated entry with a closure note. An empty incident log for a firm running a dozen AI systems reads as absence of detection, and supervisors know it.

The underwriting end of this discipline, where explainability expectations bite hardest, is covered in our piece on AI model-risk governance for insurer underwriting under IRDAI. The same logic now extends to every function the working group touches.

The mandate could have named underwriting, pricing or distribution as the priority. It named claims processing and fraud detection, and the choice is informative.

Claims is where AI decisions reach policyholders with the least buffer. A pricing model's error surfaces as a bad quote a human can still refuse. A claims automation error surfaces as a delayed or wrongly repudiated claim, which is one of the largest categories of policyholder grievance in India. Fraud detection carries the mirror risk: a false positive flags a genuine policyholder as a suspect, delaying their claim on the say-so of a score they never see. Both functions have also seen the fastest real deployment, with insurers running document extraction, triage, straight-through processing and network-level fraud scoring in production today.

So the highest-probability early outcome of this working group is audit expectations that bind claims and fraud AI first. If you can only prepare one part of your estate before September, prepare that part:

• List every model or tool that touches a claim between intimation and settlement, including vendor fraud scores you consume rather than build.
• For each, write down what it can do without a human decision, and where the human decision points sit.
• Check whether a repudiation or a fraud referral influenced by a model can be explained to the policyholder, and to a supervisor, after the fact.
• Confirm that appeals and grievance paths do not route back through the same model that made the first call.

The working group's security-heavy composition connects to a document already in force. IRDAI issued revised information and cybersecurity guidelines for regulated entities in April 2026, a revision analysed by Sansa Legal that lands two months before the AI group was constituted. Seen together, the sequence is deliberate: refresh the security baseline first, then commission an AI framework from a group anchored by the CISO's office, CERT-In and ReBIT.

Two mandate items make sense only in that light. Controls against AI-driven automated attacks treat AI as a threat vector aimed at insurers: automated social engineering against call centres, synthetic documents and manipulated images entering claims pipelines, and adversarial probing of fraud models to learn what slips through. Defending claims automation against synthetic evidence is an AI governance control and a cybersecurity control at once, and the audit framework will likely test it under both headings.

Sector-wide stress tests point at concentration. If many insurers consume the same vendor model for fraud scoring or document extraction, a defect or compromise in that model is a market event rather than a firm event. A stress test presumes the regulator can see who depends on what, which loops back to inventories: yours feeds the sector map.

The practical implication for compliance teams is to stop running AI and information security as separate files. Your AI systems should already appear in the asset registers, vendor assessments and incident procedures the April 2026 guidelines require. When the audit framework arrives, firms with one integrated evidence base will answer both sets of questions from the same shelf. If your firm has not yet built the governance basics, our primer on AI governance frameworks for insurers and brokers is the starting point.

Three months is a short drafting window, and the period between the report's submission and IRDAI's eventual regulatory action is unknowable. What is knowable is that documentation built voluntarily now costs less than documentation reconstructed under a compliance deadline, and reads better under inspection.

A workable sequence for an insurer's compliance function or a mid-sized broking firm between now and the report:

1. Weeks 1 to 3. Build or refresh the AI inventory through a declared amnesty. Include vendor-embedded AI and informal chatbot use, which is where most surprises live.
2. Weeks 4 to 6. Stand up the model register for systems that influence claims, fraud referrals, pricing or coverage decisions. Chase vendors for validation documentation while you are a customer asking, not an auditee scrambling.
3. Weeks 7 to 9. Fix the two gates: a dated pre-deployment approval for anything new, and a sampled human-review check on the highest-impact production system, starting with claims.
4. Weeks 10 to 12. Reconcile the AI inventory against your April 2026 cybersecurity documentation and your DPDP records, log the gaps, and open an incident register if none exists.

When the working group's report is published, read it against this base. Some of its recommendations will name artefacts you now hold, and the remainder become a delta list rather than a programme.

Brokers should resist the assumption that this is an insurer-only exercise. The mandate covers AI governance in the insurance sector, brokers run AI in claims support, placement and client advice, and a broker whose AI-assisted advice goes wrong answers to the same regulator and to a professional-indemnity insurer who will ask for exactly the evidence described above. The firms that treat the June 2026 order as their own deadline, not the working group's, will be the ones for whom the audit framework changes very little.