Only on infrastructure you control. MOD contract information carries confidentiality conditions such as DEFCON 531, which limit disclosure to the people who need to know. Sending it to a hosted AI service is a disclosure you cannot evidence. Mickai installs on hardware you own and runs offline, so contract data stays inside your perimeter.
What does DEFCON 531 require you to protect?
DEFCON 531 is the MOD's standard disclosure-of-information condition, and it operates on disclosure rather than on classification. In plain terms it stops a supplier passing information the Authority has provided, or information arising from the contract, to anyone outside the people who need it to perform that contract, without the Authority's prior written agreement.
That catches a great deal of ordinary material. Statements of requirement. Pricing breakdowns and rate cards. Drawings, interface documents, delivery schedules, commercial correspondence. Most of it arrives with no marking at all, which is exactly why bid teams assume it is safe to paste into a chatbot while they tidy up a response. The condition does not ask whether a document was marked. It asks who ended up holding it.
DEFCONs are revised, and the edition that binds you is the one your contract schedule incorporates, so work from your own contract and your commercial officer rather than a copy someone found online. Then apply the operational test before any tool touches contract material: can you name every party that will hold, process or retain that text, and show each one sits inside the need-to-know population? If you cannot answer that, you have not cleared the tool. You have decided not to look.
Does OFFICIAL-SENSITIVE material change the answer?
It raises the consequences without changing the logic. OFFICIAL-SENSITIVE is a handling caveat applied to information at OFFICIAL where wider circulation would cause damage, so the originator has deliberately narrowed who should see it. The Government Security Classifications policy and your own security officer set the handling rules, and those rules travel with every copy you make.
A copy pasted into a text box is a copy. It exists somewhere you do not administer, on storage you cannot inspect, for a period you did not set. If a security officer later asks where that document went, the honest answer is that nobody knows, and "the vendor says it was not retained" is not evidence. It is a statement from an interested party.
There is a second reason to take the caveat seriously. Suppliers on MOD contracts are assessed under the Cyber Security Model, which risk-assesses contracts involving MOD identifiable information and asks suppliers to self-assess their controls. Once you have declared how information is handled, an uncontrolled route to a hosted AI service quietly contradicts your own return. That is a harder conversation than the original data question.
Is an enterprise AI licence enough for contract data?
No, not on its own. An enterprise agreement changes commercial terms: retention windows, a training opt-out, a choice of processing region, an admin console, contractual promises about confidentiality. All of it useful. None of it changes the fact that the information crossed your boundary, which is the thing the contract condition turns on.
The deeper problem is that the assurance is contractual rather than technical. You are relying on a third party's description of its own behaviour, with no independent way to test it. The logs sit on their side. The retention setting is a switch you were shown in a user interface. When an auditor asks what left the building, you can produce a clause, not an observation.
This is not an argument against hosted services generally. Most of what a defence supplier does has nothing to do with contract information: general research, marketing, internal tooling, code that touches no MOD material. Cloud earns its place there, and the companies building that layer are doing hard work well. My argument is narrower. It is against the assumption that regulated work has to be rented, shipped offsite and taken on trust. Split the estate by data class and the question stops being ideological.
What does a defensible deployment look like?
Two properties carry it. The model runs on hardware your organisation owns, and there is no network route from that hardware to anyone else. Everything else is detail.
That is what the Mickai Sovereign Intelligence Operating System does. It installs on your own machines, runs offline and sends nothing out. You can place it on a segmented network or a fully air-gapped one. There are 63 studios in the system, 14 production-ready at launch and 49 in development, drawing on 50 specialised models for different kinds of work. Consequential actions do not fire on their own. They wait for a named person to approve them, so the record shows a human decision rather than an inference.
One honest limit, because bid teams always ask about documents. A local OCR runtime has read scanned PDFs in controlled tests, and the extraction and ingestion integration inside SIOS is still being completed. If your first use case is dropping in a folder of scanned contract packs and asking questions of it, that work is in progress, and I would rather you heard it from me than found it in a trial.
The closed beta is open, with one regulated company onboarding as a design partner.
How do you evidence that nothing left the building?
With two separate kinds of evidence: network evidence and action evidence. Neither satisfies a serious reviewer on its own.
The network side belongs to you. Egress rules, firewall configuration, segment design, the absence of any route out. Your infrastructure team already knows how to produce that, and it is the same evidence you would produce for any other contained system.
The action side is what most deployments cannot produce. In SIOS, every consequential action is sealed in the Open Audit Record under ML-DSA-65, the post-quantum signature scheme NIST published as FIPS 204 in 2024. An auditor exports the record, takes it away and verifies it offline against a public key, using tools that are not ours. We are not in the loop at verification time, which is the point.
Be precise about what that property is. It is tamper-evident, not tamper-proof. Tamper-proof would claim the record cannot be altered, and nobody can honestly promise that about bytes on a disk that someone sufficiently privileged can reach. Tamper-evident means an altered record fails verification, visibly, to a person holding only the public key. That turns a silent edit into a finding. In an assurance conversation it is the stronger position, because it does not ask anyone to trust us.
What should you write into your internal AI policy?
Classify tools by where they run, not by brand, and keep the rule short enough that a bid manager at 9pm can follow it. Four lines do most of the work.
First, a named list of approved tools per data class, with MOD contract information (marked or unmarked) restricted to tools running on infrastructure the company controls. Second, a standing statement that putting contract material into any other service counts as a disclosure and needs the commercial team involved before it happens, not after. Third, a route for staff to ask about an unlisted tool, answered in hours rather than weeks, because a slow policy gets bypassed and you lose visibility of what people actually use. Fourth, a flow-down obligation so subcontractors hold the same line, since a tier-two supplier's habits become your exposure.
Two documents are worth reading before you write it. The NCSC's Principles for the security of machine learning covers failure modes specific to these systems. JSP 936, Dependable Artificial Intelligence in Defence sets out MOD's own direction on how AI is developed and used in defence, which tells you how your customer thinks about the subject.
Then name an owner. A policy with no owner is a document, not a control. If you want to see how this is assembled on hardware you own, the offline assistant and sovereign AI pages cover the deployment side.
Frequently asked questions
Can we use a public AI chatbot to draft a defence bid?
Not with MOD contract information in it. The moment a statement of requirement, a price or a drawing goes into a public service, you have disclosed it outside your need-to-know population and you cannot evidence where it went. Generic bid-writing technique is fine. Anything specific to the contract belongs on a system your organisation controls.
Does the MOD have a standard contract clause on generative AI?
No condition dealing specifically with generative AI was found in the published DEFCON set at the time of writing. The duty flows from the conditions already in your contract, principally the disclosure-of-information condition and the cyber requirements assessed under the Cyber Security Model. Treat AI as one more route by which information can leave, and apply the existing rules to it.
Can we use AI on export-controlled technical data?
Treat that as a licensing question rather than an IT question. UK strategic export controls can cover transfers of controlled technology by electronic means, so putting such data into a service that processes it elsewhere may require authorisation. Ask your export control officer before any tool touches it. Keeping the processing on your own hardware avoids the transfer question entirely.
What do primes ask tier-two suppliers about AI use?
Expect questions about which tools are approved, where they run, whether contract data is retained or used to train anything, who inside your business can see the outputs, and what evidence you hold. The answer that survives scrutiny is a named tool list tied to data classes, plus logs you produced yourself rather than a statement from a vendor.
Does using AI on contract information need the Authority's written consent?
It depends on whether a disclosure occurs. If the tool sends contract information to a third party that holds or processes it, that is a disclosure and consent is the safe assumption. If the tool runs on hardware you own and the information never leaves your need-to-know population, no new disclosure has happened. Confirm the position with your commercial officer.
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 for Procurement Contract Review: Is It Allowed?
- AI Supplier Contract Clauses: A UK Buyer's Checklist
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)