Why NAIC Exhibit C Targets Agentic AI in Claims

Why the NAIC Evaluation Tool's Exhibit C focuses on agentic AI in claims, and the governance documentation carriers discover they are missing.

An adjuster has a recommendation on screen. The model has scored the file against prior claims and is suggesting a denial. The adjuster reads the summary, agrees with it, and clicks approve. The whole thing takes about thirty seconds.

If you ask the carrier afterward who made that decision, the answer is usually that the adjuster did, because there was a human in the loop. A regulator working through Exhibit C asks something narrower. Across the last quarter, how often did the human in the loop actually disagree with the model? If the honest answer is almost never, and the carrier does not record the reasons on the rare occasions it happens, then the human review is not really oversight. It is a rubber stamp, and the model is the thing running claims.

That gap, between having human review on paper and being able to show it means something, is what Exhibit C of the NAIC AI Systems Evaluation Tool is built to find. Claims is the first place it looks.

This article covers why claims draws that scrutiny, what Exhibit C asks for, and the documentation carriers tend to find missing once a request lands. For a walk through all four exhibits and how they connect, see our guide to Exhibits A through D. Here we stay inside C.

The autonomy trap

“Agentic AI” is the phrase doing the rounds for systems that act with some degree of autonomy to reach a goal, anywhere from quietly suggesting a next step to deciding and acting on their own. The label is less useful than it sounds, because it invites the comforting line carriers like to draw. Our AI does not make the final call, so it is not high-risk. It helps to know where the tool draws its own line, because the two lines are not in the same place.

The tool sorts AI by autonomy into three bands: supportive (suggests a next step), augmented (recommends a decision a human can override), and automated (decides on its own within set parameters) ¹. Which band a system falls into gets recorded back in Exhibit A, as part of the inventory. When the tool gets to risk in Exhibit C, though, the autonomy level is not an off-ramp. A system does not turn low-risk just because a human technically sits at the end of it. What counts is whether the system influences a decision that reaches a consumer.

Run the opening scenario through that test. The model recommended a denial and the adjuster approved it, so the model influenced the outcome, and that is all the tool needs. “The adjuster had the final say” does not get a system out of Exhibit C. If anything it points the other way. The arrangement where a model recommends and a human signs off is precisely the arrangement Exhibit C wants documented.

So the practical scope is wider than most carriers assume. Triage tools, fraud flags, damage estimators, settlement recommenders: if any of them shape what happens to a claim, they belong in scope. The useful question for your own inventory is not whether a system is autonomous. It is whether the system changes what you end up doing to a claim.

Why claims, and not underwriting

The tool names several high-risk areas. Claims gets singled out, and the three reasons are worth understanding, because they also tell you where your own exposure sits.

The first is the timing of the harm. An underwriting model shapes coverage a person might draw on at some later point. A claims decision moves money the policyholder is already owed. A denial, an underpayment, or a check that arrives three weeks late while the roof is still leaking does damage right away, and it is easy for a regulator to point at.

The second is how quickly claims AI grows up. These systems rarely show up as a finished model. A triage tool that began by sorting files picks up a settlement-suggestion feature in some later release. A fraud filter that used to flag anomalies for a human starts auto-routing small claims to denial. Each of those changes adds autonomy, and almost none of them arrives with a governance review attached.

The third is the documentation gap, and this is the one that does the real damage. Underwriting and pricing models live in a part of the company that already generates paper: actuarial memos, rate filings, validation reports. Claims AI grew up in operations rather than actuarial, and a lot of it has none of that. Some of it was never even logged as a model. The fraud-scoring tool the SIU team has run for years does not sit under data science, no one ever filed it, and so it never lands on the AI inventory. That holds right up until an examiner asks how claims get flagged, and someone has to account for a system that exists nowhere on paper.

If your claims AI governance is thinner than your underwriting AI governance, that does not make you an outlier. It makes you a fairly typical carrier, and Exhibit C is built to find that exact gap.

What Exhibit C actually asks for

Exhibit C is a detailed questionnaire for each high-risk system. For a claims model, the questions fall into four areas ¹:

Function and logic: what the system decides, supports, or automates; its decision logic and architecture; when it was put in and last validated.

Human oversight: what review is required before the output is acted on, whether the reviewer can override the system, and whether that override is documented and tracked.

Monitoring: what performance metrics you watch, how often you revalidate, and what triggers a review or a retraining.

Fairness: whether the system has been tested for disparate impact across protected classes, which proxy variables you screened, and what you do when an adverse pattern turns up.

Put those four together and the point is hard to miss. Exhibit C is not really testing whether your model is accurate. A model can be accurate and badly governed at the same time. What it tests is whether you can show how the system works, who is genuinely watching it, and how you would catch it if it started treating a protected class differently. Accuracy is your problem. Provability is theirs.

The governance debt nobody booked

There is a pattern worth naming, because carriers rarely recognize it from the inside. A claims AI system tends to evolve along roughly this path:

A simple rules engine sorts incoming claims. Low risk, and nobody documents it, which is reasonable enough.
A machine-learning model takes over fraud flagging. Medium risk, with some documentation, usually technical.
A recommendation system starts proposing settlement amounts. The risk is high now, and the documentation often stopped back at step two.
Low-complexity claims get approved or denied automatically within set limits. High risk, and the governance almost never caught up.

At every step the system got more autonomous, and at no point did anyone schedule a governance update to match. What you end up with is a kind of debt. The system is making or shaping real financial decisions while sitting on documentation written for a smaller, simpler version of itself. The capability moved on and the paperwork stayed behind.

FIG. 1 — THE CAPABILITY MOVED ON; THE PAPERWORK STAYED BEHIND

When Exhibit C shows up, that debt comes due. The examiner is not interested in the rules engine from step one. The question is about the automated approval logic from step four, and the document you can actually produce describes step two.

What to do this week

You are not going to fix claims AI governance in a week, and that is not the goal. The goal this week is to find out how far behind your documentation actually is. The carriers that get hurt in an exam tend to be the ones surprised by their own gaps, not the ones who already knew where the gaps were.

Map autonomy, honestly. Go through claims system by system and put each one in a band: supportive, augmented, or automated. Pay attention to the ones that have drifted upward. A triage tool that now suggests settlement amounts belongs in augmented, whatever it was called when it went in. For anything augmented or automated, pull whatever decision logic, override records, and monitoring logs exist, and see how thin the file really is.

Stress-test the override story. Pick three recent claims where the AI recommended one thing and a human chose another. See whether you can produce the original recommendation, the human’s final decision, and the recorded reason for the difference. If you cannot, you have found a gap. If you go looking and find that humans almost never choose differently, you have found a harder one, and it is the question that will be most uncomfortable to answer in the room.

Screen your inputs for proxies. If your claims AI uses demographic or geographic data, or anything credit-adjacent, test whether those features are standing in for protected class. Write down the method and the result. “We never checked” is the answer that both Exhibit C and Exhibit D are built to punish.

None of this adds up to a finished governance program. It is closer to a flashlight. If you run it now, in a quiet week of your own choosing, the picture you get is one you control. If you wait for the exam notice, the same picture gets assembled for you, on the regulator’s schedule, with the findings written up by the person sitting across the table.

The adjuster who approved that denial in thirty seconds is not the problem. The open question is whether, six months from now, you can show it was a decision and not a reflex. That is most of what Exhibit C is asking for.

InsureAI Wire tracks NAIC and state-level AI governance developments weekly. Subscribe for updates on the evaluation tool pilot, state adoption maps, and compliance checklists.