AIS Program Template for Small Insurers: Sections, Controls and Evidence

What the template is anchored to

The NAIC AI Model Bulletin reminds insurers that decisions or actions made or supported by AI must comply with all applicable insurance laws and regulations. It also sets expectations for how insurers govern AI use and tells them what information a Department may request in an investigation or examination. The AIS Program is the written vehicle for that governance.

The bulletin says the program should address governance, risk management controls and internal audit functions. It should cover AI use across the insurance life cycle, from product development and marketing through underwriting, rating and pricing, claim administration and fraud detection. It should also cover each phase of an AI system's life cycle: design, development, validation, implementation, use, ongoing monitoring, updating and retirement.

NYDFS Circular Letter 7 adds several expectations that a template should absorb. Insurers should formalize development and management of AIS and external consumer data and information sources (ECDIS) in written policies and procedures. They should run a training program with a regular cadence and accountability for completion. They should maintain comprehensive documentation of all AIS use, whether built internally or supplied by third parties, and be ready to give it to the Department on request. Colorado SB 24-205 lists duties that include a risk management policy and program for high-risk systems and disclosure to the attorney general within 90 days after discovering algorithmic discrimination. As of October 2026, counsel should confirm which of those duties apply to your company before the template asserts Colorado coverage.

Sections that are primarily documentation

Some sections are satisfied by a well-written, approved document. The first is governance and accountability. The template should vest responsibility for developing, implementing, monitoring and overseeing the program in named roles, with senior management accountable to the board or a board committee. A small insurer without an AI function should name specific officers or an existing committee rather than a generic "AI owner."

The second is scope and life-cycle coverage. State which insurance functions and which AI life-cycle phases the program covers, and tie the program to existing compliance processes, since AI-supported decisions are subject to existing insurance law.

The third is the AI system inventory. NYDFS expects documentation of all AIS use, including ECDIS relied upon and third-party systems. The inventory is a living record, so assign an owner and an update trigger, such as new deployment, material change or retirement.

The fourth is standards for model development, implementation, use and validation, with provisions for independent review and effective challenge. These are written standards, but their operation depends on people who are available to apply them.

Sections that need operational controls

A template fails when a section describes a requirement but nothing in operations applies it. Four sections need a control that runs, not only a paragraph.

Risk identification, mitigation and internal controls: the bulletin expects the framework and internal controls to be documented generally and at each life-cycle stage. The control is whatever actually limits what an AI system can do, such as which data it may receive and which actions it may take.

Third-party AI systems and data: the program should address how third-party AI is acquired, used and relied on. Contract terms and due diligence are documentation. The operational part is how the insurer controls what is sent to and returned from a vendor system it calls.

Monitoring and internal audit: the use and ongoing monitoring phases require observation that produces records an auditor can examine. NYDFS also expects the internal audit function to be engaged with AIS and ECDIS use.

Review and effectiveness: the NAIC supplement asks how the program is integrated, assessed and remediated, and how effectiveness is assessed. Give this section an owner, a cadence and a remediation record.

Where runtime policy enforcement fits, and where it does not

Runtime policy enforcement applies written policy in the execution path, at the point where an AI system receives a request or calls a tool. Trussed enforces policy there: it can allow, redact, block, rate limit or escalate an interaction for human approval, across models, agents, tools and MCP servers. It generates audit-ready evidence from those enforcement decisions, mapped to NAIC and NYDFS expectations.

That maps to the control-oriented sections of the template. A rule that customer identifiers must not reach an external model becomes a redact or block decision on each interaction. A rule that a tool call affecting a claim requires approval becomes an escalation for human approval. Each decision produces a record that can support the monitoring and audit documentation the NAIC bulletin lists. Recording the policy version applied at each decision lets the evidence tie back to the approved written program.

The scope is individual interactions and tool calls. Runtime enforcement does not replace governance, the inventory, validation standards, training or independent review, and it does not trace whole business transactions or complete agentic workflows. Whether a control point can sit in front of an AI feature embedded inside a vendor product depends on the architecture. It is most direct for AI the insurer operates or calls through an API. For small insurers, a self-managed deployment in the customer cloud with configurable retention and data residency can help keep evidence within existing data boundaries.

Keeping the template proportionate

A small insurer should scale each section to its risk and staffing without dropping any element. Start with the inventory and rank systems by their effect on consumers, such as underwriting, pricing and claims, and apply the fullest controls there. Lower-risk internal uses can follow lighter review with the same documentation structure.

Independence is the hardest section when staff are few. NYDFS expects independent review, effective challenge and internal audit engagement. Decide in advance who provides that challenge, whether an internal audit function, a compliance officer outside the business line that owns the system, or an external reviewer, and record the decision in the template.

For third-party systems, concentrate effort on the controls you can exercise directly: what data you send, which actions the system may trigger on your behalf, and what evidence you can retain. Keep vendor documentation in the file, but do not treat it as a substitute for your own record of use.