Most organisations now have AI somewhere in the building. Bought in, switched on inside a product they already use, or piloted by a team who saw a chance to save time. Very few can show how it is governed, who owns it, or what happens when it gets something wrong.
I put that governance in place, working to ISO/IEC 42001, the international standard for AI management systems. It is practical work. You end up with a set of documents your people actually use, and a way of running AI that keeps going after I have gone.
Qualified
BSI-certified ISO/IEC 42001 Lead Implementer. Trained and certified by BSI against the international standard for AI management systems.
Procurable
On G-Cloud 15 (RM1557.15, Lot 3 Cloud Support Service), awarded July 2026. Public sector buyers can call off directly through the Digital Marketplace.
Grounded
27 years delivering technology change in the NHS and the wider public sector, including four national programmes and an organisation brought out of CQC special measures. That is not AI governance experience, the standard is younger than that. It is knowing how these implementations go wrong, which is what the method is built around.
Which one fits depends on where you are and what is driving it. If you are not sure, that is a normal place to start and the first conversation usually settles it.
Where do we actually stand? I find the AI you are using, including the parts nobody has declared, and measure it against the standard. You get a plain report of the gaps, what matters most, and what it would take to close them. The usual first step, and often enough on its own for a while.
You are putting a specific tool into live use and want it done properly. Risk and impact assessment, the data protection work, supplier assurance, a monitoring plan, and a go live gate with named owners. Where the system touches clinical care, the clinical safety workstream runs alongside it.
The whole management system, built to the standard. Scope, policy, roles, objectives, risk method, controls, internal audit and management review. Certification afterwards is your choice, and the aim either way is a system that runs without me.
You build or sell AI and a customer has started asking questions you cannot yet answer. This gets your own house in order, including the model documentation and update policy that buyers increasingly ask to see, and the evidence you would need if a customer or a regulator starts asking about the EU AI Act.
Choosing a supplier can be added to any of these. If you have not picked the AI yet, doing the requirements work with your users first tends to be the difference between a tool people use and a tool people work around.
Almost nobody wakes up wanting an AI management system. Something prompts it, and it is normally one of these. If you recognise one, you are in the ordinary case rather than a late one.
A security questionnaire or a bid now has AI questions in it, and the honest answer to several of them is that nobody here knows.
A tool a team wants has been held at the gate because there is no assessment, no owner, and no policy to point at.
Usually a short one. What AI are we using, and who is accountable if it goes wrong. It is surprisingly hard to answer from a standing start.
An output was wrong in a way that reached someone, or a tool turned out to be doing more than anyone had agreed to.
Or is about to be. This is the one where the work is best started before the letter rather than after it.
A pilot worked and it is going into real use. That gap is where the governance either gets done or gets skipped.
The decision points are fixed and dated, and each has a named person who signs. What happens between them flexes as we learn what is really there. Gates you cannot iterate past are the ones that protect people, so those hold.
There is a method, and it is most of what makes this work. How it meets your own reporting and governance is something we settle at kickoff rather than assume, and the plan can hand over as data if your systems need to take it. What matters is that there is one plan and not two, because two plans drift apart and then nobody is sure which one is right.
The registers you will keep using, risks, suppliers, findings, the AI inventory, hand over as working data rather than a frozen report. A system that only runs while I am there has not really been handed over.
Every number in a proposal comes with the working shown, line by line, so you can challenge any of it.
Worth saying plainly, because in this field the boundaries matter and some of them are not optional.
Nothing I produce is "ISO approved". ISO writes standards and certifies nobody. Certification, if you want it, is decided by an independent UKAS-accredited certification body. My job is getting you genuinely ready for that conversation.
Independent audit of a management system I implemented would not be independent. Internal audit as a service is deliberately not on this page.
Where clinical safety applies, I coordinate and support the work and produce the evidence. The Clinical Safety Officer is a clinician and that role stays with your own clinician, or a partnered one. I am not a clinician.
I will tell you where a regulatory question sits, and what evidence you would need to answer it. The advice itself, and any formal regulatory determination, come from people qualified to give them.
Six questions, rough answers welcome. "Don't know" is a perfectly good answer to any of them, and is often the useful one. I aim to reply within two working days.
There is a longer discovery questionnaire, fifteen questions, that covers the ground a proposal needs. Ask for it and I will send it over. It is not a prerequisite for talking, and plenty of engagements start with a phone call instead.
