The question is not whether AI does legal work. The question is who signs for it. At Navabi that is always a lawyer, and you see for every item who did what.
Fictional names, real way of working.
With one line: we want to sign on Monday.
YouOne-sided, no end date, penalty of € 50,000 per breach. A proposal for each point.
AI agentThe lawyer keeps the penalty but makes it mutual. Two points adjusted.
LawyerThe redline goes to Aldenhove. Cost: 1 credit.
YouThe agent is fast and thorough. It is not a lawyer, and we say so.
An employer asks in Slack whether he needs to do anything if he does not renew a fixed-term contract. This is how that question runs through Navabi, second by second. Fictional names, real workflow.
Every document that comes in goes through the same fixed chain. Four of the six steps are code, not a model. That is deliberate: what can be deterministic, we do not leave to a model.
| Step | What happens | By |
|---|---|---|
| 1. Ingest | Open the file, extract text and tables, convert scans with OCR. In an isolated environment without network access. | code |
| 2. Classify | What kind of document is this: employment contract, NDA, SaaS agreement, invoice, a letter from the tax authority. | model |
| 3. Extract | Parties, dates, amounts and clauses according to a fixed schema per document type. Every item with page and passage. | model |
| 4. Quote check | Every quote must appear verbatim in the source. If it does not, the item goes no further. | code |
| 5. Missing documents | The checklist from your company profile minus what is already there. You see what is missing before it matters. | code |
| 6. Risk rules | Per document type, tested against your standard positions: liability, term, payment terms, forum, covenants. | code |
Before anything goes to a model, a classification on our own servers decides how sensitive the matter is. The system then picks the route.
| Matter | Route | What leaves the building |
|---|---|---|
| Standard | Models from major providers, only through their EU region, without retention and without training on your data. | The text the task needs |
| Moderately sensitive | Pseudonymised first: names, numbers and amounts become tokens. The mapping stays in our vault and is restored afterwards. | Tokens only, no names |
| Sensitive | The whole chain on models we host ourselves in the EU. Health, criminal records, national ID numbers and IDs, KYC and UBO, price-sensitive information, and anything you mark as such. | Nothing |
A model that sounds good is not yet a model that is good. So we measure per task, and the measurement decides what a model may do.
For every task, from pulling a deadline out of a contract to assessing a non-compete, a fixed set of examples with the right answer. A new model or prompt only goes live if it scores at least as well.
The system states how confident it is about every item. We calibrate that confidence on the evaluation set. Below the threshold it asks for confirmation instead of guessing.
Not the same prompt again, but a separate verification task, preferably on a different model family, plus the literal quote check in code.
In spot checks we measure how often something was not escalated that should have gone to a lawyer. If that rises above the threshold for a task, the task goes back to sign-off.
When a lawyer corrects something, it becomes a new example in the evaluation set and a proposal for the playbook. The proposal only takes effect after a lawyer approves it.
We do not train models on your data, and neither do our providers. Improvement happens through prompts, rules and tests, all versioned and traceable.
Only Navabi, and only the people working on your matter. See the Trust Center.
No. Only after your approval.
No, that plan has no credits. You can bring in a lawyer per item.
Then we say so upfront, with a fixed price. You decide.