EU AI Act compliance for credit scoring and insurance AI: what the audit trail looks like

Credit scoring and life-and-health insurance pricing carry their own sectoral rules already. The EU AI Act now layers a second regime on top: both are high-risk. Annex III, point 5 names them explicitly: "AI systems intended to be used to evaluate the creditworthiness of natural persons or establish their credit score, with the exception of AI systems used for the purpose of detecting financial fraud" and "AI systems intended to be used for risk assessment and pricing in relation to natural persons in the case of life and health insurance."

If you build the AI, you are a provider with provider obligations. If you deploy it to make decisions about real customers, you are a deployer with deployer obligations. Both have to produce the audit trail. The full regime is in force.

The audit trail in plain English

A high-risk AI system under the AI Act has to be defensible at three moments in time.

Before it goes live. Article 11 and Annex IV require a technical documentation file with nine sections: intended purpose, system architecture, data and data-governance, performance metrics, risk-management measures, monitoring plans, harmonised standards applied, the EU declaration of conformity, and the post-market monitoring plan. This file is kept for ten years.

While it is running. Article 12 requires that the system "technically allow for the automatic recording of events ("logs") over the lifetime of the system." Article 19 requires the provider to keep those logs for at least six months — and longer where Union financial-services law requires, which it almost always does for credit decisions.

After incidents. Article 73 requires serious incident reports within 15 days (10 if there is widespread fundamental-rights infringement). A wrong credit decision that affects a protected class can qualify. The AI Act does not wait for a court to tell you.

Stack those three together and you have the audit trail: pre-deployment artefacts, runtime logs, and post-market evidence. It is the same shape for credit scoring and for life-and-health insurance pricing.

Why "we tested it on a sample" does not survive

The PM checks ten profiles. The model assigns ten reasonable scores. Engineering ships. A quarter later the supervisory authority asks for the performance breakdown across applicant age bands, postcodes, and gender, plus the rationale for the score cut-off. Nobody on the team has those numbers, because nobody on the team ever generated them. The Ship and Pray loop produces a model that runs, not a system that is documented.

Article 26(4) requires deployers to ensure input data is "relevant and sufficiently representative." Article 26(6) requires automatically generated logs to be kept for at least six months. Article 27 requires public-sector deployers and certain private deployers — including banking, insurance, and credit scoring — to perform a Fundamental Rights Impact Assessment before first use.

If you cannot tell a regulator how your credit-scoring model performs on applicants over 60, you have not done the FRIA. If you cannot show why you set the approval threshold at 0.62 rather than 0.65, you have not documented the risk-management trade-off. If you cannot reproduce the score a real applicant got six months ago, you have not kept the logs.

The penalty band that applies is €15 million or 3% of worldwide annual turnover. For a mid-size insurer, 3% of turnover is a quarter's profit.

The credit and insurance audit-trail checklist

For each AI feature touching credit or insurance pricing, you should be able to produce:

1. - Annex IV technical documentation — including a description of training data, accuracy and bias metrics broken down by protected sub-groups, the rationale for performance thresholds, and the human-oversight measures.
2. - Versioned prompts and model configurations — every change to the prompt, the model, the temperature, the cut-off threshold, captured with the date, the author, and the reason.
3. - Evaluation reports — per-version performance against the acceptance criteria, on a representative dataset, signed off by the domain expert who defined the criteria.
4. - Runtime event logs — every score generated, the inputs that produced it, the model version, the threshold applied, and any human review that occurred.
5. - Reviewer and override records under Article 14 — who looked at flagged cases, what they decided, what they overrode.
6. - Post-market monitoring evidence under Article 72 — periodic re-evaluation against fresh data, drift detection, retraining decisions.
7. - Fundamental Rights Impact Assessment under Article 27.
8. - Serious-incident register under Article 73.

That list is the audit trail. It does not appear from observability dashboards. It appears from the discipline of running evaluations before changes ship, with the domain experts who understand credit risk and insurance underwriting.

Where domain experts have to be in the loop

The Act is unusually direct on this. Article 14 requires that systems be designed so a person with the right competence can "decide not to use the system or otherwise disregard, override or reverse its output." Article 26 puts that obligation on the deployer in real time.

For credit and insurance, the people with the right competence are not engineers. They are credit risk officers, actuaries, underwriters, compliance officers. They know what a defensible score distribution looks like for a protected sub-group. They know which rationale will survive a supervisory review.

Standard AI tooling cuts them out. The evaluation interface is built for ML engineers. The eval set lives in a notebook. The acceptance criteria are buried in a Slack thread. By the time anything reaches the credit risk officer, the model is already in production and the conversation is a dashboard, not a decision.

Lovelaice is the inverse. The credit risk officer or the actuary defines what "acceptable" looks like before the platform sees data: thresholds for disparate impact, factual-correctness requirements for the rationale text, completeness checks for required fields, risk flags for edge cases. They evaluate outputs directly, with a blind review that removes bias from the scoring. Every evaluation is captured. Every prompt version is immutable. Every result is exportable for the auditor.

When the supervisory authority asks "how do you know this model performs equitably for applicants from this postcode range," the answer is not "we ran some tests." The answer is a report.

Retention and reporting windows to design for

• - Six months minimum log retention under Article 19. Sector-specific financial-services rules typically extend this.
• - Ten years retention of Annex IV technical documentation and the EU declaration of conformity.
• - 15 days to file a serious incident report. 10 days if a person dies or a fundamental-rights infringement is widespread.

If the model is shipping today and the audit trail is not, the model is shipping into a fine. Data beats gut feel. Always. In credit and insurance, it also beats a regulator's patience.

Sources

• - Regulation (EU) 2024/1689 — official text (EUR-Lex)
• - Annex III, point 5 — essential private and public services
• - Annex IV — technical documentation
• - Article 11 — technical documentation
• - Article 12 — record-keeping
• - Article 14 — human oversight
• - Article 19 — automatically generated logs
• - Article 26 — deployer obligations
• - Article 27 — Fundamental Rights Impact Assessment
• - Article 47 — EU declaration of conformity
• - Article 72 — post-market monitoring
• - Article 73 — serious-incident reporting
• - Article 99 — penalties

More in this series

The EU AI Act audit-trail series — one article per Annex III high-risk category:

• - Biometrics: remote identification, categorisation, and emotion recognition
• - Critical infrastructure: safety-component AI
• - Education and EdTech: admissions, assessment, and proctoring
• - Employment and HR: recruitment, ranking, and workforce management
• - Law enforcement: risk assessment, polygraphs, and profiling
• - Migration, asylum, and border control
• - Justice and democratic processes