Building compliant software in legal technology

Software for lawyers carries a risk that software for almost anyone else does not. Build a tool that helps a person do something a court would call practicing law, and the product itself, alongside the vendor's marketing, can become the subject of an unauthorized practice of law complaint. Get a confidentiality control wrong, and you have made it harder for a lawyer using your product to meet a duty attached to their license. Get retention wrong, and you have built the thing a court sanctions your customer for when a lawsuit lands. None of that shows up in a typical software requirements document, because none of it comes from a product manager. It comes from the rules governing lawyers, which reach into your code whether or not anyone told you so.

This guide is written for the team building the product, not for the lawyer using it. It covers four areas: where the line between "legal software" and "practicing law" actually sits, what the ethics rules that bind every lawyer using your tool require of the tool itself, what federal discovery rules mean for how your product stores and deletes data, and how the AI features on your roadmap change the confidentiality picture. Each area gets a page of its own, because each one is a different kind of obligation with a different kind of check.

What sets legal technology apart

Most regulated verticals govern what a business must do with its customers' information. Legal technology adds a second layer: it governs what the product itself is allowed to do, because a legal document generator that gives specific advice to a specific person's specific situation is edging toward legal practice, a status reserved for licensed attorneys in every state. That distinction, between a tool that helps someone and a tool that acts as their lawyer, is the subject of why legal software needs a compliance-first build, the starting point for this guide.

The result is that a legal software team has to answer a question most product teams never face at all. Beyond "is this feature good" sits "is this feature something only a licensed attorney is allowed to do." That second question does not have a fixed answer that applies everywhere the product is sold, and it can shift as a feature grows from a narrow, well-scoped starting point into something broader over several quarters of ordinary product work, with nobody deciding at any single point to cross a line. The rest of this guide treats that shift as a design and engineering problem with a real answer, alongside the legal question counsel resolves.

The line itself is not fixed nationally. There is no single federal statute defining the unauthorized practice of law, often shortened to UPL: the unlicensed provision of legal advice or services. Each of the fifty states writes and enforces its own definition, which the National Center for State Courts and the American Bar Association describe as a real varied continuum of scope and clarity across jurisdictions [1]. Two states have moved recently and specifically because of software. Colorado adopted a nonprosecution policy in 2024 and 2025 that deprioritizes UPL enforcement against developers of legal-help technology tools, on the reasoning that most of those developers are not lawyers and still deliver something a person needed [2]. Texas amended its own UPL statute to exclude computer software from the definition outright, on the condition that the product clearly discloses it is not a substitute for a lawyer [3]. Those two moves point at where the rest of the country is likely heading, but they are not the rule everywhere yet, and a product that ships nationally has to assume the stricter states are still watching. Avoiding unauthorized practice of law in product design covers what that means for how a product is built, which reaches further than the wording of a disclaimer.

The confidentiality duty that becomes your product's job

Every lawyer using your software is bound by a duty of confidentiality that predates computers and now has to be satisfied by them. ABA Model Rule 1.6(c) requires a lawyer to make reasonable efforts to prevent the inadvertent or unauthorized disclosure of, or unauthorized access to, information relating to the representation of a client [4]. That duty extends explicitly to digital data: emails, electronic documents, and the metadata attached to them.

Here is the part that matters for a builder rather than a lawyer: the lawyer cannot make those reasonable efforts alone. If your product stores client documents, drafts client communications, or processes case data, the lawyer's ethical duty is only as good as your product's actual controls. A permission model that lets one attorney in a firm see another's client files, an export feature with no audit trail, or a support tool that gives your own staff standing access to client data are gaps in a licensed professional's ethical compliance, created by your code rather than their conduct. ABA Rule 1.6 confidentiality controls for legal software works through what a product actually needs to hold up its end of that duty.

The rule's own language covers "reasonable efforts," which is a standard rather than a fixed checklist, and a standard is worth taking seriously precisely because it resists being satisfied by a single feature. A firm cannot point at one encryption setting and call the duty met. What they can point to, if it exists, is a coherent account of how access is limited, how it is logged, how a support engineer's standing access is bounded and recorded, and how an export leaves the system without carrying more than the user intended to share. Building a product that can produce that account on request is a different, harder task than building one that merely encrypts data at rest, and it is the task this guide is actually about.

Sitting next to Rule 1.6 is a second, newer obligation: the duty of technology competence. Comment 18 to ABA Model Rule 1.1 requires a lawyer to keep abreast of the benefits and risks associated with relevant technology, and as of 2026, forty states have adopted a version of that standard [5]. That duty does not stop at the lawyer's own device. It extends to vetting the vendors a firm relies on, which means a firm adopting your product is expected to have asked real questions about how it handles client data before signing anything, and to be able to show that they asked. Technology competence duty and what it means for vendors covers what a vendor should be prepared to answer, and what that implies for how the product is documented.

Discovery obligations reach your data model

A large share of legal software exists to manage documents that will eventually be produced in litigation, which pulls a different body of rules into scope: the Federal Rules of Civil Procedure governing discovery. Rule 26 sets the general standard that a party must produce data that is relevant and proportional to a case, and relieves a party of the duty to produce electronically stored information, generally shortened to ESI, that is not reasonably accessible because of undue burden or cost. Rule 34 governs the mechanics of a document request, requiring the responding party to answer within 30 days by producing the material or objecting with specificity. Rule 37 is the one with teeth: it lets a federal court sanction a party for failing to preserve ESI it had a duty to preserve, a failure called spoliation, and the sanctions available include an instruction that lets the jury assume the missing evidence was unfavorable to the party that lost it.

None of those rules is about your software directly. They are about your customer's legal obligations, and your software becomes the thing that determines whether your customer can meet them. A retention policy that is well defined and consistently applied is one of the strongest defenses against a Rule 37(e) sanction, because it shows the loss of a record was routine business practice rather than a decision to make evidence disappear. A product with no retention model, or with an inconsistent one where some users can silently delete records that others cannot, puts every one of its customers at risk of that sanction the next time they are sued. E-discovery and retention requirements under FRCP covers what that means for a document management or case management product's schema and deletion behavior.

Why a working product can still be non-compliant

The pattern we see most often in legal technology is a product that works exactly as its team designed it, reviewed against that same design, and passed every review with nothing found, while a real gap sits untouched the entire time. That is a structural result of how software review works: a team can only check a system against the design they wrote down, and the gaps that matter most are the ones nobody wrote down in the first place.

In legal software specifically, this shows up in a handful of recurring shapes. A permission model built to separate clients within a firm, reviewed carefully, and never checked against a support tool added six months later that gives customer-facing staff standing access to every account for troubleshooting. A retention policy documented in a compliance handbook, enforced faithfully by the primary application's deletion job, and never wired into the backup system that keeps its own independent copy on its own schedule. A drafting assistant added because users asked for it, evaluated entirely on whether its suggestions were good, with nobody in the room asking whether its underlying model pools examples across every customer's confidential documents. None of these is a mistake anyone would defend if you described it to them directly. Each one is invisible from inside a review that only asks whether the system does what it was built to do.

This is also why a self-review, however careful, tends to find very little. Reviewing a system against its own design confirms the design was followed. It does not surface an obligation the design never accounted for, because there is nothing in that process that would ever raise the obligation. The only way past this is to start from the obligation, not from the code, which is the method covered in compliance gaps in legal software.

Turning the obligations above into checks

Everything above reads as legal text, which is exactly the problem this site exists to solve for regulated software generally: a rule written in operative language is close to a specification, and a specification can be tested. "The audit trail must show who accessed which client's file" is an assertion with a subject, an action, and an observable result, so it can fail a build the same way a broken login flow can.

That reframing matters more in legal technology than in most verticals, because the cost of writing several hundred checks by hand used to lose every prioritization meeting to a feature a client could see, exactly as it does everywhere else. What changed is the cost. When code is close to free to generate, the checks that prove a confidentiality boundary holds, that an audit trail names the actor rather than the account, that a retention rule fires consistently across every account type, become an afternoon of specification work rather than a quarter nobody approved. Veracode's spring 2026 testing across more than 150 models and 80 coding tasks found that only 55 percent of AI generations produced secure code, while syntax correctness ran above 95 percent [6], which is the honest reason this only works with independent verification. A model that writes a confidentiality feature and grades its own work is the same risk as a junior engineer reviewing their own pull request. Evals as legal compliance evidence covers what a check suite derived from these obligations looks like, and why the run history is worth more to a firm's own risk review than a policy document ever was.

AI drafting features carry the confidentiality question forward

If your product includes an AI feature that drafts documents, summarizes filings, or answers questions from case data, the confidentiality duty above does not go away. It gets harder to hold, because a feature that retains or reuses input across sessions poses a heightened confidentiality risk compared to older technology: a prompt built from one client's facts can, if the feature is built carelessly, surface in a session about a different client's matter [7]. That risk follows directly from how many AI features are built by default, where a model learns from every customer's interactions to improve suggestions for the next one, with no boundary drawn at the level of an individual client's matter. AI drafting features and confidentiality risk covers what isolation actually has to look like, and connects to the broader question of what it means to hold an AI feature accountable, covered in our regulated industries guide and our guide on taking AI-generated code to production.

The same accountability question that applies to AI-generated code applies to AI-generated legal drafting output. If a feature produces language that reads confidently and turns out to be wrong, incomplete, or built from another client's confidential facts, the responsible party is the team that shipped the feature, not an unexplainable property of the model. That is worth stating directly, because the alternative, treating a model's behavior as beyond anyone's control, is precisely the framing that lets a real design gap go unexamined.

What this guide does not do

None of this is legal advice, and nothing on this page or the pages beneath it should be read as a determination of whether a specific product crosses into unauthorized practice of law, satisfies a specific bar's confidentiality rules, or meets a specific court's discovery expectations. Those are questions for counsel, licensed in the relevant jurisdiction, who can look at the actual product and the actual facts. What this guide does is take the obligations once counsel has scoped them and turn them into requirements an engineering team can build against and test for, the same approach we take across every regulated vertical we build in.

That division of labor is deliberate and worth restating plainly, because it is easy to blur once a build is underway and a deadline is close. Counsel decides which rules apply to a given product in a given state. Engineering decides how the product proves, continuously, that it does what counsel says it must do. A team that lets engineering guess at the legal scope, or lets a legal opinion stand in for an actual technical check, ends up with neither the coverage nor the evidence a real review needs.

If you are building or auditing a legal technology product, our custom software development service and eval-driven development guide are where to start. Compliance gaps in legal software covers how to find out where an existing product stands. If you would rather talk it through first, get in touch.