AISTORSServicesAI governance and compliance
Service 08Written down before anyone asks for it.
For risk, legal and engineering leaders who have AI in production and nothing an assessor would accept as evidence. The gap is rarely the policy document. It is the audit trail, the model documentation, the incident playbook and the tested controls behind them. We build that evidence while the systems are being built, not reconstructed under deadline afterwards.
Book a 30-minute call
What an assessor actually asks for
Not the policy document. The audit trail, the model documentation and the tested incident path behind it, built while the system is built rather than reconstructed under deadline.
If the left column is not you, say so on the call and we will tell you what would help instead.
Four gaps show up in almost every AI governance review. None of them is solved by a policy document.
What we do. We implement the controls and produce the evidence that they operate: access registers, approval gates, audit logs, retention settings and the tests that show each one works. The policy then describes something real.
What we do. Audit trails are designed in at build time, recording input, model version, prompt or feature set, output, and the human approval where one applied. Reconstructing this after the fact is expensive and usually incomplete.
What we do. Model cards, the sub-processor list and the risk assessment are versioned alongside the system and updated from the provider's announcement rather than at audit time, so what is documented matches what is running.
What we do. We write the AI-specific incident playbook and then rehearse it, because an untested playbook is a document rather than a control. This is the single most commonly missing item we find.
Eight deliverables, all of them artefacts an assessor can read.
The first phase often reveals that the exposure is narrower, or wider, than assumed.
Every AI system in production or planned, including the ones bought rather than built and the ones nobody registered. Shadow usage is normal and finding it is part of the work.
Each system classified against the frameworks that apply to you, with the obligation and its date recorded. Where scope is genuinely uncertain, we say so rather than assume the stricter reading and inflate the work.
What an assessor would ask for, what you can produce today, and what is missing. Delivered as a ranked list with effort against each item so you can decide what to close first.
Implemented in your environment, versioned with the systems they govern, and accompanied by the evidence that each control operates.
Adversarial testing of the deployed systems, findings ranked by real consequence, and one rehearsal of the incident playbook so it becomes a tested control.
Dates move, as the Digital Omnibus demonstrated. The register is re-checked against the published timetable at each review rather than trusted from the original plan.
Governance evidence is produced from your own platform's native controls, not from a tool of ours.
Azure
Azure Policy and Purview for classification and lineage, Defender for Cloud posture, Entra ID access reviews, AI Foundry content safety and model logging.
AWS
Config and Control Tower for policy, CloudTrail and Audit Manager for evidence, Macie for data classification, Bedrock Guardrails and model invocation logging.
Google Cloud
Organisation Policy and Assured Workloads, Cloud Audit Logs, DLP for classification, Vertex AI model registry and safety filters.
DigitalOcean and self-hosted
Where open-weight models run in your own estate, the audit trail, access control and retention design are built explicitly, because the platform supplies less of it for you.
Everything is built on controls you already own and can keep operating after the engagement. If an assessor can only get the evidence by asking us, the control belongs to us rather than to you, which is the wrong place for it.
You do not need these numbers to recognise the problem. They are here because somebody in your approval chain will ask.
28%
of 510 senior leaders said they had incident-response playbooks for AI failures. 23 percent said they conducted adversarial testing.
Source: UST, Enterprise AI at Scale, 2026; global survey of 510 senior leaders.
86%
of organisations reported experiencing AI-related incidents.
Source: OneTrust 2026 AI-Ready Governance Report.
47%
have clear governance, oversight and controls in place, while 87 percent encourage agent use.
Source: OneTrust 2026 AI-Ready Governance Report.
The gap between the last two figures is the whole problem. Most organisations are actively encouraging agent use while fewer than half have the oversight to govern it, and incidents are already common rather than hypothetical. Set against roughly one in four having a tested incident playbook, the exposure is not that something will go wrong. It is that nobody has decided in advance what happens when it does.
Not all of them, and we publish exactly which. We would rather tell you than have you discover it during due diligence. The current status table is in section 11 of the main site, and it distinguishes between what we help clients achieve and what we hold ourselves.
No, and this is the most common out-of-date assumption we meet. The Digital Omnibus on AI came into force on 27 July 2026 and moved the standalone high-risk obligations under Annex III to 2 December 2027 and the embedded high-risk obligations under Annex I to 2 August 2028. Transparency and watermarking obligations for AI-generated content apply from 2 December 2026. We re-check this timetable at every review.
Possibly, if your system is used in the EU or its output is. Territorial scope is a legal question rather than an engineering one, so we will tell you what the architecture does and where it sits, and your counsel decides whether the obligation attaches.
No provider can, and one that says otherwise is selling something. Compliance is a state your organisation maintains, not a deliverable we hand over. What we produce is the technical evidence, documentation and controls an assessor asks for, plus an honest list of the gaps we cannot close for you.
No, and we should not. We prepare the evidence and the controls; an independent assessor certifies. A supplier who both builds the controls and signs them off is a conflict of interest you should decline.
It is tracked from the provider's announcement rather than discovered later. Model documentation, the sub-processor list and the risk assessment are versioned, so a change produces an update to the record instead of a silent divergence between what is documented and what is running.
Thirty minutes, no obligation. Tell us what is live, who is going to ask about it, and by when. We will tell you which frameworks plausibly apply, what an assessor would ask for first, and whether the deadline is realistic.
Or write to [email protected].
AI capability and data handling
Which model providers, on what terms, with training disabled, residency respected and every sub-processor named before you sign.
Service 09Managed AI and cloud operations
Governance that is not maintained decays. This is the layer that reports against it every month.
Service 01AI agents and assistants
Where the boundary of what an agent may decide alone becomes a contract term rather than a configuration flag.