How to specify AI in a tender

A Danish municipal tender we read recently specifies that user logs are retained for six months and then deleted, that the product integrates with Azure AD for staff and MitID for citizens, that it exposes a REST API callable from the case system, and that the training environment is separated from production. Precise, testable, and clearly written by someone who has run a procurement before.

The AI requirement in the same document is one sentence: the product shall offer AI features that comply with the applicable rules of the AI Act. The system supports citizens looking for work.

That sentence hands the buyer's most consequential decision to whoever wins. It is what people write when they know the topic matters and have no template for it. This is the template.

Specify properties, not architecture

The most common failure in the other direction is a requirement that names a technology. On-premises deployment, a specific model, a named vector database. Each of those decides the architecture on behalf of a need that was never written down, and it excludes suppliers who could have met the need more cheaply.

Write what must be true of the running system. Let suppliers propose how.

Traceability

Require that for any output the system can produce the sources it drew on, the model and version that generated it, and the identity of the user or process that requested it. Require a retention period for that record, stated in months, in the same way log retention is already stated.

Ask for the evidence at tender stage: a description of what is captured per request, and a sample record.

Access and permissions

Where the system reads from existing content, require that retrieval respects the permissions of the source systems, and that filtering happens before ranking rather than after. Require a maximum staleness for permission changes, expressed in minutes or hours.

Evidence: a description of how permissions reach the index, and how revocation propagates.

Human control

Require that a named role can reject or amend an output, that the interface offers that path rather than only a view, and that overrides are recorded. Where the system may act unattended, require that the boundary is configurable by the authority rather than fixed by the supplier.

Evidence: a walkthrough of the override path in the demonstration, not a paragraph in the response.

Evaluation and change

This is the clause almost nobody writes and the one that matters most over a five year contract. Require that the supplier states how the system is evaluated, that the authority receives the results on a defined cadence, and that a change of model or a material change of behaviour is notified in advance with evidence that the evaluation still passes.

Without it, the system you accepted at go-live can become a different system in March and nobody has to tell you.

Data handling and exit

• Which jurisdiction governs access to the content the system processes, and whether any foreign disclosure obligation applies to the supplier or its subprocessors
• Whether authority content is used to train or improve models, with the default set to no rather than left to the supplier's terms
• What is returned on exit, in what format, and within how long, including the retrieval index and the traceability records rather than only the source documents
• Whether the authority can move to another supplier or run the system itself without rebuilding the integrations

A requirement that names a technology has already chosen the architecture. A requirement that names a property leaves the architecture open and the need precise.

Where each clause belongs

Traceability, access, human control, and evaluation belong in the requirement specification, because they are properties the solution either has or lacks and they should be evaluated in the award.

Notification of model change, evaluation cadence, training use of content, and exit belong in the contract, because they govern behaviour over the term rather than at the point of delivery. Splitting them this way also stops the requirement specification becoming a legal document that suppliers answer with boilerplate.

What we recommend

Replace the single AI Act sentence with the five property groups above and ask for evidence rather than assurance. Every one of them is testable at tender stage, and a supplier who cannot describe what their system captures per request is telling you something useful.

Keep naming the regulation as well. It sets the frame. It just cannot be the whole requirement, because it tells the supplier which law applies without telling them what to build.

What should an AI requirement in a public tender actually contain?

Properties the running system must have: traceability of outputs to sources and model version, retrieval that respects source permissions, a human override path that is recorded, an evaluation regime with notification before model changes, and defined data handling and exit terms. Each is testable at tender stage.

Is it enough to require compliance with the EU AI Act?

It sets the frame and should be stated, but on its own it tells a supplier which law applies without telling them what to build. The obligations that follow from the Act are properties of a system, so the requirement specification has to name those properties for them to be evaluated in the award.

Should a tender require on-premises deployment?

Usually not. That names an architecture in place of a need. Write the need instead: which jurisdiction governs access, whether foreign disclosure obligations apply, how model versions are controlled, and what the exit path is. Suppliers who can meet those more cheaply than by moving hardware should be allowed to.

Which AI clauses belong in the contract rather than the requirement specification?

Anything governing behaviour over the term: notification before a model change, evaluation cadence and reporting, whether authority content may be used for training, and exit obligations. The requirement specification should carry the properties evaluated at award.