Are Insurance Companies Ready for the AI Vendor Compliance Audit? in Europe

Direct answer: No, most European insurance companies are not fully ready for an AI vendor compliance audit under the EU AI Act, because they have never inventoried which of their software vendors actually embed AI components, at what risk tier, or with what documentation. The fix is not a legal memo — it is a concrete audit of the vendor stack, followed by re-architecting or replacing the pieces that cannot produce compliance evidence on demand.

Through 2026, EU AI Act compliance commentary has been consistent on one point: European businesses of every size are now being asked to audit their AI vendor stack for AI Act exposure for the first time, and many are discovering they cannot answer basic questions about what their vendors' tools actually do. This is not a hypothetical exercise confined to large multinational carriers. It applies to a regional insurer running a claims triage tool from a third-party SaaS provider, a broker network using an AI-assisted underwriting plugin, and an insurtech running a chatbot built on a vendor's foundation model API. The common thread is that insurance, as an industry, has spent the last several years bolting AI features onto legacy policy administration and claims systems through vendors, integrations, and point solutions — and almost none of that vendor relationship management was built with audit-readiness in mind. Now the audit requirement has arrived, and the paperwork trail that regulators expect does not exist in most of these stacks. This post is written for insurance companies operating in Europe who need to understand what this actually means for their technology, not just their legal department, and what changes in how software gets built, bought, and maintained from here.

What the AI Vendor Compliance Audit Actually Requires

The AI Act's core mechanism is risk classification. Systems are sorted into unacceptable, high, limited, and minimal risk categories, and the obligations scale with the tier. Insurance sits in an unusually exposed position because several of its core functions — risk assessment and pricing for life and health insurance, and certain claims-handling processes — fall squarely into categories the regulation treats as high-risk when AI is involved in the decision. That single fact reshapes the audit conversation for insurers specifically, compared to, say, a retailer using AI for product recommendations.

A vendor audit under this framework is not a checkbox exercise. It typically requires an insurer to be able to answer, for every AI-touching vendor and every AI-touching internal system:

• What is the specific function of the AI component, and does it influence pricing, underwriting, or claims outcomes for an individual customer?
• What data was the model trained or fine-tuned on, and can the vendor produce documentation about that data's provenance?
• Is there a human review step before an AI-influenced decision reaches the customer, and is that step meaningfully substantive rather than a rubber stamp?
• Can the system's decisions be explained after the fact, in a way a regulator or an ombudsman would accept?
• Who is contractually and legally responsible if the vendor's model produces a discriminatory or erroneous outcome — the vendor, the insurer, or both?

Why Insurers Are Finding Gaps They Didn't Expect

Most insurance technology stacks are decades deep in layered legacy. A policy administration system from one era sits underneath a claims platform from another, with newer AI-enabled modules — fraud detection scoring, automated claims triage, chat-based customer service — added on top through vendor contracts signed by procurement or operations teams who were evaluating features and price, not compliance posture. Vendor contracts frequently do not specify what data was used to train the models, do not guarantee audit rights, and do not commit to supplying documentation in the format European regulators expect. This is the exact gap the compliance commentary points to: it is not that insurers deliberately avoided compliance, it is that AI adoption outpaced governance, and the audit is the first moment that mismatch becomes visible and consequential.

It also does not help that many of these vendor tools were purchased in stages, by different teams, over several years. A claims department might have brought in a triage tool through one procurement cycle, while underwriting separately adopted a risk-scoring plugin, and marketing added a chat assistant to the customer portal through yet another vendor relationship entirely. None of these purchases were coordinated, and none of them were evaluated against a shared compliance standard because no such standard existed at purchase time. The result, when an insurer finally sits down to build a single inventory, is often a longer and more fragmented list of AI touchpoints than anyone in the organization expected, spread across departments that have never had to compare notes on vendor governance before.

Why This Matters Specifically for Insurance Companies in Europe

Insurance carries two features that make this audit heavier than it is for most other sectors: regulatory density and the sensitivity of the decisions AI is making.

European insurers already operate under Solvency II, GDPR, and in many member states, additional national insurance conduct rules. The AI Act does not replace any of these — it adds a parallel compliance track that intersects with all of them. A pricing model that uses AI has to satisfy AI Act high-risk obligations and GDPR's rules on automated decision-making and profiling and Solvency II's requirements around model governance and actuarial soundness. An audit that only checks one of these regimes and ignores the others will not hold up. This is precisely why an ad hoc legal review is insufficient: the technical documentation needs to be built once and mapped to all three frameworks consistently.

The second factor is what is actually being decided. Underwriting and claims decisions affect whether someone can get coverage, what they pay for it, and whether their claim is honored. Regulators and courts across Europe have shown low tolerance for opaque automated decision-making in exactly this kind of consequential context. An insurer that cannot explain why an AI-assisted underwriting tool declined an applicant, or why a claims triage system flagged a claim for extended review, is exposed not just to an AI Act penalty but to conduct-risk complaints and reputational damage that compound the regulatory problem.

This is also where the intersection of regulatory regimes becomes more than a theoretical concern. A customer who feels they were unfairly declined coverage does not file a complaint under "the AI Act" specifically — they complain to a national ombudsman or regulator, who then looks at the full picture: was the decision explainable, was it fair, did the insurer follow its own stated processes. An insurer whose AI Act audit trail is solid tends to also have good answers for that broader conduct inquiry, because the same underlying discipline — knowing what the system did and why — serves both purposes. Insurers that treat the audit as a narrow legal exercise, separate from how they handle customer complaints day to day, are missing how closely these two concerns actually overlap in practice.

The Practical Business Risk, Not Just the Legal One

There is a commercial dimension too. Insurers that cannot produce clean vendor documentation during an audit face delays in product launches, restrictions on markets they can operate in, and in some cases forced suspension of specific AI-enabled features until compliance gaps are closed. For a mid-sized European insurer competing against larger carriers with dedicated compliance teams, an audit failure is a genuine competitive setback, not an abstract fine on a balance sheet.

What Changes in Practice for the Insurer's Software and Systems

Once an insurer takes this seriously, several concrete things change in how the technology stack is built and maintained.

First, vendor selection criteria change. "Can this vendor produce AI Act-compliant documentation on request" becomes a gating question in procurement, alongside price and feature set. Vendors that cannot answer clearly, or that treat their models as an unexaminable black box, become a liability regardless of how good their feature set is.

Second, system architecture starts to separate cleanly between the decision engine and the audit trail. An AI-assisted underwriting or claims system needs to log not just the final output but the inputs, the model version, the confidence score, and whether a human reviewed and could override the outcome. Many legacy and even some newer vendor tools were not built with this level of structured logging, because it was never a sales requirement until now. Retrofitting audit logging into a system that was not designed for it is materially harder — and more expensive — than building it in from the start.

Third, the human-in-the-loop requirement stops being a policy statement and becomes a workflow design problem. If an underwriter has to meaningfully review an AI-flagged application rather than click "approve" on autopilot, the interface has to be designed to support genuine review — showing the reasoning behind the AI's output, surfacing the data points that drove the score, and making it easy to override. This is a UI and UX problem as much as a compliance one, and it connects directly to broader interface design discipline: how a system presents empty states and error screens when a review queue is empty, when an AI score fails to compute, or when a reviewer needs to flag an anomaly all shape whether the human review step is real or theater. An insurer rebuilding this workflow should think about those failure and edge states as carefully as the happy path, because auditors will look at what happens when the system does not behave as expected, not just when it works.

Fourth, insurers with AI-driven customer-facing tools — chat-based quote generators, self-service claims portals — need those systems to be discoverable and explainable to customers across every market they serve, which for insurers operating regionally often means multiple local offices or branch pages. Getting the underlying content and page structure right so customers and regulators alike can find accurate, current information about how a product works ties back to fundamentals covered in SEO for multi-location businesses — a page for each regional office that accurately reflects local underwriting rules and AI usage disclosures is not just a marketing asset, it is part of the transparency obligation.

What Insurance Companies Should Actually Do About It

The starting point is an internal audit before the external one arrives. That means a full inventory: every vendor and every internal system that touches AI, mapped against what decision it influences and how consequential that decision is for a customer. From there, insurers typically fall into three buckets of response.

Some vendors can supply what is needed already — documentation, audit rights, explainability tooling — and the relationship continues with a formal compliance addendum to the contract. Some vendors cannot, and the insurer has to decide whether to push for contract renegotiation, accept the risk, or replace the tool. And for the systems that sit at the core of underwriting and claims — the highest-risk, most consequential category — many insurers are concluding that a vendor's generic, black-box tool is no longer an acceptable foundation, because they cannot compel a third party to open its model internals on the insurer's timeline or in the insurer's preferred documentation format.

This is where building rather than buying becomes the more defensible path for the highest-risk components. A system built through Custom Software Development gives an insurer direct control over exactly what data trains the model, how decisions are logged, what the human review interface looks like, and how documentation is generated and stored for audit purposes — none of which is guaranteed with an off-the-shelf vendor tool. It also means the insurer is not dependent on a vendor's roadmap to add compliance features the vendor may not prioritize. For lower-risk, more generic functions, a well-vetted vendor with strong contractual guarantees may remain the right call — the point is not to build everything in-house, it is to make a deliberate, documented decision for each system based on its actual risk tier.

Before going further, it's worth being direct: a precise industry-wide figure for how many European insurers have completed a full AI vendor audit is not publicly available, and any specific percentage claimed for this would be invented. What is clear from the compliance commentary is the pattern — audits are becoming mandatory in practice even where not every enforcement mechanism has fully activated, and insurers that wait until enforcement begins in earnest will be doing this work under far more pressure than those starting now.

There is also a sequencing question worth thinking through early: which system to tackle first is rarely obvious from a spreadsheet alone. The instinct is often to start with whatever system is easiest to fix, but the more defensible approach is to start with whatever system carries the most customer impact and the least existing documentation — usually the core underwriting or claims-decision engine — even if that means the first project is also the hardest one. Insurers that start with the easy wins and leave the highest-risk system for last are, in effect, choosing to carry their biggest exposure the longest.

What This Kind of Work Typically Costs

Insurers researching this tend to ask where AI vendor audit remediation and custom compliance-ready system work falls in terms of budget. It depends heavily on scope — a documentation and logging retrofit on an existing system is a different project than replacing a core underwriting engine — but the general shape looks like this:

Tier	Typical scope	Fits this kind of work when
Essential — $1,000	Vendor inventory support, audit-readiness documentation review, small logging or interface fixes	You need a focused audit gap-check or a single workflow updated with human-review logging
Growth — $2,000	Rebuilding a customer-facing or reviewer-facing workflow with proper audit trails, explainability UI, and documentation pipelines	You're replacing a mid-complexity tool (claims triage, quote assistant) with a compliant, custom-built version
Enterprise — $4,000+	Full custom underwriting or claims decision system with built-in compliance logging, human-in-the-loop design, and multi-market rollout	Your core high-risk decision system needs to be rebuilt or heavily re-architected across regions

These are starting reference points for scoping conversations, not fixed quotes — the right tier depends on how many systems are in scope and how deep the current documentation gap is. An insurer with a single AI-enabled customer portal and no core underwriting AI exposure will land at a very different tier than one running an AI-assisted risk-pricing engine across several product lines, and the honest scoping conversation up front saves both sides from a mismatched estimate later.

Key Takeaways

• European insurers are now expected to be able to audit their entire AI vendor stack for AI Act exposure, and most have not done this systematically yet.
• Insurance is unusually exposed because underwriting and claims decisions frequently qualify as high-risk under the regulation, layering AI Act obligations on top of existing GDPR and Solvency II requirements.
• The audit gap is mostly a documentation and architecture problem: missing training-data provenance, missing decision logging, and human-review steps that are not designed to be genuinely substantive.
• Vendor selection criteria need to explicitly include compliance documentation capability, not just features and price.
• For the highest-risk, most consequential systems, custom-built software gives insurers the control over data, logging, and explainability that generic vendor tools often cannot guarantee.
• Waiting until enforcement is active rather than starting the internal audit now puts insurers at a structural disadvantage compared to competitors who prepare early.

Getting ahead of this starts with an honest inventory of what your AI vendors can and cannot prove, and a clear-eyed decision about which systems need to be rebuilt rather than patched. If you want help figuring out where your stack stands and what to prioritize first, book a meeting with our team.

Frequently Asked Questions

What is the EU AI Act vendor compliance audit that insurers are being asked to do?

It is a systematic review of every software vendor and internal system an insurer uses that involves AI, checking whether each one meets the documentation, risk-classification, and human-oversight obligations set out in the EU AI Act. For insurers, this typically starts with underwriting, pricing, and claims-handling tools since those are most likely to be classified as high-risk.

Why are insurance companies specifically singled out in this trend?

Insurance functions like life and health underwriting and certain claims decisions are treated as high-risk under the AI Act because they materially affect a person's access to coverage and pricing. That risk tier carries the heaviest documentation, transparency, and human-oversight obligations, which is why insurers face a more demanding audit than businesses using AI for lower-stakes functions like marketing.

Does this apply to small and mid-sized insurers, or only large carriers?

It applies regardless of size. The compliance commentary is explicit that businesses of every size are being asked to audit their AI vendor stack, and a smaller insurer using a third-party AI-enabled claims tool has the same underlying exposure as a large multinational carrier, just with fewer internal compliance resources to handle it.

What counts as an "AI vendor" in this context?

Any third-party software provider whose product embeds an AI or machine-learning component that influences a decision, recommendation, or customer interaction — this includes claims triage tools, chatbot platforms, fraud detection scoring engines, automated underwriting assistants, and even some CRM or communication tools with AI-based features layered in.

How do we even find out which of our vendors use AI?

Start with a structured inventory: contact every software vendor in the stack and ask directly whether their product uses AI or machine learning in any customer-facing or decision-affecting capacity, and request documentation. Many insurers are surprised to find AI components in tools they did not think of as "AI vendors," such as document processing or communication platforms.

What happens if we can't get documentation from a vendor?

You have three practical options: push for a contractual compliance addendum that commits the vendor to supplying documentation and audit rights, accept the residual risk with eyes open and a mitigation plan, or replace the tool — often with a custom-built alternative where you control the documentation trail directly.

Is a vendor contract enough to transfer compliance responsibility to them?

Generally no. Regulatory obligations under the AI Act typically remain with the "deployer" of the system — in most cases, the insurer using the tool with its customers — even if the vendor built the underlying model. A contract can allocate liability between the two parties, but it does not remove the insurer's own compliance obligation.

What's the difference between a "high-risk" and "limited-risk" AI system under this framework?

High-risk systems are those that materially affect access to services, safety, or legal rights — underwriting and certain claims decisions for insurers fall here — and carry heavy documentation, oversight, and transparency obligations. Limited-risk systems, like a general customer-service chatbot that doesn't make binding decisions, carry lighter transparency requirements, such as disclosing that the user is interacting with AI.

Does our claims triage tool count as high-risk even if a human makes the final decision?

It can still be classified as high-risk if the AI's recommendation meaningfully influences the outcome, even with a human "in the loop," unless that human review is genuine and substantive rather than a formality. Auditors and regulators look closely at whether the human reviewer actually has the information and authority to override the AI's output.

What documentation does a high-risk AI system need to have ready?

Typically: a description of the system's purpose and function, information about training data provenance, risk assessment records, evidence of human oversight design, accuracy and performance metrics, and a record of how the system is monitored post-deployment for issues like bias or drift.

How does this interact with GDPR, which we already comply with?

GDPR governs personal data use and automated decision-making rights, including the right to an explanation for significant automated decisions. The AI Act adds system-level obligations on top of that — documentation, risk classification, oversight design — that apply even where GDPR's specific automated-decision article doesn't strictly trigger. Insurers need both frameworks satisfied simultaneously, not one substituted for the other.

Does Solvency II already cover this, since it has model governance rules?

Solvency II's model governance requirements focus on actuarial and financial soundness, not on AI-specific transparency and human-oversight obligations. There is overlap in spirit, but Solvency II compliance alone does not satisfy AI Act requirements, particularly around explainability and documented human review of AI-assisted decisions.

What's the realistic cost of retrofitting audit logging into an existing claims or underwriting system?

It depends on how the existing system was architected. A tool with reasonably modular logging can often be extended for a few thousand dollars in a focused Essential-tier engagement; a system with no structured logging or explainability layer at all may need a more substantial Growth or Enterprise-tier rebuild, since audit trails frequently cannot simply be bolted onto a system that never captured the underlying decision data.

How long does an AI vendor compliance audit typically take for a mid-sized insurer?

It varies with the number of vendors and systems in scope, but a realistic first-pass inventory and gap assessment across a mid-sized insurer's stack often takes several weeks to a few months, particularly when vendors are slow to respond to documentation requests. Remediation of identified gaps then runs as a separate, longer project.

Should we build our own underwriting AI instead of using a vendor's?

Not necessarily for every system, but for the highest-risk core functions, many insurers are finding that custom-built software gives them the control over training data, logging, and human-review workflow design that vendor black boxes cannot guarantee on the insurer's timeline. Lower-risk, more generic functions may still be well served by a vetted vendor with strong contractual guarantees.

What does "explainability" mean in practice for an underwriting model?

It means the system can produce, for any given decision, a clear account of which factors drove the outcome — for example, which risk indicators contributed most to a premium calculation — in language a regulator, an ombudsman, or the customer themselves could follow. A model that only outputs a score with no supporting reasoning does not meet this bar.

Are chatbots and AI customer service tools also in scope for this audit?

Yes, though typically at a lower risk tier than underwriting or claims tools, unless the chatbot is making binding decisions about coverage or claims outcomes. Even limited-risk AI customer-service tools generally need to disclose to users that they are interacting with an AI system.

What's the risk of doing nothing and waiting to see how enforcement plays out?

Insurers that wait typically end up doing the same remediation work later, but under active regulatory pressure, tighter timelines, and potentially after a specific complaint or incident has already drawn scrutiny. Early preparation is generally far less disruptive and less costly than reactive remediation.

Can a single vendor audit failure block a product launch?

It can, particularly for a new AI-enabled underwriting or claims feature going to market in an EU jurisdiction where regulators or internal legal teams flag the compliance gap before launch. This is one of the more concrete commercial risks driving insurers to prioritize this now rather than treating it as a background compliance task.

Who inside an insurance company should own this audit — legal, IT, or compliance?

It genuinely needs all three working together: legal and compliance define what documentation is required and interpret risk classification, while IT and engineering are the only people who can actually verify what the vendor's system does technically and where the data flows. An audit run by legal alone, without technical verification, tends to miss the gaps that matter most.

How do we handle vendors based outside the EU who supply AI tools to our European operations?

The AI Act generally applies based on where the AI system is placed on the market or used, not where the vendor is headquartered, so a non-EU vendor supplying tools used by your European operations is still in scope for the audit. Contractual clauses requiring the vendor to meet EU documentation standards become especially important in this scenario.

What's a practical first step if we haven't started this audit at all?

Begin with a complete vendor and system inventory — list every software tool touching underwriting, pricing, claims, or customer interaction, and flag which ones you believe involve AI. That single list, even incomplete, gives you a concrete starting point for prioritizing which systems to investigate and remediate first.

Does this affect how we design internal review dashboards for underwriters?

Yes — if underwriters are meant to meaningfully review AI-assisted decisions, the dashboard needs to surface the AI's reasoning, confidence level, and key contributing factors clearly, not just a final score. Poorly designed review interfaces, including how they handle empty queues or missing-data states, undermine the credibility of the human oversight the regulation requires.

How does multi-country operation complicate this for European insurers?

Insurers operating across multiple EU member states need to account for how national insurance regulators interpret and enforce AI Act obligations alongside local conduct rules, which can create inconsistent expectations across markets. Keeping accurate, current information for each regional office or branch — including how AI is used in that market — also becomes a transparency and findability requirement, not just a compliance formality.

What should be in our contract with an AI vendor going forward?

At minimum: a commitment to supply documentation on training data and model behavior, audit rights allowing you to request evidence of compliance, clear liability allocation if the model produces a discriminatory or erroneous outcome, and a notification obligation if the vendor materially changes the underlying model.

What's the difference between an internal audit and a regulatory audit?

An internal audit is something the insurer runs proactively to find and fix its own gaps before anyone else looks. A regulatory audit is initiated by an oversight body, often triggered by a complaint, an incident, or routine supervisory activity, and by that point the insurer is responding to someone else's findings rather than controlling the process.

Can existing staff handle this audit, or do we need outside help?

Existing compliance and IT staff can often run the initial inventory and gap assessment, but remediation — particularly rebuilding systems to include proper logging, explainability, and human-review workflows — frequently requires dedicated software development expertise that internal teams weren't resourced for, since it wasn't part of the original system design.

What happens to AI features that fail the audit — do they have to be shut down?

Not always immediately, but a feature identified as non-compliant typically needs a remediation plan and timeline, and in more serious cases regulators can require the feature to be suspended until compliance is demonstrated. This is part of why proactive remediation is preferable to waiting for an external finding.

How does this affect fraud detection AI specifically?

Fraud detection scoring often sits in a middle risk zone — it can influence claims outcomes significantly, so it warrants the same scrutiny around explainability and human review as claims triage tools, even though it wasn't always treated with the same caution as underwriting models historically.

What's the connection between this audit and customer complaints or ombudsman cases?

If a customer disputes an AI-influenced underwriting or claims decision and the insurer cannot produce a clear explanation for how the decision was reached, that gap becomes evidence in an ombudsman case or regulatory complaint, independent of any formal AI Act audit. Good documentation practices built for AI Act compliance directly reduce this exposure too.

Should smaller regional insurers worry about this as much as national carriers?

Yes — smaller insurers often have less capacity to absorb compliance costs and less leverage to negotiate documentation commitments from large vendors, which can make the exposure proportionally larger relative to their size, not smaller.

What's a realistic timeline for fully remediating an insurer's AI vendor stack?

It depends on scope, but a full remediation program — from initial inventory through rebuilding or renegotiating the highest-risk systems — commonly spans many months to over a year for insurers with a broad vendor footprint, especially where core underwriting or claims systems need custom rebuilding.

Does using open-source AI models instead of vendor APIs change our compliance obligations?

Not fundamentally — the obligation attaches to how the system is deployed and what decisions it influences, not to whether the underlying model is open-source or proprietary. Using an open model can, however, give you more direct visibility into training data and behavior, which can make documentation easier to produce.

What role does data provenance play in this audit?

Regulators want assurance that training data for high-risk systems was lawfully sourced, reasonably representative, and free of the kind of bias that would produce discriminatory outcomes. If a vendor cannot describe where training data came from, that is one of the most common audit failure points insurers encounter.

How do we test our AI underwriting tool for bias before an audit finds it for us?

This typically involves running the model against test cases that vary only in protected characteristics or their proxies and checking whether outcomes shift in ways that can't be justified by legitimate risk factors, then documenting that testing process itself as part of the audit evidence. It's a task best handled with technical input from whoever built or maintains the system.

What's the cost difference between fixing this now versus after an enforcement action?

A precise cost comparison isn't something that can be stated as a hard figure, but the general pattern across regulatory compliance work is that proactive remediation is planned and scoped on the insurer's terms, while post-enforcement remediation happens under externally imposed deadlines, often with added legal costs and reputational damage layered on top.

Does this apply to reinsurance arrangements too?

The AI Act's obligations generally attach to whoever deploys the AI system in a decision-affecting way, so if a reinsurer's AI tooling directly influences underwriting decisions passed through to the primary insurer's customers, that relationship can also fall into scope and should be reviewed as part of the vendor audit.

What's the first system insurers should prioritize auditing?

Start with whatever system most directly touches individual pricing or claims outcomes — typically underwriting decision engines and claims triage or fraud scoring tools — since these carry the highest risk classification and the most direct customer impact if something goes wrong.

How does this affect our marketing website's claims about "AI-powered" services?

If your website or product pages describe AI-driven underwriting, pricing, or claims features, those claims need to accurately reflect what's actually happening technically, since overstating AI capability — or understating human involvement — can create both a compliance and a consumer-protection problem if scrutinized.

Can we use a generic compliance software tool to manage this audit?

Generic compliance management tools can help track documentation and deadlines, but they don't replace the underlying technical work of actually building explainability, logging, and human-review capability into your AI-enabled systems — the audit output is only as good as the systems being audited.

What should our contract renegotiation with existing vendors focus on first?

Prioritize the vendors touching your highest-risk systems first — request documented data provenance, audit rights, and a commitment to notify you of material model changes — before spending time renegotiating lower-risk, low-impact tool contracts.

Is there a certification we can get to prove AI Act compliance?

Formal third-party certification schemes for the AI Act are still maturing across the EU, so most insurers today rely on internally documented compliance evidence and legal review rather than a single external certificate, though this landscape may develop further over time.

How do we know if our current claims triage vendor is a compliance risk?

Ask them directly for their AI Act documentation — training data description, risk classification rationale, and human oversight design. A vendor that cannot answer clearly or treats the question as unusual is a signal worth taking seriously, regardless of how well the tool performs functionally.

What's the relationship between this audit and cyber-insurance or E&O coverage for the insurer itself?

Some insurers are finding that their own professional liability and errors-and-omissions coverage terms are being scrutinized in light of AI-related exposure, since an AI-driven underwriting error could trigger claims against the insurer's own coverage. This is a conversation worth having with your own insurance broker alongside the technical remediation work.

Does staff training factor into audit readiness?

Yes — underwriters and claims handlers who use AI-assisted tools need to understand what the tool is actually doing and how to meaningfully exercise human oversight, since an audit will look at whether staff can explain and defend AI-assisted decisions, not just whether the technical documentation exists.

What's the biggest mistake insurers are making right now with this audit?

The most common mistake is treating it as a purely legal or paperwork exercise rather than recognizing that the underlying technical systems often need to be rebuilt to produce the documentation and oversight capability the audit requires in the first place.

How does this affect our decision to keep using legacy policy administration systems?

Legacy systems that predate any AI Act consideration often lack the structured logging needed to support an audit trail for any AI modules bolted onto them, which is pushing some insurers toward modernizing or replacing core systems rather than continuing to patch around the gaps.

Will this get easier once initial enforcement guidance settles?

Enforcement practice and interpretive guidance are still developing across EU member states, so some clarity is likely to emerge over time, but insurers that wait for perfect certainty before acting risk falling further behind on the underlying technical remediation work that needs to happen regardless of how guidance evolves.

What's a reasonable next step for an insurer reading this today?

Start the vendor and system inventory this quarter, even if it's incomplete at first, and get a technical assessment of which systems can and cannot currently produce audit-ready documentation — that assessment is what determines whether you need contract renegotiation, a workflow redesign, or a custom rebuild.

Can Scult help with both the technical audit and the rebuild?

Yes — Custom Software Development work in this context typically starts with understanding what your current systems and vendors can document, then designing and building the logging, explainability, and human-review workflows your highest-risk systems need to pass an audit with confidence.