Compliance Guide: Insurance

    Insurance LLM Prompt and Response Retention Requirements: What Regulators Expect

    The provisions of NYDFS Circular Letter 7 and Colorado SB 24-205 described in this guide do not require insurers to retain every LLM prompt and response. The expectation is evidence: documented governance, and the ability to show what an AI system was allowed to do and what it did. Retention scope for prompts and responses is therefore largely an internal design decision. It should be risk-based, written down and tied to enforcement events such as redaction, blocking and escalation.

    Evaluating runtime enforcement that produces evidence

    • Can policy decisions and enforcement actions be recorded separately from prompt and response content?
    • Can retention be configured by record category and aligned to the insurer's retention plan and internal policy?
    • Is redaction applied before storage, and can the insurer verify it?
    • Are records tamper-evident and reconstructable from a separate location?
    • Does the deployment run in the insurer's own cloud, with the insurer controlling residency?
    • How are evidence outputs mapped to NAIC and NYDFS expectations, and what is documented versus asserted?

    What each regime states, and what it leaves open

    NYDFS Insurance Circular Letter No. 7, dated July 11, 2024, sets out the Department's expectations for how authorized insurers, Article 43 corporations, HMOs, licensed fraternal benefit societies and the NY State Insurance Fund develop and manage ECDIS, AIS and other predictive models in underwriting and pricing. It expects policies and procedures with clearly defined roles and responsibilities, plus monitoring and reporting requirements to senior management. The final version also adds a clause drawn from the NAIC Model Bulletin on the Use of Artificial Intelligence Systems by Insurers, expecting certain terms in third-party vendor contracts where appropriate.

    The circular also says an insurer should not use ECDIS or AIS in underwriting or pricing unless it can establish that the data source or model does not use, and is not based in any way on, a class protected under Insurance Law Article 26. The same applies if the use would result in or permit unfair discrimination. The burden to establish implies demonstrable evidence. As stated, though, it does not name record types or retention periods.

    Colorado SB 24-205 includes developer duties to disclose known or reasonably foreseeable algorithmic discrimination risks to the attorney general and to known deployers or developers, within 90 days after discovery or after a credible deployer report. These are risk-communication duties. They are not framed as a retention rule for an insurer's LLM interactions. Status and obligations for any of these regimes should be confirmed as of October 2026.

    Separate requirements, expectations and design choices

    The useful question is not whether to retain everything. It is what evidence must exist to show what the AI was allowed to do and what it did. Answering that depends on keeping three categories apart.

    Explicit requirements are obligations stated in a rule, such as the records retention plan and tamper safeguards under New York Regulation 152 for the records it covers. Regulator expectations are the governance outcomes an examiner can reasonably look for: documented policies, assigned roles, monitoring, reporting to senior management, and the ability to establish non-discrimination. Internal design choices are everything the text does not settle, including capture scope, redaction before storage, retention periods by category and where data resides.

    Most teams get into trouble by treating a design choice as a mandate, or an expectation as optional. Writing down which category each retention decision belongs to makes the policy easier to defend. No source supports a claim that any regulator has endorsed a particular retention approach, and a page, policy or vendor claim should not imply one.

    Regulation 152 is the concrete retention reference

    NY Regulation 152 (11 NYCRR Part 243) is not AI-specific, but it is the most detailed retention framework available for New York insurers. It requires an insurer to establish and maintain a records retention plan describing the types of records retained, the method of retention and the safeguards against alteration. The plan must be provided to the superintendent on request, and the insurer must certify the accuracy of records provided under it.

    DFS opinions state that records covered by the regulation generally must be retained for six years under 11 NYCRR § 243.3(b), and that the policy record is kept six calendar years after the relationship with the licensee terminates. Electronic retention is permitted if the medium qualifies as a durable medium and the insurer can demonstrate that stored documents have not been tampered with. If the original paper record is not kept, a duplicate or back-up system at a separate location must allow reconstruction. DFS describes the purpose as letting the Department examine the insurer's operations for compliance. Records maintained by an agency on the insurer's behalf are subject to the insurer's requirements.

    Whether prompts, responses, policy decisions or enforcement events count as Regulation 152 records is an interpretation question for counsel. If they do, a retention plan entry and the six-year default become relevant. Even if they do not, tamper-evidence, durable storage and reconstruction are sound design targets for any AI evidence store.

    Capture options and their tradeoffs

    The comparison below is analysis, not regulator guidance. Each option trades auditability against stored sensitive data, and the right mix can differ by use case and risk tier.

    • Full capture: Strongest reconstruction of each interaction. Largest volume, highest concentration of policyholder data, and the widest discovery and privacy exposure.
    • Sampled capture: Lower volume and exposure. Supports monitoring and testing, but cannot show what happened in an interaction that was not sampled.
    • Redacted capture: Keeps interaction context while removing sensitive values before storage. Depends on redaction being applied before write and being verifiable.
    • Decisions and enforcement events only: Smallest footprint. Shows what policy applied and what was allowed, redacted, blocked or escalated, but not full content.

    Defining a defensible, risk-based retention scope

    Start with the uses the Circular Letter addresses: underwriting and pricing with ECDIS, AIS and predictive models. Document separately any other LLM use cases the insurer chooses to cover, and state why. Then set retention per evidence category rather than one period for everything.

    Policy decisions and enforcement events are the core of the evidence question. They show what the AI was permitted to do and how policy was applied when it acted. They are compact, carry little sensitive content, and can be kept for the longer period the insurer's retention plan sets. Interaction content is where scope decisions matter most. Higher-risk uses may justify redacted or full capture for a defined period. Lower-risk uses may justify sampling or decision-only records.

    Over-retaining prompts and responses concentrates nonpublic personal information in a new store, which adds privacy exposure, discovery burden and storage sprawl. Under-retaining leaves the insurer unable to show an examiner what a system did. A written rationale for the chosen scope, owned within the roles and reporting structure Circular Letter 7 expects, is the artifact that holds the position together. Third parties that hold records for the insurer should be required to meet the insurer's retention standard, and vendor contracts should be reviewed for the terms the circular expects.

    Three evidence categories, retained separately

    Interactions

    Prompt and response content, captured in full, sampled or redacted form.

    Policy decisions

    What the AI system was permitted to do in a given context.

    Enforcement events

    Allow, redact, block and escalate outcomes at runtime.

    Define the evidence your AI systems must produce

    See how policy enforced at runtime generates audit-ready evidence with configurable retention in your own cloud.

    See How Evidence Is Produced