How legal AI is engineered — and why it belongs inside your ERP, not beside it

The question in legal has stopped being whether to use AI. Nine in ten legal teams already do, and the ones deciding now are deciding how — and where it runs.

That second half is where most of the value is won or lost. A tool a lawyer has to open, in a tab away from the matter they are working, gets used for the first week and abandoned by the second. The record still lives in the ERP. The obligation still lives in the ERP. If the AI lives somewhere else, someone has to carry answers back by hand — and that is the job nobody does.

So this is the engineering, layer by layer, and then the part that decides whether any of it survives contact with a real legal team: where it runs.

The pipeline, honestly

AI contract review is not one model reading a PDF and giving an opinion. A system you can trust with an MSA is a pipeline, and each layer exists because the layer before it is not enough on its own.

Ingestion and clause segmentation. A contract is broken into its actual units — the indemnity, the limitation of liability, the renewal and notice terms — matched by meaning, not by clause number, because no two paper templates number the same thing the same way. This is what lets everything downstream reason about a clause instead of a page.

Retrieval grounded in your own paper. The model does not answer from what it read on the open internet. It answers against your playbook, your fallback positions, your red lines and precedent — retrieved and put in front of the model at the moment it reasons. This is the difference between "here is what a contract usually says" and "here is where this contract departs from what you accept."

Extraction as structured fields, not prose. When the system pulls an obligation — who promised what, by when — it returns it as data with a place to live, not a paragraph of description. That is not a formatting preference. A structured field carries the source clause it came from, so a person can check it against the paper in one glance; a free-text summary is a sentence a model may have invented, and you find out which the hard way. Grounding the output in the source clause is the single largest lever on whether the thing is trustworthy.

Scoring against your positions. Each clause is read for how far it sits from what you will accept — a mutual indemnity with the caps you normally take is one thing, unlimited liability with no carve-out is another. The scoring is only as good as the playbook behind it, which is why the playbook is an input to the system, not an afterthought.

A person commits the change. The system proposes; a person decides. That boundary is the design, not a limitation of it — it is what makes the output safe to act on, and it is what keeps a human accountable for the clause that ships.

Measured, not trusted. None of the above is worth anything if nobody can tell whether a change to the system made it better or worse. Retrieval and extraction that are not evaluated are just a demo that happened to work the day it was shown.

Where it runs is not a detail — it is the whole thing

Every layer above can be built beautifully and still fail, for one reason: the answer has to arrive where the work already happens.

For an in-house legal or procurement team, the work happens in the ERP. The contract is attached to a purchase order in Business Central. The renewal date needs to become a field on the record, not a diary entry. The obligation needs to sit against the vendor it binds. When the AI is built into that system — inside your own Azure tenancy, the document never leaving your environment, the ERP staying the system of record — there is no second place to keep updated and no answer to carry back by hand. The buyer on the Dynamics community forum who asked for contract functionality that would "integrate seamlessly with the other deployed BC 365 modules" was describing exactly this: not a new island, a capability inside the system they already run.

That is the part the platforms a lawyer logs into cannot do for you, and it is not a criticism of them — a horizontal product cannot ship pre-integrated into your particular Dynamics or SAP estate, your particular approval routing, your particular paper. That integration is an engineering job, and it is the one we do.

What we build

The pipeline above is the pipeline we build into a legal team's own work: the playbook as the input, clauses matched by meaning, obligations and renewals extracted as data with their source, replacement language drafted, a person committing every change — running inside Dynamics 365, SAP or Business Central rather than bolted beside it.

We built one to prove it is shipped engineering rather than a slide. Paralegent AI reads every clause against a playbook and drafts the replacement language, in production today. You will likely never buy it — it exists as evidence. What we build for you is the same pipeline pointed at your paper, your positions, and the system your team already lives in.

If your contracts and obligations live in your ERP and you are weighing how to put AI against them, tell us what you run and where you are stuck — you will get a straight answer, including where we think an off-the-shelf tool is the better call. Or see Legal AI Ops for Dynamics 365 and SAP.