Yes, provided the documents never leave infrastructure you control. Supplier contracts and tender responses arrive under confidentiality terms, so the risk is not AI itself but sending commercially sensitive material to an outside service. A deployment on hardware you own removes that transfer. Mickai indexes those documents into private knowledge bases locally.
Can procurement teams use AI on supplier contracts?
Yes, and many teams already do, often ahead of any policy that covers it. The constraint is not the analysis, it is the transfer: a supplier contract or a tender response is another organisation's commercial information held by you under obligation, so putting it into a service you do not control is a disclosure decision before it is a productivity decision.
A tender box holds rate cards, subcontractor lists, margin assumptions and the working detail of every company that bid. You hold all of it under terms. That is the real context for this question, and it is why the answer turns on infrastructure rather than on capability.
The work itself suits machine reading well. Comparing thirty bids against the same evaluation criteria. Finding the indemnity cap and the liability carve-outs across a framework and its call-off contracts. Checking whether a counter-signed version quietly moved payment terms from thirty days to sixty. Pulling every clause that mentions data location. This is slow, repetitive, high volume reading where a human is expensive and inconsistent, and where the cost of missing something surfaces eighteen months later.
So the question is not whether to use the tool. It is where the document sits while the tool reads it.
What do confidentiality terms in tenders actually say?
They usually bind you as well as the bidder, and they usually restrict onward disclosure to anyone outside a defined circle. Read the instrument in front of you rather than assuming what it permits.
The common pattern in a UK invitation to tender runs three ways. Disclosure is limited to employees, officers and professional advisers who need the information to evaluate the bid. Anyone you do disclose to must be placed under equivalent obligations. Use is restricted to the purpose of the procurement and nothing else. A general purpose AI service sits outside that circle. It is a third party, and in data protection terms usually a processor or sub-processor you never declared.
Then there is the end of the process. Most packs require return or destruction of the material once the competition closes. That is hard to honour if content has been absorbed into logs, caches or training corpora you cannot inspect. Asking a vendor to delete something is not the same as being able to show that they did.
Is a bidder's pricing safe in an AI tool?
It depends entirely on whether the system retains the figures and who inside your own organisation can reach them. Those are two separate failures and both matter.
A bidder's rate card is the most sensitive thing in the box. If it leaks, you have not only breached a duty to one supplier. You have damaged the integrity of the competition, which can mean standing down the evaluation and running it again, with the delay and the challenge risk that follows. External retention is the risk everyone talks about: the vendor keeps a copy, their staff can read it, the content informs a model. Internal over-sharing is the risk that tends to bite first. A category manager asks a broad question and gets an answer assembled out of a rival bidder's submission.
Public sector buyers have a further reason to care. Section 43 of the Freedom of Information Act 2000 allows information to be withheld where disclosure would, or would be likely to, prejudice the commercial interests of any person. An exemption is no use against material that has already left the building.
What does UK procurement guidance say about AI use?
Current guidance addresses transparency about AI in a procurement rather than granting or withholding permission for buyer-side contract review. Procurement Policy Note 017, which replaced PPN 02/24 for procurements commencing on or after 24 February 2025, deals with improving transparency of AI use in procurement, including how bidders disclose their own use of AI when preparing a response.
Which means your permission question is answered somewhere else: in the confidentiality terms you signed, and in data protection law. The ICO's guidance on AI and data protection sets out how UK GDPR applies to these systems, that accountability stays with you as controller, and that a data protection impact assessment is expected where processing is likely to be high risk. Tender documents routinely carry personal data. Named key personnel, CVs, referee details, sometimes vetting status.
On the build and operate side, the NCSC's Guidelines for Secure AI System Development treat an AI system as a system: secure design, secure development, secure deployment, then secure operation and maintenance, with explicit attention to the supply chain. Read alongside your own terms, those documents give you a defensible position without anyone having to invent one.
What does a private deployment change?
It removes the transfer, and the transfer is the part you cannot argue your way out of. The Mickai Sovereign Intelligence Operating System (SIOS) runs on hardware the customer owns. It is capable of operating offline, and it does not send data out. The contract stays inside the estate, so consent to disclose to a third party does not arise in the same form.
The second change is the record. The Open Audit Record seals every consequential action 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. The distinction matters: this is tamper-evident, not tamper-proof. Nobody can stop a sufficiently privileged person altering a record. What you can do is make the altered record fail verification, which turns a silent edit into a finding.
The third change is who decides. Consequential actions wait for a named person to approve them, and the approval is recorded against that person's identity. Reading a clause does not need that. Disqualifying a bid does.
SIOS carries 63 studios in total, 14 production-ready at launch and 49 in development, drawing on 50 specialised models. The closed beta is open, with one regulated company onboarding as a design partner. One honest caveat for this use case, since procurement runs on scanned paper: a local OCR runtime has read scanned PDFs in controlled tests, and the extraction and ingestion integration inside SIOS is still being completed. I would not build a scanned-archive workflow on it today.
How do you control who sees which supplier's documents?
By scoping the knowledge base and the permissions before documents go in, then testing what the system actually returns. Private knowledge bases can be separated per category, per framework or per individual competition, so an evaluator on one lot is not working against a corpus that includes another lot's submissions.
Answers draw on the passages the person is permitted to see. That is a control, not a guarantee, and it deserves the same treatment as any other access control. Have someone attempt questions from an account that should not have access, ask for things you know sit in the restricted set, and read the audit record afterwards to see what was retrieved and by whom. If your evaluation model depends on separation between commercial and technical scorers, build that separation into the system instead of leaving it to an instruction in a briefing note.
What should a procurement AI policy cover?
Three things, in order: where documents may go, who approves an outcome, and what gets recorded. The rest is detail.
A workable policy names the categories of material in scope, including drafts and supplier correspondence. It states the transfer rule in one line: which systems may hold tender material, and which may not. It defines permission boundaries per competition. It requires a named human decision for anything that affects a supplier's position. It sets retention so destruction obligations at the close of a competition can actually be evidenced. It says what you will tell bidders about your own use of these tools. And it carries a review date, because the systems move faster than the paperwork.
None of this is an argument against cloud. Cloud remains the right answer for a great deal of work that is not regulated, and the organisations building the compute and cloud layer are doing hard engineering well. What I dispute is narrower: the assumption that a regulated buyer has to rent its intelligence, ship commercially sensitive documents offsite and take a vendor's word for what happened to them afterwards. For a tender box, that assumption is no longer necessary.
Frequently asked questions
Can we upload supplier contracts to an AI tool?
Check the confidentiality terms attached to that contract first. Most UK tender packs limit disclosure to named categories of people and require equivalent obligations on anyone else who sees the material. A hosted service is a third party under those terms. A deployment on infrastructure you own avoids the disclosure question, because nothing is transferred.
Is bidder pricing safe inside an AI system?
Only if you know the system retains nothing outside your control and that access inside your organisation is scoped. A rate card reaching the wrong evaluator can compromise the competition itself, not just one supplier relationship. Separate the corpus per lot, require named approval for decisions, and keep a signed record of what was retrieved and by whom.
Does using AI on tender documents break confidentiality?
Not in itself. Reading a document with software you control is normally within the purpose for which the bidder gave it to you. Disclosure to an outside service that keeps or learns from the content is the part that can breach the terms. The location of the processing decides the answer, not the use of AI.
Can we stop one category team seeing another supplier's documents?
Yes, by building the separation into the system rather than into a briefing note. Knowledge bases can be scoped per category, framework or competition, and answers draw on passages the person is permitted to see. Treat it as an access control: test it from an account that should fail, then read the audit record.
Do we need a policy before letting the team use AI on contracts?
Yes, and it can be short. Name the material in scope, state which systems may hold it and which may not, define permission boundaries per competition, require a named human decision for anything affecting a supplier's position, set retention that lets you evidence destruction at close, and give the policy a review date.
Related briefings
Procurement and defence
- Buy AI Through G-Cloud and Government Frameworks: Guide
- AI Disclosure in Public Sector Tenders: What's Required?
- AI Bid Evaluation in Public Procurement: Is It Lawful?
- AI Supplier Contract Clauses: A UK Buyer's Checklist
- JSP 936 for AI Suppliers: What the MOD Now Requires
UK AI regulation
- Is There a UK AI Act? How the UK Regulates AI Today
- AI Cyber Security Code of Practice: Who It Applies To
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)