Building compliant software in legal technology / Start here
Why legal software needs a compliance-first build
Most software risk comes from what a company does with data. Legal software adds a second kind of risk: what the product itself does can be read as practicing law, a status the product does not hold. This page explains why that changes the build from the first design decision, well before the launch checklist.
Published September 4, 2026. Updated September 19, 2026. Editorial.
Key takeaways
- Legal software carries two kinds of risk at once: ordinary data handling risk, and the risk that the product's own behavior is read as legal practice.
- Unauthorized practice of law rules differ by state, so a product built to one state's limit can still break another state's rule.
- The confidentiality and technology-competence duties bind the lawyer using the product, but the product's design determines whether the lawyer can actually meet them.
- Treating compliance as a late-stage review is a mistake: several of these obligations are decisions about what the product does, not settings added afterward.
Building software for most industries means satisfying rules about how a business handles data: who can see it, how long it is kept, how it is protected. Legal technology has all of that, and it adds something most other industries do not. The product's own behavior, along with how it stores information, can make it subject to a body of law it was never meant to fall under: the rules against unauthorized practice of law, generally shortened to UPL.
This page is about why that difference means legal software has to be designed with these questions in mind from the start, not reviewed against them once the design is done.
The legal limit that applies to legal software and not to other software
A tax preparation tool can calculate a specific number for a specific taxpayer and stay within its permitted scope, because tax preparation software is a well-established, separately regulated category. A tool that reviews a person's specific contract and tells them what to do about a specific clause is much closer to what a lawyer does for a client, and the closer it gets, the more it risks being read as practicing law without a license.
There is no single national definition of what counts as practicing law. UPL is regulated separately by each of the fifty states, and the National Center for State Courts and the American Bar Association describe the result as differing in scope and clarity from state to state: some states have specific statutes addressing software and AI tools, most do not, and enforcement priorities differ even where the underlying rule looks similar [1]. A feature that is clearly allowed in one state can be a real question in another, and a nationally distributed product has to design for the strictest plausible reading rather than the most permissive one.
Two states have changed their rules recently, and the direction of the change is worth understanding because it shapes where the rest of the country may go. Colorado adopted a nonprosecution policy in 2024 and 2025 that deprioritizes UPL prosecution against developers of legal-help technology tools specifically, reasoning that most developers of these tools are not lawyers and are still delivering something the person needed [2]. Texas went further and amended its UPL statute to exclude computer software from the definition of unauthorized practice altogether, conditioned on the product clearly disclosing that it is not a substitute for an attorney [3]. Neither change removes the limit nationally. It means two states have decided that a well-disclosed tool serving an unmet need is not the target the UPL rules were written for, and other states have not yet made that same decision.
Why this is a design question, not a legal-review question
The instinct is to treat UPL as something legal counsel checks at the end, the way a privacy policy gets reviewed before launch. That instinct underestimates how much the question affects the product, because several of the decisions that determine how close a product comes to practicing law are product decisions made early: does the tool present a single recommended answer or a set of options with tradeoffs explained. Does the copy say "you should" or does it say "here is what people in this situation typically consider." Does the flow end with the user making their own decision, or does it end with the product deciding for them. Those choices shape the UPL exposure as much as anything a lawyer reviews afterward, and undoing them after the product is released means a rebuild, not a wording change.
The same is true of confidentiality. ABA Model Rule 1.6(c) requires a lawyer to make reasonable efforts against unauthorized disclosure of client information [4], and if your product stores or transmits that information, the lawyer's ability to meet that duty depends entirely on decisions your team made about access control, encryption, and logging, most of which are architecture decisions rather than settings a compliance reviewer can switch later. Avoiding unauthorized practice of law in product design works through what those early product decisions actually look like.
Why this is now affordable
The reason to build this way is that the obligations above are, like the regulatory obligations in every industry we build for, close to specifications once you read the actual rule text rather than a summary of it. "The lawyer must make reasonable efforts to prevent unauthorized access to client information" is close to a test case already: does an unauthorized user's request for a client record succeed or fail, and does the attempt get recorded.
What used to make this kind of exhaustive checking impractical was cost. Writing several hundred narrow checks against a full set of state-by-state and rule-by-rule obligations was weeks of work that delivered no visible feature, so it was always ranked below something a customer could see and pay for. That constraint is largely gone. When code is close to free to generate, the checks that used to be unaffordable become a specification exercise and a test run, which is the argument we make across every regulated industry, laid out in more depth in our eval-driven development guide.
That does not mean generated code is automatically trustworthy here. Veracode's spring 2026 testing across more than 150 models and 80 coding tasks found only 55 percent of generations produced secure code, even as syntax correctness ran above 95 percent [5]. A generated confidentiality control that compiles and looks right is not the same thing as one that has been verified against the actual obligation, and the difference matters more in legal software than almost anywhere, because the thing being protected is privileged information a lawyer is ethically bound to guard.
What this does not settle
Nothing in this page, or in this guide, determines whether a specific product in a specific state crosses into unauthorized practice of law, or whether a specific confidentiality control satisfies a specific bar's expectations. Those are legal questions that depend on facts a lawyer needs to review, not a generic build guide. What a compliance-first build does is make sure the product's behavior reflects a real decision, made early and on purpose, rather than an accident of what was fastest to release.
If you are scoping a new legal technology product or reviewing one already in the market, get in touch, and see compliance gaps in legal software for how we approach an audit of an existing build.
Best for
- New legal technology products where the UPL exposure and confidentiality obligations have not yet shaped the design
- Products distributed nationally, where the design has to hold up against the strictest state's reading of UPL rather than the most permissive one
- Teams rebuilding a legal product where confidentiality or retention behavior was added late and needs to be rebuilt into the architecture
Avoid if
- Counsel has not yet scoped which states' UPL rules and which bar's ethics rules actually apply to the product, since a build cannot resolve a legal question on its own
- The team is not prepared to treat confidentiality and retention as architecture decisions rather than settings added before launch
Check before you decide
- Ask whether the product's core flow was reviewed for UPL exposure before the interaction design was finalized, not after
- Ask which specific states' UPL rules the product has been scoped against, and whether that list matches where it is actually sold
- Ask what evidence exists that a confidentiality control was tested against the actual rule text, not a summary of it
Common questions
Why does legal software carry more design risk than other regulated software?
Because the product's own behavior, along with how it stores data, can cross into practicing law without a license. Most regulated industries govern what a business does with information; legal technology adds a second layer where the product's recommendations or conclusions themselves can be read as legal advice.
Is unauthorized practice of law the same rule in every state?
No. Each of the fifty states regulates UPL separately, with different statutes, different enforcement priorities, and different treatment of software specifically. A feature that is clearly allowed under one state's rules can be a real legal question in another, which matters for any product sold nationally.
Have any states created specific rules for legal software?
Yes. Colorado adopted a nonprosecution policy in 2024 and 2025 that deprioritizes UPL enforcement against developers of legal-help technology tools. Texas amended its statute to exclude computer software from the UPL definition, provided the product clearly discloses it is not a substitute for an attorney.
Why can't UPL compliance be handled as a late-stage legal review?
Because several of the decisions that determine UPL exposure, such as whether a flow presents options or a single recommended answer, are made early in product design. Reviewing a finished product against UPL rules can catch the wording, but rebuilding the underlying flow at that point is close to a rebuild, not an edit.
How does confidentiality fit into a compliance-first build?
A lawyer using the product is bound by ABA Model Rule 1.6(c) to make reasonable efforts against unauthorized disclosure of client information, and the lawyer can only meet that duty if the product's access control, encryption, and logging support it. Those are architecture decisions, so they need to be made early rather than reviewed at the end.
Does building with AI make legal software riskier?
Only without independent verification. Veracode's spring 2026 testing found only 55 percent of AI-generated code was secure even though it compiled correctly over 95 percent of the time, so generated confidentiality or access controls need to be checked against the actual obligation rather than assumed correct because the code runs.
Can a disclaimer alone protect a legal software product from UPL claims?
Not reliably on its own. Even Texas's software exclusion, one of the more permissive state rules, conditions it on the product clearly disclosing it is not a substitute for an attorney, and whether the underlying product design also avoids UPL is a separate, fact-specific legal question a disclaimer cannot resolve by itself.
Who should decide which UPL and confidentiality rules apply to a legal software product?
Counsel licensed in the relevant states should scope which rules apply, since that is a legal determination rather than an engineering one. Once that scope exists, the engineering team can convert each obligation into a specific design decision and a testable check.
Related reading
Adding eval tests was the best decision we made
We generate every line of code we release. The single change that made that safe was writing the check before the code, and it turned out to change how we review, how we spec, and how fast we can work.
Never let the model grade its own work
When the same run writes the code and the tests, a passing build proves only that the code is consistent with itself. That is not verification, and it is the most common way an AI-built codebase becomes confidently wrong.
A practical pre-launch security review for a small team
You do not need perfect security to launch. You need to check the few basics that find most real problems, and to know when the risk is big enough to bring in a specialist.