AI is only as good as the context you give it

Every week, a new AI model comes out. Faster, cheaper, top of a leaderboard nobody remembers the following week. And every week, someone asks me the same question: “Which model do you use?”

I get the question. But for a procurement team, it’s a bit like hiring a negotiator based on their IQ without checking whether they’ve read the file.

The best model in the world has never read your amendment no. 3

An AI model has read a good chunk of the internet. It can explain what an indexation clause is, write a polite email to a supplier and summarize a contract in five bullet points. What it doesn’t know is what’s going on in your company.

It doesn’t know that the amendment signed last year cut the liability cap in half. It doesn’t know that your master agreement caps increases at 5% a year. It doesn’t know that the supplier already gave up a discount in round two, or that the internal client wants to shrink the scope.

Without those pieces, it does what any brilliant person would do walking into a meeting without having opened the file: it answers with confidence. And misses the point.

Procurement context is everywhere, except in one place

If all the context were neatly stored in a single file, we’d have solved this long ago. In real life, for a single renewal, you have to gather:

• the master agreement, and each of its amendments, some of which quietly rewrite the earlier ones;
• price lines, indexation, notice period and automatic renewal;
• the supplier’s offer, which happens to arrive a few weeks before the deadline;
• the internal client’s actual need, which isn’t quite what it was three years ago;
• the history of exchanges, concessions and promises made in meetings.

All of that lives in shared folders, inboxes and spreadsheets. With the usual bonus: three versions of the same contract, one of them named “FINAL_v2_really-final.pdf”. Good luck to the model. And good luck to the buyer.

The real work today isn’t analysis. It’s rebuilding. And it gets redone at every step: to launch the RFP, to prepare the renewal, to negotiate. The same puzzle three times, with pieces that change shape between games.

Same question, two answers

Take an everyday case. A software vendor announces a 7.2% increase at renewal. You ask a general-purpose assistant whether that’s acceptable.

It will talk about inflation, market practice, maybe the importance of “preserving a relationship of trust with your partners”. Nothing wrong. Nothing useful either.

Now ask the same question to a system that has read the contract and its amendments. The answer changes in kind: section 11.2 caps the annual revision at 5%, the offer exceeds that cap, here is the gap in euros over the contract term, and here is the clause to quote back to the supplier.

Same model, same question. The only thing that changed is what it had in front of it.

There’s a second, quieter effect: trust. An answer without a source doesn’t hold up in committee. An answer that points to the section, the page and the document does. And nobody wants to explain to their CFO that they renegotiated a contract worth several hundred thousand euros because “the AI told me so”.

What this changes when you design a tool

If context is what matters, a procurement tool has to be built around it. Not around a chat window sitting next to the screens, hoping the user remembers to paste everything in before asking their question.

In practice, that means four things:

• gather context along the cycle, without asking the buyer to re-enter everything;
• keep it from one step to the next, from need to contract, then all the way to renewal;
• cite sources, so every statement can be checked in one click;
• leave calculations to the system and decisions to people. An AI doing mental arithmetic on your amounts? No, thank you.

Seen that way, the choice of model becomes almost secondary. It should be able to change, depending on your confidentiality requirements or preferences, without the tool losing the memory of your files. The model is the engine. The context is the map. A great engine without a map goes very fast. Rarely in the right direction.

Why I built Naigo this way

That’s the starting idea behind Naigo: procurement intelligence starts with context. Every contract read, every bid analyzed, every negotiation conducted enriches the file the AI works on next. You don’t start from a blank page; you start from what the file already knows.

The big vendors in the market will get there, of course. But starting from scratch gives you a luxury they don’t have: asking, with nothing to protect, how the work should be done if the AI had all the context at hand. It’s the question I ask myself every morning. And, to be honest, the answer is almost never “one more chatbot”.

In Naigo, every extracted piece of data cites its source, amounts are calculated by the system, and every decision stays with the buyer. The AI model remains your choice: Mistral is recommended, and you can plug in your own via API.