Legal Technology: Why Contract-Template Tools Aren't Solving the Real Problem

Look at how most legal-technology products are marketed and you'll find the same thing: drafting a contract, suggesting a clause, formatting a document. These are useful. But they aren't the field's real problem, and the thing these tools appear to solve is actually the easiest part of it.

The real problem sits somewhere else. An organisation is subject to a legal duty. Someone interprets what that duty means. The interpretation gets written into a document. The document goes into a folder, and the organisation's day-to-day operations carry on unaware it exists. That gap between the document and the running system is the most expensive mistake I see in practice, and no contract-template tool closes it.

Interpretation is a human job; enforcement is the system's job

Turning a rule into software isn't the same as writing the rule into code. There's a step in between that can't be automated.

Article 7 of Law No. 6698 provides that personal data must be deleted, destroyed or anonymised once the reasons requiring its processing no longer apply. That provision is clear. But what does "the reasons no longer applying" mean, precisely, for an organisation's invoice data? The end of the customer relationship? The expiry of the tax-law retention period? Whichever comes later? A lawyer answers that question. The answer is an interpretation, and unless it's put on record, nobody will remember six months later why that particular period was chosen.

That's where the software's job starts: making sure the interpretation, once given, is applied the same way every single time, and that this can be shown. A system that does that is legal technology. A system that only produces templates is a word processor.

What happens when the document and the system come apart

Take a concrete example. An organisation's retention policy says customer contact records are kept for two years. An audit arrives, and that policy gets shown.

The auditor asks one question. What component enforces this period?

Often there's no answer. The database has a created_at field, but no expires_at. There's no job that deletes an expired record. Even where deletion happens, it produces no record of having happened. In the end the organisation can't show that it did what its own policy says. The policy document isn't evidence — at best it's a statement of intent.

The fix isn't a better-written policy. It's adding a field to the data model that carries the retention period, writing a component that enforces it, and making sure that component produces a record when it runs. Once all three exist together, the policy stops being a claim and becomes a description of what the system actually does.

The five links in the chain

Turning a legal text into a working control in a system happens in five steps, and the order matters — skip any one of them and the result becomes unreliable.

First, the provision is identified: the applicable rule and any exception. Then comes interpretation — deciding what the rule means for the concrete business process. This step belongs to a human and has to be put on record. Third, the interpretation is tied to the architecture: which field carries which rule. Fourth, the component that enforces the rule at run time is written. Fifth, that component's operation is logged.

A control built without interpretation enforces the wrong rule. A control that produces no evidence is useless at audit. The mistake I see most often is skipping straight from step three to step five: the organisation keeps a log, writes something into it, but it's unclear what rule that log is actually evidence of.

The lawyers' monopoly

Anyone building a product in this space needs to know one boundary. Article 35 of Law No. 1136 on Attorneys reserves the conduct of legal work and the giving of legal opinions to lawyers.

In practice, this decides what your product can and can't say. "Your contract is missing this clause" is information. "Don't sign this contract, it will work against you" is an opinion. The line is thin and has to be protected deliberately in product design. The most reliable way to protect it is for the system never to make the decision itself, and for a human decision to remain visible behind every output.

That boundary looks like a constraint, but it's actually good design discipline. A system that doesn't take on the decision doesn't take on the responsibility when it gets something wrong — and that stops users trusting the system blindly.

What AI has changed, and what it hasn't

Natural language processing delivers a real productivity gain in document review. Finding a particular clause type across hundreds of contracts used to take weeks. Now it takes hours.

What hasn't changed is responsibility. If a model's output can't be traced back to which document and which paragraph it came from, that output is a guess, not a finding. Likewise, if the system doesn't visibly distinguish a result it's confident about from one it isn't, users trust both equally and errors slip through unnoticed.

Without those two conditions, whatever efficiency gain was made gets paid back later as risk — and the worse part is that nobody knows when that risk will actually materialise.

Where to start

Starting a legal-technology programme inside an organisation, pick a single obligation. Trying to tackle everything at once sounds appealing but never actually finishes in practice.

For the chosen obligation, build all five links: write the provision, put the interpretation on record, connect it to the data model, build the control, produce the evidence. This work finishes in about six weeks, and what you end up with isn't a report — it's a working control and a record you can show at audit.

The second obligation moves much faster. The hard part was never the rule. It was building the chain for the first time.