Avoiding unauthorized practice of law in product design

A product team building a legal technology tool usually asks the UPL question the wrong way round: "does our disclaimer say we are not a law firm." The better question is: "does our product, independent of the disclaimer, function like one." This page is about the second question, because it is the one that actually determines the exposure.

No single rule to design against

The unauthorized practice of law, generally shortened to UPL, is the unlicensed provision of legal advice or legal services, and it is regulated at the state level with no uniform federal definition. The National Center for State Courts and the American Bar Association describe the resulting landscape as a real varied continuum of scope and clarity, where some states have adopted specific statutes or guidance addressing software and AI tools and most have not [1]. That means a product built to satisfy one state's understanding of UPL is not automatically safe in the other forty-nine, and a company selling nationally has to assume the strictest state's reading applies unless it has scoped otherwise.

Two states have made specific, recent moves worth understanding in detail, because they show where regulators' thinking is heading. Colorado's nonprosecution policy, adopted across 2024 and 2025, deprioritizes UPL prosecution of developers who build legal-help technology tools, explicitly recognizing that most of these developers are not lawyers and are still delivering something a person needed [2]. Texas amended its UPL statute to exclude computer software from the definition of unauthorized practice entirely, on the condition that the product clearly discloses that it is not a substitute for an attorney [3]. Both moves share a common thread: they reward disclosure and a defined, limited scope of function, and they do not extend blanket protection to any tool that happens to be built out of software.

The decisions that actually shape UPL exposure

Four product decisions move a tool along the spectrum from "legal information" toward "legal advice," and none of them are fixed by a disclaimer.

Whether the tool presents options or a conclusion. A tool that lays out what people in a described situation typically consider, with tradeoffs explained, is providing information. A tool that tells one specific user what they should do about their specific situation is closer to a legal opinion. The line is rarely crisp, the direction matters, and the decision gets made in the flow design rather than in the terms of service.

Whether the output is general or fact-specific. Explaining what a term in a standard lease generally means is different from reviewing a user's actual lease and telling them what to do about the specific clause they uploaded. General information applied to a specific document, with a conclusion delivered back, is where UPL risk concentrates most sharply.

How the copy is worded. "You should" and "you are entitled to" read as conclusions. "People in this situation often" and "this is a factor courts have considered" read as information. This sounds like a wording exercise, and it is one, but it is a wording exercise that has to be applied consistently across every screen, not fixed once in a disclaimer paragraph that most users never read.

Who makes the final decision. A tool that surfaces information and lets the user decide keeps the user in the position of directing their own legal affairs. A tool that decides for the user, even implicitly by presenting only one path forward, has taken over a decision the UPL rules reserve for a licensed attorney or the person themselves.

Disclosure is necessary, not sufficient

Both Colorado's and Texas's approaches condition their protection on clear disclosure that the product is not a substitute for an attorney [2] [3]. That disclosure needs to be genuinely clear, not a line buried in a terms-of-service document nobody reads. It belongs where the user actually makes decisions: at the point where the tool delivers its output, and again at signup.

But disclosure alone does not offset a product that otherwise functions like legal advice. A tool that says "this is not legal advice" immediately before delivering a specific recommendation about a specific person's specific legal position is not resolved by the sentence. Regulators and courts look past the label to what the product actually does, which is exactly why the flow-design decisions above carry more weight than the disclaimer text.

Where this connects to confidentiality

A product built carefully around the UPL line often ends up handling exactly the kind of information the confidentiality rules protect: user-uploaded contracts, case facts, personal legal circumstances. Staying on the right side of UPL does not reduce the confidentiality obligation that comes with holding that data. If your product stores or processes documents that a lawyer relies on, or that a self-represented user treats as sensitive, ABA Rule 1.6 confidentiality controls for legal software covers what the product needs to hold up its end of that separate duty.

A practical starting point

Before finalizing a product flow, write down, for each screen that delivers output to a user, whether it is presenting general information or a specific conclusion, and whether the wording matches which one it is meant to be. That single exercise surfaces most of the drift that happens naturally as a product grows: a feature that started as neutral information gradually adds a recommendation because a user asked for one, and nobody revisited whether the wording still matches the intent.

None of this is a substitute for counsel reviewing the actual product against the actual states it will be sold in. What it is meant to do is put the product in front of that review already designed with the line in mind, rather than asking counsel to find every instance of a "you should" buried three screens deep. Why legal software needs a compliance-first build covers the broader argument for building this way from the start, and get in touch if you want help auditing an existing product's flows against this line.