What is an AI system? Regulatory definitions compared for insurers
There is no single regulatory definition of an AI system. The EU AI Act and NIST AI RMF define it by characteristics such as autonomy and generated outputs, and the EU adds inference and adaptiveness. NYDFS Circular Letter 7 defines it by function and by use in underwriting or pricing. Colorado SB 24-205 frames duties around high-risk AI systems. Insurers should scope inventories against the broadest characteristic-based definition, then overlay the use-based and high-risk tests.
How each regime defines or characterizes an AI system
The regimes use different structures. Two describe what a system is, one describes what a system is used for, and one frames obligations around a risk tier. Reading them side by side shows why a single yes or no test does not work across jurisdictions.
- EU AI Act: A machine-based system designed to operate with varying levels of autonomy, that may exhibit adaptiveness after deployment, and that, for explicit or implicit objectives, infers from the input it receives how to generate outputs such as predictions, content, recommendations or decisions that can influence physical or virtual environments.
- NIST AI RMF: An engineered or machine-based system that can, for a given set of objectives, generate outputs such as predictions, recommendations or decisions influencing real or virtual environments. The framework also states that AI systems are designed to operate with varying levels of autonomy.
- NYDFS Circular Letter 7: Any machine-based system designed to perform functions normally associated with human intelligence, such as reasoning, learning and self-improvement, used in whole or in part to supplement or act as a proxy for traditional health, life, property or casualty underwriting or pricing, or to identify lifestyle indicators that may contribute to an underwriting or pricing assessment.
- Colorado SB 24-205: Obligations are framed around high-risk artificial intelligence systems. Developers must use reasonable care to protect consumers from known or reasonably foreseeable risks of algorithmic discrimination, and must give deployers disclosure statements and documentation for impact assessments.
Where the definitions overlap and diverge
The strongest overlap is the machine-based system that produces outputs. The EU and NIST wording both list predictions, recommendations and decisions, and both refer to influence on virtual or physical environments. Both also state that systems operate with varying levels of autonomy. NIST's wording derives from the OECD's 2019 definition. The OECD updated its own definition in March 2024 to reference content generation more explicitly, while the NIST definition remains unchanged.
The EU text diverges by adding inference and adaptiveness. Recital 12 calls the capability to infer a key characteristic and says the definition rests on features that distinguish AI systems from simpler traditional software. It describes autonomy as some degree of independence of actions from human involvement, and adaptiveness as self-learning capability that allows a system to change while in use. It also says the definition should not cover systems based on rules defined solely by natural persons to automatically execute operations.
NYDFS diverges more sharply. Its wording does not mention autonomy, and it uses reasoning, learning and self-improvement where the EU uses inference. It defines no output type. Scope instead comes from use: underwriting, pricing, or identifying lifestyle indicators. In the final letter of July 11, 2024, DFS rejected comments urging narrower or alternative definitions and kept the original wording so that it covers systems whether or not they use external consumer data and information sources. The proposed version referred to medical, property or casualty underwriting or pricing, while the final version refers to health, life, property or casualty.
Colorado adds a third axis. Rather than turning on technical characteristics, its duties attach to systems classed as high-risk, and they differ for developers and deployers. That matters for insurers that deploy vendor-built models.
Applying the definitions to common insurance tools
The mappings below are textual readings of the definitions, not regulator commentary on specific tools.
Underwriting and pricing models are the clearest case. They fall within the NYDFS use scope by definition. For life and health risk assessment and pricing of natural persons, the EU high-risk list in the consolidated text also applies, as of October 2026. A model that infers risk scores from applicant data also fits the EU and NIST characteristics.
Claims triage and customer-service assistants are not named in the NYDFS wording. A triage model that infers priority from claim inputs fits the EU and NIST characteristics, but whether it falls inside NYDFS or Colorado scope is a scoping decision that should be made by counsel and documented.
Fraud detection needs care. The EU credit-scoring high-risk entry excludes systems used to detect financial fraud. That exclusion sits in one entry and should not be generalized to insurance fraud models or to other regimes.
Generative assistants produce content, which appears in the EU output list but not in the quoted NIST list. The OECD update toward explicit content generation suggests the gap is narrowing, but the basis for scoping an assistant in or out should be written down.
Fixed-rule scorecards are the sharpest divergence. The EU recital excludes systems based solely on rules defined by natural persons. The NYDFS wording contains no equivalent exclusion, so a scorecard used in underwriting or pricing may be treated differently under each regime.
Vendor-supplied models and scores are assessed on the same attributes. NYDFS applies its definition regardless of external data use, and Colorado separates developer from deployer duties, so a carrier cannot treat a third-party origin as taking a system out of scope.
Scoping an AI inventory across regimes
Scope the inventory against the broadest characteristic-based definition, the EU and NIST style, and then overlay the narrower use-based NYDFS test and the Colorado high-risk framing. Record which regimes apply to each system. The same attribute record can also be applied to the NAIC AI Model Bulletin and to state-level adoption of it. Each inventory record should capture:
- Autonomy level and degree of human involvement in the output
- Whether the system infers or learns from inputs, or only executes fixed human-defined rules
- Whether it adapts after deployment
- Output type: prediction, content, recommendation or decision
- Business function influenced: underwriting, pricing, claims, fraud or service, including whether it supplements or proxies underwriting or pricing, or identifies lifestyle indicators
- Intended purpose, affected population and whether the system is built in-house or supplied by a vendor
Governance and tradeoffs
A broad inventory definition produces more records to maintain, but it avoids the larger risk of different teams applying different tests to the same tool. The cost of breadth is lower than the cost of an inconsistent scoping record when a regulator asks why two similar models were treated differently.
For each in-scope or out-of-scope decision, record the rationale and the definition element relied on, such as inference, the rules-only recital, or the NYDFS use test. Assign an owner to monitor definitional change. The EU consolidated text was updated on July 27, 2026, with the definition wording unchanged, and Colorado's current status should be confirmed before obligations are mapped.
For vendor models, align due-diligence requests with the developer-to-deployer documentation duties described for Colorado high-risk systems, subject to the law as currently in force. Where model internals are not visible, the inventory should still record intended purpose, output type and the decision the output influences.
Runtime enforcement and evidence for in-scope systems
Definitions decide which systems are in scope. Showing how those systems behaved is a separate task. Trussed enforces policy in the execution path of models, agents and tools, applying allow, redact or block actions at the level of individual interactions and tool calls. Enforcement produces audit-ready evidence, mapped to NAIC, NYDFS, the EU AI Act and NIST, that records what the policy allowed and what happened. This supports demonstrating compliance for systems an insurer has already scoped in. It does not replace the scoping decisions described above.
Elements each regime turns on
Autonomy
Stated in the EU and NIST wording, absent from NYDFS.
Inference
Explicit in the EU definition and a key characteristic in its recital.
Adaptiveness
Addressed in the EU definition as possible change after deployment.
Outputs and influence
Predictions, recommendations, decisions and, in the EU text, content.
Use in insurance
Central to NYDFS scope and to EU high-risk categories.
Turn scoping decisions into evidence
Discuss how policy enforcement in the execution path and audit-ready evidence apply to the systems in your AI inventory.
Talk to an Expert