Data sovereignty and model routing
How the model router keeps a sovereign tenant's documents away from third-party model providers, and why where your analytics go is a separate question with its own control.
The model router picks a backend on two independent axes. The tier (quality or sovereignty) is a data-residency decision. The model class (reasoning or generation) is a capability and cost decision, which the Review Level can nudge.
| Tier × class | Backend → model |
|---|---|
| quality · reasoning | Anthropic → Claude Opus (adaptive thinking) |
| quality · generation | Anthropic → Claude Sonnet |
| sovereignty · reasoning | Ollama → local reasoning model (configurable) |
| sovereignty · generation | vLLM → DiffusionGemma (falls back to local reasoning) |
| vision / OCR (sovereign) | Local Gemma 4 (native multimodal) |
| fast open-weight (opt-in) | Cerebras → Gemma 4 (cloud, very fast, BYOK-friendly) |
The sovereignty guarantee
A sovereignty-tier call never touches a cloud provider. If a sovereign lane is misconfigured to point at a cloud backend, it throws at startup instead of leaking. OCR fails closed too: a sovereign tenant's scanned pages are transcribed by a local vision model, never sent to cloud OCR.
Token use and cost are metered per call and aggregated per review, and a per-review budget with a circuit breaker caps runaway spend. Local models are promoted into reasoning slots only after they pass evaluation, so quality is proven before it is trusted.
A guarantee about models is not a guarantee about analytics
Everything above is about where your documents are processed. The second question has a different answer: where does LexCore's own operational data go? That means the product analytics that count how often a feature is used, and the error reports produced when something breaks.
Those carry no document text. They do carry your tenant identity, so an offshore analytics service would learn which firms use which features and how often. That is client-adjacent information leaving the jurisdiction, even though no contract does.
Two boundaries, set independently
You can choose cloud models under a data-processing agreement and still require that LexCore's own analytics and error reports never leave the country. They are separate controls. On an in-country deployment the analytics service is self-hosted inside your own network. No third party is involved, so there is nothing to add to a sub-processor register.
This is enforced, not just promised. If a telemetry or error-reporting destination is outside the boundary, the application refuses to start rather than starting and quietly sending. The check runs before anything can be transmitted, and we test it by deliberately pointing it at an external host and confirming the refusal.
Notification email is egress too, and it is the easiest to overlook. Matter notifications and deadline reminders carry matter subject lines and client addresses. LexCore can send them through a mail service self-hosted on your own infrastructure, so that traffic need not pass through a third-party sending platform at all. Again, that removes an entry from the sub-processor register instead of documenting one.
Related documentation
Deployment modes: cloud, sovereign and hybrid
Same code, different data boundary. You choose where AI runs, per tenant and per matter.
Bring your own key (BYOK) and self-hosting
Use your own model provider account, or run the whole stack on your own infrastructure.
Data privacy and the no-training policy
Your documents are never used to train public models, and Nigerian data-protection handling under the Nigeria Data Protection Act (NDPA) 2023 is built into the platform.