Claims triage, document extraction, underwriting support and fraud detection. An insurance decision moves a policyholder’s money, so the system’s job is to assemble the file and the trace — and a named human disposes of the decision.
Every insurance system we build starts from the same distinction. Reading a hundred pages of a claim file, pulling out the policy number, the date of loss, the excess, the schedule limits and the three sentences in the engineer’s report that decide liability — that is assembly, and a model does it faster than a person and does not get bored on the eightieth file. Deciding whether the claim is paid is disposal, and it stays with a named handler who can be asked why.
That distinction is not a philosophical position, it is an architectural one. It determines what the system is allowed to write, what it may only propose, and what it must attach. Every extracted field carries a citation to the page and the line it came from, so the handler is checking a claim rather than trusting a summary. Every proposed action is logged with the identity that released it. Nothing about this makes the model correct; it makes the model’s errors visible to the person accountable for them, in the seconds before they matter.
The same shape holds in underwriting. A submission is read, normalised against your appetite and exposure rules, and presented with the gaps and the contradictions surfaced rather than smoothed over. The referral is drafted; the risk is priced by your pricing function and accepted by your underwriter.
Multimodal extraction over the whole claim file — photographs, scanned reports, faxed forms, spreadsheets — with typed exception queues for what cannot be read, and a severity and completeness score that decides routing rather than arrival order.
SEE THE DOCUMENT PIPELINE →Retrieval over submissions, wordings, endorsements and your own appetite guidance, so a referral arrives with the relevant clause quoted and linked rather than paraphrased. The system finds and cites; it does not price.
SEE RAG SYSTEMS →Alerts are assembled into a structured case — network context, prior claims, inconsistencies between documents — for an investigator to work. A model that flags is a model that must be evaluated on its false positives, and we build the harness that does it.
SEE RISK AGENTS →Policy questions, document requests and claim-status enquiries answered from your own systems with citations, with anything touching vulnerability, distress, a complaint or a coverage dispute routed to a person immediately and with the full conversation attached.
SEE SUPPORT AGENTS →Insurance is one of the few sectors where the regulatory question is not a governance afterthought but a design input, and three regimes shape the architecture before any code is written. What follows is how we build against them. Whether a given system falls inside any of them is a determination for your compliance and legal functions, not for us.
The EU AI Act. Annex III lists AI systems intended to be used for risk assessment and pricing in relation to natural persons in the case of life and health insurance among its high-risk categories. If a system you are commissioning sits there, the obligations that follow are engineering obligations as much as paperwork ones: a risk management process, data governance covering the training and evaluation sets, automatic logging over the system’s lifetime, technical documentation, human oversight designed in rather than asserted, and demonstrated accuracy and robustness. Our part is to build a system where each of those can be evidenced from artefacts that already exist — the evaluation harness, the trace log, the architecture document — rather than reconstructed for an audit. The EU AI Act page sets out the timeline and the classification questions in full.
GDPR Article 22. A decision based solely on automated processing which produces legal effects or similarly significantly affects a person carries specific restrictions and rights. Declining cover, setting a premium, or repudiating a claim is capable of being exactly that. The engineering consequence is that human involvement has to be real: the reviewer needs the authority to reach a different answer, the information required to reach it, and the time to use both. A screen that shows a recommendation and an approve button is not oversight, it is a rubber stamp with an audit trail. We design the review step so the evidence arrives before the recommendation does.
Discrimination through proxies. A model does not need a protected characteristic in its inputs to price on one. Postcode, vehicle model, occupation history, device and payment pattern all carry correlations, and a system fitted on historic outcomes will reproduce whatever was in those outcomes. The controls are unglamorous: keep the feature set documented and deliberate, test outcomes across groups where you lawfully can, record what was tested and what was found, and keep a person able to override. None of this removes the exposure. It makes it measurable, which is the difference between a finding you can answer and one you cannot.
These are engineering controls we build into the architecture, not certifications. QQuantum.ai holds no security certifications, and the audits, attestations and regulatory permissions your sector requires remain yours — see our trust centre.
It can prepare one, and in our architectures that is what it does. The system reads the file, extracts and cites the facts, checks them against the policy wording and the schedule, flags the contradictions and drafts the recommendation. A named handler releases it. That boundary exists partly because GDPR Article 22 restricts decisions based solely on automated processing where they significantly affect a person, and partly because a model will occasionally be confidently wrong about a document, and the cheapest place to catch that is before the decision leaves the building.
It may be. Annex III lists AI systems intended for risk assessment and pricing in relation to natural persons in life and health insurance among the high-risk categories, and the classification of your specific system is a determination for your compliance function rather than for us. What we can say is what changes if the answer is yes: logging over the system lifetime, documented data governance for the training and evaluation sets, technical documentation, demonstrated accuracy and robustness, and human oversight that is designed rather than asserted. We build so those artefacts are produced as a by-product of the engineering instead of assembled retrospectively.
We do not claim to remove the exposure, because no architecture can. What we do is make it visible. The feature set is documented and deliberate rather than inherited; outcomes are tested across groups where testing is lawful and the test is recorded with its result; the system explains a decision in terms that can be reviewed by a person; and an underwriter can override with the override logged. A vendor who tells you their model is free of proxy discrimination has not measured it.
In the ordinary case, nowhere. The system runs in your own cloud accounts against your own claims and policy stores, and we hold no copy. Where a hosted model is used, we record the provider’s retention and training terms in the architecture document at the time of writing, and you should confirm them against the provider’s current terms before relying on them. Where no third party may see the data at all, an open-weight model on your own infrastructure is the design, and we will say plainly what that costs in capability.
No — none. We are a small engineering firm and we do not sell assurance. What we produce is the evidence your own audit needs: an architecture document, a trace log, an evaluation harness with its method written down, and access scoped by role. If your procurement process requires a certified supplier for this scope, we will tell you early rather than late.
Start with one line of business and one decision — we map who decides what on what evidence, then build only the assembly around it.
30-minute technical call · no deck
What we built, what stage it is at, and a link to the live thing wherever there is one.
yourOS is an operating system with an AI at its heart. You talk to it like a person, out loud or typed. It makes your calls, plans your days and works on your projects with a crew of agents, on your own private server. Our own product, built from the first commit; the waitlist is open.
Website, backend and app assets for Sonora, a free AI sound-therapy app on iOS and Android published by Cognitive AI.
Brand, website, prototype, apps on five platforms, the AI backend and the algorithm-intelligence pipeline for Podswap, a social growth engine that runs without a human in the loop.
In closed beta: Roxy, a private AI assistant with permanent memory running on infrastructure the user owns. Brand, site, product, backend and conversational design.
Live at coherence.com: brand identity generated with AI agents we directed, the motion system and website for the group behind Sonora, AboutAI, WakeUp and MudShadows. Agent work remains in build.
Live at domainbooth.com for DomainBooth, a premium domain brokerage: a new animated mark, every page redesigned and rebuilt with designed mobile layouts, and a custom CMS for its sales record, featured names, press and enquiries.
Apps, platforms and campaigns for these teams, long before the AI work. Every one is written up on the work page — what we did, and where our part ended.
