AI for the Legal Department: Source-backed Answers

Why lawyers need answers that are only source-backed

When AI replies without sources, the legal department doesn't get help — it gets a new risk. A mistake can make its way into a letter to a counterparty, a litigation position, or an internal policy, and then it's hard to undo. In legal work it's important not only to be "plausible" but verifiable: any claim should be openable in a document and read exactly the same way.

The most dangerous trait is a confident tone. It masks gaps: a model can mix provisions from different versions, confuse terms, "fill in" missing contract conditions, or present general advice as a definitive conclusion. An obvious error is often noticed immediately, while a confident inaccuracy is easily accepted as fact and propagated through processes.

The practical formula for "source-only" is simple: every material claim must rely on a specific document, an exact location in that document, and a verbatim quote. If no source exists or the source doesn't support the conclusion, the system must plainly state "I cannot answer" and suggest what data is missing (for example, the required contract version, addenda, or the regulation's amendment date).

Guesses are especially harmful where the cost of error is high: when reviewing contracts and SLAs, in compliance and internal policies (including sanctions and procurement rules), in labor issues and personal data handling, and in claims work and preparing litigation positions.

A simple example: an employee asks whether a contract can be terminated without penalty "by giving 10 days' notice." An AI without sources will easily answer "yes." An AI for the legal department should show the contract clause with that wording or honestly state that the text contains no such provision.

What counts as a source and what a "quote" means

For AI in a legal setting, a "source" is the primary document that allows you to verify every assertion: open the same text and see the same wording. Summaries, media articles, someone's notes or a presentation can help orient, but as evidence they are weaker: conditions, caveats and exceptions are easily lost there.

Practical rule: the reference must point to "where it is written," not "someone explained it." For laws and subordinate acts this means a specific provision (article, paragraph, subparagraph) and the edition. For contracts and internal policies — a specific document version and an exact place in the text.

A "quote" is a verifiable text fragment that can be matched against the primary source without guessing. A good quote contains context and coordinates:

• the document title (if needed — the issuing body, party, or unit)
• version details: date, number, edition, note like "as amended on ..."
• precise location: article and paragraph, or contract section and clause, or page and paragraph
• the fragment itself verbatim, not paraphrased

Versioning is a separate pain point. A law may have changed, a contract may have been amended by addenda. If the answer doesn't fix the edition, you get "correct, but not for that time."

It's important to keep two layers in mind: (1) facts from the source, and (2) the user's conclusions. AI can show a quote about a notice period or penalty amount, but a conclusion such as "this is a breach" or "recovery is possible" must be explicitly labeled as interpretation and based on the chosen norm.

Example: an employee asks whether a penalty can be charged under a contract for a delivery delay. A correct answer shows a quote of the penalty clause in the contract and a quote of the statutory provision about consequences of breach, states the document versions, and then separately formulates the conclusion: "If the delay is confirmed by acceptance certificates, then under the cited clause a penalty can be calculated by the formula ..." If any primary source is missing, no quote should be presented.

Which documents to connect and how to prepare them

The legal department should connect only materials where the primary source can be shown precisely. Typically these are regulatory acts (codes, laws, decrees), court decisions, regulator letters and clarifications, signed and template contracts, internal policies and regulations, orders and instructions, compliance standards and authority matrices. The closer a document is to the company's actual practice, the more useful the answers.

To make "source-backed answers" work reliably, bring documents into a common standard. The main idea: any quote must unambiguously point to a particular version of the text. Otherwise, checks will inevitably lead to disputes about which edition was meant.

Unified identifier and version

Create a unified identifier format. It should be short and consistent across document types: title, number, date and version. For example: "Privacy Policy, v3, order No.12 of 05.02.2025." For contracts add the type and counterparty: "Supply Agreement with Company A, No.45, 12.03.2024, edition 2." If a document changes, the new edition is a new version, not a replacement of the old.

Practical rule: AI must not "merge" different editions into one answer. Better: one document — one set of quotes. It may look less "clever," but it is verifiable.

Storage, access and logging

Set confidentiality levels and access rights from the start. Lawyers often need closed contracts, while the business must not see everything. It's useful to separate documents into at least: public, internal, confidential, strictly confidential. For each level record who can read and who can export text.

Logging is just as important: who requested, which sources were used, which fragments were quoted. This helps investigate incidents and respond to audits. Another effect: users adopt disciplined query habits faster when they know the chain "question — sources — answer" is saved.

Minimal metadata for search and audit

Minimum fields to keep with the text:

• identifier (title, number, date, version)
• document owner and responsible unit
• type (regulation, contract, policy, letter, court decision)
• confidentiality level and validity period
• source of acquisition and date of update

If these fields are filled, the no-guess policy becomes real: the model either finds an exact fragment and quotes it, or honestly reports that no suitable source exists.

The "no source — no answer" policy in plain words

The idea is simple: an internal AI for the legal department answers only what can be confirmed by a specific fragment from connected documents. If there's no confirmation, the model does not guess or fill gaps with "general experience."

Behavior rules can be captured in two points:

• If the question is settled by text in the sources, the AI gives an answer and attaches quotes.
• If the sources lack the necessary data, the AI replies "no data in sources" and asks 1–3 clarifying questions (which contract, edition, date, party, whether there are appendices or addenda).

Every material statement must be verifiable. In practice this means: next to each claim there is an internal reference identifier to the document (for example: "Supply Agreement, edition of 12.03.2025, cl. 4.2") or a clear note that nothing relevant is available in the accessible materials.

What this looks like in an answer

A good format includes a separate "Quotes" block where fragments match the primary source character-for-character (no paraphrasing) and are accompanied by exact references: document, section, clause, page (if any).

Example: an employee asks whether the contract allows unilateral termination. The AI either shows the quote from the specific termination clause, or writes: "The provided documents contain no clause on unilateral termination. Please specify whether there are addenda or a template form that was applied to this contract."

Ban on guesswork

The internal service should forbid formulations that sound confident but aren't grounded in text: "usually," "as a general rule," "most likely," "practice shows." Such phrases are acceptable only in two cases: they appear verbatim in a quoted document or they are marked as a hypothesis and immediately accompanied by a request for missing sources.

Output format: how to show quotes and references

A lawyer needs not only an answer but a quick way to verify it. So the interface should fix a consistent format: first a brief conclusion, then supporting quotes, and only after that — the list of sources to check.

A practical template for answers:

• Conclusion: 1–3 sentences addressing the core question (no new facts not present in sources).
• Quotes: 2–4 text fragments, each shown separately with a citation of where it comes from.
• Sources: a list of documents so they can be opened and checked in full.

A quote should be minimal: only the piece that proves the specific point. If two conditions are needed for the conclusion (for example, notice period and method of delivery), show two short quotes rather than one long chunk.

Do not combine different documents into one quote. One quote always belongs to one primary source. Otherwise verification is lost: we cannot tell which part came from which document and where the model's interpretation begins.

To make a reference truly verifiable, a person should be able to open the exact place in the document, not search for it manually. Therefore include with each quote:

• document title and version (or approval date)
• structural marker: article, clause, subclause, appendix
• page (for PDFs) or section number (for HTML/Word)
• internal file identifier in the system (if available)

Example: a question about unilateral termination. In the conclusion the AI writes: "Yes, in case of delivery delay over 10 days, with 5 working days' notice." Then it provides two quotes: one from the contract about delay and another about the notice procedure. In the sources block — the same contract with date and clause number so a lawyer can open the exact fragment in seconds.

Step-by-step setup of an internal source-backed service

To make answers suitable for legal work you must configure not just a "chat" but behavior rules: the model either shows verifiable quotes or honestly says there is no data. Make these rules requirements for the service, not just user guidance.

Minimal configuration that actually works

To start, a simple five-step process is enough.

First, compile a list of allowed sources and assign content owners: who updates contract templates, policies, authority matrices, regulations, explanatory letters. Then define the proof format in answers: document name, version or date, section or clause and an exact quote in quotation marks (no paraphrasing when precise wording matters). Enable a clarification question mode for vague queries: contract type, party, edition date, governing law, and what counts as a "penalty" (interest or liquidated damages).

Next, lock in the rule "every claim is backed by a source": if a phrase has no support in the database, it cannot be presented as fact. Then run the service on real legal cases and write a short instruction: what can be asked, what cannot, and how to verify quotes.

How it looks in a live query

Example: an employee writes "What liability do we have for delivery delays?" The service first clarifies which template and edition apply. Then it answers only according to the chosen document, shows 1–2 quotes from the relevant clause and adds a brief plain-language explanation.

If the connected sources lack a liability clause or the edition doesn't match, the correct reply is: "The available documents contain no clause confirming the amount or type of liability. Please specify the template or upload the current edition." This useful "error" prevents guesswork.

Common mistakes and pitfalls during rollout

A common problem is: "sources exist," but the answer is still not verifiable. Usually the issue is not the model but how documents, search and issuance rules are organized.

First pitfall — source substitution. The service shows a link to a document, but the quote is taken from another place or paraphrased. A lawyer sees "document support" and trusts it, while in fact there is no proof. Fix: require each quote to be verbatim and tied to a concrete fragment (section, clause, page, version).

Second typical error — mixing editions. The model finds a familiar provision in an old file or archived edition and cites it as current. Therefore the quote must include the edition date and the answer must explicitly state which version was used.

Third pitfall — pseudo-disclaimers instead of quality control. Phrases like "may be incorrect" do not protect compliance processes because they don't stop the service from speaking when data is missing.

Fourth — overly general answers. If a conclusion cannot be broken into 2–3 verifiable fragments, it's usually useless for a lawyer.

Finally, context is often ignored: jurisdiction, date, subject matter. For example, for a 2024 delivery the service cites a 2021 template and mixes it with a law from another country.

Check rollout by these signs:

• Answers contain verbatim quotes that match the source text.
• The edition (version date) is indicated and matches the task.
• When sources are missing the service says "no answer" instead of reasoning.
• Conclusions are supported by specific clauses, not general wording.
• The query context is fixed in the request (country, date, deal type).

If an integrator builds the service, lock these rules as mandatory quality requirements, not optional model preferences.

Disclaimer templates without empty wording

A disclaimer isn't for "avoiding responsibility" but to honestly explain the service mode: which sources it relies on, where it may err, and what a lawyer should do next. If wording doesn't change user behavior, it's useless.

Where to place a disclaimer depends on risk and frequency. For a daily service a short line in the header is enough. For scenarios where someone might copy an answer into an external letter, put a reminder at the bottom of the reply or before export. For rules that must be set once, a modal on first login is convenient.

Useful formulations are specific: "the answer is formed based on the documents listed below in 'Quotes and Documents'," "if sources are missing the service provides no answer," "we show extracts, but the legal decision is taken by an employee." Harmful formulations create false security: "we do not guarantee accuracy," "information is for reference only" without indicating what to do next.

Important: a disclaimer does not replace sources and quotes, does not cure model guesswork, and does not override access restrictions. If a user lacks rights to a document, the service must not show the text or fragments.

Below are templates for different modes (these can be inserted as ready blocks in the interface):

Mode: reference
The answer is based on the sources shown below in "Quotes and Documents." If sources are missing, no answer is provided. Check the document date and edition before applying.

Mode: draft (for lawyer revision)
A draft has been generated based on the indicated sources. The text requires review and edits by a lawyer before sending to a counterparty or regulator. Use the quotes below to support formulations.

Mode: database search
Results are matches in documents. Click a document and check the fragment in context. The service does not draw conclusions if there is no direct basis in the found materials.

Mode: document summary
The summary reflects the selected document and may skip details. For disputed points rely on the specific quotes and section numbers. If the document is incomplete or missing appendices, the summary may be incomplete.

Example: if an employee asks "can we terminate the contract without penalty", the draft-mode disclaimer should prompt them not to copy the answer into a message but to open the quotes on termination conditions and verify the contract edition and appendices.

Practical example: an answer on a contract with verifiable quotes

The sales team asks: "Under the supply contract with the client, can we move the shipment date without a penalty if the delay was caused by external logistics restrictions? Which exceptions apply?" This is a typical request where a "rough" answer is dangerous: formulations about notice, agreement and force majeure matter.

Before answering, the AI does not draw conclusions. It clarifies information without which the answer cannot be tied to the contract text:

• which contract version was signed (date, number, file)
• what exactly was breached: delivery date, shipment date, or commissioning date
• whether there is written agreement on the changed date (correspondence, addendum)
• what event is considered the cause of delay and when it began

After clarifications the result must be short and verifiable: first the conclusion, then 2–3 exact quotes, then the list of sources.

Sample conclusion: the default penalty applies for delay, but it may not apply if (a) the term was changed in writing or (b) the delay falls under force majeure and the notification requirements were met.

Sample quotes:

“Supplier shall pay liquidated damages of 0.1% of the price of the undelivered goods for each day of delay” (Supply Agreement No. 17/24 dated 12.03.2024, cl. 6.3).

“Changes to delivery dates are permitted only by written agreement of the Parties” (ibid., cl. 3.4).

“A Party that finds itself in force majeure circumstances shall notify the other Party within 5 (five) business days” (ibid., cl. 9.2).

To make the result auditable, record the response together with metadata:

• Source: “Supply Agreement No. 17/24 dated 12.03.2024 (signed version)”, sections 3, 6, 9
• File version: name or ID in storage, checksum (hash), upload date
• Metadata: timestamp of the answer, who requested it, ticket or request ID

Quick checklist before launch and for audits

If you deploy AI for the legal department, agree on simple quality control rules from the start. Then verification won't turn into a debate about "does it look true" but will reduce to whether each phrase can be confirmed.

Before launch (readiness check)

Run 10–20 typical legal questions: contracts, policies, procurement requirements, internal rules.

• For each claim in an answer there is a verbatim quote or precise reference: document title, section or clause, page or anchor in the repository.
• The source date, version and status (draft, approved, repealed) are shown. If multiple versions exist, the chosen one is visible and is current.
• Facts from the source are separated from conclusions: where the quote ends and interpretation begins.
• Logging is configured: saved are the query, the set of found sources, shown quotes and the final answer so the chain can be reconstructed.
• The scenario "no source" is clear: the service asks to specify the document, period and context or offers escalation to the responsible person (for example, compliance or the document owner).

During audits (what to check regularly)

Audit by sampling: random requests over a period plus several critical topics.

• Do the quotes match the primary source word-for-word, without edits or stitchings that change meaning?
• Are there guesses: answers presented as fact but based only on general knowledge, not on a document?
• Is version control broken: after updating a policy or template the system still quotes the old edition?
• Are there gaps in the database: repeated "no source" responses on the same topic indicate missing or poorly tagged documents?
• Are there clear actions after findings: who updates the source, who approves the change, and how is it verified that the error won't recur?

A small practical test: take one internal document (e.g., a contract template or a regulation) and ask the system 5 questions so any lawyer can open the relevant clause and immediately confirm the answer.

Next steps: how to implement this in the company

Start small, otherwise the project will spread out. For a pilot choose 1–2 processes where "source-only answers" will have an effect in the first month. Common choices are answers for standard contracts (supply, services, NDA) and internal policies (procurement, gifts, conflicts of interest). Such a pilot is easier to measure: fewer disputes, faster search, less manual routine.

Then assign roles and boundaries of responsibility. Failures usually stem not from the model but from document ownership and update rules. The document owner (often a lawyer) is responsible for accuracy and contested wording. InfoSec sets access levels, storage and logging requirements. IT handles integrations, accounts, support and change control. Compliance or risk defines where "no source — no answer" is mandatory and where a clarification mode is allowed.

Plan storage and access before building the UI. Legal data typically needs an in-perimeter option, role-based models (by unit, project, document category) and clear confidentiality rules. Decide in advance what materials cannot be uploaded and how to handle "mixed" documents that include personal data or trade secrets.

Integrator help is usually needed at the start of operations: connecting storage, configuring infrastructure, backups, monitoring answer quality and incidents, and user support. An internal "AI for legal" service rapidly becomes a product that needs an owner and operations, not a one-time setup.

If the company lacks resources for the full cycle, GSE.kz can cover parts of the task as a systems integrator: select and deploy AI and data-center infrastructure for an internal service, set up a secure perimeter and provide 24/7 support. This is suitable when security requirements are strict and users expect stable operation without manual workarounds.