AI Governance, Security and Compliance
Governance that survives an auditor, a regulator and an enterprise customer's questionnaire. Thirteen engagements covering frameworks, regulation, assurance and the security of the systems themselves.
Most AI governance is written to be filed.
The common failure is not too little governance but the wrong kind: a policy that affirms responsible use without answering whether you may paste a contract into a chatbot, a risk register of amber ratings with no decisions attached, an inventory built by survey that was incomplete the day it was finished. All of it satisfies a reviewer and changes nothing about what the organisation actually does.
So the work here starts from what is really running — including the vendor features nobody declared — makes review proportionate enough that teams route through it rather than around it, and tests claims against evidence rather than accepting them. Where a system cannot be measured, or a fairness definition has not been chosen, or a deletion request cannot honestly be answered, that is written down as a finding rather than smoothed over.
What we build
Each is a standalone engagement with its own scope, price and output. Most clients use two or three in sequence.
AI Governance Framework Design
Proportionate risk tiers, named accountability and decision rights — a framework people follow rather than route around.
Read more →EU AI Act Compliance Readiness
Classification, the transparency duties already in force, and a plan against the deferred 2027 and 2028 deadlines.
Read more →ISO/IEC 42001 Implementation
An AI management system built for certification and for use, reusing your ISO 27001 machinery rather than duplicating it.
Read more →NIST AI Risk Management Framework Alignment
Govern, Map, Measure and Manage applied to real systems, producing evidence rather than a maturity score.
Read more →AI Risk Assessment and Model Cards
Risk assessments that end in decisions, and model cards that state limits honestly rather than advertising.
Read more →Responsible AI and Bias and Fairness Audit
The fairness definition chosen explicitly, disparities measured on real subgroups, remediation tested not asserted.
Read more →Explainable AI Implementation
Explanations built for a named audience — affected person, regulator, or engineer — because each needs something different.
Read more →AI Red Teaming and Adversarial Testing
Adversarial testing against your threat model, with reproducible findings and regression tests you keep.
Read more →LLM Security: Prompt Injection and Data Leakage
Security by architecture: untrusted model output, constrained tool permissions, enforced retrieval permissions.
Read more →Data Privacy for AI: GDPR, HIPAA and DPDP
Lawful basis, DPIAs, transfers, and the hard questions — deletion rights and retention inside trained models.
Read more →AI Policy and Acceptable-Use Documentation
Specific rules with named tools and worked examples, plus an approval route fast enough that people use it.
Read more →AI Audit and Third-Party Assurance
Independent assessment against a stated standard, with evidence tested rather than taken on assertion.
Read more →AI Inventory and Model Registry
A complete inventory including shadow and vendor AI, kept current by discovery rather than by annual survey.
Read more →How they fit together
You do not need all twelve. Most programmes follow one of these paths depending on where the uncertainty sits.
Build the operating model
Framework design with proportionate risk tiers and named accountability, an AI inventory built by discovery rather than survey, and acceptable-use policy specific enough to answer real questions.
Meet the regulation and the standards
EU AI Act readiness against the current timetable, ISO/IEC 42001 certification, NIST AI RMF alignment and privacy compliance under GDPR, HIPAA and DPDP.
Assess the systems themselves
Risk assessment and model cards that end in decisions, bias and fairness audit with the definition chosen explicitly, and explainability built for a named audience.
Secure and assure
Red teaming that leaves a regression suite behind, LLM security designed on the assumption the model can be subverted, and independent audit and assurance for readers who will not accept a self-assessment.
FAQ
Marked up with FAQPage schema so these answers can surface in search results and inside AI assistant responses.
When do the EU AI Act's high-risk obligations apply?
Following the Digital Omnibus package approved by the Council on 29 June 2026, Annex III stand-alone high-risk systems apply from 2 December 2027 and Annex I systems embedded in regulated products from 2 August 2028 — deferred from August 2026 and August 2027. The prohibitions, AI literacy duties, general-purpose AI obligations and Article 50 transparency duties are already in force. See EU AI Act compliance readiness. This is our understanding as at September 2026; we are not lawyers and work alongside your counsel.
Do we need ISO 42001, NIST AI RMF, or both?
It depends on who is asking. ISO/IEC 42001 gives you a certificate from an accredited body, which is what procurement and public tenders increasingly ask for. NIST AI RMF is voluntary with no certificate and is cited in US enterprise and federal-adjacent contracting. They overlap heavily, so the evidence largely serves both — build once rather than running two programmes.
Where do we start if we have nothing?
With the inventory, because every other requirement assumes you know what you run and almost no organisation does. Discovery through procurement, expense and engineering records reliably finds more AI than any survey, and the size of that gap usually settles how much framework you need and how urgently.
Can prompt injection be prevented?
Not completely. Instructions and data reach a language model through the same channel in the same form, with no reliable way to separate them, so any product promising prevention is overselling. The workable position is to assume the model can be subverted and bound the damage architecturally — see LLM security and red teaming.
Can you certify or audit us?
We can audit against a stated standard and produce an independent opinion with tested evidence, which is what most boards and enterprise customers are asking for. We cannot issue a certificate — that requires an accredited certification body — and we will not audit a framework we designed and built, because that is not assurance. Where that applies, we say so and recommend a different assessor.
Start with a conversation.
Thirty minutes, no charge, no deck. Tell us what you are trying to build with language models and we will tell you which of these engagements fits, or whether none of them do.