JSP 936 Part 1 is the MOD's directive on dependable AI. It sets mandatory requirements built on five ethical principles: human-centricity, responsibility, understanding, bias and harm mitigation, and reliability. Suppliers must show governance, assurance and human accountability across the AI lifecycle. Mickai answers the evidence question with a tamper-evident record sealed before each action runs.
What is JSP 936 and does it apply to suppliers?
JSP 936 Part 1, Dependable Artificial Intelligence (AI) in Defence, is the MOD's directive on how AI-enabled capability is adopted and held to account. It is departmental policy, so strictly speaking it binds the MOD and not your company, but it reaches you through the contract. It was published on 13 November 2024 and gov.uk calls it the principal policy framework governing the safe and responsible adoption of AI in the MOD.
That distinction matters less than bid teams hope. Policy that binds the buyer arrives at the supplier through the contract. What you will be asked for at bid stage, and again at every gate review after it, is evidence that your system can be operated in line with the directive: who is accountable, what was assured, and what actually happened. If you sit below a prime, it reaches you through flow-down. Read the clauses in your own contract rather than a summary of them, including this one.
What are the five ethical principles a supplier must support?
The directive rests on the five ethical principles the MOD set out in its 2022 policy on AI-enabled capability, Ambitious, Safe, Responsible: human-centricity, responsibility, understanding, bias and harm mitigation, and reliability. They are not slogans. Each one implies a specific artefact that you either have or do not have.
Human-centricity asks who is affected by the system and how their interests were weighed. Responsibility asks for a named human accountable for a given use, a person rather than a team or a function. Understanding asks whether the people operating the system can explain what it does and where it fails, which is a training and documentation problem as much as a technical one. Bias and harm mitigation asks what you tested for and what the testing found, including the results you did not want. Reliability asks for evidence that the system performs as specified under the conditions it will actually meet.
What does the directive require on governance and assurance?
Governance and assurance across the AI lifecycle are the two things the directive is built around. Governance means a documented owner, defined decision rights, and a route by which a concern stops the work rather than being noted and passed along. Assurance means activity proportionate to the risk, evidenced at the time, and repeated when the system changes.
In a bid this lands as three questions. Who decides this system is fit for use, by name and role. What did you do to test that judgement, and what did the testing produce. What happens when the model, the data or the threat picture changes. Be clear about what sits alongside this rather than inside it. The Cyber Security Model and Def Stan 05-138 cover supplier cyber risk against a specific contract. The NCSC machine learning principles covers attack surface that conventional security review misses, including poisoned training data and adversarial input. Both matter. Neither answers the AI directive, and answering one well is not credit against the others.
What evidence does human accountability actually need?
It needs a record that ties a named person to a specific action at a specific time, and that stands up when checked by someone who has no reason to trust you. That is a higher bar than most AI deployments clear, and it is where assurance conversations tend to break.
Everybody can produce a policy stating that a human approves high-consequence output. Very few can produce the approval itself, in a form that cannot be quietly rewritten afterwards. Application logs are normally mutable by anyone with database access, which includes your own administrators and anyone who has taken their credentials. A log your insiders can edit is not evidence of oversight. It is a claim about oversight, stored in a place where claims can be changed. An assessor who has seen that pattern before will ask the follow-up question.
What does JSP 936 expect across the AI lifecycle?
Lifecycle means the evidence is not a single gate at delivery. Data, build, evaluation, deployment, change and retirement each carry their own record, and those records have to stay connected to each other.
The chain runs like this. Where the data came from and on what licence. Which model version and which weights were live. What the evaluation of that version produced. What changed at the last update and who signed it off. The common failure is simple and expensive: an audit in month eighteen asks what the system did in month four, the model has been updated eleven times since, and nobody recorded which version produced the output under question. Binding the version to the decision at the moment the decision is made solves that. Nothing reconstructed afterwards does, and reconstruction is exactly what an assessor is trained to spot.
How do you show what an AI system actually did?
You seal the record before the action runs, and you let somebody else verify it without your help. That is the problem the Mickai Sovereign Intelligence Operating System was built around. SIOS runs on hardware the customer owns, is offline capable, and moves no data off the estate.
Every consequential action is sealed into the Open Audit Record under ML-DSA-65, the post-quantum signature scheme NIST published as FIPS 204 in 2024. The order is deliberate: seal, persist, then act. A consequential action waits for a named person to approve it, and that approval is part of the sealed record rather than a note beside it.
The record is tamper-evident, not tamper-proof, and the difference is the whole argument. Tamper-proof would mean the record cannot be altered, and nobody can honestly promise that about data sitting on a machine that somebody administers. Tamper-evident means alteration breaks verification: change a byte and the signature stops checking out. Delete the whole record and the absence is conspicuous rather than silent. The property rests on key custody. Protect the signing keys and it holds. Lose control of them and it does not. That is the honest shape of the property, and an assessor can test it.
An auditor exports the record and verifies it offline with a public key, using tools that are not ours. That is the point of the design. Evidence you have to take my word for is not evidence. There is more detail on what an auditor can independently check and on the audit trail itself.
Some practical detail, because bid teams ask. SIOS covers 63 studios, 14 of them production-ready at launch and 49 in development, with 50 specialised models. The closed beta is open, with one regulated company onboarding as a design partner. I am not naming the partner or the sector it works in. On scanned paper, which defence work generates in volume: a local OCR runtime has read scanned PDFs in controlled tests, and the extraction and ingestion integration into SIOS is still being completed. I would rather tell you that than let you assume it is finished. The underlying approach is covered by 104 filed UK patent applications carrying 2,340 claims, owned by Mickai LTD. Filed, not granted.
None of this is an argument against the companies building the compute or the cloud layer. Cloud stays valuable for work that is not regulated, and most of what any organisation does is not regulated. The assumption worth arguing with is narrower: that a regulated organisation must rent its intelligence, ship its data offsite, and take a vendor's word for what happened to it. For sovereign AI in defence that assumption is the thing that fails assurance.
What should you work through before you bid?
Read Part 1 yourself rather than a consultant's summary of it. Name the accountable person for each use case, as a person. Write down decision rights and the escalation route, then test that the route actually stops work. Record data provenance and licence position for training and reference data. Bind model version to output at the point of decision. Keep evaluation results, including the failures, against the version they belong to. Make approval records verifiable by a third party who does not trust your infrastructure. Keep the cyber answer and the AI answer separate, because they are separate questions. Plan for change, because the model will change and the assurance has to survive it.
The suppliers who find this straightforward are the ones already keeping records they never expected to have to explain. If you cannot currently say who approved a given AI-assisted action, on what basis, at what time, and prove it to somebody who starts from the assumption that you are wrong, that is your gap. It is cheaper to close before a bid than during one. There is a longer treatment of the same problem in the defence AI assurance gap.
Frequently asked questions
Does JSP 936 apply to a subcontractor?
JSP 936 is MOD policy, so it binds the department rather than your company directly. It reaches you through the contract, and it reaches a subcontractor through flow-down clauses in the contract above yours. If you sit at tier two or three, ask the prime for the exact wording rather than assuming what applies. Read the clauses, not a summary of them.
Is JSP 936 the same thing as Def Stan 05-138?
No. Def Stan 05-138 is the MOD's cyber security standard for defence suppliers, applied through the Cyber Security Model with a risk assessment against each contract. JSP 936 is about dependable AI: governance, ethics and assurance of AI-enabled capability across its life. You can meet the cyber standard in full and still have nothing that answers the AI directive.
What does JSP 936 Part 2 cover?
A JSP is normally issued in two parts: Part 1 is the directive, the mandatory policy, and Part 2 is guidance on how to meet it. Part 1 on dependable AI is the published directive. Check the gov.uk publication page for the current status of Part 2 rather than relying on somebody's description of guidance you have not read yourself.
Do we need ISO 42001 to satisfy JSP 936?
No. ISO/IEC 42001 is an AI management system standard, and certification against it is useful evidence of governance discipline, but it is not what the directive asks for and it is not a substitute for it. A certificate says your management system was audited. It does not say what your AI system did on a given Tuesday.
How do we prove human oversight of an AI-enabled system?
Not with a policy document. You need a record naming the person who approved a specific action, what was put in front of them, when they approved it, and what the system did next, in a form somebody can check without trusting your infrastructure. If an administrator can edit that record afterwards, it is an assertion rather than evidence.
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)