How Insurers Can Apply ISO/IEC 23894 to Underwriting and Claims AI

What ISO/IEC 23894 provides, and what it leaves to the insurer

ISO/IEC 23894:2023 is titled "Information technology — Artificial intelligence — Guidance on risk management" and is published under ISO/IEC JTC 1/SC 42. Its abstract describes processes for the effective implementation and integration of AI risk management. It is guidance. This page does not treat it as something to certify against, and it contains nothing specific to insurance.

That gap is where risk teams spend their effort. The standard gives a structure. The insurer still has to decide which underwriting and claims use cases are in scope, which risks matter for each, who owns each treatment, and what proof shows the treatment works in production.

Regulatory expectations sit alongside it. The NAIC Model Bulletin on the Use of AI by Insurers, approved by NAIC members in June 2024, is a guiding document rather than a model law or regulation, intended to foster uniformity among state regulators. Adoption should be confirmed state by state. NYDFS Insurance Circular Letter No. 7 (11 July 2024) addresses AI in underwriting and says insurers should have standards for model development, implementation, use and validation, and should promote independent review and effective challenge. Colorado SB 24-205 should also be assessed with counsel for applicability. A documented ISO/IEC 23894-style process gives these regimes a common set of outputs to draw on. Which regimes apply to which business is a legal determination, not something the standard settles.

Underwriting scenario: eligibility and pricing support

Consider an AI system that helps underwriters assess eligibility and recommend pricing. Context-setting should record whether the output is advisory or can trigger a decline, a referral or a price change without review.

The main risks are unfair discrimination, weak explainability for adverse outcomes, data quality problems in applicant and third-party data, reliance on an external model or data provider, and automated adverse decisions. Circular Letter 7 is directly relevant here because it is written for underwriting.

Treatments and owners will differ by risk. Bias testing and model validation belong to model risk or actuarial teams, with independent challenge from a second line. Vendor due diligence belongs to procurement and third-party risk. Data quality checks belong to data owners. These are insurer activities, and runtime enforcement does not replace them.

Some treatments do apply to individual interactions. Personal or sensitive applicant data can be redacted before it reaches a model that does not need it. Tool calls that would write a decline or a price change to a downstream system can be blocked, or escalated for human approval. Use is limited to approved models and tools. The business owner of the underwriting process should own these rules, and the control function should own their review.

Claims scenario: triage, fraud detection and settlement support

Now consider claims AI that triages incoming claims, flags possible fraud and drafts coverage or settlement recommendations. The context is different: claimants are often under stress, the data includes free text, medical and photographic material, and an error can delay or deny payment.

Risk identification should cover data quality in unstructured inputs, explainability when a claim is flagged or a recommendation is made, reliance on third-party models, unfair treatment of groups of claimants, and automated adverse decisions such as denial or a reduced settlement. Claims-specific regulatory expectations should be confirmed with counsel for each jurisdiction and not assumed from underwriting guidance.

The owners are typically the claims operations lead for use rules, the special investigations lead for fraud flag handling, and model risk for validation. At runtime, a fraud flag can be required to route to a human before a referral action runs. A denial or settlement tool call can be blocked unless an adjuster approves it. Claimant personal data can be redacted before it is sent to an external model. Whether a fraud model is statistically fair across claimant groups is a validation question answered before and between deployments, not in the execution path.

Which treatments can be enforced at runtime

The distinction matters for audit. A treatment that is only documented cannot be shown to operate. A treatment enforced at runtime can be shown per interaction. Many treatments need both.

• Minimize data sent to a model: Runtime: redact selected fields from an interaction. Outside runtime: decide which data is permissible and why.
• Human oversight of adverse decisions: Runtime: escalate a decline, denial or settlement tool call for human approval. Outside runtime: define authority levels, train reviewers, staff the queue.
• Restrict approved models and tools: Runtime: allow or block by policy. Outside runtime: approve vendors, perform third-party due diligence.
• Bias and fairness testing: Runtime: not addressed. Outside runtime: validation, testing and independent review by the insurer.
• Explainability documentation: Runtime: evidence of what was permitted and done. Outside runtime: the model rationale and consumer-facing explanations.
• Framework effectiveness review: Runtime: supplies retrievable evidence. Outside runtime: internal audit assesses the framework as a whole.

Where runtime policy enforcement and audit-ready evidence fit

Trussed enforces policy in the execution path across models, agents, tools and MCP servers. For each interaction or tool call, policy can allow, redact, block, rate limit or escalate for human approval. These controls are enforced at runtime, not reviewed after the fact. The scope is individual interactions and tool calls. Trussed does not provide model provenance or lineage, and it does not govern whole business transactions across tasks and agents.

Enforcement generates audit-ready evidence continuously: which policy applied, what action was taken and, for escalations, that a human approval step occurred. Evidence is mapped to NAIC, NYDFS and NIST requirements, so internal audit can retrieve it when assessing whether treatments operated. Deployment is self-managed in the customer cloud, with configurable retention and data residency. Trussed has run in continuous production in a regulated enterprise for more than 18 months and serves customers in insurance.

The practical next step is to take one use case, complete context and risk identification, and mark each treatment as runtime, outside runtime, or both. Then confirm with internal audit which evidence they would expect for each runtime treatment before the policy is written.