EU AI Act AI Underwriting Logs: What Insurers Should Be Ready to Produce After December 2027

What the EU AI Act explicitly requires

Regulation (EU) 2024/1689 states that high-risk AI systems shall technically allow for the automatic recording of events (logs) over the lifetime of the system. Providers must keep the automatically generated logs referred to in Article 12(1), to the extent the logs are under their control. The retention period must be appropriate to the intended purpose of the system and at least six months, unless Union or national law provides otherwise, in particular Union law on the protection of personal data.

Two points follow. The six-month figure is a floor for provider-held logs, not a target, and data protection law can push retention in either direction. Recital 71 also treats record-keeping and technical documentation as related but distinct records, tied to traceability, verification of compliance, monitoring of operations and post-market monitoring. The logging requirement is framed as a system capability, so insurers will need to decide and justify which events and fields they capture for underwriting.

On timing, the Commission states that high-risk rules apply from 2 December 2027, and rules for AI embedded in physical products from 2 August 2028. As of November 2026, the Digital Omnibus on AI, proposed on 19 November 2025, has reached provisional agreement between the Council and Parliament (7 May 2026). The high-risk dates remain subject to the legislative process, so plan around 2 December 2027 and keep a change log of developments. Whether each underwriting use case is classified as high-risk should be settled through legal review. Enforcement is shared between the Commission's AI Office, the European Data Protection Supervisor and national competent authorities designated by Member States.

Explicit requirement versus likely supervisory request

The table separates what the regulation states from what supervisors may reasonably ask for. The entries marked as inference are practitioner judgement, not regulatory requirements.

• Event records for each underwriting interaction: Explicit basis: automatic recording of events over the system lifetime. Content and fields are for the insurer to define and justify.
• Retention schedule and rationale: Explicit floor of six months for provider-held logs, subject to other law. A documented rationale per log category is an inference.
• Log security and access conditions: Where Delegated Regulation 2024/1774 applies to the insurer, logging policy covers events logged, retention and securing log data. Extending that approach to AI logs is an inference.
• Technical documentation: Recitals describe general characteristics, capabilities, limitations, algorithms, data, testing and validation, and risk management, kept up to date.
• Permitted versus actual behaviour: Inference: a supervisor reviewing one decision may ask what the system was allowed to do and what it did.
• Human oversight records: Inference: where a human approved or overrode an outcome, a record of who, when and on what basis.

Raw logging is not audit-ready evidence

Most carriers already hold application-level logs and model documentation. The difficulty is that these are rarely organised around the question a supervisor asks: what happened in this specific underwriting interaction, and was it within policy? Answering that from scattered logs means manual assembly after the fact, with inconsistent results.

A useful test is to pick one past underwriting interaction and reconstruct it. You should be able to show the input and output records, the policy that applied, the action taken, any human approval, and the retention status of each record. You should also be able to say who retrieves it and how long that takes.

Control matters too. The provider duty covers logs under the provider's control, so an insurer using a third-party system should establish which logs the provider holds, which the insurer holds, and how the insurer obtains the former on request. Retention should then be set by log category, using the six-month floor and any data protection or sector rules as constraints, with the reasoning written down. Where personal data sits in underwriting logs, shorter retention or minimised content may be appropriate, and residency decisions belong in the same record.

How runtime policy enforcement supports the evidence

Trussed enforces policy in the execution path across models, agents, tools and MCP servers. Each interaction or tool call is allowed, redacted, blocked, rate limited or escalated for human approval, and that enforcement is enforced at runtime, not reviewed after the fact. The enforcement itself generates audit-ready evidence at the level of individual interactions and tool calls, mapped to frameworks including the EU AI Act.

This addresses a specific gap: pairing the policy in force with the outcome for each interaction. An application log shows what happened. An enforcement record also shows which rule applied and what the system did about it, including when a human approval was requested. That supports the permitted-versus-actual question a supervisor may ask about a given decision.

The mapping to AI Act record-keeping and oversight expectations is analytical. The regulation does not prescribe runtime enforcement records, and they do not by themselves satisfy Article 12. Trussed deploys self-managed in the customer's cloud, with configurable retention and data residency, so insurers can align evidence storage with their own retention rationale and location requirements.

What stays outside the enforcement layer

Evidence from enforcement at the interaction and tool-call level is one component of a regulator-ready record set. Several categories must be produced and owned elsewhere.

Technical documentation, including system characteristics, testing and validation, and the risk-management system documentation, remains a provider and insurer responsibility. Model lineage and dataset provenance are not produced by enforcement records, and neither is end-to-end tracing of multi-step agentic workflows. Human oversight procedures, reviewer training and the governance around reviewer decisions also need their own records. The same applies to data protection assessments and the classification decision for each use case.

Assign an owner to each of these categories. A supervisory request will rarely be limited to one record type, and the insurer must be able to assemble the full set consistently.