It happens for an innocent reason. Procurement has to describe something technical nobody in the building has bought before, so somebody asks a friendly vendor for input and the vendor is glad to help. What comes back is a specification shaped like their product: their features, in their order, with the parts they are weak at left out.
The other bidders recognise it on sight. Some will not bid. The ones who do will price knowing they are there to make up the numbers, so you get one real offer and two pieces of theatre, and the file still looks competitive to anyone reviewing it later.
The way out is not to write it alone in a room. It is to write it about the result you want rather than the machinery that produces it.
Specify the result, not the product
Write down the decision or task you want improved, how well it goes today with a number next to it, and what would count as good enough to buy. That is most of a good tender, and it is the part nobody outside your organisation can write for you.
Do not name the AI model, the database, the cloud provider or the programming language. Each is a door held open for one supplier and closed to the rest, and none of them tells you whether the thing will work. Where a technical constraint is real, write it with the reason beside it: the data must stay inside the UAE because of the rule we operate under, or our team supports this technology and no other. A constraint with a reason is legitimate and any serious bidder will respect it. A constraint with no reason is capture, whether or not anybody meant it that way.
Put the test in the tender
Take real examples out of your own records where the correct answer is already known, keep them back, and tell every bidder the award will be scored on that same set. Say who assembles it, which is you, and publish the pass mark before the bids come in rather than after.
That one change alters the character of the exercise. It moves the decision off promises and onto a number, and it is hard to argue with a year later when somebody asks why the winner won. If you answer to a board or a government process, that is worth more than the time it takes.
Score what happens after they win
Most tenders put nearly all their weight on the build and almost none on what you are left holding. Then the system is delivered and every future change has exactly one possible supplier, who is well aware of it.
Put weight on the ending, in the scoring sheet, before the bids are opened. What you receive at handover. Whether it runs on your systems or theirs. What it costs to run each month at the volume you have stated, priced against your numbers rather than their example. The day rate afterwards, held for a stated period. What it costs to add capacity later, and what it costs to leave, including getting your data out in a form somebody else can use.
- The source code, the trained model, the test examples and the written instructions for running it, all named as yours in the contract.
- A handover period with your own staff working alongside theirs, and a test at the end that your team can run it without them.
- Prices held for the connections into your existing systems, since that is where the cost usually moves.
- The right to stop at the end of the first stage without penalty.
If the ending is worth no points in the scoring, every bidder will price it accordingly, and they will be right to.
Make the bids comparable
If one supplier includes the monthly running cost and another leaves it out, you will compare a large honest number against a small dishonest one and reward the wrong behaviour. Publish the assumptions everybody has to price against: how many users, how many questions a day, how many of your existing systems have to be connected, over how many years.
Then ask for the prices back in a shape you can lay side by side. It sounds like administration. It is the difference between a decision and a guess.
Award it in two stages
For anything substantial I would award a short paid first stage to two suppliers rather than the whole thing to one. A few weeks each, same brief, real data, with the right to stop at the end. It costs a fraction of the build, and you learn how each of them behaves when something goes wrong.
Government and board processes usually allow this. It is worth asking before assuming they do not.
If you are drafting one and want somebody to read it for the places a supplier could stand, that takes about an hour. We write these specifications and scoring sheets as a piece of work in their own right, and we resell nothing and take no margin on what gets bought under them.
Working through this on a live programme?
A 45-minute call with the engineer who would run the work. We will tell you whether AI is the answer, including when it is not.