AI public procurement: where manual review misses collusion
Manual procurement analysis works confidently while there are dozens of procedures: a reviewer reads the documentation for each one and catches inconsistencies by eye.
In a stream of thousands of lots per period, only a tiny share can be reviewed — the rest is covered by formal criteria: there is a complaint, a deviation in documents, exceeding a threshold. The volume grows, but the review staff does not.
Violations that are not visible within a single procedure slip through: rotation of winners among connected suppliers, synchronized price reductions down to the last decimal place, bids from the same template, matching contacts and details among formally independent participants.
Individually, each sign of cartel collusion looks like statistical noise, but together they produce a stable picture.
Therefore, collusion detection in public procurement is built not around a lot, but around a graph of connections: supplier — customer — lot — time.
Anomalies in procurement data manifest over distance: the signal is spread across regions, platforms, and periods, and becomes noticeable only when comparing hundreds of procedures.
Data from the Unified Information System in the Field of Procurement provide the basis for this, but require normalization — matching names, addresses, and participants — otherwise connections break.
The cost of an error here is not in a missed lot, but in the accumulated risks of procurement procedures: contracts go to a single circle of suppliers, competition becomes formal, and violations are recorded after the fact. We explain how this is closed by a model that handles the entire stream, not a sample.
What AI gives in public procurement: measurable effects of control
Detection is built on a set of signs, not just one: matching participants by details, shared subcontracting chains, price deviation from the market corridor, template documentation among different customers.
The output is a risk score with an explanation, not a binary verdict: the reviewer sees which signs were triggered and with what weight.
Hence the measurable effects. The share of detected anomalies on a labeled sample is higher than with manual review: rules catch combinations that a person cannot keep in memory.
The time to review one procurement is reduced from hours of parsing a document package to minutes of working with a ready risk card.
Repeatability of decisions is ensured by a unified register of risk signals — the verdict is stored together with the signs and the version of the rules.
Two reviewers on the same data arrive at the same conclusion, and discrepancies are explained by signs, not by the specialist's experience.
Classes of violations that were previously missed due to volume are covered: cartel agreements, affiliation of the customer and the participant, splitting of a procurement, overstatement of the initial price.
The check runs across the entire sample, so reducing the number of missed risks provides coverage rather than tightening the cutoff threshold.
The data source is open information from the Unified Information System in the Field of Procurement and related registers: bidding history, complaints, contract terminations.
The model is further trained on review outcomes and gradually shifts from formal matches to signs that are confirmed in practice.
Options for building the system: rules, statistics, learning
The choice of detection mode is determined not by the "sophistication" of the model, but by the maturity of the customer's data: whether there is a history of confirmed violations with labels, how stable the procurement reference data is, how often the regulatory framework changes.
On weakly labeled data, a complex model produces unstable results and unexplainable triggers, and in public procurement a decision must be defended before oversight — therefore explainability here is not a wish but a requirement for system design.
| Approach | When it fits | Limitations |
|---|---|---|
| Rule-based checks | A transparent start is needed: explicit signs — affiliation, template matches in documentation, anomalous submission deadlines | Catches only what is described in advance; can be bypassed by changing the scheme; the number of rules grows along with false positives |
| Statistical anomaly models | There is a volume of history and deviations need to be found without labels | They give a deviation from the norm, not a violation; sensitive to seasonality and changes in reference data |
| Machine learning models | A labeled set of confirmed cases has been accumulated | Require regular retraining and drift control when participant behavior changes |
| Hybrid detection approach | A working loop is needed on incomplete data | More expensive to maintain: aligning signals and tuning thresholds between layers |
The practical path is to start with rules and statistics, and connect learning as confirmed cases accumulate: this way the system delivers results from the first weeks and does not degrade.
Each trigger is ranked by the aggregate of signals, and the expert sees why the object entered the sample — this removes the main limitation of detection methods.
How we implement procurement analysis: stages of engineering work
Procurement is a stream of notices, protocols, and results, where a violation is almost invisible in a single record: it manifests in the connection between participants, prices, and deadlines.
Therefore, work begins not with the model but with data inventory — it determines which signs can be calculated reliably at all.
- Audit of procurement data. We collect notices, protocols, commission compositions, and price history for homogeneous goods, and check completeness and duplicates. The output is a map of sources and a list of fields missing for the signs.
- Labeling of violation signs. Together with your experts, we describe what we consider a risk: a sharp price reduction, a recurring set of participants, a single bid, a short submission window. Each sign receives a formal definition and a calculation rule.
- Consolidation of signs into a single loop. Some signals are caught by hard rules, others by deviation statistics for homogeneous procurements. We remove overlaps so that one case does not produce three triggers.
- Tuning trigger thresholds. We select the threshold based on data: at what value the share of confirmed cases grows while the flow of false positives remains within the limits the service can handle.
- Pilot on historical procurements. We run the system on closed periods and compare the output with known review outcomes — accuracy is visible before the solution begins to affect current procedures.
- Handover of the model to operation. We provide the configuration of signs, thresholds, retraining regulations, and analysis of typical triggers, and train analysts to read the output without our support.
The order of the stages is not accidental: each next one relies on the artifacts of the previous one, so the pilot does not turn into a demonstration, and the thresholds remain explainable for reviewers.
System handover: rule registry, data schemas, regulations
We hand over the system not as a built application, but as a set of artifacts by which your team can read, modify, and develop it without us.
The check is simple: an engineer who did not participate in the project uses these documents to stand up an environment, runs historical procurements, and gets the same signals.
The following is handed to the customer.
- Registry of rules and signs. Each trigger is broken down into a sign, threshold, and weight; rules are edited in configuration, without changing code — false signals are removed in a targeted way.
- Data schema and labeling. Description of procurement data sources, fields, and connections between procedures and participants; a labeling log with examples of "signal / not signal" and recorded discrepancies between labelers.
- Regulations for reviewing triggers. Who reviews a signal, within what timeframe, and by what criteria; what they record in the decision; when the signal is archived and under what conditions it is raised again.
- Access policies for procurement data. Roles, permission matrix, retention periods, anonymization of samples for external contractors and reviews.
- Model documentation. What is fed as input, what is produced as output, where the boundaries of applicability are, and which control sets to run after each update.
- Change log. Who approves a new version of the rules or model, how it is introduced, and how it is rolled back if quality on the control sample has dropped.
Acceptance is based on reproducibility, not on a demonstration: identical procurements are run on your environment, and decisions are compared with reference ones. We resolve discrepancies before handover, not after.
Practice: how the system found signs of collusion in a sample
The pilot was launched for a regional procurement operator — the Center for Competitive Procedures, through which several thousand procedures pass per quarter.
Before implementation, risk analysis relied on a manual sample: three specialists reviewed 40–50 lots per month, that is, roughly every fortieth. The rest remained outside control — anomalies were revealed already at the complaint stage, when the procedure had been conducted.
What was changed
The model was trained on historical protocols and "bid — winner — price" connections.
The risk calculation included matching details and network addresses of participants, template wording, an atypically narrow price reduction, and repetitions of "customer — supplier" pairs.
Signals were separated by levels: critical ones go to the inspector immediately, weak ones accumulate in the procurement card until the sum of signs becomes significant. Implementation — from data export to daily working mode — took seven weeks.
Result
We check the entire stream, not a sample: about a thousand lots per month. The share of confirmed signals grew from one in eight to two in three — inspectors stopped spending time on noise.
Review of one procurement decreased from 3–4 hours to 25–30 minutes, and for critical signals the card is assembled automatically: participant connections, win history, deviations from typical behavior. In the first quarter, 14 materials with signs of cartel agreements were handed over for action.
How does rule-based checking differ from a learning model?
Rules answer the question "is there a formal sign", while the model answers "how much does the behavior differ from typical".
The rule-based loop is deterministic: conditions such as "the same suppliers appear in procurements of the same industry", "bids are submitted at an interval atypical for open competition", "the winner rotates while the set of participants remains constant" are checked directly against data from the Unified Information System in the Field of Procurement.
The same export gives the same result — the conclusion can be presented to a reviewer and defended in a disputed situation.
The limitation of rules is that they describe only already known schemes. Collusion adapts: amounts change, lots are split, new legal entities are created — and the formal sign stops triggering. This is where learning on historical procurements with confirmed violations comes in.
The model evaluates not one condition but a combination of dozens of weak signals: overlapping addresses and contacts, proximity of submission times, similarity of wording in bids, anomalous price reduction dynamics.
The key objection to learning is the opacity of the decision. We close it with an explanation layer: for each anomaly, the system shows which signs raised the score and with what weight, and selects comparable procurements for comparison.
The hypothesis can be challenged, recalculated on another sample, and verified with primary documents, rather than by reference to "that is how the model calculated it".
In practice, the loops work together: rules filter out obviously permissible procurements and record indisputable violations, the model ranks the remainder by risk level, and the analyst reviews the top of the list.
Such a hybrid increases the share of procurements covered by review while reducing false positives — and every conclusion remains verifiable.
Technical doubts: data, false positives, access
The model does not pass a sentence — it ranks procurements by risk signs, and the decision remains with the analyst.
Therefore, the first question during implementation is not "what accuracy" but what data the system learned on, how it is checked, and what happens in case of an error. Below are four doubts that almost always come up.
What to do if exports are incomplete and in different formats?
Departmental exports come in different structures, some fields are empty or filled contradictorily.
We bring them to a unified schema, and we do not erase gaps but mark them with a separate sign — the model learns to distinguish "no data" from "no violations" and does not build a conclusion on emptiness.
How often does the model make mistakes and what about false positives?
We tune the threshold to your workload: it is better to send a borderline case to manual review than to flood analysts with false connections.
Each trigger receives an explanation by signs, the analyst confirms or rejects it, and the labeling returns to further training — the share of false positives decreases from iteration to iteration.
What about personal data of suppliers?
The model uses anonymized signs of connections and procedure parameters, not personal data. Access is delimited by roles, data requests are written to a log, and the retention period is set by policy.
The system is deployed in your environment or in an isolated environment — exports do not go outside.
How is model quality controlled after launch?
We maintain a control sample of past procurements with a known outcome: a version that underperforms on it is not rolled out. We monitor data drift, and if a new version behaves worse, we roll back to the previous one without losing accumulated labeling.
Let's discuss the task: where to start procurement review
You can start the review with a single export, not full access to the system.
Across several procurement periods, you can see which fields are filled, how often conditions change, whether there is a history of edits and related supplier data — this is enough to understand the structure of the array and assess which risks can be detected on it.
The first conversation is about the task, not a technology demonstration: which violations are important first, who reviews signals, what is considered a miss. Based on the discussion, we return with an estimate and a plan.
- Pilot on customer data: we run the model on your export and show which connections of procurements and suppliers it highlights.
- Assessment of the scope of work: how many procurements are processed at a time, whether labeling of historical data is needed, and how much manual review remains.
- Phased implementation plan: what is launched first, what is connected after quality checks on the live stream.
- Connection scheme to your systems: export methods, update frequency, access isolation, and handling of the closed part of the data.
- Quality metrics: share of detected violations, share of false positives, coverage of key scenarios by reviews.
- Regulations for reviewing signals: prioritization of cards, who confirms a violation, where the rationale is recorded.
Describe the task and the format of the data you have — we will return with an estimate of the scope of work and a plan for the first stage. If an export cannot be prepared, we will start with a description of processes and available reports.