EU AI Act vs EIOPA AI Governance Opinion: What Insurers Must Evidence After the Digital Omnibus

Legal status and timing: what has changed

The EU AI Act (Regulation (EU) 2024/1689) is in force. Its governance rules and general-purpose AI obligations have applied since 2 August 2025. The high-risk rules were originally due to apply from 2 August 2026, but the Digital Omnibus on AI, which the Commission reports entered into force on 27 July 2026, supersedes that date. The Commission cites the delayed availability of standards as the reason.

As of November 2026, the dates are 2 December 2027 for stand-alone high-risk AI systems and 2 August 2028 for high-risk AI systems embedded in products. Any internal plan built on August 2026 should be re-baselined. The Act can also be amended by delegated and implementing acts, including reviews of the Annex III list of high-risk use cases, so the dates and scope should be tracked.

The Act also says the same regime should apply to insurance and re-insurance undertakings and to insurance intermediaries, alongside other financial institutions, for consistency and equal treatment across the financial sector. Whether a given use case is high-risk, whether life and health underwriting and pricing, claims or fraud detection, is a classification decision to confirm with legal counsel before the evidence work is scoped.

Requirement areas, artefacts and where the evidence comes from

The Act's high-risk requirements fall into six areas. The table sets out what the Act requires, the artefact an insurer should be able to produce, and whether runtime enforcement can contribute. Accountability is not a separate high-risk requirement area in the Act, so it is evidenced through named ownership of each area below.

• Risk management: Act: a risk management system established, implemented, documented and maintained, run as a continuous, iterative process across the lifecycle. Artefact: risk assessments, mitigation decisions, review records. Source: organisational process. Runtime enforcement does not substitute.
• Data governance: Act: training, validation and testing data sets subject to governance and management practices suited to the intended purpose. Artefact: data governance records and data set documentation. Source: development-stage processes. Runtime controls on individual interactions do not evidence this.
• Technical documentation and record-keeping: Act: documentation sufficient to assess compliance and support post-market monitoring, plus automatically generated logs. Artefact: technical file and retained logs. Source: mostly pre-deployment documentation; runtime can contribute interaction-level records.
• Transparency to deployers: Act: information provided to deployers so they can use the system appropriately. Artefact: instructions for use and capability and limitation statements. Source: provider documentation and internal communication.
• Human oversight: Act: systems designed, with appropriate human-machine interface tools, so people can effectively oversee them while in use. Artefact: oversight design records, reviewer roles, approval records. Source: system design plus runtime records of escalation and approval.
• Robustness, accuracy and cybersecurity: Act: requirements on robustness, accuracy and cybersecurity for high-risk systems. Artefact: test and validation results, security documentation. Source: pre-deployment testing and ongoing security processes.

Treating the Act and the EIOPA opinion as layers

The legal difference is the starting point. The Act creates enforceable obligations with defined application dates. EIOPA's opinion is supervisory guidance: principles-based expectations that shape how a supervisor will assess an insurer's AI governance and risk management. Compliance with one does not discharge the other, and the vocabulary differs, so the same control may be described in different terms by a regulator and by a supervisor.

The efficient design is to produce evidence once and map it twice. Build the register around the Act's requirement areas, because they are specific and each implies a concrete artefact. Then map each artefact to the supervisory expectation it supports, and record that mapping against the opinion's own text. Where the opinion is more general than the Act, the Act-derived artefact is typically enough to anchor a supervisory conversation. Where it covers governance topics the Act does not frame as a requirement area, such as accountability and board-level ownership, the evidence will come from organisational governance and not from system controls.

The failure mode to avoid is producing separate evidence sets for each instrument, or assembling evidence after the fact in response to a request. Both produce inconsistency. Evidence that is generated by how systems are actually controlled is easier to defend than evidence reconstructed from policy documents.

What runtime enforcement can and cannot evidence

A control layer in the execution path can only evidence what it observes: individual interactions and tool calls, the policy decision taken on each (allow, redact, block, escalate for human approval), and any human approval that follows. That is useful for record-keeping and for showing that oversight steps happened. It does not describe how a model was built, what data trained it, or how risk was assessed before deployment.

Trussed enforces policy in the execution path across models, agents, tools and MCP servers, with actions including allow, redact, block, rate limit and escalate for human approval. Enforcement generates audit-ready evidence, mapped to regimes including the EU AI Act, NAIC and NYDFS requirements. It can be deployed self-managed in the customer's cloud, with configurable retention and data residency. Its scope is individual interactions and tool calls. It does not provide model provenance, model lineage, dataset provenance or end-to-end tracing of agentic workflows.

Escalation supports the Act's human-oversight design requirement only if the approval step, the reviewer and the outcome are recorded. It complements oversight design at the system level and does not replace it. For providers that are financial institutions, the Act places automatically generated logs within the documentation kept under financial services law, so exportability into existing documentation matters as much as capture.