Building compliant software in legal technology / Building it right
Evals as legal compliance evidence
When a firm's compliance function or a court asks how a product's confidentiality or retention controls actually worked, a policy document only describes intent. A check suite derived from the underlying rules and run on every change describes real behaviour, with dates attached. This page covers what that looks like for legal software specifically.
Key takeaways
- A confidentiality or retention policy document describes intent at the moment it was written. A check that runs on every change describes what the system actually did, continuously.
- Each check should trace to a specific rule, such as ABA Rule 1.6(c) or FRCP Rule 37, so coverage is visible rather than assumed.
- The run history is what makes this credible: it cannot be produced retroactively the way a policy document can.
- This only works when the checks are independent of the code they verify, since generated code is not secure by default.
Legal technology has a particular version of a problem every regulated industry shares: the gap between what a policy says a system does and what the system actually does, discovered only when someone asks the hard question at the worst possible time. This page covers how to close that gap using the same method we apply across every regulated vertical, adapted to the specific rules that govern legal software.
Why a policy document is the weaker kind of evidence
A confidentiality policy that says "attorney records are isolated by firm" is a description of intent, written at a point in time, by people who designed the system to work that way. It does not change when the system stops matching it, and systems drift for ordinary reasons: a new reporting feature added eighteen months later queries across firms for an aggregate statistic, and nobody remembers to scope it the way the original design intended. The policy is still accurate about what was intended. The system no longer does what the policy describes.
A check that runs on every code change closes that gap by construction. The day the cross-firm reporting feature is added, a test asserting that one firm's records never appear in a query scoped to another firm's account either covers that new code path and fails, revealing the problem immediately, or misses it, which at least tells you where your coverage has a blind spot once someone reviews it. Either outcome beats the alternative, which is silence until a client notices their data somewhere it should not be.
Trace each check to the specific rule
Every compliance-relevant check in a legal software product should reference the specific obligation it satisfies. Not "confidentiality test," but the actual rule: ABA Rule 1.6(c) for access isolation, FRCP Rule 37 for retention hold behavior, the specific state UPL guidance for a disclosure requirement in a particular flow.
This matters for the same reason it matters in every other regulated vertical we build in: it turns coverage into something visible rather than assumed. Put the list of obligations from this guide next to the check suite, and any obligation with no check attached is immediately apparent. Without that trace, verifying coverage means reconstructing intent from test names, which is unreliable enough that most teams simply do not do it and assume they are covered.
It also makes the suite resilient to change. Ethics rules and state UPL guidance are not static. Colorado's and Texas's recent moves on software and UPL are evidence that this area is actively evolving, and a traced suite means that when a rule changes, the affected checks are a search away rather than an archaeology project across a test suite nobody has revisited in a year.
The run history is the actual evidence
The single strongest piece of evidence a check suite produces is the history: a specific assertion, tied to a specific rule, that has run and passed on every commit for the last two years. That history cannot be manufactured after the fact. A policy document can be written the week before a firm's due diligence review or a bar complaint response. A run history spanning two years of actual commits cannot be backdated, which is exactly what makes it credible in a way a document never fully is.
This has a practical consequence worth designing for directly: retain the results of these checks alongside the current state of the code. Most CI systems default to a retention window measured in weeks or months, chosen for storage cost reasons that have nothing to do with the evidential value of the history. If your product's confidentiality and retention checks matter for the reasons covered in this guide, that default needs to be overridden deliberately.
What checks in this domain actually look like
A few concrete examples, each traceable to a page elsewhere in this guide. A test that creates records for two separate firm accounts, then asserts that a query scoped to one account, run through the real application code path rather than a direct database query, never returns the other account's records, tracing to ABA Rule 1.6 confidentiality controls for legal software. A test that places a litigation hold through the real interface, then confirms the scheduled deletion job skips the held record while still deleting an unrelated, unheld record of the same type and age, tracing to e-discovery and retention requirements under FRCP. A test that exports a document and asserts the exported file's metadata does not contain the internal revision history, tracing to the metadata provision in Rule 1.6(c).
None of these are exotic tests. They are the tests that a team under normal prioritization pressure tends not to write, because writing several hundred of them by hand has always been the unglamorous work that lost every planning meeting to a visible feature. That calculation is the one that changed, and it is the same argument made across this site: when code is close to free to write, the checks that used to be unaffordable become a specification exercise and a run.
The condition this depends on
None of this works if the checks themselves were written carelessly, and it is worth being direct about the risk rather than glossing over it. Veracode's spring 2026 testing across more than 150 models and 80 coding tasks found only 55 percent of AI generations produced secure code, even as syntax correctness ran above 95 percent [1]. A generated confidentiality check that looks reasonable and passes is not the same as one verified against the actual rule text, and the difference matters more here than almost anywhere else, because what is being protected is privileged client information a lawyer is ethically bound to guard.
The two conditions that make the difference are the same ones that apply everywhere we build this way. The check has to be derived from the rule before the implementation exists, not written afterward to match whatever the code already does. And the work has to be graded by something other than the process that produced it, a fresh review rather than the same context checking its own output, which is the argument covered in never let the model grade its own work.
What this cannot do
A check suite cannot tell you whether a specific product crosses into unauthorized practice of law in a specific state, cannot interpret an ambiguous ethics opinion, and cannot decide whether a retention period is appropriate for a specific type of legal matter. Those are legal judgments. What a check suite can do is make sure that whatever counsel decides the product must do, the product actually and continuously does it, and can show its work when asked. Get in touch if you want help building that suite for a legal technology product.
Best for
- Legal technology products handling confidentiality-sensitive client data or litigation-relevant records
- Teams that already have obligations scoped by counsel and need them converted into engineering checks
- Products preparing for a firm's vendor due diligence review, where a run history is stronger evidence than a policy document
Avoid if
- Nobody has scoped which specific rules apply to the product yet, since a check suite cannot resolve that legal question on its own
- The team is not prepared to independently verify generated checks, since an unverified check provides false confidence rather than real coverage
Verify before you commit
- Ask whether each compliance check references the specific rule or provision it satisfies
- Ask how long check results are retained, beyond whether the checks currently pass
- Ask whether the checks were derived from the rule text before the implementation existed, and ask to see that order in the commit history
Common questions
Why is a check suite stronger compliance evidence than a policy document?
Because a policy document describes intent at the time it was written and does not change when the system stops matching it. A check that runs on every code change describes actual behaviour continuously, and the failure it produces when a new feature breaks a rule is immediate rather than discovered later.
What does it mean to trace a check to a specific rule?
It means the check references the exact provision it exists to satisfy, such as ABA Rule 1.6(c) or FRCP Rule 37, rather than a generic label like 'confidentiality test.' That makes coverage visible: an obligation with no check attached is apparent at a glance rather than hidden inside test names nobody reads closely.
Why does the run history matter more than the current pass or fail state?
Because the history cannot be manufactured after the fact. A policy document can be written the week before a review, but a specific check that has run and passed on every commit for two years is evidence that cannot be backdated, which is what makes it credible in a way a document is not.
What kind of legal software checks are commonly missing?
Tests that exercise the actual boundary rather than assume it, such as confirming a query scoped to one firm's account never returns another firm's records, or confirming a litigation hold placed through the real interface actually blocks the scheduled deletion job. These are straightforward to write but often skipped under ordinary prioritization pressure.
Is generated code safe to use for legal compliance checks without review?
No. Veracode's spring 2026 testing found only 55 percent of AI code generations were secure even though syntax correctness ran above 95 percent, so a generated confidentiality or retention check needs independent verification against the actual rule text before it can be trusted as real coverage.
Should compliance checks be written before or after the implementation?
Before. A check written after the implementation encodes what the code already does, so it passes without proving the requirement was actually met. A check derived from the rule text first can fail on the first run, and that failure is often the moment a real gap is discovered.
How long should legal compliance check results be retained?
For as long as the underlying obligation could matter, which is often years, not the weeks or months most CI systems default to for cost reasons. A short retention window discards the run history, which is the part that actually carries evidential weight.
Can an eval suite decide whether a product violates unauthorized practice of law rules?
No. A check suite can verify that a product behaves the way counsel determined it should, but it cannot make the underlying legal judgment about whether a specific feature crosses into unauthorized practice of law in a specific state. That determination has to come from counsel first, and the checks enforce it afterward.
Related reading
Adding eval tests was the best decision we made
We generate every line of code we ship. 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 move.
Never let the model grade its own work
When the same run writes the code and the tests, a green build proves the code agrees with itself. That is not verification, and it is the most common way an AI-built codebase becomes confidently wrong.
How many tests does AI-generated code need?
The honest answer is not a number, and coverage percentages are the wrong unit. Here is the unit we use instead, and why a suite of fifteen checks can be worth more than two thousand.