Start from a simple test. For any automated quote, decline, or referral your system issued last quarter, could you sit across from a regulator and show why it happened, who was accountable for it, and which rule it followed? If the honest answer is "not easily," the gap is rarely the model. It is that the decision was never captured in a form anyone can inspect after the fact. The work here is less about proving a model is right and more about proving every decision is accountable.
That distinction matters because an AI decisioning system reads a submission, scores the risk, and issues an outcome in seconds, faster than any human file note. If the reasoning is not recorded as the decision is made, it is gone. The fix is to design the audit trail into the decision itself, and to run the whole thing as an external layer that never replaces the core policy system.
The five capabilities an AI underwriting audit must prove
A defensible audit trail is not a report you generate at year end. It is five properties that have to hold for every single decision the system makes.
- A complete decision log. Every automated quote, decline, or referral records its inputs, the data sources and enrichment used, the model version that ran, the output, and the reason, all time-stamped and tamper-evident. If you cannot reconstruct a decision months later, you cannot defend it.
- A plain-language explanation. For each outcome, a person should be able to read why it happened in business terms, not a raw feature vector. A decline a broker or an ombudsman cannot understand is a decline you cannot stand behind.
- Human oversight with real authority. A named role can review any decision, override it, and is accountable for the outcome. Cases that fall outside the rules the system was given escalate to a person with the reasoning attached, rather than being forced to a machine verdict.
- Continuous monitoring for drift and bias. Model performance and outcome distributions are watched over time, so that data drift or a disparate effect on a group of applicants is caught by the system rather than by a complaint.
- A map from each control to the rule it satisfies. Every log, explanation, and oversight step is traced to the specific obligation it meets, so an auditor sees not just that controls exist but which requirement each one answers.
These five are not arbitrary. They mirror the duties the EU AI Act places on high-risk systems: record-keeping, transparency, human oversight, accuracy and monitoring, and risk-management documentation. Build to them once and you have a single evidence base for every regulator who asks.
Auditability is not the same as accuracy
A model can be accurate and still fail a review. Accuracy is a property of the model. Auditability is a property of the decision. A regulator looking at a disputed decline does not ask whether your model scores well on a validation set. They ask why this applicant, on this day, received this outcome, and whether a person could have caught an error. A correct decision you cannot explain is, for compliance purposes, a decision you cannot defend. That is why most of this work is capturing and explaining decisions, not tuning models.
What the rules actually require
In Brazil, two regimes bind an insurer's book today, across every line. Under the LGPD, a person has the right to request a review of decisions made solely by automated processing that affect their interests, and to receive clear information about the criteria behind them. In practice, an automated decline cannot be a black box. Under SUSEP conduct and governance expectations, the insurer has to show that its acceptance decisions follow a consistent, documented policy, applied the same way to every comparable case. The five capabilities above produce exactly the evidence both regimes ask for, and every auditable decision record should be encrypted at each step.
The EU AI Act is the third reference, and it is worth building to even from Brazil. It classifies AI used for risk assessment and pricing in life and health insurance for natural persons as high-risk under Annex III, which triggers duties on logging, transparency, human oversight, and monitoring, the same five capabilities again. Non-compliance with those high-risk obligations can reach EUR 15 million or 3% of worldwide annual turnover under Article 99. Those obligations were set to apply from August 2, 2026 under the enacted regulation, though the European Commission's November 2025 Digital Omnibus proposal floated adjusting that timeline, so the final date is worth tracking against the published text. The takeaway does not rest on the calendar. For a global insurer, the EU standard is already the strictest one on the horizon, and building to it clears SUSEP and the LGPD by default.
Why the core system is never touched
An audit layer is worthless if standing it up means migrating the policy system. It should not. WIR runs as an external AI layer on top of the existing core: it reads the submission, makes the decision, and writes that decision and its full audit trail back to the system of record, which stays the book of authority. Nothing is ripped out, and the insurer keeps its authority limits and the final say.
This is also what makes the project shippable. BCG has found that roughly 70% of insurers do not carry their innovation initiatives through, largely because of IT limitations. An audit-ready agentic layer that needs no core migration and adds no load to the IT roadmap is often the only version of the project that survives contact with reality.
Where to start
Sequence it. Logging and explainability come first, because every other control assumes a decision you already captured and can read back. Wire human review into referrals next, then stand up monitoring, then produce the control-to-rule map your auditors will actually open. WIR is proving this approach in a live proof of concept with a global insurer in the Transport line, where each decision returns to the core with its audit trail attached. The goal is not an AI that is never wrong. No one in insurance should promise that. The goal is a decision you can always explain, calibrated to a policy you approved, with a person in the loop wherever the risk deserves one.
Perguntas frequentes
What does it mean to audit an AI underwriting decision?
It means being able to show, for any automated quote, decline, or referral, why it was made, who was accountable, and which rule it followed. The decision has to be recorded and explainable after the fact, not reconstructed from memory. Auditing is about accountability for each decision, which is a separate question from whether the underlying model is accurate.
Does the EU AI Act apply to insurers in Brazil?
The EU AI Act binds AI placed on the EU market, so it reaches a Brazilian insurer mainly as part of a multinational group with European operations. Even where it does not bind directly, its high-risk requirements for logging, transparency, human oversight, and monitoring have become the reference template that other supervisors echo. Inside Brazil, the binding rules are the LGPD and SUSEP conduct and governance expectations.
Do you have to replace the core policy system to make AI decisions auditable?
No. A well-designed audit layer sits on top of the existing core as an external AI layer. It reads submissions, makes decisions, and writes each decision and its audit trail back to the system of record, with no core migration and no added load on the IT team. That is usually what lets the project ship at all, given the IT constraints most insurers face.
What does the LGPD require for automated underwriting decisions?
Under Article 20 of the LGPD, a person can request a review of a decision made solely by automated processing that affects their interests, and can ask for clear information about the criteria behind it, subject to trade secret. For an insurer, that means an automated decline has to be explainable and open to human review, not a black box.
Is an accurate model enough to pass a compliance audit?
No. Accuracy is a property of the model; auditability is a property of the decision. A regulator reviewing a disputed outcome asks why a specific applicant received a specific decision and whether a person could have caught an error, not how the model scores on a test set. A correct decision you cannot explain still fails the review.