Contract review in purchasing with an internal AI: supplier terms against your own

What AI contract review does in purchasing

AI contract review in purchasing takes a supplier's contract, framework agreement or general terms and conditions, compares each clause that matters to the buyer with your own purchasing terms and writes a deviation list with the supplier's wording, page and clause. A person in purchasing checks the list, and the clauses that need a legal view go to your lawyer with the list attached. The language model for this is of moderate size and runs on one card of a company AI server.

This guide is for heads of purchasing, managing directors and commercial managers at companies without an in-house legal department, where contracts are read by buyers and only the difficult ones reach an external lawyer. The first part describes the work in purchasing terms; the server sits in one section with one table; notes for the IT team come at the end. Legal points are general information on EU law as of October 2026. National law, including the rules on standard terms and on which terms apply when both sides refer to their own, differs between Member States; your legal counsel confirms what applies to a given contract.

The work is familiar. A supplier sends an offer with its own terms attached, or a framework agreement of forty pages drafted by its legal department. The buyer has to find out where those terms differ from the company's own: a shorter warranty, a cap on liability, a price adjustment clause, a longer notice period, a different place of jurisdiction. Reading every clause against your terms takes hours, and in a busy week the reading gets shorter than it should be.

Your purchasing terms as the yardstick

The AI needs something to compare against. Most companies have general terms of purchase; few have written down what they accept when a supplier refuses them. A playbook closes that gap: one line per clause type with your standard position, the fallback you accept, and the point at which a decision moves to the lawyer or the managing director. Writing it takes a working session with purchasing and your lawyer, once. After that, the AI applies it to every contract, and new buyers learn from it as well.

Our example playbook for a buyer of components and services; the clauses, values and thresholds are illustrations that each company sets with its lawyer.

The playbook also records clauses that must be present. A contract without a confidentiality clause, without a governing-law clause or without a defined delivery date is a finding of its own, and an AI that only compares the clauses it finds would miss it. The list of required clauses makes the absence visible.

Contract clause extraction and comparison, step by step

The comparison runs in five steps:

1. Reading. The contract is converted to text. A signed scan goes through a document model first, as our guide to vision-language models for document AI explains; a contract exported from a word processor is read directly.
2. Finding clauses. The model goes through the contract and assigns each clause to a type of the playbook, keeping the clause number and page. Clauses that fit no type are listed separately.
3. Comparing. For each type the model compares the supplier's wording with your standard and fallback and rates it: matches, acceptable, escalate, or missing.
4. Deviation list. The result is a table with the supplier's exact wording next to your position, so the reader sees both without opening the contract.
5. Review. The buyer checks each line against the contract, marks what to negotiate and sends the escalated lines to the lawyer.

Our example deviation list; a real list quotes the supplier's text verbatim and gives the clause number of the contract.

Finding and labelling clauses is a task with public test data. The Atticus Project's CUAD dataset, published under CC BY 4.0, contains more than 13,000 labels in 510 commercial contracts, "manually labeled to identify 41 categories of important clauses", among them the agreement date, the expiration date, the renewal term and the notice to terminate renewal, as its Hugging Face card describes. Its categories follow what lawyers look for in corporate transactions such as mergers and acquisitions. A purchasing playbook has different clause types, often in another language, which is why the test belongs on your own supplier contracts.

Payment terms: an example from EU law

Payment periods show how the list can flag a point of law next to a commercial one. Directive 2011/7/EU on combating late payment in commercial transactions provides that the period for payment fixed in a contract between undertakings "does not exceed 60 calendar days", unless the contract expressly agrees otherwise and the term is not grossly unfair to the creditor (Article 3(5)). Where goods or services are checked on acceptance, the maximum duration of that procedure "does not exceed 30 calendar days" unless expressly agreed and not grossly unfair (Article 3(4)).

Article 7 adds that a term on the payment date, interest for late payment or compensation for recovery costs is unenforceable or gives rise to a claim for damages if it is grossly unfair to the creditor. A term that excludes interest for late payment "shall be considered as grossly unfair", and one that excludes compensation for recovery costs "shall be presumed to be grossly unfair" (Article 7(2) and (3)). Member States had to apply the directive from 16 March 2013 and may keep rules more favourable to the creditor. The Commission proposed a regulation to replace it on 12 September 2023 (COM(2023) 533); check its current state with your counsel before relying on either text.

For the buyer this cuts both ways. A supplier's "net 14 days" is a commercial deviation from your terms. A standard of 90 days in your own terms would be a legal point: above 60 days it needs express agreement and must not be grossly unfair to the supplier. The playbook should mark such lines, and the AI then flags them in your favour and against it. Whether a given term is grossly unfair is a question for your lawyer; the list only shows where the question arises.

We supply AI servers built to order, and our Private AI/ML service sets up the models, the playbook and the comparison; send us your purchasing terms and the contract types you receive, and our team replies with a configuration and a pilot proposal.

What the deviation list is, and what it is not

The deviation list is a working document for purchasing. It does not replace the reading of the contract and it is not legal advice. Three kinds of error occur, and the process has to catch them:

• A missed clause. A liability limit can sit in an annex, in a footnote or in terms referred to by a link. The model sees only the documents it receives. The buyer checks that all annexes and referenced terms are in the file.
• A misread clause. Cross-references ("subject to clause 11.3"), exceptions and double negatives can turn a clause around. Because each line quotes the supplier's wording and gives the page, the reviewer checks the line against the source in seconds.
• A wrong rating. The model applies the playbook as written. If the playbook is vague, the rating will be too.

The lawyer receives the deviation list together with the contract. That shortens the lawyer's work, because the questions are prepared and the commercial points are already settled, and it leaves the legal judgement where it belongs. Our article on local LLMs and ChatGPT answer quality explains in plain words why models make such errors and how to test for them.

Confidential contracts stay in the company

Supplier contracts contain your prices, volumes, discounts and the supplier's own terms, which may themselves be under a confidentiality clause. Framework agreements reveal your purchasing strategy. With the model on your own server, none of this leaves hardware you control and the library of reviewed contracts stays in the company. Our article on trade secrets, NDAs and AI tools covers the business side of that decision, and local AI and the GDPR the personal data of contact persons that every contract carries. Law firms and tax advisers work under professional secrecy and a different set of tasks; our guide to an on-premise LLM for law firms and tax advisers covers that case.

Which model, and how long a contract may be

Reading a contract and comparing it with a table does not need the largest models. Qwen3.8-27B is an example of the size that does: 27 billion parameters by its Hugging Face card, a native context of 262,144 tokens, and an FP8 checkpoint of 30,866,866,928 bytes (30.9 GB) under the Apache 2.0 licence, which places no restriction on commercial use. The card states that thinking mode is on by default and can be disabled per request.

How much memory. By our users-per-card rule, 90 per cent of the memory the driver reports, less 3 GiB per card and less the weights, one 96 GB card keeps 83.04 GiB. The FP8 weights take 28.75 GiB and leave 54.29 GiB for the cache. Only 16 of the model's 64 layers keep a growing cache, so with an FP8 cache a request of 131,072 tokens needs about 4.14 GiB and one of 32,768 tokens about 1.14 GiB, by our arithmetic from the configuration file. One card therefore reviews 13 contracts of up to 128K tokens at the same time, or answers 47 shorter requests of 32K.

Why the long context matters. A clause on page 3 can be limited by a definition on page 1 and an annex on page 40. Reading the whole contract with its annexes in one request lets the model follow those references. Longer files, such as a framework agreement with many annexes, are split by document, and the deviation list is assembled from the parts. A 128K request also takes processing time before the first word of the answer appears; check the response time with your own contracts on the target card.

The model card does not list the languages Qwen3.8 supports. Purchasing in Europe deals with contracts in several languages, so test the model with contracts in each language you receive; our comparison of open LLMs for European languages lists alternatives.

One server for purchasing and the other departments

A purchasing department reviews a few contracts a week, which uses a card for minutes at a time. The same server can carry the other office tasks of the company, such as offers, supplier questionnaires and an assistant for all staff, as our guide to AI in customer audits and supplier questionnaires shows for a neighbouring task.

Reference configurations on our AI servers page; requests by our users-per-card rule with Qwen3.8-27B FP8 (28.75 GiB, FP8 cache) and gpt-oss-120b (60.8 GiB, 16-bit cache, 0.5625 GiB per 16K request), as in our guide to AI in customer audits; power by our estimate (cards, two processors and 15 per cent for the rest), confirmed by a measurement on the delivered system.

The entry server on our AI servers page has two NVIDIA RTX PRO 6000 Blackwell Server Edition cards with 96 GB each, two AMD EPYC processors, 384 GB of DDR5 ECC memory and two NVMe drives. One card runs Qwen3.8-27B for contracts and documents; the other runs a larger assistant model for the whole company. By our estimate it draws about 1.8 kW at the wall, within one 230 V 16 A feed. Four cards add a tensor-parallel pair for several hundred staff, as our page on private ChatGPT servers by company size works out, at about 3.4 kW.

Both belong in a server room or a data centre, because they are loud and warm under load, as our guide to a GPU server in an office explains. Without a server room, our Private AI/ML service runs the platform on dedicated hardware in a Tier-3 data centre in Lithuania, inside the EU. A company without an IT department finds the division of tasks in our guide to an AI server without an IT department.

Notes for the IT team

1. Playbook as data. Keep the playbook as a versioned file (clause type, standard, fallback, escalation, required yes or no) and pass it with each request, so a change to the playbook applies to the next review without retraining anything.
2. Structured output. Request the deviation list as JSON against a fixed schema; vLLM accepts a JSON schema with each request, and its documentation states that "the output will follow the JSON schema". A valid record can still carry a wrong rating, so the human check stays.
3. Verbatim quotes. Check by software that every quoted supplier wording appears in the source text; a quote that cannot be found marks the line for review.
4. Thinking mode. For clause finding, test enable_thinking set to false in chat_template_kwargs against the default; comparisons with cross-references may gain from thinking mode, at the cost of longer answers.
5. Access and retention. Contracts and lists are readable only by purchasing and the people they choose; contracts carry personal data of contact persons, so set a retention period for prompts and outputs with your data-protection officer and check whether a data protection impact assessment is needed.
6. Network. vLLM's --api-key protects only paths under /v1, /v2, /inference and /cohere (vLLM 0.32.0 security guide), so keep the engine on an internal network behind an LLM gateway with keys and a query log.

What we supply

You can buy this system from us: our team sizes the configuration to your workload and budget and replies within one business day. We build AI servers to order with two, four or eight cards, assembled and tested before delivery, delivered anywhere in the EU on one EU contract and invoice, with manufacturer warranty on every component handled through us; quantities and lead time are confirmed in writing with the quote. Our Private AI/ML service, with our engineering partner Vixen.UNO, sets up the model, the playbook, the comparison and access for purchasing. Describe your contract volume and the languages you receive, and we propose a setup for your purchasing team.

FAQ