Why Vendor AI Oversight Needs Its Own Compliance Track
Most insurers already run a third-party or vendor risk management program covering financial stability, data security, and business continuity. That program was not built to answer AI-specific questions: how a model was trained, whether its outputs vary across protected classes, or how the vendor manages model updates over time. The NAIC Model Bulletin's framing of AI governance as a program-level obligation means insurers cannot simply route vendor AI systems through the existing vendor risk process and call it complete. Because adopting states have not applied identical language, risk leaders should treat the bulletin's third-party provisions as a starting point for building a dedicated review track, then confirm the specific wording and scope against their state's adopted text before finalizing internal policy.
Due Diligence Before Deployment: What to Document
Before a vendor AI system reaches production, risk leaders need a documented basis for concluding the model is fit for its intended insurance use. That basis generally covers four areas: the model's stated purpose and intended scope of use, evidence of testing relevant to insurance outcomes such as underwriting or claims decisions, a summary of how the vendor's data was sourced and whether it reflects the insurer's book of business, and the vendor's process for notifying customers of material model changes. None of this replaces the insurer's own responsibility for the outcome. The due diligence file exists so the insurer can demonstrate, to a regulator or internal audit function, that it understood what it deployed and why it judged the model acceptable for use.
When Vendors Won't Open the Black Box, Accountability Doesn't Transfer
Vendors frequently decline to disclose full model logic or training data, citing proprietary interest. This is a common and largely unavoidable constraint, not a reason to skip oversight. Where an insurer cannot fully audit a vendor's model, the practical response is to shift emphasis from inspecting internal logic to validating outputs: independent testing of model results against the insurer's own data, documented acceptance criteria for disparate impact, and contract language requiring the vendor to notify the insurer of material changes that could affect those results. What does not change is who answers for the outcome. Across model risk management frameworks generally, limited visibility into a vendor's model does not relieve the entity using that model's output of responsibility for the decision it produces. Risk leaders should confirm whether their state's bulletin text makes this accountability explicit, but should not assume that a lack of audit access reduces their own exposure.
Ongoing Monitoring: Oversight Doesn't End at Onboarding
A due diligence file completed at onboarding answers questions about the model as it existed at a single point in time. Vendor models change: providers retrain, tune, or swap underlying models without always characterizing the change as material. A monitoring program built only around initial approval will miss drift introduced after deployment. At minimum, risk leaders should define a reassessment trigger tied to vendor-notified changes, a periodic review interval independent of vendor notification, and a mechanism for detecting output drift in production rather than relying solely on vendor self-reporting. Runtime monitoring and policy enforcement tooling can support this by giving the insurer continuous visibility into how a deployed AI system behaves in production, which is a useful complement to point-in-time due diligence rather than a substitute for it. The specific reassessment cadence a bulletin recommends, if any, should be confirmed directly against the adopted text rather than inferred from general practice.