DEV Community

Micky Irons
Micky Irons

Posted on

AI Disclosure in Public Sector Tenders: What's Required?

There is no blanket duty. PPN 017 gives UK contracting authorities optional example questions asking whether AI helped write your bid and whether AI will deliver the service. Those questions are for information only and should not be scored, so an honest declaration should not cost you the contract. Answer plainly and keep the evidence.

Do suppliers have to disclose AI use in public tenders?

No general legal duty sits on you to volunteer it. Disclosure arises when the buyer asks, and under PPN 017 asking is optional for the contracting authority.

PPN 017, Improving Transparency of AI Use in Procurement, replaced PPN 02/24 for procurements commencing on or after 24 February 2025. It sits alongside the Procurement Act 2023 rather than creating a new statutory obligation. What it does is hand in-scope authorities a set of example questions they can drop into a tender when they want to understand how AI is being used, both in the writing of the bid and in the delivery of the contract.

So the practical answer depends on the pack in front of you. Read the tender documents. If the AI questions are there, answer them. If they are not, you are not obliged to write an unprompted essay about your tooling. What you cannot do is answer dishonestly. A false statement in a tender response is a far larger problem than the AI use it was covering up.

What does PPN 017 actually ask?

The example questions sit in Annex B of the notice, and they run in two directions. One set asks whether AI was used to create the tender response itself. The other asks whether AI will be used in delivering the goods or services you are proposing.

Expect wording along those lines: did you use AI to build this submission, and if so where and how. Then: will AI form part of what you deliver, and if so what does that mean for the authority. The notice is also clear that suppliers' use of AI is not prohibited during the commercial process, which tells you a good deal about the intent behind the whole exercise. It is a transparency mechanism, not a filter.

Nothing in Annex B asks you to hand over model weights, prompt libraries or source code. It asks you to be clear about where the machine sat in the process, and who was responsible for the output.

Are the AI disclosure questions scored?

No. The Annex B questions should not be scored or taken into account when assessing a tender, and should be used for information only. That is the notice's own position, not my interpretation of it. Contracting authorities are also told not to discriminate between suppliers in how they use the questions or how they read the answers.

There is a counterweight you need to hold at the same time. An authority can still ask and evaluate further AI questions of its own, where those questions are specific to its requirement and compliant with procurement law. Where it does that, whether and how the questions will be scored has to be set out in the tender notice or the associated tender documents.

The test is therefore simple, and it is a reading test. Work out which category each question falls into before you draft the answer. If it is the Annex B transparency question, it is information. If it is a bespoke question about how AI will operate inside the service, and the documents say it carries marks, treat it like any other scored response and evidence it properly.

Will declaring AI use hurt your bid?

It should not, and the notice is explicit on that point. The risk that genuinely loses contracts is a different one: an answer that reads as though you do not know what your own system does.

Three patterns do the damage. The first is vagueness, such as "AI was used for drafting support" with nothing after it. The second is over-claiming, where a supplier describes a level of autonomy it cannot demonstrate when asked. The third is contradiction, where the AI answer says one thing and the security questionnaire or the data protection schedule says another. Evaluation panels read those documents side by side, and an inconsistency between them is the one thing that will pull a non-scored answer into a scored conversation about your reliability.

Buyers in regulated sectors are long past being startled that AI exists. What unsettles them is a supplier who cannot say where the data went, or who approved the output.

What should a good disclosure answer say?

Name the tool, name the task, name the person who checked the result. Three sentences of that beats a page of hedging.

A structure that works: state whether AI was used; state what it was used for, such as research summarisation, first drafts or formatting a response matrix; state what it was not used for; state your review process. If a named bid manager read and owned every word before submission, say so. If your policy forbids putting the authority's own documents into an external service, say that too, because it answers the question the buyer is really asking, which is where their information travelled.

Then keep that answer consistent across frameworks. Bid libraries drift. A three-year-old paragraph claiming you use no AI at all, resubmitted in 2026 by a team that plainly does, is exactly the inconsistency that turns an administrative question into a diligence problem.

What if AI will deliver part of the contract?

Then disclosure stops being administrative and becomes part of the technical answer. The buyer is no longer asking about your bid-writing habits. They are asking what happens to their data and their decisions once the contract starts.

Four things need answering. Where processing physically happens, and on whose hardware. What leaves the estate, if anything. Which decisions the system takes by itself, and which wait for a person. And how anyone establishes, months later, what the system actually did.

That last one is where most answers thin out, and it is why we built Mickai the way we did. The Sovereign Intelligence Operating System runs on hardware the customer owns, offline where that is the requirement, with no data egress. Every consequential action is sealed in an Open Audit Record under ML-DSA-65, the post-quantum signature scheme NIST published as FIPS 204 in 2024. An auditor exports a record and verifies it offline with a public key, using tools that are not ours.

That makes the record tamper-evident, which is a different claim from tamper-proof, and the distinction is worth spelling out in a tender. Nothing stops someone altering a file. Tamper-evidence means that if they do, verification fails and the alteration becomes visible. A supplier promising records that cannot be altered is promising something no cryptography delivers. A supplier offering verifiable ones is describing a property the buyer's own team can test.

Consequential actions in our system also wait for a named person to approve them. That is a deliberate design choice aimed at the accountability question procurement keeps asking, because the answer to "who decided this" should be a name rather than a model.

None of this is an argument against cloud. Cloud remains the right answer for a great deal of non-regulated work, and I have no quarrel with the companies building the compute and cloud layer. The argument is narrower than that. It is against the assumption that a regulated organisation must rent its intelligence, ship its data offsite and take a vendor's word for what happened to it.

What evidence should sit behind the answer?

Assume the answer gets checked, at award or at the first audit. Write it so it survives being checked.

The minimum set is small. A dated internal AI use policy. A list of the tools your bid team may use and the ones it may not. The data classification rules that govern what can be pasted into an external service. Named sign-off on the submission itself. Where AI forms part of delivery, add the deployment architecture, a data-flow description, the human approval points, and a sample audit export the buyer can verify independently. That sample does more work than any paragraph of prose, because it converts a claim into something testable.

For the governance side, the ICO's guidance on AI and data protection is the right starting point. For the security side, the NCSC's guidelines for secure AI system development. Cite them in your own documents only where they genuinely apply to what you are offering.

One last point on tone, and I will use our own position as the example. Our closed beta is open and one regulated company is onboarding as a design partner. On document handling I would rather be precise than impressive: a local OCR runtime has read scanned PDFs in controlled tests, and the extraction and ingestion integration into SIOS is still being completed. That is the kind of sentence I want in a tender answer. It tells the buyer what works today and what does not, and it costs a great deal less than being found out later.

Frequently asked questions

Do we have to say we used AI to write our bid?

Only if the tender asks. PPN 017 gives contracting authorities optional example questions on exactly that point, so some packs contain them and some do not. Where the question appears, answer it honestly and specifically: the tool, the task, the human who reviewed the output. Where it does not appear, there is no duty to volunteer a statement, but never deny use that occurred.

Will declaring AI use lose us marks?

Not for the Annex B transparency questions. PPN 017 states they should not be scored or taken into account when assessing a tender, and are for information only. Authorities are also told not to discriminate between suppliers in how they use those questions. A separate, requirement-specific AI question may carry marks, but the tender documents must say so.

Which procurement policy note covers AI disclosure in tenders?

PPN 017, Improving Transparency of AI Use in Procurement. It replaced PPN 02/24 for procurements commencing on or after 24 February 2025 and sits alongside the Procurement Act 2023. Annex B holds the example questions covering AI in bid preparation and AI in contract delivery. Read the notice itself before drafting a standard answer for your bid library.

What if AI will be used to deliver the contract itself?

Then treat it as a technical answer rather than a declaration. Say where processing happens and on whose hardware, what data leaves the estate, which decisions run without a person and which wait for named approval, and how an auditor reconstructs what happened months later. A verifiable audit export the buyer can check independently carries more weight than any written assurance.

Do private sector buyers ask the same questions?

Increasingly yes, though without a common template. Regulated firms tend to fold AI questions into security questionnaires, supplier due diligence and data protection schedules instead of a separate annex, and those versions are often scored. The practical effect is that one well-evidenced public sector answer, kept current, does most of the work across both routes.


Related briefings

Procurement and defence

UK AI regulation

Part of a series of 60 briefings on deploying and governing AI in UK regulated organisations, archived with a DOI at 10.5281/zenodo.22975756.

Evaluating AI for a regulated organisation? Mickai runs on hardware you own, offline. Consequential actions wait for a named person to approve them, and what the AI did is sealed into a signed record an auditor can check without us. Applications for the invitation-only closed beta are open. Apply for the closed beta.

Written by Micky Irons, founder and chief executive of Mickai LTD.

Top comments (0)