// wiki · reference · September 2026
AI for lawyers: tasks, agents, chatbots
Lecture material from the professional development course “Digital Law — 2026” (topic 8). Rules are stated as of September 2026; assessing a specific situation depends on its circumstances.
The short answer
AI for a lawyer is a preparation tool, not a decision-maker. The model predicts text; accuracy is established by checking the primary source. Routine — search, transcripts, digests, drafts, first passes through case files — can be delegated to the machine behind gates; the decision, the signature and the outward position stay with the lawyer.
How a language model works
The model predicts the next word from statistics over billions of texts. A plausible text may be untrue: where data runs out, the model completes plausibly — it has no internal “I don’t know”. A confident tone says nothing about accuracy; weak spots are rare practice and fresh registers. Hence the working rule: every AI output is a hypothesis until checked against a source.
Tasks and technologies
- speech recognition — transcripts of hearings, interviews, calls;
- classification — sorting requests and contracts by type;
- data extraction — parties, amounts, deadlines, numbers from a contract portfolio;
- summarisation — digests of case files, practice reviews;
- generation — drafts of letters, positions, minutes;
- semantic search — knowledge base, case law, data room.
RAG: a model with a library
In a RAG (retrieval-augmented generation) setup the model answers not “from its head” but from retrieved fragments of your documents: query → search over the base → answer → link to the source. This gives freshness (the model was trained “then”, the base is “today”) and verifiability. Hallucination is possible here too — links are still checked, and answer quality rests on the completeness of the knowledge base.
A chatbot answers — an agent acts
For a chatbot the cost of an error is a wrong answer; for an agent that performs steps itself and uses tools it is a wrong action. The distinction is legal, not technical. An agent needs four gates: a list of permitted actions (everything else prohibited by default), minimal permissions, a spending cap, an action log. Critical steps — under human confirmation. An agent must not: send payments or documents outward, communicate externally on the firm’s behalf, access sensitive data without de-identification, or make final decisions.
The boundary: 2026 practice
- No. А27-7831/2025 — 50,000 ₽ for citations of non-existent judicial acts; the reference to AI did not mitigate;
- Case No. А71-11377/2025 — 5,000 ₽ from the client: none of the 12 practice citations held up;
- № 02-1545/2026 — dismissal for uploading reports to a public AI service;
- № 22-1201/2026 — an AI opinion does not replace an expert’s opinion (art. 74 of the Criminal Procedure Code);
- item 42 of Supreme Court Plenum resolution No. 15 of 21.05.2026 — facts obtained with the help of AI must be disclosed to the court.
The same story internationally: Mata v. Avianca (sanctions on a lawyer for invented precedents), Ayinde v. Haringey (the court accepted an apology for an AI text filed without proofreading), Moffatt v. Air Canada (costs awarded against the company whose chatbot invented tariffs). More in “Court practice on AI in Russia” and “AI at work: what an employee may do”.
A department chatbot without programming
A bot covers: questions about policies and regulations, request status, access to the knowledge base, intake and routing of requests, onboarding. It does not cover: advice and legal positions, external communications, decisions on deals and disputes.
Four ways to build without code: a bot builder (scenario-based, data stays with the platform) → an assistant from a model provider (assembled in an evening — check the data shelf and the licence) → a corporate RAG platform (knowledge base, roles, log, source links) → your own stack (a local model and an agent over your base — full control, skills required). A department’s typical path: pilot on a vendor assistant → platform → own stack when the volume of sensitive data makes the cloud unacceptable.
Three data shelves
- public — statutes, case law, publications: process anywhere;
- de-identifiable — to the cloud after stripping identifiers; a “de-identified” contract is re-identified by amounts, deadlines and structure — clean those too;
- sensitive — deal data, personal data, secrets: local models only, data never leaves the perimeter.
The shelf is decided before choosing a tool, not after a leak.
Four questions for a vendor
- where our data is physically processed;
- whether the service trains on our data and who else can see them;
- what is in the log: who, when, requested what;
- what happens on an incident and how data is returned or deleted.
The absence of a clear answer is itself an answer: the service may be given only data from the first two shelves.
Where to start
A task + a data shelf + an internal knowledge base. A pilot on a vendor assistant, testing colleagues’ demand, then a platform. Automation changes how work is done, not who signs.