EU AI Act Article 9 vs NAIC AIS Program: Risk Management Mapping for US Insurers in the EU

Two frameworks with different units of obligation

The NAIC Model Bulletin on the Use of Artificial Intelligence Systems by Insurers was adopted in December 2023. It is a guiding document, not a model law or regulation, and it is meant to foster uniformity among state insurance regulators on what they expect of carriers deploying AI. It expects an insurer to create and implement a written AIS Program, commensurate with an assessment of risk and in line with the NAIC's 2020 Principles of Artificial Intelligence. It also expects AI-made or AI-supported decisions that affect consumers to be accurate and to comply with unfair trade practice laws and other applicable legal standards. Because the bulletin is a model document, state adoption and examination expectations can vary, so it should not be described as directly binding in every state.

Article 9 of Regulation (EU) 2024/1689 works at a different level. Article 9(1) requires that a risk management system be established, implemented, documented and maintained in relation to high-risk AI systems. The obligation attaches to the system, not to the company's overall program. A US insurer can therefore have a sound AIS Program and still lack the per-system documentation that Article 9 expects.

The practical consequence is a layering model. The AIS Program is the organizational anchor. Article 9 adds system-level lifecycle risk documentation on top of it for each in-scope system.

Crosswalk: Article 9 against the NAIC AIS Program

The table uses a working risk management lifecycle to line up the two regimes. It is a planning aid for your own mapping, not a paragraph-by-paragraph legal reading. Confirm the detail against the full regulation text and your counsel's advice.

• Documented system: Article 9: documented and maintained per high-risk system. NAIC: written AIS Program for the organization. Overlap in documentation discipline; divergence in unit of scope.
• Risk identification and evaluation: Article 9: performed for each in-scope system and its use. NAIC: program commensurate with an assessment of risk. The program sets the method; the system-level record applies it.
• Mitigation measures: Article 9(3): covers risks that can reasonably be mitigated or eliminated through design, development or adequate technical information. NAIC: consumer-affecting decisions must be accurate and lawful. Different tests, shared need for effective controls.
• Testing and residual risk: Article 9: expect system-level records of what was tested and what risk remains. NAIC: the AIS Program should describe how your organization validates and accepts risk. Keep the record per system.
• Interaction with other requirements: Article 9(4): measures must consider the combined effect of the other requirements in the same Section. Evidence should not sit in an Article 9-only silo.
• Continuous iteration: Article 9(1): the system is maintained, not produced once. NAIC: the program is implemented and kept current. Both need a living record, not a point-in-time file.

Where the regimes overlap and where they diverge

The overlap is real. Both expect written documentation, both scale expectations to risk, and both care about outcomes for the people affected by AI-supported decisions. An insurer that already runs a mature AIS Program has done much of the governance work that Article 9 presupposes, including ownership, risk assessment practice and documentation habits.

The divergence is in scope and granularity. The NAIC bulletin addresses AI used by or on behalf of an insurer to make or support decisions, at program level. Article 9 addresses the lifecycle of individual high-risk systems. Article 9(3) also bounds what counts: the risks covered are those that development, design or adequate technical information can reasonably mitigate or eliminate. A control mapped to Article 9 should be traceable to that scope.

Classification is the first scoping step. The Commission publishes guidelines for providers and deployers that explain how AI systems are classified as high-risk, with practical examples. A recital also states that AI systems provided for by Union law for detecting fraud in financial services, and for prudential calculation of insurers' capital requirements, should not be considered high-risk. Test each insurance use case against both before assuming Article 9 applies.

Gaps a single AIS Program cannot close alone

Three gaps recur. The first is system-level lifecycle documentation. An organization-level program describes how risk is governed in general. Article 9 expects a maintained record for each high-risk system, so the AIS Program needs per-system risk files attached to it.

The second is role clarity. The EU regime distinguishes providers from deployers, and a US insurer may hold either role depending on the system. A US-oriented AIS Program is not written around that distinction, so it should be extended to record which role applies to each system and which obligations follow.

The third is timeline. On 19 November 2025 the Commission proposed targeted amendments, the Digital Omnibus on AI, to address delays in standards and in designating national competent authorities and conformity assessment bodies. As of November 2026, the European Parliament's legislative tracker reports fixed deadlines for the delayed application of high-risk rules: 2 December 2027 for stand-alone high-risk AI systems and 2 August 2028 for those embedded in products. Plan against both the original and the delayed dates, record the date you last checked the status, and assign an owner to track the outcome.

Which gaps depend on runtime enforcement and evidence

Article 9(3) suggests a useful split. Some controls are fixed before deployment: design choices, development practices, the technical information supplied to users. Others operate while the system runs. Pre-deployment work stays organizational and is documented in the program and the system file. Runtime controls produce a different kind of record, one about individual interactions.

That is where a documented policy can diverge from observed behavior. A risk file may state that a system must not expose certain personal data or must not take certain actions without human approval. A regulator or auditor will want to see that the rule was applied when the system actually ran. Enforcing policy in the execution path, with decisions to allow, redact, block or escalate for human approval, creates a record of what the AI was permitted to do and what it did, interaction by interaction and tool call by tool call.

Trussed enforces policy in the execution path across models, agents, tools and MCP servers, and generates continuous audit-ready evidence from that enforcement, mapped to NAIC and EU AI Act requirements. Its scope is individual interactions and tool calls. It does not replace the AIS Program, the system-level risk file, pre-deployment testing or legal review, and no tool delivers compliance on its own. It supplies runtime evidence that those documents can reference. This page is not legal advice.