When I talk with InsurTech founders about their underwriting models, the conversation about explainability usually comes up late and in a defensive register: "We know we'll need to add some explainability features eventually." This framing misses the actual structure of the regulatory requirement. EIOPA's explainability standards — developed under the Big Data Analytics guidelines first published in 2019, refined in subsequent supervisory guidance, and now reinforced by the EU AI Act's provisions on high-risk AI systems — are not a post-hoc documentation requirement. They are a design constraint that, if addressed from the start, produces better models. If addressed retroactively, they often reveal that the model as built cannot satisfy the requirement without substantial redesign.
What EIOPA's Explainability Requirements Actually Say
EIOPA's 2019 report on Big Data Analytics in insurance set out two core explainability principles that national supervisory authorities across EU markets have subsequently operationalised. First, insurers using ML models in underwriting or claims decisions must be able to explain, to the policyholder and to the supervisory authority, the material factors that contributed to a specific decision — not just to describe how the model works in general terms. Second, the explanation must be in terms that the affected person can understand and, where the decision is adverse, can meaningfully contest.
The EU AI Act, which classifies AI systems used in insurance underwriting as high-risk AI systems under Annex III, reinforces and extends these requirements. High-risk AI systems must maintain technical documentation that includes a description of the model's relevant input data, the logic by which the model processes inputs to reach outputs, the performance metrics including accuracy, robustness, and fairness measures across relevant demographic groups, and the testing protocols used to validate the model before deployment.
This is substantively more demanding than what most InsurTech founders describe when they say "we'll add explainability later." Generating a SHAP value attribution for a specific prediction is a useful technical tool. It is not equivalent to producing the systematic documentation, fairness testing, and audit trail that the AI Act requires for ongoing deployment of a high-risk AI system.
Why This Is a Model Architecture Constraint, Not a Documentation Problem
The reason explainability has to be addressed at design rather than deployment is that some model architectures are fundamentally more amenable to producing the kind of explanations EIOPA requires than others, and retrofitting explainability onto an architecture that was not designed for it is significantly harder than building explainability in from the start.
Gradient boosting models (XGBoost, LightGBM) produce feature importance outputs that, with some care in feature engineering, can generate policyholderreadable explanations at the individual prediction level. The explanation is approximate — SHAP values for tree models are a practical proxy for true Shapley values — but the approximation is close enough for supervisory purposes when the feature set has been designed with explainability in mind.
Deep learning architectures applied to insurance underwriting inputs — particularly unstructured data inputs like free-text risk descriptions or image-based property assessment — produce explanations that are harder to translate into policyholder-meaningful terms. This does not mean deep learning is unusable in European insurance underwriting; it means that the explainability layer for deep learning models requires substantially more architectural investment, and that founders building on deep learning architectures need to have thought through their explainability approach before deployment, not after.
The models that are clearest to defend under EIOPA scrutiny are those where: the feature set is limited to variables with direct causal relationships to the risk being priced; the model architecture produces locally interpretable explanations at the individual prediction level; and the training and validation process includes formal fairness testing across protected characteristics. Designing toward these properties does not require sacrificing predictive accuracy — in many cases it improves it, by preventing the model from learning spurious correlations that would fail fairness testing at the point of regulatory review.
The Fairness Dimension That Founders Consistently Underestimate
The fairness requirement is the component of EIOPA's explainability framework that generates the most compliance risk for founders who have not engaged with it early. The principle is straightforward: AI underwriting models cannot use proxies for protected characteristics — gender, race, disability, religion — even when those proxies appear to be commercially neutral variables like postcode, occupation category, or behavioural patterns that happen to correlate with protected groups.
The practical challenge is that many variables that are actuarially predictive of insurance risk are also correlated with protected characteristics. Postcode is predictive of theft and flood risk. Occupation is predictive of life expectancy. Credit score is predictive of claims frequency. Using any of these variables in underwriting models requires either demonstrating that their predictive value is attributable to the risk factor (the geographic characteristic of the area, not the demographic composition of its residents) or removing them and accepting the predictive loss.
EIOPA guidance does not require that insurance models use zero actuarially-meaningful variables that are correlated with protected characteristics. It requires that carriers can demonstrate that the correlations are driven by risk factors rather than proxy discrimination, and that the model has been tested for disparate impact on protected groups with the results documented and available for supervisory review. This is not a compliance checkbox — it is ongoing monitoring work that continues as long as the model is deployed.
The Competitive Advantage for Founders Who Get This Right
We are not saying that EIOPA explainability requirements are primarily a burden. For founders who build with them from the start, they are a competitive advantage. A carrier evaluating two underwriting AI vendors — one that can produce a complete AI Act technical documentation package, fairness testing results, and individual-prediction explainability in policyholder-readable format, and one that cannot — will prefer the former, not only because of regulatory compliance risk but because the documentation package is evidence of model quality and operational discipline that reduces the carrier's own regulatory exposure.
The founders who treat EIOPA explainability as a moat, rather than a compliance burden, are building products that incumbents find easier to adopt than technically superior but regulatory-opaque alternatives. In European insurance, regulatory trust is a form of distribution authority. The teams building toward it from day one are making a correct strategic decision, even if the near-term development cost is higher.