The AI Claims-Support Promise: How to Test It Before You Put It on a Group Health Renewal

On 25 August 2026, Business Today reported that Staywell.Health had announced an investment led by Equanimity Investments, a Mumbai-based early-stage venture firm, to build an AI-native health insurance distribution platform. The amount was undisclosed. The platform as described combines artificial intelligence with expert human advisors across the full member journey: coverage selection, servicing, renewals and claims support.

The line worth pausing on is the investor's stated reasoning. Equanimity cited that combination of AI and human advisors, and specifically the focus on claims support, as key factors behind leading the investment. Coverage selection and renewals are the parts of health distribution software has been eating for a decade. Claims support has resisted, because it is where a member is sick, a hospital is asking for money, and a wrong answer has a cash consequence the same evening.

The timing follows the market. A Kotak Securities note reported by ANI on 20 August 2026 put health premium growth at 26 percent year on year in July 2026, with retail health at 31 percent. Distribution capacity is the binding constraint at that rate, and AI-assisted servicing is the obvious way to add capacity without adding headcount in proportion.

For an HR head or CFO, the practical consequence is that platforms making this promise are now funded, are selling, and will appear in your next group medical cover (GMC) renewal conversation, either as the broker or alongside one. This piece is about how to test the promise before your employees test it for you.

When a vendor says its AI handles servicing, it is usually describing one of two things, and they carry entirely different risk.

The first is the advisory and administration layer. It compares plan options, explains a benefit table in plain language, handles endorsements when a member joins or leaves, chases documents and prompts renewals. This layer is cheap to build in 2026, demos beautifully, and fails cheaply. A slightly wrong answer about a waiting period during onboarding gets corrected a week later and nothing is lost.

The second is the claims-support layer. Here the system answers a member whose cashless pre-authorisation has just been queried or rejected, often outside office hours, with a hospital billing desk waiting. The failure cost is a family paying in cash, an escalation to HR the next morning, and a benefit programme that loses credibility with the whole workforce over one case.

Most pitches present these as one product because the interface is the same chat window. Your evaluation has to pull them apart. Ask the vendor to state in writing which member journeys the AI decides on its own, which ones it drafts an answer for a human to approve, and which ones it never touches. A vendor that cannot draw that boundary crisply has not thought about it.

The rest of this piece is five questions that separate the two layers in practice. The fifth turns on a regulatory development that is about to make the other four answerable rather than rhetorical.

The most useful test of an AI servicing partner is the escalation path to a human, measured rather than described. Ask for four numbers at account level, for books of your size:

• Median and 90th-percentile time to reach a human on a claims query raised between 8 pm and 8 am.
• Coverage hours and staffing model for the human advisor pool. A partner running advisors on a single shift is offering office-hours support with a 24-hour chat veneer.
• Advisor-to-covered-lives ratio, and how it moves when the platform onboards its next large client. Servicing quality on these platforms degrades at growth rather than at launch.
• Deflection rate, the share of member queries the AI closed without a human, alongside how many came back as a repeat contact within 72 hours. High deflection with a high repeat rate is a queue being suppressed rather than served.

Then write the answers into the contract. A servicing commitment that lives only in a slide deck does not survive the account manager who sold it. Specify the escalation SLA, the hours, a named contact above the advisor pool, and a service credit if the SLA is missed on a defined number of cases in a quarter. Service credits here are small money. Their function is to make the vendor's operations team care about the metric.

Fix one more thing in writing: what the AI does when it does not know. Two behaviours are acceptable, saying so and handing off, or labelling the answer provisional pending confirmation. The common and unacceptable one is a confident answer synthesised from how health insurance usually works rather than from your actual policy wording.

An AI platform sitting between your employees and the claims process has no independent power to approve anything. The decision belongs to the insurer, and the operational workflow usually belongs to a third-party administrator (TPA). What matters is whether the platform has contractual standing with those parties or is simply a better-designed way of joining the same queue your HR team already joins.

Ask directly:

1. What is your licence category with IRDAI, and are you the broker of record on the policy, a corporate agent, or a technology vendor operating on another entity's licence?
2. Do you have a written service agreement with the TPA servicing our account, and what does it commit the TPA to?
3. When your advisor escalates a stuck pre-authorisation, does it enter a dedicated channel or the general provider queue?
4. Who owns the relationship at renewal, and what happens to our claims history and service data if we move away from you?

The answers determine whether the AI layer adds weight or adds a hop. A platform with real standing can put a name and a phone number against a stuck case at the TPA. A platform without it drafts a very well-written email into the same inbox.

This also decides who you hold responsible when service fails. If the platform is a technology vendor riding someone else's licence, your regulatory recourse and grievance route run through that licence holder, not the vendor whose app your employees use. Buyers usually discover this only when something goes wrong. The TPA selection questions that apply to any corporate health programme do not stop applying because an AI layer sits on top of the TPA.

Suppose the AI tells an employee a planned procedure is covered, the employee proceeds on that basis, and the claim is declined because of a sub-limit or waiting period the model read wrongly. Somebody is out of pocket. Who, is answered by an insurance policy, and it is worth reading that policy before you sign the servicing contract.

Insurance brokers in India are required to hold professional indemnity cover as a condition of licence, and other intermediaries may or may not, so ask for the certificate rather than a reassurance. Then read past it:

• Whose acts are covered. Traditional professional indemnity wordings respond to the negligent act, error or omission of the insured in the conduct of its professional business. Ask the vendor to confirm in writing that advice generated by its software, without a named human in the loop, falls inside that definition on its policy. If the answer is a pause, the answer is no.
• Exclusions aimed at automation. Some wordings carry exclusions or sub-limits for algorithmic, automated or unsupervised decisioning. This is exactly the exposure you are buying protection against.
• The limit, and whether it is per claim or in the aggregate. An aggregate limit shared across every client the platform serves is thin protection for a large employer, because a systemic model error produces many claims at once from one root cause.
• Retroactive date. A young platform with a recent retroactive date has no cover for anything before it, which includes the period when its model was least mature.
• The interaction with cyber and technology errors-and-omissions cover. A model failure can be argued as either a professional service failure or a technology failure, and both insurers can point at the other. Ask which policy the vendor expects to respond.

Every dispute about AI advice reduces to one evidentiary question: what was the member told, when, by which version of the system, and on what policy data. If the platform cannot reconstruct that, no contractual indemnity is enforceable, because you cannot prove the advice was given.

Specify the logging requirement rather than asking whether logging exists. Every vendor logs something. What you need is:

• The full member-facing output, stored verbatim, not a summary or a category code.
• The model or system version that produced it, and the date that version went live, so a systemic error can be bounded to an affected population.
• The policy data the output was grounded in, meaning the specific benefit table, endorsement and member record the system read.
• Whether a human reviewed or edited the output before it reached the member, and who.
• A retention period that outlasts your claim-dispute window, with an export the employer can obtain on request in a readable format.

There is a data-protection dimension here. Claims conversations are health data, so logging, retention and export have to sit inside a lawful processing structure between the employer, the platform and the insurer. Settle the roles and the consent flow at contracting time, because retrofitting them means going back to every enrolled member. The contract and consent architecture for AI vendors handling insurance data is the same problem in a different seat.

One practical test: ask the vendor to produce the complete audit trail for a single real member interaction from three months ago. A partner with genuine logging returns it in a day. A partner without it returns a screenshot of a chat window.

Until recently a buyer asking these questions was improvising, with no reference standard to point at. That is changing.

IRDAI announced a seven-member working group on artificial intelligence on 19 June 2026, chaired by Sandeep Shukla of IIIT Hyderabad, with a three-month deadline to deliver recommendations. Its remit is to prepare governance frameworks, safeguards and an AI audit framework for the sector. Reporting on the group's formation identified claims processing and fraud detection as the functions warranting closest attention first.

Two things follow for a corporate buyer.

First, the direction of travel on audit is visible. A regulator building an AI audit framework and naming claims processing as a priority function will expect insurers and their intermediaries to evidence what their models did. Vendors already logging model outputs to the standard described above will absorb that with a policy update. Vendors that are not will spend a year retrofitting, and servicing quality suffers while they do. Ask a prospective partner what it is doing to prepare, and treat a blank answer as a delivery risk on your account.

Second, you can draft for it now. Write into the servicing contract a commitment that the platform will meet applicable IRDAI guidance on AI governance and audit as and when it is issued, with a defined remediation window and a right to terminate without penalty if it does not. That clause costs nothing today and gives you an exit if the framework lands somewhere the vendor cannot reach.

Time your renewal governance to the same calendar. If you are renewing a GMC in the second half of 2026, set a contractual review point rather than locking a three-year servicing arrangement, so you can reprice or replace once the working group's recommendations and any consequent guidance are on the table.

None of this needs a separate procurement exercise. It fits inside the renewal you are already running, provided you start early enough that the answers can change the decision.

Run a live escalation test before you sign. Ask for access during evaluation and put a genuine, complex query through the system outside business hours: a pre-authorisation deduction, or a coverage question on a procedure with a sub-limit. Time the response, time the handoff to a human, and read the answer against the actual policy wording. One such test tells you more than a reference call.

Ask for account-level service data from two comparable clients, with permission, covering deflection rate, repeat-contact rate, escalation times and cases that reached an insurer or ombudsman grievance. Portfolio averages and testimonial quotes are not data.

Collect the paperwork before the servicing contract is signed: the IRDAI licence category, the professional indemnity certificate and wording, the TPA service agreement, the data-processing terms, and a written description of the AI decision boundary. Each takes a vendor a day to produce if it exists.

Then contract for the things that matter: the escalation SLA with hours and a service credit, an indemnity in your favour for loss caused by wrong automated advice, the audit-log retention and export right, and the regulatory review point. Brief your HR team on where the AI stops, and tell employees plainly which channel is for questions and which is for emergencies.

The underlying judgement is straightforward. An AI layer that absorbs small servicing questions before they reach your HR team is worth having, and the growth in the health market means more of these platforms are coming. An AI layer that stands between a sick employee and a human who can move a stuck claim is a liability, however good the interface is. The questions above are how you tell which one you are buying, and every answer is obtainable before you commit a renewal to it. The same discipline applies to the insurer's own automation, where straight-through claims processing under the cashless timelines creates a parallel set of governance obligations.