18-Month EU AI Act Readiness Plan for Insurers

The dates the plan is built on

Regulation (EU) 2024/1689 was amended by the AI Omnibus, which entered into force on 27 July 2026. The Commission states that delayed availability of standards put the original 2 August 2026 date for high-risk systems in jeopardy, so the application date moved to 2 December 2027. AI embedded in products moves to 2 August 2028. Any plan keyed to 2 August 2026 is superseded.

A second date belongs in the plan. Article 5(1) first subparagraph points (ba) and (bb), and Article 5(1a) and (1b), apply from 2 December 2026. Prohibitions and general-purpose AI obligations are already applicable. The screening step in Phase 1 should therefore cover prohibited practices as well as high-risk classification.

Standards remain a stated dependency, and the dates have already changed once. Assign a named owner to track official changes and re-baseline the plan when they occur. The 18-month window ends at the high-risk date, which means the plan should aim for evidence that already exists on 2 December 2027, not evidence assembled afterwards.

Phased milestones from July 2026 to December 2027

The phases below are sequenced by dependency. Inventory has to precede classification, classification has to precede control mapping, and controls have to run for some time before there is evidence worth reviewing. Where early phases are already underway, compress them rather than skip them.

• Phase 1, July to December 2026: inventory, classify, assign: List every AI use in risk assessment and pricing, underwriting support, claims handling and customer interaction, including AI embedded in vendor tools. Classify each use against Annex III and the Commission's high-risk classification guidelines and examples. Record whether the insurer is provider or deployer for each system. Screen for prohibited practices ahead of 2 December 2026. Name an accountable owner per system.
• Phase 2, January to March 2027: map obligations to controls: For each high-risk system, list the applicable obligations: risk management, human oversight, monitoring and record-keeping, transparency and instructions for use. Assign each to a control, an owner and an evidence type. Mark which controls can be enforced in the AI execution path and which are process or document controls.
• Phase 3, April to June 2027: close vendor and oversight gaps: Review vendor and third-party AI contracts for instructions for use, monitoring data and records. Allocate evidence responsibilities between provider and deployer. Appoint human oversight roles and document their competence, AI literacy, training and authority.
• Phase 4, July to September 2027: enforce and collect: Put runtime controls into production for in-scope systems and begin generating evidence from live operation. Schedule the first risk management review. Feed monitoring findings into the documentation the provider or insurer maintains.
• Phase 5, October to November 2027: rehearse the audit: Pick a system and an obligation, then reproduce the evidence an auditor or supervisor would ask for. Fix gaps in coverage, ownership or retention. Confirm training records and oversight rosters are current.
• Phase 6, December 2027: baseline and operate: Confirm readiness status for 2 December 2027, record open items with owners, and move to a standing review cycle. Risk management is continuous, so the plan converts into an operating calendar and does not end.

Which obligations can be enforced at runtime

Risk management, human oversight and post-market monitoring are lifecycle obligations. A risk management system must be established, implemented, documented and maintained as a continuous, iterative process with regular systematic review. High-risk systems must be designed so that natural persons can effectively oversee them while in use, including through appropriate human-machine interface tools. Both point toward evidence that comes from live operation, not from a one-off document.

Mapping these obligations to runtime controls is a design judgement, not a statement in the regulation. In practice, the useful question is what each AI interaction or tool call is allowed to do. A control in the execution path can allow a request, redact personal data, block an action, rate limit usage, or escalate for human approval. Escalation to a person is the most direct way to produce evidence that oversight happened on a specific action, such as a model attempting to change a claims decision or call a tool outside its permitted scope.

Some obligations will not be met this way. Post-market monitoring is a provider duty and its plan forms part of the Annex IV technical documentation. Instructions for use, competence of oversight staff and governance of vendor contracts are process controls. A sound control map labels each obligation honestly as runtime, process or document, so that nobody counts a policy document as an enforced control.

Working alongside NAIC, NYDFS and Colorado requirements

Insurers operating across jurisdictions also face the NAIC AI Model Bulletin, NYDFS Circular Letter 7 and Colorado SB 24-205. These regimes have their own scope and requirements, and equivalence with the EU AI Act should not be assumed. Counsel should map each against its primary text.

The practical overlap is in the operating model. An AI inventory, named owners, oversight roles, vendor contract review and a retained evidence base are useful under any of these regimes. Build them once, tag each record to the regimes it supports, and add jurisdiction-specific items where they differ. This avoids maintaining parallel inventories and parallel evidence stores that drift apart.

Ownership is the main dependency. Compliance typically owns the obligation map and evidence definitions. Technology owns control implementation. Business line owners own the use case and the oversight role. Procurement and legal own vendor terms. Record these owners in the Phase 2 map, and review them whenever a system or a date changes.

Where Trussed fits in the plan

Trussed is relevant to Phases 3 and 4, where policy has to become behaviour in production. Trussed enforces policy in the execution path across models, agents, tools and MCP servers: allow, redact, block, rate limit, and escalate for human approval. Enforcement applies to individual interactions and tool calls, and is enforced at runtime, not reviewed after the fact.

That enforcement produces continuous, audit-ready evidence, mapped to the EU AI Act alongside NAIC, NYDFS, HIPAA and NIST. It supports the evidence rows for operational control and human oversight described above. It does not replace the inventory, classification, risk management review, vendor contracts or training records, which remain with the insurer.

Trussed can be deployed self-managed in the customer cloud, with configurable retention and data residency, which matters when evidence must stay in a defined location and for a defined period. Trussed has run continuously in a regulated enterprise for more than 18 months, supports 100+ models under one policy plane and generates 30+ GB of audit evidence per day. Insurance is among its four regulated verticals.