Back to latest

Vibe-coding procurement: What works, and what doesn’t

It’s maybe not surprising that public procurement data tends to be one of the most used and reused data sets in government. It’s a trillion dollar market, it’s a dataset often available and fairly well structured, and it provides a fascinating insight into how the government works and spends and who it benefits, whether it’s the businesses that win a contract, or the services, works and goods that citizens need. 

So when AI comes with a promise to revolutionize data, we know it comes to procurement.

Over the past year, we have come across new procurement platforms powered by OCDS and users have reached out to share how they are building procurement tools with the help of AI or that use AI features that are not limited to any one region or market. 

A company in Australia (Demiton) is using AusTender OCDS data and mapping other local sources of procurement information to OCDS, to identify civil works tenders and help suppliers decide whether to bid on opportunities and prepare tender documentation. A procurement expert in the UK, building open data tools using gen AI to track compliance with the new Procurement Act and to make data easier to download. A platform (Fylings) allows users to search for companies across Africa, check their registration status, sanctions and public procurement participation using OCDS data from Tanzania, Kenya, Uganda, Nigeria, Zambia, Ghana and South Africa. A publisher in Greece (Diavgis), that aggregates data from three different public sources and transforms it into OCDS, and provides different analytics and alerts on public procurement to its users. 

We have also heard from more researchers using OCDS for their academic work and accessing the Data Registry. 

That is a great signal. All these tools were built independently, by people solving problems in their own countries, and it shows that more users are finding OCDS data easier to use, and that the ecosystem is growing.

What has changed?

Before AI tools were widely accessible, understanding the data, having the technical skills to begin using it, and finding the resources and expertise to build a tool were real constraints for users to even start using the data, getting insights from it and even more to build tools. 

Generative AI has lowered the cost of building tools that work with procurement data and made data analysis itself more accessible. 

You can now describe to a model what you want, let it handle the technical execution, iterate, review, and have a prototype of a platform working rather quickly. Analysis tasks that used to require specialist skills have become easier, such as extracting structured information from procurement documents, cleaning and structuring the dataset in the format you need for analysis, matching or classifying records, writing or debugging code for analysis, running fast exploratory analysis, and the list goes on. 

However, what hasn’t changed is that you need good quality data to begin with. No model can recover a data field that was never collected or produce reliable outputs if the data quality is bad. 

The constraint has shifted from the cost of building things to the availability and quality of the data itself, as this does not get cheaper as models improve.

Why this makes standardization more valuable, not less

We already discussed why standardization still matters in the age of AI. Our short answer was that “standards are infrastructure, and AI is a powerful vehicle. You don’t stop building roads because you’ve invented better cars. The cars work better when the roads exist”. A data standard like the Open Contracting Data Standard, used by more than 50 publishers globally to publish procurement data, gives AI models a defined structure to populate and a common language to map diverse sources onto. It also gives you a shared schema for understanding what the underlying data means and for validating what comes out.

When we work with governments to publish OCDS, their local procurement data needs to be mapped to the standard. This involves joint work between the local experts who know the data systems and procurement experts who are familiar with procurement legislation, to identify which data elements match which OCDS fields, at a semantic level. We can then provide technical advice on how these fields can be structured. 

In practice, we have found that publishers sometimes use fields in ways the schema didn’t intend or map a local concept onto an OCDS field that doesn’t quite fit. However, having a standard gives you a shared reference point to spot errors more easily, raise them with the publisher, and correct them. Also, by working with different publishers globally across very different legal and administrative systems, we are able to align semantics and encourage publishers to document their publications so others can use them more easily.

Users can then apply similar queries, validation processes, and trust the result whether the OCDS data comes from Paraguay or Uganda. 

Without standardized data available, let’s say you want to build a tool that compares tender opportunities across five countries and gives alerts to suppliers on relevant opportunities to bid according to their sector. If each publisher has its own field names, its own codelists and its own conventions for dates and procurement methods, you can ask a model to reconcile all of that, and it will try and, in some cases, do it accurately. But without access to local expertise and the people responsible for those countries’ systems, as OCP has, it will be hard to spot where the model goes wrong. As for your tool, the model’s misinterpretations can cause suppliers to get the wrong alerts or not notice relevant opportunities.

So is standardized data plus AI all you need?

Not really. While the cost of building and using data has lowered, the cost of making that use effective and getting a tool adopted remains.

We’ve found the most useful tools are built because they serve a clear need and fit into work that is already happening. A good example is Vigía, a tool we built with local partners in Paraguay, that helps small and medium enterprises find public procurement opportunities and flag irregularities in real time. The platform was designed based on the user research conducted with those who would be using the platform and uses OCDS data published by Paraguay’s Procurement Agency (DNCP). In the first 3 months after its launch in 2023, it drew over 3,000 users and helped small businesses win more than US$300,000 in contracts, and it is still in use. 

Meanwhile, other tools built using procurement data didn’t get much traction because they failed to reach or involve users or were not built around a decision process. For example, in 2020 we had included Chile as part of a proof of concept for a multi-country benchmarking tool, since they had good data. It was easy to then adapt our single-country dashboard for Chile, since we had already modeled their data in Qlik for the benchmarking tool – but that single-country dashboard got no adoption (unsurprisingly), because we hadn’t made any design effort. More recently, we supported ChileCompra in building a business intelligence solution, doing user research with the end users and the result is a BI tool that is now being used by ChileCompra to track the participation of SMEs and women-led businesses. 

Cheap building increases the risk of creating many tools that don’t serve real needs, because it is now possible to produce them quickly, make them look visually polished, and make them appear to provide answers. 

In our view, AI is at its best as an assistant rather than something you delegate work to that you have no way of verifying. A model will produce plausible outputs whether or not it understands your data. Analyzing procurement information, it might sum the wrong values, apply the wrong filters, or use incorrect date fields. Detecting those errors, or avoiding those from the outset with better instructions, requires someone who knows both about procurement and the data. 

For instance, when we developed our red flags library, Cardinal, which helps you calculate red flag indicators using OCDS data, we identified data quality issues in the publications we tested and built a command to help users fix them. In the Dominican Republic, we quickly made multiple fixes across millions of rows: filling in default values for currency and item classifications, redacting placeholder values like zero amounts and dummy identifiers, and mapping non-standard codes to standard ones.

This domain expertise has become even more important, as it improves outputs in the first place and makes a real validation process possible. Standardized data and AI will help you get to an answer faster, but knowing if it’s the right one, still requires people. 

How OCP can help

In our work with government partners, civil society and the private sector we have focused specifically on what AI hasn’t made easier: getting good data published in the first place, knowing procurement well enough to tell a right answer from a plausible one, and building tools for users that are embedded into workflows. 

Tell us what you’re building! 

While we aren’t able to provide financial support (we are a non-profit), we are eager to learn more about how you are using open contracting data and what you are building, including what didn’t work. Tell us the use case and who it serves, how the standard helped, and where the data fell short. We document effective use of open contracting data as part of how we measure our own results, and we will publish what we learn. 

You can reach us at [email protected].