Why this is a real question and not a compliance formality
A single life insurance document routinely contains a full legal name, a date of birth, a policy number, a face amount, a premium, a bank account for the draft, and — on an application or an underwriting letter — a medical history. That combination is close to the definition of sensitive personal data.
The part most buyers have not checked is that several major model providers do not merely warn about this. Their acceptable-use terms prohibit sending financial or medical information and dates of birth to the service at all. That is a prohibition rather than a permission you can apply for, and it is not fixed by an enterprise plan or a checkbox.
What Briar does
- 01
Documents are read on your machine
The model that reads a carrier PDF, a scan or a photograph runs on the hardware Briar is installed on. The page never leaves it.
- 02
There is no hosted fallback on that path
This is a deliberate design decision and the more important half. A fallback fires when the local model is busy or down — at three in the morning, unwatched — and it would send exactly the data the rule exists to protect. A degradation that breaks the rule is not a degradation, it is the incident.
- 03
The overnight analysis is local too
The pass that reads client files looking for opportunities is the one that assembles the most sensitive payload of all: name, date of birth, policy values, and a prompt asking the model to look for serious illness. It runs on the same local model, on the same machine, with the same absence of a fallback.
- 04
The two are switched separately
Reading documents and analysing the book are different lanes with different switches, because a refused document read and a refused analysis fail in completely different ways, and one flag for both would hide the second.
What does still leave, stated plainly
It would be easy to write "fully local" here and it would not be true. Briar routes each job to the model measured best for it, and two categories still use hosted models:
- Message routing and the conversational assistant — working out what you meant when you type something, and answering questions about your book. These carry the text of your own messages and the records needed to answer them.
- Letter and document authoring — writing a client letter or building a proposal deck in your voice. Long-form prose is the one job where the quality difference is externally visible, so it currently runs on a hosted model.
- Neither of these is the document path. A carrier PDF, a scan, a photographed page and the overnight client analysis do not go to either.
That is the honest boundary as it stands today, and it is the boundary a buyer should ask every vendor in this category to draw. A vendor who cannot draw it has not thought about it.
The other half: isolation between agents
Separation between one agent's book and another's is enforced by the database rather than by application code. Every tenant table carries a policy PostgreSQL applies to every query — 52 tables as of this writing, verified automatically — so a bug in the application cannot leak across agents, because the application is not what is enforcing it.
Documents are stored once, by hash, encrypted at rest. Every automated decision Briar makes on its own judgement is logged with the evidence behind it, so "why did that end up there" is always answerable.