Governing an FNOL / Claims-Intake Triage Agent (NAIC AI Bulletin + EU AI Act)
13 min · Updated 2026-06-02
Answer
You govern an FNOL triage agent against its binding regime — the NAIC AI Model Bulletin's written AIS Program and state unfair-claims-practices law (Model #900) — not against EU AI Act Annex III, because claims-intake triage is claims handling, not the life-and-health risk assessment or pricing that Annex III(5)(c) makes high-risk. KLA enforces that with a govern-in-place policy gate on each routing decision (fast-track, adjuster queue, or SIU), routes contested fast-tracks and SIU fraud flags to a named human approver in Decision Desk before the action executes, and seals the lineage as independently verifiable evidence.
KLA is the independent, framework-neutral runtime governance and assurance layer for this workflow. KLA governs the agent you already built — in LangGraph, CrewAI, Agentforce, Microsoft Copilot, or in-house — it does not build, sell, or run the agent. The customer owns the agent; KLA owns the controls, the evidence, and the audit trail.
The workflow
The job & where the agent takes high-stakes action
An FNOL / claims-intake triage agent ingests a first notice of loss (claimant statement, policy data, photos, third-party loss data), then classifies the claim's severity and complexity, scores fraud likelihood, and routes it down one of three paths: fast-track for straight-through processing (auto-acknowledge, set reserve, advance payment, or close), route to a human adjuster queue, or flag to the Special Investigations Unit (SIU). The high-stakes action is the routing write and any straight-through side effect that follows: the agent can fast-track a claim out of human review entirely, queue it with a severity/complexity label that adjusters anchor on, or brand a claimant a suspected fraudster by routing to SIU. Model #900 confines this to claims arising under issued policies (excluding workers' compensation, fidelity, suretyship, and boiler/machinery), and the NAIC bulletin names 'case management, claim administration and payment, and fraud detection' as life-cycle areas the insurer's AIS Program must cover — so every one of these routing actions sits inside a regulated practice.
Stakes
Why it's high-stakes
A wrong fast-track or a wrong SIU flag is not a model-quality nuisance — it is an unfair claims practice the insurer is liable for regardless of whether AI made the call. Model #900 Section 4 makes it an unfair practice to refuse to pay without a reasonable investigation (F), to fail to adopt reasonable standards for prompt investigation and settlement (C), to fail to affirm or deny coverage within a reasonable time (G), to fail to give a reasonable and accurate explanation of a denial (L), and to fail to provide claim forms within fifteen (15) calendar days of a request (M). An agent that fast-tracks a closure with no investigation can trip (F); one that parks a claim in an SIU hold with no clock can trip (C) and (G); one that can't explain why it routed to SIU can trip (L). The NAIC bulletin is explicit that these statutory standards apply 'regardless of the methods the Insurer used to determine or support its actions,' and that the AIS Program exists to mitigate the risk of an 'Adverse Consumer Outcome' — a decision that adversely impacts the consumer in a way that violates the standards the regulator enforces.
What goes wrong
Failure modes specific to this agent
Silent fraud-score gating of the fast-track lane (auto-deny by omission)
The agent doesn't 'deny' a claim — it routes a borderline claim into an indefinite SIU hold or quietly keeps it out of the fast-track lane because the fraud score crossed an internal threshold. No denial letter is ever generated, no investigation clock starts, and the claimant simply never hears back. The unfair-claims-practice harm (refusing to pay without a reasonable investigation, failing to affirm or deny coverage within a reasonable time) happens through routing inaction, not through an explicit adverse decision anyone reviews.
Why it's hard to catch: Accuracy testing measures whether the SIU flag was 'right,' not whether a downstream investigation and a Model #900 timeliness clock actually started. The failure is an absence — a missing letter and a missing deadline — so it produces no error signal in a confusion matrix and no exception in the claims system. It surfaces only as an aging-claims complaint or a market-conduct exam months later.
Severity/complexity label anchoring that suppresses investigation
The agent attaches a 'low severity, low complexity' label to fast-track a claim. Human adjusters who later touch the file anchor on that label and under-investigate, and reserves are set low off the agent's classification. A genuinely large or coverage-ambiguous loss gets processed as routine because the first label framed it that way. The agent's classification, not the facts, drives the standard of investigation the claim actually receives.
Why it's hard to catch: The label is usually plausible and individually defensible, so case-by-case QA passes. The harm is a systemic shift in investigation depth that only appears in aggregate — reopened-claim rates, reserve-development surprises, and severity misclassification cohorts — none of which a per-decision unit test or a golden-dataset eval exposes. The bulletin's concern is exactly this: model behavior that diverges post-implementation from in-development performance.
Fraud-score drift and disparate fast-track rates across cohorts
The fraud-likelihood model was validated on historical claims, but loss patterns, fraud typologies, and claimant mix shift after deployment. The agent gradually starts routing one geography, product tier, or claimant cohort to SIU — or excluding it from straight-through processing — at a materially higher rate, encoding proxy discrimination into who gets fast, frictionless service and who gets investigated.
Why it's hard to catch: Each individual routing decision looks justified by the score; the disparity is statistical and only visible across cohorts over time. The NAIC bulletin names Model Drift directly — 'the decay of a model's performance over time' as deployment data diverges from training data — and requires comparing in-development to post-implementation behavior, which a one-time pre-launch fairness test cannot do. Ordinary regression tests freeze the world at launch and never see the drift.
Third-party fraud-score and loss-data passthrough with no accountability trail
The agent calls a vendor fraud-scoring model or pulls external loss/claims-history data and routes the claim on that output. When a claimant disputes an SIU referral or a denial, the insurer cannot reconstruct which third-party signal drove the routing, what version produced it, or whether the data was even suitable — because the agent treated the vendor score as an opaque input and logged only the final route.
Why it's hard to catch: The end-to-end route looks correct and the vendor call returns a tidy number, so functional tests pass. The gap is provenance: the insurer remains responsible for third-party AI Systems and data under the bulletin and must be able to answer a regulator about them, but nothing in ordinary agent testing forces capture of the vendor model version, the input data lineage, or the contractual audit posture behind the score.
How KLA governs it
Runtime controls, mapped to each decision point
KLA evaluates each consequential action with a policy gate that runs before the action executes — a Decision Request to POST /v1/decisions.evaluate — resolving to one of four outcomes in precedence order: allow → warn → require_approval → block (fail-closed by default). Every non-allow outcome carries reason codes and remediation.
| Decision point | Intercept (before action) | Policy checks → reason codes | Human routing (maker-checker) | Evidence captured |
|---|---|---|---|---|
| Fast-track a claim for straight-through processing (auto-acknowledge, set reserve, advance payment, or close) | Govern in Place: a KLA SDK checkpoint wraps the fast-track / straight-through tool call and submits a Decision Request to POST /v1/decisions.evaluate before the agent acknowledges, reserves, pays, or closes. The SDK call blocks on the outcome, so no claims-system side effect occurs until policy resolves. |
| On require_approval, KLA opens a Decision Desk Escalation routed by policy to a named claims supervisor (maker-checker: the agent is the maker, the supervisor is the checker). The reviewer sees the proposed route, the fraud score, the severity/complexity label, the triggering rule and reason codes, and a link to the Lineage Record, then approves, denies, or re-routes to a senior adjuster — execution resumes exactly where it paused only on approve. |
|
| Flag a claim to the Special Investigations Unit (SIU) on a fraud-likelihood score | Govern in Place: the SDK checkpoint on the route_claim tool submits a Decision Request before the SIU referral is written. Where a vendor fraud model or external loss-history source contributed, those tool calls are themselves intercepted so their version and inputs land in lineage before the routing action evaluates. |
| require_approval opens a Decision Desk Escalation routed to a named SIU intake reviewer; the reviewer confirms or rejects the fraud basis before the claimant is branded a suspected fraudster. Re-route hands it to a senior SIU manager without losing context. The maker-checker separation means no agent-only SIU referral leaves the system unreviewed. |
|
| Assign a severity/complexity label and route to a human adjuster queue | Govern in Place: the SDK checkpoint submits the classify-and-route Decision Request before the label and queue assignment are written to the claims system of record, so the label cannot anchor an adjuster until policy and (where required) a reviewer have cleared it. |
| Low-confidence or drift-flagged labels route as a Decision Desk Escalation to a named claims triage lead, who can correct the label before it reaches the adjuster queue. Adjusters retain the standing authority to disregard, override, or reverse the agent's classification — and every override is captured as oversight evidence. |
|
Least-privilege execution & data boundaries
- Fast-track a claim for straight-through processing (auto-acknowledge, set reserve, advance payment, or close): The agent's immutable Release binds only the tools it needs (lookup_claim, classify_severity, score_fraud, route_claim); the pay/close/advance-reserve tools are bound separately and gated. An unbound tool call (e.g., issuing payment without the route_claim gate) is blocked before execution by the Tool Catalog. Data Boundaries keep claimant PII and loss data inside the approved region/system.
- Flag a claim to the Special Investigations Unit (SIU) on a fraud-likelihood score: route_claim with target=SIU is a distinct, separately bound capability in the Release; the agent cannot escalate privilege to write an SIU referral unless that binding is active. Vendor fraud-scoring tools are bound in the Tool Catalog so an unapproved scoring source is blocked. Data Boundaries confine the fraud signals and loss-history data to the approved system.
- Assign a severity/complexity label and route to a human adjuster queue: classify_severity and route_claim are bound in the Release; the agent cannot write reserves or payments from this path. Assurance Center monitors the deployed classifier against its baseline; Data Boundaries keep claim data in-region.
Mapped to regulation
Regulatory mapping
| Framework | Article / section | Obligation (plain language) | How a KLA runtime control satisfies it | Source |
|---|---|---|---|---|
| NAIC Model Bulletin on the Use of AI Systems by Insurers (Dec 2023) | Section 3 — Regulatory Guidance & Expectations; AIS Program Guidelines 1.6 (insurance life cycle incl. case management, claim administration and payment, fraud detection) | Every insurer must maintain a written AIS Program governing AI Systems that make or support decisions across the insurance life cycle — expressly including case management, claim administration and payment, and fraud detection — designed to mitigate the risk of Adverse Consumer Outcomes. This, not EU AI Act Annex III, is the binding governance regime for an FNOL/claims-triage agent. | Each routing decision point (fast-track, SIU, adjuster-queue) is a govern-in-place policy gate, so every life-cycle action the bulletin names is enforced by a published, signed policy pack with reason codes and remediation — operationalizing the AIS Program at the moment of action rather than in a binder. | Source |
| NAIC Model Bulletin on the Use of AI Systems by Insurers (Dec 2023) | Section 3 — Risk Management & Internal Controls 3.4; Predictive Model oversight 2.4 (test for errors, bias, unfair discrimination; assess generalization post-implementation; Model Drift) | Insurers must validate, test, and retest AI Systems for errors, bias, and unfair discrimination, comparing in-development performance to post-implementation behavior and monitoring for model drift. | Assurance Center tracks the fraud-scoring and severity classifiers against cohorts and a baseline; drift or a materially different SIU/fast-track rate across cohorts raises an Assurance Alert and triggers the FNOL_DRIFT_GUARD / FNOL_SIU_FAIRNESS_COHORT policy checks, turning continuous fairness monitoring into runtime routing controls. | Source |
| NAIC Model Bulletin on the Use of AI Systems by Insurers (Dec 2023) | Section 3 — AIS Program Guidelines 4.0 (Third-Party AI Systems and Data), 4.2 (audit rights; cooperation with regulatory inquiries) | Where the agent relies on a third-party fraud-scoring model or external loss/claims data, the insurer remains responsible, must perform due diligence, and should secure contractual audit rights and vendor cooperation with regulatory inquiries. Accountability cannot be outsourced to the vendor. | The FNOL_THIRDPARTY_PROVENANCE check blocks an SIU route built on a vendor score whose model version or data suitability is not captured; the vendor call is itself intercepted so its name, version, and input lineage are sealed into evidence — giving the insurer the reconstructable record a regulatory inquiry demands. | Source |
| NAIC Unfair Claims Settlement Practices Act (Model #900) — applied via the bulletin's Section 1 legislative authority | Section 1 (Purpose; scope of claims); Section 4 (Unfair Claims Practices Defined: C, D, F, G, L, M incl. 15-calendar-day claim-form deadline) | Unfair-claims-practices law sets the standards an FNOL agent's outputs must satisfy — prompt investigation, good-faith fair settlement where liability is clear, no refusal to pay without reasonable investigation, timely affirm/deny of coverage, a reasonable and accurate explanation of any denial, and claim forms within fifteen (15) calendar days — and applies regardless of whether AI determined or supported the action. | FNOL_COVERAGE_NOT_CONFIRMED blocks silent auto-close so coverage is affirmed or denied; FNOL_SIU_EXPLAINABILITY forces a reason-coded basis so a denial/referral can be explained (L); FNOL_INVESTIGATION_CLOCK stamps the affirm/deny and 15-calendar-day form obligations onto the lineage the moment a claim leaves the fast-track lane (C, G, M). | Source |
| EU AI Act (Regulation (EU) 2024/1689) | Annex III, point 5(c) and 5(b); Article 6(2)–(4) (classification + derogation + Art. 49(2) registration) | Annex III makes high-risk only AI for 'risk assessment and pricing in relation to natural persons in the case of life and health insurance' (5(c)) and creditworthiness/credit scoring (5(b), excluding fraud detection). FNOL/claims-intake triage is claims handling — not life-and-health risk assessment or pricing — so it is generally NOT Annex III high-risk. Article 6(3) further derogates Annex III systems that do not materially influence the decision outcome, but a provider relying on it must still document the assessment and register under Article 49(2). | KLA records the classification rationale (FNOL triage falls outside Annex III(5)(c)) as governed evidence, and the human-approval gate on fast-track and SIU routing is precisely the control that keeps the agent from 'materially influencing the outcome of decision making' on its own — so if a mixed pipeline ever touches health-insurance risk assessment, the Article 6(3) derogation argument and its Article 49(2) documentation are already evidenced. | Source |
| EU AI Act (Regulation (EU) 2024/1689) | Article 14 (Human oversight) — 14(1), 14(4)(b) automation bias, 14(4)(d) disregard/override/reverse, 14(4)(e) stop-to-safe-state | Where an insurance AI system IS high-risk, oversight persons must be able to oversee it effectively, stay aware of automation bias, decide not to use / disregard / override / reverse its output, and interrupt it to a safe state. Cited as the governance pattern even though FNOL triage is generally outside Annex III, because mixed FNOL pipelines may touch health-insurance risk assessment. | require_approval pauses the routing action and hands it to a named Decision Desk reviewer who can disregard/override/reverse the agent's route (14(4)(d)); block is the stop-to-safe-state on fail-closed (14(4)(e)); the label-override-audit and SIU confirmation surface automation bias by making humans confirm rather than rubber-stamp (14(4)(b)). | Source |
| EU AI Act (Regulation (EU) 2024/1689) | Article 26 (Deployer obligations) — 26(2) competent oversight, 26(6) keep logs ≥ 6 months, 26(11) inform affected natural persons | Deployers of high-risk systems must assign human oversight to competent, trained, authorized persons (26(2)); keep auto-generated logs for at least six months (26(6)); and inform affected natural persons when an Annex III system makes or assists decisions about them (26(11)). | Decision Desk routes Escalations to named, authorized claims/SIU reviewers (26(2)); the ImmuDB append-only ledger retains lineage well beyond the six-month floor (26(6)); reason codes plus remediation give the explanation needed to inform an affected claimant that an AI system contributed to the routing (26(11)). | Source |
| EU AI Act (Regulation (EU) 2024/1689) | Article 12 (Record-keeping / automatic logging) — 12(1), 12(2)(a)–(c) | High-risk AI systems must technically allow automatic event logging over their lifetime to enable risk identification, post-market monitoring (Art. 72), and operation monitoring (Art. 26(5)). | Evidence-by-default captures every routing decision, fraud score, tool call, and human verdict as OpenTelemetry spans sealed into the append-only ledger, and the Evidence Room can export a Control Pack mapped to EU AI Act Annex IV — the exact automatic, lifetime logging substrate Article 12 requires if the system is in scope. | Source |
| Insurance Distribution Directive (Directive (EU) 2016/97) | Article 17(1)–(2) (general principle: honest, fair, professional; information fair, clear, not misleading) | Insurance distributors must act honestly, fairly, and professionally in customers' best interests, and information to customers must be fair, clear, and not misleading. SCOPE CAVEAT: the IDD governs insurance distribution (sales/advice/intermediation), NOT claims handling per se — so it is a fair-treatment background norm on the EU side, not the binding claims-triage regime. The binding EU-side gap is that FNOL claims handling is not an Annex III high-risk use case; the operative regime is the NAIC bulletin + state unfair-claims-practices law (US) and national insurance-conduct law (EU). | The reason-code + remediation requirement on every non-allow outcome means any claimant-facing communication the agent triggers carries a fair, clear, non-misleading basis — supporting the IDD fairness norm where claims handling shades into customer information, without overclaiming that the IDD governs triage. | Source |
Prove the control held
Audit-evidence checklist
- Written AIS Program reference linked to each governed routing rule (bulletin Section 3) — which policy pack version enforces case-management, claim-administration, and fraud-detection life-cycle controls
- For every fast-track: the Decision Request, fraud score, severity/complexity label, policy outcome, reason codes, and (if held out of fast-track) the stamped Model #900 affirm/deny + 15-calendar-day form clock
- For every SIU referral: the reason-coded basis, the vendor fraud-model name/version and input data lineage, the cohort-disparity check result, and the named SIU reviewer's verdict
- Assurance Center fairness/drift evidence: cohort-level SIU and fast-track rates over time, drift alerts on the fraud and severity models, and the in-development-vs-post-implementation comparison the bulletin requires
- Human-oversight evidence: every Escalation with approver identity, verdict, note, and timestamp; every adjuster override of an agent label (Art. 14 / 26(2))
- Third-party accountability evidence: vendor model versions, data-suitability records, and contractual audit-rights/cooperation posture (bulletin 4.0/4.2)
- Retention proof: lineage entries on the append-only ImmuDB ledger held beyond the EU AI Act Art. 26(6) six-month floor, each verifiable via GET /v1/lineage/{id}/verify
- Sealed Evidence Bundle / Control Pack export (EU AI Act Annex IV mapping) an auditor can verify against the published root hash without trusting KLA
A concrete intercept
Reference scenario: A high-fraud-score claim the agent tries to fast-track and silently close
- 1
FNOL ingested: a water-damage claim with a vendor fraud score of 0.82 and a severity label of 'low'; the agent plans to fast-track it — set a small reserve and auto-close — via route_claim(target=fast_track) plus the close tool.
- 2
Before the close executes, the Govern in Place SDK checkpoint submits a Decision Request to POST /v1/decisions.evaluate with the fraud score, severity label, and target lane.
- 3
Policy matches FNOL_FASTTRACK_FRAUD_CEILING (fraud 0.82 > straight-through ceiling) and FNOL_COVERAGE_NOT_CONFIRMED (no affirmative coverage step); the strongest outcome, require_approval, wins, with reasonCodes FRAUD_SCORE_OVER_FASTTRACK_LIMIT + COVERAGE_UNCONFIRMED_NO_AUTOCLOSE and remediation 'High fraud score and unconfirmed coverage: a human must decide investigate vs. affirm/deny before any close.'
- 4
Execution pauses (the close never fires); KLA opens a Decision Desk Escalation routed by policy to a named claims supervisor, who sees the action, the 0.82 score, the 'low' label, the triggering rules, and a link to the Lineage Record.
- 5
The supervisor rejects the silent fast-track and re-routes to SIU intake for a documented investigation — which starts the Model #900 timeliness clock (affirm/deny obligation; claim forms within 15 calendar days) that the FNOL_INVESTIGATION_CLOCK warn stamped onto the lineage.
- 6
Every step — the blocked fast-track, the reason codes, the supervisor's verdict and note, the SIU re-route, and the stamped UCSPA clock — is sealed into a Merkle-proofed Lineage Record on the append-only ledger, exportable as a Control Pack and verifiable via GET /v1/lineage/{id}/verify without trusting KLA.
What most teams get wrong
The non-obvious insight
FNOL / claims-intake triage is almost certainly NOT EU AI Act Annex III high-risk — Annex III(5)(c) captures only 'risk assessment and pricing in relation to natural persons in the case of life and health insurance,' which is underwriting/pricing, not claims handling. Teams that reflexively label every insurance agent 'high-risk' and chase Annex IV technical documentation are governing to the wrong regime: the binding constraint on an FNOL agent is the NAIC AI Bulletin's AIS Program plus state unfair-claims-practices law (Model #900), which apply 'regardless of the methods the Insurer used,' carry concrete deadlines (claim forms within 15 calendar days), and bite on every fast-track and SIU flag today — with no 2026/2027 effective-date debate.
Why it matters: Misclassifying the regime wastes effort on EU conformity paperwork while leaving the actual liability surface — silent auto-denial, missed affirm/deny clocks, unexplained SIU referrals — ungoverned. The correct posture is to govern hardest where Model #900 bites (the routing actions), document the Annex III non-applicability as evidence, and keep the EU human-oversight pattern (Art. 14 require_approval) in reserve for any mixed pipeline that touches health-insurance risk assessment — at which point Article 6(3)'s 'does not materially influence the outcome' derogation, satisfied precisely by the human-approval gate, becomes the argument that the gate also documents.
The hardest FNOL failure to govern is not a wrong decision but a non-decision: an agent that routes a claim out of the fast-track lane on a fraud score and never starts an affirm/deny clock commits an unfair claims practice by omission — and because there is no adverse 'decision' to test, no confusion matrix or golden-dataset eval will ever flag it. The only reliable control is an intercept that, the moment a claim leaves the fast-track lane, stamps the Model #900 timeliness obligation onto immutable lineage.
Q&A
Frequently asked questions
Is an FNOL / claims-intake triage agent high-risk under the EU AI Act?
Generally no. EU AI Act Annex III(5)(c) makes high-risk only AI used 'for risk assessment and pricing in relation to natural persons in the case of life and health insurance' — that is underwriting and pricing, not claims handling. FNOL triage classifies, scores fraud, and routes claims, so it is not captured by Annex III(5)(c), and 5(b) (creditworthiness/credit scoring) is a separate domain that even carves out fraud detection. Do not assert FNOL triage is automatically high-risk under the Act. If a pipeline mixes triage with health-insurance risk assessment, classification turns on Annex III plus the Article 6(3) derogation (whether the system 'materially influences the outcome'), and a provider relying on that derogation must still document the assessment and register under Article 49(2).
If the EU AI Act doesn't bind it, what regime actually governs an FNOL triage agent?
In the US, the NAIC AI Model Bulletin (Dec 2023) requires a written AIS Program covering AI across the insurance life cycle — naming 'case management, claim administration and payment, and fraud detection' — and state unfair-claims-practices law (NAIC Model #900). The bulletin is explicit that those claims standards apply 'regardless of the methods the Insurer used to determine or support its actions,' so the agent's outputs must satisfy Model #900's duties: prompt investigation, no refusal to pay without a reasonable investigation, timely affirm/deny of coverage, a reasonable explanation of any denial, and claim forms within fifteen (15) calendar days of a request. That, not Annex IV, is the binding constraint on each routing action.
How does KLA stop the agent from silently auto-denying a claim by routing it into an SIU hold?
The govern-in-place SDK checkpoint submits a Decision Request before the routing write executes. The FNOL_COVERAGE_NOT_CONFIRMED check blocks any auto-close/auto-deny path that lacks an affirmative coverage step, and FNOL_INVESTIGATION_CLOCK stamps the Model #900 affirm/deny and 15-calendar-day form obligations onto the lineage the moment a claim leaves the fast-track lane. A held-or-suspicious claim becomes a require_approval Escalation to a named claims supervisor — so a non-decision can no longer happen by omission; it becomes a tracked decision with a clock and a human owner.
Who approves a fast-track or an SIU referral, and what do they see?
On require_approval, KLA opens a Decision Desk Escalation routed by policy to a named approver — a claims supervisor for contested fast-tracks, an SIU intake reviewer for fraud flags. The reviewer sees the proposed route, the fraud score, the severity/complexity label, the exact triggering rule with its reason codes, and a link to the full Lineage Record, then approves, denies, or re-routes to a senior reviewer. This is maker-checker: the agent is the maker, the human is the checker, and execution resumes only on approve.
The fraud score comes from a third-party model — who is accountable if a claimant disputes the SIU referral?
The insurer is. NAIC bulletin Section 4.0/4.2 keeps the insurer responsible for third-party AI Systems and data and expects contractual audit rights plus vendor cooperation with regulatory inquiries. KLA intercepts the vendor scoring call so its model name, version, and input-data lineage are sealed into evidence, and FNOL_THIRDPARTY_PROVENANCE blocks an SIU route built on a vendor score whose version or data suitability was not captured — so the insurer can always reconstruct which third-party signal drove the routing.
How does KLA detect that the agent has started routing one cohort to SIU more than others?
Assurance Center tracks how automated outcomes distribute across cohorts you define (geography, product tier, age bracket). If the SIU or fast-track exclusion rate for one cohort diverges materially, that becomes an Assurance Alert with the cohort breakdown attached, and the FNOL_SIU_FAIRNESS_COHORT / FNOL_DRIFT_GUARD checks turn that signal into a runtime routing control. This directly answers the NAIC bulletin's requirement to test for unfair discrimination and to compare in-development against post-implementation behavior, which a one-time pre-launch fairness test cannot do.
Related blueprints & guides
- Governing a Claims-Settlement Recommendation Agent: Fair, Explainable, Auditable Offers
- Governing an AML Transaction-Monitoring Alert-Triage Agent
- Governing a Pharmacovigilance Adverse-Event Intake & Case-Processing Agent
- Insurance governed-workflow blueprints (hub)
- Governing a claims-settlement-recommendation agent
- Governing an AML transaction-monitoring alert-triage agent
- Add a Human Approval Gate (KLA docs)
- Govern an Agent End-to-End (KLA docs)
- Policy-Gated Execution (KLA docs)
- Decision Desk (KLA docs)
- Assurance Center (KLA docs)
- Evidence Room (KLA docs)
Primary sources
- NAIC Model Bulletin: Use of Artificial Intelligence Systems by Insurers — NAIC
- NAIC Unfair Claims Settlement Practices Act (Model #900) — Section 4 Unfair Claims Practices Defined — NAIC
- EU AI Act — Annex III, point 5 (essential private/public services), incl. 5(c) insurance — EUR-Lex (mirrored at artificialintelligenceact.eu, Regulation (EU) 2024/1689)
- EU AI Act — Article 6 (Classification rules for high-risk AI systems), incl. 6(2), 6(3) derogation and 6(4) — EUR-Lex (mirrored at artificialintelligenceact.eu, Regulation (EU) 2024/1689)
- EU AI Act — Article 14 (Human oversight) — EUR-Lex (mirrored at artificialintelligenceact.eu, Regulation (EU) 2024/1689)
- EU AI Act — Article 26 (Obligations of deployers of high-risk AI systems) — EUR-Lex (mirrored at artificialintelligenceact.eu, Regulation (EU) 2024/1689)
- EU AI Act — Article 12 (Record-keeping / automatic logging) — EUR-Lex (mirrored at artificialintelligenceact.eu, Regulation (EU) 2024/1689)
- Insurance Distribution Directive (Directive (EU) 2016/97) — Article 17 General principle — EIOPA Rulebook / EUR-Lex
- KLA Docs — Govern an Agent End-to-End — KLA Digital
- KLA Docs — Add a Human Approval Gate — KLA Digital
- KLA Docs — Policy-Gated Execution — KLA Digital
- KLA Docs — Evidence-by-Default — KLA Digital
- KLA Docs — Architecture Overview — KLA Digital
- KLA Docs — Agents & Registry (Releases, Tool Catalog, least-privilege) — KLA Digital
- KLA Docs — Assurance Center (drift, bias/fairness cohorts) — KLA Digital
- KLA Docs — Decision Desk (maker-checker, re-route to SIU/senior reviewer) — KLA Digital
- KLA Docs — Evidence Room (Sealed Evidence Bundle, Control Pack, EU AI Act Annex IV mapping) — KLA Digital
- KLA Docs — API Reference (decisions.evaluate, lineage verify) — KLA Digital
Govern this workflow without re-platforming the agent
KLA wraps the agent you already run, gates each high-stakes action, routes the hard calls to a named human, and seals independently verifiable evidence mapped to regulation.