How to Use AI for Document Comparison

The change that costs a client is rarely the one in bold. A track-changes redline shows you inserted and deleted words, but it will not tell you that a defined term now means something narrower, that an obligation moved from a warranty into a best-efforts clause, or that a figure in Schedule 2 quietly shifted while the operative clause referencing it stayed the same. AI comparison is useful because it can read for meaning across a hundred-page agreement in seconds. It is dangerous for the same reason: it will summarise, and a summary is where a material change goes to hide.

Name the baseline and the revision explicitly

Before anything else, tell the model which version is the starting point and which is the proposed change, and label them so its output refers to each by name. Comparison is meaningless if you cannot tell which direction a change runs. Confirm you are working from the correct executed baseline and not an earlier draft, a mistake no amount of clever analysis will recover from.

Ask for clause-level output, not a narrative

Do not accept "the main changes are..." Instead, ask the model to list each substantive change with the clause number, the old wording, the new wording, and a one-line note on its effect. A tabular, clause-by-clause output forces the comparison into a shape you can verify against the originals, and it prevents the model from folding three changes into one smooth sentence.

Watch the places automated diffs miss

Direct the model's attention, and your own, to the categories where meaning shifts without obvious textual change:

• Defined terms, where a changed definition silently alters every clause that uses it
• Cross-references, where a renumbered clause breaks the logic of another
• Schedules, annexures, and pricing tables, often pasted rather than tracked
• Obligation strength, "shall" becoming "may," "will" becoming "may endeavour to"
• Carve-outs and exceptions added to an otherwise unchanged clause

Verify against the source, always

Treat the model's comparison as an index, not a conclusion. For every change it flags as material, open both versions and read the actual clauses. For anything it did not flag in a section you consider critical, read that section anyway, because the failure that hurts is the change the model decided was not worth mentioning. A workspace that keeps both versions open beside the analysis, such as Juniorlawyer, makes this checking fast enough to do properly rather than skip.

Keep a decision log, not just a diff

A comparison is a means to a negotiation, not the end of one. As you review, record which changes you accept, which you will push back on, and which need the client's instruction. Tie each entry to a clause number. This log becomes the agenda for the next call and the memory of why a clause reads as it does, which the redline alone will never preserve.

Close the loop before you rely on it

Once the review is done, confirm three things: that the version you analysed is the version on the table, that every material change has a recorded decision, and that the points needing client input are separated out clearly. Comparison done well ends with a short, referenced list a colleague could act on without re-reading the whole agreement.

Used this way, AI turns a slow, error-prone read into a fast structured pass, and frees you to spend your attention on judgement rather than hunting for what moved. But it is the lawyer who decides what a change means and whether it is acceptable. The model finds candidates; you find the ones that matter.