The Procurement Paradox in the Age of AI
In every enterprise software negotiation there is a question that arrives punctually, like coffee at the end of a meeting: “How many references do you have?”
A legitimate question, to be clear. The problem is when it comes at the wrong time. For example, immediately after the software has just demonstrated that it works.
The scene, more or less, is this:
— Did the Proof of Concept work?
— Yes, all the KPIs were achieved.
— Security?
— Verified.
— Integration with our systems?
— Done and tested.
— Great. And how many companies like ours are already using it?
— …
And in that silence, everything that has been demonstrated in the field risks weighing less than a slide full of logos.
We ask companies to innovate. Then, when it comes time to choose, we reward those who have the most history. It is a bit like expecting a newcomer to have already won three championships.
The Egg, the Chicken, and the Procurement Department
Every software product in history, including those that are now the market standard, has had a first customer. And that first customer, by definition, had no references to consult.
The mechanism, reduced to its essentials, works like this:
- to obtain the first reference, you need someone willing to be the first;
- to find someone willing to be the first, you ask them for a reference.
If everyone waits for someone else to take the first step, the first reference never arrives. And new technology never becomes mature: it simply becomes old, without ever having been adopted.
A technology that has just arrived on the market cannot have ten years of history. Not because it is worth less, but because it is new. Asking it for a long list of customers means, in practice, asking it not to be innovative.
“Yes, but in our industry?” The Problem Is Not Just About Banks
One might think that the issue only concerns startups or only the banking sector. It is not so.
Even software with many customers will, sooner or later, encounter the most common version of the question: “Do you have a reference in our industry?” And if the answer is yes, the follow-up questions arrive:
- in our industry, but of our size?
- of our size, but in our country?
- in our country, but with the same ERP as ours?
At this rate, the perfect reference is a company identical to ours. At that point, it would probably be us.
The point is simple: no software can have a reference for every industry. Every time it enters a new sector, it becomes “without references” again, even if it has been on the market for years. This happens in manufacturing, utilities, healthcare, Public Administration, retail, energy, and finance.
And it also happens in reverse. Every company that is the first in its sector to adopt a certain technology finds itself in the same position as the first bank: it does not have a “peer” to call.
For a low-code platform this is even more evident. Its value does not lie in the sector in which it has already been used, but in its ability to adapt to the processes of those who adopt it. The fact that it has worked in an insurance company says little about a logistics company, and vice versa. The useful question is another one: does it work on your processes, with your systems?
References and Proof Are Not the Same Thing
References are useful. They say that a supplier has already worked in complex contexts, with demanding volumes, integrations, and security requirements.
But a reference mainly tells you one thing: someone has already used that solution.
A Proof of Concept tells you something different: that solution has worked here, with our data, our processes, and our criteria.
They are two useful pieces of information. But they are not the same information, and they should not exclude each other.
There is another distinction to keep in mind: maturity does not mean innovation. Software that has been on the market for fifteen years can be excellent. One that was created two years ago can be just as good, with a history of adoption that is inevitably shorter. The number of references measures adoption, not the ability to solve your problem.
This does not mean that new is automatically better. It may have more risks, a smaller ecosystem, and require more checks. But the response to those risks should be “let’s evaluate it more carefully,” not “let’s not evaluate it.”
From References to Evidence: the Innovation Gates
The paradigm shift is all in an arrow. No longer references → decision, but a process in which risk is reduced step by step:
- Qualification. The company, technology, architecture, cybersecurity, data processing, business continuity, and exit strategy are assessed. References are collected, but they do not act as a gate.
- Sandbox. The technology is tested in a controlled environment, with defined scope, access, and data.
- Proof of Concept. First, objectives, KPIs, use cases, success criteria, and stop criteria are defined. Then it is tested.
- Security and resilience testing. Depending on criticality: performance, vulnerabilities, logging, monitoring, access control, and behavior in abnormal scenarios.
- Pilot. If the PoC is positive, the process moves to a real but limited scope.
- Contract and industrialization. SLAs, audits, continuity, exit strategy, renewal conditions, and, where necessary, escrow come into play.
It is not an eccentric idea. It is the same logic that the European Commission promotes with innovation procurement and Pre-Commercial Procurement: comparing different solutions and reducing risk in stages, through prototypes, development, and testing, before large-scale adoption.
The result is a decision based on evidence + risk + value + governance. Not on the number of logos on a slide.
Risk Is Managed, Not Delegated to Logos
If the real concern is the risk of relying on an innovative SME, why not manage it with the tools created specifically for this purpose?
Instead of using the reference as the only parachute, the following can be combined:
- PoCs and pilots with measurable KPIs;
- clear SLAs and contractual obligations;
- audit and verification rights;
- continuity, exit, and rollback plans;
- where appropriate, a software escrow agreement.
Escrow involves the deposit with a third party of agreed assets, such as source code and technical documentation, with precise conditions for their release. If the supplier were no longer able to guarantee the service, the customer would not be left empty-handed.
It is not a magic wand. It does not replace due diligence, financial assessment, or cybersecurity checks, and it must be designed according to the criticality of the solution. But it shifts the question: the SME is no longer asked to demonstrate a past it cannot have; instead, safeguards are built to govern the future.
In Regulated Sectors: Resilience Is Verified, Not Assumed
In the financial sector, the issue also has a regulatory dimension. The European DORA Regulation (Digital Operational Resilience Act) places ICT risk management, testing, and control of third-party providers at the center, with precise contractual requirements: SLAs, security, continuity, audit rights, and exit strategies.
The implicit message is clear: resilience is not deduced from how many others use a provider. It is verified and governed, proportionately.
And the same principle applies well beyond banks. Any company that entrusts critical processes to a platform, from healthcare to utilities, has more to gain from measured risk than from a list of logos.
Six Questions More Useful Than “How Many References Do You Have?”
The question about references can remain. But it deserves to be accompanied by questions that actually measure risk:
- What evidence can you produce in our context?
- Which KPIs and stop criteria do we agree on before starting?
- What is the ICT risk associated with the platform, and how do we verify it?
- Which contractual conditions protect us if something goes wrong?
- What is the plan in the event of failure to meet the SLAs or interruption of the service?
- What is our exit strategy?
And, in the end, the question that sums them all up: how do we turn what we still do not know into a risk that we can measure, test, and govern?
From “Trust me” to “Test me”
We are in the age of AI. We ask organizations to reinvent products, processes, and operating models. And then, when it comes time to choose, we risk rewarding above all those who have the longest past.
The first company in a sector to adopt an innovative technology will not have a reference to cite. But it can have a PoC, security and performance tests, KPIs, a pilot, a rollback plan, contractual guarantees, and documented evidence.
In other words, it can have something more useful than a reference: proof.
Innovating responsibly does not mean buying without controls. But neither does it mean rejecting the new because it does not yet have a sufficiently long past. It means stopping asking for trust based on history and starting to build it based on facts.
From “Trust me” to “Test me”.
