AI Vendor Risk in Insurance Requires Evidence at the Decision Route
New York DFS Circular Letter 7 expects insurers using external AI in underwriting and pricing to keep responsibility for compliance, oversee vendors, maintain governance documentation, and seek audit and regulatory-cooperation terms where appropriate. Request-level controls connect those duties to the exact data, model, and user involved.
An underwriting service sends an applicant's claims history and external consumer data to a vendor model that returns a risk feature. The carrier still owns the resulting insurance decision. New York's 2024 Insurance Circular Letter 7 says insurers retain responsibility for understanding third-party tools used in underwriting and pricing and for ensuring compliance with applicable law. AI vendor risk insurance therefore extends through the model call, where approved data and a named deployment meet an authorized purpose.
I want to connect that supervisory expectation to the request record an insurer can produce for compliance and model risk, or for an investigation.
TL;DR
- New York DFS expects insurer governance over external data and AI used in underwriting or pricing, including third-party vendor oversight.
- The 2024 circular calls for an AI inventory and usage and performance monitoring. It also calls for vendor procedures and appropriate contract terms.
- A vendor assessment covers the supplier; request evidence connects a consumer-data class and caller to the purpose. It also captures the endpoint and model plus the policy outcome.
- Inline policy can enforce the approved model route before an authenticated underwriting request reaches the vendor.
Insurers retain responsibility for vendor tools
The 2024 circular applies to insurers authorized to write insurance in New York when they use external consumer data and information sources or AI systems in underwriting and pricing. It states that an insurer may not rely solely on a third party's non-discrimination claim or proprietary process to establish compliance. Responsibility for compliance is the insurer's throughout that use.
The letter expects written standards and policies, along with procedures and protocols for acquiring, using, or relying on vendor-developed or vendor-deployed systems. It also calls for procedures to report incorrect information to a vendor and investigate it. The same procedures should update it where needed and remove identified errors from the insurer's AI system.
Where appropriate and available, vendor contracts should provide audit rights or qualified audit reports and require cooperation with regulatory inquiries or investigations. Those terms give the insurer access to provider evidence. AI vendor risk management covers that diligence layer. The request record shows how the insurer used the approved service.
The governance inventory needs deployment detail
The circular letter says governance documentation may include an up-to-date inventory of AI systems in use and under development, plus those recently retired. It also lists each system's purpose and products; inputs and sources; actual or expected use; restrictions and potential risks. The list also includes safeguards and change history, plus usage and performance monitoring.
A vendor name alone is too coarse for that inventory. One provider may offer several models and regions, with hosting modes and retention settings plus version aliases. The insurer should identify the endpoint and tenant; model family and resolved version; approved insurance product and decision stage; external-data sources and permitted data classes. It should also identify the owner and change-notice terms, with audit evidence plus the regulatory contact path.
My opinion is that an unpinned model alias in underwriting should be treated like an unapproved rate-table change. The vendor label is the same, but the mechanism producing the feature may have changed. Insurance AI underwriting under the EU AI Act addresses a separate regulatory regime; recording the resolved version lets both programs identify affected decisions.
Request records support consumer-level review
Consumer complaints and regulatory reviews begin with an outcome. A per-request record connects the case to the provider controls approved in the vendor assessment.
Picture the review room. A claims file is open on one monitor, and yellow marks cover the margin of a printed adverse-action notice. Counsel asks which model version touched the case. The evidence should identify the authenticated employee or agent and the acting application; insurance product and approved purpose; consumer-data classification and external-data source category. It should also identify the provider endpoint and resolved model version; policy version and decision; reason plus timestamp. A stable case reference can connect the event without copying the full prompt into the audit store.
The record should also distinguish the insurer's policy decision from the model's output. Permitting a call proves only that the route and data class fit approved conditions. Actuarial validity and fairness require separate review, as do accuracy and legal sufficiency. AI audit trail requirements by regulation covers the integrity and retention design.
Supply-chain risk continues after procurement
NIST's cybersecurity supply-chain guidance, SP 800-161 Revision 1, describes an organization-wide practice for identifying and assessing risks in acquired products and services, then mitigating them. Its guidance covers strategy and policies, along with plans and risk assessments rather than a single procurement checkpoint.
For an insurer, the operational link is the approved model route. Policy can allow public drafting to a general endpoint and send regulated underwriting data to a reviewed deployment. It can require an authorized product and role, then stop a model version awaiting validation. A correction workflow can identify affected calls after a vendor reports bad source data or a model defect.
The HTTP-layer policy enforcement point makes that control preventive. It also records denied attempts, which reveal where applications or agents tried to operate outside approved conditions. Procurement evidence is necessary. Runtime evidence shows that the insurer followed the decision it made during procurement.
DeepInspect
DeepInspect is a stateless proxy for authenticated HTTP traffic between insurer users or agents and LLM endpoints. It evaluates identity and application; insurance-product context supplied by the caller and consumer-data classification; provider plus resolved model route before transmission. Policy can permit or redact the call; it can also reroute or block it.
Each decision creates a signed audit record containing the supplied caller identity and application; classification and destination; model version and policy version; outcome and reason; plus the timestamp. DeepInspect governs the managed AI request boundary. Model validation and anti-discrimination testing are the insurer's responsibility. So are actuarial judgment and notices. The insurer is also responsible for vendor contracting, regulator engagement, and final insurance decisions.
Book a demo today.
Frequently asked questions
- Does the 2024 DFS circular cover every insurer AI use?
Its stated focus is external consumer data and AI systems used in underwriting and pricing by insurers authorized in New York. Other insurance uses can fall under laws and regulations, as well as contracts and internal policies. The carrier's legal and compliance teams should determine scope for each product and jurisdiction, as well as each workflow.
- Can an insurer rely on a vendor's fairness statement?
The circular letter says an insurer may not rely solely on a third party's claim of non-discrimination or a proprietary process to determine compliance. The insurer needs its own governance and assessment, with documentation and monitoring plus controls proportionate to the use. Vendor confidentiality can shape access. The carrier still owns responsibility for the insurance outcome.
- Should every model-version change trigger review?
The review depth should follow the insurer's documented risk framework and the change's effect on data and purpose, along with behavior and decisions. Recording the resolved version lets model-risk staff identify affected requests and apply their change criteria. A high-impact underwriting route may require a hold until validation finishes.
- Can request enforcement prove an underwriting model is fair?
Request enforcement proves which authenticated caller sent which classified data to which route under a stated policy. Fairness testing and actuarial validation require separate processes, as do consumer notices and adverse-action reasons. Governance approval and legal review also require separate processes. DeepInspect preserves route evidence and enforces approved conditions at the HTTP boundary.