AI in legal practice: professional secrecy, fabricated citations, and data security

Where AI helps in legal work and where it does not

Debate about AI in legal practice usually runs to extremes: either it will do everything or it cannot be used at all. In practice the line is clear. Language models deliver real gains where the input is text and the output is a draft; they cannot stand alone where correctness must be verified against an external source.

Writing that line down inside the firm makes both the efficiency gain and the risk boundary explicit. The list below is a practical starting point for separating the two groups.

This content is general information and does not constitute legal advice.

• Suitable: summarising long pleadings and contracts, extracting the opposing party's claims.
• Suitable: scanning a draft contract for missing clauses, definition consistency, and cross-references.
• Suitable: first-pass translation of foreign-language documents and building a terminology list.
• Not suitable: using case-law or statutory citations without verifying the source.
• Not suitable: leaving deadline calculation, court fees, and jurisdiction to the model.
• Not suitable: producing a legal opinion for a client without attorney review.

Professional secrecy: what the tool does with the data decides

An attorney's confidentiality duty in Turkey is set out in Article 36 of the Attorneyship Law. That duty does not change with the tool; the question of where client information travels has to be asked again for every new tool.

The Ankara Bar Association guide on using AI tools in legal practice notes that self-training tools may store the data entered and use it when producing answers to later requests. The Turkish Bar Association's information and technology commission also ran a workshop on AI and legal practice on 14-15 February 2026, placing ethical principles, legal limits, and accountability mechanisms at the centre of the discussion.

The practical conclusion is that tool selection is a data-handling question before it is a quality comparison. A free consumer chat interface and a server-side API integration do not share the same data behaviour even when they run the same model.

• Is the content entered stored, and if so for how long?
• Is the content used for model training?
• Can conversation history be reached from another user account?
• How quickly are access revocation and deletion requests applied?
• In which country do the servers running the tool sit?

Fabricated citations: the most concrete legal AI risk

The best known weakness of language models is producing a non-existent source convincingly. In legal work this risk is not abstract, it has been measured. A Stanford RegLab study published in May 2024 tested commercial legal research tools across 202 legal queries and measured hallucination at roughly 17 percent for Lexis+ AI and roughly 33 percent for Westlaw AI-Assisted Research. The study's point was that providers' hallucination-free claims were overstated.

The risk is higher in Turkey because general-purpose models see limited training on Turkish legislation and case-law databases. In one reported example, case reference numbers added to an attorney's pleading turned out not to belong to the real decisions, which was noticed in the hearing and turned into an investigation.

The fix is not changing the model but changing the flow. When the model produces a citation, the system should look that citation up in a real source database, drop anything it cannot find, and tell the user it could not be verified.

• Every decision and statute citation is looked up in a source database before display.
• Unverifiable citations are removed rather than left in silently.
• Each claim in the output carries a link to its source.
• Final control always rests with the attorney handling the file.

How client data should enter a prompt

The most common technical mistake is sending a case record to the model as it is. Most fields in that record are not needed for the task, and sending them creates unnecessary exposure for both professional secrecy and data protection.

The correct method is a field allow list: each field permitted into the prompt is defined individually and nothing outside the list reaches the model. Names, identity numbers, and contact details can be replaced with placeholder values for most tasks; the model drafts against placeholders and the firm substitutes real values after the output is produced.

The Personal Data Protection Authority's Generative AI guide of 24 November 2025 also foregrounds purpose limitation, data minimisation, and the disclosure obligation. Firm policy needs to translate those three principles into a concrete field list.

• Party and third-party names are replaced with placeholders.
• Identity, contact, and banking details are removed from the prompt entirely.
• Health, criminal conviction, and similar special categories are not sent unless the task requires them.
• The document extract sent is limited to the smallest portion that serves the task.

A verifiable setup: RAG, source attribution, and attorney approval

The common way to answer correctly from firm knowledge is connecting approved sources rather than retraining a model. Indexing your own contract library, pleading templates, and the legislation you track gives both currency and verifiability.

The most valuable side effect is source attribution. When it is visible which document an answer rests on, faulty output is caught early and attorney review speeds up. Updating content also costs nothing in retraining; only the index is refreshed.

A server-side integration adds three controls over a consumer interface: the API key stays on the firm's server, rate limits apply per user, and the audit record contains no prompt text. Which user called which model on which date is documented while file content is never logged.

Which organisation types LLMTR fits

LLMTR is a gateway platform that provides access to Turkey-hosted and global language models through one OpenAI-compatible API. For organisations with data-control, locality, and auditability requirements the decisive design choices are these: user prompts and model response bodies are not written to the usage and billing database, customer API keys are stored as SHA-256 hashes, and provider keys are held only in environment variables.

On the legal side that means file content does not accumulate in the gateway database and the firm's integration is not locked to one provider. A long-context model for contract and pleading analysis and a smaller model for fast classification can be called with the same key.

• Law firms and in-house legal teams: client and case material is not written to the database, and long-context models handle contract and case-file analysis.
• Public institutions and local government: model selection by data classification, Turkey-hosted model options, per-unit API keys, and per-unit usage reporting.
• Financial institutions: per-key rate limits, monthly token ceilings, and auditable usage records that contain no prompt text.
• Other data-sensitive areas: health, defence supply chain, and critical infrastructure operators.
• Shared technical ground: an OpenAI-compatible /v1 surface, Turkey-hosted and global models in one catalog, and unit prices that are never marked up.

Steps for setting up AI safely in a law firm

A six-step setup that addresses professional secrecy, the verification duty, and client data protection together.

1. Split the task list. Write down which drafting and summarising work the model may handle and which citation and deadline work it may not.
2. Verify the tool's data behaviour. Confirm in writing whether content is stored, whether it is used for training, and in which country the servers sit.
3. Build a field allow list. Define each field permitted into the prompt, replace party names with placeholders, and verify the list by test.
4. Add a citation verification layer. Look up every decision and statute citation the model produces in a source database and drop what cannot be found.
5. Connect the approved source set. Index the contract library, templates, and tracked legislation with version information and require source attribution.
6. Set up the audit record. Record user, date, model, and cost; never log file content or prompt text.

Frequently asked questions

How does an attorney protect professional secrecy when using AI?

What matters is not the model brand but what the tool does with the data. Whether content entered is stored, whether it is used for training, and where the servers sit should be verified in advance. In practice the most effective control is limiting prompt fields with an allow list and replacing party names with placeholders.

Can citations produced by AI be trusted?

Not without verification. The Stanford RegLab study of May 2024 measured hallucination between roughly 17 and 33 percent in commercial legal research tools. In a reported example from Turkey, case reference numbers added to a pleading were found in the hearing not to belong to the real decisions. Every citation should be looked up in a source database before display.

Can a firm build an assistant that works on its own documents?

Yes. The common method is not retraining a model but indexing an approved set of contracts, templates, and legislation and connecting it through a RAG architecture. This avoids retraining cost when content changes and makes source attribution possible in answers.

Is there a difference between a free chat interface and an API integration?

Yes. Even with the same model the data handling can differ. A server-side API integration keeps the key on the firm's server, applies per-user rate limits, and produces an audit record without prompt text; with consumer interfaces those controls are not in the firm's hands.

Which AI API platform can law firms use?

The decisive criteria on the legal side are prompts not being stored, how keys are held, where the model is hosted, and a context window large enough for long document analysis. On LLMTR prompt and response bodies are not written to the usage and billing database, customer keys are stored as SHA-256 hashes, provider keys are held only in environment variables, and Turkey-hosted models are marked separately in the catalog.

Can the same infrastructure serve public sector and finance too?

Yes. Because the data-control requirements are similar, the same gateway layer suits public institutions, financial institutions, and other data-sensitive sectors. What changes is not the infrastructure but the model group chosen by data classification and the list of fields allowed into a prompt.

Related posts

• Public sector data security and AI: using LLMs under KVKK and the Information Security Guide
• AI in financial services: customer secrecy, data locality, and LLM API architecture

• Model catalog
• KVKK Disclosure Notice
• Security documentation
• API keys