LLM Reservation of Rights Letter Drafting: Runtime Controls Under Current AI Rules

Treat the letter as a consequential output

A reservation of rights letter tells a policyholder that the insurer is handling a claim while preserving its coverage defenses. It is a legal communication, not a productivity artifact. New York DFS states that the Insurance Law does not specifically address reservation of rights, that no regulation specifies the language of a standard letter, and that the insurer is responsible for meeting whatever case law requires. For that reason, accuracy of the cited policy language, facts and coverage grounds is a legal-content risk, not a style risk.

New York DFS also distinguishes reservation of rights letters from disclaimer letters, which give notice of intent to deny coverage or disclaim liability, and says reservation letters are usually not effective as disclaimers. A draft that blurs reservation and denial is a separate failure mode to test for.

The failure modes that matter most with LLM drafting are fabricated policy provisions, omitted or misstated coverage grounds, incorrect deadlines, exposure of personal data and unreviewed output reaching a claimant. Timing and content requirements vary by jurisdiction, so the workflow needs jurisdiction-specific checklists maintained by compliance and counsel. The model should never be the source of those rules.

Define the drafting boundary in writing

The boundary should be explicit enough to translate directly into runtime policy. If a permission is not written down, it cannot be enforced or evidenced. The table below separates what the model may do from what stays with a licensed person.

• Policy language: Model: quotes and organizes provisions from supplied policy text. Human: confirms the provisions are the right ones for the loss.
• Claim facts: Model: summarizes facts from the supplied claim record. Human: resolves conflicts and gaps in the facts.
• Coverage grounds: Model: lays out grounds already identified by the adjuster or counsel. Human: decides which grounds to reserve.
• Template choice: Model: fills a reservation of rights template. Human: decides whether the matter is a reservation or a disclaimer.
• Approval and sending: Model: none. Human: final approval and release belong to the adjuster or coverage counsel.

What current regulation expects, as of October 2026

The NAIC AI Model Bulletin says an insurer's AIS Program should be designed to mitigate the risk that AI use results in Adverse Consumer Outcomes. A wrongly worded or wrongly timed reservation letter is a plausible example of such an outcome. The bulletin also lists contract terms with third-party AI system, model and data vendors as a governance topic, including data security and privacy, confidentiality and cooperation with regulators. Confirm each state's adoption status before mapping obligations.

NYDFS Insurance Circular Letter No. 7, issued July 11, 2024, is titled as covering the use of AI systems in insurance underwriting. It should not be cited as a rule for claims letters. Teams in New York can still treat it as a reference point for how the department thinks about AI governance and documentation.

Colorado changed after the original brief for this topic was framed. SB 24-205 created consumer protections from algorithmic discrimination in consequential decisions made by high-risk AI systems. The Colorado Attorney General now reports that SB 26-189, signed May 2026, repeals and reenacts those provisions with new requirements for automated decision-making technology in consequential decisions. Requirements and dates under SB 24-205 are superseded, so Colorado-specific controls should be built against the current law and reviewed with counsel.

The common thread is that regulators ask what the AI was allowed to do and what it did. A post-hoc review of finished letters does not answer the first half of that question.

Testing the controls and evaluating tooling

Test with adversarial cases before production: missing policy text, conflicting facts, sensitive data buried in the claim file, a prompt asking the model to decide coverage, and an attempt to send without approval. Each case should have an expected enforcement outcome, and the result should be retained as evidence. Repeat the tests when policy forms, templates, models or jurisdictions change.

When evaluating enforcement tooling, ask whether it acts in the execution path or only reviews afterward, whether evidence is produced per interaction and per tool call, what stops an unapproved send, and where evidence is stored and for how long.

Trussed enforces policy in the execution path across models, agents, tools and MCP servers, with allow, redact, block, rate limit and escalate for human approval at the level of individual interactions and tool calls. Enforcement generates audit-ready evidence mapped to NAIC and NYDFS expectations, and deployment is self-managed in the customer cloud with configurable retention and data residency. Trussed does not provide transaction-level governance or end-to-end tracing of agentic workflows. The claims system remains the record of the claim workflow and the licensed human remains the decision-maker.