AI for insurance, mutuals and finance

What I put in place

I build a pipeline that reads, extracts and classifies your documents automatically, wired into your business system. These are the use cases that pay off fastest in the sector:

• Policy and claims extraction: amounts, renewal dates, coverage, clauses, IBANs. The right fields come out structured and ready to enter your tool, even from scanned, stamped or badly framed PDFs.
• Classification and routing: each document recognized (claim form, evidence, letter, statement) and sent to the right file or team, with no manual sorting.
• Regulatory copilot: your policy wordings, procedures and compliance texts become a base you query in plain language, with a sourced answer in seconds. Every answer cites its source so you can check it.
• Back-office automation: follow-ups, completeness checks, status updates and reporting handled by reliable workflows, with an alert when something gets stuck.

Compliance and sovereignty, by design

Your data is sensitive by nature: health data for mutuals, financial and personal data everywhere else. So GDPR compliance isn't a box you tick at the end, it's an architecture decision from day one.

In practice, I deploy on an EU cloud when speed matters, or directly inside your own infrastructure when your data must never leave it. Private open-source models, EU hosting outside the US Cloud Act: your perimeter decides, not mine. Your documents are never used to train public models.

In a regulated sector, traceability isn't optional

A system that handles policies and claims has to answer a simple question: who saw what, and on what basis was this decision made. That holds for an internal control, a regulator audit or a dispute.

So I put an audit trail on every step (which field was extracted, from which document, when) and strict access control: each person sees only what they're entitled to, and the copilot never surfaces a file someone wasn't allowed to open. It's the first design point, not a patch added afterwards.

One number, and what it doesn't tell you

At an insurance company: 10x more documents processed per day, zero rekeying. It's the only figure I put forward, because it's the only one I can stand behind honestly, anonymized.

That number doesn't mean your context will land on exactly the same result. The real gain depends on the state of your documents, your volumes and your systems. That's precisely what an audit measures before a single line of code gets written: I'd rather give you a reasoned no than a promise I can't keep.

The electronic invoicing turning point

Electronic invoicing is becoming mandatory for French companies, in phases. In practice, a growing share of your inbound flow will arrive in structured formats that have to be read, checked and reconciled automatically.

It's a constraint, but mostly an opening: the same pipeline that reads your policies and claims reads your supplier invoices and receipts. Better to build one clean document-processing chain now than to scramble against the deadline later.

Where to start

You don't take on the whole system at once. I start with a short audit: I look at your processes, the state of your data and your compliance constraints, then I size the use cases by return on investment and honestly rule out the ones that aren't worth it.

Then a POC on a real, measurable scope (one document type, one line of claims) to prove the value on your data before scaling. One contact from the first call to production, a documented architecture, a clean handover: no lock-in to a supplier, your team keeps control.