Procuring AI through a tender: requirements you must formulate in advance
Procuring artificial intelligence within the public and semi-public sector differs fundamentally from purchasing standard information technology or generic software licenses. Public and semi-public organizations such as municipalities, provinces, healthcare institutions, educational institutions, and executive agencies operate in a field where legislation, public accountability, and public values carry significant weight. When such organizations want to integrate artificial intelligence into operational practice, the need arises to formulate sharp, verifiable, and sector-specific requirements as early as the initial phases of the procurement cycle. Correcting vague or overly noncommittal criteria after the fact leads in practice to legal risks, budget overruns, and unwanted dependencies on market parties.
The public audience often follows technological developments through mainstream media, but sometimes lacks the in-depth operational experience needed to set up a complex procurement process correctly. To understand how governments currently deal with this technology, it's advisable to explore the general landscape via AI in Dutch government: the current state of affairs, which covers the current state of affairs within the Dutch government.
The need for requirements formulated in advance
In traditional procurement practice, the focus is often on basic functional ingredients and the lowest price. With artificial intelligence, this mechanism backfires. Models and data flows change continuously, and the impact of decisions supported by systems affects citizens' fundamental rights directly. If an organization only discovers after the contract is awarded that the delivered software provides no insight into the underlying decision-making, an unbridgeable gap arises between the statutory duty of accountability and the technical reality.
Formulating requirements in advance ensures a level playing field for all bidders and prevents later disputes about the scope of the delivered services. It forces the organization to think internally about exactly what is being asked for. After all, anyone who asks for 'modern technology' or 'smart innovation' gets a wide range of interpretations back from the market, ranging from simple scripts to complex, opaque systems. By setting hard requirements in advance for manageability, transparency, and data quality, the contracting authority filters out unsuitable solutions at the gate.
For a broad orientation on the various solutions available on the market, procurement professionals can use AI tool selector to see which types of systems fit specific public-sector challenges.
The EU AI Act as risk classification and foundation
European regulation surrounding artificial intelligence forms the primary legal and policy anchor point for public and semi-public procurement. The law classifies systems based on risk: from unacceptable risk to high risk, limited risk, and minimal risk. Public organizations must explicitly determine in the tender request which category the procured system falls into. This directly determines which obligations apply regarding data quality, human oversight, technical documentation, and robustness.
A system used to assess citizens, build risk profiles in the social domain, or allocate public funds falls, almost without exception, into a stricter category. The procuring organization must document in the tender specification that the supplier must be able to demonstrate that the system meets the requirements associated with that specific risk class. Failing to determine this classification in advance results in systems being purchased that afterward may not be used for their intended purpose.
Anyone wanting to understand how this European legislation is structured and which obligations it entails in practice can consult the explainer at EU AI Act explained.
In addition, it's useful to use targeted tools to determine the correct risk category. A practical first step in this analysis can be found at EU AI Act category checker tool to determine which category a proposed application falls under.
Functional and technical requirements in the tender
In addition to the risk classification, contracting authorities must include in-depth functional and technical requirements in the program of requirements. These requirements cannot be noncommittal; they must be formulated in a measurable and verifiable way. This calls for specifications across several domains:
- Data management and data quality: Requirements regarding the origin, representativeness, and objectivity of the training data to prevent discrimination and bias.
- Transparency and explainability: The requirement that the system make it transparent how a particular outcome or recommendation was reached, so that officials or caseworkers can verify it.
- Logging and audit trails: Mandatory logging of decisions, model changes, and input data, so that an independent review or audit can take place afterward.
- Integrations and API standards: Technical requirements that guarantee the application integrates seamlessly with the existing national or municipal IT infrastructure and supports open standards.
- Model management and updates: Agreements on how the model evolves, who is responsible for retraining, and how it is ensured that the system's behavior doesn't imperceptibly drift.
Selecting the right market party that can meet such technical preconditions requires carefully weighing the supplier's background. More background information on the selection procedure for suitable parties can be found at AI vendor selector.
Legal preconditions, contracts, and SLAs
Legal safeguards in the contract and the Service Level Agreements (SLAs) are where the ambitions set in advance are translated into binding agreements. Many standard supplier terms are written from a commercial perspective in which the supplier's liability is limited as much as possible. Public and semi-public organizations cannot agree to this, because they are bound by public law norms and legislation.
The contract must, among other things, document agreements on intellectual property of the generated data, confidentiality, data security, and compliance with privacy legislation (GDPR). The performance indicators in the SLA must also be specifically tailored to AI systems. Think of agreements on maximum response time, model availability, uptime, and recovery times in case of disruptions or incorrect predictions.
For an in-depth overview of the contractual aspects and how to set up specific service levels for this technology, you can turn to AI contracts and SLAs.
Exit strategy, continuity, and vendor lock-in
One of the biggest risks in procuring advanced technology is the emergence of a strong dependency on a single supplier, also known as vendor lock-in. If a municipality or healthcare institution houses all its data flows, logic, and processes within a closed system of an external party, switching to an alternative eventually becomes practically impossible or disproportionately expensive.
To prevent this, contracting authorities must already require a solid exit strategy during the tender phase. This means the supplier is obligated, upon termination of the agreement, to transfer all data sources, trained models, documentation, and configuration settings to the organization or a successor party in an open, readable format. Continuity arrangements, such as an escrow arrangement for the source code or the underlying parameters, provide additional assurance that service delivery won't stop abruptly in the event of the supplier's bankruptcy.
Proportionality and verifiability
Every requirement a public organization sets in a tender must comply with the principle of proportionality. This means the requested criteria must be reasonably proportionate to the nature, scale, and risk of the assignment. Imposing disproportionately heavy administrative or technical requirements on small-scale suppliers can unfairly restrict competition, while the absence of sufficiently strict requirements for high-risk applications endangers public safety.
Formulating proportional requirements also means the organization must be able to demonstrate how it monitors compliance with those requirements. This calls for active monitoring during the execution phase. It's not enough for the supplier to declare that the requirements are met; the contracting authority must secure the right to conduct spot-check audits, have source code or model performance reviewed by independent experts, and take enforcement action based on pre-established sanctions when deviations are found.
Fitting into the broader procurement cycle
Formulating AI-specific requirements doesn't stand on its own; it's an integrated part of the organization's overall procurement cycle. This process follows a logical structure that starts long before the tender is actually published:
| Procurement cycle phase | Action by the public organization | AI-specific point of attention |
|---|---|---|
| 1. Preparation | Needs assessment and market exploration | Determining whether AI is necessary and performing risk classification |
| 2. Specification | Drawing up the program of requirements | Formulating measurable requirements for logging, bias, and explainability |
| 3. Selection & award | Evaluating bids | Assessing the technical and ethical reliability of the supplier |
| 4. Contracting | Documenting legal agreements | Including specific SLAs, data rights, and exit strategy |
| 5. Management & evaluation | Monitoring performance | Conducting periodic audits and checking for model drift |
Rules of thumb in practice show that the preparation and specification phase for complex technology often takes considerably more time than for standard deliveries. Always verify these timelines for your own specific organization and context.
Practical checklist
To ensure all necessary elements are included when drawing up the tender documents, procurement professionals and project leaders can use the checklist below:
- Has the risk classification under the applicable European frameworks been determined in advance and included in the tender request?
- Are the functional requirements formulated as measurable and verifiable criteria rather than noncommittal qualitative wishes?
- Does the program of requirements contain clear specifications regarding data quality, bias prevention, and transparency of decision-making?
- Are there obligations included for extensive logging and audit trails to ensure verifiability?
- Are the legal preconditions, including intellectual property and GDPR compliance, covered in the contract terms and SLAs?
- Is a clear exit strategy and continuity arrangement included to prevent vendor lock-in?
- Has the principle of proportionality been applied by weighing the weight of the requirements against the actual risk of the application?
- Is the right to independent review and audits during the execution phase contractually documented?
