Service 04
AI governance & compliance
The policies, registers and evidence trail that let you say yes to AI, and prove to a regulator, an auditor or a procurement panel exactly how it is controlled.
What governance is actually for
Most AI governance work is sold as risk reduction. In regulated organisations its real function is closer to the opposite: it is what allows things to be approved. Without it, every proposal reaches the same meeting and stalls on the same unanswerable questions, and the organisation slowly acquires a reputation for not being able to do this.
Good governance is not a set of prohibitions. It is a defined path to yes, with the evidence already assembled.
What we produce
An AI inventory that is actually complete
You cannot govern what you have not counted, and almost every organisation we assess materially underestimates its own footprint, because AI arrives embedded in tools procured as something else. Lead scoring in the CRM. CV screening in the HR platform. Auto-triage on the service desk. These are frequently higher-risk than anything on the roadmap, and nobody has assessed them.
A policy people can follow
Most AI policies fail because they are written as prohibitions and are therefore ignored, which converts managed risk into invisible risk. Ours specify which data classifications may go into which tier of tool, and give a route to get something approved. If the compliant path is impossible, you have not reduced risk; you have relocated it somewhere you cannot see.
Risk entries with the AI-specific failure modes
Generic technology risk registers miss what actually goes wrong: confident incorrect output, drift as the world changes underneath a fixed model, prompt injection through untrusted content, over-reliance by users who have stopped checking, and data leaking into a tool tier it was never classified for. Each gets an owner, a control and a review date. "We are aware of hallucination" is not a risk entry.
DPIAs done at design time
For AI processing personal data at scale or consequence, the DPIA is a legal requirement and the most useful document you will produce, provided it is written before the architecture is fixed, when its conclusions can still change something. Done then, it also pre-answers most of what information governance and procurement will later ask.
EU AI Act position, in writing
A scope determination for each system (are you in scope, and as provider or deployer) plus Article 5 prohibition screening across your third-party tooling, and Annex III classification for anything heading toward the December 2027 deadline. Written reasoning, not just conclusions, because the reasoning is what you will need when someone asks in two years.
AIME and ISO/IEC 42001 groundwork
We work through the DSIT AI Management Essentials self-assessment with you. That is increasingly relevant if you sell to the public sector, where government has been exploring integrating it into procurement. We also produce a gap analysis against ISO/IEC 42001 if certification is on your roadmap.
How it runs
Weeks 1-2: Discovery and inventory. Systems review, supplier review, interviews, and the uncomfortable exercise of finding out what is genuinely in use.
Weeks 3-4: Assessment. Classification, scope determinations, Article 5 screening, risk identification, control gap analysis.
Weeks 5-6: Artefacts and adoption. Policy, register, DPIAs and templates drafted, then worked through with the people who have to operate them, because a policy written without its operators is a policy that will not be followed.
Where this is most urgent
- You sell to the public sector, or into a supply chain that does, and AI questions have started appearing in tenders.
- You have AI in production that predates any governance around it.
- Your outputs reach EU users and nobody has done an Article 5 screen of your third-party tools.
- Staff are clearly using AI tools that were never approved, and you would rather know than not.
We are not a law firm and this service is not legal advice. We produce the technical and organisational evidence your DPO, counsel and assurance functions need to reach and defend their own conclusions.
Questions we get asked
Is there actually a UK AI Act we need to comply with?
No. As at September 2026 the UK has no cross-economy AI law, and the Regulating for Growth Bill announced in May 2026 proposes sandboxing powers rather than a horizontal regime. But obligations reach you anyway through UK GDPR, sector regulators, equality law, consumer law and employment law. The absence of a single statute makes compliance harder rather than easier, because there is no checklist that discharges the duty: you have to reason about your specific use and evidence that reasoning. We cover this in detail in UK AI regulation in 2026.
Does the EU AI Act apply to us if we are UK-based?
It applies if you place an AI system on the EU market, put one into service there, or produce output used in the EU, the last of which catches organisations that do not consider themselves EU-facing at all. The high-risk deadlines were deferred to December 2027 and August 2028, but the Article 5 prohibitions are enforceable now at up to €35 million or 7% of global turnover. Screening your third-party tooling against Article 5 is the most urgent item on most organisations’ list.
Do we need ISO/IEC 42001?
Worth pursuing if AI governance questions are already appearing in your tenders and security questionnaires, in much the way ISO 27001 became the standard answer for security. Not worth pursuing merely because it exists. The underlying artefacts matter more than the certificate, and they are the same ones you need regardless, so we build those first and let you decide on certification afterwards.
Our policy is that staff must not use AI tools. Is that enough?
It is almost certainly not working. Prohibition-only policies reliably produce shadow usage on personal accounts with the worst possible terms, and you lose the ability to see it. A workable policy tells people which data classifications may go into which tier of tool and provides a route to get something approved. That converts invisible risk into managed risk.
Can you work with our DPO and legal team rather than replacing them?
That is the intended arrangement. We are not solicitors and we do not give legal advice. We produce the technical and organisational substance (inventory, classification, architecture positions, control design, evidence) that your DPO and counsel need in order to reach and defend their own conclusions.
How does this connect to a build?
Directly, and that is the point of buying both from the same place. Governance produced in isolation from delivery tends to be unimplementable, and delivery produced in isolation from governance tends to be blocked at the assurance gate. When we build, the evidence is a by-product of how the system is constructed rather than a document assembled afterwards.
Other services
AI readiness assessment
A structured review of your data, systems, controls and people, ending in a ranked list of AI opportunities with costs, risks and a build order.
Read more 02Private, self-hosted & air-gapped AI
Open-weight models on your own infrastructure or in a UK region you control, up to fully air-gapped on NVIDIA DGX or HGX B300, hardened to DISA STIG and CIS Level 2.
Read more 03AI implementation
Retrieval over your documents, agents that complete real work, and automation wired into the systems you already run, built to be handed over, not rented back to you.
Read moreStart with a straight answer
A 30-minute call, no pitch deck. Tell us what you are trying to do and we will tell you whether AI is the right tool, what it would take, and what it would cost, or that you should not bother.