A legal AI router directs each request to a suitable model tier. Layer makes that choice inspectable; the professional remains responsible for checking the response and disclosed data.
A router does not draft or advise. It answers a prior question: what model capability does this request need? The answer affects cost, response time and sometimes the strength of the resulting reasoning.
What is a legal AI router?
In a law firm or legal department, AI tasks differ. A greeting, short rewrite or deadline reminder does not need the same capability as a cassation memorandum, appeal submissions or an analysis under Rome I / Brussels I bis.
Without a router, organisations often default to the most powerful model—or a single “approved” model that may be too weak. In either case, the choice is no longer guided by task difficulty.
A legal AI router examines the request and assigns it to a tier : lightweight, intermediate or frontier. It does not necessarily select a provider; it indicates the level of reasoning required. The professional, or the surrounding tool, retains control over the actual mapping to Mistral, Claude, GPT, a local model or another option.
Routing does not automate advice. It avoids treating every prompt as though it carried the same legal weight.
What changes in practice
First, cost governance. AI budgets are often consumed by calls disproportionate to the task's actual difficulty. A router reserves frontier models for work that justifies them, without requiring the professional to choose manually for every prompt.
Second, continuity within a matter. The same professional moves between small questions and substantial analysis. Adapting model capability reduces the gap between tools that are too expensive for simple requests and too weak for complex ones—a gap that encourages unsanctioned consumer chat use.
Finally, clearer internal policies. Instead of a fixed list of approved models, the organisation can define usage tiers and apply them consistently.
Legal implications
A router removes no obligations. It shifts some and makes others more visible.
Professional secrecy and confidentiality. Choosing a lighter model does not itself reduce the risk associated with disclosed data. What leaves the computer, or stays on it, depends on the overall architecture: local pseudonymisation, the BYOK scope and hosting policies. The router adds to that chain rather than replacing it. In Lexanon, it comes after document pseudonymisation.
Professional responsibility. The lawyer or legal professional remains responsible for the advice provided. Under-routing—sending a complex question to an insufficient model—can weaken the reasoning support. Systematic over-routing does not remove the need for critical review either. A router allocates resources; it does not guarantee correctness.
Traceability and governance. Once a system decides which engine processes a prompt, audit questions arise: which criteria, what error margin and which corpus? Publishing the router as open source allows a firm, IT department or DPO to inspect its logic before authorising it, rather than accepting a contractual black box.
Proportionality and minimisation. Data protection law calls for processing only what is necessary. By operational analogy, using frontier capability for every tiny prompt is neither economically nor organisationally proportionate. Routing formalises this proportionality in model use without replacing the GDPR rules applying to the data itself.
What Lexanon is making open
Layer is released under Apache 2.0 on GitHub. The repository can be reviewed, reused or integrated outside Lexanon. In the product, the router complements the Layer interface : local pseudonymisation, model choice and professional tools.
Open code is not a secondary marketing gesture. It meets a requirement specific to law: whatever directs the processing of a professional request must be understandable, open to discussion and, where appropriate, rejected.
Evaluate a legal AI router on your own tasks
Before deployment, distinguish request difficulty from information sensitivity. A simple question may reveal an identity, while complex reasoning can be requested without any personal data. These dimensions require different decisions. Routing handles model selection; the firm's policy determines acceptable data and authorised destinations.
Build a representative test set
Choose everyday requests: rephrase a letter, compare two clause versions, find information in a document or prepare an argument outline. Add difficult, incomplete and ambiguous cases. For each example, record the expected result and errors that would make the answer unusable. Use fictional files or documents prepared for the trial, rather than sending client material without prior review.
Keep some examples separate from tuning. This avoids claiming improvement based only on the requests used to adjust the router. The test should remain useful for future tasks rather than merely reproducing a demonstration. Document model versions, parameters and selection rules so that two trials can be compared.
Compare total cost and errors
Compare routing against an explicit baseline, such as a single model chosen by the firm. Measure call costs, retries, response time and review time. A cheaper answer requiring lengthy corrections may cost more overall. Conversely, a small task correctly handled by a lightweight model can avoid unnecessary expense.
Classify under-routing and over-routing errors separately. In the first case, the chosen model lacks capability. In the second, the task uses excessive capability. Their consequences differ: a reasoning error on an important question deserves more attention than an occasional extra cost. The protocol should reflect the firm's priorities.
Plan retries and model changes
Decide in advance what to do when a response is uncertain, incomplete or contradicted by a document. The professional must be able to retry, choose another model or return to manual work. This recovery option belongs in the workflow and must not depend on implicit trust in the initial classification.
A provider, model or price change may alter routing's value. Rerun the same test set and compare results before expanding the configuration. Keep useful observations without unnecessarily storing sensitive case content. The aim is to understand decisions and errors, not create another copy of every processed document.
In Lexanon: prepare documents before choosing a model
The local document processing and routing address two stages of the same workflow. The first prepares what will be sent; the second helps choose processing capability. Also check information added to the question: a name repeated in the prompt can bypass the work done on documents.
Benchmark results describe a particular corpus and configuration. They do not guarantee cost or quality for every firm. Ask which examples were tested, which errors occurred and how results change on your own tasks. That comparison determines whether routing belongs in your organisation.
To distinguish pseudonymisation from anonymisation, see the CNIL factsheet and the GDPR, Article 4(5) and Recital 26. These references explain data processing; they do not certify any product.
This article provides general information and is not personalised legal advice. Checks must be adapted to the matter and its recipient.
Practical questions
What does a legal AI router do?
A legal AI router directs a request to a model tier suited to its difficulty. It helps allocate cost and computing time across uses. It does not itself provide advice or remove the need to check responses.
Does a legal AI router protect personal data?
Routing selects processing capability rather than confidentiality. Protection depends on the content sent, where processing runs and authorised access. Local document preparation can reduce exposure, but the professional must also review prompts and responses.
How should you evaluate Layer before using it in a law firm?
Prepare representative requests with an expected result for each task. Compare selected models, cost, response time and routing errors. Include complex and ambiguous cases. Repeat the evaluation when models or configuration change.
Does open-source code guarantee routing quality?
Open code lets you inspect and adapt the router. It does not guarantee accuracy on every matter. Quality depends on evaluation examples, the models used and the selected thresholds. Human review and a recovery mechanism remain necessary in practice.
Sources
- Lexanon-legaltech, Layer — github.com/Lexanon-legaltech/Layer (Apache 2.0).
-
Lexanon, A/B router benchmark on a corpus of French legal prompts (
layer_router_ab_20260727_223329) — indicative cost and quality with and without routing. - Lexanon, Why is legal AI adoption still limited? — separating data protection from model selection.