Insurance policy document extraction was the job: a life insurer’s product team kept every fee, deadline and exception of its flagship product in an 84-page terms and conditions set, and in people’s heads. We built a system that reads the full document, turns it into one parameter table with a clause reference for every value, writes a plain-language summary for customers, and points to the places a person should look at before the next revision.
The problem: the product lives in 84 pages of clauses
A modern life insurance product is rarely one document. This one was a main set of terms for an investment-linked life policy, six sets of optional riders (accidents, loss of working capacity, critical illness, telemedicine, capital accumulation) and two annexes with injury tables. Together that is 84 pages.
Everything the product team, the call centre and the sales network need sits somewhere in those pages: the monthly administration fee, the cost of changing the contract, the minimum indexation of the sum insured, how long a customer must pay before they can pause premiums, how long the pause can last, when the suicide exclusion ends, where in the world the cover applies.
In practice that knowledge lived in two places: in the memory of a few experienced people and in a separate spreadsheet that someone had to keep in sync with every new edition of the terms. Every revision risked a cross-reference that no longer matched, and every customer question about a premium holiday meant somebody opening the PDF.
What we built
- Structure first. The system reads the whole document and recognises it as seven separate sets of terms plus two annexes, each with its page range, so the team sees the product map before any detail.
- A parameter table with clause references. From the main terms it extracted 24 parameters in five groups: fees, indexation, premium holidays, cover and exclusions, and process deadlines. Every value carries the clause number it came from, and one click shows the original sentence.
- Plain-language summaries. The same clause is shown twice: in legal wording and as a short answer a customer would understand. For example, the premium-holiday rules become “Yes, if you have paid for at least 3 years; the pause can last up to 12 months”.
- Review flags. The system marks places a person should check. In this document it flagged five: an indexation rule that applies a “not less than” minimum to the sum insured but not to the premium; a clause that depends on a threshold defined in another chapter; five different time limits inside one premium-holiday process; a definition of dangerous sports set in the main terms but used by two riders; and a customer-friendly rule that a surrender value is paid even when an event is excluded.
What changes for the team
| Before | With document extraction | |
|---|---|---|
| Finding a fee or deadline | Search the PDF, or ask a colleague | One table, grouped by topic |
| Checking where a value comes from | Read the chapter again | Click the clause reference |
| Answering a customer question | Paraphrase legal text on the phone | A ready plain-language summary |
| Preparing a new edition | Hope the cross-references still match | Flagged dependencies and asymmetries to review |
| Product knowledge | In a few people’s heads and a side spreadsheet | In a structured, shareable table |
The effect is less about speed and more about confidence. The same table serves the product team, the call centre and the self-service pages, and each value can be traced back to the clause that defines it.
Where people stay in control
The system does not decide whether a flagged point is a mistake. The flags are not an error list; they are places where a careful reader would want to look, and the product team decides what, if anything, to change.
We also drew a clear regulatory line. Risk assessment and pricing in life and health insurance are high-risk uses under Annex III 5(c) of the EU AI Act. This work deliberately stays on the other side of that line: product documentation, customer summaries and consistency checks, with no underwriting and no pricing decisions. That is why it is a practical place for an insurer to start.
Where else this works
Any organisation whose product or obligations live in long, versioned documents can use the same approach:
- Banks and leasing companies: general terms, fee schedules and product sheets kept consistent across editions.
- Property owners: leases turned into fields, deadlines and ERP entries.
- Public procurement and construction: tender documents checked for requirements and contradictions.
Related use cases: Insurance product documentation AI · Competitor policy monitoring · Lease abstraction AI. All Contracts & documents to data use cases · How we deliver this: Custom AI solutions · Document extraction as a product: extriq
FAQ
Does the system change the policy documents?
No. It reads them, builds the parameter table and summaries, and flags points for review. People decide on any change to the terms.
How do we know an extracted value is correct?
Every value shows the clause it came from, and the original sentence is one click away, so each number can be checked against the source.
Is this a high-risk AI system under the EU AI Act?
Documentation work like this sits outside the high-risk area for life and health insurance, which covers risk assessment and pricing of individuals. We keep it that way by design.
Want to see your own product terms as one table with clause references? Talk to us