AI assurance: proving your system says what it can defend.
Almost everything written about AI TRiSM explains the framework. Very little of it answers the question a business actually has, which is: can we show someone that this system is right?
I verify that AI systems produce output that is correct, attributable and auditable — against a frozen evaluation set, with the run artefacts attached.
I run this work against my own systems first, and publish the results. The most recent published run records 0 hallucinated citations across 297 cases and 144/150 retrieval accuracy on PatronusAI FinanceBench. Methodology and raw artefacts are on the proof page so you can check the claim rather than accept it.
“AI assurance” is three different markets
The phrase gets used for three unrelated problems, sold by three unrelated kinds of supplier. Sorting them out first saves everyone a wasted call.
| The question | Who solves it | Do I? |
|---|---|---|
| Is our AI’s output correct and attributable? | Practitioners who have built and measured retrieval systems | Yes — this is the work |
| Can we govern and evidence AI risk across its lifecycle? | Security vendors, auditors, and governance consultancies | Yes — the technical half |
| What does ChatGPT say about our brand? | Monitoring SaaS — Profound, Peec AI, Semrush and similar | No — buy a tool |
The third row is worth stating plainly because the vocabulary overlaps badly. Brand visibility in AI answers is a real and growing concern, and it is a monitoring problem with mature tooling behind it. It is not an assurance engagement, and a consultant who sells it as one is selling you a dashboard at consulting rates.
What actually gets verified
Assurance fails when it becomes a document review. These are the checks that produce evidence rather than opinion:
- Grounding. Every factual claim the system makes traces to a source it genuinely retrieved — not to a source that merely exists.
- Refusal behaviour. When retrieval returns nothing useful, the system declines rather than fills the gap. This is the single most under-tested property in production AI, and the one that causes the incidents.
- A frozen evaluation set with a threshold agreed beforehand. A threshold set after seeing results is not a threshold. Building the set is its own discipline — there is a separate write-up on how.
- Deterministic controls the model cannot override. Access rules, redaction and audit logging have to hold regardless of what the model decides.
- Adversarial input. Whether retrieved content can instruct the system — see prompt injection defence.
- Tenant isolation, where it applies. Whether one customer’s data can surface in another’s answer — the four-layer version.
Why an engineer rather than an auditor
Governance frameworks are well documented and freely available. Gartner’s AI TRiSM material is explained at length by Palo Alto Networks, Proofpoint and others. You do not need to buy the framework.
What is scarce is somebody who can open the retrieval layer and tell you whether the controls described in the document are the controls actually running. I build these systems — a live multi-tenant citation-verification platform, a codebase intelligence product, and validation work in a regulated pharmaceutical environment covering audit trails, prompt-injection guardrails and 21 CFR Part 11 readiness.
That is also the honest limit of the offer. I assess the technical substance. A formal regulatory sign-off is a different profession, and where an engagement needs one I will say so rather than approximate it.
Regulatory context by market
Assurance work is documentary and remote — evaluation sets, run logs and written assessments — so the binding constraint is the regime, not the postcode.
- Malaysia and Singapore. PDPA obligations, and for Singapore the PDPC’s advisory guidance on personal data in AI recommendation and decision systems.
- United Kingdom and EU. UK GDPR and the Data Protection Act 2018, with EU AI Act obligations phasing in for higher-risk systems.
- Regulated life sciences. 21 CFR Part 11, where the hard part is validating something non-deterministic against a fixed expected output.
How an assessment runs
A short call to establish what the system is for and what decision rests on it, because an assurance question is always relative to a consequence. Then the evaluation set is built or reviewed, the checks above are run, and you receive a written assessment with the artefacts attached — findings, the runs behind them, and what remains unverified.
That last part matters. An assessment that reports only what passed is marketing. If something could not be tested in the time available, the report says so. Related work: codebase audit where the concern is the system around the model, and hallucination remediation where the problem is already known and needs fixing rather than measuring.
Frequently asked questions
What is AI TRiSM?
AI Trust, Risk and Security Management — a governance framework originating with Gartner, covering whether an AI system can be trusted, what it can be relied on to do, and how it is secured and monitored over its lifecycle. Most published material on it is definitional. The practical question underneath is narrower and answerable: can you demonstrate, with evidence, that this system produces correct and attributable output, and can you show that to an auditor.
What does independent AI assurance actually involve?
Establishing a frozen evaluation set the system is measured against, agreeing a pass threshold before testing rather than after, checking that every claim the system makes is traceable to a source it actually retrieved, verifying that it refuses when retrieval returns nothing, and confirming the deterministic controls a model cannot override are genuinely deterministic. The output is a written assessment with the run artefacts attached, not a score.
Why does independence matter here?
Because the team that built a system chose its evaluation set, and an evaluation set chosen by the builder tends to contain the cases the builder already handles. Independence is not a claim about competence — it is about who selected the test. For regulated work it is often also a procedural requirement rather than a preference.
Do you monitor what ChatGPT or Gemini says about our brand?
No. That is a distinct product category with established tools — Profound, Peec AI, Semrush and others track brand mentions, share of voice and citation sources across AI assistants. If that is the requirement, buy one of those; it is a monitoring problem, not an assurance engagement. What I work on is whether your own AI system produces output you can stand behind.
Which markets do you work with?
The United Kingdom, United States, Singapore and Malaysia. Assurance work is documentary and remote by nature — the artefacts are evaluation sets, run logs and written assessments — so the constraint is regulatory context rather than location. Malaysian and Singaporean engagements typically sit against PDPA obligations; UK and EU work against UK GDPR and the EU AI Act; regulated life sciences against 21 CFR Part 11.
Find out what your system can actually defend
Bring the system and the decision that depends on it. If assurance is the wrong instrument, I will say so on the call.
Last updated