A 2026 Mental Model for Generative AI in Legal Practice

As generative AI evolves, it is worth updating the cognitive framework or heuristic you use to understand and navigate this complex system (your “mental model” of generative AI). For legal practitioners, assuming all AI systems work the same way can lead to inefficiency, uneven work product, and avoidable risk. A more accurate approach is to stop thinking of AI as a monolith and instead evaluate an AI system as three layers: 1) the underlying model, 2) the tools and data it can access, and 3) the application or interface through which a human user accesses the model. By adopting this structured approach, attorneys can more predictably match the specific capabilities of an AI system to the requirements of a specific legal task, ensuring higher quality output, improved factual accuracy, and more robust risk management.

Layer 1: Underlying Model

Start by identifying the model, since it largely determines capability, speed, and baseline reliability. In practice, legal users will most often encounter three categories: general purpose or non-reasoning models, reasoning or thinking models, and fine-tuned or domain-specific models.

General-purpose models (non-reasoning) are predictive-text models. They provide rapid responses based on the pre-trained weights from their original training data. They perform well at structural tasks, formatting, and producing high-quality drafts, but carry a greater risk of hallucination for factual tasks. Examples include GPT-4o, GPT-5 non-thinking variants, Gemini 3 Flash, Claude Haiku 4.5, and Claude Sonnet 4.6 standard variants.

Reasoning models are optimized for multi-step reasoning. They take additional computing time to plan, check intermediate steps, and internally verify consistency before producing an answer, which can improve performance on complex analysis, but usually increases latency and cost. Examples of reasoning models include Gemini 3 Thinking / Pro, Claude Opus 4.6 Extended Thinking, or the GPT-5.4 Thinking / Pro.

Fine-tuned, legal domain specific models have been adapted to behave more like a legal specialist. Fine-tuning primarily affects how a model responds (style, structure, terminology, and adherence to legal drafting conventions) rather than guaranteeing factual correctness, which still depends on the inputs and any retrieval or tools provided. Examples of fine-tuned / domain-specific legal models include those packaged within legal AI platforms such as Harvey, CoCounsel (Thomson Reuters), Lexis+ AI (LexisNexis), and Vincent AI (vLex).

While the underlying model (Layer 1) can be useful in isolation (and may even be preferrable when input includes highly sensitive information, such as health information (PHI), personal data of individuals in the European Economic Area, payment card data (e.g., credit card numbers), or other highly sensitive information), Layer 2 is where AI systems can become materially more useful, accurate, and controllable in practice. Layer 2 enables the model to retrieve approved sources, run calculations, follow structured workflows, and take limited actions under defined permissions, logging, and human review.

Layer 2: Tools and Data Retrieval

On its own, a model is a closed system that relies on pre-training, along with any mid-training or fine-tuning it has received. To make outputs more accurate, up-to-date, grounded, or verifiable, many AI systems connect the model to external tools and data sources (Layer 2).

In this context, “agentic AI” does not simply refer to an underlying model. Instead, it describes a system design choice that combines an underlying model with external tools and data retrieval. In such a system, the model can plan and execute a multi-step workflow by calling tools (e.g., searching, retrieving documents, running analyses, or updating systems) and then using the results to produce the final output.

You may also see the term “harness” used for the surrounding software layer that governs tool access, manages what information is pulled into context, and adds checks before an output is delivered. The following are some examples of common tools and data retrieval patterns.

Database or Repository Retrieval (Controlled-corpus RAG). Retrieval-Augmented Generation (RAG) means the system retrieves relevant passages from a specified corpus and places them into the model’s context before it drafts an answer. In legal workflows, that corpus is often a controlled source such as Westlaw or Lexis, a document management system, a matter workspace, or a clause library. This can improve grounding and citation quality, but results still depend on what is in the corpus, how it is indexed, and whether citations/quotes are preserved. High-quality controlled-corpus RAG is useful for tasks like drafting a memo or brief section that quotes and cites to specific documents in the matter file (e.g., deposition excerpts, contracts, key emails) or assembling a first-pass clause comparison from an approved clause library.

Computational or Analysis Harness. The model is connected to a computational environment (for example, a calculator, an Excel spreadsheet, or a secure calculation engine, often Python-based) so it can run formulas instead of estimating results in plain text. This is useful for tasks like damages and interest calculations, date and deadline computations, or summarizing numeric data, and it reduces arithmetic errors when the inputs and formulas are correct.

Web Retrieval (Web RAG). The system pulls excerpts from public web sources and places them into the model’s context before it drafts an answer. This is useful for recent developments and background facts, but reliability depends on the sources retrieved and whether citations or quotes are preserved. This is useful for tasks like pulling and summarizing newly issued agency guidance or rule changes, locating a regulator’s current enforcement priorities, or compiling publicly available company background (e.g., press releases or SEC filings) for a first-pass diligence or case strategy memo, while still verifying the primary sources.

Browser Automation (Agentic Web Use). Here, the web is not just a source of text but an environment the model can operate in. The model can open a browser, run searches, navigate sites, download or upload files, and complete form-based steps, then use the results to produce the final work product. Because actions can change external systems and the record of what was done may matter, this pattern benefits from clear permissioning, audit logs, and human review. This could be useful for tasks like pulling case dockets and filings from court portals, downloading agency guidance or public records from government sites, or populating repetitive web forms (e.g., registrations or routine submissions), with attorney review of the retrieved materials and any actions taken. Because this capability is relatively new and can create real-world consequences (including erroneous filings, unintended disclosures, or incomplete records), many legal teams have not adopted these tools or are currently limiting their use to sandboxed test environments or tightly scoped pilots until controls are proven.

Action Tools (APIs and MCP). An API (application programming interface) is a standardized way for one software system to request data or trigger actions in another system, subject to configured permissions. Many agentic systems use MCP (Model Context Protocol) to package these integrations in a more standardized, governable way, so the same AI application can connect to multiple approved tools and repositories while maintaining a clearer record of tool use. This is useful for tasks like connecting an organization’s document management system and matter workspace to a model so it can pull the right documents into context, draft or revise work product, and (with appropriate permissions and human approval) save outputs back to the correct matter folder with consistent naming, tags, and audit logging.

Once you know which tools and data sources the model can touch, the next question is how you (and your organization) use, access, and govern that capability in practice. That is Layer 3: the interface or application layer.

Layer 3: Application or Interface

Consider the application or interface you use to access the AI system. This layer determines (i) what the system makes easier in day-to-day work (workflow fit), (ii) what the system can do in practice (capabilities), and (iii) what controls are in place to make it safe for the task at hand. In some interfaces, you can choose between underlying models for the same workflow (for example, toggling between a “fast” general purpose mode and a “deep thinking” or “pro” reasoning mode). In practice, most interfaces fall into the following three categories.

Web interfaces (browser-based). These are chat-style or portal-style tools accessed in a browser, including on a phone or tablet. They are quick to adopt for drafting, research, and brainstorming, and they may enable web retrieval or other tools depending on the provider and account settings. Many legal drafting tasks can be done in any interface, but browser-based tools are especially useful for quick, low-friction work (including on mobile), such as turning rough notes into a client update email or building a first-pass outline for a motion or memo between meetings.

Desktop and mobile applications. Some AI tools are delivered as dedicated software rather than purely through a browser, including desktop applications and, in some deployments, mobile applications on a phone or tablet. In legal contexts, these applications may be designed around specific workflows such as bulk document upload, clause comparison, citation-oriented research, or structured matter workspaces, and they may include firm- or department-specific guardrails. While the underlying AI tasks may be similar across interfaces, dedicated applications are often most useful when you need a structured workflow and a review-friendly user interface (UI), e.g., ingesting a set of contracts or production documents and generating a structured issues list with links back to the underlying documents.

Native integrations (in-product). Here, AI features are embedded directly into tools practitioners already use, such as word processors, email, document management systems, or e-discovery platforms. An advantage is reduced friction and better access to relevant work context, but the risk profile depends on what repositories the integration can reach, what it can write back to, and what permissions, logging, and retention controls are enabled. Many of the same tasks are possible elsewhere, but native integrations shine when the work already lives in the tool, e.g., revising a draft brief or agreement in place (tightening defined terms, headings, and argument structure) and capturing changes without exporting, copy/paste, or losing document context.

Controls and Safeguards. Regardless of the interface or application, the interface or application itself is not a reliable indicator of confidentiality or retention practices, so confirm the deployment model and terms-and-conditions before entering client or matter-sensitive information.

As a practical matter, public models and personal subscriptions (e.g., a $20-per-month consumer account) typically do not provide protections for information you input into prompts, and may allow prompt and input data to be used for product improvement or model training. However, many vendors offer higher-security deployments (often labeled “business” or “enterprise” tiers) that provide stronger commitments around data isolation, retention, logging, and training on input data.

Because these terms vary by vendor and product, attorneys should confirm the specific terms-and-conditions for the account and deployment they are using before entering client, privileged, or otherwise sensitive information. In some cases, the safest approach is to use only organization-approved AI tools whose terms have been pre-screened for appropriate uses, typically accessed by signing in with work credentials.

Applying the Mental Model. Instead of treating all AI systems as one type of tool, you can strategically select a specific AI system for a particular task by evaluating its combination of layers (Layer 1 model, Layer 2 tools/data, Layer 3 interface/controls).

This framing can help explain why two systems that look similar may provide very different output in terms of factual accuracy, currency, and source traceability. Regardless of the layer configuration, human validation remains required. Treat AI outputs as draft work product, confirm key facts against primary sources, and cite-check quotations and authorities (including dates and numbers) before relying on them. When client, privileged, or regulated information is in scope, prefer organization-approved deployments and workflows with appropriate permissions, retention settings, and audit logs.

Because the technology is changing quickly, treat AI as a living mental model and revisit it as new AI models, tool standards, and interface patterns emerge.