Every procurement conference now has a stage on which someone explains that artificial intelligence will transform the function. The description is rarely specific enough to act on. What follows is an attempt at the specific version, written for people who have to sign the order and defend it afterwards.
Four things it does well
It reads documents that were never meant to be read by machines. Scanned invoices, delivery notes, certificates, terms and conditions attached as PDFs, handwritten annotations in the margin. Extracting structured values from this material used to require a template per document type and broke whenever a supplier changed their layout. That constraint has largely gone.
It compares one document against another. Invoice against order, order against contract, delivery note against both. The comparison itself is old technology; what is new is that it now works on unstructured inputs, which is the form most of this material arrives in.
It classifies and routes. Which category does this request belong to, which buyer owns it, which framework agreement covers it, is this a duplicate of something submitted last week. Individually trivial decisions, collectively a large amount of somebody's day.
It answers questions about your own material. What did we agree with this supplier about liability caps. Which contracts renew in the next quarter. Where did we set that delivery penalty. This works when the search is grounded in your actual documents and returns the source alongside the answer — and it fails, sometimes spectacularly, when it is not.
Three things it does badly
It does not know what it does not know. A language model produces a fluent answer whether or not it has grounds for one. In a procurement context that is a specific hazard: a confidently invented clause reference is more dangerous than an admission of ignorance, because it survives review by anyone who is skimming.
It does not make commercial judgements. Whether a variation is justified, whether a supplier's explanation is credible, whether to press a claim or let it go — these depend on relationship, precedent and appetite for conflict. No amount of context window substitutes for the person who has dealt with that supplier for six years.
It does not fix an undefined process. If two departments disagree about who approves what, introducing a system that automates approvals will produce automated disagreement. This is the most common way these projects fail, and it has nothing to do with the technology.
The useful question is never “what can AI do”. It is “which of our steps consist of comparing documents, and how much do those steps cost us”.
A rough test for any proposed use case
| Question | Good sign | Warning sign |
|---|---|---|
| What is the input? | Documents you already receive | Data somebody would have to start collecting |
| What is the output? | A proposal a human confirms | An action taken without review |
| How is a mistake noticed? | Immediately, by the person receiving it | Months later, in an audit |
| What happens if it is switched off? | Work continues, more slowly | Nobody remembers how it was done before |
A use case that scores well on all four is worth building even if it sounds modest. One that scores badly is worth avoiding even if it demonstrates beautifully.
Where the data goes
One practical matter that decides more procurement projects than capability does: supplier pricing, contract terms and internal cost structures are among the most commercially sensitive material a company holds. Whether that material may leave the organisation, and to which jurisdiction, is a question to settle at the start rather than at the security review three weeks before go-live.
There is almost always a workable arrangement — processing under contract in a European data centre, or a model running inside your own environment. What varies is how much it costs and how much capability you give up. That trade is a decision for the business, not for the IT department, and certainly not for the vendor.