How the EU AI Act's August 2, 2026 high-risk deadline for life and health insurance underwriting changes Article 86 explanation requests — and the six-month Article 26 log retention rule insurers must meet for automated pricing decisions

This guide explains how the EU AI Act’s August 2, 2026 deadline reshapes Article 86 explanation requests for life and health insurance underwriting. It also sets out the six-month Article 26 log retention rule for automated pricing decisions.

Map the deadline to the workflow

Regulation (EU) 2024/1689 places an AI system used to assess risk or price natural persons for life or health insurance in the high-risk category under Annex III, point 5(b). The relevant high-risk requirements apply from 2 August 2026 under the Act’s transition rules. The practical deadline is therefore not the date a model is purchased or trained; it is the date on which the insurer uses the system for an in-scope underwriting or pricing decision.

When an insurer uses the system in underwriting, it is generally the deployer. Article 26 consequently requires logs automatically generated by the high-risk system under the insurer’s control to be retained for at least six months, subject to applicable statutory requirements and any longer retention duty. Before 2 August 2026, assign ownership for the log stream, confirm that the system actually generates it automatically, and set a retention rule that cannot delete a decision record before the six-month minimum.

Map the requirement to each decision event: application intake, risk assessment, premium or coverage recommendation, human review, and adverse outcome. At every event, record a stable decision identifier that connects the person’s application, the system version, the inputs used, the output produced, and the final underwriting action. A useful release check is simple: select one materially adverse outcome in testing and verify that an authorized reviewer can retrieve the complete linked record without reconstructing it from separate, unconnected systems.

Article 86 supplies the person-facing step. Where a decision based on the output of a high-risk AI system produces a legally significant effect and adversely affects the person, the deployer must be prepared to provide a clear and meaningful explanation of the system’s role and the main elements of the decision. The explanation process should therefore be triggered from the same decision identifier as the retained log, rather than from a later manual search for the applicant’s file.

Use 2 August 2026 as the go-live acceptance gate: an in-scope life or health pricing decision must generate a controlled log, remain retrievable for at least six months, and route an adverse outcome to an explanation-ready record. Test both paths before that date—an ordinary underwriting decision and a materially adverse one—and require the result to show the system used, the relevant decision inputs, the output, the action taken, and the channel for delivering the Article 86 explanation.

Build the evidence chain

Make the evidence chain begin with the individual decision, not with a generic description of the model. For every materially adverse life or health pricing or underwriting outcome, retain the relevant Article 26 decision log for at least six months and link it to the case record. The chain should identify the system and version used, the decision timestamp, the inputs actually received, any preprocessing or eligibility steps, the output, and any human adjustment or override. If a reviewer cannot move from the customer’s outcome back to the exact input-to-output record, the decision is not explanation-ready.

The modernvoice.ai telematics guidance offers a useful starting point for customer-facing language: explain underwriting as the carrier’s method for translating observed risk into coverage and price. Use that plain-language metaphor only as an introduction. Replace it immediately with the variables used in the individual case, such as the relevant health, medical, behavioral, or other permitted data fields, and describe whether each variable affected eligibility, price, terms, or a referral for human review. “The system assessed your risk” is not meaningful if the person cannot learn what information drove the assessment.

The techsurance.in medical-underwriting overview usefully names medical history, prescription history, age, lifestyle, and similar factors as common underwriting inputs. Treat that list as an explanation prompt, not as a compliance shortcut. It is not evidence that an EU insurer may lawfully use any particular factor, obtain it in a particular way, or apply it to a particular person. For each field, preserve the source, collection context, permitted-use check, transformation, and relationship to the output. If the field was not used in the case, do not present it as a reason.

The key evidentiary distinction is between a practical underwriting explanation and regulatory proof: a clear explanation helps the affected person understand the outcome, while regulatory proof requires retained records that demonstrate what the system actually received, did, and produced. Test both separately. Ask a customer-facing reviewer to explain the outcome in plain English, then ask an independent reviewer to reproduce the evidence chain from the retained log without relying on the model’s current behavior.

Apply a final release check before communicating an adverse result: confirm that the explanation names the case-specific factors, distinguishes facts from inferences, identifies any human intervention, and matches the retained output. Preserve the explanation alongside the log and record any correction or follow-up. This prevents a later, generic explanation from being mistaken for evidence of the decision that was actually made.

Compare implementation choices

Choose the operating model by testing whether a reviewer can move from an individual adverse underwriting or pricing result back through the exact data and processing that produced it. The useful pass/fail question is: can the insurer retrieve one case, identify the applicable model version and decision inputs, and explain the result without relying on a generic model description?

The narrative-only model fails the individual-case test. A model card can describe intended features, general performance, and permitted use, but it does not show which input values were used for a particular applicant or which threshold affected that person’s result. Set a control that rejects any explanation workflow whose source record is only a model card or other general documentation.

The snapshot archive is workable only where its limits are explicit. It should preserve the submitted inputs, final price or underwriting outcome, timestamp, case identifier, and model version. Before selecting it, run a reconstruction test on adverse cases: if the reviewer cannot identify material transformations, missing-value treatment, derived variables, and decision thresholds, the snapshot is not sufficient for that use.

The evidence-first ledger should be the default design. Require one immutable case ID to connect the request, normalized and derived inputs, each material transformation, model and rule versions, thresholds or cutoffs, output, reason codes, and access history. Retain the relevant Article 26 decision logs for at least six months, and verify through scheduled retrieval tests that the complete record remains readable and linked.

Accordingly, reject narrative-only storage, approve snapshot archives only after a documented reconstruction test passes, and select the evidence-first ledger when the insurer controls or materially adverse outcome must be explanation-ready at the point of use. That choice gives the Article 86 response process a case record to work from rather than an after-the-fact narrative to invent.

Budget the six-month evidence duty

Budget the six-month evidence duty as a capacity-and-operations problem, not as a single storage line item. The variables that determine cost are the number of decisions retained, the average compressed record size, the retention window, the number of replicas or immutable copies, indexing and encryption overhead, backup policy, access-log volume, key-management requirements, retrieval testing, and vendor charges. Put each variable in the budget and assign an owner before production use.

Use a simple first-pass estimate: monthly storage = decisions per month × average compressed record size. At 250,000 decisions and 12 KB per compressed record, the calculation is 250,000 × 12 KB = 3,000,000 KB, or about 3 GB of raw records per month. Validate both inputs from production measurements: count the retained decision population, and sample compressed records after including the fields required for the decision log rather than relying on an uncompressed database estimate.

A six-month hot-or-retrievable window at that baseline is approximately 3 GB × 6 = 18 GB of raw records. Treat 18 GB as the starting capacity figure, not the compliance budget. Create separate lines for replicas, immutable copies, indexes, encryption overhead, and backups; otherwise, a storage dashboard may appear within capacity while the actual retained footprint is materially larger.

Apply a second checklist to operating costs. Confirm where access logs are stored, how encryption keys are generated, rotated, and recovered, how long key-management records remain available, and whether the selected vendor charges for ingestion, storage, retrieval, or outbound data transfer. Require a documented retrieval test for a sampled decision, including the time to locate the record and reconstruct the stored output, and budget the test environment and personnel time rather than assuming retrieval is free.

Set a monthly review rule: recalculate capacity using the latest decision count and compressed-record average, then compare the result with the six-month requirement and every copy or backup policy. Escalate when either input changes, when indexes or access logs grow faster than the records, or when retrieval testing exposes missing fields or unacceptable delay. This keeps the Article 26 retention budget tied to the records actually needed at the point of use.

Separate proof from legal conclusions

A decision log is a record of processing, not a certificate of lawfulness. It can show what the system received, which model version ran, and what score or rating it returned. It cannot, by itself, establish that the underlying data were accurate, lawfully obtained, free of discriminatory effect, or actuarially appropriate for the product being underwritten. That gap is where much of the compliance risk sits.

Consider what a typical entry contains: an application identifier, the input fields the model consumed, a version number, a timestamp, and an output. That chain is internal to the system. It says nothing about whether the medical or prescription history loaded into the model matched the source record, whether the applicant's consent covered that specific data flow, or whether a proxy variable is quietly tracking a protected characteristic.

Close the gap with two companion controls. First, provenance: for every field feeding the model, record the source system, the lawful basis for processing, the refresh cadence, and the accountable owner. Second, fairness: test outcomes by cohort on a fixed schedule, keep the results, and document any remediation. An entry reading "age band 45-54" proves the band was applied, not that the banding is justified for that life or health product.

Article 86 does not push that in the direction vendors often fear. The right to explanation does not convert a proprietary model into a source-code delivery obligation, and it does not require disclosure of every mathematical coefficient or the training corpus. What it requires is a clear, meaningful account of the system's role in the decision and the main elements that drove it.

So apply a readability test before the explanation template goes live. If a rated-up or declined applicant can identify the role the AI played, the main factors that moved the outcome, and the route to contest it, the explanation does its job. If it only makes sense alongside the code, it fails. If it reproduces the code, it over-delivers and exposes protected trade secrets.

Treat retained logs as the spine, not the entire skeleton. Provenance records, fairness test results, and a plain-language explanation template are separate evidentiary limbs. Losing any one of them leaves a file that documents processing but cannot answer a supervisor's question about whether the underwriting was lawful and fair.

Trace a premium decision end to end

On 10 August 2026, an insurer’s high-risk health-pricing system receives five input categories: the applicant’s age of 47, declared tobacco use, medication history, prior-claims indicators, and product selection. It records how any missing value was treated, applies model version H-4.2, and returns a risk score of 0.68. Because that score exceeds the system’s 0.60 surcharge threshold by 0.08, the case receives a 20% premium loading. The operational check is simple: the ledger must show both the threshold comparison and the resulting pricing action, not merely the final premium.

The decision ledger identifies the case as EU-H-10482 and timestamps the outcome. It preserves the five input categories and their values, the missing-value treatment, model version H-4.2, the 0.60 threshold, the 0.68 score, the 20% loading, and the underwriter’s confirmation. Together, those records permit the insurer to reconstruct the path from the submitted information to the adverse pricing outcome. A useful test is whether a reviewer could answer what data entered the system, what the model did with it, and who authorized the resulting decision without relying on memory or an unrecorded spreadsheet.

The Article 26 retention clock starts from the timestamp of this decision. Accordingly, the insurer must preserve the relevant decision log for at least six months, through 10 February 2027. If the case remains under review, the insurer should not treat the routine retention limit as permission to destroy material. The workflow control should flag the record before deletion, identify the person responsible for extending retention, and document any hold. The ledger should also distinguish an unchanged input from a corrected one so the insurer can show which evidence supported the decision actually made.

The same case demonstrates how the ledger supports an Article 86 response about the individual decision. If the person asks for an explanation, the insurer should identify AI’s role in producing the risk score, describe the main factors derived from the five input categories, and explain the result in concrete terms: H-4.2 produced 0.68, the applicable surcharge threshold was 0.60, and the system therefore triggered the 20% loading. It should also identify the underwriter’s confirmation without suggesting that human involvement erased or replaced the system’s contribution.

The final quality check is to read the response without access to the technical documentation. The explanation should let the affected person understand the decision’s practical effect and the principal reasons for it. A generic statement that the model considered health information is insufficient. By contrast, an explanation that connects age, declared tobacco use, medication history, prior-claims indicators, product selection, model version H-4.2, the score, the threshold, and the loading gives each retained record a purpose—and gives the insurer a traceable answer grounded in the ledger.

Apply four operational decision rules

This section converts the guide into four if/then controls for insurers. Each control should be assigned to an operational owner, embedded in the relevant workflow, and tested before the insurer begins using the system for EU life or health underwriting decisions.

First, if an AI output can change eligibility, coverage terms, or the price of EU life or health insurance, classify the workflow for Annex III review and make its case-level record explanation-ready before 2 August 2026. The operational check is simple: can any model recommendation alter the offer, conditions, premium, or decision to proceed? If yes, place that workflow on the high-risk register. Connect the review to the system’s duties under Articles 26 and 86, and identify who will answer a person’s question about the resulting decision. Do not wait for a complaint to determine whether the explanation process exists.

Second, if the insurer controls the underwriting deployment, automatically retain the generated decision logs for at least six months. Configure retention by default rather than leaving it to a case handler. Before releasing a model into production, test that each case-level log contains the model version, material inputs, output, threshold applied, and any human action, including approval, modification, or rejection. A missing human-action field is a control failure: silence cannot reliably show whether a person overrode, accepted, or merely reviewed the AI recommendation.

Third, if a customer asks why an AI-influenced outcome occurred, route the request into a defined explanation workflow. The handler should retrieve the relevant case record, identify the factors that materially affected the result, distinguish model-generated reasoning from human adjustments, and provide a clear account of the decision. A generic description of the model is not enough. The workflow should also record what information was unavailable, what explanation could not be reconstructed, and who resolved the follow-up.

Fourth, if a materially adverse outcome cannot be traced to retained inputs, model output, and the applicable decision rule, do not treat the case as explanation-ready. Flag the record for human review before the adverse decision is communicated, document the corrective action, and preserve the revised or confirmed case history. This final check catches broken evidence at the point of use, where it can still be repaired rather than becoming an unsupported decision months later.

What to do next

Frequently Asked Questions

When does the Article 86 explanation deadline for affected life and health insurance underwriting decisions begin?

The deadline arrives on August 2, 2026.

Which automated life and health insurance underwriting decisions may affected persons ask to have explained?

Affected persons may seek a clear, meaningful explanation of automated decisions that produce materially adverse outcomes.

Must insurers wait for a dispute before creating an explanation path for automated life or health pricing?

No; insurers must treat each automated pricing decision as requiring an explanation path when it is made.

How long must insurers retain Article 26 logs relevant to automated life and health insurance pricing and underwriting decisions?

The logs must be retained for no less than six months.

What records must be preserved to connect a materially adverse underwriting outcome with its explanation?

Insurers must preserve the input-to-output record so the outcome can be linked to the relevant decision logs and a meaningful explanation.

Why are life and health insurance risk assessment and pricing systems covered by the August 2, 2026 requirements?

Regulation (EU) 2024/1689 places an AI system used to assess risk or price natural persons for life or health insurance in the high-risk category under Annex III, point 5(b), and the relevant high-risk requirements apply from 2 August 2026 under the Act’s transition rules.

Quick answers

Also worth reading: Product liability insurance: What it covers and who needs it: Product liability insurance: What it · How to protect your company assets with the right hazard insurance for business: How to protect your company · How long do you actually need SR22 insurance: How long do you actually